我们将继续分享J.H. Rainwater
的生存技巧初学者技术
指南的摘录。 在第一个系列中，我们讨论了经理通常必须与哪些类型的开发人员一起工作； 现在，让我们尝试了解如何处理所有这个动物园。 技术团队中的组织活动可以分为两个部分-或多或少的本机工作（例如代码审查和体系结构管理）和程序员一生所没有准备的全部工作，即管理人员和流程。 我们先和一个陌生人打交道。
优先次序
通常击倒新出炉的领导者的第一件事就是大量信息的雪崩。 这种情况是很合乎逻辑的：团队负责人在框架中的封闭程度较低，并且参与了更多的过程，但并没有变得更容易。 结果，技术领导者经常开始分散精力-考虑到他对每个信号做出响应的职责，他立即抓住所有东西，从一项任务跳到另一项任务，而错过了最需要注意的地方。
仅有的出路是-过滤此信息流，分离与主要任务直接相关的内容（发布符合商业要求并在约定的期限内满足要求的代码），然后将主要信息发送给积压。 但是起初，这种分类的标准可能并不明显。 对于初学者来说，一切似乎都非常重要。
使事情复杂化的事实是，许多刺激会激发情绪，从而干扰人们明智地评估问题的重要性和紧迫性。 传入的信号可能会引起关注（在代码中发现了一个奇怪的异常），内（设计人员回想起他已经多次请求实现自己想要实现的功能），忧虑（用户对更新表示不满意）。
为了更成功地将所有请求和信息系统化，作者建议使用以下矩阵来处理它们：
- 新数据如何影响项目范围，设计决策和项目期限？
- 信息来源可靠吗？ 如果没有，可以忽略吗？
- 我应该立即对收到的信息做出反应还是可以稍等一下？
- 在何处以及如何保存信息，以便在必要时可以迅速解决？
- 信息的有效期是多少？ 什么时候变得无关紧要？
- 该信息与该项目的已知信息相比如何？
如您所见，此矩阵有助于在几个方面从谷壳中分离出谷物：摆脱坦率的无用或不可靠的信息，移走其他可以移动的内容，以及严格评估信息对当前项目的重要性。 但是，有关时间安排和存储方法的问题暗示，目前不相关的信息原则上不应被视为无关紧要的，这是另一个极端，从长远来看，这将导致团队陷入停滞。 我们稍后将在讨论“领导力”和“领导力”的概念时对此进行更多讨论。
庞大的项目
下一个痛点是工作量和工作条件的评估。 同样，一段时间以来，对于初学者而言，在这方面``游泳''几乎是不可避免的-需要经验，以便能够一次审查项目的所有组成部分而不遗漏任何东西，并且从第一次尝试为每种类型的工作开始，包括不熟悉的适当术语。 但是，即使获得的经验也无法从某个错误中保存下来，并且不可能将其减少到零。 汉弗莱恰当制定的两个定律阻碍了工作计划的极高准确性：
任何过程的持续时间都将超出您的预期。 总是会出现您没有想到的东西。
基于所有这些，作者呼吁从哲学上对待这个问题。 作为最近似的方法，最有可能的是，您将无法考虑到任何不太明显的功能或无法预测的复杂性，并且它们将需要您未抵押的额外资源。 对于这样的意外，您需要准备并准备一个团队-教人们快速重建以“修补漏洞”，为他们留出一点时间来应对不可预见的情况。 在任何情况下都无法将自然增长视为紧急情况，并寻求有罪感，尤其是在其他部门（这总是很诱人）。 因此，您只会在团队之间撒下仇恨，而无助于解决问题。
尽管如此，不应完全落入宿命论：项目的增长仍然是计划缺陷的结果。 您将无法完全摆脱它们，但是您可以并且应该减少注意力。
如果我们将汉弗莱定律转移到程序现实中，则很明显，计划的下降有两个原因：对细节的分析不足以及对软件产品设计持续时间的过于乐观的估计。 经理之间的乐观情绪通常会自然而然地消失：几次超出最后期限，您就会强迫自己开始谨慎行事。 至于细节，该技能也随经验而来，但是从一开始就应该大致了解路线图是值得的。
例如，如果您着手进行包含此类文档的项目，那么面前将会有很多自然灾害和麻烦：
如果路线图与下面的示例更加相似，则获得满意结果的机会将大大增加：
除了这两个原因，Rainwater还列出了一些其他风险因素，Robert Glass是一本关于IT领域的灾难项目的悲伤著作的作者，他着重指出：
- 项目目标规范不充分
- 该公司的新技术应用
- 年度/项目管理方法缺失
- 小组中缺乏领先的专家
- 硬件/软件制造商破坏协议
通用语言搜索
您可能以为我们在谈论交流才华的沟通技巧，但是，不，标题的含义更为直白。 在不同的公司中，程序员团队的形成依据不同。 如果幸运的话，您可能会负责使用您的本机技术堆栈的人员。 但是经常会遇到混合团队，其中不同的员工说不同的语言。 有时这种困惑使领导者生活困难。
负责人的职责之一是监督团队的所有活动，以确保发布到世界上的所有代码都有效，高质量并且没有过多的复杂性。 如果您不熟悉下属在开发时使用的工具，那么您的双手会被束缚。 您无法独立进行代码审查，只有在测试阶段才能了解严重的错误，这会破坏整个工作节奏，并且粗略地说，这很容易被人发现。
在这种情况下该怎么办？ 通常，有两种方法。 如果语言和技术的集合不是太大且不能更改，那么您将不遗余力地尝试至少在基本级别上掌握它们。 这也许是最好的出路-因此您不必依赖任何人，您将直接收到信息，这意味着在讨论功能，要求和截止日期时，您可以避免“死电话”。
如果无法自己学习必要的语言，那么您将必须寻找委托这种责任的方法。 作为助手的核心，他们可以为您提供关于每种不熟悉的技术的客观，诚实的反馈（如果只有一名员工拥有，那么这种方法自然就行不通了）。
出于另一个原因，加深您对与技术和工具相关的问题的了解也很有用-这是从字面上讲成为技术领导者的唯一方法。 在他的术语系统中，作者将“经理”和“领导者”的概念进行了划分。 经理是组织工作，解决日常问题并确保按时正确完成当前任务的经理。 领导者是一个战略家，他在控制期限之外进行思考，为团队设定总体行动方向，提高标准，重新思考并优化流程。 当然，在开发团队中，这种有远见的工作需要对技术市场有很好的了解。 在此背景下，技术负责人不断估计当前工具包已过时，需要更换，监视新产品，同时具有足够广阔的前景来评估其真正的优点（而不属于特技综合症）。
在本文的第一部分中，我们谈到了领导者不必担心他会退出与技术合作的事实-对于那些为领导者做标记的人来说确实如此。 但是在这里，从同一位置重复警告是有意义的：不要希望同时逃避经理的责任。 管理涉及两个角色之间的平衡，有时这是冲突的，但保持团队生存所必需的几乎相等（管理有些逊色）。 磨练组织技能以发挥自己的优势-每天吃的时间越少，您作为技术专家的成长就越快。 如果将日常任务留给机会，混乱将成为主流，不再有任何策略。
羊群采摘
现在我们来讨论第二个问题-与人臭名昭著的工作。 让我们从头开始：在谈论如何管理人力资源之前，您需要弄清楚从何处获取人力资源。 即使您已经建立了团队，迟早也会出现有关招聘员工的问题。 之前，我们分析了程序员的类型，并指出了那些首先应该被追逐的人。 现在，您需要了解如何采取行动，以便在候选人中找到必要的素质，而不要对他们的选择感到失望。
作者提供以下采访建议：
- 给应试者一个测试任务。 为潜在的员工设置一项任务，他必须立即解决该问题，或者将其带到家中并在到期日之前解决。
- 确保对候选人的技能进行口头测试-这样您就可以评估他的知识和在压力大的情况下清晰思考的能力。
- 尽可能写下所需雇员的职责，他必须执行的所有任务，并将此清单交给候选人进行审查。 因此，对话将立即变得更加客观，并且通常会更加坦率。
- 不要将自己限制在一次会议上。 如果候选人不仅与您进行沟通，而且与上述“核心”（您的助手，代表，团队中的领先开发人员）进行沟通，那将是非常好的。 但是与整个团队安排一场演出并不值得，这已经太多了。
- 个人素质的验证，类型学测试等是可能的，但可选的步骤。 仅在候选人不反对并且您拥有可靠的评估工具时才诉诸于此。
说到雇用，一个人不得不提及另一面-解雇拉低团队的工人。 在这里，雨水采取了相当艰难的立场，并毫不犹豫地建议摆脱那些表现不称职或有问题的人。 最好的位置是发出警告的政策：它给一个人改善的机会，但不允许滥用这一权利。 如果某个员工落入“黑名单”，并且您与他进行了交谈，则需要特别注意监督他的进一步成功。 这需要额外的努力，因此给第三次机会已经是不合理的浪费。
此外，不仅抽象的“共同原因”通常会遭受团队成员的疏忽，而且还有非常特殊的人，他们必须纠正他的错误或忍受他破坏了他们工作成果的事实。 因此，过度放纵是要付出代价的，并且不太可能增强您的领导地位。
员工工作安排
舒适的生活环境这本书在这方面非常注意。 要从您的员工那里获得最大的生产力是领导者的直接责任，但是高生产力需要高度集中，如果程序员被四面八方的刺激物包围着，集中精神是不可能的。 因此，领导者必须尽其所能为团队提供良好的工作条件。
设计Rainwater所提供的办公室的具体建议在某些地方听起来有些田园诗（例如，在一个兄弟的单独办公室中），在某些地方听起来像是遥远而艰难的过去的回声（每个开发人员必须拥有自己的计算机）。 但是总的原则仍然是合理和适用的：对于程序员来说，要想成功地开展工作，他们必须一方面有机会在团队中工作一段时间，另一方面则有机会独自洗脑。 首先，您需要配备适当的培训场地：带投影仪的会议室，带有臭名昭著的网球桌或游戏机的休闲团队（理想情况下）。 第二，有必要组织可用的空间，以使人们尽可能少地被噪音，闪烁，气味和其他干扰因素所分散。 如果条件恶劣，请让员工，特别是有价值和可靠的员工，在家工作。
必需的最少便利设施还包括现代化的高质量设备，开发人员可以在合理的范围内自行配置。 如果汽车虚弱且过时，则无需谈论技术突破，您不仅可以安静，无故障地运行。 对于测试程序，应分配可重现标准用户特征的特殊设备。
工作时间我们概述了技术顾问的职责，这表明他的工作时间几乎应增加一倍。 但是在这里您必须小心。 问题在于，在他的工作方式下，经理本人不情愿地为整个部门定下了基调。 如果您坐得晚，工人们会认为他们也会有类似的期望。 结果，加工过程可能会渗入您当地文化的血肉之中-这充满了麻烦。
首先，并不是每个人都会对这种状况感到满意。 首先，加工将打击那些承担额外义务的人，例如家庭义务。 如果有很多这样的人，团队中的情况将会很紧张。 嗯，其次，作者像他之后的许多人一样指出，额外的工作时间更可能损害生产力-既是由于疲劳，又是因为动力下降。 在课上要求学校进行有效的工作比灌输会导致倦怠的习惯更明智。
任务分配与监督说实话：即使理想的条件和温和的时间表本身也不会鼓励人们自我组织和勤奋工作。 除其他事项外，还需要一个老板来分发工作并确保其得到执行。 您的一部分时间应该控制住-顺便说一句，这也有助于集中精力。
作者建议不要将下属的“报告期”过多划分，也不要在每天都要求获得结果的情况下不停地观察他们。 确定每周的任务清单并评估同期的工作量比较明智。 在特别炎热的时期，由于出现紧急事件和优先级的变化，即使在很小的间隔内也必须对清单进行调整。 领导者必须牢记所有这些变化（以及现代现实，并在适当的会计系统中进行调整）。
如果领导者以已经确定的工作节奏来到“外国”团队，那么值得每位员工以同样的方式来描绘他的日常任务。 这样的文档可以揭示很多有趣的事情-不仅涉及谁，涉及什么以及之前如何进行管理，而且还包括人们通常对责任的看法。
至于这些清单的内容，当然，在许多方面，将取决于员工的技能和公司的要求。 但是，有了这一切，本书提出了一个想法，即有必要尽可能地轮换任务-开发人员不应每周都做同样的事情。 这有几个原因。 首先，它有助于保持团队的健康氛围：由于某人经常感到最不愉快或相反，最有趣的事情，减少了日常工作和单调的感觉，因此没有冒犯。 其次，程序员需要保持良好的智力状态-各种各样的任务将为此做出贡献。 最后，通过这种替换，将需要最少的精力来形成一个工作台。
Reinwater非常重视板凳。 这里的主要思想是，在任何开发人员生病，休假，解雇，过早死亡的情况下，团队应包括能够履行其职责的人员-至少在此期间，直到雇用替代人员为止。 这不仅确保了部门的平稳运行，而且避免了其他一些问题（例如，公司对Wizards的严重依赖）。 因此，有必要保持雇员对相关技术的兴趣，以各种可能的方式鼓励合作和参与“外国”项目。
顺便说一句，老板本人没有受到砖块掉落的影响。 因此，一旦您习惯了这一点，就开始考虑要由谁来接班。 这不仅是再保险，而且是委派任务的好方法-在准备继任者时，您无意间必须考虑哪些工作最容易，最安全地委托给他人。 在流言mag语中，此知识将非常有用。
最后一点：到目前为止，主要是为了团队和上级的利益，但不要忘记我们仍然与人合作的事实。 应尽可能考虑员工的个人喜好和特征。 您不应该期望很难从一个人切换到另一个人的特殊机动性，也不能出于正义的原因将“刹车”发送到他害怕不能应付的任务等等。 在这里，我们再次反对这样一个论点，即我们需要仔细监控员工并充分了解他们。
激励与鼓励
但是关于鞭子的知识已经足够多了，让我们来谈谈更愉快的事情-程序员应该从工作中得到的那些姜饼。 雨水列出了以下类型的姜饼（按优先顺序排列）：薪水，职业发展，友好的用语，最后是抽象的公司荣誉。
在薪酬方面，离开开发人员的经理们不太容易挑剔，但常常陷入相反的极端，高估了员工的期望。 在制定费率决策时，请记住以下因素：生产率，经验，效率，任务的及时性，当前平均费率，市场条件和公司标准。 一个常见的错误是提前加薪，希望这会鼓励工人全力以赴。 , – , .
, , , . , , .
– . , , , (, , «»). . – , . , , , .
, . – , -, , , , . : , . « » , . ( – ) – .