https://medium.com/swlh/62-lessons-from-50-years-of-software-experience-2db0f400f706

1970年，我在大学上了第一门编程课（当然是FORTRAN）。在过去的半个世纪中，我花了很多时间从事软件工作：需求，设计，用户体验，编程，测试，项目管理，编写文档，过程改进，撰写7本书和许多文章，提供咨询和培训。

当然，在此过程中也有做一些其它事情，例如获得有机化学博士学位（我的论文的三分之一是计算机代码）并做了几年科研。但基本上我是一名软件工程师。

在过去的这段时间里，我积累了许多有关软件行业的经验。在这里，我总结了 63 条经验。也许您会发现它们会有一些有帮助。

需求层面

1) 如果没有正确地理解需求，那么不管后面的工作做得再好，项目都会失败。

2) 午餐后您在办公桌上找到的便签条，已保存的语音邮件和电子邮件，以及只有一半记忆的走廊随机对话的收集都不构成一组需求。这只是一堆信息。

3) 所有项目利益相关者的利益相交，在需求整理过程中无处不在。

4) 没有高质量的需求，利益相关者可能会对所交付的内容感到惊讶。软件给出的惊喜几乎总是坏消息。

5) 在分析需求时，请跳出手上所拥有的用户的范围。您的客户即便从清单中移除也仍然是您的客户。

6) 不应当只是简单地“收集”需求。需求启发是一个探索，协作，发现和发明的过程，而不是简单的收集过程。业务分析师并非仅仅是抄写员。

7) 激发需求的目的是尽可能将客户的声音（VOC）带给开发人员（EOD）。业务分析师有助于缩小这种沟通的鸿沟。

8) 两种常用的需求启发做法是心灵感应(telepathy)和洞察力(clairvoyance)。不过没有什么用处。

9) 客户并不总是正确的。但是客户总是会有一些观点，必须理解并尊重这些观点。

10) 需求开发需要迭代。在第一次讨论中，您无法完全获取到所有要求；您可能永远无法保证所有的事情都正确。有效的需求开发是对细节和清晰度的逐步改进。

11) 不要害怕写文档。与获取知识的成本相比，记录知识的成本很小。

12) 如果需求中没有描述某些功能或特性，那么没人期望在产品中看到它。

13) 需求开发的可交付成果不仅仅是一组书面需求。还是一种共同的理解和共同的期望。

14) 需求开发的现实目标不是创建一组完美的需求，而是创建在可接受的风险范围内可以使团队推进工作的需求。由于忽视、不必要、不完整、模棱两可或沟通不畅的需求，这种风险会导致过多的计划外返工。

15) 我们有时会随意表达需求，因为我们会假设读者拥有一个和自己一样的“敏感性过滤器”，但是人们经常以不同的方式解释相同的陈述。这种含糊不清会导致不匹配的期望和非预期的交付。

16) 保持需求研讨会和审核小组的规模。众口难调，更不用说就某些需求的措辞应该如何达成一致了。

17) 当有人提出新要求时，第一个要问的问题是：“这是现有范围内的吗？”如果是，则必须处理。如果不是，那么不用理会，至少不是现在。但是，如果答案是“不是，但应该如此”，那么您必须调整范围以适应它。这会影响成本、进度、资源、承诺、优先级和权衡等各种问题。

18) 如果您没有记录记录和已达成共识的项目范围，您怎么能知道自己是否正在经历需求范围的蔓延呢？

19) 在确定要包含在产品或迭代中的功能时，请避免“分贝优先级”。从业务的角度来看，喊声最大的客户不一定需要那些最重要的功能。

20) 项目相关人员必须理解一个区别，即讨论可能的需求与承诺将其包含在产品中之间的区别。

21) 应该避而远之的两个术语是“假定需求”和“隐含需求”。力争明确传达需求期望。

项目管理层面

1) 没有“项目管理”这样的具体活动。项目管理是人员管理、需求管理、风险管理、机会管理、期望管理、提交管理、变更管理、资源管理和供应商管理的集合。

2) 为什么组织永远没有时间来正确地构建软件，却总是花时间，金钱和人员来进行后续修复？这是一个谜。

3) 每个人都喜欢和顶尖人才在一个团队，但是所有软件开发人员中有一半的能力都低于平均水平。这些人在干什么呢？

4) 不要给任何人过高的预算。对评算请求的最佳答复是：“在我深入考虑之后，我会再次与您联系。”

5) 无论别人施加多大压力，都不要做出自己无法实现的承诺。

6) 当您有可用的数据来支持自己时，您的谈判地位会更高，因为对方几乎可以肯定没有任何数据。

7) 除非您记录您的预算并将其与实际发生的情况进行比较，否则您将永远是猜测，而不是预算。

8) 您给某人的预算不应受到您认为这是他们想听到的声音的影响。

质量与流程改进

1) 关于软件质量，您可以现在交付一些，或者以后再交付更多。

2) 力求完美；追求卓越。

