【产品经理】从产品经理的技术理解力看产品需求流程

一、写在前面

鹅厂对产品经理的能力项要求中有一条重要考量，叫做技术理解力。所谓的技术理解力，不是让产品经理学看代码，而是在沟通、需求、及项目推进时，思考方式与技术人员保持基本同步。这应该怎么理解呢？就让我们从一个需求流程的角度来详细说明吧。

需求来源有很多途径：用户调研、反馈，产品创新、升级、迭代、运营，市场分析，竞品对标，甚至是老板需求等等不一而足、不可胜数。在传统意义上，产品经理根据需求特性，抽象产品特性，思考产品逻辑，制定产品目标、愿景、实施计划，拟定详细的文档，按照交互-设计-重构-前后台开发-测试验收上线的流程，一步步推进即可。但看似合理且被大多数产品经理认为是理所当然的流程中，却隐藏着技术理解层面严重的bug。

二、对软件设计的理解问题

大家知道，软件开发设计有“面向过程”和“面向对象”之分，虽然两种方式之间有千丝万缕的关系，但在思考方式层面，却有很大的区别：

• 面向过程，是指以任务/事件为中心，进行软件设计。
• 面向对象，是指以事物为中心的软件设计。

举个用户要搭乘地铁从T站到F站的简单例子来说明：

如果用面向过程的设计方式，会将地铁启动、运行、到站等一系列的动作设定为过程，也许还要设定地铁维修的过程。然后将这所有的过程按照逻辑串在一起，完成一个任务。

如果用面向对象的方式设计，那直接将地铁定义为对象，地铁的颜色、形状等则为属性，地铁的运行和到站就是地铁的方法，也即地铁的行为，而不是过程。

参照软件设计的方式，产品经理在思考需求、抽象产品特性和逻辑时，也有类似的思考方式的区别：

1. 有时过于关注产品如何实现每一个步骤，就难以描绘产品大局，难以把握用户分类、了解每一类用户的目标；又有时如果面向对象，就有可能将简单的逻辑复杂化。这样没用明确思考方式的情况下，无论是产品PRD、交互或开发沟通，都可能产生分歧。
2. 要达到合理的技术理解，需要在需求思考环节，就要考虑使用哪种思维方式继续，尤其是需要和技术人员提前沟通，磨合双方对于产品需求思考的方式，是需要面向过程，还是需要面向对象。
3. 在沟通的基础上，继续详细的设计产品：明确产品用户分类、每一类用户的目标以及行为路径，从而明确产品特性和逻辑。根据每类用户的情况，拟定对应的流程、时序、交互等一系列所需的说明，然后再提交技术开发。产品与技术这样同步的思维方式，相信可以免去很多需求设计转换为软件设计时的问题。

三、对需求实施的理解问题

很多产品经理都说过这样的话：这个需求很简单，随便改改就可以啦。当然，这也是技术同学最不喜欢的话之一，我也不例外，曾因为一个简单页面的图文修改，对技术人员嗤之以鼻，但当了解内情后才发现，不仅仅是修改html的问题，还涉及到css、json、数据库读取修改以及数据字段的调整。所以对于需求的理解，从产品经理和技术人员角度而言，所看到的大小和范围，也许就像冰山一样，水面和水底有很大的区别。

在这种技术层面的改动要大于产品预期的情况，难免就会产生分歧。为了尽量使需求的实施理解，也能保持同步，可以参考以下要素：

