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

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

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

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

1 需求调研

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

2 需求分析

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

3 需求评审

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

4 需求管理

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

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

评论

33 楼 tianyichang 2008-07-25  

有时候和具体分析用户的需求比起来，对一个行业的理解更加重要，因为当你在和他谈需求的时候，客户往往不知道自己要的是什么，这时候就需要对行业有比较深入认识的人来引导他们。

32 楼 xiao0556 2008-07-25  

就如楼上所说对需求的挖掘 是一切的中心,但是你不懂业务怎么挖需求?客户表达的需求你很难体会和把握 需要你进一步的分析和挖掘.这一切都离不开对业务的熟悉.为什么行业经验这么重要? 其实就是掌握某一行业的业务知识加上自己的技术能力 能更好的做好需求.软件就是工具,要知道客户真正需要的是什么样的工具 然后才是去把工具做出来.

31 楼 poeao 2008-07-24  

感觉需求其实就是根本的地方~~~

一切转绕在它周围

30 楼 hyhongyong 2008-07-23  

clamp 写道

shenrd666888 写道

项目管理是个头疼的问题

很重要的一点要考虑后期维护， 可行性  扩展性很重要。 后期维护我已经很头疼了，

成了没止境的事情了。。。。。

期待大家有好的建议。。。。

后期维护的关键不是前期的可行性和扩展性，而是能不能收到钱
这是一个商务问题，而不是技术问题

不能一概而论，有的时候后期维护是要增加功能的，如果前期技术问题没做好，可扩展性差，后期会相当难办的。
系统的重构不是一件简单的事情！

29 楼 clamp 2008-07-23  

shenrd666888 写道

项目管理是个头疼的问题

很重要的一点要考虑后期维护， 可行性  扩展性很重要。 后期维护我已经很头疼了，

成了没止境的事情了。。。。。

期待大家有好的建议。。。。

后期维护的关键不是前期的可行性和扩展性，而是能不能收到钱
这是一个商务问题，而不是技术问题

28 楼 clamp 2008-07-23  

liuqiang 写道

clamp 写道

lz讲了那么多,但是我认为有一个比懂业务的人是最重要的,最好比客户还懂业务.
对于小公司而言,这个人在创业期就该有了.
否则再好的过程也不能把一个一窍不通的人变成高手.

很多小型软件企业的老板只有客户关系,没有业务管控能力,这是非常致命的一点.
客户关系只能接单,业务管控能力是让单子赚钱的关键.

你说的有道理，但不知你有遇到这种情况吗？有的公司为了活下去做的行业不单一，有钱就赚，那么如何做到比客户还懂业务？
业务管控能力确实是很多公司所缺乏的，但非常的重要，我很赞同！

那这些公司就是被淘汰的命啊

27 楼 shenrd666888 2008-07-23  

项目管理是个头疼的问题

很重要的一点要考虑后期维护， 可行性  扩展性很重要。 后期维护我已经很头疼了，

成了没止境的事情了。。。。。

期待大家有好的建议。。。。

26 楼 jili 2008-07-23  

1、大多数所谓新需求或者需求变更，其实是未能看到用户核心需要，为用户提供真正的解决方案。项目团队对所作项目的行业和领域熟悉吗？有较多行业和领域经验的核心成员吗？
2、客户的管理水平如何，有改进机制吗。项目发起人和关键用户对it信息化有比较清醒和实际的认识吗？对于一个项目付出的代价带来的好处有比较符合实际的期望吗。

如果两个问题是比较否定的答案，我觉得需求甚至是技术的恶性变更大部分是无法避免的。这个问题，我觉得与过程无关。cmmi或许可以通过文档、形式来保证质量，把某些风险明确化或者推向用户；敏捷或许可以降低一些变化成本和质量成本，但是都并不能解决根本问题。一个项目中，解决客户问题才是最终目的，it系统只是手段之一，如果关注点只在后者，或者对前者的解决方案根本没底，那就必须抱着艰苦作战或者陷入大坑的心理准备。

25 楼 javacc 2008-07-22  

我觉得项目成功的关键在于需求调研、需求分析这阶段，在需求调研阶段尽量做到需求的正确性，在需求分析阶段，配合美工快速构造出关键需求的原型界面，利用原型界面来验证需求的正确性和利用反馈完善需求，在分析阶段，详细描述系统的功能性需求、非功能性需求、主要界面的方案等；需求管理阶段利用jira、wiki等工具来跟踪需求的实现情况。

24 楼 tian4 2008-07-22  

说的很好，项目管理等于平时做事的方式一样。方法不对累死人。

23 楼 ozzzzzz 2008-07-22  

reilf 写道

我们公司也尝试了很多种项目管理方法，目前正在推行IPD。IPD对于市场和需求管理的流程定义得不错，对于任何一个公司，客户和市场都是非常重要的。我觉得可以将IPD过程的市场和需求管理部分裁剪，供自己所用。不知道O6Z大师对IPD有什么看法？

