安排管理

让我们谈谈安排安排。 为什么这突然呢？ 是的，因为我们在TeamLead Conf上喜欢讨论痛苦和问题，但是我们不会忘记解决方案。 当然，每个人都有与工作安排相关的问题。

“没有执行安排，”船长证据

首先，让他们感到痛苦的是，这些协议得不到履行-每个人都知道这一点，即使我们的朋友，证据上尉，也会在本文中为我们提供帮助。

看来是什么问题？ 许多事情并没有如我们所愿。 例如，圣彼得堡并不总是晴天。 那么，这座城市屹立不倒，人们来了，就喜欢它。 我们想要的方式没有发生的事情并不总是一个非常严重的问题。

但是，在这种情况下，Stas Mikhalsky声称问题不仅仅严重。 在削减之后，我们将了解导致该协议未得到执行的事实，以及最终如何使它们坚不可摧。


关于演讲者： Stas Mikhalsky自1998年以来一直从事网络开发。 他从初级的Perl程序员转到Biglion的开发总监。 他参与了数十个项目的开发，并提供了大力支持。

为什么这是一个问题

我们团队以及团队领导者的业务和领导力正在等待结果。 按时完成任务可能不会导致结果，但这是另一回事。

工作和结果是两回事，但让我们再谈一次。

结果是工作的结果-任务，项目，子项目的完成。 可能会有不同的划分，但一种或另一种方式是，该工作由一些操作组成，每个操作实际上都是协议的结果。

看起来-一切都很清楚： 当我们不执行任何操作时，我们就会违反协议。

让我们考虑标准示例。 遵守代码风格标准是与特定开发人员的协议。 并非整个团队都用一个声音回答：“是的，明智的Kaa，我们将遵守代码风格，”但是每个人都亲自说他承诺遵守它。 在星期五或星期一发布该版本也是一项协议。 无论我们做什么，都会有人问我们这个问题，或者我们自己认为这对于某些事情是必要的，如果可以期望我们取得结果，那么这是作为协议一部分采取的行动。

-如果我们自己决定他们期望我们这样做-这是协议吗？
-是的，与他自己达成协议，但这是特例。

现在，最有趣的事情实际上是相反的：协议失败=行动失败。

也就是说，如果不执行该动作，则不会破坏协议，但是未执行的动作是协议失败的结果 。 我们不同意，因为我们不同意，或者我们真的不想要，或者其他。 协议中存在中心问题。 因此，我们得到了这样的印象：协议失败会导致行动失败，这当然会影响工作质量，最终导致结果不足。

我想向您传达一个想法，即开发人员，后端，前端，测试人员，团队负责人，开发经理都是我们在其中执行某些职责的角色。 但是，如果您看起来更高一些，那么我们的所有工作就是达成协议及其执行。 就像UDP-其他所有内容都封装在协议中。 如果我们不知道如何正确地达成协议，那么我们可以成为优秀的前端或后端，编写出色的代码，但是没有结果。

相反，如果我们学习如何创建正确的安排，则：

• 节省大量时间；
• 显着减少所有控件，拆卸等的开销；
• 我们真的可以做我们的工作。

怎么办

“确保安排得到执行”

队长证据

这对每个人都是清楚的，即使是证据队长，您也只需要确保协议已得到执行，而不必这样做就不会执行它们。

如何做到这一点的经典模型：

1. 了解原因。
   
2. 确定并采取措施解决这些原因并改变结果。
   

让我们再详细一点。 有三个演员：

1. 处理的安排 。
   
2. 安排发生中断 。
   
3. 失败的原因 。
   

如果您从各个方面看待所有这些，那么您可能可以理解问题所在以及如何改善情况。 我希望情况需要干预，每个人都同意。

什么安排？

该安排包括两个部分：承诺和承诺。 它们之间的区别是作出承诺，作出承诺 。

许诺是一种内脏，这是我向某人作出承诺的信息。 原则上，它甚至不能给出，因为这只是一条通知消息。 但我承担这项义务。 因此，没有承诺的承诺比没有承诺的承诺要好得多。 我们经常遇到后者。

