忙与盲 – 写在二月底（其一）

春节前后，本应该是项目闲暇的时间。结果1月中旬的部门调整，整个节奏全被打乱了。

N项目的死掉

N项目的确值得我去写一篇文字来悼念，先不来评价这个项目成功与否。它是我2011年底加入这家公司以来一直在做的项目，而是是仅有的一个，所以它的好坏就是我的荣辱。

N项目首先值得肯定的地方是它是一个伟大的构想，没有vision的项目是没有前途的。（对公司来说也是，对人呢？）第二个值得赞许的地方，它是部门Director自己喜欢和力推的项目。所以和其他所有项目一样，刚开始的时候大家都积极乐观对它抱有极大希望。

那么这个衔着金钥匙出生的项目怎么样呢？来说说它的先天不足吧。

第一，项目的范围大。没有哪个老板不喜欢“大”的项目，项目（范围）大才可能入得了更高层老板的法眼，才有可能争取到更多的预算，更多的resource。这个大家都懂。可是懂软件的人应该都知道，一个有生命力的项目是在真正需求的土壤上生长出来的。

第二，涉及多个团队。跨越团队的合作，难。跨越太平洋的团队合作，难上加难。于是，各种开会，各种拖延。12年初还在美国开了一周的峰会，烧钱啊。为什么有的团队不太合作呢？原因有几个。一是因为“懒得变化”，这里没有批评的意思。其实每个人都不是那么喜欢变化，尤其是现状还过得去的时候；二是因为工作忙，自己的事情都忙不过来哪里会有意愿一起来推动创新，搞这种高大上的项目呢；三是因为觉得时间还早着呢。因为是“大”项目，规划的时间长达N年（大老板可以N年都拿到经费，何乐不为？）。下边有人觉得反正还早呢，于是拖延症变成恐怖的拖延症。

第三，没有一个强力的领袖。跨团队的项目，对领袖要求太高了。而悲催的情况是，N项目并没有一个官方的领袖，没有能够拍板的人。各个团队工作就靠自觉啦。我记得开始的时候，每次开会有很多人参加。后来有人找各种借口不参加了。再后来就直接消失了，连借口都不用了。很多人并不清楚自己的职责，开会没他什么事，会后也没有什么事需要他负责，这样当然大家都散漫稀松了。开始的时候，大家希望美国人B先生来领导这个项目，因为B先生已经工作了20多年，对业务非常熟悉。随着项目的推进，开发团队越来越讨厌B先生，因为B先生真的不懂软件开发，却总是对开发团队指手划脚，甚至于“指导”资深程序员做数据库设计。这几个程序员都有着10年的软件开发经验，一个外行人来指导数据库设计本质上就是侮辱。合作相当的不顺利，许多努力都无疾而终。Director意识到这个问题的时候已经过去了一年了，特意跑到中国的开发团队这里来安抚，承诺自己会亲自担任project lead。对于这样的承诺，敝人只能在心里冷笑了。Director怎么可能像项目经理一样整天盯着项目里的大事小事呢，时间精力都不允许啊。结果可想而知，Director先生只参加了第一周的周会，再也没有出现。后来他委派另一个同事Z先生来掌舵，依然无法让N项目驶上正轨。

第四，开发流程的问题。Z先生其实一直都在团队里边，而且他是清华毕业的华人，所以中国团队和他的沟通很频繁，效果也不错。但是Z先生一样犯了第一点所说的错误，N项目唯一的架构性设计是他做的。他将N项目中的数据访问层独立出来，成立B项目组。这样做分层本省没有大问题，可是小问题慢慢发展成大问题。一个是沟通的问题，B项目只有两个人做开发，一个在美国一个在中国，沟通也不太好。B项目和N项目组的沟通协调也不好，因为B项目梦想着做一个大而全的数据访问层，服务公司的多个内部项目。结果N项目需要得到B项目的支持的时候总是被各种理由推脱或拖延下来。N项目没办法，自己的特定数据总得找地方存储下来吧，于是自己建自己的数据库。Z先生对N项目组提出的问题，也没有合适的解答。对于建议也不予采纳，总是话里话外说N项目组成员太年轻，考虑的不周全。N项目成员是敏捷的粉丝，B项目走的是瀑布模型的路子。大家各自抱着自己的“哲学”不放，没办法匹配上。B项目和D项目的第一次整合，很少很少的几个API，居然花了一个多月，真让人泄气。到了13年的下半年，Z先生才同意将两个项目组合并起来一起跑Scrum。当然，这是不得已而为之啦。看看下一点你就知道了。

第五，资源的问题。N项目虽然有很大的vision, 却没有那么多的resource。开始的时候干活的只有中国的1.5个人。后来有了3.5个resource, 前台，服务层，后台数据库分工很明确，大家做的还是蛮开心的。可惜好景不长，这样的快乐时光跑了4个Sprint之后，12年年底公司因为效益问题进行大裁员，一个小同事被裁了。N项目组还需要支援其他的项目，所以resource只剩下2个了。要命的是QA也被裁掉了，本身那个QA就是像雇佣军一样的，要测试的时候才找人家老板去要的。而且QA经常换人，每次都要重新培训。开发这边要自己做更多测试，所以很不happy。裁员之后，我呼吁B项目组合并进来，进行敏捷开发，集中火力，做点实际的靠谱的事情。一个理由是：再不这样做就来不及了，如果还是瀑布模型走下去，等你做好需求分析，做好顶层设计，再来一次裁员，你就颗粒无收了。再漂亮的分析和设计，定屁用啊。可是Z先生没有采纳。一年之后的部门重组还是不可避免地将N项目彻底打垮，只留下一个人维护，其他的人都换到另外的部门了。

我不知道参与项目的同事（D, H, QA, DEV等等）以及一些关注者，除了我之外还有谁会去分析这里边的原因。也许时至今日，我的老板还是不认为项目失败吧。项目结果再差，只要有理由就好了，但求无过矣。可是千万不要以为项目的halt是因为部门重组造成的。

===========================================================================

无意吐槽，只为记录。独立博客http://brucejia.net