有效软件生产的八项规则

在我的职业生涯中，我参与了多个现实生活中的软件项目，并观察了各个层面的事情是如何完成的：决策制定、实践采用、团队建设、招聘、技能分配等。显然，不同的方法产生了不同的结果. 作为一个以改进为导向的人，我注意到并收集了最有效的做法和最佳实用技巧来帮助我工作。

从观察中学习是一种艰难而漫长的方法。 我会非常乐意更早地从书本中获取这些知识。 不幸的是，我没有找到关于该主题的内容。 所以我决定与其他寻求这种知识的人分享我的经验。 希望它可以为他们节省几年的个人研究。

在本文中，您将了解如何通过生产坚固可靠的软件产品，将维护量减少 5 到 10 倍，从而超越行业平均水平。 我可以毫不谦虚地说，在过去的 10 到 15 年里，我（个人和我的团队）已经超出了所有人的预期，留下了成功的痕迹。 经理们再高兴不过了。

有一次，我的团队在极短的时间内完成了一个重要项目，为此我们获得了更高管理层授予的“高绩效团队”奖。 所有这一切都无需熬夜和周末让自己筋疲力尽。 只是正常的工作。

你看，有效的软件生产知识本身就是一种力量。 事实上，这是一种即使用简单的语言解释也没有多少人能够掌握的黑魔法。 你会免费得到它。 如果您想被视为软件生产魔术师，请继续阅读。

这是给谁的？

让我在这里做一个重要的、重要的、重要的免责声明。

我向那些需要提高生产力的人解决这个问题。 并非生活中的一切都与生产力有关。 也不是所有的软件项目。 在某些情况下，您的表现不会受到评判。 显然，这些做法在那时无济于事。

这些技术对团队领导、架构师和项目经理最有用，尽管高级软件开发人员也可以从中受益。

规则 1：了解 IT 心态

IT 行业是科学、技术、艺术和商业的混合体。 如果不充分了解这些方面，就很难在那里导航。 最大的问题是行业本身相当复杂； 因此，最佳实践也很复杂。 你需要学习很多东西并通过大量练习来验证你的知识才能取得成功。

令人难以置信的技术更新速度使其变得更加艰难。 你十年前学到的任何东西都不再需要了。 所以你需要加快学习速度。

综上所述，我们可以说，在 IT 领域的成功不是基于先天的技能或感觉，而是基于实际的例子。 永远不要“跟随直觉”或仅仅基于感觉相信，包括你的感觉。

如果是，这个想法值得考虑。 否则，需要一个非常好的和非常详细的解释，说明选择这条路径如何让你的团队生活得更好。 如果它通过了此测试，请安排一个轻量级的概念证明项目，通过实验证明它适合您的环境。

这里要理解的重要一点是，解决方案没有对错之分，因为解决软件问题的方法有很多。 但是，对解决方案的理解有好有坏。

如果一个人能够清晰地详细阐述想法，或者将采用这种解决方案与团队的成功联系起来以说服其他团队成员，那么我们可以依靠这个人的眼光并希望获得成功的机会。

规则 2：不要混合软件生产和软件开发方法

软件生产以软件开发为基础。 然而，这两者有着完全不同的目标、心态和实践。 试图用另一个领域的方法解决其中一个领域的问题会产生荒谬的结果。 重要的是要了解区别并为每个世界使用适当的方法。

软件开发是艺术与工艺的结合。 无论自动化工具和软件开发方法如何，艺术组件将始终存在。 因此，解决开发任务需要最大限度地集中注意力并屏蔽所有其他干扰信号。

激励有经验的开发人员的最佳方式是以排除所有人为因素的纯技术形式向他们展示任务。 所有要求也应以技术语言表达。 它们应该易于验证，以使他们能够在单独的研究阶段朝着目标前进。

相比之下，软件生产更多地属于企业管理领域。 您一方面了解客户的需求，另一方面了解您可以使用的团队资源。 因此，现在您尝试引导您的团队努力实现目标。 同时，你也可以估计自己的进度，给老板一个周密的计划。 那里的重要技能是了解客户的愿望、了解团队的优势以及传达正式的计划和时间表。

