Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

那些做了一半的项目

Posted on 04/12/202007/04/2022 by 四火

最近有一个项目做了一半不做了,准确地说是由于某些原因,项目需要别的团队来接手了,于是我想随便聊聊这个话题。我猜想,“项目做一半撒手”,这应该是一个很常见的现象,因为这样的事情无论大厂小厂,在软件的世界里不断上演。具体来说,有这样几种典型的情况:

  • 业务变动、组织调整,工作重心变了,项目做了一半直接砍掉,或者无限期停工。这大概是最常见的一种情形。
  • 由于前期的调研、设计的严重问题,或是市场等变化过于剧烈,项目做不下去了,静悄悄地黄了。
  • 项目还做,但是转交给某个其它的团队,这是我这一次遇到的情形。项目还存在,只不过所属关系已经发生变更。

文档和隐性成本

无论哪一种,有一点是毫无疑问的,那就是资源投入的浪费,无论是软件还是硬件。即便不砍掉,暂停一段时间,再恢复的时候,要捡起曾经的项目,一样需要一定的成本。而项目要转交给其它团队,软件的交接成本也相当可观。其实这没有什么奇怪的,这是软件的本质所决定的。具体来说,软件开发,特别是上规模的软件开发,就意味着大量的 “隐性成本”。

从项目管理的角度来说,我们当然希望规范而且具体,或者说,大家都照章办事,项目设计可以纸面化,事无巨细地把 “为什么要这样做”,和 “‘这样做’ 是 ‘怎样做’ 的” 这样的信息都落地成文字交代清楚。可是你我程序员都知道,这是遗憾到不可能发生的事情。我在中国的大厂待过,也在北美的大厂待过,有个别经历的团队和项目甚至被内部外部视作典范,可是客观地说,文档依然缺失,而且不是缺失一点,而是大量地缺失,再好的项目也是如此。有一个有意思的网站,叫做 Killed by Google,上面记录了被 Google 砍掉的项目。

其实,这并不是什么不可理喻的事情,相反,如果一个一定规模的软件项目,文档清清楚楚,把项目事项和设计细节都交代得清清楚楚,我反而觉得这个项目有着猫腻。因为代码和文档永远有着显著而不可调和的矛盾。为什么呢?因为对于软件工程师来说,一个且只有一个真正的、准确的数据来源(Single Source of Truth),是值得推崇的最佳实践。这样的指导思想是根植于他们脑海中的,一个凡是对 Engineering Excellence 有着追求的程序员,一定会把它放在相当重要的位置。而在多数情况下,文档和代码就是两个数据来源,且无法被统一,但是你我都知道,真正工作的一定是代码,代码才是真正的 source of truth,文档只能成为不断过时的那一个。

我知道一定会有声音说,难道不能及时更新文档吗?比方说,代码逻辑修改了,修改的工程师也负责更新文档。没错,但这过于理想化了,而且,就好像软件的世界里一致性和可用性经常是难以调和的矛盾一样,文档的细致程度,和保持准确性的能力,也一样是难以调和的:文档越是细致,就约难以被及时更新,也就越容易成为过时的文档。文档的更新,不但涉及到工作量的问题,它本身也不符合很多工程师基于代码的思维习惯,因为它的读者有了变化,而且叙述的方式也有了变化;再者,真正在业务中直接生效的,也是代码,文档相应地,总是显得那么间接。

对于大多数工程师来说,特别是某些踏入职场时间并不长的工程师来说,文档的地位要更低一些。就好像 “talk is cheap, show me the code” 已经被不可思议地滥用一样,他们对于代码有着过度的狂热。这原本不是什么坏事,软件工程师总是要立足的代码的,可是,软件工程所谓工程,它一定是一个复杂的结合体,代码只能是其中一部分,有时甚至只是一小部分。随着时间和阅历的增加,越发觉得合适的文档在软件工程中的价值,比方说,就在几年前,关于文档我的一点思考记录在这里,现在其实也已经有了更新。

再回到隐性成本的话题上来。已经说了,在文档缺失或过时的情况下,程序员需要去理解需求,并阅读代码来理解前前后后整个故事,这里面的时间成本和试错成本可想而知,可退一步说,哪怕真的文档齐全,要把这些东西消化掉,也依然需要大量的时间。我们都说程序员是一个终生学习的职业,而每一个项目,就是一个可观测的学习的单元。

