公司内，研发部的程序员和产品部的产品经理之间有一场交锋。焦点在于：提交到研发部的需求文档应该是怎么样的。

程序员：你一个功能模块，需求文档就写了半页纸，非常笼统，你让我们怎么写程序？
产品经理：我们给到你们那里的东西已经很详细了，除了有需求文档之外，还有相关的页面，足够理解了。
程序员：问题是，几乎每个功能模块做出来，你们都说，有许多地方不符合你们的本意，why？
产品经理：双方都有问题。我们不是搞技术的，没有法子用技术术语说法，所以更多的细节，需要你们去考虑。我们双方这么多的沟通，貌似都没有效果啊。
程序员：让我们自己考虑？你知不知道，你们提供的很多内容，在技术实现的时候，有很多约束甚至相互矛盾的，你们从来就没有考虑过，你们只知道，我要做这个，我要做那个，你只是口头上动动嘴巴，我们这里就要弄个鸡飞狗跳的。
产品经理：~~~~~~~
程序员：~~~~~~~~~

这场交锋，我当时并未参与，是后来才知道了，然后苦笑一声。

作为有技术背景的人，我深知程序员的苦恼。
因为我当初应聘的也是产品经理这个职位（虽然目前并没有做这个），所以一直有所关注。

需求文档怎么写？
产品经理写的需求文档，通常是要从商业需求转换成产品需求。
程序员需要的需求文档，通常是要把产品需求转换成技术需求。
这三种需求之间，存在着一个转换关系。如果由一个既懂技术又了解市场的人来写，那是再好不过。不过，一般的公司里面，商业需求可能轮不到一般的产品经理来写，并且貌似在很多的互联网企业中，产品经理大多不懂技术，所以咱们先略过。

从我的角度来看，交到程序员手中的需求文档，如果由不懂技术的产品经理来写，那么，至少、无论如何也应该保证如下一些内容：
1. 模块的目的，可能还会涉及到现状的描述。
2. 模块的优先级。
3. 完成该模块的时间和人力资源等要求。
4. 输入和输出以及相应的技术上的约束条件（如果能想到某些限制条件的话，就加上去）。
5. 参考资料：如该模块和哪个商业需求相关，最关注这个商业需求的人和部门是谁。

以上几点，我个人认为，最后两点是最主要的。

第4点，输入和输出，描述一下这个，不是问题吧？就算产品经理没有一点技术背景，但是望文生义，也应该猜得出是什么意思。如果能稍微学那么一点儿技术活，写起来就更方便了。
啥？很多内容在实现的时候，可能会存在相互掐架的事情？嗯，这是一个问题。咱们来想想看怎么解决。
如果产品经理在输入输出以外，把限制条件也稍微列一下，相信会好很多。如果这份需求文档并非产品经理的一言堂，必须要技术负责人评审过后才通过，是不是又会好很多？

这里，不得不提一种可能情况：
产品经理：这个功能，我需要一周内搞定。
程序员：一周内搞不定，需要10天。
产品经理：我不管，你如果搞不定，我就去找老板协调。
程序员：行啊，你协调去吧（心里却想:又来了，你一去协调，老子就得又连着好几天加班，你是动动嘴皮子，我可是实打实的天天熬夜啊，你还让不让人活啊，下次啊，10天能完成的，我就说需要15天，明明努力一下就可以实现的，我就说技术条件限制搞不定）。
要预防这种事情发生，怎么做最好？
其一，让技术人员尽早的参与需求文档的撰写；其二，产品经理还是学一点技术吧，哪怕是去了解一些框架性的东西也好，总不能出现一个互联网产品总监却连最基础的互联网应用Email都不会用的情况发生吧？如果这样子，程序员哪个服你呀？

第5点，写上最关注的人是谁大有好处，你想想，如果文档中写上“该模块是本产品的最大亮点之一，也将是销售的主要战场，董事长亲自拍板这么做”，那么，就算程序员和产品经理的理解不一致，他也能知道该向谁去核实。虽然直接跳过产品经理找董事长并不符合一般的沟通流程，但至少能引起所有人的重视，也便于追根溯源

嗯，关于需求，牢骚就先发到这里吧，下次有机会再码字。