【引言】

小公司研发人员就那么十几个，日积月累几年下来在研的、维护的项目可能会有十几个，虽然业务比较单一，但是架不住产品型号繁多，各种事务真实剪不断、理还乱。按照产品来划分项目吧，实际上几乎所有人都需要参加所有的项目，强行让员工专职负责一个项目更不现实。可是不推进项目化管理吧，整个研发的效率越来越低，大家天天忙得要死，什么996、007，12x12玩过，老板累、员工累，但是产品上线比生孩子还难。

【正文】

本文所指的小公司并不是刚刚创业的小型公司，创业型的小公司，组织结构比较简单，所有的管理和服务的角色老板一个人都包圆了，由于专注，效率也很高。本文所指的小公司是指度过了创业期，进入成长期的公司，公司有一定的规模，甚至可能员工的数量已经达到百人的规模（研发人员一般不会太多，加上测试二三十个左右），职能分工以初见模型。随着公司规模的扩大，管理层开始发现创业时自己和员工如臂指使班的默契和效率没有了，混乱和低效率与日俱增。虽然能够支撑当前的业务规模，但是想再上一个台阶非常困难。公司战略规划执行起来，总是有一种沼泽行军的感觉。

企业进入了该认认真真谈谈管理的阶段。并不是说以前没有管理，之前的管理多数情况属于经验式管理，属于见招拆招式的管理。这里所说的是科学管理，是经过精心设计的管理。既然是设计，就必须首先进行架构设计。

本文重点谈一下小公司的项目管理，提供一些可供借鉴的框架/架构，将公司的项目管理从经验式逐步迁移至科学的管理。搞产品设计的人都清楚产品框架也就是架构，对于产品的重要性。技术需要框架，管理同样需要框架，甚至有学者提出来企业应该设置“企业架构设计师”这样的职位，可是对于小公司恐怕只有老板亲自出马了。管理架构的好处是：1）降低信息处理的维度；2）统摄全局，实现有序分工；3）易于传播，统一工作流程；4）符合渐进明细处理复杂事务的原则。

项目是组织中临时的一项“工作”，项目本身也是一个组织（项目团队），另外项目也是一个系统（包括其所处的环境系统），项目无法脱离它所在的环境而单独存在。对于成长型的公司，我们需要先理顺项目所处的大环境，才能设计出符合实际的项目管理框架。这些环境包括：业务分工架构、研发流程架构、技术管理架构、研发组织架构，最后我们给出一种项目管理架构——研发事务看板。

一、业务分工架构

公司的成长过程必然伴随着分工的加剧，分工是为了提高应对工作的专业性和效率。但是对于客户来讲，它要的是作为整体的结果，所以分工之后必须进行整合才能为客户提供有价值的产品。分工越多，整合越困难，管理在某种程度上就是在平衡分工和整合之间的关系。

成长型公司由于管理层架构设计（现在流行叫顶层设计）的意识不强，被动反应式分工现象普遍存在。通俗一点说就是干到哪，想到哪！这非常类似生活中无计划的购物，需要什么了就买什么，时间久了，发现屋子里面堆满了需要的和不需要的商品，有的用一次就没用了。似乎每一个决策都是正确的，但是所有正确的单次决策，一定不会得到一个正确的全局性决策。这是系统的普遍规律决定，一个和谐完美的系统，一定是多个组成部分之间相互妥协之后的结果。

为了防止被动反应式分工的发生，需要在分析公司核心业务流程的基础上设计公司的业务分工架构。当公司在发展中遇到新的工作（内部和外部）需要处理时，首先对照业务分工架构进行安排，并仔细衡量增加业务职能和人员的必要性。当然架构并不是一成不变的，必要时可以进行更新。但无论如何，它为组织的发展提供了框架和指南，最重要的是可以让公司员工从总体上了解公司是如何处理业务分工的。这一点之所以重要，是因为公司在成长的过程中必然会招聘大量的员工，而这些员工头脑中根深蒂固的是他们原来公司的工作方式，在没有统一指导的情况下，每个人都会根据自己的经验来决定工作该如何做，这加剧了管理的混乱和冲突。

图1 业务分工架构

图1是作者为一家100人左右的成长型科技公司设计的业务分工架构，简称MSVC架构。其中：M-Marketing System，市场体系；S-Service System，服务体系；V-Sales System销售体系；C-Creative System，创新体系。

市场体系负责产品规划、品牌形象、服务平台建设、商业分析、产品行销培训等工作。

服务体系负责解决客户售前、售中、售后问题，提供客户运维技术培训，支持市场现场活动，发起完善产品体验的倡议，另外HR被定义为服务于公司内部其它部门的部门。

销售体系用V表示，而不是用S代表，有两个考虑：1）销售是直接将产品变成利润的职能，即实现了产品的价值，所以强调利润价值导向，销售不是为了把产品卖出去，而是为了实现价值；2）服务已经占用了一个S，用V便于区分。另外销售还要担负发现市场机会、跟踪客户、处理客户关系、回款等工作。

