50 年的软件开发经验带给我的 63 个启示 - 信息谷 - ICITU

技术圈能够从业 50 年的开发者显得弥足珍贵，本文作者 Karl Wiegers 就是这样一位有着丰厚经验的软件行业从业者，在过去 50 年里，他积累了 63 条启示，并将其梳理分享出来，希望对你有所启发。

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

当然，在此过程中也完成了一些支线任务，比如读了有机化学的 PhD（我的论文有三分之一都是计算机代码），做了几年的研究员。但基本上来说，我是个软件行业的人。

在如此漫长的这段时间里，我积累了许多关于软件行业的见解。在本文里，我将跟大家分享 63 个启示，也许你也会像我一样觉得它们很有用。

2. 午餐后你在办公桌上发现的便签纸，保存下来的语音邮件和电子邮件，以及记得似是而非的走廊上的随意对话，所有这些都不能算得上是需求。这只是一堆信息而已。

3. 对于所有项目利益相关者来说，利益的交集在流程需求（Requirements Process）中发生得最多。

4. 如果缺少了高质量的需求，利益相关者们可能会对最后交付的内容感到倍感意外。在软件中，意外几乎总是坏消息的代名词。

6. 人们不应该只是去“收集”需求。需求获取是个探索，协作，发现和发明的过程，而不仅仅是简单的收集。一个商业分析师不仅仅要干抄写员的活。

7. 需求获取的目的是让客户的声音——即 VOC，voice of the customer——尽可能地贴近开发人员的耳朵——即 EOD，ear of the developer。商业分析师有助于缩小其中的沟通差距。

8. 对于需求获取，人们通常寄希望于两种方法：“心灵感应”和“千里眼”。但这两样都没用。

9. 不管我们的文化怎样宣称，但客户其实并不总是正确的。但是客户总是有他自己的意见的，而你必须理解以及尊重这个意见。

10. 需求开发需要迭代。你不能指望在第一次讨论中就 get 到所有的需求；要知道你可能永远也无法完全 get 到。有效的需求开发涉及对细节和清晰度的逐步改进。

14. 对于需求开发而言，比较实际的目标不是创建出的需求有多完美，而是创建出的需求足以使团队以可接受的风险水平进行建设。这种风险就在于，由于被忽视的，不必要，不完整，模棱两可或沟通不畅的情况下产出的需求，而不得不进行过多的计划外返工的情况。

15. 我们有时在表达需求时会比较随意，因为我们会假设读者有一个跟我们自己类似的“理性过滤器”，但是对于一段相同的陈述，人们经常会以不同的方式解读。这种模糊性会导致期望不匹配以及交付时的意外。

16. 把需求工作室和审核小组保持在一个较小的规模。一大群人连是否要离开一个起火了的房间的无法做到意见相同，更不用说在某项需求应该如何措辞上达成一致了。

17. 当有人提出新需求时，第一个要问的问题是：“这在我们的讨论范围之内吗？”如果是的，那就必须解决。如果不是，那就不解决，或者至少不是现在解决。但是，如果答案是“不是，但我们应该关注这个问题”，那么你必须调整范围来适应它。这对成本，进度，资源，参与度，优先级和效益折中都有影响。

18. 如果你没有一个记录在案且已达成共识的项目范围，怎么能知道自己是否正在经历范围蔓延？

19. 在决定要在一个产品或迭代中包含哪些功能时，请避免“分贝优先级”的做法（俗称按闹分配）。声音最大的那些客户所要求的功能从业务角度来说并不一定是最重要的。

20. 项目的利益相关者们必须能够理解，对可能的需求进行讨论与承诺将其包含在产品中之间是有区别的。

21. 有两个术语，你听到时一定要提高警惕：“假定需求”和“隐含需求”。要力争明确地交流需求的预期。

22. “项目管理”指的不是一项具体活动。项目管理是人员管理，需求管理，风险管理，机会管理，预期管理，承诺管理，变更管理，资源管理，以及供应商管理的混合物。

23. 为什么有些公司永远没有时间来好好地做出软件，而后续却总能挤出时间，金钱和人力来弥补？这是一个谜。

24. 每个人都愿意认为自己的团队拥有顶尖人才，但事实是在所有软件开发人员中有半数的能力都低于平均水平。那么这些人都在哪工作呢？

25. 不要轻易地评估任何人。如果别人请你评估，最合适的回复是：“让我先考虑一下，回头再与您联系吧。”

27. 如果你手上有很有说服力的数据，而对方几乎没有任何数据的话，你在谈判中就会占据优势地位。

28. 除非你把评估记录下来并将其与实际发生的情况进行比较，否则你将永远是在猜测，而不是在评估。

33. 质量应该是你的重中之重。高质量的自然结果就是长足的生产力，因为这样团队就不需要浪费太多时间进行返工了。

34. 力求能让一位同辈，而不是客户来发现缺陷。同辈技术评审是一种行之有效的技术，可以提高质量和生产力。

36. 当人们被要求改变自己的工作方式时，他们的本能反应是问“这对我有什么好处？”但其实这个问法是不对的。正确的问法应该是“这对我们团队有什么好处？”

37. 软件开发人员永远都在寻找出色的工具，但请记住，小傻瓜有了工具以后也只会变成大傻瓜。

38. 当人们不了解当前工作方式所导致的痛点在哪里时，进行流程更改是很难的。就像如果人们不知道自己家里有老鼠，就很难把更好的捕鼠器卖给他们。

39. 问：更换灯泡需要多少名软件过程负责人？答：只需要一个，但前提是灯泡必须愿意被更换。

40. 在朝着新的工作方式发展的过程中，不要低估改变组织文化的必要性和困难程度。实行一套新流程比灌输一种新文化更快。你需要在这两方面都做到成功。

42. 在许多情况下，常识，良好的判断力，以及经验应当比正式程序更重要。但是，有时候这个程序的存在是有充分理由的。在决定绕过它之前需要先调查一下。

44. 能促使人们改变工作方式的最好动力是痛苦。不是人为的，外部施加的痛苦，而是当前工作方式带给团队的非常真实的痛苦。选择那些可以最终减轻痛苦的改善活动吧。

45. 除非你花时间进行回顾，学习经验教训并不断改进团队的流程，否则没有理由来预期下一个项目能比上一个项目做得更好。

46. 你不能一下更改所有内容。找出那些能够带来最大收益的流程变更，并在下个周一开始实施。我没有开玩笑：就是下周一！

47. 对文档模板中采用“缩小以适应”的理念。先从一个丰富的模板开始，用来提醒你多考虑有哪些信息可以包含进去，然后再根据每个项目的规模，性质和需求来进行重塑。

48. 有许多团队都被要求做到事半功倍。不过，通常情况下，他们并没有能让自己事半功倍的方法。如果没有相应的培训和过程改进来提高效率和效果，就不要期望更高的生产力会神话般地自己显现。

49. 适用于四个在同一办公室里工作的人的非正式流程是无法扩展到在不同大陆工作的多个开发团队上面的。

50. 如果软件行业有什么东西是可复现的，那就是在一个又一个的项目上重复地做同样的蠢事。你需要通过回顾来学习，理解，以及不断改进。

51. 当人们不遵循既定流程时，你面前只有三种选择：（1）让人们开始遵循流程；（2）调整流程使其更加有效和实用，然后让人们遵循它；（3）放弃这个流程并不再假装你遵循这个过程。

55. 软件系统的许多问题都发生在接口上：软件和软件，软件和硬件，软件和人，人和人。这些接口需要好好研究。

56. 人们总是过多地谈论自己的“权利”。而每项权利的另一面都是责任。要以协作的心态去思考以及行动。

58. 要当心“商业周刊式的管理方式”——仅仅因为有人读到了它所承诺的极好结果，就匆忙地在软件开发中采用最热门的新事物。

59. 在拇指和食指之间保持一英寸的距离。在大多数情况下，这就是质量和垃圾之间的唯一区别。只在于多聆听一点，检查一下你的工作，再次运行测试，参考清单，阅读说明，再多问一个问题。通常，这是改善垃圾的唯一方法。

60. 你没有时间去重新犯一遍那些软件从业者之前犯过的错误。阅读并尊重文献。向你的同事学习。慷慨地与他人分享你的知识。

61. 软件开发中计算技术可能占 50％，剩下 50％在于交流沟通。但商业分析是完全在于交流沟通的。我们在计算方面要占得更多。

62. 如果你想自立门户做个独立顾问或承包商，则你需要向全世界宣告自己有空。如果没有人了解你，那不管你业务能力有多好都没用。

63. 在软件行业中，我们经常会假装。我们假装已经找到了合适的利益相关者，他们了解自己的业务目标，并且清楚自己的需求。我们假装合适的人向我们传达了正确的需求，且我们理解并准确地做了记录。我们假装我们的评估是准确的，且我们已经考虑到了所有必要的任务。我们假装所有可能会损害到我们项目的风险都不会真的出现。我不爱假装。有时候，我也不是那么喜欢现实，但我除了现实以外一无所有，所以我必须面对它。让我们停止假装吧。