<<醒了自悟>>系列--蝶恋花-项目小结
注：这是作者在一个项目结束后，作的一个小结，作者是这个项目的架构师兼程序员。
蝶恋花
梦入江南烟水路，行尽江南，不与离人遇。
睡里消魂无说处。觉来惆怅消魂误。
欲尽此情书尺素。浮雁沉鱼，终了无凭据。
却倚缓弦歌别绪，断肠移破秦筝柱。
在公司两年，有些人是一个两年，有些人是两个一年，我不知道如何评价自己。
我进Echo 项目（化名） 不知道多少个月了（不是我不会数数，而是由于并非旦旦夕夕的做这个项目，所以到后来，自己也说不清楚了，如果你强要说，“这就是爱，说也说不清楚”，我也没有办法。）那就姑且算12个月吧（算1个12月还是算12个1月？：））。
项目开发过程中会形成一些优势、文化，当然也会产生一些问题。
以下是这个项目的一些优势：
1． 至少能做出来。
2． 至少能让用户越来越满意。
3． 看上去很美。
4． 让我觉得自己的潜力是无法估计的。
拿我做的XX管理和XXX这两个模块来说吧，刚开始的时候需求简直不知所谓何事,后来才慢慢开始适应，我一般要花1周时间，不写任何代码，就是看一个模块的式样书，看不懂就问，后来就一马平川了。在潜移默化的过程中，任务完成了！在开发过程中，我觉得技术是次要的东西，摆在软件开发过程中的两座大山，根本性问题、次要问题。根本性问题，就是如何解决业务问题，次要问题是技术问题。现在微软帮大家解决的就是次要问题，使我们把力量集中在解决根本性问题上。关注业务，很重要。
其他不大清楚了，其实编程不是我的爱好（最爱），可能是理工科出身的关系吧，文人向武，武人向文吧，我比较爱好文学（这样说，不会有人打我吧！：））。
你上次听你的组长队你的组员说“我对你很失望，你只做完了份内的工作，并没有追求进步”是多久以前的事。
我觉得写项目总结之类的文章，好像就是说要等一个项目做完之后，才把问题抛出来（马后炮），我看晚矣，就好像一朵花，说它放在天平上称量，有青菜萝卜的斤两。
所以我把以前的一些文字的整了整如下。
以下是我认为一些需要改正的地方：
下降一个等级！
如果你是一个Developer，或则更高级的。
请记住，你最值得做的项目是在开发时能让你的开发水平下降整整一个等级的项目。
或许这样做，你才不会亏本。
你亏本了吗？如果你亏了，很好，Keep it on！
一个项目到底有多好的先决条件！
这个故事在很多方面和不同层次都是非常深刻和富有教育意义的。让我们将它仅仅作为纯粹的工程项目，来看看有什么值得学习的教训。一个项目到底有多好的先决条件？他们是否有： 1. 清晰的目标？是的，尽管幼稚得近乎不可能。而且，项目早在遇到这个基本的限制之前，就已经失败了。 2. 人力？非常充足。 3. 材料？在美索不达米亚有着丰富的泥土和柏油沥青。 4. 足够的时间？没有任何时间限制的迹象。 5. 足够的技术？是的，金字塔、锥形的结构本身就是稳定的，可以很好分散压力负载。对砖石建筑技术，人们有过深刻的研究。同样，项目远在达到技术限制之间，就已经失败了。 那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。
马后炮
“疯狗，我决定下一季要你坐冷板凳。”
“什么？我不懂，我觉得我踢得很好呢。”
“是踢得不错，但是每次球要传给你时，你接球的反应都不够快。”
“我是这样吗？”
“没错。而且你因此而漏接到不少机会球，在你改进这一点之前，我必须罚你不准上场，当然，这也就是说，你的薪水将从520 万美元掉到不足2万美元。不过别担心，你还享有各种福利，赛季中有免费的饮料和热狗，买纪念品时还可以打折。”
疯狗这时候可真是疯了，向他的教练咆哮道：“既然你看见了我接球不够敏捷，你为什么不早点告诉我？我可以改的啊！”
“喂，我现在就在告诉你啊，而且赛季的检讨报告就在这里，写得不够清楚吗？拿去，这是你的新合约。”
一个稳定状态的项目就是死胡同！
写下一个预言，项目总结的时候可以参考：
我们在评估一个人在一个项目中的价值时，所用的方法经常是基于他们的稳定特征：他们能写多少行代码或他们能写多少文档。我们很少注意他们每个人如何适合一个整体，也就是说对大多数人来说“团队”这个概念是可笑的，于是人们进进出出。
以下是一个掌故：
几年前我在进行一门课程的内训时，有一个高级经理强留我谈话，要求我评估一下课上一些人（他的项目组的成员）。他对一位女士感到特别好奇。很显然，我们对她的成绩表示怀疑：“我看不出她为项目做了些什么-她既不是一个得力的开发人员，或测试人员，也不是有任何其他特长的人”。通过一些调查之后，我发现了这个令人迷惑的事实：在她就职这家公司的12年间，这个令人怀疑的女人从事过的项目都取得了巨大的成功。她为项目做了什么是不明显的，但是有她在，项目总是成功的。通过在班上对她进行为期一周的观察以及通过和她同事的谈话，我得出的结论是：她是一个级品催化剂。有她在，队员们自然会团结得更好，她协助人与人之间的交流并使大家融洽相处，当她是项目组的成员时，整个项目变得更加有趣。当我试图要向那个经理解释这个想法时，我感到非常震惊。他恰恰就不承认催化剂作用对一个项目来说是重要的。
--------TDM
催化剂是重要的，因为项目总是处于一种变化的状态之中。能够帮助一个项目凝聚起来的人比得上两个只做工作的人。
实际的软件开发过程
• 早上该9点上班但9点半才到(跟老板讲原因是路上塞车厉害)
• 到办公室后先和几个同事聊聊天，谈昨晚电视转播的比赛…
• 打开电脑后，看到有两个必须要修复的Bugs。哼，等下再说吧…
• 先看看朋友的邮件，再将几个笑话转给朋友…
• 再跟女朋友发几个短信… 对了，还得给我那两哥们儿发个明天下班后去逛电子商场的约会。
• 赶快看看新浪网上有啥新鲜的…女朋友来电话，不得不接。
• 阿呀，忘了去倒杯咖啡喝… 隔壁同事讲淘宝网上有卖我想要了很久的数码相机，赶快去看看… 咦！真快，午饭时间已到了！
• 吃完饭，打开我那两个bug看看… 有点晕，先去拿瓶可乐醒醒脑…
• 再玩几分钟扫雷的游戏… 再看看bug，还不知道该怎样修复。算了，随便试试再说,行了。该提交代码了，Check-in…
• 电话铃响，老板在骂：“你的什么垃圾代码，将今天整个团队的Build 全都 Break了！” 唉，这该死的Job! 撤销 Check-in…
• 谢天谢地，6点到了。看看外面，路上好挤，早点回家吧…
Nothing will happen
He'll sit here and he'll say,
"Do this! Do that!"
And nothing will happen.
Because he has no right!
交流
“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。[以及电子邮件。]
一年目睹Echo之怪现状（删节版）
领导见我无事，请求我写点文字，写点我进入这个项目以来发现的问题。
代码上的问题我就不说了，讲了也没用。我未著文章久已,但是你要知道拒绝领导这种旦旦夕夕的请求是不好的，不，简直是不可能，我只要重做冯妇。
但是事实也不尽如此，自己也蛮想的，真的。一年多来，我也一直在寻找答案，可是也说不出个所以然。不知道Echo算不算成功，在我眼里，有些人死了而这个项目还活着，有些人活着而这个项目已经死了。直到有一天晚上，我发现了KISS这个英文单词，“Keep in stupid and silent”，这个词语再也贴切不过了。
……
无论何时你试图去鼓动一次变化，你可能得到各种不同的反应。
1． 盲目的忠诚（不问问题，就是KISS）
2． 信任者同时又是质疑者
a. 怀疑（“给我看看”）
b. 被动的观察者（“对我而言它意味着什么”）
c. 反对（害怕改变）
d. 反对（害怕失去权力）
3． 以武力反对（暗中破坏和损毁）
看看这个连续的统一体，问你自己，哪些人是我潜在的敌人，哪些人可能是我的支持者呢？你可能得出结论：盲目的忠诚者是好人，其他所有人则是爱发牢骚的人；盲目的忠诚者是盟友，而其他群体都是敌人。这个观点是完全错误的，例如我们需要认识到盲目的忠诚者造成的危害性。他们可能相当没有权力，而且他们跳到看起来很热门的东西上去，他们追随时髦。
Jerry Johnson断言：作为信任者又是质询者的人们是任何一种改变的唯一有意义的潜在的盟友，走向极端的两种人士真正的敌人。
如果根本不能改变的话，永远不会有改进。
胶冻团动的重要标志，在项目过程中在任务确定好了的过程中人员的低流动率。
雄心壮志
两年前，潼门大行村，皇宫大酒楼门前的大排档，开张大吉，我和兄弟们雄心壮志，谁知开张还不到半个月，平均每天被人扫荡1.3次，一年内死了6个兄弟（离职6人）。算命的说我是一将功成万骨枯，我不信，我觉得我们出来混的是生是死要由自己决定，你们跟着我的日子最短，底子最干净，路怎么走，由你们自己选择。
......
祝你们在EchoII EchoIII EchoIIII...一帆风顺，干杯各位长官。
参考书目《The Mythical Man-Month》、《Peopleware》、《微软研发致胜策略》、《无间道》、《围城》
