高效软件生产的8条规则

英文原文：Eight Rules for Effective Software Production

前言

由于一个巡展项目一直拖了近一个月才完成这篇文章，原本收到的是两篇文章，无奈一是最近没时间一下完成两篇文章，另一个原因就是略微看了下应该是通过Xamarin使用c++开发安卓/ios的文章，由于目前专注的主要是java以及web方向，所以也就没多少心情去翻译了，有兴趣的自己去看吧：

Building Cross-platform Apps with Xamarin: Perspective of an Android Developer

文章正文

在我的职业生涯中，我参加了多个真实生活中的软件项目，并观察了各个层面上做了哪些事情：决策、实践应用、团队建设、招聘、技能分配等。显然，不同的方法产生不同的结果。作为一个改进型的人，我注意并收集了最有效的做法和最实用的技巧来在我的工作中帮助我。 从观察中学习是一个艰难而漫长的方法。我本来非常乐意从书本中选出这个知识。不幸的是，我在这个话题上什么也没发现。所以我决定与其他寻求这种知识的人分享我的经验。希望这将节省他们几年的个人研究。 本文中，你将学习如何通过生产健壮可靠的软件产品，是维护成本降低5-10倍，从而可以击败平均行业绩效。我可以毫不犹豫地说在过去的10-15年中，我（个人和我的团队）已经出超出了所有的期望，留下了一系列的成功。 曾经我们在一个不可能的短时间内完成了一个重要项目，从而被高层管理人员授予“高效率团队”奖。所有的这一切不需要熬夜和在周末疲惫不堪的工作。仅仅是正常工作。 你看，有效的软件生产知识本身就是一种力量。事实上，这是一种黑魔法，即时用简单的话来解释，也没有多少人掌握。你将免费得到它。如果你想被认为是软件生产魔法师，请继续阅读。

这是给谁的？

让我在这做一个非常、非常、非常重要的免责声明。 我将它送给那些需要提高生产力的人。在生活中不是所有的事情都与生产力有关，软件项目中也是如此。有些情况下你不会对你的表现作出判断。显然，这些做法不会有帮助。 尽管高级软件开发者也可以从中获益，到这些技巧对于团队领导者、架构师和项目经理来说更为有用。

规则1：了解IT心态

IT行业是科学、技术、艺术和商业的组合。在没有足够高的水平了解这些方面的情况下是很难通行的。最大的问题是行业本身是非常复杂的，因此，最佳做法也很复杂。你需要学习好多，并且通过很多成功的实践来验证你的知识。 令人难以置信的技术更新率使其双重困难。你十年前学到的已经不一定是现在所需要的。所以你需要加快学习。 综上所述，我们可以说在IT领域取得成功不是基于先天的技能或感觉，而是基于过硬的实践。从来不会“跟随直觉”或者仅仅基于感觉，包括你自己的。

采用新想法的最佳实践是验证某人之前曾经做过的工作。

如果是的话，这个想法是值得考虑的。否则，需要一个非常好和非常详细的解释，如何选择这条路让你的团队的生活更美好。如果通过此测试，请安排一个关于概念项目的轻量级实验来证明它符合您的环境。 在这里要了解的重要事情是没有正确的和错误的解决方案，因为解决软件问题有很多方法。但是，对解决方案有好的和坏的理解。 如果一个人可以清楚地明确表达想法，或者将这个解决方案与团队的成功联系起来，说服其他团队成员，那么我们可以依靠这个人的愿景和希望获得成功的机会。

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

