转载

谈产品规划和发展思路03(1.2)

今天是新年第一天上班，再思考下我们产品规划方面的事情，在12月写过一篇产品规划思路的文章，特别提到从19年开始可以看到的企业中台和DevOps建设提速，包括传统架构朝微服务架构转型提速。而对于我们的整个偏平台的产品体系，其中的微服务架构咨询规划，研发过程支撑，DevOps支撑平台和API网关，这些刚好形成一个完整的围绕中台建设的支撑能力平台的整体。有了这个基础能力建设，企业可以更加方便的进行上层各个中台微服务模块的建设。而在这个推进过程中，本身又存在两种策略。

其一：强规划咨询方式+平台+实施落地

其二：弱咨询，仅仅建设实施DevOps支撑平台+API网关能力开放体系

在这两种发展思路里面，实际上我更偏向于第二种弱咨询的方式，因为这种方式可以更好的按产品化的思路推进，同时又可以最大限度的控制主团队规模，要明白团队规模的控制本身就是最好的一种利润最大化又抵御风险的方式。

但是按现在大部分企业的信息化建设水平来说，仍然是相当的落后，信息化已有的积累很弱，本身传统IT架构都还没有实施好更谈不上转型。即使是转型，本身对新业务，新技术的思考和理解也存在很大的偏差。也就是说，没有很强的规划咨询，包括对企业研发文化的重塑，你的平台建设很难在企业真正落地和推广。

因此实际上更好的思路在前期仍然是咨询规划和强实施切入，然后对这部分内容进一步的产品化和服务化。要意识到 软件可以产品化，那么咨询规划本身也可以产品化和服务化 。

产品，项目和现金流

回顾下我们整个19年的产品规划和实际落地情况来看，实际上真正落地的在60%左右，这个效果感觉还算不错，不错的原因是在利用团队资源空闲的时间来做了这个事情，最大限度控制了成本。

一说到产品规划，绕不开的就是产品前期研发资源投入和成本的问题，每次做产品规划我们都会做SWOT分析，都会做ROI测算，但是规划完成的产品无法真正卖出去，没有孵化成功的情况也是经常的。一个产品研发完成没有市场，卖不出去，不能形成收益回补完成自我造血功能，那么产品夭折是迟早的事情。

原来我们也会谈基于项目来孵化产品，这种方式最好的思路就是不需要单独的产品研发成本投入，成本费用包括在了项目中，但是缺点也很明显，项目明显带了客户的定制化，导致有时候抽象和剥离标准产品变得很困难，或者说根本就无法通过项目的产出直接形成一个我们理想的标准化产品。

对于软件企业来说，这一两年日子并不太好过，相信2020年也会是苦日子，在这种场景下往往生存下去，活下来才是第一位的。因此现金流至关重要，产品能够卖出去形成稳定持续盈利至关重要，你所有的产品规划仍然必须围绕企业经营来展开。

因此项目是否一定能产品化不是最重要的，项目能否持续并稳定盈利才是最重要的。

那么在产品规划上面，我们需要考虑两点

其一是产品最小化迭代完成自我造血能力 ：一个产品如果不能通过最小化的投入来完成面向客户的迭代版本并实现自我造血能力，那么这个产品在当前的形势下就不是一个好的产品。我们在产品规划上面可以试错，但是这个代价必须可控，我们的退出机制必须要完善。

其二是产品整个研发周期要匹配市场机会来敏捷响应和投入 ：比如当前某一个产品我们分析有一定的市场需求和机会，那么我们是先提前全部投入将这个产品全部研发出来呢？还是实际上我们会先形成各种可组装的半成品等待机会出现？要知道一个市场需求的真正落地本身也有一个周期，而我们本身的产品研发投入也完全可以更加灵活的去匹配这个周期，以控制风险。

异地多团队协同研发模式的完善

最近几年大家看到比较多的就是一线城市的软件企业，很大研发超类似武汉，西安，成都等城市的转移，分别在这些地方建立研发中心或者研究院。一线城市的研发人力成本问题当前已经严重影响到软件企业本身的经营乃至生存，战略性的转移也势在必行。

而这种转移带来的一定就是跨地域的多团队研发协同，这种协同和当前主流的微服务架构，组件化和模块化拆分本身也是相匹配的，同时也和我们推广的DevOps平台匹配的。异地协同必须有相应的组织，架构，团队上面的转变，也一定会需要研发支撑过程和工具上面的转变。

而我们说的支撑包括了研发过程管理，持续集成和交付，测试和环境管理多方面，同时这些支撑能力完全可以构建在公有云平台上来完成。也就是说异地团队来说，团队唯一需要的就是一个办公场所和个人的研发笔记本电脑即可以完成异地开发协同工作，人究竟在哪里已经不重要。

在2020年我们规划还是要进一步完善异地开发团队构建和协同上的实践，这个实践刚好也是我们对微服务架构，对DevOps支撑过程的一次全面自我实践。

原文 http://blog.sina.com.cn/s/blog_493a84550102z6gc.html

正文到此结束