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

【产品经理】从产品经理的技术理解力看产品需求流程_第1张图片

一、写在前面

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

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

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

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

你可能感兴趣的:(产品经理,产品经理)