软件生成是基于软件开发的。但是，这两者有完全不同的目标、思维方式和实践。试图用另一个领域的方法解决一个领域的问题将产生可笑的结果。了解这些领域的区别和使用适当的方法是很重要的。 软件开发是艺术和工艺的结合。艺术成分将永远在那里，无论自动化工具和软件开发方法如何。因此，解决开发任务需要最大程度的集中和屏蔽所有其他分心的信号。 激励有经验的开发人员的最佳方法是将其全部人为因素排除在纯技术形式的任务之外。所有要求也应以技术语言表达。它们应该很容易被验证，让他们在他们的个人研究阶段向目标前进。 相比之下，软件生产更多的偏向企业管理领域。一方面你知道你的客户需要什么，另一方面你知道有哪些团队资源可任你自由支配。。所以现在你试图引导你的团队努力达到目标。同时，您还可以估计您的进度，并向老板提供一个精通计划。重要的技能有了解您客户的意愿，理解团队优势以及沟通正式计划和时间表。 话虽如此，我想强调，软件开发方面的许多角色都在这两个领域工作——在建立商业和技术之间的桥梁—— 例如团队领导、设计师、分析师和项目经理。这些角色的人应该能够轻松地走在两个现实之间，明白什么时候谈谈生意，何时花时间用于艺术。

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

人类的记忆虽然惊人，但具有极限。你靠不可预测的准确性与持久性记忆事情，当你忘记的时候，将没有办法随意回忆它们。 这就是为什么我们使用持久性存储以可预测的速度前进。这不是关于正式的文件，比如你在实现之后创建的用户手册和其他人使用的手册。这是关于使用文档作为你工作中记忆的外部扩展，从而可以帮助您完成软件开发过程。 我建议您在面对不平凡的任务或涉及多个人的任务时，记录您的想法和计划。尽量使其尽可能简便。不要在其上创建含有公司标志的正式文件。一个好的工具wiki成为您的项目空间中伴侣。为任务或问题创建专用页面（30秒）。那么每当你有一个想法或者你要和别人讨论的时候更新它。

在你的想法仍旧在你脑海中飞行时，暂停谈话，并立即更新它。

在一次会议上，说“坚持下来，让我把它放下”，用10-30秒的时间记录下来。记录不应该是广泛的，但它应该是完整和连贯的，就像你将想法全部转移到论文上一样。以后，你或者任何阅读你记录的段落时都应像你现在了解的一样清楚明白。这个技巧可以节省大量的时间，而且可以让你快速的进行文档化。 这种技术有两个目的。 首先，它锁定你的走向成功的路通过将其刻入石头上。不会再有更多的类似某人忘记一些事，一再重申同样的事情，或重新谈判已经谈判过的同样的事情等情况发生。 第二，你清楚你的想法，倾倒出你抱怨的问题。现在你的头脑渴望下一个挑战。提高生产力！ 这适用于任何大小的项目或任务。对于较大的页面，您将拥有更大的空间，其中层次结构的页面随着项目的发展而逐渐增长。这里的重要概念是在开始任务之前准备一个文档空间和结构，以建立一个快速的内存转储协议！ 对于喜欢技术类比的人来说，我将把我们的大脑比作一个有巨大的处理能力但操作内存有限的处理器。你本质上可以一次思考一件事情。在这个类比中，您的文档用作持久存储，而您的思想则以迭代方式解决复杂问题。在某些时候，您决定开始下一次迭代，阅读以前的文档，并在你的操作内存中加载您的当前状态，考虑一段时间，并用新的发现更新代码和文档。一步一步，直到完成。 以上所说，我不鼓励人们一次处理很多任务。相反，你拥有的任务越少越好。 没多少工作是真正的人力优化，以及需要多任务处理，尽管如此，但您必须以某种方式处理它。上面的技巧有助于更好地处理它。

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

没有两个项目是一样的。下一次你做类似的项目时，你会有不同的客户，不同的目标，不同的团队; 甚至可能是不同的技术。即使使用标准工具和组件，您仍然需要自定义其配置和架构。当您处理软件项目时，请记住，它们涉及到50％至100％之间的定制工作。他们需要研究，讨论，思考，试验和其他高度不可预知的活动。在实践中，您可能会遇到与您之前所做的工作表面上出现的完全相同的项目类型的巨大差异。一个新的项目类型，扩展，几乎是不可能准确地估计。 如果它是如此不可预测，那么项目经理应该如何提出项目进度并坚持下去呢？ 文献中描述了一种正式的方法; 即将整个项目分成较小的步骤，估算每一步所需的时间，然后通过组合单个作品的工作长度来计算总项目长度。在MBA课程中教授的这种方法背后有许多理论。 不幸的是，再多的数学也救不了它。这种方法是众所周知的不准确的，已经到了完全不可用和不切实际的地步，更不用说它是如何耗费时间的。我从来没有看到一个项目经理使用正式的计算方法没有任何调整，甚至没有方法论狂热分子（使用）。甚至当公司严格强制使用这种方法的时候！事实上，效能最好的经理使用完全不同的替代方法，如下所述：