话虽如此，我想强调的是，软件开发中的许多角色都在这两个世界中工作——在业务和技术之间架起一座桥梁——例如团队领导、架构师、分析师和项目经理。 担任这些角色的人应该能够轻松地在两个现实平面之间行走，并了解何时该谈生意，何时该谈艺术。

规则 3：使用持久存储作为人类记忆的扩展

人类的记忆，虽然容量惊人，但也有其局限性。 你记得事物的准确性和持续时间都无法预测，当你忘记时，就无法随意回忆。

这就是我们使用持久内存存储以可预测的速度移动的原因。 这与您在事后很久创建并供其他人使用的用户手册之类的正式文档无关。 这是关于在工作期间使用文档作为您记忆的外部扩展，以帮助您完成软件开发过程。

我建议您在遇到不重要的任务或涉及多人的任务时记录您的想法和计划。 尽量让它便宜。 不要创建带有公司标志的正式文件。 一个好的工具是包含您的项目空间的公司 wiki。 为任务或问题创建专用页面（30 秒）。 然后在每次有想法或要与他人讨论时更新它。

在开会时，说“等一下，让我把它放下”，然后花 10-30 秒以书面形式表达出来。 写作不应该是广泛的，但它应该是完整和连贯的，就像你将整个想法转移到纸上一样。 稍后，您或任何其他阅读您的文章的人都应该像您现在理解的那样清楚地理解它。 这个技巧可以节省大量时间，但可以让您即时记录。

这种技术有两个目的。

首先，它通过用力将其压入石头，将您的进步锁定在通往成功的道路上。 不再有某人忘记某事、一次又一次地重申同一件事或重新谈判已经谈判过的同一件事的风险。

其次，你要理清思路，把困扰你的问题抛在脑后。 现在你的头脑渴望下一个挑战。 多么提高生产力！

这适用于任何规模的项目或任务。 对于更大的空间，您将拥有更大的空间以及随着项目的发展而逐渐增长的页面层次结构。 这里的重要概念是在开始建立快速内存转储协议的任务之前准备文档空间和结构！

对于喜欢技术类比的人，我会将我们的思想比作具有强大处理能力但操作内存有限的处理器。 你基本上可以一次考虑一件事。 在这个类比中，您的文档用作持久存储，而您的大脑以迭代的方式解决复杂的问题。 在某个时候，您决定开始下一次迭代，阅读以前的文档，并将当前状态加载到您的操作内存中，考虑一段时间并根据您的新发现更新代码和文档。 一步一步，直到完成。

综上所述，我不鼓励人们一次处理很多任务。 相反，你的任务越少越好。 不过，真正为人工优化的工作情况并不多，而且可能需要多任务处理，并且您必须以某种方式处理它。 上述技巧有助于更好地处理它。

规则 4：停止在正式的时间估算上浪费时间

没有两个项目是相同的。 下次你做类似的项目时，你会有不同的客户、不同的目标、不同的团队； 甚至可能是不同的技术。 即使使用标准工具和组件，您仍然需要自定义它们的配置和架构。 当您处理软件项目时，请记住它们涉及 50% 到 100% 之间的自定义工作。 它们需要研究、讨论、思考、试验和其他高度不可预测的活动。 在实践中，您可能会在表面上看起来与您之前所做的完全相同的项目类型方面遇到巨大差异。 一个新的项目类型，通过扩展，几乎不可能准确估计。

如果它如此不可预测，那么项目经理应该如何提出项目时间表并坚持下去？

文献中描述了一种正式的方法。 即，将整个项目拆分为更小的步骤，估计每个步骤需要多长时间，然后通过结合各个部分的工作长度来计算项目总长度。 MBA课程中教授的这种方法背后有大量理论。

