萤火虫小姐

写成一个项目管理

1、有需求要点的时候,没有做项目的权限跟机会,那时候我眼巴巴瞅着旁人忙来忙去不亦乐乎,心中泛酸水;
2、做项目的时候,没有自主权,我自欺欺人地把过错和拧巴归结为自己只是个影子执行者;
3、终于有自主权做项目的时候,发觉你身旁是今天有人在明天人溜走的开发、一有问题就吵吵的测试、总要耗时数月的后台,一方面我在这纷纭中一天矮视自己一天,另一方面,我还要每天奋不顾身毅然决然地和各种要将问题的源头拧到我头顶上的各路将军抗争,于是我发觉自己变成一天来撞一次钟的半熟老油条了。呜呼哀哉!不记录这良稻变憋谷的过程我真是要被自己的眼神杀死了。
4、欣然认同“成功是成功者之母,失败中孕育下一个失败”这可恨可怕的真理,我觉得现在我就可以忘穿自己下半生了。
5、以上为缘由。
6、分割线。
7、以下为正题。

A 性能优化:
    消灭严重影响功能的BUG要排在产品管理的最高优先级;紧随其后的就是性能优化。如果你玩游戏的时候刚刚向敌人投掷了一支长枪,结果一分钟后这长枪还在空中不落地,这游戏就毁了。如果你只有在吃饭的那个短暂10分钟内可以休闲,结果电子书翻页2分钟都翻不过去,那这东东你也不会再用了。
    跟进性能优化项目的时候,我觉得自己在做一件了不起的事情,因为这是产品维护的核心之一。那时候我太把每个人讲的话当真了(即便现在也依然如此,没救了),看到技术文档上写满了数字和字母就误以为是高端级别代码,看到截图上圈满了红字和绿底标记,就以为会如何如何。
    最后跟进开发的时候才发觉,大侠并不是每天一点一点雕琢,而是事到临头加个班熬个夜大手一挥搞定。最后测试的时候我无言以对,怎么看怎么觉得就是改了跟线条。如果非要说图片压缩了XK,速度提高了X毫秒,那对不起,我真得没什么感知度。
    最后可以认为这次项目经历败得足够让我丢脸,最严重的后果我其实并没有描述出来,因为我现在听到性能二字就很头痛。
     如果我把问题的原因归结为我一星星的技术都不懂,这说得过去么?


B 写论文从来成不了一个项目
    有一类词语/说法,总是我听起来觉得咋呼与费解,而耳听八方,大家又真是在频繁使用的东东,比如说“忙”,比如说“项目”。
    按照六度分割理论,我们一辈子总要认识那么多的人,而几乎又没有人有那么大的脑容量能把认识的这么多人全部消化为“朋友”,于是迎面走来一个六度分割理论中的XXX,你总得招呼一两句吧——“好久不见啊!最近在忙什么呀?”“对呀,好久不见!最近在忙~”
    我一度禁止自己说“我在忙”,结果屡次尴尬地发觉:当我真正陈述自己的近况的时候,原本双方预期的两句以内的谈话竟被延长了,因为彼此都觉得碍于面子无法停止寒暄。
    
    在我一度荒废数年的阳光烂漫的好时光里,我想不明白什么样的事情可以称之为“项目”,那总是一个很宏观的概念,应该指的是开天辟地与大自然作斗争这种级别的技术含量。
    曾经我生活的全部就是阅读纸张与用笔尖锻造垃圾,我不知道工作后还能有什么样的改变。所以我对高我一等的理工科大侠嘴里的“项目”既欣羡又记恨。

    好在我终于在有生之年消了心头嫉恨,也到了可以随口漫谈“项目”的好境界。其实说起来“项目”无它,也就是一个事件的意思。可是我的心是扭曲的,听到什么便都是扭曲的倒影而已。

    起初拿到这个题目“XX领域商业模式创新”,我满心欢喜,觉得自己要干出一番大事业——老毛病难改。我总是把有成寄托在所谓的演绎规则中。固然我们可以从纷繁的现象中捕捉到某种超出现象的东西,但是有成的产品为什么总是那么几个零星呢?
    果不其然,漂亮的材料总是找来了又有新的,刚刚归结出来的行业规则总是不能涵盖全量业务,一张一张的网页累计成庞大数量的缓存,我实际上并没有头绪。模式意味着我要得到一个成形的结论。创新意味着我要拿得出一个金灿灿的果子。
    其实这份作业的潜在设定是,从业者并不需要怎么摸爬打滚,只要我们能找到成功的先锋开辟的路径,那么我们一样可以套用。多么可怕的好吃懒做的行为。
    
    写论文肯定成不了一个项目,我想得太多啦!把它当做一份私人作业,才会OK的呀。


