小公司如何做项目管理(上)

我所在的公司和大多数国内IT公司一样，十几到几十人的规模，每次在做完项目过程中我们都会感觉很累，老板其实也很累，在小公司老板更像是一个项目经理的角色，很多东西都没有流程化的东西可走，所以很多事情都要等老板拍板后才可以继续下去，员工在很多时候就会感到迷茫，随着公司规模的扩大，公司也意识到没有一套规范的项目管理方案是万万不行的，自己在这方面也摸索的一段时间。

我首先接触的是敏捷开发的方法，但很快我就感觉这个方法行不通，至少对于我们是这样，因为我们无法保证和客户以及业务人员及时沟通，一个月见几次面就很不错了，而且我们的开发人员也并不具有敏捷能力。后来接触了下CMMI，CMMI对于小公司就更不靠谱了，它庞大的身躯足以把一个小公司压垮，如果仅为一个证书的话，我建议完全可以向o6z订购，但不可否认的是CMMI也有很多优秀的地方可以借鉴。那么我对小公司项目管理的看法是一定要精简，做到不是傻瓜都能够理解并且能够执行，况且很多项目经理（老板）也并不是领域专家。在此我想简单谈谈我对适合小公司的项目管理方案的一些想法，所谓基本适合就是80%适合，我要是说100%适合那我是在扯淡，另外20%怎么办？那就像06z所说的那样，靠经验这个王道。

首先要谈的是需求这个东西，那么什么是需求？需求就是掏钱买你产品的人一些需要，只要是客户的需要，不管是合理不合理那都是需求。其实很多开发人员都意识需求的重要性，那么真正去做需求的人有多少呢？需求应该是包括需求开发和需求管理这两个过程，这里有个特别的情况是对于自主研发的项目，我接触的项目也是这种情况居多，于是我们认为自己就是客户，所以需求开发做的很简单甚至跳过去，结果后期的需求管理非常混乱，我觉得既然自己是客户，那就要当好客户这个角色，在做客户时应完全忘却自己是个开发人员，同样要把需求做全面。很多教科书上都说应该做需求，但关于怎么做的问题上却和实际情况差别比较大，以下是我关于需求该做什么以及怎么做到一些看法。

1 需求调研

我觉得需求调研非常的重要，1年前我还打算做一个在线教育服务平台，理念就是淘宝在网上卖商品，我在网上卖教育资源，我提供网上交易场所，签约的老师、学校以及培训机构提供可交易的服务，这种服务可以通过视频、音频、在线PPT、文本的形式展现。忙活了好一阵，发现这个市场早就有很多人做了，而且这个市场并不是很好做，首先在网上学习的人有几个？并且先不说前期推广需要海量资金就是所需要的那么些高性能服务器丫也买不起！这件事就此搁浅，结果信了马云的邪，2年后你还想创业你在创业！我觉得这就是典型的需求调研没做好，没有对用户需求做调查，没有考虑同行竞争，没有考虑可行性！另外还要考虑括行业标准和法律规定，比如前些时候国家就出台了关于办视频网站的政策，我觉得你丫没有足够的背景就不要往火坑里跳楼。总之根据所做行业情况尽可能的把需求调研做全面，这样才可以保证项目首先是可以赚钱的。那么文档要写吗？我觉得可以不要正式的文档，小公司的人手本来就不够用，要把主要文档化工作集中在重要的环节上，对于需求调研，本来就很杂乱，完全可以记在工作笔记上，放到需求分析的时候整理。

2 需求分析

为了得到用户的金钱，我们总是在说，用户是上帝，用户永远是对的，尽管背地里在说客户端坏话：“你丫钱给的倒不多，要求还真少，这需求根本不合理，是正常人的逻辑吗？”，如果你想活下去，最终我们还是要想方设法满足用户的要求。用户是个外界因素，我们是无法控制的，那么我们只有尽可能改进需求分析的方法来尽量减少不必要的麻烦。那么我觉得日本人做法倒是可以借鉴，在有条件的情况下派专人去现场，随时记录关键性的需求，即使不能去现场也尽可能的获取尽可能多大信息，不要指望开发后去获取什么有价值的东西。那么是否应该做个原型给客户看看？我是觉得这不大合适，因为如果项目周期短的话，等你做好原型，黄花菜都凉了。但我觉得等到需求做到差不多的时候可以做用户界面，所谓用户界面就是用户接口，是和用户打交道的地方，所谓一图解千言，有了界面用户会清楚自己所买的东西在未来会是个什么样的东西，再者开发几个有说明性都界面倒是不会暂用很多时间。等到需求确定下来后就要整理成文档了，这个是很重要的一步，是做设计时候的重要凭证和依据，这个文档就是用户规格说明书，所谓规格就是有规范的格式和内容。

