在很多公司，特别是中小企业。很多产品经理对接的需求提出者往往是老板或者老板的代理人。在这样的情况下。“两个凡是”的精神基本上得到了全面贯彻执行。“凡是老板做出的决策，我们都坚决拥护；凡是老板的指示，我们都始终不渝地遵循”。这样的情况下，很多时候需求都是直接产品经理和老板进行对接敲定之后，直接递到研发部门。导致需求的必须的评审就成了一个过场或者遮羞布，或者有时候连遮羞布也不需要了。在这样的情况下，很多时候往往形成了产品经理在技术部门的一言堂。产品经理让干什么就干什么的场景。所谓的前景规划、研发流程、规章制度都在执行的过程中得到了弱化，或者无法执行。因为产品经理很强硬的提出这是老板的意思。如果产品经理碰上了强硬的技术主管，那场面，那酸爽…
在说到两个凡是对技术的伤害值之前，我们必须先要聊下需求评审的重要性。
为什么我们要对需求进行评审？
• 统一思想，了解需求意义
对所有需求相关人员进行需求的讲解，让大家对需求的 认知处在同一面。这样大家可以有劲一处使，在思想上形成统一战线。
• 明确需求具体涉及范围
确定需求的具体事项和范围边界，以免需求的不清晰而导致后续工作评估失真和需求的蔓延。毕竟在理解上面来说，达不到所谓的千个读者有千个哈姆雷特的情况，但是要达到无言的默契那还真不是一般的基友可以做到的。
• 确定事项落实工期与责任
需求确定后，就可以评估当前的工作的事项，对事项进行时间评估。并且将对应工作事项安排对应的负责人。毕竟要想一个工作能够有效的开展下去，一个责任人是很有必要的。
• 确定开展工作
事情定了才能做，否则就是凭着经验摸石头过河。
先看下需求评审流程图：
会议前
image
image.gif
会议中
image
image.gif
会议后
image
image.gif
（上面的图来自网络，作者用的电脑是linux的没法安装visio,就直接盗图了）
我们看到上面的流程图中，没有那个说明是由老板直接和产品经理进行需求敲定的。为什么呢?因为需求的实现不是简简单单的涉及到老板和产品经理。它还涉及到研发、测试、运维等多个岗位的配合。当你提出一个需求但是你又让别人无法拒绝，只能进行被动的配合，这本身就是一个痛苦的过程。这个需求是否有效？是否能实现？这个其实是需要进行各个方面的论证，不仅仅是在产品层面论证可行就可以了，它还需要进行技术可行性论证的。
在两个凡是的指导下，需求只是需要经过产品经理和老板两个就敲定了。像我曾经经历过一个需求，是一个计算从J地到H地的两地仓库流转路途中的货物价值的一个需求的实现。老板说完需求之后，产品经理在没有技术的参与下，就提出了实现的模型。因为这是个维护项目。所以是有历史数据存在的。需求实现的过程中，发现需求的实现模型所需要的一些数据在系统中根本就不存在。然后产品经理就不断的去修改数据公式和数据来，用一种侥幸的心里让技术不断调整程序，来验证需求的可实现性和完整性。
从周一实现第一个数据公式一直忙到周五（需求的截止完成时间），中间不停的调整公式和数据来源。最后还是没有实现。没办法宣布不做了。
其实上面的这个实例，我们正常的流程应该是在老板提出需求后，在业务上确定需求的可行性之后，再需要给技术一定的时间来调研技术实现的可行性。然后再来和老板确认需求的完成时间。而很多小公司的做法完全就是把技术人员当做二等公民的方式。让技术人员被迫的接受一些不合理的需求。如果需求能够按时完成的话还好说，没有按时完成或者实现不了，这个时候往往技术人员要给自己增加一个背锅属性才行。
公司是老板的，是要听老板的。正值的员工，应该为公司的长远做打算，而不是一味的最求两个凡是。这是对自己的不负责任，也是对公司的不负责任和对老板的不负责任。
网友评论