关键字：项目管理 专用软件

适用于：专用软件开发的项目管理，与通用软件不同，与大众消费软件不同。涉及甲方、承建方。

观察项目的三个指标：时间、预算、质量及功能完整性。

失败的项目一般体现为：超时、预算超支、牺牲了部分功能或质量。彻底失败的项目，就是一个最后压根没有完成的项目，比如烂尾楼。

首先，我们讨论其中的一个指标，时间。

每个人对时间的理解不同，同样在项目里面的每个人对项目的时间理解也是不同的。

1、 公司，　希望项目在最短的时间内完成，这样时间和预算都是最小的。当然能做到的项目少之又少，业内有数据的。

2、 项目经理（为行文方便，暂称为PM，下同），　希望项目的计划时间尽可能地长，这样才有机会应付各种突发事件和不可抗的影响，毕竟很多原因是客观存在的。墨菲定律。

3、 功能模块小组长(如.....等，暂称为小组长)，　一方面承受着项目经理的压力，一方面又承受着来自基层开发人员的压力。PM会要求小组长以最短时间完成所负责的部分；开发人员则很反感长期加班、高度的压力感。

从过去的一年多来看，在时间要求方面，我们公司的意愿并不强烈。当然并不是强烈就可以解决的，后面会讲到，这是本文的重点。

在我们公司，最后决定项目时间长短的关键，是开发人员。在人数不变、人员不更换的前提下，每个开发人员的产出是固定的，至少目前来说是固定的。加班，也不会有更好的改善，原因已经在我以前的邮件中说明过了。

那么，从上至下形成一种新的强制性时间要求，会不会有效呢？事实上，不是没人试过，结果估计并不理想。程序开发是一种脑力劳动，决定一件任务完成所需时间是由程序员的脑袋决定的，甚至任务完成到什么程度，如果不花费大力气的检查也是不会轻易能发现的。这点有过中层管理经验的人，应该都清楚。例如，管理人员要求用三天完成某个新功能，开发人员说至少要一周时间，即使最后管理人员令开发人员妥协了，他得到的也很可能是一个半成品——能用，但有缺陷；或者表面功能完成了，主线功能有部分没有完成。

换人吧，中国程序员遍地都是，这不是问题的关键，所以换人作用不大。新人很快会被同化。那全换吧？全换是什么概念，换到哪个级别，这是个Big Question。而且还有另外一个问题——知识传承。弄不好，伤筋累骨，结果还不一定就能如愿。

那么，问题是不是无解了呢？ 不知道，我也没有经验，这里只能提供一点看法，周末不想逛街，就写点东西，分析一下身边的问题，说得不对，就按一下DEL，不会太费事。就当是闲聊吧。

接着……其实还有一类人的时间，或许他们的时间要求才是最值得研究的。

4、 甲方(客户)　一般地，政府作为甲方，内部意见并不完全统一。我们作为承建方，可能要配合那些支持我们的某些甲方代表（暂称友好方，下同），另一方面也要考虑到对我们不太支持的另一些人（暂称反对方）。很可能看起来无关紧要的一个小员的一句话，就会对项目产生不可挽回的影响。

甲方内部的友好方和反对方，他们的时间要求是不一样。反对方，在具体开发的过程中会有一些不配合，另一方面对项目完成的时间要求又会格外的严格。所以，我们的时间表，以达到甲方内部的反对方的时间要求为最优，以达到甲方内部友好方的时间要求为及格。如果我们在开发中，处处以友好方的时间表作为自己的时间表，完全不预留安全时间，那么到最后我们会非常被动。
甲方的时间表对我们的可能影响包括：

A、 要弄清楚甲方真正的时间表，尤其是反对方的，并传达到公司内部每一个相关人员，所有计划都就应按这个时间表走。（反观我们，一方面我们只考虑友好甲方的时间表。另一方面，现在整个时间表其实已被开发人员劫持，我们的计划是按开发人员人数×每周工作量摊开的，呵呵。)