创新体系负责将市场机会转化成产品、服务能力和解决方案，并保证其质量，其中外协生产部分也是划归创新体系。

创新体系负责通过项目的方式创造价值，销售实现价值和发现价值机会，服务保证价值的顺利转移，市场对创新、销售和服务进行统筹规划和指导。这个架构并不是凭空想象出来的，而是在分析总结公司当前业务运行情况，抽象提炼出来的。另外这个架构又不是现实的复制，而是升华。这些工作有些是现在正在做的，有些是管理层希望做的，通过这个架构进行了整合，明确了公司业务运转的模式，为今后的业务分工提供了统一指导。

二、研发流程架构

公司的业务分工架构统一了全公司的分工配合问题，接下来我们谈一谈如何统一产品研发管理步骤，也就是MSVC中的“C”，因为“C”是本文要讨论的重点。要建设研发体系，首先需要做的就是梳理最大的研发流程，大部分情况下我们称其为“产品/项目 生命周期”，如图2所示。

图2 研发流程架构

产品/项目生命周期明确了完成产品或项目需要经历的主要阶段，以及他们的先后顺序。它的功效在于统一了研发人员的行动步骤，为工作分工和协作打下了基础。一般意义上产品管理和项目管理侧重点是不同的。产品管理侧重产品的定义，即“产品应该是什么样子（需求）和为什么做这个产品（市场）”，另外还要保证产品从定义到退出市场整个生命周期内的市场适用性（即能卖的出去且盈利）。而项目管理侧重于如何将一个特定的产品创造出来，即“如何干”，产品做出来项目就结束了，而产品管理未必会结束。产品生命周期中可能会经历多个项目生命周期来完成包括创造、维护、升级等工作。

对于规范成熟的公司来讲，产品管理和项目管理是两条并行的管理线，他们在特定的时间点重合与分离。

对于成长型公司来说产品管理线和项目管理线实际上是由同一部分人完成的，也就在事实上融合成为一个整体。图2实际上就是将产品管理和项目管理融合成为一个统一的“研发流程”。

如果单纯从项目的角度来看待产品管理也是可以自洽的，即把产品管理看作是项目集，把单个项目看作是项目集的组成部分，这样就可以用统一视角来看待研发工作，减少概念的混乱。

基于小公司的产品类型的单一性（品种少型号多），根据图2的架构，我们把整个研发部的项目看作一个项目集，可以简单理解为一个大项目，这样就避免了因为强行划分项目导致人员管理分工的困难。在实际操作中，小公司中的项目论证和论证启动阶段的工作相对比较简单，通常是少数管理层来完成，这部分不是管理活动的重点作用对象。研发管理的重点是规划、实施、交付、收尾，以及生产和维护。

当然图2所示的流程顺序在实际工作中并不一定是按照严格的顺序方式来执行，针对不同的产品、不同的环境可能出现，交叠、往复、循环等各种模式。如果某种模式可以很好地解决实际问题，那种模式就可以称作是“生命周期模型”。例如常见的生命周期模型有：瀑布式、迭代式、增量式和敏捷适应式等。

三、技术管理架构

我们用把整个研发部在研和在维护的项目看作项目集的方式解决了统一管理的问题，接下来还要解决的是从技术上怎么协调诸多产品型号、不同产品层次、多种产品组合的问题。不解决这个问题，管理就失去了作用的对象，因为管理要管的工作就是技术工作，要协调的工作也是这些技术工作。

基于货架的产品交付框架可以很好的解决多产品、多型号、多层次交付的问题，如图3 所示。

图3 技术管理架构

凡是摆在货架上的产品（可能是中间产品）都是经过验证的，也就是说在自己所属领域是可以交付给客户（可能是内部客户）的产品。未经验证，无法保证质量的产品不允许放在货架上。当客户需要某种产品时只需要在货架上寻找适合自己的产品，而不需要直接跟产品提供者打交道。

产品货架上的产品根据其适用的范围，需要进行纵向和横向的分类，例如图3中自下而上将公司的产品分为：软件平台和硬件平台，整机，解决方案三个层次。纵向上越往下通用性越强，越往上定制程度越强。横向还可以根据型号、版本、客户进行更加具体的分类。

解决方案层级，基本上没有研发创造活动，它主要是根据客户（通常是需要综合服务的客户）的需求，从自己货架上挑选产品，形成一个满足特定客户需求的综合解决方案，并进行部署和调试。解决方案层面根据底层产品提供的特性解决接口兼容问题，如果需要调整底层的特性，则由整机层和平台层负责。

四、研发组织架构

成长型公司在人力组织上面临的最大的现实就是“人少活多”。如果按照一般意义上的产品或项目来组织人员工作，将会使团队分割成一个个碎片，加之人手本就不足，个个都身兼数职，更不适宜划分项目组。

