前面聊过,作为程序员,如果不尽早晋升,在 35 岁后很可能就失业或者被迫转行做外卖员了。也聊到过,如果要晋升,被考察的其中一项就是影响力。

一流的程序员,可以影响整个世界,比如计算机领域的各种之父们。

我们不是一流的程序员,影响不了世界,先从身边人开始影响吧。经常看到新闻说产品经理和程序员因为需求问题打起来了,这真的是不堪入目。原因无非是产品经理觉得程序员不按自己的需求去写代码,而程序员却觉得产品经理不按照自己的要求去写需求,总之,产品经理影响不了程序员,程序员也影响不了产品经理,于是打起来了,最终免不了双方都被公司所开除。

所谓影响力,是用一种别人所乐于接受的方式,改变他人的思想和行动的能力。如果双方都能有效地影响对方,打架的悲剧就不会发生。

今天分享一个我所使用过的一个方法,成功改变了产品经理提需求的姿势,为后面的合作打下了良好的基础。虽然标题叫做程序员影响产品经理,以及的确当时是我作为程序员影响了当时的产品经理,但如果产品经理自己主动采用这个方法,也能让程序员愉快地写代码,成功地影响程序员,避免打架的尴尬。

这个方法就是:

实例化需求


这其实是一本书,但是我今天只举一例子,正好实例化需求地中心思想,就是用举例子地形式说明需求。

我曾经在一家专注职业教育的公司任职,产品经理提了一个需求,开发做了一段时间,验收时产品经理觉得不对,但是工期又紧,双方都顶着巨大的压力,需求讨论会开了好几轮,再这样下去很可能真的要打起来了。

于是我在那一次的周报中反应了这个问题,提出了改进建议:


建议与思考

问题: 在最近的迭代中发现,大家对于反复讨论过的需求,仍然有各自不同的理解。

分析: 需求描述的是逻辑,然后由于自然语言天然的不精确性,导致不同的人会有不同的理解。

实例: XX 项目里有对板块解锁周期的描述:某一个板块可观看的时长,这个时长后才能解锁下一个板块。这个描述,不同的人就有不同的理解,主要是容易让人误解为,第一个板块也是在周期之后开始(可能程序员很习惯设想还有一个不显式在页面上显示的,但是逻辑上存在的第零个板块)。

改进方案实例化需求。使用举例的方式,来说明需求,就不会有歧义,比如上面的例子改成:

“初级产品经理入门”这门在线课程,它一共有 4 个板块。这 4 个板块的解锁周期分别为:板块一周期 7 天,板块二周期 2 天,板块三周期 7 天,板块四周期 5 天。

如果开课日期是:2019.1.1,那么前端显示的板块区间范围是:

- 板块一:2019.1.1-2019.1.7 - 板块二:2019.1.8-2019.1.9 - 板块三:2019.1.10-1.15 - 板块四:2019.1.16-1.20

这样不仅消除了歧义,而且,更进一步采用严格的“给定某一条件……-当……-那么……”这样的结构来描述需求,就能够采用一些工具来生成自动化测试。

这样的好处是不仅需求清晰,而且是可以自动化运行的活文档。

另外,通过将模糊的大需求拆解成一个个使用三句话描述清楚的小需求,也算是金字塔原理的一个应用(当时这家公司很推崇《金字塔原理》这本书)。


提高开会效率


后来,产品经理写的需求,总是会刻意给出例子。并且他们自己也发现,在举例的过程中,会发现自己的逻辑漏洞,从而在需求评审会之前,就能自己发现很多问题,提前可以打磨。在开需求评审会时,需求都比较清晰,没有歧义并且不再有那么多低级错误,或者漏洞,开会效率提高了很多。

程序员写代码极度舒适


后来程序员写代码去实现实例化的需求时,心情是极度舒适的。但是具体的当时的项目代码就不分享了,毕竟那家公司是闭源开发方式。

举一个更有含金量的例子,这可是我当时学的一门课程,5000 元一天,含金量可想而知。

需求是写成这样子的:
image.png
程序员写完代码,是可以运行这些需求的,并即使给出反馈结果:
image.png
上面截图是对需求运行的反馈,同时运行的产品截图如下:
image.png

总结


实例化需求帮助产品经理厘清需求,避免逻辑漏洞和低级错误,和程序员沟通时避免语言歧义,而程序员开发时心情极度舒适,真的是工作的必备良药呢!