50000
在科技圈50年的开发者，弥足珍贵。本文作者Karl Wiegers就是这样一位经验丰富的软件行业从业者。50年来，他积累了63个灵感，分享出来，希望对你有所启发。
作者|卡尔·威格斯，译者|香槟超新星
编辑|唐
标题图|东方IC下载的CSDN
出品| csdn (ID: csdnnews)
以下是翻译:
1970年，我上了大学的第一堂编程课(当然，我学的是FORTRAN)。在过去的半个世纪里，我花了很多时间在软件工作上:需求、设计、用户体验、编程、测试、项目管理、写文档、领导过程改进、写了7本书和很多文章、咨询和培训。
当然，在这个过程中，我也完成了一些副业，比如读有机化学博士(论文三分之一是计算机代码)，做了几年研究员。但基本上，我是一个软件行业的人。
在这么长的一段时间里，我积累了很多关于软件行业的看法。在这篇文章中，我将与你分享63个灵感，也许你会发现它们和我一样有用。
关于要求
如果不了解需求，项目的其他部分做的再好也没用，最终会失败。
2.午饭后你在办公桌上发现的便利贴，保存下来的语音信箱和邮件，走廊里你记得似是而非的随意对话，这些都不能算是需求。只是一堆信息。
3.对于所有的项目涉众来说，利益的交叉在需求过程中发生的最频繁。
4.没有高质量的需求，涉众可能会对最终交付的内容感到惊讶。在软件领域，事故几乎总是坏消息的同义词。
在探索需求的时候，请不要只考虑现在的用户。你以前的客户还是你的客户。
6.人们不应该只是“收集”需求。需求获取是一个探索、协作、发现和发明的过程，而不仅仅是简单的收集。商业分析师不仅仅是抄写员。
7.需求获取的目的是让客户的声音——VOC，客户的声音——尽可能靠近开发人员的耳朵——EOD，开发人员的耳朵。业务分析师有助于缩小沟通差距。
8.人们通常寄希望于两种获取需求的方法:“心灵感应”和“千里眼”。但是两个都没用。
9.不管我们的文化宣称什么，顾客并不总是对的。但是客户总有自己的看法，你必须理解并尊重这个看法。
10.需求开发需要迭代。你不能指望在第一次讨论中就得到所有的要求；你知道，你可能永远不会完全明白。有效的需求开发包括逐步改进细节和清晰度。
11.不要害怕记录需求。与获取知识的成本相比，记录知识的成本很低。
12.如果一些功能或特性没有在需求中描述，没有人期望在产品中看到它们。
13.需求开发的可交付成果不仅仅是一组书面的需求，而是一个共识和一致的期望。
14.对于需求开发，实际的目标不是需求有多完美，而是需求足以让团队在可接受的风险水平下进行构建。这种风险在于，由于被忽视的、不必要的、不完整的、不明确的或不良的沟通，输出需求不得不返工太多。
15.我们有时会很随意地表达我们的需求，因为我们假设读者有一个与我们相似的“理性过滤器”，但人们往往会以不同的方式解读同一种说法。这种模糊性会导致期望不匹配和意外交付。
16.保持需求工作室和审计团队的小规模。一大群人甚至不能就是否离开燃烧的房间达成一致，更不用说就一个要求的措辞达成一致了。
17.当有人提出新的需求时，首先要问的问题是:“这在我们讨论的范围内吗？”如果是，那就必须解决。如果没有，就不会解决，或者至少现在不会。但是，如果答案是“不会，但是要注意这个问题”，那么你就必须调整范围来适应它。这对成本、进度、资源、参与、优先级和利益权衡都有影响。
18.如果您没有一个记录在案的和一致同意的项目范围，您如何知道您是否正在经历范围蔓延？
19.当决定在一个产品或迭代中包含哪些功能时，请避免“分贝优先”(俗称按噪音分配)的做法。从商业角度来看，最大声的客户所要求的功能不一定是最重要的。
20.项目涉众必须能够理解讨论可能的需求和承诺将它们包含在产品中是有区别的。
21.有两个术语你听到一定要警惕:“假设需求”和“隐含需求”。努力清楚地传达需求的期望。
关于项目管理
“项目管理”不是指一项特定的活动。项目管理是人员管理、需求管理、风险管理、机会管理、期望管理、承诺管理、变更管理、资源管理和供应商管理的混合体。
23.为什么有的公司永远没有时间做好软件，却总能挤出时间、金钱、人力在后面弥补？这是一个谜。
24.每个人都喜欢认为他们的团队拥有顶级人才，但事实是所有软件开发人员中有一半低于平均水平。那么这些人都在哪里工作呢？
25.不要轻易评价任何人。如果有人请你评价，最恰当的回答是:“让我先考虑一下，再回复你。”
26.不管别人给你多大的压力，都不要做出自己无法兑现的承诺。
27.如果你有令人信服的数据，而对方几乎没有数据，你就会在谈判中占据优势。
28.除非你把评价记录下来，并与实际发生的情况进行比较，否则你永远都是在猜测，而不是在评价。
29.不能因为觉得对方爱听好话就影响你对一个人的评价。
关于质量和流程改进
30.关于软件质量:你可以现在付钱给我，也可以以后付钱给我，但是你要多付钱。
31.力求完美；追求卓越。
32.千万不要被老板或客户说服去做坏事。
33.质量应该是你的首要任务。高质量的自然结果是巨大的生产力，因为这样团队就不必在返工上浪费太多时间。
34.尝试让同行而不是客户发现缺陷。同行技术评审是一种有效的技术，可以提高质量和生产率。
35.如果和你打交道的人不讲道理，那么软件工程的任何技术都是没有用的。
当人们被要求改变工作方式时，他们的本能反应是问:“这对我有什么好处？”但其实这个问题是错的。正确的问题应该是“对我们团队有什么好处？”
37.软件开发人员总是在寻找优秀的工具，但是请记住，小傻瓜只有拥有工具才会变成大傻瓜。
38.当人们不知道当前的工作方法导致的痛点在哪里时，进行流程变革是非常困难的。就像如果人们不知道家里有老鼠，就很难卖给他们更好的捕鼠器。
39.问:换一个灯泡需要多少个软件过程领导者？答:只需要一个，但前提是灯泡愿意换。
40.在向新的工作方式发展的过程中，不要低估改变组织文化的必要性和难度。实施新流程比灌输新文化要快。你需要在这两方面都取得成功。
41.不管是不是善意的，如果改善计划不能转化为行动，都是无济于事的。
42.在许多情况下，常识、良好的判断和经验应该比正式的程序更重要。然而，有时这个程序的存在是有原因的。在你决定绕过它之前，你需要调查它。
43.当领导组织采用新的工作方法时，请持续而温和地施加压力。
44.改变人们工作方式的最好动力就是痛苦。不是人为的和外界强加的痛苦，而是当前的工作方式给团队带来的非常真实的痛苦。选择那些能最终减轻痛苦的改善活动。
45.没有理由期望下一个项目会比上一个项目更好，除非你花时间回顾、吸取教训并不断改进团队的流程。
46.你不能一下子改变一切。找出那些能带来最大收益的流程变革，下周一开始实施。我不是开玩笑:下周一！
47.在文档模板中采用“缩小以适应”的概念。从丰富的模板开始，提醒你多想想可以包含哪些信息，然后根据每个项目的规模、性质和需求进行重塑。
48.许多团队需要用更少的资源做更多的事情。但是，通常情况下，他们没有办法事半功倍。如果没有相应的培训和流程改进来提高效率和效果，就不要指望更高的生产率会神话般地出现。
49.适用于在同一办公室工作的四个人的非正式过程不能扩展到在不同大洲工作的多个开发团队。
50.如果有一件事可以在软件行业重现，那就是在一个又一个项目上一遍又一遍地做同样的蠢事。你需要通过复习来学习、理解和提高。
51.当人们不按照既定的流程走的时候，你只有三个选择:(1)让人们开始按照流程走；(2)调整流程，使其更有效、更实用，然后让人去遵循；(3)放弃这个过程，不要再假装自己在遵循它。
其他意见
52.人工智能代替不了真实的东西。
53.在技术领域，如果你比别人领先一周，那么你就是老大。
54.今天“必须马上完成”的开发项目将成为明天遗留系统维护的噩梦。
55.软件系统的很多问题都发生在接口上:软件和软件，软件和硬件，软件和人，人和人。这些接口需要研究。
人们总是过多地谈论他们的“权利”。每项权利的另一面是责任。以合作的方式思考和行动。
57.一盎司的设计相当于一磅的重建。
58.当心“商业周刊管理风格”——仅仅因为有人读到它承诺的优秀结果，他们就争先恐后地采用软件开发中最热门的新事物。
59.拇指和食指之间保持一英寸的距离。大多数情况下，这是质量和垃圾的唯一区别。再听一会儿，检查一下你的作业，再做一次测试，参考列表，阅读说明，再问一个问题。通常，这是改善垃圾的唯一方法。
60.你没有时间重复以前那些软件从业者犯过的错误。阅读并尊重文献。向你的同事学习。慷慨地与他人分享你的知识。
61.计算技术可能占软件开发的50%，剩下的50%在于通信。但是商业分析都是关于交流的。我们必须在计算上多下功夫。
62.如果你想成为一名独立的顾问或承包商，你需要向全世界宣布你拥有空。如果没人了解你，你业务能力再好也没用。
63.在软件行业，我们经常假装。我们假装找到了合适的利益相关者，他们知道自己的业务目标和需求。我们假装是正确的人，把正确的需求传达给我们，我们理解并准确记录。我们假装我们的评估是准确的，我们已经考虑了所有必要的任务。我们假装所有可能损害我们项目的风险都不会真正出现。我不喜欢假装。有时候，我不是那么喜欢现实，但除了现实我一无所有，所以我必须面对现实。我们别装了。
英语:50年软件经验的63个教训。
原文:https://medium . com/swlh/62-50年软件经验的教训-2db0f400f706。
作者简介:Karl Wiegers，作家，内容涵盖软件开发与管理、咨询、自我提升、化学、军事历史等领域，目前正在撰写推理小说。
香槟超新星
本文由CSDN翻译，请注明出处。
主题测试文章，只做测试使用。发布者：rekoe，转转请注明出处：https://www.mulub.com/5113.html
微信扫一扫 
支付宝扫一扫 