我们的管理：产品经理与程序员协作

今天CTO顾问咨询团发了一个问题，是关于产品经理频繁改版 VS 程序员的事。那我就来以实践经历说说我们是怎么协调产品经理和程序员。


一、导向一致


协调的关键在于在大底线大导向大原则方面要一致。在一个层面一个角度上说话才能说到一起共同促进，否则各说各有理就没法走下去了。


我们的产品设计导向原则是：
1、功能的增加一定是为企业经营增值，把什么平衡制衡、风险、管控、成本先放放


2、一定要聚焦企业核心价值链，不搞边缘部门边缘人的边缘流程


3、场景化。也就是说你描述一项功能需求，一定要明确说明是什么样的企业（人员规模/营收规模/企业性质/地域），什么部门的什么岗位的什么流程的什么环节，目前面临什么业务问题，先不说软件缺陷先说业务问题，说完业务问题再提业务解决方案，然后再提IT改进解决方案。需要业务和IT一起并行改进


4、最简化、迭代改进。聚焦核心问题，最简化解决核心问题，周边需求先放放，不要太追求体系化，否则拔出萝卜带出泥一整就是大解决方案包，这样要解决一个核心问题就太复杂了。先把七寸打了


5、数据统计论证。说要增加一个功能需求，要给出实际客户统计。我们有需求管理系统、BUG管理系统，这两个系统可以客户、各个部门员工、渠道合作伙伴都可以登记需求和BUG。我们的系统也有业务使用日志收集引擎，自动记录用户日常使用习惯，并且这些日志都通过我们服务器后台的同步软件传输到我们的运维服务中心，我们每个季度会根据这些数据自动出每个客户的应用质量体检报告。这些都是数据。我们有这些数据来支撑一个需求是普遍需求还是个性化需求，需求的紧急重要程度如何。不能产品经理靠在一线的客户交流来判定客户是否需要。这个原则是和程序员同思维很重要的基础，大家看到数据就都心服口服了。


我们的技术设计导向原则是：
1、分离式、自封闭模块化。也就是说我们的每个功能每个代码层都能部署到不同的服务器上。功能和功能之间的关联（UI URL调用关联/业务逻辑接口关联/数据关联）都通过ESB中央企业服务总线来统一规格集中管理，不能形成直接互相调用，否则就成蜘蛛网了


2、低成本高效率高质量支撑产品实现。我们的导向是防止过度设计。由于我们有分离式、自封闭模块化、ESB中央服务总线的保证，所以在扩展性和管理性上还不错，所以不担心会出现临时方案的风险。所以有导向原则，就不会过度设计也不会很临时拼凑。


二、协作流程整合


我们的产品规划是三个版本持续滚动：现在正在开发的、下一个版本即将要开发的、下下个版本想要瞭望的。


我们是每两个月开一次产品规划讨论会。产品规划讨论会是由产品决策委员会负责。产品决策委员会是个跨部门跨层级的组织，有产品经理，有技术架构，有市场营销，有实施服务，有运维客服。能进入产品决策委员会的一般都是各条业务线的一线实干专家和各业务线的决策领导人。产品决策委员会CEO和COO都会参加，由各线产品经理进行汇报。


我们有专门的技术架构部门，我们也有每两个月开一次技术规划讨论会，就是根据产品经理的产品规划输出然后做技术架构的输入。与会者有产品经理、技术架构人员、测试经理（关系到测试）、实施服务（关系到安装部署配置的门槛）、运维支持（关系到问题查找/更新升级）。


所以经过这两个规划委员会，我们的产品和技术就走到了一起，这是顶层的设计。


我们的产品研发是预研制度。有专门的创新研发中心负责原型开发。从产品经理构思设计到最后真正产品，是一条非常长的路。先开发原型，然后在合作客户中做试点运行，必须东西南北各找一家，而且大中小客户各不同。经过这样的原型开发和试点改进才能决定是否可以进行专门立项做正式的新产品研发。不少原型产品做了几年都没能立项做正式新产品。


在开发原型的时候，技术架构人员同时也在做架构设计、技术预研攻克、技术原型代码。


等新产品正式开发时，技术难关已经都过了都验证了，这样新产品研发的风险就小很多了。中间出现小的技术风险，通过每周PM汇报会来暴露风险申请技术人员整合支援攻克，都有明确的流程，如果是紧急的技术异常问题会直接通报总监进行协调。