B、 系统主要功能的真正完成，是真正完成，需要与客户多次反复交互、反复调试修改。第一次提交的版本，完全不能算是最终版本。对于具体的某个功能，或对于整个系统来说，都是这样。（反观我们，我们可能无法在客户要求的时间表之前（之前！）提交版本，即使提交了，也是首次提交，而非经与客户反复联调过的版本）

C、 准确把握业务需求，还要准确地把握客户的非业务需求（如性能、推动试运行、UI易用性人性化、配套的培训等等）。准确地把握这两件东西，将会对开发效率，乃至于项目进度都会产生极大的助益。（反观我们，我们现在的绝大部分兵力，都投在研发环节，投在客户身上的时间实在不够，下面还会着重提到。）

D、 公司应该有自己的时间表，产品研发计划应与市场运作联动。如获取业内行家的好评，需要我们及时发布可用的、漂亮界面的、稳定的、功能完整的版本；如搞财政系统内的推介会，我们也需要这样一套东西。对于我们没有的系统，我们应该有演示版本，而演示版的制作，也需要公司有专门的部门提前研究潜在的客户要求、业务需求。

E、 产品研发的进度，任何时候都应该有5～10％的弹性。不是说要把时间表随意向前一调就叫弹性。（如果所谓的时间表到了一点动静都没有，下次开发人员也会学精的。同一个老鼠夹都会给老鼠识破，何况是自以为天下最聪明的程序员们呢。这是事实，不止一次发生了。比如说1月1号系统上线，1.1到了什么事也没有。结果才知道原来甲方要求的是2月1号上线。而甲方给上级的承诺是2月15号。双重忽悠！下次再说某月某日上线，大家就心里有底了，反正还有一个半月。忽悠的反作用。要么，就说1.1是我们上线第一次全面测试；1.15再做一次全面测试；2.1如果有时间就做第三次全面测试。我们的要求是最少做两次全面测试。这听起来都会好一点。）而是需要我们真正掌握产品研发中哪些因素在影响我们的开发进度，如何激活这些因素，在必要的时候为我们所用。比如说建立一套量化的、可监测的指标系统，在需要时加入一些物质激励，让各项指标在固定时间内得到实质性的增长。（如在服装厂，假设剪线工段是瓶颈，平时一个剪线工每天可以剪100件牛仔裤的线头，赶单的时候只要提出每人日产量达到150件，每件的单价提高20％。那么用一个瓶颈工段的费用，激活了整个生产线。前提是有指标衡量，而且知道哪一个工段是瓶颈。我家里是曾经做牛仔裤的，且家乡共计有1000多家牛仔裤公司，这是实例。）

F、时间表至少应该有两份，公开也无所谓。一份为最优时间表，一份为合格时间表。项目整体时间，或具体的小项任务都应该有。Time is money. 报价1000万的项目，用500万/年成本×1年完成，跟用250万/年成本×2年完成，其结果是截然不同的。推荐高德拉特的《关键链――突破项目管理的瓶颈》P53，第九章，其中有“安全时间”的讨论。

下面讨论一下具体问题

××做为一个专用软件开发的公司，内部事务可分为两类：

1、销售　促成客户采购决策。关键字：采购。

2、交货　开发并保证客户顺利收货。关键字：收货。

包括采购前试用、采购后交货。因两者在实际工作中没有质的区别，所以统一讨论。

交货，可以说是我们当前绝大部分工作的目标。

根据具体工作的复杂度，可将它分两个部分。如果这两部分的复杂性没有一定的当量，那么以下的讨论将失去意义。划分如下：

一、客户部分；（负责人：项目经理）

目标：在低于报价的预算成本、在既定的时间内，保持主要功能完整性的基础上，让客户满意并保证顺利收货。

重点：真正搞清楚客户需要的是什么？包括业务需求、非业务需求等。

难点：客户

负责人职责：

泡在客户那里，研究客户。
　为研发部门，提供清晰、完整的需求文档及时间表。
　推进安装联调、试运作的进展。
　负责产品阶段的质量测试检查。

二、研发部分；（负责人：研发经理）