一个好的项目经理通过研究和观察许多过去的项目来调整自己的直觉。

一个好的项目经理会注意到项目类型，环境，涉及的资源，组织类型以及影响实际项目长度的所有其他工作方面。当然，没有人需要从自己的错误中学习。这种观察可以直接和间接地进行; 例如，通过书籍或者研究别人所做的项目，甚至只是将知识人传递给人。这种统计顶级知识改善了个人项目进度导航。 我想强调上述方法的两个重要后果。 首先，经验可以提高估计精度。没有一个没有经验的人有任何强有力的方法可以做到这一点。第二，即使最好的估计仍然只有统计学上的好。也就是说，可以说某个项目可能需要4到12个月的时间。假设这是正确的，应该明白，该项目在平均8个月的时间内将有50％的机会。 了解统计预测有如此令人难以置信的效果。一个聪明的经理只会对这样一个项目进行十二个月的估计，然后尽早完成这个项目。换句话说，没有人会期望一个团队遵循项目进度一天。 对项目经理及其老板的一般建议将是停止浪费时间在正式的时间估计方法上。相反，鼓励收集关于项目期限的统计信息，并在整个公司分享这些信息。我知道在全公司范围内实施这种方法的公司，正导致神奇的预测精度。

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

人类的心灵是由自然而设计的。即使它是不可思议的，依旧有其局限性。换句话说，它旨在在特定领域和特定类型的任务中表现优异。 开发人员的思想绝对是软件开发中的一大优势。作为项目经理，您是否有兴趣更好地了解它，并将其置于最佳状态？ 让我们简单的说，避免太多的理论。记住，理论只需要你到目前为止，你需要从经验中学习，无论是从你自己还是别人那里学习。 人类思维具有较强的问题解决能力和观念生成潜能。不幸的是，挖掘这种潜能并不总是可能的，主要是为了支持概念生成，您需要同时将所有问题集中在活动内存中。这就是为什么当一个任务被广义化或改写时，复杂的问题会经历一个简化阶段，以排除不重要的部分，同时减少在内存中保留的元素的数量。换句话说，我们既可以解决一个非常狭窄的复杂问题，也可以解决多个简单的问题。 然而，比例不是线性的。增加你同时做的事情的数量会大大削弱你解决问题的能力。这就是为什么人类总是雇佣和使用角色分离作为生活优化的原因。两个人在两项任务上分开工作会比他们同时完成这两项任务更快。 另一个重要的人类心理特征是，它不能像计算机那样立即在任务间切换。事实上，你不能只是不停地思考某件事。你不能马上就以全速开始思考一个新概念。空中交通管制人员完美地说明了这种精神惰性。即使他们正在看雷达，看到整个画面，他们仍然需要在内存中加载，以便快速操作。一个新的操作员要花十分钟的时间来观察屏幕，然后才能更换旧的屏幕。 更糟糕的是我们不能随意忘记事情。我们所学到的一切都与我们保持在一起，随着时间的推移逐渐消失，占据了我们可以用来获取新知识的空间。更糟糕的是，这种效应由于“未完成的事业”的感觉有时更加复杂。忘记一些已经完成的事情，而你以后却不需要它。然而，当你把事情放在完成的一边以后，你的大脑自然将其标记为“未来参考”的信息，不愿意让新知识取代它。 好的。现在我们已经概述了切换任务的想法，让我们来看看它在现实生活中（可以说）的思想实验。 想象一下，您有十位常规开发人员从事十项常规工作 - 每人一项任务。假设我们可以将他们包围在一个完美无暇的环境中，每个任务都可以通过一个单一的头脑在一定的时间内解决。整个事情花费的时间只需要完成最长的单个任务即可。 现在我们重复同样的脑力实验。这一次，我们将没有（重要）原因的不断地在开发人员之间切换任务。每一个开发人员每天都有一个新的工作要做。更好的是，让我们每小时换一次。你觉得他们多久会完成？也许永远不会。 第一种情况下的项目经理能够有效地执行项目。第二个人设法“处死”它，这是肯定的，因为它们有助于其死亡。恭喜。这种项目杀戮技术是非常有效的，因为除了浪费时间之外，它也将员工的士气降至零。

