第四十一期：一个项目正在走向失败

一个项目正在走向失败

自计算机被广泛使用以来，编写出来数以万计的程序。当我写这段文字的时候，可能又有无数的程序即将完成。然而，此次此刻，一个项目正在走向失败。

想象一下！一个没有正真技术创新的项目正在走向失败的深渊。很多程序不过是一个重复发明的轮子，经验老道的开发人员面临这样的项目总是能驾轻就熟。即便如此，在项目中付出的努力去南辕北辙，最终将项目推向失败。假设其中一个走向崩溃的项目已经结束，并邀请你来会诊。

假设在所有参与者寻觅到各自的借口之前，你有机会分析到底什么地方出了差错。自然，我们不会将项目遭遇滑铁卢归结于技术问题，一定是其他因素造成了项目的失败。

失败的原因

”政治“这个词是我们经常会归咎到的失败原因。但是这个词有很多不相关连以及松散关联的东西。比如:交流问题，人员安排问题，缺乏动力，高离职率等。

人们经常使用“政治”来描述所有与人相关的工作，但语言学对这些内容提供了更为准确的描述：它们构成了项目的社会学。真正的政治问题不过是这些病态特征的冰山一角而已。

倘若你认为一个问题属于政治的范畴，你会宿命般的逆来顺受。我们总是能直面技术的挑战，然而坦率的讲，我们又有几个人能自信的面对政治这个圈子呢? 认识到问题真正的本质分属社会学的范畴，而与政治无关，能帮助我们面对问题时更游刃有余。

项目或团队社会学也许超出了我们的专业范畴，但是却没有超出我们的能力之外。

我们工作中的问题更多的属于社会学范畴，而非技术范畴。

大多数管理者坦诚：他们对人的担心更多于对技术的担心。但他们很少以这种方式去管理。他们的管理方式总是以技术为主要关注点。

滋生这种现象的部分原因来自于管理者的提拔机制。对新晋管理者的训练是如何完成一项工作，而不是如何管理它。

人力商店

在生产环境中，很容易将人定义为是机器的零部件。零件磨损了你可以换个新的。新的部件可以和原来的进行互换。你定义的新部件，无论多少，都不过是数字而已。

很多技术Leader持相同的态度。他们竭力说服自己：没有人是不可替换的。正是因为 他们害怕关键人物会离去，于是强迫自己相信没有所谓的关键人物。

管理的本质不就是保证工作正常进行吗，不用去考虑个体的去或留吗? 他们的行为看起来就好像是有这么一个奇妙的人力商店，只需要拿起电话说：“给我派一个新的“尤雨希”过来，但是要让他那么高傲”。

稳定的项目濒临死亡

稳定的生成思维对项目工作尤为有害。我们很容易忘记的一件事情是：

项目的生命周期的最终目标就是要结束自己。

一个项目唯一的稳定期就是将死之时。除非你正在一个被取消或者将要取消的项目中，所有的项目管理关注点都应该投入到开发人员的动态调整上。然而在一个新项目中，我们衡量员工的价值却使用了稳定状态下的特征：他们写了多少代码，或者产出了多少文档。我们对于每个员工在整个开发投入中的切合度关注太少。

我们只是做事，没时间考虑工作自身

如果给你分配一个任务，你会花多少时间来真正实施这项任务? 不可能百之百，实施之前肯定需要做一些头脑风暴，调研新方法，找到规避一些子任务的方法，阅读相关材料，培训，以及试错。

回首我们作为管理者的那些年，我们都没有正确的认识到这一点。我们都花了太多的时间去做事，却没有花足够的时间提出关键问题，"这件事该不该做?" 稳定阶段的心态使得我们根本没有时间去思考这项工作。这种心态会推着我们把百分百的投入放到实施状态。倘若真要为没有时间思考寻找借口，那么这个接口永远是时间压力。

随着更多利益的介入，思考方法的重要性也显著提高。正所谓"磨刀不误砍柴工"，我们必须学习如何多花时间在思考上，少花时间在实施上。项目投入的越夸张，成员就越应该学习如何更好的协作，对这份工作的热爱也会变的更重要。项目越是需要在一个无法完成的固定时间交付，项目团队就不能缺乏频繁的头脑风暴，或者项目组聚餐之类的活动来帮助团队形成一个统一的整体。

但是，这些都是人文关怀。每个人都知道怎么做,对吗? 不对！在做事情上，我们都是如此的一根筋。我们花费不到5%的时间在计划，新方法调研，培训，读书，评估，预算，排期，人员安排这一系列活动上。

对于读书的统计结果：以软件开发人员的平均水平为例，平均每人没有一本和工作相关的书籍，甚至没有阅读过一本相关书籍。

这种现状，简直就是一场悲剧。