Get best of the week

我们设定发展目标（不仅限于血腥企业）

一个小伙子冲进医院：
-医生，紧急cast割我！
-???
-急，医生，没有时间解释！
医生去势。第二天早上，那个家伙从麻醉中走出来，问他到底是怎么回事？
-你知道，我要嫁给一个犹太人，他们有这样的宗教信仰。
-也许您需要包皮环切术？
- 我说了什么？ ！！！
大多数问题是由于误解引起的。您将任务设置为下属或盟友，然后发誓，因为人们做错了事，因为人们误解了您，所以做错了。面对这个？如果您是经理，并且解决问题是您职责的一部分，那么您可能知道不正确的执行是您的错误，而不是执行者的错误。

注释包含一个问题框架，如果您是问题解决者，则应在任务中写出答案。如果您是表演者，那么这些问题的答案将帮助您更好地理解任务。对于大多数问题，已收集了实际和否定的实例。


出现问题的原因通常是根据“需要完成的任务”而不是“需要获得什么样的结果”和“为什么需要此结果”来设置任务。

为了了解可能性，人工成本和截止日期，表演者将问您许多不同的问题（尤其是如果他不在主题范围内）。信件会浪费时间，因此会浪费金钱。如果您详细说明需要完成的工作，则可以加快任务的执行速度。但是究竟需要部署什么呢？并非每个任务管理器都理解这一点。

有不同类型的任务。

本文不考虑解决已知错误的方式和表现形式的缺陷。

在本文中，我们将分析变更任务，包括在项目框架内进行的工作，系统改进，组织和其他非标准任务（诸如``解决问题''之类的任务将不在范围内，将在后续文章中进行讨论），考虑问题陈述的框架并给出示例。该框架由各种方法和框架综合而成。

承包商可以自己执行任务，但可以管理一组艺术家（例如，开发人员）。

任务可能是特定的。

软件开发挑战需要回答许多其他问题。我们将不专注于特定任务，而将考虑与变更过程相关的一般性问题。

为什么要给作者写文章？
, , , .

问题陈述框架


并非需要描述所有要点，不是针对每个任务，也不针对每个执行者。规定中可以确定许多要点

任务内容


  1. 术语和缩写
  2. 该怎么办
  3. 做什么的

    1. 任务级别（根/子任务）
    2. （对于子任务）作为项目的一部分。什么是子任务（您要解决什么任务，在此框架中设置此子任务）
    3. （对于根任务）业务效果
    4. （对于根任务）将以这种方式实现
    5. （对于根任务），将以这种方式衡量业务效果
    6. 相信此任务将使您获得业务效果的原因
    7. 如果任务没有完成，那么（公司将因此而丢失/不予接收，...）
    8. . () / … ( ). -
    9. ( ). .



    1. - (),
    2. ( )
    3. ,
    4. , . , ( ). , . /
    5. , , ( )
    6. ,
    7. … ..



    1. , -. . - …



  1. ,
  2. ( ),
  3. ( -).
  4. /
  5. /

    1. ( )
    2. , / , ,
    3. - - ( )
    4. -, ( )
    5. , -
    6. / ()
    7. /


    1. / / .
    2. / ( )
    3. , , , .
    4. ( )

  7. ( )

  8. (, ) ( ),
  9. ( ) ( )
  10. , ( )

    2. ?
    3. ?
    4. 在这种情况下，对于非关键操作该怎么办？

  11. 如何进行回滚（用于更改）

客户要求（资源，信息，凭证）


承包商在处理任务时将其填满。

背景


一些概念的简要概述
?

SMART , , , .

megaplan.ru/letters/how-to-set-tasks , (, ).

