产品和团队管理(10.7)

今天是长假最后一天，早上起床后依旧是到奥森公园南园+北园完成10公里，但是配速特意降低了很多，虽然最近几天北京早上的天气已经明显感觉到冷，但是跑起来后整体感觉还是非常舒畅。

最近有时间的时候就思考下产品研发，项目和团队管理方面的事情，现在深感要再研发一个成功的产品并迅速的能够拓展和占领市场是相对困难的事情。我一直在思考这里面的原因究竟在哪里？除了需要前期的研发费用和资源投入外，更加重要的就是我们长久以来的研发和项目实践究竟积累和沉淀下来多少内容？即不管是产品还是平台或技术，包括知识库，这么多年真正沉淀下来的并不多。这就直接导致了你现在的研发往往并不比从头开始的团队强多少。这是项目型公司或团队都存在的一个关键问题，特别是人员流动率还很大的情况下，一个核心人员的流动往往就导致一个项目或产品停滞也是常事。

基于以上问题，实际上需要做两个方面的重点改进

1. 加强知识库建设，特别是技术组件，技术点知识库的建设，而不仅仅关注产品

2. 加强培训机制的建设而不仅仅是降低的培训流程或培训课件

要意识即使一个产品或项目消亡，但是产品或项目中应用到的关键技术，技术组件仍然是可复用的。因此做好技术知识库的建设就尤为重要。这个本身存在的一个拆分的过程，即大粒度的产品不容易复用，但是细粒度的技术点往往一定是容易复用的。举个简单的例子来说，我们在很多项目或产品里面都用到消息中间件，那么对于消息中间件这个技术点就应该是完整剥离的知识库，包括具体的学习文档，验证过程，实践案例等。以方面他人快速的理解和掌握。

其次就是培训，培训不应该再是简单的机械化的培训计划，培训流程或培训课件这些基础内容。更加重要的是培训机制的建立。即我们的整个培训机制是逐层往下的，是可以传承的，是以师带徒模式的。每个人都在整个培训架构中承上启下，既是老师又是学徒，同时需要做好这两种角色。同时培训应该理论和实践结合，培训是问题驱动的，但是最终又高于单一的问题解决。

经过这么多年，我们的产品技术架构，开发模式，开发框架或语言基本都经常在变化，我们耗费了大量的时间在这些方面，这对于一个产品或技术驱动的团队是必须的，但是对于一个项目型的团队往往则是过重的，因为对于一个外部定制化项目来说，最重要的是客户需求的满足，而不是技术架构如何先进。其次，你可能还会发现一个问题，用了更新的技术架构后，反而对开发人员的技能要求更高的，而这点本身又是一个大问题，直接导致了整体项目成本的增加。

一个好的架构其技术复杂性一定是隐含在技术内部的，即内部可能很复杂，但是对于开发人员来说整个开发过程应该更加简单，开发效率应该更高。

前面一直在谈我们的API网关的研发思路，实际上也是同样的道理，在进行大的组件模块拆分后，真正的技术复杂度应该是在网关引擎里面，而其它子系统仅仅是一个管理系统而已。其次在拆分后形成松耦合的架构，对接口进行标准化定义，这样可以做到对于网关引擎本身也随时可以进一步替换为自研模块。

研发一个产品需要不断的研发资源投入，但是产品究竟有无市场却很难在一开始就看清楚，所以你可以看到很多走产品化路线的IT公司往往存活下来的并不多，反而是很多项目型公司能够生存下来。但是产品化公司一旦成功，那么带来的就是巨大的边际效益和强大的可复制性。

一个产品研发必须走迭代的思路，但是一定要注意的就是迭代版本一定不是内部版本，而是真正可以对外发布，可以开始使用的正式版本，越是新产品，越要重视对第一个迭代版本的研发和发布，第一个版本往往都无法给用户一个好的使用感受，那么后面也很难真正成功。

整个软件产品发展逐渐形成一个大趋势，就是不再是为最终的产品或系统付费，而是为服务付费，那么就一定需要考虑 产品本身如何服务化，服务本身如何产品化 方面的问题。软件即服务，这个说了这么多年的概念，逐渐又将变成一个主流，即用户最终需要的仅仅是提供服务的能力。