项目经理的工具箱---走出软件作坊：三五个人十来条枪 如何成为开发正规军（三）

   自从写了关于《三五个人十来条枪 如何走出软件作坊成为开发正规军》走出软件作坊：三五个人十来条枪 如何成为开发正规军（二），系列文章后，收到了很多网友的评论，也收到了很多网友的疑问请教。而大部分人都已经当上了项目经理，手下有个2-3个人或5-6个人。少部分人还在上学或者才毕业出来1-2年，询问的还是学什么语言和什么才是核心技术的之类问题。

    从接到的请教来看，许多中国国内软件公司都是以项目为主，有单做单，没单就干靠，靠的时间长了老板心毛了就裁人，来活了就招人，就这样反反复复。所以，大量的公司没有开发部（因为除了销售，开发部从开发到实施到支持都全做），当然也没有开发部经理，只有项目经理。更不用提技术总监和CTO。即使有个技术总监的头衔，也是为了给客户的名片，而手下也就5-6个人，项目一来，技术总监也需要编码和实施，其实就是一个项目经理。

在国内，项目经理这个词如此常见。均为实施项目经理和开发项目经理混为一身，统称项目经理。虽然，开发和实施是软件产品的不同阶段，不同阶段关注的重点也有不同。但既然都为项目经理，那么其关注点也有共性之处。

    项目经理，主要职责是：

    项目范围定义

    项目计划制定、分解、分配、协调、汇报

    项目质量控制

    项目需求变更控制

    国内项目经理一般没有人事权和财务费用权。老板给分配什么人就带什么人，自己只是一个最能干的工人加工头而已，当然更没有财务费用权，要想请客户吃顿饭，当然需要和老板打报告（自己团队想休息娱乐会，只能联机打把游戏，想团队吃顿饭，不可能给费用的）。

    不过，从现状来看，国内现在的项目经理，连项目范围和项目需求都无法控制。老板说什么就是什么，客户说什么就是什么，用户说什么就是什么，只要自己和自己的团队能做，并且不累死或者不跑路，能做的都照单全收。当然，做什么，什么时候做完，都不属于自己管理和控制，当然，项目计划的制定由项目经理制定，就是虚设了。唯一剩下的，就是项目质量控制：开发有代码的质量，实施有实施的质量。

    接到网友很多询问，都问我工具的使用情况（对组织结构和流程问的极少，可能觉得都自己改变不了，根本没有机会实现，道理能不能行的通也就不用去想了，因为想了也白想）。问我现在的团队使用什么UML工具、什么压力测试工具、什么数据库设计工具、什么版本管理工具、什么需求管理工具、什么进度管理工具、什么BUG管理工具。

    在他们眼里可能觉得，一个团队，只要用上先进的工具就会成为一支装备了机关枪的军队。就跟我们的客户一个想法，只要上了这套ERP软件，我们的管理就上了一个台阶，我们的盈利就会提升。这个想法，真是奇怪，就如同一个人拿了一把屠龙刀，人没砍到，倒是把自己砍伤了。一把好厨子的刀，到了不会做菜的人的手里，仍然做不出好菜，就这么浅显的道理，但大家还在幻想。

    许多人想得到答案，觉得一个正规的开发团队应该使用是Rose、Together、LoadRunner、PowerDesigner、VSS、CVS、SVN、ClearRequest等等。

    但其实，我们也并没有使用这些工具。

    我一直在商业软件公司工作，也深深的明白自己的责任就是帮助公司最大限度的利润最大化。而利润最大化的实现手段就是最小的成本、最少的人、最少的时间、最简单的方法达到老板的目的，拿出合适质量和功能的产品，包装好，卖上尽可能高的价格。只要能赚到老板想赚到的钱，达到老板的目的，只要不影响这个目标，不影响大目标，小磕磕碰碰自然难免，有问题解决问题，没问题继续前进。哪个企业没个矛盾没个利益集团，哪个企业没个问题没个埋怨，有人爱自然有人恨。就是这样，这样是常态，不是异常。所以，我使用工具，一般都是在各种手段我都使用的差不多的情况下自然使用的，而非为了正规而正规，而是为了解决问题，而且是很有效的解决问题，而且是最简单的解决方法。我从来不为面子工程付出成本。

    我们最先遇到的问题当然也是软件质量的问题。软件的质量问题，引起了实施培训、实施推动上线的困难、客户使用效果的困难、支持费用的增高、支持难度的加大。最后实施部不愿意实施、销售部不愿意销售、支持部直接把电话转开发部。所有人对把自己工作的不顺利和不顺心归罪到开发部。当然，这样的开发部，不被老板开掉才怪。

    于是我空降入主了。

    我采取的第一个策略就是：专门划出一个辅助开发人员（因为他对客户需求也不了解，讲了3遍也不懂，写的代码也考虑不周全，所以代码漏洞百出。不过这个小伙耐心还不错，就是有些懒。看来懒人一般都耐心不错。不过还是有些得过且过，做一天和尚撞一天钟。就这么个才。），让他做技术支持兼测试。

    过去是实施部有不少人，每个人都直接打开发员的电话。支持部也是。客户也是。老板呢，不懂软件也不深入操作研究软件，却从使用者角度老提意见，看到哪里想到哪里就直接给开发员打电话让开发员修改，从最皮毛的字的字号到最深入的商业智能问题，都提，而且让立即改掉，其他所有人包括客户提的都靠后。这样，一个开发被干扰的无法工作，最后离职。

    我划出开发部专人支持后，规定流程。所有的需求，不管是哪个部门或哪个客户，都归口到他这个人手上。即使还有人直接打给开发员，包括老板打给开发员的，开发员必须把需求或问题再并口到这个技术支持手里，我来统一安排调度开发。

    开发人员是消停了，可以安心按我的安排的进度和优先级修改了。而支持小伙子呢，电话开始被打爆。幸好我给小伙子的指示是，都先接上记录好，能不能解决，能不能快速解决，看自己能力，不着急，谁跟你急，你跟我说。于是，小伙子被吃了一颗定心丸。

    小伙子一开始使用的是一个EXCEL。别人提的问题都自己记录在里面。但是弄到最后，我的手里、小伙子手里、开发人员手里、支持人员手里，都出现了不同版本的EXCEL。互相都说这个已经修改了，那个说没有修改。这个说有多少BUG，那个说不可能。

    于是，我上了第一个工具，BUG管理系统。不管是BUG还是需求还是建议还是疑问，谁想提，都提到这里来，随时记录。不管你是出差还是在支持部坐班，都记录到这里来。凡不记录者，一律不解决。

    于是，天下太平。经过技术支持和开发人员努力，一个大风浪过去。利益冲突处于一个平衡或者可能随时崩塌引来下一次冲突。

    我于是给支持小伙子分配了另一项重要工作。测试。为了不让你以后继续享受折磨，那么你必须卡好关。你自己卡不好，那么以后的技术支持仍然很痛苦。小伙子为了自己以后能过上幸福的上班生活，于是测试做的不错。所有测试出来的BUG也记入到BUG管理系统。 现在，开发人员工作量和工作质量有了量化，支持人员的工作量和工作质量也有了量化，给我安排计划和考核人员和申请资源做了大量的支持工作。

    所以，一个BUG管理工具，能把计划、进度、质量、需求、BUG都能管理起来，而且能追溯，能考核，能统计工作量和工作质量。真是必备。

    但是，接下来发现了一个问题。就是在修改的时候，老误会客户的需求。程序员一天在家里面开发，不了解外面的客户和在第一线战斗的实施人员到底想表达什么。于是修改完，程序员觉得自己费了很大的劲，而实施人员和客户却非常恼火，一点不领情还发怒。最后，搞的开发人员和实施人员冲突不断。

    需求如何描述清楚，成了必须提上日程的事情。许多没有经验的项目经理尤其会在这一步犯晕。UML工具、数据库设计工具，需求管理工具，能上的都上，最后也没解决问题，把自己和自己的团队累的半死。

    我使用了PPT+WORD+脑图+EXCEL的描述方法。

    因为很多需求都是这个支那个叉出来的。程序员往往想的了这头想不了那头。这就是人的思考的周密性差异。

    想让人能从千万丝绦中理出头绪，于是脑图软件上场。把各个分支来龙去脉表现清楚。

    到了描述某个节点的时候，PPT上手。一页PPT相当于一个界面窗口。每页PPT的图形模仿了菜单、输入框、按钮。按钮按下，还可以跳转到其他的PPT页上，和软件操作流程非常相似。

    PPT让程序员很直观的看到未来软件作出来是什么样子。关于PPT的详细描述，如字段，流程，特殊注意，特殊控制，都用WORD说明好。

    遇到有报表功能的时候，用EXCEL把报表画出来，让程序员喜闻乐见。

    这样，从表及里，从概要到详细，从分支到关联，都表述OK。客户也能明白，程序员也能明白，实施人员也能明白，老板也能明白（这点非常重要。虽然老板不懂软件，但他要干涉软件，他如果不明白，他就不知道这帮家伙到底在干吗，是在真正干活还是在偷懒，到底工作量是大是小，软件功能是复杂还是简单。老板如果不明白，老板在给与资源和时间上就会很谨慎，处处提防。这是许多项目经理都忽略了大事。还拿UML做秀，谁也看不懂，谁也用不了，白花费时间画那些好看的图。这就是中国的现状，我们站哪个山头就唱哪个山头的歌，有效解决问题提高销售收入才是我们的根本任务，我们不抱怨不幻想踏实推进解决问题）。

    于是，老板的天平开始向开发部倾斜了。资源，当然就容易申请了。

    画这些EXCEL+PPT+脑图+WORD，当然很费时间（我直到引进了日本外包开发过程管理才发现，我们的解决方法和强调质量的日本人的做法非常相似）。于是，我申请一个人，把过去实施的一个项目经理（还居然会写点SQL，从数据库查数据，调整个报表。实在太强了）调入开发部，专门编写这些文件。

    开发部开始蒸蒸日上。项目经理、开发人员、测试兼技术支持已经到位。工具也已用的不亦乐乎，深入到了公司的每个部门。每个部门都按照标准描述方法和标准流程走。现在，连实施人员都会画EXCEL报表格式、PPT界面。

    软件到位，就需要包装，否则软件就卖不上好价格。这是很自然的事情。干啥都要个品相。漂亮的姑娘谁都喜欢。

    软件包装，第一步就需要帮助文件、视频操作、解决方案、产品介绍、演示系统。当然，文案人员很快到位。美工美化也自然到位。能多赚钱干吗不做，老板也不是傻子。谁喜欢卖一个土灰土脸的产品。

    有了好的产品，出不去开发部也是个问题。只有自己内部人知道功能怎么用，怎么满足客户的需求，其他部门都不知道。许多人都不知道新功能和旧功能的改变。文档中都写了，更新说明也有，就是没有人看。还是打电话找技术支持，技术支持只能不断解释。问题又来了。

    文案出马。每次版本发布，功能更新，文案反复举办集中培训，办班，一批次一批次的培训，百其不厌。

    四套马车，于是真正的天下太平了。

    从此，开发人员和实施人员过上了幸福的生活。

    后续记：

    接到很多网友的评论，都说老板不可能给资源的。说我写的太理想。

    嗯，如果你看完我的文章就直接找老板要资源，当然是会被赶回来的。因为，你什么都没有做就开始要资源。

    有人还说，公司就这几条枪，能干活的更是那几头蒜。根本不可能给你派人。

    嗯，如果你思考的目标不是为老板赚取更多的钱，那么老板不可能给你一丁点的，甚至还会把你干掉。如果你觉得，这样的老板我还不伺候呢，那么中国大部分都是这样的公司，除非你转行不干这行了。要干，就别混日子。想得过且过让老板公司倒闭，这个基本不可能。再说老板倒闭了对你一点好处都没有。

    迈出你的第一步吧。不迈出第一步，你都会觉得这是不可能完成的任务。

    想过幸福的生活，从现在就开始脚踏实地的动手吧。