当然最好的方式是扩大研发队伍，加强专业化程度，但是这需要综合衡量成本和风险。除了成本的增加，在没有形成科学规范的项目管理体系之前，骤然增加大量的研发人员，会导致管理上的混乱。

稳妥的做法是基于现有人力，梳理研发流程，规范研发管理，先提高效率，培养队伍，为未来的扩大建立基础。总体战略是“先精兵强将，再兵多将广“。

图4 研发组织架构

图4中所设计的研发组织架构，是基于组织目前的分工设计的，其中虚线框是未来希望增加的部门，总体来说还是一种职能式的组织结构。

现实情况是，研发人员的总数不到30人，加上硬件的研发工作相对独立，需要协调的人员主要是软件和测试，人数不超过20人。

主要设计思路是，将整个研发部的所有在研项目和在维护项目当作一个项目集来看待，研发部要能够持续的交付价值（产品和服务）给客户，所有研发人员应当象生产线工人一样围绕产品交付价值流（隐形的生产线）工作，所有的研发工作，包括产品需求、缺陷、基础平台建设、客户反馈、风险应对全部当作研发事务（待办事项）来处理，整个研发部由一位研发副总统辖，目的是打造一部“事务“加工机，按照商定好的优先级处理规则”加工“所有的研发事务。

五、研发事务看板架构

价值流的具体实现方式，采用看板方法，这是一种脱胎于精益管理的敏捷实践方法，结合公司的情况，不是以产品和团队为单位设置看板，而是整个研发部设置一个总的研发事务看板，如图5所示。

图5 研发事务看板

研发事务看板的基本思想如下：

1）整个研发部设置一个总得“研发事务看板”，所有需要研发处理的“事务”都必须纳入看板才会被处理。

2）研发事务的主要来源有：研发需求、测试部发现的缺陷，客户提出的要求和反馈的问题、风险应对活动、技术试验活动、环境搭建活动、以及来自高层的紧急任务。

3）研发事务看板由研发部负责维护，还可以设置团队或小组级别的看板。事务看板层面管理事务（backlog又称待办事项），而团队小组级别管理任务（task）,任务是对事务的进一步分解，由事务负责人根据需要自行分解。

4）要建立统一的事务清单（可依托JIRA建立数据库），一项事务需要描述一些必要的信息，例如：标题，内容描述、优先级、工作规模、事务类型、所属项目或产品、来源、状态信息、必要备注信息等内容。凡是要研发部完成的工作都需要先进入研发事务清单，并且设定优先级之后方可进入研发事务看板。

5）研发部负责人根据优先级定期（例如每周）选择需要在本周期内完成的研发事务，纳入看板进行处理。事务需要在公司层面进行管理和存档，任务则有团队小组负责无需存档。

6）研发事务看板初期最好采用高接触低技术的方式管理，例如在研发区专门开辟一面墙当作看板，待养成工作习惯之后再采用电子化的方式管理。

以上是研发事务看板的不同于一般看板方法的要点，当然看板的基本原则和方法还是需要遵守的，例如团队还需要就以下几个方面达成一致意见，并形成运行规范：

1）迭代周期长度；

2）计划会议的规则、评审会议的规则以及回顾会议的规则；

3）设定优先级的规则；

4）允许的WIP的数量是多少，工作流转的规则；

5）度量的方法、沟通的方法、事务分类的方法、工作估算的方法；

6）数据库字段、编写不同类型事务的模板、看板泳道的设定，紧急事务的处理规则；

7）信息系统和手工看板的结合方法等等。

在对研发事务看板核心要件讨论清楚之后，就可以与现有流程并行运行一段时间。这是因为看板需要成熟的时间，另外团队也需要培训和学习。待时机成熟之后，整个研发团队就可以切换到看板模式运转。

研发事务看板并非只是权宜之计，它具有扩展性，未来随着产品线和人员的增加，可以根据产品线进行扩展，也可以根据部门扩展。各产品线的看板还可汇总信息到公司层级的看板，当然公司层级看板的内容是一个个的项目，不是具体的项目事务。

【小结】

一个企业是一个系统、一个项目也是一个系统，对于项目而言，企业就是它的超系统。一个系统有三个主要部分：组分、结构和组分的相互作用。一个系统之所以成为一个系统，不是因为组分的不同，而是因为结构的不同。组分通过结构相互作用，最终使得系统表现出与众不同的特性。对于管理来讲，结构是统摄全局的总的抓手，结构顺则管理顺，结构乱则管理乱，梳理清楚管理的结构才能排兵布阵，组织战斗，实现战略。

参考文献

[1] PMI. The Standard for Program Management 4th. 美国项目管理协会，2017

[2] (美)理查德L达夫特，组织理论与设计（第12版）. 清华大学出版社，2017

[3] 周辉，产品研发管理，电子工业出版社，2014

[4] (美)David J. Anderson，看板方法，科技企业渐进变革成功之道，华中科技大学出版社，2017