目标：更好地实现需求，完成研发任务。
　重点：如何更快更好地完成开发。
　难点：技术细节、需求变化、框架设计、技术人员管理
　负责人职责：
　　分析需求文档，设计实现方案。
　　管理开发人员的日常工作。
　　提供研发进度表。
　　负责开发阶段的质量测试。
　　理想的模式及比例：两边的圈一样大

我们当前的架构安排：（没有专门的客户代表。少量的客户接触+大量的技术细节）

两个阶段各自不同的复杂性，决定了这两部分工作不能由同一个人负责，因为一个人的精力不可能应付这两种复杂性。同时关注两个领域，意味没有关注。

项目经理的工作焦点是客户；研发经理的工作焦点是技术。一个将工作重点放在技术细节的项目经理……或者相反，对于公司都可能是一个灾难。是不是如此，我们只要判断一下，或询问一下，就可得知。这种错位，一般有以下表现：

a、客户的意志，在公司内部没有人传达，或传达失真。做过市场的人就知道，客户代表往往在公司内部充当着客户利益的代言人，会为客户催单。对于产品的质量问题，往往比研发人员、生产人员更加敏感。因为大家的立场不一样，技术人员对于自己的作品往往有着非理性的感情，而客户代表一般没有这种感情，他基于公司与客户的共同利益，往往先于客户在公司内部处理掉一些可能会令客户不满的内容。

典型地，客户要求的时间表，对于一个平时聚焦在技术细节的经理，他往往倾向于以技术上的客观原因，反对客户的时间表，或为项目的延迟提出纯技术性的原因。对于客户要求的需求变更，往往有抵触心理。这点在其他软件公司有时表现成为一种公司内部的冲突，市场人员与开发人员的冲突。这种冲突是一种良好的现象。说明立场、利益在冲突，这种冲突在公司内部发生，总好过在客户与公司之间发生。

所以，当客户要求的时间表发生延迟的时候，技术经理和客户代表的态度是截然不同的，虽然他们的公司立场可能是一致的，但关注点却是完全不同的。技术经理更倾向于忽略这种延迟的重要性，而表现出一种麻木感。这对于客户来说，很可能是致命的。对于判断项目的实质进展，公司内部与客户常有截然不同的定论。

b、公司内部没有人真正掌握客户的需求。我是指此时此刻的真正需求，这不是资深的行业顾问，或完整的项目协议书能够体现的。

典型地表现为，研发人员经常会因为客户的需求变更而抓狂。为什么会这样？皆因没有人真正超越技术层面，去研究客户的需求。客户的需求有功能上的需求，也有非功能性的需求，对于不同的需求有着完全不同的优先级和完全不同的时间表。

不了解客户，才会被客户牵着走，才会对于客户要求的一些变化感到突然、无所适从，才会被不断新增的需求掩埋，即使很多需求是关联的，甚至是同一件事情不同的面。

c、所有人对于产品的质量都不敏感。不会有人跳出来说，我们的产品就是垃圾，那我们就要警惕了。据我所知，在做外贸的工厂中，跟单人经常会跟车间的负责人吵，最常用的话就是，这种垃圾，你叫我怎么跟客户交待啊？多悦耳的话语，至少对于老板来说是这样。

我们的系统，有没有人跟你讲过很慢啊，界面很难用啊，功能很不稳定啊？如果没有，小心了！

以下为建议部分

公司架构服务于公司的目标，也服务于客户，而不是服务于公司历史，最多只受历史的限制。

所以，我个人觉得应划分为以下四大部门，如行政/财务/人力/后勤等功能性的部门就暂时忽略不谈了。

一、市场销售部（商务部、市场部、销售部、营销中心，都一样了……）

负责促成客户采购决策倾向于××公司。
　……

二、客户项目部（项目部、客户部……什么好听、习惯都可以，把握重点就好）

　负责在常驻客户所在地的项目管理工作：
　　1、为研发部门，提供清晰、完整的需求文档及时间表；
　　2、推进安装联调、试运作的进展；
　　3、负责产品阶段的质量测试检查；
　　4、协助推进商务工作的开展；