老实说，在我看来，整个问题在于，在达成协议时，并非所有（而且我们也是如此）并非总是这样。 我们并非总是有意识地做出决策，并不能真正理解这一诺言威胁着我们什么。 我们只是点头：“是的，是的。”我们要走了，但是我们不承担我们的义务-这是一个大问题。

实际上，它仍然更加复杂，因为安排的类型不同：

• 作为其直接职责的一部分 ，例如，用代码编写注释，完成对环境的发布。
• 在主要工作之外 ，例如，监视Wiki中信息的相关性，看书，上课。
• 更改行为 ，例如，在某个小时开始上班，或者跟踪花费在任务上的时间。

这些是完全不同的协议，人们对待它们的方式有所不同，您需要以完全不同的方式使用它们。

通常，主要工作的范围超出了问题，在我看来，从某种意义上说，这比开发人员的当前编码水平更为重要，因为开发人员可以通过它们进行转换。 如果一个人知道如何学习，那与10年后才学会快速编码且没有错误的人完全不同。 有时候，与开发人员达成协议来读书可能比要求他记录代码困难得多。 但是在改变行为方面更有趣。

一个经典的例子，当它过去不重要到10或12时，因为（如果有的话）您可以延迟并完成它，但是现在您需要不晚于11到达工作场所，因为流程等等。 如果一个人简单地同意：“是的，我明天明天11点会来”-这不是行为上的改变，而是一项壮举。 如果事实证明为此，也许有必要重建生活-早点上床睡觉或不玩魔兽，那么这意味着该人本人必须改变。 像任何项目一样，这是困难的，而且最重要的是不可控制的。

因此，了解所涉及的协议非常重要。 详细程度取决于我们要达成的协议类型。

破坏

协议不仅破裂，而且它们首先，出乎意料地破裂，其次，在终点线破裂，因为这非常有趣。 尽管这是出乎意料的，但通常是可以预见的。 我总是知道协议何时会破裂。

我们现在正在团队合作中，单身人士和车库计算机的时代已经过去。 我们有一个团队，流程和每一个安排，都是连锁的。 如果它崩溃了，那么一切都会崩溃。 如果一个人只是没有读过这本书，那么原则上不会有坏事或坏事，但是一年之内，您的团队就会突然变得比现在更好。 对我来说，这个文件比所有系统两个小时的故障要大得多。

干扰也不同。

失败是我最喜欢，最诚实，最无害的一种失败。 我们答应了，那个人答应了，没有答应-它发生了。 这是一个简单的故障，因为一切对他来说都很清楚。

还有更多不愉快的选择，例如正式执行。

正式执行是指开发人员（用于获得灵感的啤酒吊舱）在星期五晚上散布40小时的工作时间，以完成他一周内完成的任务。 实际上，与您达成此协议的人目前未收到任何东西。 如果不必为了使每个人都精打细算而进行时间记录，而是为了统计地了解不同类型的任务花费了多少时间，平均错误是多少等，那么这种执行就会破坏整个计划。 因为数据是从头获取的，所以不会有统计信息。 结果，虽然似乎已经完成了某些工作，但一切都很好，但是该协议没有得到满足。

问题在于，我们并不总是将正式的履行登记为破裂的协议。 特别是如果您对自己不是很感兴趣。 例如，我是团队负责人，主管从上面告诉我：“写手表，否则我会惩罚所有人的！” 我来到团队并广播我需要记录时间，否则每个人都会受到惩罚。 结果，以某种方式记录了时钟，我很满意-我有事要给导演看。 我本人也参与了这次破坏活动，对我而言，正式处决很重要。 对于任务提供者，这是不可接受的。

替代与形式的正式实现略有不同，但实际上，这是违反协议的相同尝试。 只是代替了已完成任务的可见性，而是创建了替代项。 以时间记录为例，听起来像是这样：“要记录每个任务的时间，我需要5分钟。 总共是一周两个小时。 哦，他。 我已经在4个小时内完成了我不打算做的任务。 但是我做了比我承诺的更多的事情，也没有说我没有典当时间。

这是尝试为您提供一些东西，以便您落后于支票，但实际上这也是一种故障。 问题是，通常，我们还有很多其他事情，不安全的时间并不是最糟糕的事情。 我们宽恕自己。