不幸的是，再多的数学也无法挽救它。 这种方法是出了名的不准确，以至于它完全不可用和不切实际，更不用说它是多么的耗时。 我从来没有见过一个项目经理在没有任何调整的情况下使用正式的计算方法，即使是在方法论狂热者中也是如此。 即使公司严格要求使用这种方法！ 事实上，表现最好的经理使用完全不同的替代方法，如下所述：

一个好的项目经理会注意到项目类型、环境、所涉及的资源、组织类型以及影响实际项目长度的所有其他工作方面。 当然，没有人需要仅仅从自己的错误中学习。 这种观察可以直接也可以间接进行； 例如，通过书籍或研究其他人完成的项目，甚至只是将知识传授给他人。 这种统计顶级知识改进了个人项目进度导航。

我想强调上述方法的两个重要后果。

首先，估计精度随着经验而提高。 一个没有经验的人用他们拥有的任何强大的方法论武装起来，是不可能擅长的。 其次，即使是最好的估计也只是在统计方面是好的。 也就是说，可以说某个项目可能需要四到十二个月的时间。 假设这是正确的，人们应该明白该项目有 50% 的机会运行超过其 8 个月的平均时间。

了解统计预测具有如此不可思议的效果。 一个聪明的经理只会对这样的项目进行 12 个月的估算，然后提前完成它，让每个人都惊叹不已。 换句话说，没有人会期望一个团队能按照项目进度执行一天。

对项目经理及其老板的一般建议是停止在正式的时间估算方法上浪费时间。 相反，鼓励收集有关项目持续时间的统计信息，并在整个公司内共享这些信息。 我知道一些公司在全公司范围内实施了这种方法，从而产生了惊人的预测精度。

规则 5：了解转换任务和兼顾优先级的成本

人类的思想是由大自然惊人地设计的。 尽管它令人难以置信，但它也有其局限性。 换句话说，它旨在在特定领域和特定类型的任务中表现出色。

开发人员的头脑绝对是软件开发的重要资产。 作为项目经理，您是否有兴趣更好地理解它并将其置于表现最佳的位置？

让我们简单地说，避免过多的理论。 请记住，在您需要从自己或他人的经验中学习之前，理论只会带您走这么远。

人脑具有很强的解决问题和产生想法的潜力。 不幸的是，并非总是能够挖掘这种潜力，主要是因为为了支持创意的产生，您需要同时将所有问题的部分一起保存在您的活动记忆中。 这就是为什么解决复杂问题会经历一个简化阶段的原因，当一项任务被概括或重新制定以删除不重要的部分并同时减少内存中保留的元素数量时。 换句话说，我们既可以解决一个非常狭窄的复杂问题，也可以解决多个简单问题。

但是，该比率不是线性的。 增加你同时做的事情的数量会极大地削弱你解决问题的能力。 这就是为什么人类总是使用并将使用角色分离作为生活优化的原因。 两个人分别处理两项任务会比他们同时处理两项任务更快地取得突破。

另一个重要的人类思维特征是它无法像计算机那样立即在任务之间切换。 确实，您不能随意停止思考某事。 你也不能立即开始全速思考一个新概念。 空中交通管制操作员完美地说明了这种心理惯性。 即使他们正在看雷达并看到全貌，他们仍然需要将其加载到内存中才能快速运行。 新操作员需要十分钟才能看到屏幕，然后才能在换班时更换旧操作员。

更糟糕的是，我们不能随意忘记事情。 我们所学的一切都会留在我们身边，随着时间的推移逐渐消失，占据我们可以用于新知识的空间。 更糟糕的是，这种影响有时会因“未完成”的感觉而更加复杂。 忘记已经完成并且将来不再需要的东西要容易得多。 而当你把事情放在一边待会儿完成时，你的大脑自然会紧紧抓住标记为“供将来参考”的信息，不愿让新知识取而代之。

好的。 现在我们已经概述了切换任务的想法，让我们看看它在现实生活（可以说）思想实验中是如何工作的。

想象一下，您有十个常规开发人员从事十个常规任务——每人一项任务。 假设我们可以将他们封闭在一个完美无干扰的环境中，那么每个任务都可以在一定时间内由一个人解决。 整个事情只要完成最长的单个任务所需的时间。

现在，让我们重复同样的心理实验。 这一次，我们将不断在开发人员之间切换任务分配，没有（重要）原因。 每天，每个开发人员都有一项新任务要处理。 更好的是，让我们每小时切换一次。 他们多久能完成，你觉得呢？ 也许永远不会。

第一个场景中的项目经理能够有效地执行项目。 第二个设法“执行”了它，这是肯定的……从某种意义上说，他们促成了它的死亡。 恭喜。 这种扼杀项目的技术特别有效，因为除了浪费时间之外，它还将员工的士气降低到零。

当上面的例子以纯粹的学术方式呈现给他们时，大多数人都会同意。 然而，在现实生活中，他们在丝毫压力下突然忘记了一切。 大老板要求提供进度报告，或者客户询问某个功能的实施日期——几乎任何外部事件都可以让项目经理冲向团队并表达他们的担忧，然后是一连串的任务重新分配和优先级调整试图在这里和那里赢得一点时间，最终只会导致项目更加偏离轨道。

不幸的是，这是一个经常发生的现实场景。

一个好的经理会站起来，通过吸收情绪冲击波并将其转化为富有成效的未来讨论项目来保护团队免受此类轻微干扰。 这在情感上肯定很难，但这是让团队保持良好工作节奏并让他们交付的唯一方法。

规则 6：使用架构评审作为改进系统设计的一种方式

IT 行业以过度工程和工程不足的概念运作。 当它在采访中出现时，每个人都说过度设计是不好的。 这个问题很容易回答，因为这个问题本身传达了“过度”的负面含义，即“太多”。 真正实用的知识是如何识别您的架构何时过度设计并在早期阶段避免它。

让我给你一些我在这方面久经考验的建议。

首先，如果有另一个更简单的解决方案提供所有所需的功能，则该解决方案可能被认为是过度设计的。 这意味着如果您不知道更简单的解决方案，那么您可以提供的任何最简单的解决方案都是您眼中最好的解决方案，除非有人证明您错了。

如果我们想象中的架构师真正追求完美的解决方案，那么通常的架构审查可以保证它足够优化。 不幸的是，架构审查至少需要一些其他合格的架构师。 在许多情况下，它存在不可用或不切实际的危险。 在没有同行评审的情况下，架构师很容易犯常见错误。 让我们一一审查它们并讨论每种可能的补救措施。

最常见的错误之一是没有考虑商业目标的设计。 显然，任何工作活动都应该与最终消费者的满意度或公司的成功或类似的业务需求相关联。 然而，您经常会看到整个或部分设计的架构没有考虑到这样的目的。 推理要么不存在，要么归结为使用尽可能多的现代花里胡哨。

在这种情况下，架构师不会做消费者支付的费用。 相反，他们为了自己的乐趣和乐趣而玩很酷的玩具。 这在正规行业是绝对不能接受的。 然而，无论如何，它似乎经常发生。

有时，问题在于架构师的个性以及他们对某些技术或工具的痴迷。 他们只是喜欢使用它们，无法连贯地解释他们试图解决的业务需求。 接近这种情况是另一种情况，当人们除了从小块构建东西之外什么都不知道。 当然，任何外部事件都会触发他们潜入设计世界的冲动，并且永远不会回到真正的客户那里。 即使最初的触发因素可能是有效的商业投入，他们与现实的长期脱离也会降低他们艺术品的实用性。

解决这个问题很简单，但需要自律。 一个好的建筑师不应该接触笔和纸，直到他们能够清楚而诚实地回答自己为什么需要它。 这种需求可能以不同的形式出现。 它可能是正式的要求、对产品改进的隐含需要，或者是新技术的出现，从而降低了以前的设计效率。 无论如何，只要架构师自己了解驱动力，它就不应成为正式的触发因素。 然后他们可以用这种力量作为对他们设计质量的最终验证。