是勇气还是荒唐?

这样的决定很多时候并不容易做出。我经历过的多数情况,都来自自上而下的决策。有时候部门调整(reorg),结果一些项目的重要性就发生变更,直接砍掉了。而甚至有时候整个部门或团队都砍掉了,我在亚马逊的时候就经历了这么一回,一个原本负责商品在欧洲内各个国家之间方便流通的团队就这样直接砍掉了,当时作为团队里的一份子,我获得了几个 “下家” 团队的选项。也就是说,工程师重新回归资源池,重新分配归属团队。

但也经历过自下而上的,做过的某个内部应用,本来也是摸着石头过河,第一个版本做出交付了,却发现可用性还是比较差,具体说就是流程还是过于苛刻和冗长,而这个问题又不是一个比较容易解决的问题,很难把它继续推广开去,因此这个项目就烂在半途中了。虽说不能说项目砍掉了,但已经低优先级、无限期搁置了,也就和砍掉没有什么太大区别了。

多数时候,这样的损失并不只有纸面上能看到的 “浪费” 那么简单。除了上面所说的隐性成本,还有对团队士气的打击。但是,这里面有一个值得玩味的话题,当一个团队全身心地、毫无保留地投身奉献于一个项目的时候,这里的风险就很容易不可控了。有一位团队经理给下属画饼的时候说过,“你要把 xxx 项目当做你自己的孩子一样”,无疑这对于传递 ownership 的精神,是一个很形象的比喻,可是项目可能会黄,到时候该怎么收场呢?因此我觉得这不是一个特别职业的表达。

最后,回想起来,这种 “做了一半的项目” 还真是挺常见的。非常遗憾,可对于一个大型的组织来说,回头是岸,及时止损,通常可不是坏事。这样的决定无疑需要勇气,更糟的结果是继续这个项目,决策下的越晚损失越大。软件工程似乎就是这样一个无完美解的难题,处处充满了看似可以避免的弯路和糟糕实践,可是换个项目重来一遍的时候,还是一样有这样那样的问题。这有点像是人生,大道理我们都懂,可还是过不好这一生。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 几种华丽无比的开发方式
  2. 多吹牛,少写代码
  3. 文档那些事儿
  4. 关于 Jeff Dean 的几个搞笑传言
  5. Dart:JavaScript 的未来

4 thoughts on “那些做了一半的项目”

  1. thinkkdancer says:
    12/26/2020 at 6:57 PM

    前几年做项目的时候也想过这个问题,因为也经历了几次项目被砍掉或者转交其他人的经历,所以有一些感受和想法。

    首先从感受上还是有些打击,因为毕竟花费了时间,精力去做,突然不做了就会有空虚感,缺少完成时候的成就感。其次是对自己的价值的质疑,进而通过项目的中断来否认自己,这里需要会调整自己,总结反思,即是是失败的项目或者中断的项目也是有收获的地方。最后是对下一个项目的期待和谨慎,失败是成功之母,母亲孕育和生育孩子是漫长而痛苦的,迁移到项目上也是这个道理。这种挫折的状态可能是常态,需要我们不断去适应,及时作出改变。

    Reply
  2. Dennis says:
    09/11/2020 at 2:45 AM

    我觉得文档能把 why 写出来就好了,就是这个地方为什么要这样设计,为什么采用 A 方案没有采用 B 方案?
    文档确实会过时,代码总是最新的。

    Reply
    1. 四火 says:
      09/11/2020 at 5:49 PM

      第一句话我不太敢苟同;至于第二句话,说的没错,但是很多情况下,过时的文档作用依然大了去了。

      Reply
  3. Niven says:
    04/15/2020 at 5:58 PM

    关于文档的描述,确实深有感触。我是做产品的,写需求文档是本职工作。一句话需求固然不可取,但是洋洋洒洒几十页的需求文档,其实研发也并不喜欢。他们通常会按照自己的理解开工,中途不断修正。通常最终做出来的东西,都会有那么一点点偏差。每个版本积累一点点差异,时间久了,后来者接手的话,光靠文档,可能会有点懵。。。

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme