如何做好创业公司研发团队的项目管理？

1 前言

探讨创业公司中的软件研发项目管理问题：

大部创业公司的软件研发管理处于什么阶段？

如何改善软件研发过程和提高效率？

软件研发过程会涉及哪些工程理论和方法？

2 如何衡量软件研发团队所处的项目管理成熟度阶段？

2.1 项目管理成熟度衡量方法

目前成熟度模型总数超过30种，其中，以美国卡内基·梅隆大学软件工程研究所(SEI)提出的 CMM(Capability Maturity Model For Software)、著名项目管理专家 Harold Kerzner 博士提出的项目管理成熟度模型 K-PMMM、美国项目管理协会 PMI(Project Management Institute) 从组织面策定的 OPM3(Organizational Project Management Maturity Model) 和 PM solution 提出的项目管理成熟度模型 PMS-PMMM 等最为知名。

软件能力成熟度（CMM）是1987年美国软件工程研究所（SEI）首先提出的，该模型 CMM 侧重于软件开发过程的管理及工程能力的提高与评估，基于以往软件工程的经验教训，为软件开发选择过程改进战略提供了框架和指南。并将软件过程改进的进化步骤组织成5个成熟度等级，如表所示。

级别	级别数字	描述	备注
初始级	1	软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
已管理级	2	建立了基本的项目管理过程来跟踪费用、进度和软件的功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
已定义级	3	已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
量化管理级	4	分析软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理活动有一个作出结论的客观依据，能够在定量的范围内预测性能。
优化管理级	5	过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 有能力识别软件过程中的薄弱环节，并有足够的手段改进它们，防止缺陷的产生。

2.2 大部分创业公司所处的阶段

虽有存在不同衡量项目管理成熟度的方法，但总体来说，大部分创业公司处于“已管理级”，正在走向“已定义级”的过程中（处于CMM 5 级中的第 2 级，正在往第 3 级发展）。企业制定了部分规范、纪律，但未形成体系完善的标准，或者形成了一些标准规范，尚未完全落地。

2.3 我们为什么要在一个组织中推行标准流程，它有什么价值？

亚当斯密在《国富论》中提出“分工产生效能”，因此，一个组织期望提高整体效率，其内部也需要进行“精细化分工”，但是，精细化分工会带来不同分工角色之间的“复杂协作”，因此，组织需要一套解决协作问题的流程机制，这也是建立标准化流程的根本动机。

因为社会化大分工显著提高生产效能，同时也产生复杂协作需求，而提高这些复杂协作的效率需要科学的管理方法。1911年，“科学管理之父”泰勒发表《科学管理原理》，提出科学的分工管理方法。其方法演变为工业时代的流水线生产管理模式，经典代表是福特的汽车流水线生产模式。1913年，福特实现著名的流水线生产．第一条流水线使每辆T型汽车的组装时间由原来的12小时28分钟缩短至90分钟，生产效率提高了8倍。

对于创业公司来说，随着创业公司的逐步壮大，内部分工变得更精细，其软件研发过程也需要一套解决内部复杂协作的流程机制，也就是标准研发流程。

软件研发流程标准化，它通常包含两个方面：

1. 资源的集中管理和调度
2. 流程和管理标准化

它们为什么如此重要？

以春秋战国的秦国为例，它通过建立国家的集中管理和标准化，实现自身效能的明显提升，最终实现古代中国的统一。并且，在2000多年前的技术条件下，完成修建万里长城、灵渠、西安兵马俑等匪夷所思的世界级工程 ，这些事情即使放在今天的科技条件下，也都是非常有挑战的宏伟工程。

为什么秦国能在残酷和激烈的战国竞争中胜出？

• 周朝是一个由多个大小不等的分封诸侯国组成的弱集权国家。
• 早期的秦国内部就是一个缩小版的“周朝”，分封的对象是秦国内部的贵族。
• 重要的转折点——商鞅变法：中央集权、标准化、非人格化的行政体系（制度化）。
• 秦国自商鞅变法后，整个国家的效能显著领先于其他诸侯国。
• 除开秦国占据更好的地缘位置和其他因素外，秦国统一古代中国最重要的原因是“国家效能”（国家能力）超过其竞争对手。

