众所周知程序员和产品经理之间产生矛盾大多是因为一个叫「需求文档」的东西,那我们应该如何撰写一份程序员真正需要的需求文档来解决这个矛盾呢?
〄 观点:从来不存在一份完美的需求文档可以满足任何程序猿的任何需求。
如果一定要一个答案,那么就是:
让开发小伙伴认同功能价值,充满成就感是PM最重要责任之一。实操角度看,从宽度(关联性)、深度(逻辑性)、长度(预见性)、量度(价值数据化)4个方面出发去描述需求,文档自然可以画的清晰、写的明白。
从下面3个角度分析:
1、因人而异
程序猿也需要画像区分:
✎ 不喜欢任何文档的程序猿。这类小伙伴记忆力强、理解力好,只要PM说一遍就可以很快理解业务逻辑,想的比PM可能都细致。
对于这类成员,PM的需求文档力求主业务逻辑清晰,比如开通个人委托扣款的前置条件具体有哪些条件;TA系统进行补单的几种业务逻辑情况。设计与交互上的逻辑为辅。
✎ 喜欢流程图多过文字与原型的程序猿。这类小伙伴对于图形有特别偏好,你给他看一堆原型跟文字描述,他会觉得不耐烦。对于这类成员,我们一定要保证流程图的模块完整性、逻辑准确性。原型与文档可作为一些设计与交互逻辑的辅助参考资料。
✎ 只喜欢文档原型且较少交流。他只想安静的做个Coding的美男子。如果是这类,那么我们就需要准备齐全,图、原型、文档&#x