“ ” (https://habr.com/ru/post/475284/) .

TOTE ( habr.com/ru/post/339556) , .

Agile ([5]) — “” “ ”, , ( ).

INVEST SMART, - .

, , , .

, . ( [7])

  • Independent (). , .
  • Negotiable (). , . , .
  • Valuable (, ). . , , .
  • Estimable ( ). “ , ” .
  • Small (). 1-2 , . .
  • Testable ( ). .

agile[6]:

  1. , , . , , , , , .
  2. , . , , - , , .
  3. , , , ( ).

user story, : product owner, , . .

- , , , . , . , user story?

, ( ).

主机说明


任务内容


该怎么办


需要完成的工作=该任务中需要完成的工作清单。如果添加艺术家和截止日期，您将获得解决问题的计划。通常这会终止生产。

经理写道：“去做。” 根据个人经验，这是想设置任务的第一件事。我们记下需要做的事情，稍后，如有必要，我们将回到这一点进行澄清或重写。

“让我cast割。”

也许尚不清楚要完成的工作的完整列表，然后仅指出解决方案的第一步。但是在这种情况下，为了避免造成误解，值得将附言“确定并采取此类后续措施”。

该描述应基于常用术语和缩写。否则，值得创建“术语和概念”小节。

做什么的


首先，需要“为什么”这一点来向表演者解释您的目标设定，以便在开始任务时，他可以分析“该做什么”中的工作清单，并检查它们的充分性和完整性，从而可以更好地理解您想要实现的目标。

任务“让我去势，因为我要嫁给一个犹太人，而且他们有这种习俗”，一位称职的医生将提出措辞是否适当的问题，并防止灾难。

其次，描述应使您理解此特定任务的优先级。
想象一下自己扮演一个“完成许多任务”的艺术家的角色。他应该先执行什么任务，如何确定任务的优先级？如果您是其领导者，则可以直接指定优先级，但是如果不是，该怎么办？

承包商有权决定首先要做什么，以后要做什么。在这种情况下，他应对这种选择的正确性负责。

在一个血腥企业的框架中，碰巧的是，优先级是根据“运营状况”或当前需要什么而大声喊叫的。它也可以简化为“我是你，你是我的”或“让我们成为那个朋友”，但是面对总导演，最好使用其他优先级排序方法。

定义运行队列的选项
. .

, , , (, , , , ).

. -.

, , , , , , (. [3]), - ( , , ).

.

— . .

任务级别（根/子任务）

任务是具有SMART目标和需要完成的工作的特定事件。

一个目标不明确的任务的示例：第一季度增加销售额（增加1卢布=解决了问题？）。

根本任务旨在直接获得最终效果（以另一种方式-第一级任务）。影响可能会或可能不会在业务指标中表达。

根任务示例

  • “”.
  • ( - ).
  • .
  • .
  • .
  • .


如果任务的结果直接影响业务指标，则需要指定任务级别“根任务”。

通常，解决根本问题需要其他员工的帮助。在这种情况下，为了解决该问题，形成了子任务的层次结构。
如果需要任务结果来解决某些根本问题，则需要指定“子任务”级别。

任务/项目以及为什么需要此任务（对于子任务）

如果在要解决的第一级问题的框架内设置子任务，则需要指出要解决的任务。

如果任务是在项目框架内执行的，并且项目具有跨领域的优先级，则指定项目可以使工作中心以正确的顺序完成任务。

如果您是执行者，并且使用公式框架来查找任务的参数，则可以问您：“我们为什么需要此任务，您将如何使用结果？我需要知道这一点，以便更好地了解如何完成任务。”

收到答案后，5Why的技术人员建议更深入地设定目标：“以及为什么需要此目标”等5次。

想象一下在体育用品商店的对话
: ” ”
: “ ?” (1 why)
: “ ”
: “ ?” (2 why)
: “ ”
: “ ?” (3 why)
: “ ”
: “ ?” (4 why)
: “ , , ”

实际上，在第二个原因之后，任务管理器开始变得非常紧张。

可以问的问题是：“我了解您为什么需要它（您可以重复您的理解为什么）。选择我们下一步要做的事情：继续讨论此任务的细节，或者我可以帮助您找到解决该任务的更简单的选择。”

体育用品店，双人间2
1
: ” ”
: “ ?” (1 why)
: “ ”
: “ , , . ”
: “ ”
: “, : , ?”
….

2

: ” ”
: “ ?” (1 why)
: “ ”
: “ , , . ”
: “ ”
: “ , : , ?” (2 why)
: “ , ”
: “ . ( ). , . , , .”
: “ ”

让我a割，我嫁给一个犹太人。

业务效果（对于根任务）

该任务有什么业务影响，我们将对其进行衡量以及如何衡量。

业务指标示例
-

  • :
  • ( - ):
  • :

-
  • :
  • :
  • :
  • : HR


如果难以评估任务对业务指标的影响（例如，这是操作员界面可用性的改进，不会导致更快的订单处理），那么有必要指出任务对消费者而言为何重要的原因。

分解问题的解决方案，或者您打算如何使用任务结果

需要与执行者讨论困难的任务（例如，应用程序集成任务），以将您的任务（任务）分解为执行者的任务。

但是碰巧的是，给表演者一个任务却没有解释您打算如何使用他的工作结果来解决问题。

通常，这会导致问题：任务的结果无法在将来使用，这会导致时间的浪费或必须重新做的“拐杖”。

例
— .
— . ?
— .
— , .
— , .
— . . ?
— .
— + , , — . ?
— .


为什么要为客户（消费者）使用

谁是任务的使用者？为什么对消费者来说呢？
为什么割礼的丈夫对开玩笑的新娘来说很重要？

如果任务与客户有关，那么您应该明确指出为什么要针对客户。

碰巧系统更改会恶化客户端与您进行交互的体验。这是由于某些经理希望进行局部优化，尤其是如果这些领导者不直接与客户互动的话。
示例1.来自物流师的任务（销售电子产品）。
“ , ”.

, - - . , .

示例2.来自市场经理的任务。

“ -, , .”

, .

示例3.来自财务主管的任务。

“ , ”.

. , 6, ( ), . .

, .
, ? ?

未来用例

作为主要角色将使用已解决任务的结果。将来的用例是什么？

指出场景中的主要参与者是否是您的客户尤其重要。

例。通过二维码付款
: QR- . - - -.

: QR-.

: QR- , -.

. ? .

1 (20% ). , .

2 (80% ). , (!!!), , , , - .

? , ( - ), ?

, QR-? (, . deeplink). , -?(, ).

如果没有完成

如果任务未完成，请说明将要发生的事情（或不会发生的事情，请参阅“ Decartes Square决策”）。这样做是必要的，以便承包商更好地了解最适合执行的任务。

这个不舒服的问题通常会为“为什么”的问题提供最容易理解的答案。

比较示例：

  • 该公司将不会获得0.1％的利润，即X百万卢布。每月。
  • 一名员工（运营商）平均每天需要花费15分钟来手动输入付款数据，这使公司花费了3,000卢布。每月。
  • 如果未对FZ-54规定的支票的电子财务登记进行改进，将导致公司被罚款，并产生公司两倍的营业额。

如果我不被cast割，我将欺骗我忠实的新娘和她的父亲，也不会得到丰盛的嫁妆。

准备标准（结果）


这是对预期结果的描述。

总体而言，
“ 您需要这样做来充分利用这一点。有必要，因为 …… 这种检查方式。”

必要

您想得到什么样的结果？（与“完成+接受标准”的定义相同）。
您何时会认为任务已100％准备就绪？

规
, , : , .

, , , , , .

至

为了使承包商同意准备标准或为评估工作提供不同的（最佳）选择，承包商必须了解客户为何需要这些标准。

如果不了解为什么这个或那个标准如此重要，表演者很可能会忽略它（或打开意大利罢工模式）。因此，最好基于短语“至”来描述标准。

需要

并非所有标准都同样重要，某些要求是必需的，必须具有，有些是合乎需要的，nice2have（尤其是对于有期限的任务）。您对执行者选择实施方法的限制越多，不履行和减少员工主动性的风险就越大（或者，由于执行者的局限性，执行者可能会更多地拉扯您，迫使您解决问题）。对于强制性标准，值得指出为什么要强制性。

例。寻找1C开发人员
HR-.

: hh.ru 1.

: 01 . , , . .

:

: 01 2 1 Middle+, . 1 .

: — 120 000 .

, 100 . , — 140 . ? ? , . : — 240 . . , .

?

: , , . ? , , , .

? , , ( ) — , . ? ? . – .

: «, , , - »
: “”.

4. . 6 ( 10-00 19-00 ), , - . Must have, .

— acceptance criteria. definition of done ( , , ):

  1. ( ).
  2. ( ).
  3. ( ).
  4. .
  5. ..

( , ? ? — ).

, HR , , , . , , . , , — . , .

, “ ” , :

: ( )

: 01 . , , . .

:

  • 01 2 1 Middle+, . 1 , .
  • — 240 . . , .
  • , , , - .
  • 6 ( 10-00 19-00 ), . Must have, , .


验证方式


值得指出的是，这不是很明显。

组织新年公司聚会的任务。
, ? ? ? ? , , , , .

, – . , , , ( ), : / ?

“, , . — . — 90% 8 ”.

重要的是指出结果准备的标准，而不是解决问题的方法。通常这是最困难的，因为进入超级系统非常罕见。

建议不要用否定的（这样就不会发生），而要用肯定的“ so”表示。在完美的形状。

例。钉在墙上
: .

: , , , .

: , . , .

: .

. . ? ? ? : , . . . .

:

  • — , . , .
  • , . .


应尝试根据最终结果来制定准备标准，而不指明如何获得此结果。

例。使用二维码在现场付款
QR , QR , .

, . .

, .

, . — deeplink, QR .

语境


上下文是对现状的某种描述（按现状）。

如果承包商不了解您当前的流程，那么他通常将不了解您的真正需求。

  • 什么样的生意
  • 有关活动现在如何进行
  • 被审核者如何进行审核活动
  • 在当前情况下有什么坏处

了解实例
, ? , .

不太清楚的上下文示例
Wildberries, OZON, .. , ?

? ? ? ? ? . .

, , , : .

? ? ? ? . .

什么样的业务（对于外部承包商）

将任务设置给外部执行者，值得提供有关您的业务的基本信息。

碰巧写一个“ Pyaterochka的商店”就足够了，并且对于执行者来说，任务的意义将变得很清楚（如果问题中考虑的过程发生的区域接近执行者的经验）。

如果不是，则应指定业务画布（画布）[请参见 8]：

  1. 业务类型
  2. 您的产品是什么（产品），产品的类型是什么（贷款，CTP，保险...）
  3. 业务的专业化是什么，亮点（UTP）是什么，价值是什么（我们在短时间内交付优质产品）
  4. 谁是您的消费者（零售客户，分销商，商店等）
  5. ( , -, , , ...)
  6. (, , , , ..)
  7. ( , , ...)
  8. (, , ...) ()

, CRM
: CRM.

: .

, ? .

? :

1.

— :
— :
— : , (30%), (10%), email/ (30%), (30%)
— :
— : , -,
— :
— : ,

2

— :
— :
— :
— :
— : ,
— : ,
— : ,

1 “B2B” CRM , , , , , , .

2 “” CRM , , email, sms, web-push, , .

,

照原样的状态指示表演者实际上需要做什么，要克服什么样的“差距”。根据当前状态，操作可能会发生很大变化。

粗略地说：对于一家营业额为90万卢布或营业额为10万卢布的公司，实现营业额100万卢布的任务是完全不同的任务。

现在，谁在解决问题的指示将立即指示关键任务执行者谁拥有有关该任务的最多信息。

如果某个问题的类似物已经在附近的单位或参考公司中得到解决，这也值得一提。

例。计算交货时间
:
: -.

:
1. ERP .

2. , . , . .

.

, ( , ). . - . 10-50 .

活动规定什么以及活动随附的文件

例如。在自动执行订单处理时，通常会在招聘时发布的经理指示中找到必要的信息。

是什么阻碍了目标的实现

为什么现有方法在考虑必要的质量参数的情况下无法实现相同的目标。

例。计算交货时间
: .
: -.

:

.
ERP .

1. : , .

: .

2. , , , .
: .
2-3 , .

以前完成任务...，请参见此处

该任务已经完成了哪些工作，有可能看到正式的结果。

任务名称


创建“为什么”和“准备条件”块之后，您还可以编写任务名称。它应该简短，宽敞且标准。

任务的组织部分


在条件（权利和限制）下


必须采用或指出基本范式（两个之一）：
“允许所有不被禁止的东西”或“禁止所有不被允许的东西”。
规章制度
. .
— “, ”.

?

—
—
—
— /.

:

— ,
— ,
—
—
— “”,

, :

  • , , , . , .
  • , , , ( ).
  • .
  • — .
  • , , — 15 /. , . , — ( — ).
  • , , /, , . , , . /, ( — ).
  • 15 , , /.
  • / , , .
  • ..


有多紧急？


如果任务的紧急性很高，请说明这一点并解释为什么任务如此紧急。例如，如果组织“黑色星期五”需要执行此任务，请指出该内容以及黑色星期五的到来时间。

有特殊的截止日期，在此之后客观上就不需要任务。例如，会议上的演讲持续时间。例如，如果您需要广告公司的目标网页，则截止日期是付费广告的时间不能转移。

对于诸如软件开发之类的任务，为什么仅在实际时间中指定截止日期以及此类任务的管理方式有何不同是很重要的
— . , . = 90% .

.

deadline = , , . , , .

deadline, . , . , .

“ ”:

  • , — 2-3
  • “ ” =
  • (scope), must have nice2have (. “ ”)

, “ ”. , — must have nice2have. Must have . , . : must have , , , - nice2have.

特别重要的任务


如果承包商将任务的执行交付给输送机，则可能有必要比平常更快地推进一些任务。

使用标签“特殊控制”突出显示这些任务，这将使承包商以不同的方式组织任务管理，任务管理器将单独监视这些任务。对于每个此类任务，请与承包商联系并说明其重要性，以便承包商将其推迟。但是请记住-这样的任务不应该太多。

为什么需要这样做，延迟执行常见任务的原因是什么？
: , , , . . .

, . , , .
, , .

:

  • ,
  • ,
  • ,
  • ,
  • “ ” — , .

, , . , , .

资金限额


对于有支出限制的任务，请指定此限制。如果费用超出了限制（购买材料比出售成品要贵得多），限制可能意味着不必要的任务，还有其他原因。

限制的存在会影响范围或时间。

例如：

  • 您需要购买一份生日礼物以支付所收款项。
  • 您可以在两个项目之间完成对自己站点的改进（免费，因为已经支付了工资）。
  • 如果没有承包商至少愿意这样做，则可以推迟企业门户的实施。
  • 备用笔记本电脑可以以您可以等待一段时间的最低价格购买。
  • , ( , KPI ).

/ ( )


如果承包商可能需要吸引更多的员工来解决问题，而他们却超负荷工作，这可能会成为问题。

在这种情况下，您应该指出“自己决定”或“不要分散这样的员工”。

相反的情况：必须出色地解决一些任务，为此您需要吸引专家。然后，我们指出“吸引某某员工”。

例如，“为此类站点在Internet上撰写文章，从此类专家那里获取有关此类案例的信息。”

如果公司被禁止吸引外部专家，但是完成此任务需要这样做，那么值得一提。

例如，“找到具有Hybris经验的资深Java开发人员来招聘招聘公司。”

协调执行方法


选择以下三个之一：

  1. 在实施之前就计划达成一致。
  2. 完成后告诉。
  3. 没兴趣。

它为什么如此重要？如果您不信任执行者，并且需要在第一时间完成任务，那么您应该尝试在工作开始之前弄清楚如何解决它。这将需要时间，但是结果您将获得可接受的工作质量。

什么时候需要协调执行方法？如果失败的风险如此之大，以至于遭受严重损失（例如，您被解雇或对领导失去信心）的威胁。还值得考虑为首次分配给您的员工的一些复杂任务指定此项目。
（在[4]中，该项目称为保险）。

“ ”
, , .

. .
? !

“ ”.
“ . , - ”.

“ ”?
“ . , ”.

“ . ? ”.


“ ”


— “ ”.
— ( “ ”). , , - .
— ?
— -.
— % , . . ? , .



— “ ”. .
— ( ). , . , ( ..) ….
— ?
— , .
— , , , , . . .
. ?
— , , .
— ?
— , .
— , “ ” , . — .

( )


执行任何长任务的过程都需要控制。

如果把任务摆在表演者身上，那么通常首先需要控制胜任能力以完成任务（见[10]）。

如果可以通过可用的报告来监视任务的执行情况，那就很好，在日历中做笔记并检查（或要求报告部门的负责人此时准备一份带有分析性注释的报告）。但大多数情况下，没有现成的报告。

控制工作的方法取决于组织承包商工作的方法，应在规章中加以规定。

最简单的方法是定义至少一个下一个控制点（为最高优先级的一项任务工作）。

简要介绍控制人员和团队的不同选项中的控制
, , . , - , .

? “ ” [5] [9]. ( 100% , , . — ).

, . .

— .

:

  • ( ) kanban = . , - ( , , …), .
  • Kanban = . , “ ” . , , , ( , , ). () ( ) ( ). , .
  • (scrum, scrum ....) = . + ( ).

— - , :

  • . , . – (-).

, — , .

, , - , , . , : , , .

顺便说一句，为什么我们需要控制？

一个关于血腥企业没有必要的故事。
- . «», . « ?», . , , , . , . , - , .

应该组织监督来帮助解决员工无法解决的问题。

控制点是时间，地点和控制方法。

一个地方就是沟通的方式。

  • 去办公室展示
  • 致电并举报
  • 聊天和举报

管制地点的规管
, . , ( / / ), .

控制方法-确定需要控制的内容。如果重点是计划的实施，则通常是计划中项目的实施。但是，如果任务很紧急，则可以在指定的时间控制任务中间结果的组成，以便您了解任务的运行方向。这是更长的时间，但这是第一次。

例。促销活动启动。
. ( ).

– . , . , .

: , ( , , ).

如何确定下一点？取决于选择的实施计划和管理方法的协调方式。

对于特别重要的任务，请单独进行管理：

  • 如果您在实施前就实施计划达成了一致，则在承包商提出此计划和实施方法的那一刻，您可以确定控制点。
  • 如果您不打算检查执行方法，则让承包商自己指示下一个控件的时间和位置，并指出这一点。

对于其他任务-由法规确定。

谁检查质量


通常，公司标准化的第一件事就是质量控制。

例如。测试人员（有时是开发经理）会检查生成的代码的质量。律师检查该协议的法律纯正性和对所达成协议的符合性。订立合同时，您要求承包商与律师核实合同，并在下一个控制点查看律师的意见。

您不会自己控制质量，而是在另一位员工的帮助下。典型的控制中心应记录在规定中。

法规示例。
  • ,
  • ,
  • – .


但是，如果这些过程还没有完全建立，或者任务不是很典型，那么就值得指出谁将控制什么。

一个非典型问题的例子。
, .

如果出了错怎么办


例。购买相同的礼物为新年，金额-2000卢布。每个孩子。如果2050卢布-我们要买吗？

值得考虑并指出：

  • 您可以超支多少
  • 你能延迟多少
  • 可以做到的最低限度（这是将就绪性标准分解为必须具有的原因，nice2have）。

如果您不能超支，请确保按时高质量地完成所有工作，那么通常一个或多或少困难的任务注定会失败。为什么？认知偏差“计划错误”促使您和表演者思考完成任务的乐观成功方案，而不考虑可能出现的问题。但是问题确实发生了。如果您事先考虑它们，首先，您可以更加清醒地评估时间安排和所需的资源。

其次，这将使得在出现这些问题时可以更快地做出响应。为什么会这样。

例如。如果您未指定允许的偏差，则默认情况下，当某些情况超出指定的限制时，承包商将针对每种情况运行。每个这样的情况都会导致延迟，至少是由于通信（您不闲着）所致，这会破坏截止日期。

可能出什么问题以及如何对此做出反应（以及是否做出反应）？大多数风险是标准风险，应在法规中进行描述。

规章制度
  • ( ) . ? ? ? ? ? ? ?
  • , . ? ? ? ?
  • . . , , ? , ( , , ).
  • . ? , .. - ,


为什么作者未命名此项目存在风险
, — . , . , . .

解决方案创建组（解决方案计划）


在解决某些问题的解决方案时，应考虑到某人的利益。如果是这样，请指明负责人（所谓的利益相关者）列表。如果尚不为人所知，请指出他们中最专业的人。

对于许多任务，承包商可以根据工作流程独立确定这些人员。

但是有时这些人没有被明确识别。为了避免有人忘了问别人的意见，您需要指定一个列表。

利益相关者不明显的任务示例
  • ,
  • ,
  • ,
  • , , .


部署愿望


某些更改无法随时输入。如果没有规定，则必须指出这些限制。

例如，当站点的用户最少时，必须对站点代码进行更改，以最大程度地减少订单损失。

谁以及如何通知该决定


如果未定义法规，则值得指出何时得出结果。

尽管问题的解决方案与他们有关，但人们并不了解。如果发生这种情况，则值得明确指定。

例如，有关使用Jira任务的法规的更改涉及所有通过Jira组织其工作的部门的员工。同时，员工必须签署对此法规的更改。

执行者


承包商是承担任务的雇员。在陈述问题期间可能不知道，稍后进行定义，例如，如果同一组中的几个人执行此类任务。

任务验收组织者


完成的任务将由设置任务的员工（员工）接受。接受者得到了他想要的东西？

但是，这项任务的责任在谁一边？承包商完成了工作（移交了球？），任务管理器接过任务进行了验证（他真的接受了吗？）。

如果通过任务跟踪器（即当前负责人字段）设置了任务，则该任务确定球在哪一侧。

但是，如果不是这样，则会发生任务冻结很长时间的情况，尤其是在没有规则和规章的情况下（即使有任务跟踪器也很有用）。

接受任务的规定。
— ( ), , ( “” , “”).

— ( ), , (, ), . (“” , ).

: , () .

, — ( ).

, .

允许回收


如果雇主要求（根据法律），处理中的雇员必须获得报酬。同时，员工可以按自己的意愿继续工作，但是是否支付此类处理费用取决于组织。

需要管理处理过程=分配需要按时完成的任务，包括通过处理在工作时间内完成的普通任务。

客户要求


承包商可以指示客户需要他什么才能成功完成任务。

简而言之，它要求：

  • 信息
  • 资源资源
  • 证书。

例如。要启动在线商店的网站，客户必须准备为IT公司在带有价格的产品卡上创建站点信息。

我们不会详细介绍此部分。

暂存过程说明


经理如何分配承包商？

经理通过在脑海中构建解决方案模型，将任务分解为子任务或定义下一个子任务来解决摆在他面前的任务或问题。之后，他将任务交给表演者，收集结果，再次设置任务，依此类推，直到他解决了自己负责的问题/任务。执行任务的结果要么直接影响业务指标，要么有人需要改进业务指标，或者他认为需要执行任务，但是他没有问自己为什么。

假设经理是您。

任务中最重要的是对任务进行定性描述。

  1. , . ( ). , . ( – ).
  2. . , . . . . ( – ).
  3. . , . , , ? – . , – , . ( ).
  4. « ». /.
  5. .

并非任务描述中的所有项目都是必需的。义务取决于任务本身和执行者的水平（经验不足的人需要编写更详细的语句）。最重要的是“为什么”和“准备标准”。但首先，请查看每个任务的项目列表。

描述什么取决于艺术家的水平。

如果表演者是6月/初学者，那么很可能他不知道如何以及如何做才能达到目的。对于这类人，“做什么”块更为重要。

如果承包商有足够的经验并且可以将任务委派给他，那么他只要写出“验收标准”（作为结果的图像）就足够了，他将想出办法。

对于两者而言，“为什么”框都很重要，它提供了目标设定和动机。

承包商收到任务后，会指示客户需要他完成什么任务，并且客户与承包商之间存在讨价还价的关系。

例子


以下是一些示例。有些示例是完全难看的，但它们都是基于一段时间前发生在不同公司中的，具有不同任务和执行者的真实事件。

我们将指定Z-分配者，And-表演者。

例。填写结算规模数据


怎么办：将所有YZOOM参数值（用于定居点= 11）填充到战斗服务器中。对于莫斯科和圣彼得堡，设置9.

为什么：对于用户来说，要有一张以正常比例显示商店中商品可用性的地图。
在项目的框架内实施商店的自助送货
如果任务未完成，客户会以最小的近似度（整个世界）看到地图，这使他很难用一根手指在电话上导航，并导致转化率降低
接受标准：默认情况下，在城市中打开网站，在“ “仅在一家商店有售的一种产品在商店中有售”，此卡即会打开，因此可以看到市中心。
任务日期：补全X编号，因为此时将启用战斗站点上的所有自动发送功能

示例1.将错误从Google.Docs程序转移到Jira


Z：有一个Google Docs表，测试人员在其中修复了修复网站上缺陷的任务。将这些任务从Google文档转移到Jira（新任务管理系统）。
并且：感动。接下来如何处理他们？测试人员说它们不相关。
Z：那么就不需要转移了
。And：您说要转移，我已经转移了。
Z：我不得不思考“我为什么要这么做”。如果您不知道自己为什么要做某事，那就不要。

道德。在此任务中，您可以猜测准备条件：该表中的所有任务在新任务管理系统中都被列为任务。做什么的？没有指示该项目，这导致能量和时间的损失。

如何正确设置任务

怎么办：有一个Google文档表，测试人员可以在其中修复任务以修复网站上的缺陷。将这些任务从Google文档转移到Jira（新任务管理系统）。

原因： Jira应该承担所有紧急任务，以修复较早发现的缺陷。

验收标准：

  • Jira已按照新的缺陷编写规则启动了缺陷纠正任务，以便可以正确地优先纠正缺陷。
  • Jira没有重复的缺陷，以免造成修复缺陷的冲突..
  • 新任务应该是相关的，以便开发人员不会浪费时间。

例子3.开发者到开发者


Z：执行任务该

怎么做：分析并重构一段代码。

原因：根据监视结果，发现了一段有问题的代码。这大大减慢了站点的加载速度，使其变得不稳定。

准备条件：在一段代码中，应该对数据库进行一次查询，并对其结果进行缓存。

并且：我不知道该怎么办。您可以用不同的方式修复这段代码，选择哪一种？
Z：请三思
而后行，然后我升上了U领队，我们进行
了讨论。
并且：可以通过不同的方法来解决该问题，例如方法1，方法2，方法3（下面介绍编程语言中的方法）。
Z：我们需要尽快解决此问题，以便及时赶上黑色星期五。
问：那么，这就是方法
1。Z：这种方法对业务有什么影响？
并且：当价格发生变化时，网站上的价格数据将不会在一小时内更新。
Z：由于价格在晚上变动，因此在最少的客户活动期间，这种方法是可以接受的。

出了什么问题：发现了问题，但没有指出如何处理，如何解决，让表演者可以自己选择执行任务的方式。同时，目标标记不充分-为了赶上黑色星期五（PE），表演者无法选择，因此必须尽快完成。
同样，“赶上紧急情况”任务的解决方案不是问题的类型，也不是错误的代价（整个公司的成功），它太高了。因此，必须在接受标准上增加一个步骤：“在实施之前就决策计划达成一致。”

黑色星期五在两周后到来。该任务必须受到特别控制，因为没有延迟的权利。我们添加“特殊控制”。

优化主要是一项研究任务，工作量不清楚。研究需要时间限制，因此我们添加了“明天9:20与您联系并检查解决方案的状态”。

例子4.开发者到开发者


Z.改进这段代码。这是分析器
I 的诊断。已改进。
Z.应该有0 个请求，而不是32个请求，而Z.应该有0个请求，数据必须完全从

Morale 缓存中获取。没有指出为什么需要执行此任务，但是在上下文中，由于整个团队的主要任务是加快站点速度，但这不是必需的。但是没有指出准备标准。

我们重写该

怎么办：从事件探查器中改进这段诊断代码
原因：加快站点
接受标准：如果缓存中有数据，所有请求都应在缓存上工作

例子5.开发者负责人-开发者


Z.了解这段代码
I.的工作方式。
Z.一个小时过去了，结果在哪里？
I.我解决了另一个问题，

这是什么问题：在没有指出任务的重要性的情况下，表演者无法理解哪个任务更重要。
有一个著名的管理三角：资源-范围-时间。

资源。承包商（如果这不是一个可以吸引自己以外的人来做事的经理）只能依靠自己，这就是资源。

选择仍然是-范围或时间。

研究任务（例如，了解正在发生的事情）通常很难通过人工成本进行评估，而优化研究可能需要数周的时间（包括研究和测试新的图书馆和技术），因此研究任务需要在时间的帮助下进行管理。

因此，此任务很重要。经过一个小时的控制后，将所有内容扔掉并做。

我们重新提出问题：

该做什么。了解一段代码是如何工作的。
为什么。根据分析器，此片段将页面加载速度降低了7秒，这阻止了网站进入战役
接受标准。讲出这段代码的逻辑并给出解决方法的意见
优先级（老板可以确定优先级）-删除所有其他任务，因为这是唯一阻止站点启动的任务，即
控制任务-您将在一个小时内调用并报告所学内容。

示例6.在网站上连接再营销服务


产品负责人设置任务。
怎么做：连接网站的再营销服务。
原因：建议将通过在互联网上投放广告来增加销售。
准备条件：在战斗站点的所有页面上，都有一个计数器，该计数器会在所有客户端打开页面（没有广告拦截器）时创建事件。
客户：直接互联网营销专家。

这次您忘记了什么？由于该任务看起来很简单，因此，新手，经验不足的开发人员将其投入工作，并将此脚本插入到同步执行中，然后在客户端的浏览器中打开网站页面。结果，该网站的页面开始加载速度慢了1.5秒，并且当计数器脚本开始生成错误时，这些页面完全停止打开。电子商务总监很生气。

产品所有者与其他任何业务客户一样，都没有考虑过速度和容错能力（如果业务部门考虑过，那么它作为一家企业将无法正常工作）。要求中未明确列出这些标准，也没有针对该站点的书面要求，甚至没有人用言语指示开发人员。

如何摆脱这种情况：对非功能性需求进行形式化，并在形式化过程进行中，与开发人员和测试人员进行问题讨论，在其中开发人员告诉他他将如何执行任务，测试人员不会忘记询问所提出的实现方法将如何影响质量属性（性能，速度，容错性，安全性等）。

例子7.纠正促销代码机制中的错误


任务：“现在网站上有错误，订阅促销代码的折扣与特惠信息的折扣相加，请纠正。”

描述了问题，但未描述需要做什么。

从客户那里了解任务的含义后，将其重写如下：

措施：

-提出一种机制，用于确定在一个购物篮中存在多个不同促销的情况下，网站应如何应用促销。
-考虑汇总折扣的可能性以及优先级更高的折扣的可能性。
-进行A / B测试，证明公司利润更高-总结折扣（营业额更高，但利润率更低）或留下一个折扣。

做什么的

上一次活动于9月1日至10月10日进行，有1100份订单，​​其中应用了订购促销代码，并购买了有特殊优惠的商品，但不应这样做，这导致可以防止的X百万卢布的损失。同时，不会出现营业额损失，因为折扣对特价商品的意义已经足够，因此客户不需要其他动机（这是一个假设）。

如果不这样做，那么计划在2月和6月进行的下列公司（致力于增加订户数量）将蒙受XX卢布的损失。

接受标准在

没有程序员参与的情况下，控制促销代码和促销如何相互作用的能力。

A / B机制，用于测试交互选项。

做出这样的声明后，承包商显然不需要解决该问题，因为计划在四月份将促销的计算功能转移到集中式软件解决方案中，这将使该问题的解决方案贬值。

往返任务的示例。将仓库空间优化15％


我们给出一个完整描述的例子（有些地方多余）。

语境


业务画布（超出生产范围，供读者使用）


-B2B分销商，
-出售家具配件（铰链，缩放仪，抽屉和架子，存储系统（拆卸））
-来自德国的低价优质品牌
- 多达-批发客户（本地分销商，家具店，个体经营的工匠），
-通过在现场并通过与经理直接联系的订单
-通过销售或分期付款（B2B）付款
-根据交易金额和与客户的合同条件享有折扣；
-通过从工厂购买，由外部运输公司运输和进口，由外力进行清关，在您的莫斯科仓库中存储，通过您自己的运输在莫斯科运输以及通过注册运输到莫斯科。

情况说明


现在如何工作：这里有一个仓库，不同的货物存放在不同的架子上。仓库不包括ABC。
操作量和操作频率：每天10次发货，一次是从脚跟到瞪羚。
对于参考对象的工作方式：他们的仓库针对不同类型的商品周转进行了优化。
活动规定了什么：（附有仓库员工的规定）。
现在阻碍实现目标的是：关于货物周转的工作还没有进行。所有货物均等地存放。
关于已完成的任务：与房东进行了谈判，达成了降低成本的协议。进行了ABS分析，发现有30％的低周转商品。
在哪里可以看到形式化的结果：谈判协议就是应用程序中的对话。ABS分析逐条应用于任务。

该怎么办


通过密封段C的存储，释放空间并准备将其转移给承租人。

做什么的


- 任务的子任务是 “通过ABC分析来通过优化仓库来降低成本”。
- 由于减少了仓库的租赁面积，每月将产生100,000卢布的业务收益。
- 计算的依据：ABC分析表明存在30％的低周转商品。由于存储压缩，让我们将这些商品占用的面积减少一半。
- 需要结果才能将释放的空间转移给出租人。
- 如果任务未完成，则公司将每月支付100,000卢布，这使公司盈利能力不足
- 未来的工作场景：仓库工人更密集地存放周转最少的货物。

准备标准


-从我们这边转移的区域已腾空，准备转移给出租人。
-收到了已签署的转让契据和与租户的已签署多普尼克，以便合法记录新条件。
-仓库租金减少了15％，因此我们可以少付些钱。减少的百分比是近似计算的，因此假设段C的货物进行了两次压实。当减少5％时，该工作就没有意义了。
-已制定重组计划并考虑了专家Semyon Semenovich的建议，以便在保持仓库生产率的前提下检查该区域的最大释放量。

任务的组织部分


客户：公司所有者。
在限制条件下：
- 货币限制：重组成本不应超过六个月租金下降的利润。
- 时间限制：重组期为2个月，因为这段时间应该足够（与出租人商定这些时期）。
- 景点分机。预算范围内的资源是可以接受的。
计划的协调
- 在实施之前，与所有者协调重组计划。
- 计划创建小组（应与谁达成协议通知谁）：仓库经理，销售主管，财务总监。
- 组联系人（已提交）。
- 交流：通过最新动态进行分组。
- 更改批准状态：所有人都同意。

部署愿望：在工作时间内花费，以免支付处理费用。
下一个控制点：在每周一次的下一次会议上。
- 下一个控制点应准备什么：将C组货物根据大小和易碎性分为几类，计算压实的可能性。
质量检验：消防安全经理，劳动保护经理。
如果这不起作用，将如何进行回滚：我们将所有内容移回原处。为此，计划必须抓住这个机会。

如果出了问题该怎么办


可能出什么问题了
-持续时间。对结果并不重要。我们将做什么：我们将与房东谈判。
-搬运时，货物可能会损坏。对结果并不重要。预防方法：指导人们保养有价值的产品。
-新的存储组织可能会阻止仓库的运营。为了避免这种情况，至关重要的是，为了防止这种情况，必须与业主找到的仓库经理和存储组织专家达成一致，以达成重组计划。

加法


标准可用性标准


如果公司为不同类型的任务制定了准备标准的标准，则可以跳过某些准备标准。

可用性标准的标准示例，具体取决于任务的类型：

任务类型-任何任务


-执行结果与任务的客户达成一致
-如果承诺了任务的最后期限，则与任务的客户达成了时间上的变化
-如果任务的承诺期限没有兑现，承包商将任务告知客户，并提供以下步骤以尽可能实现这些目标（为什么）提早但不迟于下一个工作日结束

任务类型-软件开发


-修改后的程序代码已部署（安装）在战役服务器上并可供使用
-在战役服务器上已进行了所有必要的设置，以确保过程正常运行
-改进过程不会恶化先前形成的系统（非功能性）要求（在下面有所说明）
-部署前作战服务器上的支持服务器文档已更新
-对已更改的软件更改进行了简短描述，并在指示处显示了支持文档项目
-已更新了第一天分析师和第一天开发人员文档
-与IT架构师达成的集成更改

可以披露有关非功能性要求的项目：

-软件应该方便（运行UX准则），
-客户的工作界面应与产品负责人，设计师，系统分析员协调，
-公司员工（非零售）的工作界面应与员工负责人协调，
- 员工的工作界面应协调公司的零售商店应与负责零售技术开发的人员进行协调，
-IT系统应具有此类性能参数，并且不应超出处理器，内存，I / O以及此类负载下外部请求的数量和数量的限制，此类数据量，数据相关性的此类要求
-IT系统必须能够在此类条件下进行扩展
应该有可能定期将不相关的IT系统数据传输到存档，从中将数据用于报告系统已有一段时间
-IT系统不应违反法律
-IT系统应受到保护，免受此类攻击模型的侵害
-IT系统不应是硬涂层常数。应该以存储在系统信息库或系统设置中的配置文件的形式来确定它们并进行配置
-IT系统的容错性应该是99％（企业喜欢9的语言），尽管以更易于理解的形式更好地描述了此标准以供使用（请参阅下文）。

IT形式易于理解的容错标准：

-如果服务器配置的任何一个元素（服务器，磁盘子系统，网络路由器）发生故障，IT系统应继续提供所需的方案；
-如果外部CRM系统服务发生故障，则系统可能无法注册，查看奖金，计算和花费积分购买后，但应至少支持主要道路-允许在订单中显示以下消息：“很抱歉，暂时无法使用奖金计划，经理将与您联系并说明借记点数和贷记点数

但是，仅仅列出一个清单还不够，需要建立一个控制过程（尽管在现实中，他们通常这样做：他们引入了一个标准，但是他们无法设置过程）例如，为了满足性能参数的要求，您需要创建一个测试台，加载脚本，一个加载工具和测量性能参数。

标准风险应对措施


-如果员工生病了，则他会在离开工作场所的一个小时内提前或在最坏的情况下在一般沟通渠道中发出警告，表明您有上班的感觉，以便团队的其他成员也可以考虑缺勤的时间来组织参加的工作（等待或传递给另一个）。
-如果员工生病并且在一个小时内没有通知，项目经理将在一个小时内向他学习，并告知一般渠道有关疾病的信息，以便团队可以考虑计划的缺勤时间（等待或转移）来组织工作。如果他不回答，则RP会在通用渠道上写“该雇员已失踪，没有联系”，以便团队可以将其工作转移给另一名雇员。
-如果任务挂在被解雇的员工上，则RP应该将其重新分配给另一名员工，或者将其转移到某个工作中心的缓冲区中，或者取消任务，以使任务管理不会丢失并且任务管理系统不会变成垃圾

参考书目


  1. 关于非功能性需求的文章habr.com/en/post/231961
  2. 有关TOTE方法的文章habr.com/en/post/339556
  3. E. Goldratt，目标。持续改进的过程。www.ozon.ru/context/detail/id/141279570
  4. Blanchard，Onken，Burroughs。一分钟经理和猴子www.labirint.ru/books/682838
  5. 埃列泽·尤德科夫斯基。哈利·波特与理性思考的方法。
  6. 巴顿杰夫。用户故事。敏捷软件开发的艺术。此处简要介绍：habr.com/en/post/459872
  7. INVEST habr.com/ru/company/luxoft/blog/84030
  8. -. | , . : smartarchitects.ru/business-model-canvas, — : , . -. |
  9. « . »
  10. . , . .
  11. . . ? medium.com/it-analyst/client-quiestions-30cf76275ad3


非常感谢KiFB俱乐部的成员，特别感谢Ivan Kopylov的周到和有用的反馈，以及Ulyana Leonova，Danila Golubtsova，Maxim Sinksas，Kseniia Meshkova，Denis Beskov，Serg，Mikhail Sorokin，Step_By_Step，Sergey Titkov和我的妻子Natal文章的准备以及出色的校对Olga Levina（如果您发现错误，那么由于对最终文本的更正，这些都是我的错误）。

特别要感谢安德烈·普鲁多夫斯基（Andrei Prudovsky），他不断挑剔，使我考虑了在设定任务之前要根据结果和任务进行思考的必要，多年之后，我才写了这篇文章。

More articles:


All Articles