当人们遇到这种“任务转盘”时，他们失去了所有的成就感，意识到这个项目正向毫无结果走去。

大多数人会以纯粹的学术方式向他们呈现上述例子。然而，在现实生活中，他们在轻微的压力下突然忘了一切。大老板要求进度报告，或者客户询问某个功能的完成日期 - 几乎任何外部事件都可以使项目经理催促团队并表达自己的关注，其次是为了尝试在这里和那里赢得一点时间而重新开始任务重新分配，最终什么也没完成，导致项目脱轨甚至变得更多。 不幸的是，这是一个经常发生的现实生活场景。 一个好的经理站起来，通过吸收情感冲击波并将其转化为有前途的讨论项目，来防范团队的这种微小的干扰。这绝对是情绪上的困难，但这是让团队保持良好工作节奏并让他们实现的唯一途径。

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

T行业的运作理念是“设计过度”和“设计不足”。当它在会谈中出现时，每个人都说过度设计是不好的。那个人很容易回答，因为这个问题本身就表达了“过度”的负面含义，这意味着“太多”。真正的实践知道如何识别你的架构何时变得过度设计，并在早期阶段避免它。 让我给你几个我曾经尝试和正确的忠告。 首先，如果有另一个更简单的解决方案提供所有必需的功能，该解决方案可以算得上过度设计。这意味着如果你不知道一个更简单的解决方案，那你可以提供的在你的眼睛最好的一个就是最简单的解决方案，除非有人证明你错了。 如果我们假设架构师为了解决方案的完美而真正努力，通常的体系结构评估保证了它是最优的。不幸的是，体系结构评估至少需要一些其他合格的架构师。在许多情况下，它存在不可用或不切实际的危险。 在没有同行评议的情况下，建筑师容易出现常见的错误。 让我们一一审查一下，并讨论每一个可能的补救办法。 最流行的错误之一是设计没有商业目标。似乎很明显，任何工作活动都应该与最终消费者的满意度或公司成功或类似的业务需求相关联。然而，通常情况下，您可以看到架构设计在整个或部分中没有考虑到这些目的。这种推理要么是不存在，要么是归结为尽可能多地使用现代的铃声和口哨声。 在这种情况下，架构师不会做消费者支付的那部分。相反，他们玩弄酷的玩具是为了他们自己的乐趣和乐趣。这在正规的行业中是不可接受的。然而，这种情况似乎经常发生。 有时，问题在于架构师的个性和对某些技术或工具的痴迷。他们只是想使用它们，不能一致地解释他们正在试图解决的业务需求。接近这样的情况下，除了从小件中建立东西之外，人们什么也不知道。当然，任何外部事件触发了他们深入设计世界的冲动，永远不会回到真正的客户端。即使最初的触发可能是有效的商业投入，他们与实际的长期脱离减少了他们的作品的有用性。 治愈这个很简单，但需要自律。一个好的架构师不应该触摸笔和纸，直到他们清楚而诚实地回答为什么需要它。这样的需要可能会有不同的形式。这可能是一个正式的要求，产品改进的隐含需求，或出现使以前的设计不那么有效的新技术。无论如何，只要架构师本身了解驱动力，它不应该是一个正式的触发器。那么他们可以用这个力量来最终验证他们的设计质量。 另一个更难的可检测问题与块体系结构思想有关。有这样一种心态的人相信有一个解决方案，所有解决方案总是作为​​一个组成部分来实现。换句话说，它们直接将功能转换为组件，而不评估整体架构。当出现这种功能的需要时，他们可能只是附加一个向系统提供所需功能的组件。大多数时候，这满足正式要求，但使系统处于不连贯的状态。基于现有系统兼容性的开发，支持，甚至公司的许可模式，新的块未被选中。因此，团队会尝试修改现有配置或通过现有系统容量实现此功能。结果是， 对于这个问题，没有简单的解决方案，因为系统是一门艺术，无法预测新组件是否必须添加或可以避免。最佳做法可能是随着时间的推移积压积压的维护和架构问题，然后定期审查整个系统架构。这种定期审查也可能会考虑到出现的技术。因此，架构审查的一般目的不应该是解决问题，而是评估所需改进的潜在可行性和整个系统对现有即将到来的不可逾越的必然性。