3 需求评审

我们已经有了较正规的文档了，那么下一步就是召集所有开发人员开会，最好有客户代表参加，尽管我是很厌烦开会，但该开的会还是要开到，因为之前我遇到这种情况，开发人员根据设计文档写代码，可是他并不知道自己在开发什么，站在自己的角度想一下，如果自己都不确定自己做的东西，即使有再完备的设计，也会对开发毫无兴趣，只会让自己觉得自己是个代码机器。所以所有人员参加需求评审是让大家知道自己在做一件有意义的事情，自己正在满足社会的需要，自己在为和谐社会做贡献，即使你从没那么想过，那你敢保证的你的潜意识没那么想过吗？人是要有社会满足感的吧。另外开会前一定要准备关键有价值的议题，据我观察需求评审会最容易扯到不着边的话题，所以主持人要控制话题，会议控制在2-3个钟头，最好做成幸运52的形式，所有人员一定要互动起来，否则就变成了个人演讲。需求也做了，会也开了，那么要求客户签字吧。

4 需求管理

需求管理是在开发开始之后进行的，这也是另所有人头疼的一件事，之前做完一个项目后，客户经常打电话找我们，改过来改过去，后来我听到电话，血压都要升高50个百分点，后来索性就不接电话，客户就在网上找我，搞的我连QQ都不敢登，但躲是躲不掉滴，客户直接打我手机，丫的真烦人，见过难缠的，没见过这么难缠的。后来转念一想，难道这种情况真的不能避免吗？至少是可以大幅度的缓解的吧。这就是我们需求管理中的变更管理没做好，改了哪些地方自己都忘记了，最后是跟着感觉走，拆东墙补西墙。在这里我建议要建立需求跟踪矩阵表，有了这个表我们至少可以对要修改的地方有了依据，迫使我们去调查到底是改什么地方，怎么改，最后改成了什么样。可能你会说客户需要大幅度修改原有计划，很难跟踪到具体某一项需求，那么我觉得这是由于前期的需求开发没有做好，在后期客户进行实质性的修改的几率是很小的，比如客户要求我们做个OA系统，最后总不会要我们改成个门户网站吧，在举个例子，在比如你开发一个ERP系统，客户自己的业务流程不会轻易的改变吧，总不至于把盘点这个业务改成一个报表系统吧。如果真是这样，我们完全有理由告诉客户，你丫乖乖掏银子，我们再给你们开发2期工程，要改，没门！

大家开始拍砖吧，有时间继续……

评论

13 楼 xiepinghejun 2008-07-21  

刚刚本人看了O6Z大师的帖子，觉得见解很独特，本人也觉得对于一个小的团队来说个人经验和集体经验的积累和传递，比大团队要成本低很多，成熟度也大很多，提供的效率也高很多。同时由于小团队中，自然的责任很多，委派职责很少，管理成本和监督成本虽然比例比较高，但是总额却很少，以至于有些时候可以忽略。所以说对于小的团队实施项目管理和监督作用是很大的，他们的职责是很分明的，实施起来难度也不是很大，对提高公司的效率也是很有效的；比如说用CMMI的标准来对一个软件公司的制度化，实施起来相对是简单多了；但是我想问下对于一个十几个人的公司，实施项目管理和监督对于成本来说是能否相对减少相应的成本呢?

12 楼 ozzzzzz 2008-07-21  