历史纪要：战国时期，秦国的秦孝公嬴渠梁即位以后，决心图强改革，便下令招贤，商鞅自魏国入秦，并提出了废井田、重农桑、奖军功、实行统一度量和建立县制等一整套变法求新的发展策略。

2.4 软件研发项目管理方法的理论根据

项目管理方法	理论来源
瀑布流	瀑布模型是一个软件开发模式，于1970年被温斯顿·罗伊斯（Winston Royce）提出。其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
增量迭代（双周迭代）	Scrum（迭代式增量软件开发）源自日本的“丰田生产系统”（Toyota Production System）和美国空军的OODA循环理论，提出于 1993 年。引自《敏捷革命》（【美】杰夫·萨瑟兰，英文原版写于 2014 年）

项目管理方法	理论来源
项目管理体系和流派	国际上项目管理有很多不同的流派。 PMBOK 、 PRINCE2 和 IPMP 这三大流派基本上代表了目前世界上比较主流的三种项目管理文化，并且各自侧重点不同。其中，美国的 PMBOK 侧重“项目管理包括什么”，英国的PRINCE2侧重“项目管理如何做”，瑞士的 IPMP 侧重“项目经理的能力模型”。PMBOK 是 Project Management Body Of Knowledge 的缩写， 指项目管理知识体系的意思，具体是美国项目管理协会（PMI）对项目管理所需的知识、技能和工具进行的概括性描述。提出于 1970 年代。（大家常常提起的 PMP 证书就是由该机构颁发）PRINCE 是 PRoject IN Controlled Environment（受控环境下的项目管理）的简称，国际项目管理师认证，是英国商务部（OGC）1996年开始推广的项目管理体系。国际项目经理资质认证( International Project Manager Professional，简称 IPMP) ，是一个在瑞士注册的非赢利性组织。它的职能是成为项目管理国际化的主要促进者，创建于 1965 年。

2.5 SCRUM 的理论知识介绍

2.5.1 SCRUM 理论基础

Scrum 方法是目前全球最流行与最有效的敏捷项目管理理念与方法之一，是一种快速增量交付软件产品的能力，在构建产品过程中创建产品的内部团队并与客户高度协作。

Scrum的雏形是由日本的Takeuchi和Nonaka提出的。Jeff Sutherland在1993年将这种方法在Easel中进行了实践。Jeff Sutherland（《敏捷革命》作者）与 Ken Schwaber 在1996年 OOPSLA 会议上正式将其定义为Scrum 并向业界公布了 Scrum 开发过程。之后， Scrum 成为领先的敏捷开发方法。

Scrum是增量迭代的开发过程，整个开发周期由若干个小的迭代周期组成，每个小的迭代周期称为一个 Sprint ，每个 Sprint 的长度一般为1~4周。Sprint 有固定的周期——结束于固定的明确的日期，无论工作完成与否，从不延长。

准确地说，大部分创业公司使用的是 B 型 SCRUM （在迭代结束之前，规划好下一个迭代）：

2.5.2 实施 SCRUM 时的难点

在影响 Scrum 正常实施的众多因素中，对于在 Sprint 过程中加入超出团队消化能力的额外需求，它是 Scrum 的第一杀手。

Scrum团队必须对在一次Sprint中可以完成哪些任务、谁可以在正常的一周工作日内完成这些任务作出决定。有些使用 Scrum 的公司试图在 Sprint 中塞进更多的任务，这些任务超出了 Scrum 团队在额定时间内所能完成的工作量， 这就会导致团队自治的下降、过多的加班、较高的次品率、人员的损耗和跳槽等。

Cohn 和 Ford 认为，一个组织从计划驱动的传统模式向变化驱动的敏捷过程转变的过程中会产生很多问题。这主要是因为一个软件开发团队对敏捷方法实践有抵触或是过于狂热造成的。这个转变过程会影响到整个组织的结构、文化以及管理等诸多方面。无论是文化还是人的想法都是很难改变的，这也是为什么对于很多的组织来说，向敏捷方法的转变很难实现的原因所在。

