本篇文章是写给跟我一样的普通工程师小哥看的，大佬请绕道，主要聊聊，怎么搞定我们工作中所遇到的来自很多人的形形色色的需求，我把绝大多数的需求都放在这四个阶段去想，每个阶段都有它固有的一些方法，每个阶段都有它固有的手段。

一个需求从构思到上线到维护，不可避免经历上边这么几个阶段。决定要去想，这个需求是不是要做，这是需求的初始端也是需求的来源，需求的来源总是源自某些人的某些思考或者拍脑袋，毕竟拍脑袋也是思考的一种。决定要去设计，这个阶段需求大方向其实已经定了，需要去思考怎么设计你的架构来满足这块事情。决定怎么落地，这个阶段其实架构都已经定了，需要思考的是跟谁一起合作怎么去把这个需求做成。决定怎么上线，这个阶段会有各种各样的限制，以及各种各样的数据迁移过程。

决定要去想

需求可能来自产品经理的一句话，嗯，某某某平台里有一个功能，我们也要上。第一想法是什么？"傻的，别人有我们就要做咩。"其实大可不必，我们先上他们平台去看看，取其精华去其糟粕，好的我们就借鉴，然后再跟产品经理聊这个事情的可行性。

需求可能来自产品经理的一句话，嗯，这个业务大佬说要做这个A需求，我们得在这周五完成上线。第一想法是什么？"傻的，要不五分钟后上线好了"。这个时候我们要做的事情呢，是去了解从产品经理口中出来的所谓的业务大佬的这个需求的真正意义，最好是跟业务大佬直接对话，好好思考业务真正的需求以及这么着急上线背后的思考。

这个阶段其实很多时候都是一些人的一些天马行空的东西，不要着急去落地，也不要着急去设计，优先找到最核心的人，咨询清楚这件事情背后的意义，再旁敲侧击咨询更多的人，搜集更多的信息，再做出你自己的判断。

宜：

一份文档，二次确认，三次交谈。

忌：

一口答应，二话不说。

决定要去设计

好了，需求确定需要，嗯这个玩意我们是要做了，也知道要做成怎么样的东西了，完美我们要自己设计一个从头到尾的方案。停。别什么事情都想着自己彻彻底底完成，对于小项目来说还行，对于大项目来说这绝对不可能的，搜集可用的靠谱服务，借力打力。

这个阶段要不要一次性设计好所有的东西呢？其实未必需要，这个阶段肯定是来来回回的，我们设计好一个比较基础的版本后，及时沟通，保证这个设计是符合用户的需求的。设计得七七八八，要学会自己进行沙盘演练，考虑更多的情况，在纸上甚至脑里进行沙盘推演，保证方案的可行性以及方案的契合程度。

设计的阶段，需要多多考虑能否借力打力，以及随时验证。

宜：

借力打力，随时验证，沙盘推演。

忌：

设计一个来自老铁的666火箭。

决定怎么落地

好了，大体架构已经基本确定了，该思考怎么落地了，这个阶段一般要进行详细设计了，一般来说这个阶段在细化的时候都会跟原先的需求可能会有一些出入，所以在设计完技术方案之后，要跟兄弟团队的同学一对一沟通好大家的边界以及分工合作的方法。所有的方方面面都沟通完之后，组织大家进行一次技术评审，并且在这个时候确定最终的排期以及各方的对接人。这个阶段一般都要产出自己系统相关的技术方案，甚至各个接口各个字段，系统间交互，最终产出的验收标准。

宜：

一对一沟通，技术方案确定后再聊排期，方案要落地成文档。

忌：

拉一大波人开一些无关的会。

决定怎么上线

这个阶段会出现在开发得七七八八的时候，要做一些系统上线的处理。系统部署依赖关系以及部署计划要梳理一下，灰度计划要设计一下，数据库怎么上线要梳理一下，数据库历史数据迁移要考虑一下，系统监控要提前设置一下免得不知道上线效果。整理成一个checklist，一个一个检查，确保万无一失。

宜：

依赖梳理，监控梳理，细心确认。

忌：

一波部署，听天由命。

以上