项目管理好坏，决定了项目的成败。无论做什么工作，项目地企划、执行、效果评估、复盘，总是必不可少的。
我们可能遇到过如下场景：
- 业务方提出需求，扑哧扑哧做个几周后，却发现并不是他们想要的。这样的后果就是：
-
项目结果被搁置
-
几周的开发时间浪费
-
- 业务和开发其乐融融，第一版也顺利交付，而后由于老板或者更高一级负责人的要求，要做的功能点越来越多，以至于现有功能延误。
需求的企划，项目的推进、以及团队的建设，对于结果的影响，是强相关的。做好以上三点，有两个好处。一来，可以减缓项目的失败风险，二来，也有助于团队更高效地产出。
以下内容，框架节选自书籍《程序员修炼之道》，根据理解有部分删改。《程序员修炼之道》，是软件开发的经典之作。对于软件行业的原则性问题，进行了详细而又到位的探讨，出版二十余年。第二版添加了最新的潮流趋势，由云风翻译，质量上乘，值得推荐给大家。
一般做阅读，都是带着问题来的，为了解决对应问题。项目管理方面，也有经典之作 PMBOK，不过那本书蛮厚的，还没消化完全。以下内容，解答了我对于需求、项目以及团队建设的部分迷思。大部分摘录自《程序员修炼之道》，穿插工作中的心得体会。希望给读者朋友带来帮助。也希望自己，能常读常新，在工作中实践、反馈、进步。
项目启动前
需求——没有人知道自己想要什么
在每个项目启动前，往往是需求的对接。
业务部门想要的是什么？是大老板拍脑袋的需求，还是确切有利于业务问题的解决？
之前的职业经历中，遇到的很多需求，都是大老板拍脑袋，然后层层传递下来。到了执行层，基本无法判断其真实的目的。最后只能和末端的需求人员对接，成了单一的传声筒。
这种情况，十分危险。
根据乔老爷定律：没有人能确切描述自己的需求，直到你把产品摆在他面前。
这样的后果就是，为了缓解高层的焦虑，做了很多脱离实际的功能。而一线，最熟悉用户的人，许多业务中的改进点，却只能搁置。
灯塔——开发人员的职责
作为开发人员，尤其是作为数据开发、数据挖掘人员，我们的职责之一，便是帮助他人了解想要什么。因为，产品数据、模型效果等最直观的感受者，还是我们。只有我们才知道：什么能做、能做到的程度。这也是区分初级和高级工程师的因素之一。
在帮助他人澄清需求时，常见的错误，便是照单全收。这往往会为后续开发，埋下隐患。人们的日常沟通，尚存在许多误解，更别说涉及开发建模的活。
正确的做法，是复述一遍，将自己理解的程度反馈出去，并明确问题的边界。如果，刚好对业务领域了解不深，则更应该通过沉浸体验业务、复述需求等方式，寻求反馈。
什么需求是好需求
与此同时，在需求澄清过程中，应当区分需求与策略。需求，是指功能上的开发，以期望实现某种功能。策略，则是一连串的活动，保证达到某种效果。一般而言，策略抽象自需求。关注更高层面的抽象，为底层需求做好准备，DRY（Do Not Repeat Yourself）。
抽象的，且能简单直接反应业务需求的，才是好需求。
另外，做好需求的文档化。需求文档化，不是说要去交付它；而是说，将其作为开发过程的记录。这种方式，能较为清晰的记录，软件开发过程中的 Eureka 高光。这些点子，兴许是下个需求来源，或是创新的突破口。
为什么项目会失败
查理·芒格说过：如果知道，我会死在哪里，那我就永远不会去那里。
一般而言，项目失败有两个因素导致。一个是：功能的不断膨胀。也许一开始，只是添加了一个小功能，最后却成了臃肿的庞然大物。
另一方面，则是需求的变化。昨天需要的事物，在今天可能就没那么适用。
如何破解该难题：其核心便还是，持续的反馈。
项目进行时
项目难点的处理
项目中的直接阻碍，来源于项目本身需解决的问题。除了自然界的熵增，可自发的进行。逆熵行为，无一例外都会遇到困难。所以，问题并不可怕，特别是当你知道，如何处理时。
那么，如何处理项目中的难点呢？
第一，先检查约束条件。约束条件是指，项目的边界。诸如：时间、资源配给，期望的效果等。审视，项目一开始的条件，和当下条件的差异。时刻检查，条件是否发生了改变。
第二，反问自己。为什么需要解决这个问题，为什么你需要解决这个问题。问题的收益和付出，在不同层面，是都成正比的吗？如果是边界的问题，你能消除边界吗？最后，再问问自己，类似的问题，其解决方案是什么。
处理难题过程中，值得推荐的是：新建一个文档，记录思考和开发的过程。现实生活中，不同于考试做题，没有明确的对与错。记录开发过程，有助于养成主动思考的习惯。
用户共建，敏捷开发
在项目进行时，很重要的一点是：不能脱离用户，而是和用户共建。与直接的用户，形成良好的互动关系。不断提问，不断澄清。决策、实施、演示、反馈。
传统的工作模式，是瀑布流式的工作方式。一切都规划好，然后按部就班实施。瀑布流的好处是，能看到一个大的愿景。但其坏处，也很明显：不够灵活，容易需求延期、特性膨胀。
敏捷方式，则克服了瀑布流的缺点。整个是一个三步走流程。首先，评估当前的处境。然后，朝着预期的方向，做一次最小化的改进。最后，明确事情的边界，让事情先运转起来。敏捷也有其缺点：变更频繁；难以全局最优，常常陷入局部最优。
最后，在项目进行时，不要一个人埋头进去代码。参加代码评审等活动，了解和学习别人的代码优点，也能让自己的代码更鲁棒。同时，也别忘了，遇到问题，求助他人，也是一个解决问题的中上之道。
项目交付
项目的最终目标
项目交付，不是一锤子买卖。这项活动，是类服务业：其最终目的，是解决用户的需求，让用户愉悦。
要记住，用户需求的并不是代码，而是代码逻辑后的解决方案。
所以，过程可能并非那么重要。如何挖掘用户的期望，让用户满意，才更为重要。
以终为始，挖掘期望
如何挖掘期望，不如看看《高效能人士的七个习惯》之二——以终为始。让我们从项目结束的角度，思考和评判如何叫做成功。
一旦我们记住了从期望出发，项目交付就会容易很多。以期望出发，需要确保项目中的每个人都清楚该期望。在做决策时，也尽量选择靠近该期望的路径。根据现有期望，去分析用户的需求。如果有更好的方案，能满足用户期望，则大胆的提出需求变更。最后，随着项目的进行，不断地审视期望。
在项目交付时，签上你的名字。程序创造是一门艺术，留下签名，不仅是责任，同样也是自豪感的体现。
团队建设
以上活动，离不开团队。一个好的的团队，会让事情做起来事半功倍。如何打造优秀团队，使其成为项目的牢固支撑，也是项目推进的重要一环。
优秀团队的定义
首先看，优秀团队的画像。对内，成员及时沟通。DRY 不做重复的工作。对外交流，团队成员是个性独特、心情愉悦的。外界听到的声音，是一致的。这要求团队氛围活跃，同时也要求项目文档清晰、准确、一致。且在会晤前进行了充分的准备。
曳光弹开发
项目采用曳光弹的开发模式。
曳光弹，和敏捷的概念类似。在夜晚作战时，先打出一发曳光弹，照亮目标区域，以期后续能精准命中目标。曳光弹开发，要求：个体互动高于流程工具；软件支撑高于详细文档；客户合作高于合同谈判；响应变化高于遵循计划。
建设务实的团队
另外，建设一个务实的团队，也十分重要。务实不务虚。Talk is cheap, show me your code.
时刻评估变化
务实的团队，会时时刻刻留意周遭环境的变化。无论是项目范围的扩大、还是项目时间的缩短、抑或是增加了额外特性，都需要对变化进行度量。不顾大环境的改变，蒙头做自己的开发，乃大忌。
修补破窗，是每个人的责任
同时，项目内部也要提防破窗的蔓延。破窗效应，在软件开发和团队文化中的负面效应，都影响巨大。修复破窗，不是某个人单独的责任，QA兴许能发现功能的异常，但是编码风格的懒散、可读性的下降，是无法察觉的。
慎重选型，全面评估
在技术选型上，谨慎考虑最新技术。新技术，有它的优点，但也存在踩坑的可能。慎重考察，小规模测试，再考虑将其铺开，是较为稳妥的做法。不能因为道听途说，就在核心项目上大动干戈。
这对于新成员进入新团队，也类似道理。新成员会带来新视角和新技术。但改变现有体系，风险重重。最好的办法，也是在小项目上，进行实验。
记住，技术选型，其目标仍然是：交付起作用的东西。当然，极端保守也不行。一味守旧，迟早也会因为生产力低下、不适应市场变化，而被市场淘汰。
在管理上，也是类似道理。万万不可，因为对特定公司的盲目崇拜，就照搬其模式。
合理评估当下环境。市场相同吗，机会和挑战相同吗，组织规模相同吗，管理和文化相同吗，用户规模和需求相近吗？
问完这些，再针对问题进行改善，做局部的吸收，是更好的做法。
务实的团队支持
最后，在支持上，务实的团队，一方面会提供自动化工具，帮助完成自动化测试、部署以及交付；另一方面，也会给项目设定合理的边界，让项目在合适的时机停下，进行交付。