动效给程序员用什么格式_程序员要的不是需求文档，而是一份清晰的流程图

我所见过的程序员和产品经理之间产生矛盾大多是因为一个叫「需求文档」的家伙。

有一种恶心的需求文档&＃xff0c;我曾经见过&＃xff0c;甚至再见到会觉得更恶心&＃xff0c;请看下图&＃xff1a;

这张图应该会交给交互射鸡湿&＃xff0c;交互看着这么长的文字&＃xff0c;应该是崩溃的&＃xff0c;画出交互图。交给程序员的时候&＃xff0c;程序员看着这样的需求描述再来生产的时候&＃xff0c;就会问若干个「如果」问题&＃xff0c;如果×××情况下&＃xff0c;该怎么办呢&＃xff1f;产品经理再来更新需求文档&＃xff0c;又问&＃xff0c;又改&＃xff0c;再问&＃xff0c;再改&＃xff0c;大家都疲惫了&＃xff0c;需求文档也成熟了&＃xff0c;最后谁都看不懂&＃xff0c;一份文档束之高阁&＃xff0c;没有任何价值。

请产品经理不要再浪费时间生产这样的文档了&＃xff0c;程序员其实根本不需要这份文字式的需求告白书&＃xff0c;程序员喜欢「看图」&＃xff0c;这种文字式的文档应该是产品同学脑中的思路&＃xff0c;而不应该直接把思路描述成文字交出来。

程序员需要的是一份清晰的交互图&＃xff0c;这份交互图上在关键位置有一些边界条件的说明&＃xff0c;这份交互图不一定非要用什么visio或者乱七八糟的工具输出&＃xff0c;一张草纸加铅笔描述清晰即可&＃xff0c;但是要还原出需求所描述的所有元素&＃xff0c;虽然没有UI设计&＃xff0c;但是程序员就可以开始开发demo了。

由产品、交互和程序员一起讨论出feature的关键路径&＃xff0c;并大家一起脑补好每一个流程&＃xff0c;然后简单的画出草稿&＃xff0c;我认为是效率最高的方式&＃xff0c;并且可以减少很多会议&＃xff0c;凡是一个人说想好了&＃xff0c;发起评审&＃xff0c;基本最后都被改的面目全非&＃xff0c;还不如初期就大家一起得出结论。

当然程序员是很「贱」的&＃xff0c;你没叫他一起参与讨论的时候&＃xff0c;他会抱怨说&＃xff1a;“TMD&＃xff0c;什么都不叫我&＃xff0c;乱决策&＃xff0c;现在乱的一坨屎&＃xff0c;根本跑不通”&＃xff0c;你叫他的时候&＃xff0c;他又会说&＃xff1a;“整天跟产品在一起讨论问题&＃xff0c;技术上都没有长进&＃xff0c;没有积累&＃xff0c;或者又抱怨说&＃xff0c;唉&＃xff0c;每天白天跟产品讨论&＃xff0c;只有晚上加班才能写点代码&＃xff0c;累的像条狗&＃xff0c;还总被人家说效率不高”。

程序员大多认为自己有些“武功”&＃xff0c;跟不同的程序员交流要用不同的办法&＃xff0c;例如多请他吃饭或按摩。

所谓能力越大&＃xff0c;责任越大&＃xff0c;明白的程序员早就想明白了&＃xff0c;他每天的工作不是给他的老大干活&＃xff0c;也不是给他的老板干活&＃xff0c;每天其实都是在给自己干&＃xff0c;无论在哪里干&＃xff0c;都当是创业。

再说下需求文档中的「优先级」这个选项&＃xff0c;也是令程序员很头疼的&＃xff0c;优先级分为高、中、低三个选项&＃xff0c;大多数产品经理会说&＃xff0c;高的必须上线&＃xff0c;中低优先级也是需要做的&＃xff0c;那还分什么优先级呢&＃xff1f;或者说中低选作&＃xff0c;这种模棱两可的感觉不如抽象成&＃xff0c;做或者不做&＃xff0c;当然需要产品经理能力的提升&＃xff0c;清晰评估出一个版本能否涵盖这么多的事情。

转回到正题&＃xff0c;程序员其实不需要任何需求文档&＃xff0c;只需要一份清晰的流程图即可。

#专栏作家#

给产品经理讲技术&＃xff0c;微信公众号(pm_teacher)&＃xff0c;人人都是产品经理专栏作家。资深程序猿&＃xff0c;专注客户端开发若干年&＃xff0c;对前端、后台技术略懂&＃xff0c;热衷于对新的科技领域的探索。

本文原创发布于人人都是产品经理。未经许可&＃xff0c;禁止转载。

给作者打赏&＃xff0c;鼓励TA抓紧创作&＃xff01;赞赏

3人打赏