最近公司的项目经理代表技术部门找我提需求（背景音：可算有今天了），认为现在由于文档不健全，导致技术同事们对产品和业务理解不够，希望我们能够完善所有的产品文档，并且实时更新。当然，这个要求看起来没什么不合理，他们也是遇到了各种实际存在的问题才提出来的。
我们先不说最终讨论的结果，先讲几个故事。
小东是创业公司的产品负责人，这几天接到一个特殊的需求，就是土老板在一次创业者聚会上听说了各种洋气的协作产品，回来就让小东也给公司买一个用。为什么？当然是要提高团队效率啊！你看你们用的那些破表格，还有原始社会的纸条、便签，这怎么行。
小东也没找到好的理由反驳，所以很快就买了年费会员，大家花了几天时间研究用法。过去喊一句就能解决的问题，现在要在工具上操作三步；想贴便签怕被老板骂，但新工具上又找不到整体的任务甘特图。折腾了一个多月，土老板都看出来 5 人团队其实还是 Excel 最好用，于是一声令下，又恢复原状。
小南是有完美主义倾向的产品设计师，他接到了运营团队的线下活动支持的需求。运营团队说，他们在线下用手工的方法已经能够实现啦，只是希望产品这边能做些支撑功能，降低他们的人工成本。小南一口答应下，说绝逼做出一个完美的功能。
活动本身的支撑很简单，但是好像目前方案的体验不够好，要再丰富一下。过了几天，感觉他们应该还需要完整的报表，这个功能也得有才好用。又过了几天，不对，现在的拓展性不强，可调配的参数太少，应该多增加变化空间，还得改。又过了几天，小南兴冲冲地通知运营团队功能完成了，对方一脸懵逼：我们活动前天结束了啊。
故事想说明的是，对任何的需求，不能只考虑第一时间想到的方案、别人推荐的方案、大公司惯用的方案，等等。最好的方式，是自己去调查背景、体验需求，确保自己理解到了问题本质，然后找到最急需、最有效的解决方案。
不管是做任何设计、用户分析，还是跟部门的协作、项目的规划和推进，都是遵循这个原则，先保证每个需求都得到的基本的满足，再去考虑更优化的方案。小东他们现在的协作没有问题，就别先兴师动众去折腾大家；小南运营同事的需求很明确，是要降低人工成本，那就先用最简单的产品功能提供帮助。就跟考研一样，每个科目要先都达到及格线，我们再去花时间精力提高各科的成绩。
说回最开始的那一幕，我跟产品的同事跟项目经理的回复是，我们未必直接去丰富大而全的文档系统，这自然是「正确」的，但不是当前最好的解决方案。全体产品经理扑在这上面的心思和精力，在目前不确定的情况下就是一种需求的过度满足。根据技术部门在项目推进中遇到的很多对产品和业务不熟悉的问题，我们依靠业务培训和梳理基本逻辑图等方式先满足当前的需求，可能是最合理的选择。