我目前看到的情况，绝大多数IPD都是找死的人找了一群骗子顾问在实施。比如某些前期在国内骗钱的cmm咨询公司，现在很多都转向这个领域了。
当然就产品设计来说，确实存在其特殊的模式，而且这个专业领域也存在比较久了。但是这并不是说，软件公司可以很简单的把这些思想拿过来用。不过确实是很多方面可以借鉴的。

22 楼 tuti 2008-07-22  

每个人都是一颗杰出者的种子。
优秀的领导者，就象园丁一样，使这颗种子更适宜萌芽、成长。

21 楼 neodoxy 2008-07-22  

ltian 写道

没有杰出的人，一切都是空中楼阁。

绝大多数是普通的人才能做一件大事,都是杰出的人往往只能做一件小事
只论规模
而且就算是顶尖的公司,也不能保证在每个方面都使用业界最优秀的人才,如何将所有员工的能力发挥出来才是公司应该解决的问题.

20 楼 hyhongyong 2008-07-22  

ltian 写道

没有杰出的人，一切都是空中楼阁。

人员是首要因素。如《最后期限》

• 优质管理的四大要素
• 选择正确的人。
• 为他们分配正确的工作。
• 保持他们的积极性。
• 帮助团队凝聚起来并保持团队的凝聚力。

(其他一切都只是“文案”。)

19 楼 liuqiang 2008-07-22  

clamp 写道

lz讲了那么多,但是我认为有一个比懂业务的人是最重要的,最好比客户还懂业务.
对于小公司而言,这个人在创业期就该有了.
否则再好的过程也不能把一个一窍不通的人变成高手.

很多小型软件企业的老板只有客户关系,没有业务管控能力,这是非常致命的一点.
客户关系只能接单,业务管控能力是让单子赚钱的关键.

你说的有道理，但不知你有遇到这种情况吗？有的公司为了活下去做的行业不单一，有钱就赚，那么如何做到比客户还懂业务？
业务管控能力确实是很多公司所缺乏的，但非常的重要，我很赞同！

18 楼 clamp 2008-07-22  

lz讲了那么多,但是我认为有一个比懂业务的人是最重要的,最好比客户还懂业务.
对于小公司而言,这个人在创业期就该有了.
否则再好的过程也不能把一个一窍不通的人变成高手.

很多小型软件企业的老板只有客户关系,没有业务管控能力,这是非常致命的一点.
客户关系只能接单,业务管控能力是让单子赚钱的关键.

17 楼 reilf 2008-07-22  

我们公司也尝试了很多种项目管理方法，目前正在推行IPD。IPD对于市场和需求管理的流程定义得不错，对于任何一个公司，客户和市场都是非常重要的。我觉得可以将IPD过程的市场和需求管理部分裁剪，供自己所用。不知道O6Z大师对IPD有什么看法？

16 楼 fz8224 2008-07-21  

关于项目评审，我们之前有个项目是开发人员全部到场，客户会亲自对模块负责人提问，以确定开发人员对需求的理解程度。大概总共花了半天多的时间，效果不错。在一些关键点的把握上比需求人员间接传递消息更直接。而且开发人员也不会“盲人摸象”，他们更容易理解他人和自己在团队中的作用及目标。

15 楼 hyhongyong 2008-07-21  

如果客户不能经常性参与，能否阶段性参与，由业务人员把客户的需求收集起来并及时整理。需求的变化自然需要一定的管理，开发人员阶段性的根据需求的变化来变更软件或者新开发内容。
这样的开发过程，不能算敏捷吗？

14 楼 ozzzzzz 2008-07-21  

xiepinghejun 写道

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

就cmmi的问题，我更希望单独的讲，因为这个系统十分复杂，事实上实施的方式也很多，并且评估中人为的因素也很多，最终的实施结果差异也很大。这些都是cmmi这个体系自身的内在矛盾的体现。
回过头来讲小团队的管理问题。实际上管理的加强和监督的加强，往往意味着管理和监督的减少而不增加，这一点不管小公司还是大公司都是一样的。实际上管理的增加造成的成本是否能够回收，并且如何回收，这一点不管所处的组织规模，都是十分困难的工作。而不管是什么场景，增强管理和监督首先要做的，就是这个方面。当然我们不可能一步到位的解决这个问题，也不可能固定不变的采取一个固定的模式解决这个问题。但是如果不能对一个管理和监督措施进行评估，你又如何能够相信它们能够对你进行的开发工作进行评估，而没有这个评估，你又如何进行管理和监督的工作呢？
而一旦你有了这个评估的体系和标准，那么你就可以对你的工作以及对工作的改进进行评估。也就是说，你需要一个对cmmi以外的结合自身具体情况的评估体系，以对包括cmmi或者agile的实施后果的评估系统。