C 开放项目
    去年年底接手的时候,确实非常稚嫩,(当然这么坦承也并不意味着我如今就怎么娴熟了,囧)当时拿着现成的方案跟交互图看了几遍,没察觉到有很多问题.直到从某一天开始,问题就没完没了.
    每次看到各路言论的牛人宣称研发如何被产品经理逼到死角,我就忍不住冒汗:像我这种葱,就是给PM增加分母绝对值的.
    每次被研发追问“这里少了一个环节”“那里少了一步验证的时候”,我真得心如刀割:一方面方案不严谨是上任遗留的赤裸裸的问题,另一方面我自己没有事先发觉,也摆脱不了干系.
    就算最后出来的半成品越来越跟老版本没什么区别,只是换了个新颜,也无法证明我天生就具备某种令人无法企及的才华,对一个潜意识里不会把权威和经验放在眼里的人来说,这真是最最惭愧的一件事情.
    还好我总归会用“以解决问题为首要任务,颜面问题放在一边”安慰自己,最后也真得很努力地去争取维护一些细节,虽然最后以失败告终.
    如果说这个项目就这么在小摩擦和小坎坷中匍匐前进直到顺利上线,我的教训也无非就是无论如何要警惕设计的每一步流程,以及勤于克服“对习以为常的事物熟视无睹但是上手时却一窍不通”。教训远非如此。
    我的UI设计师是一个非常资深的专业设计师,以至于她对任何意见的首要反应就是“你偷懒”“这样的东西你绝对做得出来,只是你怕费脑筋”,最终我怕了跟她沟通。每次对她有所求的时候无非就是绞尽脑汁哄着赔笑着赶紧办完事,但是我自此并不认同她。这叫我无奈又后怕。
    我的项目经理从未履行项目经理的职责对我的分类需求置之不理。这叫我经常生出无能为力之感。
    实际上我一直勇于承认自己就是张白板纸,但是我也不喜欢上来就觉得问题在别人在那里的专业人士,只想着写完代码就ok除此和我无关的负责人。
    既然我们每个人都不是翘楚,那就要看你是否有凝聚各方位牛鬼蛇神才华的魄力和能量,很让我失望的是,我也没有。
    悲伤的事情还在后头。就在上线前一周,因为新项目的缘故,大boss一句话,开放项目要做大变更,其实也就是要回到了之前的就摸样。我至今仍然记得当时的场景和心境:如果说每一个事中人都觉得身不由已无可奈何,那么问题到底出在哪里?

D 闹了一个大笑话
    说到这个事情就头疼脑热惭愧之至。
    此处略去633字。
    总结词就几句话:无论在任何时候,一定要努力用自己的脑子想问题、做事情。如果只是想跟进一件事情做完为止,那就没什么必要了,这种人,我称之为木偶人。

E 几家欢喜几家愁的CTC项目
    从通讯录项目开始,往后的项目基本就是我的命题作文。也就是说组长事先定下每一个季度每一年的大致指标,上报的同时还会预先给出时间点,我知道这个结果后就做一个方案,是为命题作文。
    我不断地在强调我很对自己的遗憾跟失望,是因为,我顶多在流程跟人事交涉上越来越熟练,而在具体的专业领域,我依然一无所知。比如我就不喜欢看到哪个被风投炒热的概念,然后跑去抠下来点儿什么东西安装在自己的版本上,我也不喜欢假设对方什么都不知道到需要你给出baby-seater式的提示。我不喜欢在某个事件发生频率很小的图标上做周而复始的讨论迟迟定不下来方案,我也不喜欢离开一个产品的气质去增加根本八竿子打不着的功能。可是,我喜欢什么呢?我又能拿得出来什么呢?这个才是我最关心的问题啊。我即便明确了我要做的方案,可是我一己之力完全是不能实现的,我还需要为编写代码而疯狂的开发、为问题而兴奋而不是幸灾乐祸的测试,我需要的是各方位放下自己的偏见去共同走向最终方案的3个臭皮匠。
    在上述背景下,就不难以想象我最终在这个项目上几近被逼疯的窘境。
    年前我就将后台跟前端拉到一起协商开发实现的细节,年假中我因为预知到即将面临的困境非常害怕回公司上班;果不其然一开发就囧了。我不能理解为什么后台总觉得前端在给自己增加临时任务,我也不能理解为什么前端总是对后台心存偏见。我不能理解为什么项目经理不问青红皂白就为了完成任务而轻而易举地将问题归结到某一方位的人身上。我不能理解为什么前组长要把这个数据处理量这么大的项目上报测试。
    我完全不能理解,为什么我只是想做一个稍微不那么傻×的东西,结果会是这个样子,就感觉自己给自己挖了一个坑。我就在坑中给自己织茧子。苦不堪言。最后在测试前我连续两个晚上都在重复梦境。
    我只想用充满欢乐的笔触告诫自己,失败固然不能成为成功之母,但是如果不面对并承认失败将更一无所获。
    这事中事,绝非人人所说的尽己之力就好。唉。

评论