我再说一遍：一份出色的协议是一项负的工作，一个结果是负的。

如何在未完成的安排中生存？

您可以简单地提醒 ：“您还记得我们记录时钟吗？”。 当谈到改变行为时，提醒是一个很好的概述。 支持行为模型的最狡猾的挂断海报：“承诺的时间-拯救了海狸！”。 实际上，我们只是提醒您，已经达成协议，而无需检查当前状态。

您可以更加坚持不懈 ，询问该协议的实施方式，此人是否已经做过什么。 这与提醒的不同之处在于，它会迫使您给出明确的答案。 但是，因此您将人置于选择之前：撒谎或不撒谎。 顺便说一下，答案并非对所有人都显而易见。 从某种意义上说，你是在把一个人推向坏处。 询问是一种潜在的控制方式-它似乎是被询问的，但未被选中。 该人撒了谎，但我们把它留在他的良心上。

您可以检查 ：

• 结果
• 一步一步地
• 在动力学上。

通过我们已经讨论过的结果进行验证。 问题是如果结果不令人满意该怎么办，但我们稍后会再讲。

通过步骤和动态，可以检查工作中和工作中协议的履行情况。 例如，我们说服一个人填写了一个知识库，与他一起概述了一个计划，然后根据该计划进行了工作-这仍然不存在。 但是行为改变呢？ 一个人要么记录时间，要么不记录； 要么准时到达，要么不准时。 循序渐进地跟踪这种转变真是荒唐可笑-今天晚了半小时，明天25分钟，第二天20天。

最大的验证问题是这并不总是可能的。 由于始终与许多人达成协议，因此这也是非常劳动密集型的 。

存在一种管理模型，其中经理几乎所有时间都花在任务执行控制上，但是在IT中无法很好地工作。 是的，这是上个世纪。 我希望这种管理方法有一天会像最后的恐龙一样消失。

与其控制，不如让我们更好地理解崩溃的真正原因-为什么向我们作出承诺的人没有履行承诺。

故障原因

这可能是不完整的列表，但以下是最引人注目的示例：

• 不合理的同意。 一个人同意，因为拒绝让您感到尴尬：您是他的领导者，还是一个受人尊敬的人，或者他真诚地想要帮助您，他喜欢您，或者他根本不愿意拒绝。
• 评估错误。 一个人可能会认为，同意但在评估中犯了一个错误。 然后他会说：“是的，我答应过，但是这项工作是我预期的两倍。”
• 优先次序的变化： “我快要结束了，但是瓦西娅来了，他有一个更重要的问题，所以我很抱歉。”
• 缺乏资源 -只是没有足够的时间。
• 不可预见的情况 -钢琴从天而降 。
• 破坏

在所有借口背后通常都是挫败协议之王-破坏行为 。 当我们不想做并且不想承认我们不想做时，我们遭到破坏。 每周使用method方法喝40个小时的工作是破坏活动。 早上9点上班来喝咖啡是破坏活动。 它基于不愿做的事，尚未明确表示。

实际上，发生故障的原因更多。 我们所说的只是表面上的内容，如果您深入研究，只有三个原因：

1. 未考虑安排类型。
   
2. 协议的类型不同意。
   
3. 没有义务的承诺。
   

此外，第一段和第二段可以同时存在。 达成协议时，我们不会考虑达成的协议。 通常听起来像这样：

-爱琴海！
-好的，我会做！ -逃走了。

当我们谈论工作时，例如编写模块：“快速完成任务28”时，就可以做到这一点。 但是，例如，要为一次集会做准备时，就无法做到这一点。 以一种好的方式，为了在会议上准备演讲，您需要坐下，整理一下，解释它的重要性等等。 但是我们经常以相同的节奏做所有事情 ：“这样做”或“看，别迟到了！” - 然后跑了 。

碰巧我们对协议的类型有不同的理解。 一个经典的例子是代码文档。 在过去的时间里，一切都可能发生了变化，但是当我遇到这个问题时，我和我的同事们一直在争论开发人员是否应该编写代码。 作为领导者，我认为我应该这样做。 开发人员认为，考虑到工作量和不断变化的优先级，代码可以正常工作。

