1970年，我在大学上了第一门编程课（当然是FORTRAN）。在过去的半个世纪中，我花了很多时间从事软件工作：需求，设计，用户体验，编程，测试，项目管理，编写文档， 过程改进领导，撰写7本书和许多文章，进行咨询和培训。
当然，在这过程中还存在一些附带问题，例如获得有机化学博士学位（我的论文的三分之一是计算机代码）并担任研究科学家几年。 但基本上我是一个软件专家。
在过去的这段时间里，我积累了许多有关软件业务的见解。 在这里，我提供其中的64课。 也许您会发现它们像我一样有帮助。
紧跟需求
· 如果您没有正确地满足需求，那么执行其余项目的效果也就无关紧要。 你会失败的。
· 午餐后您在办公桌上发现的便签纸，已保存的语音邮件和电子邮件，以及一半记忆的随机走廊对话的收集不构成一组需求。 这只是一堆信息。
· 所有项目利益相关者的利益相交，在需求过程中无处不在。
· 没有高质量的需求，利益相关者可能会对所交付的内容感到惊讶。 软件惊喜几乎总是坏消息。
· 在探索需求时，请超越动手用户的范围。 您的客户一旦被移除，仍然是您的客户。
· 人们不只是"收集"需求。 需求激发是探索，协作，发现和发明的过程，而不是简单的收集过程。 业务分析师并非仅仅是抄写员。
· 激发需求的目的是使客户的声音-VOC-尽可能接近开发人员的耳朵-EOD。 业务分析师有助于缩小沟通差距。
· 两种常用的需求启发做法是心灵感应和千里眼。 他们不工作。
· 尽管我们的文化保持不变，但客户并不总是正确的。 但是客户总是有一个观点，您必须理解并尊重这一观点。
· 需求开发需要迭代。 在第一次讨论中，您不能完全满足所有要求； 您可能永远无法使它们正常。 有效的需求开发涉及对细节和清晰度的逐步改进。
· 不要担心记录要求。 与获取知识的成本相比，记录知识的成本很小。
· 如果要求中未描述某些功能或特性，则没人期望在产品中看到它。
· 需求开发的可交付成果不仅仅是一组书面需求。 这是一种共同的理解和一套共同的期望。
· 需求开发的现实目标不是创建一组完美的需求，而是创建足以使团队以可接受的风险水平进行建设的需求。 由于忽视，不必要，不完整，模棱两可或沟通不畅的需求，这种风险不得不进行过多的计划外返工。
· 我们有时会随意表达需求，因为我们假设读者拥有一个类似于我们自己的"敏感性过滤器"，但是人们经常以不同的方式解释相同的陈述。 这种含糊不清会导致不匹配的期望和交货时的意外。
· 保持需求研讨会和审核小组的规模。 一大群人不同意离开燃烧室，更不用说就某些措辞应如何确切达成一致了。
· 当有人提出新要求时，第一个要问的问题是："这是范围吗？" 如果是，则必须解决。 如果不是，则至少现在不会。 但是，如果答案是"不，但应该如此"，那么您必须调整范围以适应它。 这对成本，进度，资源，承诺，优先级和权衡都有影响。
· 如果您没有文档记录和已达成共识的项目范围，您怎么能知道自己是否正在经历范围蔓延？
· 在决定要在产品或迭代中包括哪些功能时，请避免"分贝优先级"。 从业务角度来看，最大的客户不一定需要那些最重要的功能。
· 项目涉众必须理解讨论可能的需求与承诺将其包含在产品中之间的区别。
· 应该使您的血液发冷的两个术语是"假定要求"和"隐含要求"。 力争明确传达需求期望。
论项目管理
· 没有"项目管理"这样的具体活动。 项目管理是人员管理，需求管理，风险管理，机会管理，期望管理，承诺管理，变更管理，资源管理和供应商管理的混合物。
· 为什么组织永远没有时间来正确地构建软件，却总是会花时间，金钱和人力来修复软件？ 这是一个谜。
· 每个人都喜欢认为自己的团队拥有顶尖人才，但是所有软件开发人员中有一半的文凭、能力都低于平均水平。 这些人在哪里工作？
· 不要给任何人以高估。 对估算请求的最佳答复是："在考虑之后，让我再与您联系。"
· 无论别人施加多大压力，都不要做出自己无法实现的承诺。
· 当您有可用的数据来审理案件时，您的谈判地位会更高，因为对方几乎可以肯定没有任何数据。
· 除非您记录您的估计并将其与实际发生的情况进行比较，否则您将永远是猜测，而不是估计。
· 您对某人的估算不应受到您认为他们想听到的声音的影响。
· 项目经理必须在以下五个关键方面中的至少一个方面具有一定的灵活性：范围，进度，人员，预算和质量。 如果将所有这些都强加为约束，那么您将失败。
质量与流程改进
· 关于软件质量，您可以现在付钱给我，或者以后再付给我更多。
· 力求完美； 追求卓越。
· 切勿让老板或客户说服您做坏事。
· 质量应该是您的重中之重。 长期的生产力是高质量的自然结果，因为团队不需要花太多时间进行浪费的返工。
· 力求让同伴而不是客户发现缺陷。 同行技术评审是一种行之有效的技术，可以提高质量和生产率。
· 如果您与不合理的人打交道，那么任何软件工程技术都不会起作用。
· 当人们被要求以不同的方式工作时，他们的本能反应是问"对我有什么帮助？" 但这是一个错误的问题。 正确的问题是"对我们有什么帮助？"
· 软件人员一直在寻找出色的工具，但请记住，使用工具的傻瓜只是放大的傻瓜。
· 当人们不了解当前工作方式所带来的痛苦时，很难进行流程更改。 很难向不知道有老鼠的人出售更好的捕鼠器。
· 问：更换灯泡需要多少软件过程负责人？ 答：只有一个，但灯泡必须愿意更换。
· 不要低估在朝着新的工作方式发展的过程中改变组织文化的需求和困难。 安装新流程比灌输新文化快。 你们都需要成功。
· 不管好意如何，没有转化为行动的改进行动计划都没有用。
· 在许多情况下，常识，良好的判断力和经验应胜过正式程序。 但是，有时该过程存在是有充分理由的。 在决定绕过它之前先查找一下。
· 在引导组织采用新的工作方式时，请施加不懈的压力。
· 改变人们工作方式的最好动力是痛苦。 这不是人为的，外部施加的痛苦，而是团队从当前工作方式中经历的非常真实的痛苦。 选择那些最终可以减轻痛苦的改善活动。
· 除非您花时间进行回顾，学习经验教训并不断改进团队的流程，否则没有理由期望下一个项目会比上一个项目做得更好。
· 您无法一次更改所有内容。 确定那些将带来最大收益的流程变更，并在下周一开始实施。 我不是在开玩笑：下周一！
· 在文档模板中采用"缩小以适应"的理念。 首先从一个丰富的模板开始，该模板可以提醒您考虑应该包含的信息，然后根据每个项目的规模，性质和需求来塑造它。
· 许多团队被要求事半功倍。 不过，通常情况下，他们没有获得使他们事半功倍的方法。 如果没有培训和流程改进来提高效率和效果，就不要期望神奇地实现更高的生产率。
· 对于在一个房间中工作的四个人来说可以正常工作的非正式流程，无法扩展到在不同大陆工作的多个开发团队。
· 如果软件行业可以重复做一件事，那么一个项目又一个项目地做着同样愚蠢的事情。 使用回顾来学习，理解和不断改进。
· 每当人们不遵循既定流程时，您只有三种选择：（1）开始遵循流程； （2）调整流程以使其更加有效和实用，然后加以遵循； 或（3）放弃该过程并停止假装您遵循该过程。
其他见解
· 人工智能不能替代真实事物。
· 在技术界，如果您比其他人早一个星期，那么您就是向导。
· 今天的"必须立即解决"开发项目是明天遗留系统维护的噩梦。
· 接口上会发生软件系统的许多问题：软件到软件，软件到硬件，软件到人，人到人。 仔细研究它们。
· 人们谈论他们的"权利"很多。 每一项权利的另一面都是责任。 协同思考并采取行动。
· 一盎司的设计值得一磅的重构。
· 当心"商业周刊的管理"，匆忙在软件开发中采用最热门的新事物，只是因为有人读到了它所承诺的惊人结果。
· 将拇指和食指分开一英寸。 在大多数情况下，这是质量和废话之间的唯一区别。 只是多听一点，检查工作，再次运行测试，参考清单，阅读说明，再问一个问题。 通常，这是弥补废话的唯一方法。
· 您没有时间在每位软件从业人员犯错之前就犯错。 阅读并尊重文学作品。 向您的同事学习。 与他人自由分享您的知识。
· 软件开发可能占计算的50％，有关通信的占50％。 但是业务分析完全是关于沟通的。 我们在计算方面要好得多。
· 如果您想充当独立顾问或承包商的角色，则需要向全世界告知您有空。 如果没有人知道你在那里，你有多好都没关系。
· 我们在软件中做很多假装。 我们假装已经找到了合适的利益相关者，他们了解他们的业务目标，并且知道他们的要求。 我们假装合适的人向我们传达了正确的要求，并且我们理解它们并准确记录了它们。 我们假装我们的估算是准确的，并且已经考虑了所有必要的任务。 我们假装不会破坏我们项目的任何风险。 我不喜欢假装。 有时候，我对现实并不那么疯狂，但这就是我所拥有的，所以我必须面对现实。 让我们停止假装。