规则7：评估团队成员

大多数IT行业的专业人士在面试中被问到是否是优秀的团队合作伙伴，还是在团队中表现良好。然而，可能没有人看到文学中明确的定义。显然，这样一个人一般会为团队的成功做出贡献，但很少有人能够确定这种成功的个性特质。 我观察到许多人在不同层次上工作，看到他们的个人素质如何影响到项目进展。我想提出以下关于团队合作中最有帮助的个人素质的指南。

沟通

当然，首要和最重要的素质是沟通的能力。 想象一个没有沟通能力的人。无疑，没有收到团队成员的反馈，他们就完全没有用处了。很明显没有人在面试中实际测量这个技能，，这意味着只要人们能够很好地说话，这个技能水平就够了。 沟通不是二进制是/否技能; 它更是一个信息传递窗口。越宽越多，信息交流越快越清晰。

沟通技巧是所有其他技能的乘数。

由于该窗口的开放范围在人口中有很大变化，所以这种窗口宽度的度量是团队成员的重要特征。请记住，我们正在谈论在这方面传达信息，而不是谈论平稳的谈话或鼓励人们，或通过谈话和沟通来激励他们或组织他们。 沟通风格也是无关紧要的。信息可以口头，文字，图片或混合的方式交付。这个人可以说话快或慢。他们可以很友善，就像看着你的眼睛一直微笑，或者他们可以看出来，说出一个单调的声音。风格可能会影响您对同事的个人认知，但只要您清楚了解自己的意思，任何风格就足够了。 我们来探讨和衡量沟通能力的实际情况。 一般的沟通技巧有两个主要方面。首先是分享信息的意愿。有些人渴望分享，但有些人试图隐藏信息。这种倾向或多或少是自然的，但可以用自我激励和训练来缓慢变化。可以假定展示一种信息共享意愿的人将来也会展示它。这就是为什么这个特质有助于预测候选人在一个团队中未来的成功。 在现实生活中，试图隐藏信息的人很容易看到。他们通常试图放弃有意无用的信息，而不是任何实际需要的信息。或者，他们提出初步问题，将信息流向内部转移，并尽量减少对“需要知情”事件的回答。无论他们的策略如何，最终都会感觉到您没有获得所需的信息，或者获取所需的信息需要太多额外的努力。 了解意图很重要，因为某些类型的开放人员可能会问你初步的问题，以便更好地了解您的问题，然后以最方便的方式为您提供答案。意图隐藏信息的人会提出其他问题，只是为了引导谈话，而不是回答你的初始问题。 沟通能力的另一个部分是调谐到听众的能力。 不同的人具有不同的主题理解水平，不同的沟通方式，甚至可能对具体细节有不同的兴趣。一些交际聪明的人会根据听众的理解能力和准备他们的答案提供具体的信息来改变他们的谈话流程。在这样的准备中，可能会要求一些初步的问题来缩小听众的兴趣。“解决”沟通差异的能力是非常好的技能，因为它使我们能够在几乎所有的情况下实现理解。另一方面，灵活的谈话者有时可能会陷入无法解决的误解的死路之中。