（引自：[Moe N B，Dingsoyr T.Understanding self-organizing teamsin agile software development[C]//19th Australian Confer-ence on Software Engineering，2008:76-85.]()）

需要理性地面对“敏捷”，它对于不同的团队、不同的项目有着不同的意义，正如 IBM 公司 Rational 部门的总架构师 Per Kroll 所言:“敏捷在不同的项目中意味着不同的东西。对某一个项目作用巨大的敏捷，却不一定能对另一个项目起到同样的作用”。

2.5.3 各类敏捷研发模式和理论

2001年2月，敏捷方法的一些创始人在美国犹他州成立了 Agile 联盟，将轻载方法正式更名为 Agile 方法， Agile 有轻巧、机敏、活力的意思。

Agile方法没有一个明确的定义，其特点是对软件生产率的高度重视，主要适用于需求模糊或快速变化下的、小型项目组的研发。有人称，Agile方法是在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，笼统的讲，就是“刚刚好"（Just Enough），即开发中的活动及制品既不要太多也不要太少，在满足所需的软件质量要求的前提下，力求提高开发效率。

人们不可能在软件开发之前准确地把握当时的需求及其之后的走势，这一点已由 Peter Wegner 用数学的方法给出了严格的证明。设想有一个虚拟的“理想软件”，它是对用户的最大满足，并能随时间的推移和形势变化而与现实保持即时同步，那么软件需求实质上是对”理想软件”的粗略的外部描述。理论上来说，软件开发应是一个跟踪过程，只能通过软件开发过程的自适应性来逼近“理想软件”，不可能完全实现。

根据自动控制理论，自适应系统是一个强反馈系统。在软件开发中，需求的获取和分析、软件设计、编码等实质上均为前馈环节，真正的反馈环节应该是用户对可运行软件的使用、使用中与“理想软件”的比较判断及判断后与开发人员的信息交流。另外，控制理论还要求，反馈和前馈这一回路的响应速度应大于被跟踪(或被适应)的系统的变化速度，这就要求软件开发有快速的产出能力。

基于适应性特点，Agile方法通过快速、短迭代式的开发，不断产出和演化可运行软件，加强项目有关人员的信息交流等手段来提高反馈的速度、力度和准确性。在软件过程改进方面，Agile 方法通过对实际反馈信息的度量，根据用户满意度(时间和质量的权衡)进行微调，相当于缺陷驱动的改进方式。

软件开发中，人的因素是第一位的。人是过程的主体，而人的工作承受力是有限的，任何超出人正常承受力的过程必然导致过程结果的偏离，这一点在注重过程改进的方法中往往被忽视或低估。Agile方法认为，软件开发中的绝大部分是需要创造力的设计工作， 软件人员是创造性的工作者，有主观上做好工作的意愿，不同于大工业时代生产流水线上被动性的工人，因此，在管理理念上应注重领导和协作，而非命令和控制，充分发挥软件人员的能动性和创造力。

2.5.4 Agile 软件研发方法介绍

方法名	起源	特点	适用范围	备注
XP(Extreme Programming)	Kent Beck，1997	由Kent Beck提出，名称中Extreme的含义是将好的开发实践(Practices) 运用到极致。 XP最初实践于1997年Crysler公司 的C3项目(人员薪金管理)，采用Smalltalk语言开发。 交流(Communication)项目相关人员之间充分、多渠道(最好面对面)的沟通。 简化(Simplicity)在系统可运转的前提下，做最简洁的工作;在开发中不断优化设计，时刻保持代码简洁、无冗余。 反馈(Feedback)强调各种形式的反馈，如小交付、短迭代、先考虑测试再编码等。 胆识(Courage)面对压力做正确的判断并敢于付诸行动，如，敢于丢弃设计不良的代码，疲惫时立即休息等。 缺陷： XP中的文档问题 （几乎没有文档）。	适用于10人以下项目组、开发地点集中的场合。（封闭开发）
SCRUM 方法	由 Ken Schwaber 和 Jeff Sutherland 提出，1993	SCRUM将工业过程控制中的概念应用到软件开发中来，认为软件开发过程更多是经验性过程（Empirical Process），而不是确定性过程（Defined Process）。确定性过程是可明确描述的、可预测的过程，因而可重复 （Repeatable）执行并能产生预期的结果，并能通过科学理论对其最优化。 项目组由全职开发人员及与该交付产品有关的市场人员、销售人员、用户等组成。设以下小组： ・项目管理组。由产品经理领衔，包括总设计 师，各SCRUM小组组长，市场、销售的高级职员及典型用户等。 ・若干个SCRUM小组。各小组由组长（SCRUM Master）领衔。每个小组都是跨专业的（通常包括开发人员，质量控制人员或用户代表等），通常为 3~7人，以使小组内有充分的交流。 SCRUM在实践中大大提高了生产率（据软件生产率组织的Capers Jones称，可提高6倍）。	-
Crystal 方法系列	Alistir Cockburn，1980	应用于 IBM 项目中。 他认为不同的项目需采用不同的开发方法，并随着开发的进行应不断细调（On - the - Fly Turning），亦即连续不断的过程改进。 据此他提出了一系列方法（Crystal Clear、 Crystal Yellow、 Crystal Orange、Crystal Red等，名称借自于自然界中的晶体，有透明的、黄色的、橙色的等）作为基本参照和一些原则来指导方法的调整。 Ciystal方法系列的核心理念： 软件开发可视为创造和交流相协调的过程，其中人的因素是第一位的，软件开发的第一目标是交付有用的、可运行的软件，其次是保持开发工作的可延续性。	用在6人左右的项目 组（无下层小组），迭代周期应为2~3个月。 有下层小组则可达到 40 人以下。	多种模式并存
DSDM方法	1994	起源于英国，是一个工业联盟。由16家公司发起 （1994年）并组成，最初的目的是开发一种更好的面向领域的快速应用开发（RAD）方法，现在会员已超出英国（美国、印度、德国、法国等），应用范围也不再限于 IT 行业。由于有良好的组织基础，它在技术支持、培训认证、应用推广、研究改进等方面都远比其他 Agile 方法要完善的多。DSDM 适用于时间要求紧的项目。 DSDM的基本观点是，任何事情都不可能一次性 的圆满完成，应该用20%的时间完成80%的有用功 能，以适合商业目的为准。 MOSCOW （Must do， Should do， Could do， Won't do）优先级排序方法。
FDD（Feature Driven Development）	Jeff de Luca和Peter Coad，	是一个模型驱动、短迭代的开发方法，适用于变化周期短的业务应用开发。所谓的特征点（Feature）是一些用户眼中有用的小功能项，一个特征点能在两周或更短的时间内被实施，且产生可见的、能运行的代码。
ASD方法	Jim Highsmith	基于复杂自适应系统理论 (Complex Adaptive System)，旨在通过提高组织的自适应力以应对 Internet 时代下极度变化、难以预测的快速软件开发要求。
... ...

2.5.5 Agile 方法（敏捷）与 CMM（传统）的比较

CMM 专家 Mark Paulk 认为 ， CMM 更注重管理问题（组织过程的有效性和过程的系统化改进）， Agile 更注重技术和效率；CMM 提供了一个高度抽象的框架，有广泛的适用范围，Agile 适用于小组织和需求不定、有用户紧密参与的情况，在高可靠性要求和大型项目组，或虚拟项目组中不宜采用。

XP 专家 Ron Jeffries 认为，XP 方法从某种意义上来说是 CMM2 到 5 级的一个垂直切片（满足了 CMM2 到 5 级中的部分 KPA 目标要求），若将之应用于整个组织则还须更多的度量工作，但他同时指出，XP 方法中更多的度量不是不可以做，而是要根据投入回报分析决定是否有必要。

Scrum 的 Jeff Sutherland，支持敏捷模式，认为 CMM 模式过于重并且效率低下。

综上所述，软件研发过程不同于工业生产的流水线，不具有工业生产的确定性过程（Defined Process） ，追求完全的可控制性会比较难。

3 项目管理在推广过程中遇到的一些常见难题

3.1 项目经理的有责无权问题

为什么是这样？

只有 CEO 或者管理职责上的总负责人拥有所有的管理权力，但是，他们不可能每个项目都这样去管理。因此，项目管理角色被单独划分出来，代替他们去管理项目，导致了有权无责的现状。

因此，有责无权是项目管理的常态，正因如此，在一个制度、组织流程健全的体系下，项目经理会更容易做事。而在创业公司中实施项目管理工作，会显得更困难。

3.2 创业公司所处阶段面临的常见项目管理发展问题

• 在独立项目执行的模式下，各个团队的项目管理方法、方式呈现多样化。
• 项目管理制度虽然被建立起来了，但是完善程度比较低，存在比较多的流程空白和模糊地带。
• 该制度缺乏合适的执行主体等。

项目管理与组织的关系：

4. 项目管理所需要的上层组织与文化环境

在一个既有做事方法（可能是非标准化的做事方式）的组织中，推广标准化无异议一次“文化侵略”，容易引起原来群体的抵触，该问题需要公司高层的支持和理解，同时，也需要耐心等待规范的逐步落地。

泰勒在各个公司或者工厂中推广管理流程时，提到流程的落地难题。

企业的变革条件：

1 企业领导充分理解并相信科学管理的基本原则。

2 密切关注采取这种变革所涉及的一切因素，特别不能急于求成。

企业的变革应该遵循循序渐进的展开，最初影响到员工的少数变革，只有当 1/4、1/3 的员工转入新的方法而且充分相信运用后，再进行下一步的变革。

——《科学管理原理》（弗雷德里克·温斯洛·泰勒，1911出版，科学管理学之父）

关键概念在于“门槛”：一个人会看到多少人或多大比例的人采取一个决定时，才会采取相同决定；这一点是此人净效益超过净成本的门槛。一个人决定采取一项行为的成本效益比较部分取决于有多少人采取相同的决定。

以参加抗议为例，一个人参加抗议的成本会因为抗议规模的扩大而逐步降低，因为参加的人愈多，被逮捕的机会愈小。不同的人在决定加入抗议之前要求不同的安全感，因此在抗议中所能获得的利益也不一样。描述这个人人不同的关键概念就是每个人加入行动的不同“门槛”。

——《镶嵌：社会网与经济行动》（作者，马克 格兰诺维特，美国斯坦福大学教授，知名社会学家，主要研究社交网络和经济社会学）

5 项目管理落地后可能负面影响

5.1 因流程繁琐而效率变低、僵化

“先僵化、后优化、再固化。”

——华为任正非

1. 推行新流程和标准的初期，必然会遇到一定的阻力。
2. 在新老流程的过渡阶段，整体效率甚至会低于老流程。
3. 新流程的落地是一个渐进的过程，甚至是一个反复的过程。

推行新的流程、标准相当于推广新的做事方式、文化，因为它改变了既有的做事习惯和方式，需要同学们在观念上的改变，因此，它的落地需要一定的时间，也会遇到一些阻力和问题，推行新标准的同学也容易成为众之所矢。

6 部分参考资料

弗雷德里克·泰勒. 《科学管理原理》[J]. 当代电力文化, 2014, 04(No.010):98-98.

布鲁克斯, F.P.). 人月神话:英文[M]. 人民邮电出版社, 2010.

马克・格兰诺维特. 镶嵌:社会网与经济行动[M]. 社会科学文献出版社, 2015.

Schwaber K， Sutherland J. The scrum guide[J]. Scrum Alliance， 2011， 21(19): 1.

张敬周，钱乐秋，朱三元.Agile方法研究综述[J].计算机应用与软件，2002(06):1-9+54.

张智海，周国祥.Scrum方法的研究与分析[J].合肥工业大学学报(自然科学版)，2010，33(02):197-200.

方德英. IT项目风险管理理论与方法研究[D].天津大学，2003.

Pooley R , Wilcox P . The Capability Maturity Model for Software[J]. Applying UML, 2004, 2(4):151-159.

Fukuyama F. Political order and political decay: From the industrial revolution to the globalization of democracy[M]. Macmillan, 2014.

作者：

徐汉彬，现就职于一家C轮的创业公司从事研发和管理工作，曾就职于腾讯和阿里巴巴多年，有创业经历，负责过日请求10亿+系统从零到一的架构和研发工作。拥有十年以上的技术研发、管理经验，在海量服务架构、推荐系统、机器学习等方面有一定的实践积累和经验。

​