我怎么做这个项目？——对《为什么我们程序员总是这么累、做出来的东西这么差？ 》一文的回复

我在《为什么我们程序员总是这么累、做出来的东西这么差？》列举了个小小案例，并结尾留了个尾巴，这里做答。

其实上述这个小案例是我看到的一些真实项目的综合，跟真实情况基本吻合。现在来依我的看法来说说这个案例。这个项目中显而易见的问题有：项目前期没有开发人员参与；项目的启动比较随意，没有比较正式的kick-off；项目负责人缺乏项目管理能力；项目范围太不明确；没有与干系人的充分沟通；计划太差；没有项目工作跟踪和监控；等。

这个案例看上去是个小case，所以我们就不把PMI的九大块全给扯进来了。

简单说，如果我来做这个项目的话，我要重点做下面这几件事：

1．  找出项目主要干系人，充分沟通

这个项目干系人应该不会很复杂。我最关注的是这个项目产品的发起人如合同甲方、最终用户和项目组成员。沟通的目的很简单，就是掌握项目涉及到的所有人以及这些人的想法，如合同甲方和最终用户的真正想要的东西（据我经验，它往往与售前或市场人员告诉我的不同）；项目组成员每个人的现状。对整个项目的各方面情况心里有底（说得多通俗，呵呵）。

2．  风险识别和应对

关于风险对于这个项目无法具体说。但是我觉得风险是任何大小项目都应该考虑的问题。有人会说我从没做过风险管理，其实很多人虽然不是有意识的做风险管理但事实上是做了（从无意识的做转变到有意识的去做很重要哦），比如会说：老板，那小王这几个月会不会走啊？如果走了怎么办？

项目管理者应该根据自己的经历和经验多想些可能导致项目失败的风险，并将这些跟老板沟通，得到老板协助和解决。尽可能的把一些潜在的障碍扫除，或者如果不能避免也要先跟老板打个招呼，找个应对办法。另外风险管理是在项目进行过程中持续进行的，项目负责人应时刻观察、感觉看有什么不对劲的、可能对项目不利的因素出现。

这一点很重要，不能到出了问题才跟老板说“我以为是这样的”、“我没想到会那样”，老板不爱听这些。

3．  明确项目的目标，确定了范围再动手

这个项目里，我和我的成员要做哪些？哪些是不要做的？必须先想想好，而不是蒙头就上。很多不够成熟的项目负责人常犯这样的毛病：跟他说了一个项目的情况后，他脑子里马上浮现出的是拖控件、写代码。这样会因为考虑不全而导致项目进度估计过于乐观，到最后该做的事情都出来了才慌神了，结果这个也来不及那个也来不及，就草草应付了事。

范围确定应该避免讨论需求细节；范围确定应该从项目管理者的层次考虑。常见的问题是只考虑几个功能模块和程序源代码，甚至连测试也忘了。

我的建议是参照其他成熟项目的WBS，这样可以帮你想起很多。如果没有那么就只能自己想了，可以按照如下思路（基本是做WBS的思路）：

（1）       这个项目我大致要分几个阶段？所有学过跟软件沾边的东西的人都能说出点来（什么需求、设计、编码、测试、安装什么的）。

（2）       每个阶段我都要完成什么东西？开始阶段要逐步建立需求模型、做技术原型、与客户做沟通吧？接着的阶段要整出系统架构、系统某些问题的实现机制、开发标准、准备开发设备和环境吧？编码就不说了，大家都不会忘。接着我要测试吧？然后要修Defect、回归测试；在然后要给用户装了试用，那么部署文件是否要做安装包？是否要用户手册、用户培训？

（3）       再看看上面写出来要做的这些东西是不是要分成更细的东西来做。比如需求模型可能包括用例描述、非功能性需求、数据需求几个方面；实现机制可能包括如对象持久化机制、Exception处理机制、数据缓存机制等；测试可能包括给测试人员培训、设计测试案例、执行测试等。

（4）       看看上面分好的这些个工作，你能否比较有把握的估计完成他们的时间。如果没把握再拆，“拆到不能再拆为止”，呵呵。

（5）       把你认为你已经想周全的这个项目范围给项目组所有人看、给头看、给其他项目经理看，看是否有漏掉的。有的话补上。

（6）       最后这份东西才是你和你的项目组要做的事情。什么？还有漏掉的怎么办？那就没办法了，只能当作教训，在下次补上。

其实范围和组织的开发过程也有很大关系的，如果有个明确的开发过程（如RUP）就会少忘记很多东西。

4．  确定项目里程碑及项目完工时间；

里程碑把项目总目标分成阶段性目标来完成；里程碑是项目的时间基线。一般可以根据开发过程的模型来制定里程碑，如RUP一般有4个主要里程碑（初始阶段完成、精华阶段完成、构建阶段完成、交付阶段完成）。简单说就是根据我们上面盘算好的要做的事情，我们来分阶段实现，每个阶段、每个阶段我要完成那些东西、哪些事情。

