项目管理好坏，决定了项目的成败。无论做什么工作，项目地企划、执行、效果评估、复盘，总是必不可少的。
我们可能遇到过如下场景：
业务方提出需求，扑哧扑哧做个几周后，却发现并不是他们想要的。这样的后果就是：
项目结果被搁置
几周的开发时间浪费
业务和开发其乐融融，第一版也顺利交付，而后由于老板或者更高一级负责人的要求，要做的功能点越来越多，以至于现有功能延误。
需求的企划，项目的推进、以及团队的建设，对于结果的影响，是强相关的。做好以上三点，有两个好处。一来，可以减缓项目的失败风险，二来，也有助于团队更高效地产出。
以下内容，框架节选自书籍《程序员修炼之道》，根据理解有部分删改。《程序员修炼之道》，是软件开发的经典之作。对于软件行业的原则性问题，进行了详细而又到位的探讨，出版二十余年。第二版添加了最新的潮流趋势，由云风翻译，质量上乘，值得推荐给大家。
一般做阅读，都是带着问题来的，为了解决对应问题。项目管理方面，也有经典之作PMBOK，不过那本书蛮厚的，还没消化完全。以下内容，解答了我对于需求、项目以及团队建设的部分迷思。大部分摘录自《程序员修炼之道》，穿插工作中的心得体会。希望给读者朋友带来帮助。也希望自己，能常读常新，在工作中实践、反馈、进步。
项目启动前需求——没有人知道自己想要什么
在每个项目启动前，往往是需求的对接。
业务部门想要的是什么？是大老板拍脑袋的需求，还是确切有利于业务问题的解决？
之前的职业经历中，遇到的很多需求，都是大老板拍脑袋，然后层层传递下来。到了执行层，基本无法判断其真实的目的。最后只能和末端的需求人员对接，成了单一的传声筒。
这种情况，十分危险。
根据乔老爷定律：没有人能确切描述自己的需求，直到你把产品摆在他面前。
这样的后果就是，为了缓解高层的焦虑，做了很多脱离实际的功能。而一线，最熟悉用户的人，许多业务中的改进点，却只能搁置。
灯塔——开发人员的职责
作为开发人员，尤其是作为数据开发、数据挖掘人员，我们的职责之一，便是帮助他人了解想要什么。因为，产品数据、模型效果等最直观的感受者，还是我们。只有我们才知道：什么能做、能做到的程度。这也是区分初级和高级工程师的因素之一。
在帮助他人澄清需求时，常见的错误，便是照单全收。这往往会为后续开发，埋下隐患。人们的日常沟通，尚存在许多误解，更别说涉及开发建模的活。
正确的做法，是复述一遍，将自己理解的程度反馈出去，并明确问题的边界。如果，刚好对业务领域了解不深，则更应该通过沉浸体验业务、复述需求等方式，寻求反馈。
什么需求是好需求
与此同时，在需求澄清过程中，应当区分需求与策略。需求，是指功能上的开发，以期望实现某种功能。策略，则是一连串的活动，保证达到某种效果。一般而言，策略抽象自需求。
