「人人都是产品经理」To B 行业的 MVP：定制开发( 二 )

上面说的处境问题只是我临时想到的，有时间我会详细总结。在这里说的意思是：面对定制开发需求，产品经理只能接坑，不能决定“不做什么”（总监级、Boss 级除外）。能随时随地与客户（需求方）面对面交流是产品经理所能奢求的最大福分。
既然暴风雨总要来临，那就说一下我们力所能及可以掌控的事情：
1. 是否真正理解客户提出的（新）需求
既然是定制开发，那就代表之前我们没有遇到过此类问题，所以就需要我们再三确认是否真的搞懂客户提出的需求。
如果没有，那就反复追问；如果觉得自己理解了！注意！要给客户粑粑再讲一遍，询问他们是否理解的正确，这个很关键！必要的时候甚至需要双方签署更细致的需求确认书。
2. （新）需求与现有系统的关系
理解需求以后，就要付诸行动开始产品设计。在设计之前，产品经理需要与开发人员进行一次简单的沟通，大致还原一下需求的业务场景，以及自己打算如何实现。在沟通过程中，产品经理需要讲出该项需求涉及的数据类型和内容，哪些地方会用到新产生的数据，新内容需要从哪些地方调用。接着开发人员会提出自己的疑问，最终双方会把数据关系理清楚。
除了数据关系，还有流程、权限方面的问题需要理顺，但这些属于产品的分内之事，前期一般不需要劳驾开发人员。
3. （新）需求的实现是否会影响现有系统的运行
把关系问题理顺意味着婆婆接受了新媳妇，但婆媳之间能不能友好相处，这就属于另一个问题。在探讨这个问题前，产品经理需要准备已经画好的原型图或需求文档，再次叫上开发人员。
这次除了讨论数据关系、流程权限等问题，最重要的是确定加上这个功能会不会对现有系统有影响：需不需要动原来已经封装好的代码？会不会影响原有系统性能（数据计算效率、响应速度等）？……有时候甚至会考虑用新技术实现新功能，当需要切换不同前端界面时，如何处理新旧之间的跳转问题等等。
4. 是否需要把新功能规划到产品的下一代升级中
到此为止，新需求的定制开发肯定是没问题了，剩下的工作交给开发哥哥们就可以。但产品经理仍然需要思考：是否需要把这次定制开发的内容规划到下一版本的升级优化中？也就是探讨新功能的行业通用性、客户接受程度，以及用户的学习成本等。
5. 新功能能否独立成一个单元模块
对于小规模的定制开发，产品经理需要考虑是否要放在下一版本的升级任务中；但对于较大规模的定制开发，产品经理就得考虑，是否要完善或直接封装该功能模块，使其成为一个产品单元。
这种规划是出于产品销售考虑的，大部分ToB 产品都有按功能模块售卖这类付费选择，也就是说，每个单元模块（甚至单个功能）都有其相应价格，客户需要哪个就买哪个。独立成单元模块意味着，不仅有客户为我们的“探索”付费，我们还能把探索的成果转手卖出去；这与产品升级是有区别的，因为不管产品怎么升级，其销售价格往往是不会变的。
如果该单元模块具备一定的行业属性，还会有利于市场和销售部门进行推广宣传。
6. 新功能能否独立成一条产品线
客户选择我们进行定制开发的理由有很多，当这个理由是信任时，客户可能会让我们做一些之前没有涉足过的业务系统（其实他们只是想省钱~），这类情形就非常有利于规划新的产品线。
比方说我们公司是做财务管理软件的，客户信（xiang）任（sheng）我（qian）们，所以希望我们帮助他们开发一个用于合同财务管理的功能模块，表面上我们好像做着很吃力，但实际上这个定制开发极大地降低了我们切入新领域的风险。
7. 极端情况
还有一种情况，客户的定制开发项目完全不具备行业通用性，调研后也没有客户愿意接受。坦白说，就是由某个傻X晕头晕脑地签下，然后不得不做出来的……这种情况就给产品经理和运维人员（尤其是后者）增加了很大的负担，因为涉及到产品版本的管理，每次优化升级都得单独给他们发版……产品经理能做的就是，多陪陪负责这家客户的运维GG~