而就需要这个方面来说，客户比开发者更加有对自身具体情况的了解，也有最终决定权。但是说客户对行业和领域更加理解，却是错误的。这是因为客户往往并不能理解计算机的计算能力究竟会给他们带来什么，他们的想法是不是真的实现之后，就能带来他们想要的后果。
就某些场景来说，可能客户更加具有潜在的前瞻性。但是就大多数场景来说，客户根本就不具备任何的前瞻性，他们比开发者对应于计算之后的领域和行业的理解要低的多。而即便是开发者更加具备这个方面的优势，也往往与真正的后果差距甚远。而也就是这个原因，组织的信息系统规模就显得十分重要。而开发者如果能通过某种手段，将客户培养成具备一定能力的信息系统规模能力的人，将是目前这个阶段，其能创造的最大价值所在之一。然而一个客观存在的事实是，客户99%的情况是错误的，开发者95%的情况下是错误的。这一点并不会因为大家都具备了规模能力而改变，仅仅是因为具备了这个能力，可以具备更多的能力和机会改正这些错误。

11 楼 ozzzzzz 2008-07-21  

一个公司是不是存在一个流程化的稳定过程，其背后的原因很多。
如果你们是处于一个高度变动的环境，那么稳定的过程就无法自我完成和进化。在一个高度变动的环境下，稳定的过程其作用往往是与建造这个过程的初衷背道而驰的。我们都记得有一段时间，很多人都在说想依靠某种流程，抵消人员高度流动带来的负面影响——经过他们这么多时间的操作之后，我没有看到谁在这个方面确定的取得了值得放在桌面上讨论的成就。我们还记得，有众多的人希望建立一个稳定的流程，以应对快速扩张的企业开发团队规模，希望可以简单的copy过程，而使新团队快速的过渡到成熟团队，而不降低这些团队的开发效率，这样的尝试绝大多数也是失败的；成功的也仅仅是，那些团队本身就没啥效率可言。又比如，为什么现在华为这样的公司，在高速向敏捷方法靠拢，而我们经常看到的互联网公司即便在声称是敏捷，其内部的事实方法并非那么灵活和自适应，原因就在于华为面临的成本和质量压力要大大的高于另外那些企业，也就是说只有当开发组织真正面临高度的成本和质量压力的时候，他们才可能真正的去对自己的过程下力气进行真心实意的改造。
而小团队的管理跟成规模团队的管理策略和方式是不同的，这一点并不是所有人都有所意识。就小团队来说，个人经验和集体经验的积累和传递，比大团队要成本低很多，成熟度也大很多，提供的效率也高很多。同时由于小团队中，自然的责任很多，委派职责很少，管理成本和监督成本虽然比例比较高，但是总额却很少，以至于有些时候可以忽略。而大型组织，他们的大型团队和多团队合作，造成个人经验和集体共同经验的积累很困难，成本也很高，相互交流和传递这些东西的成本更高，组织性积累更加困难。因此大型团队更加需要一种能够被其成员普遍遵守的共同约定性的东西，更加需要一种集体的方言，这就是过程。然而我们也要看到，即便在大型团队中管理和监督的成本比例可能是低的，但是其总额却往往是高的。从公司自身优化和发展的角度来说，一旦面临成本和监督压力，在这个方面下手可能是最常见也最容易产生效果的。当然我们也必须从中国这个特殊的具有悠久官本位文化传统的民族性出发，认识到管理和监督的压缩绝对不是一件容易的事情。但是这也从反面告诉我们，在增加管理和监督的成本付出之前，一定要谨慎而谨慎，能不增加就不增加，因为一旦增加你今后要消减就会变得很困难。这一点就为什么在中国应该尽量减少临时性措施的一个内在原因。

10 楼 liuqiang 2008-07-21  

sg552 写道

我觉得，一个月才跟客户见几次，是软件开发的很危险的信号。

事实往往如此，前期可能多一点，开发过程中总是有各种理由难得和客户见一面，不是他忙就是我忙。尤其是做异地项目。

sg552 写道

另外，能否请楼主 说一下， 敏捷开发在小公司里实行不起来的 原因吗？ 我比较关心这个，希望学习下。

敏捷开发在10人以下我不好说，但十几到几十人的公司我看还是别冒险了。
只谈2点，首先看看敏捷开发的特点，业务是敏捷的，业务人员和开发人员很难经常在一起，就算经常在一起，那么随时都会有新的需求，系统要经常重构，开发人员具备这个素质吗？就等着和业务人员吵架吧。
另外敏捷要求你们公司要有很好的员工激励机制，我看这是大多数小公司所缺乏的。
你觉得呢？

