第一章 需求

凡是得有个来由，就像物理中的能量守恒定律一样，各个模块（部门、组）之前相关作用、推动，让这整个公司的业务运作起来。不可能凭空产生能量。做项目开发也是一样，总得有一个需求过来，启动一个项目，或者推动整个项目的进展。这个需求可能是老板提出来的，也可能是产品提出来的，最终到开发组这里都需要转化为功能点。

做功能分析这个事，往往需要有独立开发项目能力的人来做，而刚刚入行的初级工程师，或者是没独立承担过项目的工程师是不会委以重任的。毕竟做项目是要盈利或者达到KPI的，是实打实的现实操作，跟写几个Demo截然不同。在作者以往的经历中，也常常会推荐一些自己觉得比较靠谱的工程师（比如小A）去承担一些重任。但结果往往会被拒绝，理由很简单，在公司以往的项目中，没有什么证据能够证明小A有独立承担项目的能力。对于这个反馈作者也是认可的，毕竟让新人（刚开始独立承担项目）去做重要的项目，是存在风险的。

在现实社会或者说商业社会就是如此，用事实说话。而对于想要独立承担项目的人来说，能够分析清楚需求是至关重要的，否则，就是“差之毫厘谬以千里”。

有些开发人员会在社交圈吐槽说，又要跟PM（产品经理）开撕了。这其实是一个正常的情况，工种不同，责任不同。PM梳理用户需求，开发人员来实现。PM在做需求时不会考虑系统实现的问题，满足用户需求为第一位，因此开发人员在接到需求的第一件事就是考虑各个需求点能否实现，以及实现起来的复杂度（工期），然后反馈给产品经理。这个时候开发人员经常犯的一个错误是，以系统好实现好维护优先。这是一个错误的认知，系统的实现应该以满足用户需求为第一要务，试想下，不满足用户需求的产品怎么会留住用户，没有用户的系统，维护它作甚。所以在工期紧、任务重的情况下，往往需要排出个一二三期来，分段完成。

所以一个优秀的工程师，应该是在尽量满足用户需求的前提下，构建一个稳定、易维护、易扩展的系统。

但，这并不意味着要一味满足产品的需求，有时产品构想出来的需求，可能是脱离了技术实现的。比方说在移动端的网页中，拿到所有用户的网络状况。所以开发人员，或者称项目的技术负责人要及时的告诉产品，哪些东西是目前经验上已经明确无法实现的。避免在后期进行无谓的返工。

对于一个优秀的工程师来说，把握住需求很重要，你需要像产品那样去思考用户的需求，也需要像工程师那样去考虑功能的实现。你需要不断的权衡，尝试，总结，最终你才能到达轻松的hold住一个项目的境界。