评论

5 楼 liujunsong 2008-10-28  

阿朱同学写的东西,只看到了问题的表面,解决了表面的问题;
没有看到问题的实质,也提不出解决实质问题的方案.

软件行业,和其他任何行业都有一个共同点,那就是:
1.需要产业链来生存,
2.需要分工合作.

而目前这两者正是小企业的通病,没有形成完整的产业链,啥东西都想自己搞,小农经济意识,是软件开发方面的自给自足,所以累的要死
企业内部没有明确的分工合作,企业之间也没有明确的分工合作,最后大家都累死拉倒.

任何一个项目,都不可能完全满足客户的需求,这个必然是一个相互妥协的过程;如果没有这个前提认识,那么从项目一开始,就会把项目引上歧途.
最后要么生产一堆客户不用的代码;要么把自己累成客户的廉价劳动力,甚至白干半天.

无论那种企业,都必须遵守基本的经济规律,投入如果超出产出,支出超过收入,那么企业面临的就是倒闭一条路.

4 楼 javafun 2008-10-10  

lococode 写道

rainux 写道

引用
小伙子一开始使用的是一个EXCEL。别人提的问题都自己记录在里面。但是弄到最后，我的手里、小伙子手里、开发人员手里、支持人员手里，都出现了不同版本的EXCEL。互相都说这个已经修改了，那个说没有修改。这个说有多少BUG，那个说不可能。 于是，我上了第一个工具，BUG管理系统。不管是BUG还是需求还是建议还是疑问，谁想提，都提到这里来，随时记录。不管你是出差还是在支持部坐班，都记录到这里来。凡不记录者，一律不解决。 从 Excel 到 Bug 管理系统，楼主是刻意要走这样一个过程让大家增强体验吗？还是说为了谨慎行事不在没有根据的情况下做大改变？ 从我自己的观点来看，如果事先知道将要使用的 A 方式很快会被 B 方式所取代，还不如直接就用 B 方式。希望听听楼主的想法，谢谢。恩，你说的是有道理，理想中确实可以直接用B方式，但你实际操作中，问问看，有谁不是一开始不是用excel干这个事情的？

