如何拯救即将延误的项目.pdfVIP

如何拯救即将延误的项目 最近有个 Tweet ，说项目延误时，如果同时又有很多人插手会使事情变得更糟糕。大多数团 队碰上截止期限都会干三件蠢事儿： 1 、雇佣更多开发人员。 2、抄近路。 3 、工作更长时 间——— jasongorman 这自然就产生了个问题：如何拯救即将延误的项目？ 其实，首先，最困难的问题，就是我们也许无法拯救即将延误的项目。所以，我不得不重新考虑 策略，只有两种方式我们可以考虑： 现在不是讨论团队如何和自己的消费者周旋，当我说 少提供点儿“ ”，我指的是少做些 程序“ ”——程 序多不代表有价值，多关注用户核心需求才是正事儿，其实就是别把一开始准备的那成堆功能递 出来。 这个过程差不多就是： 房子无法按期完成，但是你能如期入住。“ ” 如果你做的是 敏捷软件开发，估计现在已经发生了。如果还没发生，说明你恐怕做的不是 敏捷软件 开发。 解决方法就是要求我们知道最终目标也许跟程序无关。你得把关注重点从展示功能转移到解决问题 。然后你就能给自己带来设计的空间。在有限时间里更多选择能够成为解决问题的有效方式。 当我临危受任时，我首先做的就是停下手头一切，退一步问自己： 我们走到这儿到底想要什么？有“ 没有更简单的方式？ ”所以准备随时去掉设计和计划。在我个人拯救濒死项目的经历中，这是关键 。面对客户，准备些充分又坦率的对话。 但是，从 Tweet 的那三项注意事项里，我们能得到什么启发？甚至让项目时间延期。 雇佣开发人员早已被证明只会让事情变得更糟 在 Fred Brook 在图书 T he Mythical Man-Month 中对雇佣过多开发人员会加剧问题做了细致的原因 阐述。我相信任何软件开发者和软件开发项目经理都该读读。 做着糟糕产品的开发人员现在转变去催促着新的开发人员。这就像让最有效的销售人员充当管理 角色，结果就是看着销售量直线下降 ! 想要指标数值激增，最重要的就是团队内部都知晓每个人正在做什么，可悲的是，这在软件开发中 是必要的，因为联系是普遍存在的 —— 最需要进行斗争的就是失去最具生产力身居要职的开发者和 大体量团队效益的迅速递减。 因此，最简单的建议是别去做。不管你如何想要，或者承受上级多大的压力，千万不要这样做。 但如果队伍已经很庞大了呢 ?如果未完成任务的原因是因为团队开销拖你的后腿 ?在这里，你可能不 得不做出非常困难的决定，把相关人员转移到其他项目 —— 或把挡在路中间的无关人等放一边，再 不行最后只能辞退一些员工。 如果你有点儿头重脚轻，或有太多实习生，有可能能承受这种打击。另一方面，假设有 3 个建 筑师、 2 个项目经理、 6 个技术大神、 4 个业务分析师、 30 名开发者和 10 名测试人员 —— 就我个 人而言，很多的人正在享受实际工作福利。他们抱着酬劳，很多人很高的酬劳，但只是不为团队带 来一点儿价值。你付钱去让他们拖累你。我们都知道，但很少有人敢说出来。 在团队显然太臃肿的情况下，当你想要提供客户需要的有价值的东西，只有精简团队，否则几乎不 可能。 雇佣、重新分配或解雇这类有风险的决定通常不是我们这些人能够决定的，不过这种情况还是得有 人先打头哨。在这些情况下，默认行为是完全知情还选择失败。其实，这也是为团队好。 抄近路是经典错误，只要我们知道雇佣更多开发人员只会让事情变得更糟，我们更得知道牺牲质量 只会拖慢我们未来的发展。 原因很简单，证据确凿如就像活生生的喜马拉雅山脉。解决 Bugs 的时间越长，就会花费成倍的时 间和金钱。前期不注重测试和实验，未来修复 bug 就需要 10-100 倍的时间，不如早些解决，免得 下游海啸发生为时已晚。 你可以让团队专注 ” code-and-fix 发展进程，不用在意” bug 列表的大小，而把大量时间和精力用于 ” 稳定 ”应用软件，做好投放市场的准备。我目睹过圈子里几个月周而复始写代码，只为使其足够好到 可以应用。 所以内