1. 参加技术人员的概要设计评审：当产品需求提到技术层面时，一般技术人员会对需求进行概要设计、评审、详细设计及评审、开发实施等环节。当然产品经理一般不会在技术层面介入太深，但为了尽量使需求不偏离目标，参加技术层面的概要设计评审，是很好的一个选择，虽然对于多数产品经理而言，不一定能全听懂技术在概要设计层面的讨论。参加概要设计评审可以了解需求在启动技术设计时，涉及到的相关系统、干系人、内外部团队等，大致了解技术实施层面的困难、瓶颈和资源需求。以减少用户类型、路径等环节的偏差。
2. 提前向技术同步产品的远期愿景：同步产品愿景和长期版本目标，可以是在需求刚出现时，也可以是在交互设计时，但个人感觉最晚不能晚于技术的概要设计。提前同步产品愿景，可以在技术人员做技术设计时，能确定数据、架构、迭代以及预留字段，更能确定技术实现方式，是按照较大的系统实施，还是按照简单的逻辑实施，因为很多时候，技术的实现方式有多种选择。以免产品的期望是宏伟大厦，因为没有提前同步给技术，导致技术在打地基时，按照普通的平房实施了。
3. 了解需求中的关键点：这一点需要在每一次技术沟通中进行确认，但尽量在技术概要设计前了解清楚，这也就是参加技术概要设计评审的重要性所在。了解需求的关键点，了解了相关困难、瓶颈、资源需求等，对于需求实施的排期、时间节点评估则会掌握的比较清晰。

所以对于需求实施的理解，产品和技术保持同步，才能使需求实施事半功倍。

四、对项目进度推进的理解问题

需求项目进度沟通方面，产品和技术的理解也存在分歧：评估的时间点内不能完成目标，甚至没有明确的时间评估。面对这样的问题，最重要的，肯定是按照前期的沟通制定计划，就是有了计划，才能感知变化。因此建议考虑以下元素：

1. 根据需求的关键点，把控项目进度：前文提到，了解需在技术实施环节的关键节点，目的就是为了整体把控需求，防止在关键节点掉链子。有时是需要产品协助，或是督促技术打通关键节点的问题，有时则是因为前期的评估和了解，提前将实施中关键节点可能存在的问题消化掉。
2. 需求实施的“时间最小单元”不能太久：需求实施的“时间最小单元”，我把它定义为，需求实施过程中，可以标识为里程碑或是有明确交付物的最短时间。例如一个H5的登录注册功能的开发，判断每个输入框信息输入格式是否准确，将信息提交至数据库，数据库写入数据并返回是否正确写入，给用户对应的反馈，这些每个环节的开发所需时间，都可以理解为一个时间最小单元。按照正常的逻辑，这样的时间最小单元，建议是0.5天至3天，最好不超过3天。
3. 时不时的讨论推进的困难和进度：对于推进实施中的需求，不能当成一个完全交出去的任务，更不能当“甩手掌柜”，而是应该参照时间最小单元，不时的讨论推进中是否存在困难，应如何解决困难，询问时间最小单元中的推进进度，如有没有进度，则可能需要调整计划了。

所以从项目进度推进角度，也是需要产品和技术都转换思维，首先是了解对方的想法，然后是从对方角度思考，共同发掘问题和困难所在，再去解决。这样提前预估、制定时间节点、共同督促的推进方式，才能使项目推进更顺利。

五、本文总结
至此，个人感觉通过思维同步、需求同步、技术同步、项目推进同步以及沟通同步这些元素，可以更好的推进需求。

a、（与技术人员沟通面向过程还是面向对象的思考方式）根据需求特性，抽象产品特性；
b、思考产品逻辑，制定产品目标、愿景（同步与技术人员讨论产品愿景）；
c、制定（初步）实施计划，拟定详细的文档，交互及沟通-设计及沟通；
d、（参与软件概要设计评审，评估项目时间排期及执行中的困难）；
e、（制定开发计划，任务拆分到0.5天至3天）重构及前后台开发；
f、（讨论推进中的困难，咨询督促进度）；
g、测试验收-上线-优化迭代；
其中括号中的内容，则为优化后的流程内容。

以上理论及观点，不一定是适用于所有需求和项目，也不一定适合所有的产品和技术，但还是希望对我们的工作推进，起到一定参考作用。

最后引用邓小平爷爷的一句话，白猫黑猫，能捉老鼠就是好猫。共勉。