另一个更难检测的问题与块架构思维有关。 有这种心态的人认为，任何事情都有解决方案，并且所说的解决方案总是作为​​构建块来实现的。 换句话说，它们直接将功能转换为组件，而不需要整体评估架构。 当需要此类功能时，他们可能只是将提供所需功能的组件附加到系统。 大多数时候，这满足了形式要求，但使系统处于不连贯的状态。 新模块的选择不是基于现有系统兼容性，用于开发、支持，甚至公司的许可模式。 因此，团队尝试修改现有配置或通过现有系统容量实现此功能。 结果，系统的支持和维护逐渐变成了一场错综复杂的噩梦，紧随其后的是性能下降。

这个问题没有简单的解决方案，因为系统工程是一门艺术，永远不可能预测是否必须添加或可以避免新组件。 最佳实践可能是保持积压的维护和架构问题随着时间的推移而积累，然后定期审查整个系统架构。 这种定期审查也可能会考虑新兴技术。 因此，架构审查的一般目的不应该是解决问题，而是评估预期改进和整个系统的潜在可行性，以应对迫在眉睫的过时不可避免性。

规则 7：价值团队成员

大多数 IT 行业专业人士在面试时被问到他们是否是优秀的团队成员，或者他们是否在团队中工作得很好。 然而，可能没有人在文学作品中看到过明确的定义。 显然，这样的人通常会为团队的成功做出贡献，但很少有人能够真正定义独特的个人品质来确保这种成功。

我观察到许多人在不同层次上工作，并看到他们的个人素质如何影响项目进度。 我想就对团队合作最有帮助的个人品质提出以下几点建议。

沟通

当然，首要的品质是沟通能力。

想象一个沟通能力为零的人。 当然，没有收到团队成员的反馈会使他们完全无用。 这一点很明显，面试时没有人真正衡量这个技能，这意味着只要一个人能说得好，这个技能就足够好。

沟通不是二元是/否的技能； 它更像是一个信息传递窗口。 范围越广，信息交流就越快、越清晰。

由于该窗口的开放范围在人群中差异很大，因此该窗口宽度的度量是团队成员的一个重要特征。 请记住，我们谈论的是在这种情况下传达信息，而不是顺畅地交谈或鼓励人们或通过交谈和交流来激励或组织他们。

沟通方式也无关紧要。 信息可以口头、文字、图片或混合方式传递。 这个人可以说快或慢。 他们可以很友好，就像看着你的眼睛一直微笑，或者他们可以移开视线并用单调的声音说话。 风格可能会影响你对同事的个人看法，但只要你清楚地理解他们的意思，任何风格都足够了。

让我们转向检测和测量沟通能力的实际案例。

一般来说，沟通技巧有两个主要方面。 首先是愿意分享信息。 有些人渴望分享，但有些人试图隐瞒信息。 这种倾向或多或少是自然的，但可以通过自我激励和训练慢慢改变。 可以肯定的是，表现出一种信息共享意愿的人将来也会表现出这种意愿。 这就是为什么该特质有助于预测候选人未来在团队中的成功。

在现实生活中，试图隐瞒信息的人很容易引起注意。 他们通常会故意提供无用的信息，而不是实际需要的任何信息。 或者，他们提出初步问题以将信息流向内，并尽量减少对“需要知道”事件的回答。 不管他们采取什么策略，你最终都会觉得你没有从他们那里得到想要的信息，或者获取信息需要付出太多额外的努力。

理解意图很重要，因为某些类型的开放人员可能会向您提出初步问题以更好地理解您的问题，然后以最方便的方式为您提供答案。 打算隐瞒信息的人会问更多问题，只是为了避开谈话，而不是回答你最初的问题。

沟通技巧的另一部分是适应听众的能力。

不同的人对话题的理解程度不同，沟通方式不同，甚至对具体细节的兴趣也可能不同。 一些善于交际的人会根据听众的理解能力和准备答案以传递特定信息的能力来改变他们的对话流程。 在这样的准备中，可能会问一些初步的问题来缩小听众的兴趣。 “解决”沟通差异的能力确实是一项很棒的技能，因为它使我们几乎可以在所有情况下实现理解。 另一方面，灵活的谈话者有时可能会陷入无法解决的误解死胡同。