了解优点和缺点

让我们专注于团队合作伙伴的另一个个人素质。 大多数人会同意，团队环境应该比平均周边世界更友好，以促进协作并提高生产力。因此，团队必须了解每个成员的优点和缺点，妥善分配任务，并强化优势。这条道路的第一步是让所有成员诚实地衡量他们的技能。从心理上来说，这可能是艰难的，因为我们自然会隐藏我们的弱点，保护自己。 在这里，友好的团队气氛会有所帮助。

建立信任是一项两个人的工作。

因此，新成员被期待按照团队规则进行游戏。不幸的是，有些人即使在友好的环境下也不能降低警惕。他们在一生中表现得像孤狼一样。这比他们更强。可悲的是，这种态度对团队的努力没有帮助。 在面试中有一个简单的技巧来识别这样的孤狼。他们从来没有承认他们不知道什么。当然，人们喜欢表现出最好的效果，展示出他们所有的能力，并努力解决每一个单一的问题。然而，每个人都有知识限制。我们的极限塑造了我们的技能。不承认限制意味着候选人将自己作为一个杰克的所有交易，同样擅长的一切都没有。 当你聘请专家时，你可能想避免这样的人。此外，这种傲慢的态度常常带来另一个红旗的特点：不愿意要求帮助。要求帮助的能力对团队合作至关重要。没有它，我们就不能快速发展和发展。这样一个顽固的人会燃烧公司资源和时间，无限期地对付困难的任务，但是永远不要打电话给队友寻求帮助。在面试中发现这样的候选人是一个容易的伎俩。问他们一个没有意义的问题或提到一些无意义的术语。一个正常的，理想的好奇的人只会说他们不知道是什么。一个防守的人永远不会这样做，即使你强调没有正确或错误的答案，“我不知道”也不会取消他们的资格。

规则8：重视团队合作

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

构筑专长

每个IT项目都是独一无二的。要成功，需要学习和掌握项目细节。它们可能包括技术和非技术知识。非技术知识的一个例子可以是管理，客户，技术支持团队等的个人网络。特殊技术知识是一般IT技能的额外细节。 例如，您可能需要知道Maven来构建一个项目。然而，确切的构建结构，属性和过滤的位置仍将根据项目而有所不同。与任何类型的知识一样，掌握这些细节需要时间; 投入更多的时间，他们可以表现得越好。时间是你最有价值的资源。您希望尽可能长时间将您的团队成员专注于相同的功能领域，以便利用他们的专业知识并进一步开发，从而不断提高团队绩效。 不幸的是，不可能无限期地做到这一点。从一方面来说，人们可能会觉得无聊。从另一方面来说，您有失去专业知识的风险，意外地将您的项目置于危险之中。 让我们看看有没有办法应对这些缺点，而不会阻碍团队表现。

大多数智力工作者都是自然学习者。他们想学习一个特定的领域，直到他们擅长。

在团队成员之间分配重点领域，并让他们在其中建立自己的专长。在某种程度上，它们达到了足够高的水平，这在本项目的范围内是有意义的。此外，额外的学习努力不会显着改善。没有动力和挑战，聪明的人变得无聊，开始讨厌他们的工作。 通过为他们的其他地方开放学习机会来防止这种情况。让他们知道项目和公司的技术栈，开辟新的挑战。如果他们的兴趣在项目的范围之内，您将获得双重奖励，以保持您的团队的挑战，同时扩展有用的团队技能。然而，任何自我发展都是好的，以避免无聊，即使它不与即时的项目需求相交。只要团队专家大脑参与，他们就会继续支持已经学习的项目区域。 离开公司时，团队专家对他们的专业知识占有很大的份额。您可以使用的对策之一是广泛传播可以即时更新的文档。想想前面提到的“持久性内存存储” 不过，如果可能的话，项目经理会喜欢在团队成员中重复知识。每个专家中有两个将是一个简单的解决方案，虽然是昂贵的两倍。但是有一个更精简的方法来做到这一点。诀窍是让大多数开发人员在多个领域开发专业知识，以便每个项目方面至少由一位深入的专家所涵盖。同时，选择了一些资深会员，随着专业知识的深度，逐渐形成广度。通常，这个角色最好由团队发展主管或建筑师进行。团队负责人与所有团队成员进行互动，并参与所有任务实施。他们可以利用项目的各个方面，了解其所有的内部构件。这样，即使你失去了专家之一， 相同想法的另一种风格是在相邻地区交叉培训开发人员，让他们观察，学习，偶尔尝试同行的工作。请记住，这种交叉训练不需要广泛，因此不会影响开发人员的主要任务，也不会妨碍生产力。在领导层面和交叉培训开发人员方面开发专业知识，为您提供了一个防止意外生活凶手的缓冲，让您有一段时间用项目资源进行操作。