5．  项目进行过程要经常性的跟客户沟通，show我们的工作成果

这一点很重要很关键。这样作有很多好处：让客户知道你确实在做事；频繁的让他看你的工作成果，一旦你有偏差马上就会被发现；可以增进相互了解，搞好客户关系，呵呵。这中间有个需要注意的地方，我们跟客户的沟通要可行、有效。老大们，这一点非常重要！！我经常看到的是写个几十页甚至上百页的“需求文档”扔给客户，然后说“你给我3天之内确认签字”。谁tm会愿意看那么几十页的文字，还夹带着很多专业术语、除了作者谁也看不明白的图啊什么的？还有，根据经验，能像样的写份需求文档的真的人真的不多。很多时候是头儿吩咐两个开发人员拼命写出来的。什么意思？那些需求的语言既象小说又像散文，真的是各有千秋。我不是在怪开发人员，而是怪很多老板、开发经理就没有意识到加强加强对开发人员这方面的培训。象这样的行为就是“没有可行性”。脾气好的用户可能不说什么，“嗯哼”过去了，但是不会签字。脾气不好的直接说“你写这个我看不懂，你做完了给我看，哪里不行你们再改”！

那怎么办？这样的沟通是一定需要的，如果不做就是很起眼的陷阱。我有几个建议：

（1）             附带界面原型，客户都喜欢看实在的东西，看到界面原型他往往问题全出来了；

（2）             为了增加可读性，将整篇的文档拆开来成小篇小篇的，你陪着他一篇一篇的给他解释过去；

（3）             为了增加可读性，注意排版、风格等一致、人性化；文档中应该多图。

需要强调的是，界面原型不能代替需求。

 

6．  确定各个交付物大致完成时间；

分得越细越好，工作包越小可控性越高。这样看着一个一个的工作包完成，心里会一步一步的踏实，就好象看着一块块砖垒到墙上去了一样。如果出现问题也是小范围的，可是及时发现，并且更正成本不会很高。在估计时间的时候应该注意留有余地，适当考虑可能存在的返工时间。

7．  项目组定期开会；

开会的功能和效用有很多。会议也分很多种，项目组会议应轻便、简单为主。通过会议你可以了解项目组绩效、运行状况，通过项目组会议还可以加强沟通、减少问题，如果你的技巧够好，还可以通过每次会议加强团队建设、增加凝聚力等等。

有时候，你会发现不开会没有问题，一开会就发现很多问题。不要把所有人都看着是自觉性、主动性很高的任务承担者，即使是责任心很强的人也有懈怠的时候。

8．  检查每项工作的完成进度、完成成果，确认其确实按标准完成；

每项工作都必须要被跟踪。这项工作是否正在被做、做的进展如何。在你的项目组成员告诉你他已经完成的时候，你必须去检查，是否完成。我经常碰到这样的情况，他跑过来告诉你：我做好了。你过去看的时候他会说：“哦，这个还差一点”、“我只要改改这个就可以了”、“那个暂时不行，但是改起来很快”云云。就在前两天我还碰到这样的事情，一个新同事跑过来跟我说一个模块做好了，我过去看看演示，结果他说：这个部分是××做的，还没有链进来。那我就说，那你链好了我再看，结果过了好大会儿，他过来跟我说：“那块发现了个大问题，可能还要两天”。Ft！

听Bleum的老板Eric说，如果一个印度的软件工程师跟他说工作ok了，那么他会相信也不会去检查，但是如果一个中国软件工程师说工作ok了则他一定会去确认一下。

9．  做好沟通枢纽。

项目经理应该是项目团队的沟通枢纽，所有项目组的信息汇聚到项目经理这里，然后再由项目经理分发到各个相关的人那里去。如果这个枢纽功能发挥不好，这个项目怎么也难做好。要不怎么说项目经理会有90％的时间都花在沟通上呢？

项目经理要应付的方方面面很多：客户、项目组成员、技术支持、市场部、公司其他相关部门、公司高级管理层、职能经理等等，如果细化开来你会发现至少由20种之多潜在的沟通渠道。能做好很不容易哦，呵呵。

10．              做好阶段总结和最后的项目总结。

坦白说，很多项目组做的差不多了的时候忙不迭闪人、脱手、飞身，为什么？很多项目的尾巴都不干净，谁还有心思做什么回顾和总结啊？但是，这是很重要很重要的一环节。没有这个环节我们吃的亏白吃了，公司的开发水平永远是这个样子，得不到积累、得不到提高。对项目组个人也是一样，犯过的错误全忘了，吃过的苦头下次照样会吃。

 

以上基本是根据一些问题泛泛而谈，稍许提了些自己的体会和做法。权当同病相怜的人来击掌对歌时嚼舌～