显然，大家对微软提供的word和excel很有偏爱

3 楼 zjyujb 2008-08-28  

搂住的文章比较受用 有些启发

2 楼 lococode 2008-08-25  

rainux 写道

引用

小伙子一开始使用的是一个EXCEL。别人提的问题都自己记录在里面。但是弄到最后，我的手里、小伙子手里、开发人员手里、支持人员手里，都出现了不同版本的EXCEL。互相都说这个已经修改了，那个说没有修改。这个说有多少BUG，那个说不可能。

于是，我上了第一个工具，BUG管理系统。不管是BUG还是需求还是建议还是疑问，谁想提，都提到这里来，随时记录。不管你是出差还是在支持部坐班，都记录到这里来。凡不记录者，一律不解决。

从 Excel 到 Bug 管理系统，楼主是刻意要走这样一个过程让大家增强体验吗？还是说为了谨慎行事不在没有根据的情况下做大改变？

从我自己的观点来看，如果事先知道将要使用的 A 方式很快会被 B 方式所取代，还不如直接就用 B 方式。希望听听楼主的想法，谢谢。

恩，你说的是有道理，理想中确实可以直接用B方式，但你实际操作中，问问看，有谁不是一开始不是用excel干这个事情的？

1 楼 rainux 2008-08-22  

引用

小伙子一开始使用的是一个EXCEL。别人提的问题都自己记录在里面。但是弄到最后，我的手里、小伙子手里、开发人员手里、支持人员手里，都出现了不同版本的EXCEL。互相都说这个已经修改了，那个说没有修改。这个说有多少BUG，那个说不可能。

于是，我上了第一个工具，BUG管理系统。不管是BUG还是需求还是建议还是疑问，谁想提，都提到这里来，随时记录。不管你是出差还是在支持部坐班，都记录到这里来。凡不记录者，一律不解决。

从 Excel 到 Bug 管理系统，楼主是刻意要走这样一个过程让大家增强体验吗？还是说为了谨慎行事不在没有根据的情况下做大改变？

从我自己的观点来看，如果事先知道将要使用的 A 方式很快会被 B 方式所取代，还不如直接就用 B 方式。希望听听楼主的想法，谢谢。