在安排类型的理解上并不总是矛盾。 我们通常认为，不需要澄清，加强该协议，因为一切都已经很清楚了：只需接受并执行。 下属认为，从他那里他想要超越他不想做的事情。 然后破坏活动开始了 。

正如我所说，最普遍的情况是没有义务的承诺。 达成承诺但没有达成义务的协议将不会因一个或另一个原因而履行：钢琴会跌落，一个人会分心，还会发生其他事情。

实际上，在系统复杂的情况下，变化的强度是：当我们匆忙编写时，迅速推出，重做它，换句话说，在熵的情况下，总会发生某些事情，这会阻碍协议的实现。 当然，您可以控制每个步骤，利用每个下属的每一个案例，尽力帮助他达成我们的协议的执行。 但是，接下来将没有足够的时间来完成您自己的所有事情。

达成协议的唯一机会是一个人想要履行协议。

如果我希望履行协议，我将处理所有的问题：钢琴坠落，我在评估上犯了一个错误等。

这与Scrum的思想相似，只是任务的复杂性尚不完全清楚。 我们以先前的经验为基础做出一些假设，进行评估，然后做所有事情以结束冲刺。 我们承认，是的，这很困难，我们可能会在评估中的某个地方犯一个错误，该系统可能会让我们感到惊讶，但是我们只是这样做就可以解决问题。

通过这种安排，应该发生与Scrum中的sprint相同的事情。 一个致力于做某事的人必须要做。 一切都很简单！

总结一下，该协议失败的原因：

• 承诺不是保证。
• 控制很困难。
• 事实表明失败。

很明显，需要做些什么：只需创建易于管理的持久协议，然后最终交给巴哈马即可。

队长证据

换句话说：

• 照原样-系统现在看起来像这样：相当脆弱的安排 ，难以管理。
• 要做到-应该是：坚不可摧的协议，其管理是透明的且不费力。

对于标准的GAP分析情况，“成为”是我们追求的最终目标，而不是我们将要实现的事实。 但是我们必须努力。

有待弄清楚什么是强有力的协议以及如何管理它。

强有力的协议

强有力的协议-这些是具有约束力的人承担的真实义务 。 这很重要。 我们讨论了义务，涉及一些需要转让的包裹，现在我们将讨论有关包裹的承运人。

与可选人员进行的安排会导致不一致。 如果您以协议流的形式想象工作，并以不同的方向分批发送，那么当您尝试与可选人员达成协议时，请做好准备，以备有50％的概率会浪费时间的事实。 因此，首先要提高一个单词的价格。

字价

理想情况下，您的每个同事都应该了解维修义务是他们的主要工作。 这是他工作的精髓。 书面代码，放气发布是已履行义务的衍生产品。 因此，我尝试与人们专门讨论义务，问题不在于代码未编写或没有结果。 这是结果，而且会带来很多痛苦。 但是问题的实质是，在承担了义务之后，我们没有找到履行义务的方法。

, , , . , , , , « — — — » . , , — , , , .

, , . - . , , 10 3. , — .

, .

, — . — , .

, , .

, — : « , ».

— , . , — . , .

— . , .

, , , .

, - — .

« » . , — . , , . , . , - . , , , , :

1. , .
   
2. , .
   

, , . — — , . - . , , , . , . .

, , «» :

• .
• .
• .

— , , , , , .

, . , .

, .

. , , : , , . , , , , . , — , - , . — .

, . — , «» . , — . - , . :

— , !
— .

-: «, , . 10:55. , ».

, , 5 — , , . , : , .

— — , .

?

, : ? 4 , , - :

1. ?
   
2. ?
   
3. , ?
   
4. , ?
   

. , . , .

: «, - , , , !» , , , .

, . . - , , , , .

« » . — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

但是在我看来，是否参加TeamLead Conf的选择是显而易见的。此外，该程序几乎已准备就绪。但是，您可以选择2月的莫斯科或9月的彼得，并订阅新闻通讯，这样您就不会错过任何新的视频和文章，征文启事和关键日期。