理解力
一、写在前面
鹅厂对产品经理的能力项要求中有一条重要考量，叫做技术理解力。我一直在思考学习，怎样才能算得上是具有技术理解力，也一直把提升技术理解力作为自己工作目标，直到最近，听曾经策划并实现央视微信摇春晚的技术哥哥分享之后，才恍然大悟，所谓的技术理解力，不是让产品经理学看代码，而是在沟通、需求、及项目推进时，思考方式与技术人员保持基本同步。这应该怎么理解呢？就让我们从一个需求流程的角度来详细说明吧。
需求来源有很多途径：用户调研、反馈，产品创新、升级、迭代、运营，市场分析，竞品对标，甚至是老板需求等等不一而足、不可胜数。在传统意义上，产品经理根据需求特性，抽象产品特性，思考产品逻辑，制定产品目标、愿景、实施计划，拟定详细的文档，按照交互-设计-重构-前后台开发-测试验收上线的流程，一步步推进即可。但看似合理且被大多数产品经理认为是理所当然的流程中，却隐藏着技术理解层面严重的bug。
二、对软件设计的理解问题
大家知道，软件开发设计有“面向过程”和“面向对象”之分，虽然两种方式之间有千丝万缕的关系，但在思考方式层面，却有很大的区别：
面向过程，是指以任务/事件为中心，进行软件设计。
面向对象，是指以事物为中心的软件设计。
举个用户要搭乘地铁从T站到F站的简单例子来说明：
如果用面向过程的设计方式，会将地铁启动、运行、到站等一系列的动作设定为过程，也许还要设定地铁维修的过程。然后将这所有的过程按照逻辑串在一起，完成一个任务。
如果用面向对象的方式设计，那直接将地铁定义为对象，地铁的颜色、形状等则为属性，地铁的运行和到站就是地铁的方法，也即地铁的行为，而不是过程。
参照软件设计的方式，产品经理在思考需求、抽象产品特性和逻辑时，也有类似的思考方式的区别：
有时过于关注产品如何实现每一个步骤，就难以描绘产品大局，难以把握用户分类、了解每一类用户的目标；又有时如果面向对象，就有可能将简单的逻辑复杂化。这样没用明确思考方式的情况下，无论是产品PRD、交互或开发沟通，都可能产生分歧。
要达到合理的技术理解，需要在需求思考环节，就要考虑使用哪种思维方式继续，尤其是需要和技术人员提前沟通，磨合双方对于产品需求思考的方式，是需要面向过程，还是需要面向对象。
在沟通的基础上，继续详细的设计产品：明确产品用户分类、每一类用户的目标以及行为路径，从而明确产品特性和逻辑。根据每类用户的情况，拟定对应的流程、时序、交互等一系列所需的说明，然后再提交技术开发。产品与技术这样同步的思维方式，相信可以免去很多需求设计转换为软件设计时的问题。
三、对需求实施的理解问题
很多产品经理都说过这样的话：这个需求很简单，随便改改就可以啦。当然，这也是技术同学最不喜欢的话之一，我也不例外，曾因为一个简单页面的图文修改，对技术人员嗤之以鼻，但当了解内情后才发现，不仅仅是修改HTML的问题，还涉及到css、json、数据库读取修改以及数据字段的调整。所以对于需求的理解，从产品经理和技术人员角度而言，所看到的大小和范围，也许就像冰山一样，水面和水底有很大的区别。
在这种技术层面的改动要大于产品预期的情况，难免就会产生分歧。为了尽量使需求的实施理解，也能保持同步，可以参考以下要素：
参加技术人员的概要设计评审：当产品需求提到技术层面时，一般技术人员会对需求进行概要设计、评审、详细设计及评审、开发实施等环节。当然产品经理一般不会在技术层面介入太深，但为了尽量使需求不偏离目标，参加技术层面的概要设计评审，是很好的一个选择，虽然对于多数产品经理而言，不一定能全听懂技术在概要设计层面的讨论。参加概要设计评审可以了解需求在启动技术设计时，涉及到的相关系统、干系人、内外部团队等，大致了解技术实施层面的困难、瓶颈和资源需求。以减少用户类型、路径等环节的偏差。
提前向技术同步产品的远期愿景：同步产品愿景和长期版本目标，可以是在需求刚出现时，也可以是在交互设计时，但个人感觉最晚不能晚于技术的概要设计。提前同步产品愿景，可以在技术人员做技术设计时，能确定数据、架构、迭代以及预留字段，更能确定技术实现方式，是按照较大的系统实施，还是按照简单的逻辑实施，因为很多时候，技术的实现方式有多种选择。以免产品的期望是宏伟大厦，因为没有提前同步给技术，导致技术在打地基时，按照普通的平房实施了。
了解需求中的关键点：这一点需要在每一次技术沟通中进行确认，但尽量在技术概要设计前了解清楚，这也就是参加技术概要设计评审的重要性所在。了解需求的关键点，了解了相关困难、瓶颈、资源需求等，对于需求实施的排期、时间节点评估则会掌握的比较清晰。
所以对于需求实施的理解，产品和技术保持同步，才能使需求实施事半功倍。
四、对项目进度推进的理解问题
需求项目进度沟通方面，产品和技术的理解也存在分歧：评估的时间点内不能完成目标，甚至没有明确的时间评估。面对这样的问题，最重要的，肯定是按照前期的沟通制定计划，正如摇春晚技术哥哥的说法，就是有了计划，才能感知变化。因此建议考虑以下元素：
根据需求的关键点，把控项目进度：前文提到，了解需在技术实施环节的关键节点，目的就是为了整体把控需求，防止在关键节点掉链子。有时是需要产品协助，或是督促技术打通关键节点的问题，有时则是因为前期的评估和了解，提前将实施中关键节点可能存在的问题消化掉。
需求实施的“时间最小单元”不能太久：需求实施的“时间最小单元”，我把它定义为，需求实施过程中，可以标识为里程碑或是有明确交付物的最短时间。例如一个H5的登录注册功能的开发，判断每个输入框信息输入格式是否准确，将信息提交至数据库，数据库写入数据并返回是否正确写入，给用户对应的反馈，这些每个环节的开发所需时间，都可以理解为一个时间最小单元。按照正常的逻辑，这样的时间最小单元，建议是0.5天至3天，最好不超过3天。
时不时的讨论推进的困难和进度：对于推进实施中的需求，不能当成一个完全交出去的任务，更不能当“甩手掌柜”，而是应该参照时间最小单元，不时的讨论推进中是否存在困难，应如何解决困难，询问时间最小单元中的推进进度，如有没有进度，则可能需要调整计划了。
所以从项目进度推进角度，也是需要产品和技术都转换思维，首先是了解对方的想法，然后是从对方角度思考，共同发掘问题和困难所在，再去解决。这样提前预估、制定时间节点、共同督促的推进方式，才能使项目推进更顺利。
五、本文总结
至此，个人感觉通过思维同步、需求同步、技术同步、项目推进同步以及沟通同步这些元素，可以更好的推进需求。
因此个人斗胆将一个产品需求流程的走法，优化为：
a、（与技术人员沟通面向过程还是面向对象的思考方式）根据需求特性，抽象产品特性；
b、思考产品逻辑，制定产品目标、愿景（同步与技术人员讨论产品愿景）；
c、制定（初步）实施计划，拟定详细的文档，交互及沟通-设计及沟通；
d、（参与软件概要设计评审，评估项目时间排期及执行中的困难）；
e、（制定开发计划，任务拆分到0.5天至3天）重构及前后台开发；
f、（讨论推进中的困难，咨询督促进度）；
g、测试验收-上线-优化迭代；
其中括号中的内容，则为优化后的流程内容。
以上理论及观点，均为个人思考归结，不一定是适用于所有需求和项目，也不一定适合所有的产品和技术，但还是希望对我们的工作推进，起到一定参考作用。
最后引用邓小平爷爷的一句话，白猫黑猫，能捉老鼠就是好猫。共勉。
相关阅读
支付宝年度账单、网易云音乐年度盘点，基本上每年都会刷一遍朋友圈。除开本身产品之外，在运营和营销方面，有多少是可以学习的呢？17年末
编者按：你的产品是市场密集型产品还是销售密集型产品？对于这个问题的答案将决定你的产品是销售占据主导地位还是市场占据主导地位。
任何一个问题地提出都有其背后的原因，而PM需要透过现象去寻找本质，这其实也是一个从需求采集、分析到产品设计的过程。互联网公司中
产品入门必备技能，结构图、流程图、原型以及各类文档的编写绘制；会画会写并不代表你是一个合格的产品经理，但是合格的产品经理一定会
导语：研究机构九月份发布的全球定价研究报告表明，72%的新产品都达不到预期的销售额。Simon-Kutcher & Partners及独立专业定价协会