最小化分心

软件开发是一个复杂而创造性的问题解决链。尽管如此，随着行业发展，这些复杂的问题越来越自动化，工作并不容易。它仍然涉及大量的艺术和个人洞察力，这很难预测，有时甚至更难扭转。 开发者是武器的边缘。他们的注意力相当于武器尖端的硬度。增加焦点，你会通过黄油切割热刀等问题。分散他们，你会用钝的棍子笨拙地戳在黄油上。 这是不能过分强调的：不能解决问题的工作可以用动机或额外的努力来加强。**对于解决问题的工作，您需要从平凡的世界中脱颖而出。**留下所有日常问题都是困难的，一个好的项目经理应该在身体和精神方面建立一个安静的发展环境。开发商的工作场所应该类似于感官剥夺坦克。 实际上，这是一个封闭的工作空间。每个团队成员至少应该有一个立方体可以潜入孤岛。最好避免大声的噪音和走道的谈话。电子邮件和聊天应该保持快速的人际沟通。大型团体应该使用封闭的房间进行会议，以免分散他人的注意力。这是一个非常标准的办公室生活照片。 不幸的是，即使在大型办公室，开放空间范式也越来越广泛。我会警告他的时尚潮流。更糟糕的是，与开放空间一起，高层管理人员鼓励就地团队对话。也就是说，在一个没有参与的团队成员的头上，就是向另一个人喊叫。每天二十次大声交谈的开发人员将不会有剩下的浓度。当然是一个主要的表现杀手。

允许学习曲线

知识本身就是力量。对于IT这样一个复杂的行业来说尤其如此。这里的每个任务都有其定期循环：学习，研究，实施。特别是学习阶段是无价的。不仅更好的理解能够更好更快地实现，必须通过某些知识阈值才能实现某些事情。当然，过度学习也没有意义。每个技能都应该符合生产需要，而不是在其上面。 然而，经常，开发商在相反的方向受到压力; 停止学习，只做生产。学习被认为是浪费的努力，因为它不会移动任务进度条。这似乎是一个很容易解决的问题，坐在家里阅读这篇文章。然而，在现实生活中，最轻微的工作压力使每个经理成为那个坚持要求每个人“停止学习，开始做某事”的笨蛋。我发誓，在整个职业生涯中听到过这么多次的确切的话…一个好的经理团队领导应该明白，学习是进程的重要组成部分，即使它不直接增加进度条。

建设竞争发展研讨会

上述提示和技巧是有效的软件生产专长的一个子集。通过了解和应用它们在现实生活中，您将逐渐提高您的生产效率。如果你认为他们在很大程度上没有联系，缺乏理论基础，你是绝对正确的。 我想强调，建立竞争性发展研讨会不是一个单一的任务。它需要在多个相邻区域的知识和专长。建立这样的专门知识是一项艰巨的工作。没有一个理论基础或想法可以立即解决您的所有问题。相信这样一个银色子弹只是为了分散你的真正目标。 在工作中尝试这些提示，看看他们是否值得永久采用。如果您发现他们有用（或没用），请在下面发表评论并分享您的经验！