程序猿们，高智商群体，往往对手中的工作有超高的自信。你经常会听他们说，
v 小问题，很快就可以解决;
v 这个不难，很常见的功能;
v 交给我，半天搞定;
实际情况是？你可以猜猜。
面对需求时，我的答复是：我考虑下，稍后答复。
我们不管是做项目还是仅仅做项目中的某一部分，我们需要遵从一种好的习惯。《《掌控习惯》》这本书中有一种说法，当你不知道从何开始时，保证流程正确总是没有问题的。
我想说的是做项目做需求，正确流程是，需求再多，文档先行。文档即理论，也是指导设计书，记录了项目或者需求一切相关的信息，能给人明确的信息提示，为后面复盘总结经验做好准备。
程序员专注实践，擅长实践，但是没有理论的指导，很容易进入误区，漏掉流程，缺东少西。
需求设计文档该怎么组织所有问题都是经济问题
开发需求是为了解决用户的问题，用户需要解决问题，肯定是为了达到某种效果，业务能给自己带来价值。重点是价值，没有价值，一切都是白搭。
所以，设计文档首先考虑，需求做出来要到达什么样的目标，也就是能体现价值，在职场上叫KPI。
目标确定后，再考虑用户低层次要求，比如，体验，功能可用。
专业人做专业事考虑清楚目标，了解用户心里，接下来就是程序员的showtime，一般的工作流程，在这里笔者不太多废话，下面一张图讲清楚。
一张图保证流程正确关注我，一起思考，一起进步。