在用于实施企业系统的多个项目中，我遇到了计划和控制难以预测的任务的任务。 想象有必要执行许多类似的任务，并且其中涉及大量人员，而您不确定确切的执行顺序以及执行的时间。
在这种情况下，项目管理中熟悉的甘特图工作不佳。 一个典型的例子是CIS扩展的开发。
下面我将告诉您我们在项目上使用了哪种方法，以便以最小的管理成本控制大量并行任务。
1.工作计划
大约五年前，我写
了一篇文章 -对项目经理的进度建议。 这些原则已经经过时间的考验，但我仍然坚持。
但是，对于某些类型的任务，实际上不可能制定出一致的详细时间表。 在许多任务并行完成的情况下，每个任务的持续时间和复杂性只能以较大的误差来估计。
一个典型的例子就是发展。 每个开发至少要经历几个阶段-设计，编码，测试。 通常，当任务移至上一个阶段时，必须进行多次迭代。 开发从编码转向测试，开发人员承担了另一项任务。 开发已返回编码，开发人员要么完成前一个任务，要么立即进行错误纠正。 根据情况和优先级，在任务池中团队工作的顺序可能不同。 该过程看起来混乱且不可控。 以整洁的甘特图的形式呈现此图（项目经理习惯于此，习惯于控制所有事情）非常费力，并且即使有可能也不是很有用。
如何成为 如何控制工作进度？ 如何理解-是否及时； 瓶颈在哪里； 有足够的资源吗？ 谁运作良好，谁运作不好？ 最终如何向管理层报告？
以下是对我来说似乎最佳的选择之一，在某些情况下是唯一的选择。
2.使用工作管理系统
值得一提的是，如果没有使用允许每个参与者接收任务，将任务转移给其他参与者并标记任务完成的任务管理系统，就不可能建立正常的流程。
在我的实践中，我使用了不同的工具并发表了有关该主题的评论文章（请参阅有关Habr：
Project manager tools的文章）。 在这里，我将更详细地描述使用JIRA的经验，该经验是我们为开发管理而设置的，它使用标准功能，而很少使用其他插件。
JIRA是Atlassian的任务（请求）管理系统。 许可证的费用视用户数量而定，每10个用户10美元起。 您可以自行安装或在云中使用该应用程序。 所有选项的价格都可以在
这里找到。
JIRA的特点是界面有点过时（这是一个非常受人尊敬的系统，已经通过了很长的发展道路），可靠性，一个灵活的系统来配置所有可能的功能（工作流程，屏幕类型，访问，通知系统），大量的付费和免费插件，以及深度发展的可能性。
我们不需要修订，我们可以建立并不断改进工作流程（工作流程是任务状态以及任务之间的过渡的状态和顺序），还可以使用参与者和仪表板来控制工作。
我并没有设定以某种方式详细描述使用该应用程序的功能和可能性的任务，但是对于进一步的介绍，阐明一些要点很重要。
3.任务管理工作流程
在我们的示例中，工作流反映了任务的生命周期-设计，编码测试。 实际上，该过程要复杂得多。 根据项目组织的特征，参与者的招募，控制要求，阶段数可以有很大的不同。
例如，一个项目具有以下用于跟踪开发任务的工作流。
协调，工作分配，在系统的所有实例上进行测试的许多阶段……但是，这使确认系统中的每个步骤，跟踪责任并确切地知道任务的执行者和阶段是可能的。
4.任务的复杂性
任务的复杂性分为两个部分：设计和构造。 设计是分析师准备文件和测试开发的工作。 在将技术传递给分析师之前，建筑是开发人员进行技术设计，编码和自己的测试的工作。
事先评估任务的复杂性而不深入细节是非常困难的，尤其是在有数千个任务的情况下，就像我们的情况一样。 但是有必要进行评估，以了解工作总量，所需的资源量并确定时间安排。
对于近似评估，使用计算器，根据任务的类型和复杂性，将其归因于计划的复杂性。
任务的复杂性取决于对象及其工作量。 例如，要在Oracle eBS中开发表单，复杂度标准描述如下：
- 非常简单-8列或更少列的单个块形式。 它不需要特殊的功能逻辑。
- 简单-具有20或更少列的单块和多块（2-3个块）形式。 需要简单的功能逻辑（简单的编辑，交叉编辑（交叉编辑），简单的计算，总计和小计）。
- 等
任务的类型反映了任务的内容，技术，应用程序或其一部分的细节。
例如：
-新的或可变的形式。
-新的或修订的报告。
-新的或可变的数据库程序。
-SQL *加载程序脚本。
-信号（警报）。
-个性化。
-等
根据开发的复杂性和类型，计算器可以计算计划的复杂性。
并且尽管估计误差可能很大，但从统计学上讲，从统计学上来说，这些误差是相当平均的，并且可以将人工量的一般思想用于项目计划目的。
5.监视任务绩效
那么，有了任务的状态及其复杂性，我们如何评估工作进度？
传统的选择是计划在一定时期内需要执行多少任务，并定期跟踪任务的完成情况。 问题在于某些任务需要很长时间，并且需要花费多个计划周期。 在某些时期，许多任务完成了，而在另一些时期，则完成得很少。 这不能提供对情况的理解，尤其是在项目开始和结束时。
您可以尝试计划任务的各个阶段的完成。 在上面的示例中，我们使用了21个阶段，每个阶段都无法计划。 我们选择主要选项-完成设计，完成编码，完成整个任务。 我们为每个任务计划一个日期，我们将控制偏差。 看来可行。 但是，在同时处理大量任务时，很难看到几百个偏差并得出正确的结论。 对于每个偏差，都有一个解释，一个客观原因。 有些事情会迟到，有些事情会更快。
在其中一个项目中，我们尝试使用日期控制方法。 计划的日期由表演者确定。 从相应状态转换后，事实便自动记录在系统中。
该图显示了功能设计（FD）准备就绪日期之前的偏差直方图。 正值表示前进，负值表示图表中的滞后。 可以看出，执行人交出的PD数量最多，滞后时间为3.8至1.7天。 在这种情况下，极端值是从计划的迟到43天到提前67天。
在这种情况下，我们看到在大多数情况下，表演者违反了他们设定的截止日期。 这个系统错误值得深思。 但是，只要团队有积极性，每个人都真诚地工作，这仅意味着人们无法实时显示情况，表演者无需考虑大多数情况下工作中出现的复杂因素。
在计划上花费了额外的时间，但实际上没有人负责完成截止日期。 如果您采取违反制裁措施，那么制裁日期将被设置得很大，并且执行情况将变得更加糟糕。
如果您想控制某件事，请考虑如何使用控制结果，您可以根据收集到的数据做出哪些决策？
6.收入法
试图集中进行详细级别的管理，因为大量不确定性很大的任务注定会失败。
您可以将这些任务分为几组，将详细的计划委派给各组。 可以将几个人，几十个任务安排在一个链中，快速响应变化，做出有关更改优先级的决策。 但是在项目级别，还需要其他方法。
利用体积法进行救援。 在不涉及理论的情况下，我将描述如何为开发的计划事实控制实现此方法。
我们已经确定了任务的生命周期，并确定了每个任务的计划复杂性。 现在，我们分配每个阶段任务的完成百分比。 就我们而言，因为 在设计和编码方面进行了人工投入的划分，每个值都分配了一个百分比。
兴趣分配是由专家完成的，评估我们认为完成任务的数量，在此阶段还剩下多少劳动力。
在编译了这样的表格之后，对于每个任务，可以从已经掌握的计划中确定多少人日，从而测量每个任务的进度。
例如，一项任务的计划人工投入为设计10个小时，开发20个小时。 然后，在测试阶段，我们认为分析人员的工作完成了80％（完成测试所需的另外20％的工作），开发人员的工作完成了50％。 我们已经准备好承认设计工作了8个小时，而开发工作却需要10个小时。 总共30个工作日中，有18个已经完成。
同时，我们没有考虑到实际上可能会花费其他时间。 对于所述目的，这并不重要。
7.项目报告
有了一张表格，对于每个任务我们都有计划的复杂性和掌握的数量，很容易理解事情的进展。
可以将任务划分为项目的方向，组件和里程碑，以便能够进行更详细的分析并在所有必要的部分中创建汇总表。
项目的总体情况便于在领导层进行展示：
JIRA上传摘要表
控制整个项目的计划事实
这种方法并不总是可以理解的。 人们对神话般的人类日子的理解比对发展的了解还少。 而且他不会取消小组和个人表演者级别的详细计划。 但是，这是评估当前情况和预测工作完成的最客观方法。