人员组成：（除市场人员外，全部归PM旗下的编制）
　　1、PM;
　　2、各系统的需求代表；（新职位，由组件派员，由公司专门培训后派出。也可解决部分技术问题）
　　3、实施人员；
　　4、产品质量检测人员；（测试员）
　　5、客户代表（市场部派员）
　　6、配置人员；

三、研发中心（各组件组、研发项目组、开发部……）

负责产品研发：
　　1、分析需求文档，设计实现方案。
　　2、管理开发人员的日常工作。
　　3、提供研发进度表。
　　4、负责开发阶段的质量测试。

人员组成：
　　1、研发PM;
　　2、设计人员（当前的条件，可由PM、副PM负责）
　　3、开发人员；
　　4、开发测试人员；（新职位，偏测试的开发人员）
　　5、配置人员；

四、质量部

负责对公司内所有产品的质量指标负责（新职能）、规范公司研发过程：
　　1、设计规范过程，并定期评估各部门的过程规范水平、效率瓶颈。
　　2、监控各部门过程规范的执行情况，定期汇报；
　　3、设计公司的质量监控指标体系；
　　4、推动公司所有产品的质量指标；对产品的质量水平负责；
　　5、负责项目组、研发中心的测试人员的培训，并负责业务上的指导管理；
　　6、将测试阶段前推至需求阶段；
　　7、构建公司的知识共享、知识传承体系；将公司知识资产以物理方式保存下来；
　　8、负责培训各部门的配置、数据库管理人员，提供业务上的指导管理；

人员组成：
　　1、部门经理；（专职）
　　2、……暂时没有，呵呵。看需不需要，可考虑增加人手支持。

新架构需要的辅助制度、工作方法规定……

1、项目组与研发中心的沟通标准。原来的项目管理和研发中心是基本二位一体，很多时候，沟通的过程都是非标准的。

如定期由项目组向研发中心发送新需求清单＋缺陷清单，附上完整的需求文档。这些文档可让在项目组内部的需求代表（研发中心派员，新增职位，见上）参与撰写需求文档。文档可能需要来回沟通，但最后应有一个标准的需求文档、待完成清单。

研发中心，定期向项目发送研发进展表（针对新需求清单＋缺陷清单）。

沟通的周期，应尽量地小，最大不应超过一周，周三应该有一份非正式的清单反馈，缩小沟通周期以免影响项目进展。如有信息化的项目管理系统的公司，这些都是实时的，可以迟点再考虑。

2、研发中心新增设了“开发测试人员”，所以研发中心应对发布出来的产品保证一定的质量。所以项目组每周的缺陷清单，应抄送指定的行政人员备档，每月统计各研发产品的产品测试阶段发现的缺陷数量。

3、各项目组与研发中心的各组件开发小组，应制定标准的沟通人员清单。规定哪些问题，应由哪些人员来负责沟通。以前的经验是，大问题由小兵来负责，小问题由项目经理来负责，完全混成一片。应做彻底的梳理和规范。保证沟通的有效性。对于没有沟通协调能力、或沟通能力较弱的小兵（比如我），应尽量避免让其参与到部门与部门之间、或跨地域之间的沟通，极影响沟通效率。

公司应规定哪些标准文档、沟通内容，应由行政人员备份。以记录项目进展和研发进展。定期发布各项目的实质进展报告。周期不应超过三个月，最佳为每月发布一次。文档可由行政部来草拟（进展文档就应该傻瓜到行政人员都可以统计，客户也和行政人员水平差不多，如果行政人员看不懂项目到哪了，那么客户也差不多），成稿之后，交给研发中心各组件负责人、各项目经理签字，在公司内局部发布。

4、项目经理，应定期撰写客户对项目进展的要求及评价报告，此报告应站在客户的角度撰写。在公司内局部发布，以保持各部门对客户态度的准确把握。

5、研发工作量化管理制度。较复杂，另文再详述。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号