3) 切勿让老板或客户说服您把事情搞砸。

4) 质量应该是您的重中之重。长期的生产力是高质量的自然结果，因为团队不需要花太多时间进行耗费的返工。

5) 力求让同伴而不是客户发现缺陷。同行技术评审是一种行之有效的技术，可以提高质量和生产率。

6) 如果您与错误的人打交道，那么任何软件工程技术都不会起作用。

7) 当人们被要求以不同的方式工作时，他们的本能反应是问“对我有什么帮助？”但这是一个错误的问题。正确的问题是“对我们有什么帮助？”

8) 软件人员一直在寻找出色的工具，但请记住，使用工具的傻瓜只是一个大的傻瓜。

9) 当人们不了解当前工作方式所带来的痛苦时，很难进行流程改进。很难向不知道有老鼠的人出售更好的捕鼠器。

10) 问：更换灯泡需要多少软件过程负责人？答：只有一个，但灯泡必须愿意更换。

11) 不要低估在朝着新的工作方式发展的过程中改变组织文化的需求和困难。安装新应用比灌输新文化快。这两方面都需要成功。

12) 不管意图有多好，没有转化为行动的改进行动计划都无济于事。

13) 在许多情况下，常识、良好的判断力和经验应胜过常规流程。但是，流程的存在是有充分理由的。在决定绕过它之前先审视一下。

14) 在引导组织采用新的工作方式时，请坚持不懈地慢慢地施加压力。

15) 改变人们工作方式的最好动力是痛苦。这不是人为的，外部施加的痛苦，而是团队从当前工作方式中经历的真正痛苦。选择那些最终可以减轻痛苦的改善行动。

16) 除非您花时间回顾，学习经验教训并不断改进团队的流程，否则没有理由期望下一个项目会比上一个项目做得更好。

17) 您无法一次改变所有东西。确定那些将带来最大收益的流程变更，并在下周一开始实施。我不是在开玩笑：下周一！

18) 在文档模板中采用“缩小以适应”的理念。首先从一个丰富的模板开始，该模板可以提醒您考虑应该包括的信息，然后根据每个项目的规模、性质和需求来塑造它。

19) 许多团队被要求事半功倍。不过，通常情况下，他们没有获得使他们事半功倍的方法。如果不进行培训和流程改进以提高效率和效果，就不要指望神奇地实现更高的生产率。

20) 对于在一个房间中工作的四个人来说正常的非正式流程无法扩展到在不同大陆工作的多个开发团队。

21) 如果软件行业可以重复做一件事，那么只是一个项目又一个项目地做着同样愚蠢的事情。通过复盘来学习，理解和不断改进。

21) 每当人们不遵循既定流程时，您只有三种选择：（1）开始遵循流程；（2）调整流程以使其更加有效和实用，然后加以遵循；或（3）放弃该流程并停止假装您正在遵循该流程。

其他见解

1) 人工智能不能替代真实事物。

2) 在技术界，如果您比其他人早一个星期，那么您就是导师。

3) 今天的“必须立即解决”开发项目是明天遗留系统维护的噩梦。

4) 软件系统的许多问题会出现在接口上：软件到软件，软件到硬件，软件到人，人到人。仔细研究它们。

5) 人们会经常讨论他们的“权利”。每一项权利的另一面都是责任。协同思考并采取行动。

6) 一盎司的设计值得一磅的重构。

7) 当心“商业周刊的管理”，这是在软件开发中急于采用最热门的新事物的原因，因为有人读到了它所承诺的惊人结果。

8) 将拇指和食指分开一英寸。在大多数情况下，这是质量和废话之间的唯一区别。只是多听一点，检查工作，再次运行测试，参考清单，阅读说明，再问一个问题。通常，这是弥补废话的唯一方法。

9) 您没有时间在每位软件从业人员犯过的错都犯一遍。阅读并尊重别人的作品。向您的同事学习。与他人自由分享您的知识。

10) 软件开发时间中，编码可能占总时间的50％，沟通占了另外50％。但是业务分析完全是通过沟通的。我们在计算方面要好得多。

11) 如果您想充当独立顾问或承包商的角色，则需要向全世界告知您有空。如果没有人知道你在那里，你有多好都没有用。

12) 我们在软件中做很多假设。我们假设已经找到了合适的利益相关者，他们了解他们的业务目标，并且知道他们的需求。我们假设合适的人向我们传达了正确的要求，并且我们理解它们并准确记录了它们。我们假设我们的估算是准确的，并且已经考虑了所有必要的任务。我们假设不会破坏我们项目的任何风险。我不喜欢假设。有时候，我对现实并不那么疯狂，但这就是我所拥有的，所以我必须面对现实。让我们停止假设。

小结

Karl Wiegers 在需求、质量和流程改进方面的工作在软件界众所周知。如果您对软件需求，业务分析，项目管理，软件质量或咨询感兴趣，Process Impact 提供了许多有用的出版物，下载和其他资源。