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

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



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

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

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

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

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

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

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

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

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

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

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