大道至易:实践者的思想(五十八):谋定后动,项目的存在权——自己想办法(拉屎就算是一项工程,具体来说,也得自己拉)

阅读数:20 2019 年 10 月 10 日 14:48

大道至易:实践者的思想(五十八):谋定后动,项目的存在权——自己想办法(拉屎就算是一项工程,具体来说,也得自己拉)

无论敏捷工程还是传统工程,都是无法为你正在做的这件事提供直接答案的。

这件事得自己努力。

一个具体化的工程涉及三个方面的问题:人与团队,产品与用户,项目与方向。如果这些东西要被“系统化地”组织在一起,必然是需要将它视为“一件事”的,这也是它被“立项”的目的。如果这一前提不存在,则产品只是用户调研、产品设计或产品线上的一个规划,而团队则可以简单地视作“一群人”。只有要做一件事,这三个方面的东西才发生了关系,也才交织在一起成了“问题”。

要开始做“这件事”,会有不少的前提条件。例如,作为一个项目经理,你或许要求“先做三个月技术培训,再开始开发”。但事实上这些都算不上“前提”,因为你显然也可以不这么做就匆匆上马——只要你有机会在团队行进中调整大家的步伐。唯一能作为“开始这件事”的充要条件的,事实上只有一个决策性的判断:我们是否需要用工程化的方法来实现一个产品目标。这里涉及下面三点细节。

(1) 是软件产品吗?如果这不是一个需要“软件生产”的产品,则它可能不需要“软件开发”这一过程,固而也就不需要我们的软件工程。例如,市场部门需要了解客户反馈,那么它既可以实现为一个在线聊天的客服机器人,也可以实现为包含大量职员的客服部门。而后者显然是不需要“软件生产”的。

(2) 需要开发吗?即使是一个软件产品,获得它的方法也可能不是“软件开发方法”。例如,上述的“在线聊天客服机器人”,如果我们将它作为一个产品外包,那么“外包”这件事对于我们来说就是一个供需管理,而不是“工程化”的软件开发活动。

(3) 需要工程化方法吗?一个研发性软件产品的开发过程,可能不是“工程化”的。例如,我们真的要在公司内立项来做上面这个产品,但我们只分配了一个开发人员或一个临时小组,产出的产品也不用于市场销售,对时间的控制也可以放得很宽轻,而且最为重要的事情是,假定这个项目是基于技术研究的,因而当它失败了也不会有什么负担,那么我们便不需要考虑“是不是需要一个工程化的软件开发方法”。

当决策判断发生了,当“应作为一个工程化的软件产品来予以立项”成为事实的时候4,产品、团队与项目三者就必须立即成为“具有相同目标”的一个合作群体。这个相同目标,就是“做一件事”;这个相同目标中的道德原则也只有一个,就是“做完”。

4 事实上三种情况的反例都是可以“立项”的,譬如组织建设或人力规划的项目,企业资产购置与管理的项目,实验性项目。它们作为项目是满足“时间、质量与成本”这样的项目要素的设定的,但却都不是工程化的。

我知道有一个项目,一个做了整整五年的项目。在项目坚持了这么久之后,是什么在支持着这个团队还保持着追求成功的激情?就这个问题,一个普通成员的回答典型、普遍而又发人深省:

“在我们的头脑里,完成一个项目是最最重要的事情。”一位成员说:“即使我们不喜欢这里,我们也不会让项目流产,我们宁愿先完成项目,然后在第二天辞职。”

这个团队就是 Windows NT 4.0 的开发团队。在读《观止——微软创建 NT 和未来的夺命狂奔》这本书的过程中,这名普通的甚至没有在这本书中留下名字的成员,说出了让我如此印象深刻的话。这样的普通成员,正是这个团队整体的职业精神的缩影。

回顾这本《观止——微软创建 NT 和未来的夺命狂奔》,我们是无法孤立地站到团队、项目与产品三个视角之任一来思考的。从根本上,具体工程最重要的话题就是这三个视角必须是统一的、系统的以及面向具体的“一件事”的。

评论

发布