项目深坑：我能做什么？
当开发者陷入“项目深坑”时，他能做什么？
这是一系列文章，讨论了开发人员在工作中可能遇到的情况。之前关于工作问题的文章是：
引言
有大量的文章和“软技能”文献可以帮助开发人员在其职业生涯中取得成功。它们讨论了许多实际的，有时是不切实际的步骤，可以帮助事业发展。这些都是完美的指南，但它们有一个假设，即开发人员需要比同行更进一步，否则他们就是默默无闻的一员。它们教授如何成为佼佼者，脱颖而出。
但是，有些情况是，开发人员已经在一个项目中陷入了深深的困境，现在只想在考虑事业发展之前全身而退。本文将探讨“如何生存”的概念，以便将自己带回到一个公平的竞争环境中。
我将以我看到和经历过的一些真实生活场景为例，阐述每个人如何脱困以及从中吸取的教训。
背景
我十五年前开始我的职业生涯，经历了许多起伏。我遇到过非凡的个体，也遇到过完全 clueless 的人。这两种经历都给了我宝贵的一课，教会我如何在一个动态的行业中处理自己。有许多案例，人们因为无法摆脱自己挖的坑而毁掉了自己的职业生涯。
文中提到的“故事”灵感来自真实事件，但已进行过删改。
什么是项目深坑？
任何参与过复杂项目或其他工作的人都会轻易地认出“深坑”。他可能会给它取一些更“贴切”的名字，但归根结底（无意双关）是项目的那个阶段，我们看不到任何解决方案、截止日期或复苏的途径。项目似乎在原地打转，没人知道如何前进，甚至根本不知道该往哪个方向走。整个团队都在寻求神助，或者希望有人能指导项目走向正轨。在某些情况下，整个项目被搁置，或者有人被解雇，或者个人遭遇不幸。
深坑并非罕见事件，实际上在许多项目中非常普遍。但我想指出一个概念。“深坑”或深渊对于任何项目都包含三个阶段。它们是：
- 陷入深坑之路
- 深坑
- 走出深坑
总的来说，人们不会区分以上阶段。对他们来说，这只是一个巨大的地狱深坑。但我希望区分每个阶段并稍作解释。在救火过程中，每个人都处于高度紧张状态，这往往会进一步加剧问题。所以我们应该尝试采取一些简单但重要的步骤来恢复。
陷入深坑之路
实际上，所有项目都会遇到瓶颈，而每一次瓶颈都有可能导致项目陷入恶性循环。正是各种检查和平衡机制，当然还有相关个人的能力，阻止了项目演变成一场灾难。
永远不要欺骗他人和自己。
我们当时正在开发一个电信计费系统，该系统包含三个模块：核心引擎、用户界面和数据库模块。“引擎”是软件的大脑，根据 UI 的输入进行计算。“引擎”是一个没有任何输入值验证的算法。也就是说，UI 负责验证用户输入。“引擎”的假设是它接收的数据是正确、有效且在范围内的。在我们每周的例会上，每个开发人员都要汇报进度。UI 开发人员总是夸大其词，说他的任务按计划进行或已完成。不幸的是，他撒谎，希望之后能赶上进度。最终，在他撒谎的事情首次被揭露（在软件的第一次部分上线时）后，整个项目都成了灾难，陷入了深渊。
他敷衍的报告可能有很多原因，比如新技术、害怕被嘲笑或纯粹的懒惰。如果他从第一天起就诚实，那么他就会得到他人的帮助或更好的指导。他欺骗自己，认为自己可以按时完成任务。向同事和上级汇报不准确的进度是没有意义的。短期内可能看起来很明智，但 nothing good comes from it.
超越你的模块
开发人员通常都很聪明，能够解决复杂的问题，但有时他们会目光短浅。看到整个项目的发展情况，而不是只专注于自己的模块，总是很有意义的。如果技术人员能有一个外部视角，在潜在问题爆发前发现它，那总是很有用的。
在上面提到的同一个项目中，许多开发人员都参与了“引擎”部分的工作。其中一个要求是使用“String”数据类型。是否是“NULL”终止没有被提及。结果，有些人假设它是“NULL”终止并用该数据类型工作。直到新来的 UI 开发人员（替换了一个）在阅读了早期同行评审的报告后，出于好奇指出了这个错误，才及时被发现。团队有足够的时间重新开发新算法，节省了宝贵的时间。
我们作为开发人员的一个问题是，我们把自己的工作视为个人领域，不喜欢别人窥探。这种方法有利有弊，但我个人认为，多一双眼睛从来不会造成太大伤害。
深坑
无论我们付出多少努力，都可能有一些情况导致项目真的陷入深渊。这时，每个人都如坐针毡，表情紧张。正常的软件开发流程被抛诸脑后，人们只是拼命工作，试图让项目回到正轨。在救火模式下，有几点需要考虑。
一天由 8-10 小时构成
在这个阶段，每个人都尽最大努力来挽救项目。管理层放弃了常规的截止日期/里程碑，设定了更短的目标。列出困扰项目的所有问题，并要求新的截止日期。给所有开发人员一个警告：在这种情况下，有额外的眼睛在盯着他们，他们承受着巨大的压力去交付和表现。所以，考虑到这一点，他们给出的估算假设他们将工作 24 小时，这是不可能的。如果任务需要 20 小时，请现实一点，清楚地说这需要至少 2 天来完成，因为你假设一天是 10 小时。轮班工作可以持续一天，或者你离解决方案很近。实际上，开发人员需要花费数天或数周来恢复项目。连续几周每天工作 20-22 小时是不可能的，这会导致倦怠。要永远假设你正在跑马拉松，只在看到终点线时才冲刺。
按天 vs. 按小时估算。
如前所述，危机期间，几位额外的管理人员会介入并监控情况。当他们询问完成“X”任务需要多长时间时，开发人员需要确定在这种情况下通常遵循什么时间单位。一个实际需要 16 小时的任务，应该被视为 2 天，而不是 1 天（24 小时）。在几次场合，我说我会在 2 个工作日内完成任务，这实际上是 40 小时，但利益相关者对 2 个工作日的解释是错误的。所以，请务必确保所有人在新截止日期上达成一致。我亲眼见过经理们有不同的想法。有些人喜欢小时，有些人喜欢工作日，有些人只想知道结束日期。
我个人总是选择按小时谈论，但提供最终的结束日期，因为它能更清楚地表明完成任务所需的努力和明确的截止日期。
谈话
假设
上述情况在正常的项目讨论中经常发生，但我们有足够的时间来纠正。但在救火阶段，细节常常被忽略，导致进一步的问题。
寻求帮助并不可耻。
在一个涉及 T-SQL 的项目中，有几名成员在关键阶段中期离开了公司。作为临时的应急安排，任何在求职申请或个人资料中提到“SQL”的人都被安排到这个项目中来恢复正常。我的一位同事的个人资料中写了 SQL 是她的一个优势，但实际上她只是一个新手。她因为害怕丢脸而保持沉默，但努力学习技巧。当她遇到困难时，她没有向任何人寻求帮助，而是告诉我她的沮丧。幸运的是，我能够让一个人去帮助她，故事就这样继续了。在我看来，承认自己卡住了并且需要帮助并不可耻。同事们可能不是我们最好的朋友，但他们在需要时会提供帮助。当水位已经淹没头部时，让项目和自己陷入更大的困境是没有意义的。
走出深坑
现在是每个人都付出了最大的努力，并将项目带回恢复模式的时候了。人们可以看到进展，并意识到他们正在逐步恢复正常。这是一个比身处开发地狱更好的地方。气氛更加积极，人们开始思考如何加速恢复正常。这也是人们开始担心项目灾难的余波的阶段。有些人必须面对后果，这就是情况的本质。但可以采取一些措施，使这个阶段尽可能富有成效，减少进一步的痛苦。
放松，但不要懈怠。
现在不是懈怠、放松手头任务的时候。项目还没有脱离困境，这是最糟糕的懈怠时机。积极的能量和努力应该滚雪球般地加速恢复，而不是倒退并失去信誉。懈怠的一个主要原因是有时会筋疲力尽，这就是为什么开发人员必须决定这次开发深坑是场马拉松还是冲刺。
我见过许多项目由于缺乏专注而陷入循环的恢复和重置。
不要指责，只关注吸取的教训。
每个人都必须记住，项目还没有完成，需要保持团队的体面。没有必要在失败或任何意外事件上指责他人。正如那句名言
引用公开赞扬，私下批评
务必不要公开指责。目的是列出出了什么问题以及如何从过去的错误中学习，以便项目不再陷入恶性循环。你不希望由于“天才”开发人员的敌对态度而导致人员大量流失。
结论和一句警告
上述讨论并非什么新鲜事，应该在所有情况下都遵循。但在正常的开发阶段，有足够的检查来处理任何意外。在项目深坑期间，开发人员倾向于超负荷工作，忽略一些基本但显而易见的开发步骤。的确，在成熟的组织中，正常的 SDLC 在开发深坑期间仍然有效。在许多中小型企业中，我们被迫“临场应变”来解决问题。
历史
- 2015 年 7 月 13 日 - 首次发布