如何落实研发管理以业务为导向？

上周发生了很多事情：来自其他中心和部门的同事通过各种渠道，反馈了他们对研发的不满和期许；公司请来业内一家著名公司的研发总监，和我们探讨研发管理经验--当然，对我们来说，基本上是请教；部门内部也有一些情况，重要产品的研发组长觉得身心俱疲，需要向他提供更多的指导和帮助。

这些情况都和一件事有关，那就是公司的产品研发管理方式。要想看清公司的产品研发方式，必须把握组织结构和产品研发过程。

现有产品研发管理情况和问题分析：

静态上看产品、研发和运营三个中心是独立的组织，产品的研发依赖三个中心的频繁沟通和紧密配合；动态看是通过项目管理把三个中心的人员组织起来，共同完成产品研发的小步快走。
三个中心互相独立的好处很明显，产品、研发、运营是公司的三架马车，通过紧密合作共同打造产品。但随着公司产品线和各个公司人员的扩充，沟通的代价也变得越来越大，而做为产品、运营需求实现者的研发部门，已经处于疲于奔命还无法满足方方面面众多需求的境地。
基于项目组织产品研发好处也很明显，可以很灵活，快速的把交付的软件投入市场，由项目的逐步实施来形成产品。这个思路很美好，也没有太大的前期资金投入，但是这样做出来的软件，在产品架构上存在先天性的不足。

从管理上看，产品、研发、运营各个部门独立，很难形成共同目标--这是造成沟通代价的根本原因。由于研发部门基本处在执行层面，开发人员性格又都比较内向，在现有的研发过程中，完全处于弱势地位。而研发目前的基于质量的考核，对开发人员的创造力，客观上是有很强的抑制作用的。而做为服务器的开发人员，除了公司项目的开发任务，还有来自运营部门的运营问题跟踪、运营短任务等工作，加上长期以来的人员过度复用欠下的技术债，问题要更多一些。

从产品开发过程上看，本身应该包含产品，平台和技术三个层面。每个层面都涉及到规划和开发两个重要内容。首先是产品应该依托于一个平台，一个产品开发平台可以开发同一个产品线下的多个产品；其次产品和平台都需要涉及到技术研究和解决，这些都会作为技术规划的输入。对于产品开发走向产品，平台和技术三个层面后才能够实现高度灵活的配置和复用，真正在规划阶段就解决产品开发的风险问题，缩短产品研发生命周期。

从技术上看，把项目当做产品来做，必然导致功能模块很难复用，系统中有大量功能类似的代码。目前影响域很难评估，这也是一个主要原因。

几条落实建议：

1. 落实产品+运营+研发的产品开发团队： 由这个团队来完成项目开发、运营问题跟踪和运营短任务开发的工作；
2. 固定重要产品的研发团队：就服务器端最重要的产品开看，第一步是要补充和培养新人，才有可能在下个季度缓解现有疲于奔命的情况；
3. 落实激励制度： 目前的市场，给好的研发人员的待遇是很高的。我们至少应该给予他们同档次的待遇，才能保证不发生我们不想看到的离职情况；
4. 产品线团队坐到一起：就算是第一点的补充吧，简单易行。方便大家的沟通交流。