9 楼 liuqiang 2008-07-21  

ozzzzzz 写道

xiepinghejun 写道

liuqiang同志　　项目管理中需求做的好与坏是很重要的　　但是项目中管理和监督也是必不可少的呀　　能否在项目的管理和监督的方面来全面考虑项目管理啊？　　不过写的还是不错的！

管理和监督的重要性主要体现在，应该建立一种机制，将管理和监督在成本中所占的比例降低到最低的可承受限度，其终极目标是将管理和监督从所谓的“必不可少”的条目中删除。

06z前辈，小公司的需求做到这个份上，是否足够和合理？想听听你的意见

8 楼 sg552 2008-07-21  

我觉得，一个月才跟客户见几次，是软件开发的很危险的信号。

另外，能否请楼主 说一下， 敏捷开发在小公司里实行不起来的 原因吗？ 我比较关心这个，希望学习下。

7 楼 liuqiang 2008-07-21  

xiepinghejun 写道

liuqiang同志　　项目管理中需求做的好与坏是很重要的　　但是项目中管理和监督也是必不可少的呀　　能否在项目的管理和监督的方面来全面考虑项目管理啊？　　不过写的还是不错的！

呵呵，听了很多大师关于项目管理的文章，但是只是站在某一个方面再谈，如果考虑项目管理上下文环境的话，我觉得未见得就是合适的。与其尽信大师，，还不如来点简明而又完整的。一篇文章要把所有的项目管理全涉及也不实际，所以我打算逐个拿出来讨论，尽量保证连续性，有时间我会补上
：）。

6 楼 ozzzzzz 2008-07-21  

xiepinghejun 写道

liuqiang同志　　项目管理中需求做的好与坏是很重要的　　但是项目中管理和监督也是必不可少的呀　　能否在项目的管理和监督的方面来全面考虑项目管理啊？　　不过写的还是不错的！

管理和监督的重要性主要体现在，应该建立一种机制，将管理和监督在成本中所占的比例降低到最低的可承受限度，其终极目标是将管理和监督从所谓的“必不可少”的条目中删除。

5 楼 xiepinghejun 2008-07-21  

liuqiang同志　　项目管理中需求做的好与坏是很重要的　　但是项目中管理和监督也是必不可少的呀　　能否在项目的管理和监督的方面来全面考虑项目管理啊？　　不过写的还是不错的！

4 楼 g81997842 2008-07-21  

总结的话,值得深思啊!~!~CMMI,不说人的质量,人的数量也需要提升!

3 楼 xidaboy 2008-07-21  

楼主的文章写的很好

如何看待需求的问题

主要是管理好需求

我手头有个项目,从无到有做了8年,一开始几乎是免费给客户试用,然后一点点加功能,再到得到客户,再到推广

需求变更怕什么,主要是改了还要让客户满意的掏钱

我们巴不的做个几十期呢,反正期期有钱拿  

2 楼 liuqiang 2008-07-21  

bfcat 写道

很多东西说不清楚.  就需求管理本身,在我们这种环境里面就说不清楚了.  如果直接跳到后面, 当然会死得更惨. 可如何走好第一步呢?  需求跟踪矩阵如何用呢?  呵呵.... 看的都晕.

我之前的想法和你一样，由于很多东西说不清，所以干脆不说，所以我们逃避，可是需求管理是躲不了的，否则就像你说的死得更惨，我也想听听你更好的建议：），就像牛根生所说的，办法总比问题多。
需求管理难做和做不做是2回事，我觉得只要你认真去做，总会有收获，需求跟踪矩阵怎么用？那要看你要怎么用，变更总要有原因吧，针对变更总得有解决措施吧，你的后续修改工作总得有个依据吧，修改完之后总得有个结果记录吧，附上需求变更表一份。

1 楼 bfcat 2008-07-21  

很多东西说不清楚.  就需求管理本身,在我们这种环境里面就说不清楚了.  如果直接跳到后面, 当然会死得更惨. 可如何走好第一步呢?  需求跟踪矩阵如何用呢?  呵呵.... 看的都晕.