七宗罪
以前每次我出差的时候，很少给老板写项目汇报，我觉得这些都是浮于形式的东西。
因为这个事情也曾经被公司说过。
只是，我想，七拼八凑的给你写一堆项目进度和RISK状况等等，你看了难道会有什么质的认识？
耽误彼此时间的事情我看还是少做的好。
与其迎合老板搞这些形式主义，还不如在自己的博客上静心做个反思，是吧。
所以今天的主题是对最近半年的这个PJ来个自底向上的总结。
为什么说自底向上呢？
因为这次我不负责带队，手下也没有人，我只是一个打酱油的身份。
以酱油男的眼光去回顾整个项目的前前后后，大概能够相对客观一些。
闲话不表，步入正题。
■项目背景
客户是一家大型地方银行。
因为是首次合作，倘若项目成功，客户日后必定持续发注，钱景乐观。
而如果失败则显然一切成空。
在IT形势尚未回暖的前提下，更加凸显了公司对于客户这种『有钱就是爷，有奶就是娘』的依赖。
换句话说，这是一个只许成功不许失败的项目。
或许是由于这种巨大的压力令后来决策层的风格日趋保守（激进意味着犯错概率增加），
导致了很多负效应。
项目核心为银行结算系统。
该系统客户定制成分很浓，业务独特，所以需要客户确认的东西非常多。
概要设计，基本设计，这些都要跟客户来回切磋。
因为这种背景，该系统并没有一个成熟的模型，
另外客户并不是系统架构师，常有犯错和误解的时候，
所以在开发过程中来回修改基本设计也是可以预见的事情。
（螺旋式前进，当然这些都是客观条件没有办法）
■团队状况
外包公司大抵都类似，每年都有一两个特别大的PJ，
而且这一年公司80%的收益主要靠这一两个项目。
加上如我前述这个项目的特殊性，因此据说部里是很重视，
挑选了许多精兵良将（据说相关领域作业经验丰富）。
清溪4月份恰逢前任项目结束未及休假，而他们正缺一个能打酱油的，
来公司一年左右，很多人我还尚未有过合作的经验，出于此目的，我便欣然受领。
最后主体团队成员状况大概如下：
按业务模块分了3个小组。A（4人），B（3人），C（5人）。
据我统计，平均年龄，30+； 平均月薪，8k+。
※此时回想，这么多大爷过来当小弟，项目失败似乎是意料中的事情。此为第一宗罪也。
我这个酱油男落在C组里，有时也兼职全项目的一些服务器脚本和数据库管理。
业务上，日方总部有一名经验者常驻银行客户现场，负责同客户一起制定确认式样，且称作M君。
另外大连这边有两名日本人常驻（且称作F君和Y君），本意是让这两人同M君配合，
把握式样的变更和指导大连团队的设计。
※事后证明这个体制并不好。因为这两人也不是太懂业务（理解不够深刻），
另外两个日本人第一次来这里长期出差，生活不能适应，工作也应该不会太上心。
况且隔着这么远，很多业务上的东西没在现场的确拿捏不准，
导致后来大连的团队要确认一些式样的时候，绕过这二人和M君直接联系。
A，B，C 3个Team，有时候M君一天要处理几十封的QA邮件，不疯也应该快疯了。
本来就是一个不成熟的业务系统模型，更加需要保证式样确认的及时性。
而F，Y二人不能发挥出其应有的作用，大连开发团队的业务指导基本上成了M君一人的工作。
沟通的成本增加，作业效率降低。
同时项目有随时中断的风险（只有M君一人能算的上是懂式样的，一旦M君倒下咋办？），此第二宗罪也。
同时，F，Y二君失去了代理职能，3个小组独立和M君沟通，
造成本来需要全局变更的式样（比如数据库某字段设计）常常不能全体及时修改。
前期打基础的时候缺乏协调全局的角色，造成后期模块对接时产生混乱，此第三宗罪也。
在管理上，大连3个PL，对本地PM负责，PM和F,Y而君一同对日方PM负责。
■项目过程回顾
2月和3月。大连方面派出5人左右（主要是PM和PL），同M君一同做基本设计（主要基于M君和客户的共识）。
所谓基本设计，就是各主体的机能模块已经有了划分，包括input和output，系统调度顺序，数据flow等等，
至于内部细节如何实现，只需简要考虑可行与否，具体留待详细设计作业。
这段时间清溪还在别的项目里，所以具体情况不详。
4月。人员全部返回大连，详细设计开始。同时一些之前残留的基本设计也在同步进行。
按照最初计划：详细设计周期为4月和5月上旬。编码制造从5月中旬到6月初。
单体测试和结合测试时间为6月份。
7月，8月到现场用客户真实数据进行综合测试。
9月正式上线。
看上去一切都很美，井井有条的感觉，但是。
详细设计一入手，发现按照基本设计所定义出来的系统来看，作业量不是一个月可以完成的。（仅我在的C组就有大约140本设计）
另外，这个时候发现基本设计的某些部分不合理，基本设计有一些也需要同步改动。
为了给新客户留下合作愉快的经验，总部下令必须恪守开发周期，没有商量余地。
那就得增加人手了。不知道是因为大家都忙（有这么夸张吗？）还是为什么，
公司决定去找外面协力来帮忙。
其中有一场面试是我参与的，主要考察脚本的编写能力。
当时有一哥们，什么问题都是跟我含糊一通，然后给我一句“这个功能用自带的函数就能解决”。
我有一下没忍住就问他用什么函数，
他想了想，说用的时候查查就知道了。
我看大家都是出来混的，就没太苛刻。（况且在大连想找到什么好的协力公司也是扯淡，我以为）
加上协力，加上内部调过来的人员。到4月中旬，项目组已经扩展到近20人。
以后来的实践来看，这批协力做事责任心不够，虽不能说没帮上忙，但是太有限，
做出来的东西很多不合格，反复review，反复修改，非常浪费时间。
再一个，做单体测试的时候，用的数据太随意，有点糊弄的感觉（临界值和一些特殊状况压根不考虑）。
尽管人手看起来很多，有用功却不随之正比，4月和5月项目成员几乎每天朝九晚九。
人力成本投下去，却没能够收到正面效果。
好的管理是人越多出力越多，而我们这次是人越多混乱越多。此第四宗罪也。
再说说6月份的事情。
因为人海战术的应用，总算，6月初制造完毕，开始进行测试了。
也许是疲劳了两个月的关系，项目成员心态明显不同了。
相当多的人持有一观念：6月份的测试工作不重要，糊弄糊弄就可以过去，
等7月8月去日方现场测试部署的那帮人发现问题再说再改。
这本质上是把问题推后，掩埋，越到后面肯定是越危险。
以我最近在现场的经验来看，A组的东西像几乎没有经过测试的。（一个SQL文件跑起来，还会提示某字段不存在，我不知道这些人在做什么？）
缺乏有效的品质管理机制（我不赞成组内测试，应该有个专门严格测试的小组才好，但是这次项目资源是个问题），
就像A组这样很多东西未经测试混水摸鱼，给后期工作造成了巨大壁垒。此第五宗罪也。
进入7月份，问题全部暴露出来了。
导入客户的数据，有些模块压根没法运行。
详细设计描述的结构和客户实际提供的不符，为什么导致这样？
因为做好的详细设计都是交给M君review的（F君Y君无法看出逻辑问题），纵然是神仙，一人也看不过来这么多，这么细。
疏漏不可避免，有些东西几乎是到了综合测试的现场敲掉完全重做的。
一再跳票。客户很惊讶。客户很生气。
生气的原因大概除了这个前期的品质太差令后期测试计划无法按时进行之外，
恐怕还有部分原因是出差人员某些行为细节的欠考虑。
客户是完全不懂中文的，但是和我们坐在一起工作。
某些人上班时间大声嬉闹，甚至发出爆笑。
客户听不懂中文，看你说话这么大声，表情这么夸张，他会怎么想？是不是会有种负面的情绪产生？
做事成败与否另说，做事的态度是你给局外人的第一印象。
项目如果做好了，可能客户也就忍一忍认为是文化差异，
可是你项目做砸了，人肯定就以此认定是你的工作态度有问题了。
现场工作，尤其是在这种濒临失败的项目现场工作，依旧说说笑笑，毫无自省之意，此第六宗罪也。
■感想
在现场常发现模块间的接口不对的问题。
双方总有一方要改，我认为这个时候应该是大局出发，两组协商，怎么最简单最快就怎么改。
但是现实却是小组之间推诿，你要我改我说那是你的问题我坚决不改。
没有一个全局观念，各leader都只想推卸责任。
按理说这些问题都应该在4月5月的设计阶段就调整好，那时候都干嘛去了？
小组之间几乎没有沟通。大部分人只知道做设计做代码，而不知道最后的目标是为了造出一个高效连贯的业务系统。
你做的东西尽管很多，可最后都接不起来，那不就是垃圾一堆吗？
PM这一点做的是不够好。起码在测试的时候，要先想办法造出一个模拟数据，来个疏通测试啊。
我还看到很多代码里加了注释，写着“此处要确认”的字样。
都啥时候了，还找谁确认去啊？
状况很恶劣，所以大家情绪都比较消极。缺乏一个正常的发泄渠道。
『带没带过项目啊』
『行不行啊，都啥时候了，还能有这种错误』
『你让他一个人整吧，出问题全是他的责任，跟你一点关系没有就行了』
『饼子，棒槌』
『反正我到点就走，就这么耗呗』
往往都是这种话语充斥着耳朵，这只会令你更加悲观，
所谓“与其诅咒周围的黑暗，不如点亮一支蜡烛”
项目的复杂度，管理的疏忽，各种条件决定了今天的这种状况，这已经成为了客观存在，
现在不是追究责任的时候，齐心协力把问题都克服掉才是首要任务不是吗？
还有一个很严重的问题。
可能上面是觉得到了最后阶段无所谓了，源代码居然都不采用版本管理，权限管理。
成员可直接修改共享目录下的源代码。。。
项目濒临失败，部里也非常着急，空降了很多高层过来督战。
问题是，这些人来了实际意义不大啊。
事实上，管理层来这么多人，下面干活的人往往会有怨言的。
最近在现场我看了很多详细设计书，找到好几个纰漏。
这些有纰漏的设计书大部分是男性写的。这难怪，写设计书需要心细一点，女性更适合这个工作。
即使你有review体制，也是不可能做到太高效的纠正。
最好的方法是用工具去生成文档，其次是分配给适合的人去做。最低下的方法是按成员人数平均分配。
当时做设计书的时候就完全可以分工灵活些，多让女性成员担当主体。
有极客精神的人多让他去负责稍复杂的模块的开发，不用你催他自己都会很用心去攻关。
而按部就班的保守派就适合让他去搞测试。
如何合理分配人员资源，这也是各leader应该考虑的问题。
你让善于游泳的人去爬树，特长没有办法释放出来啊。
而很多管理人员理解的项目管理似乎就是“分活，催活，加班”。
说了这么多。感觉自己其实挺二的。
谁会care这些事情呢？也许像我这样的loser才会关注这些罢。
别人不是照样混的很好吗？深得器重，公司有什么好处都少不了那几个人。
而每次失败的项目也少不了那几个人。
所谓的“精兵良将”，也不乏大部分骗吃骗喝的人（也许是术业有专攻罢）。
我们公司的PM没有实权的，仅仅是一个项目管理职能，
这是好事，也是坏事。在这次项目来看，就是一件坏事。
没有问责体制，成员眼里就没有权威。
项目做砸了又怎样？你又不能降我薪，不能革我职。
绩效评价给评低一些？我跟老板走的近一点，我就肆无忌惮了。
这些天有时候晚上加班后回家打开电脑收公司邮件，发现大连办公室发来的尽是一些嬉闹聊笑的群发邮件。
这个风气，这个组织的文化，可想而知了。
虽说人各有志，但是做事的态度这一点，这个团队里很多人是不合格的。
人说普遍情况下，工作五年后人的轨迹基本就定型，
对于这个平均age 30+的团队，是不能指望有什么大的变化了。
这不是一个技术团队。
可能是到了这个年龄的关系，很多人要给自己找到一把PM，PL的交椅。
所以学PMP的人很多，通过考试的人也很多，但是懂得管理的人很少（我并没有说我很懂管理的意思）。
我有时候问同事关于项目的想法，他们会说，管它那么多呢，反正最后责任又不要你担。
是，当然不用我担，我只是一个打酱油的。最多部长再去给客户下跪请罪罢了（也不是没跪过）。
但是团队是我们的，没有人去反思这个事情，大部分人总是一个观念：
认为今天弄成这个局面，主要就是前期总部和客户沟通不够的问题，
导致式样频繁变更，rework太多，管理层不会带项目的问题。。。
都是这副事不关己的心态，做事能做好吗？
这几年，KO，KTS，DE等等几个大项目，没有不失败的。
我承认《没有银弹》说的很有道理，软件系统的复杂性，很多时候你无可奈何。
但是。咱能不能先探讨完主观因素再去说客观因素。
这个样子，下次再来一项目，十之八九，我看还是要重蹈覆辙的。
不反思不总结不进步。此为第七宗罪也。
另，这次项目搞得#twituji 推土机没法持续开发，很苦闷。当然，这是外话，暂且不表。
祝各位朋友顺利开心。
（完）
拍砖