了解优势和劣势

让我们关注另一个对团队合作者至关重要的个人品质。

大多数人都会同意，团队环境应该比周围的平均环境更友好，以促进协作并提高生产力。 因此，对于一个团队来说，了解每个成员的强项和弱项以正确分配任务并以优势弥补弱点非常重要。 这条道路上的第一步是让所有成员诚实地衡量彼此的技能。 从心理上讲，这可能很难，因为我们自然倾向于向他人隐藏自己的弱点，保护自己。

这就是友好的团队氛围发挥作用的地方。

因此，新成员有望按团队规则进行比赛。 不幸的是，有些人即使在友好的环境中也不能放松警惕。 他们一生都表现得像独狼。 这比他们强。 可悲的是，这种态度对团队的努力没有贡献。

有一种简单的技巧可以在面试中识别出这样的孤狼。 他们从不承认他们不知道什么。 当然，人们喜欢展示自己最好的一面，展示他们所有的能力，并尝试解决每一个难题。 然而，每个人的知识都是有限的。 我们的极限塑造了我们的技能。 不承认限制意味着候选人将自己表现为多面手，无所不能。

当您聘请专家时，您可能希望避开这些人。 此外，这种傲慢的态度往往伴随着另一个危险信号：不愿寻求帮助。 寻求帮助的能力对于团队合作是绝对必要的。 没有它，我们就无法快速进步和发展。 这种固执的人会消耗公司的资源和时间，无限期地与艰巨的任务作斗争，但从不寻求队友的帮助。 有一个简单的技巧可以在面试中发现这样的候选人。 问他们一个没有意义的问题或提及一些无意义的术语。 一个正常的、充满好奇心的人只会说他们不知道并问它是什么。 即使您强调没有正确或错误的答案并且“我不知道”不会取消他们的资格，防御者也不会这样做。

规则 8：专注于团队合作组织

关于团队合作组织的信息与上述任何先前主题的信息一样少。 每个人都知道团队合作更好，但如何建立和维护团队仍然是一个谜。 然而，即使不可能涵盖团队建设的所有方面，我们至少可以在这里探索一些关键的团队建设技术。

建筑专业知识

每个 IT 项目都是独一无二的。 要在其中取得成功，需要学习和掌握项目细节。 它们可能包括技术和非技术知识。 非技术知识的一个例子可以是管理人员、客户、技术支持团队等的个人网络。特殊技术知识是一般 IT 技能之上的附加细节。

例如，您可能需要了解 Maven 才能构建项目。 但是，确切的构建结构、属性的位置和过滤仍然会因项目而异。 与任何类型的知识一样，掌握这些细节需要时间。 人们投入的时间越多，他们的表现就越好。 时间是你拥有的最宝贵的资源。 您希望让您的团队成员尽可能长时间地专注于同一职能领域，以利用他们的专业知识并进一步发展他们，从而不断提高团队绩效。

不幸的是，不可能无限期地这样做。 从一方面来说，人们可能只是觉得无聊。 另一方面，您冒着失去他们的专业知识的风险，意外地使您的项目面临风险。

让我们看看是否有办法在不影响团队表现的情况下应对不利因素。

在团队成员之间分配重点领域，让他们在其中积累专业知识。 在某些时候，它们达到了足够高的水平，在这个项目的范围内是有意义的。 在这一点上，额外的学习努力不会显着改善它。 没有动力和挑战，聪明的人会变得无聊并开始讨厌他们的工作。

通过在其他地方为他们打开学习机会来防止这种情况。 让他们了解项目和公司的技术堆栈，并迎接新的挑战。 如果他们的兴趣在项目范围内，您将获得双重回报，即让您的团队保持挑战并同时扩展有用的团队技能。 然而，任何自我发展都可以避免无聊，即使它与当前的项目需求没有交叉。 As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!