在无法完成“正确”和“更好”的情况下，如何建立有效的项目管理流程？ 本文概述了使用JIRA来管理大型政府客户利益的软件开发项目。 如果所描述的方法能够帮助您个人提高团队效率并减轻项目压力，我将感到很高兴。 任何批评都值得欢迎。
来源艰难的错误之子
从Internet上大量关于如何在软件开发中正确应用项目管理系统的模型文章来看，这是一件简单而感激的事情。 但是，在我有机会参与的项目中实际使用自动控制系统并不像人们期望的那样“乐观”。 在实践中遇到了几种典型的情况。
最好的选择取决于项目团队使用的许多错误跟踪系统之一。 项目的任务和业务流程的结构通常是“开箱即用”的。 这些系统主要由程序员和测试人员团队使用。 这样的开发组织可以在与私人客户进行的小型项目中获得丰厚的回报，或者如果执行者的任务仅包括对软件产品的保修支持（更正检测到的错误），则回报很高。 但是，随着新要求的增长，这种方法开始溜走了。 这体现在比较客户需求和错误跟踪程序中存储的信息（以及手动编译集成报告）上的时间增加，以及将团队分为两个阵营（“好”程序员和“坏”分析师）的时间。
其他情况则归结为领导层的“辉煌”灵感，当时，利用管理手段，将最佳的软件开发方法“引入”了项目团队的活动。 的确，这些领导人认为他们的行动仅限于寻找“银弹”的过程。 他们没有理会“
冲刺 ”，“
任务燃烧图 ”或“
累积流程图 ”之类的概念。 即使麻烦，也需要将项目状态的报告文档（再次手动）与这种最佳方法松散地联系在一起。 尝试向客户介绍这些方法导致了这样一个事实，即项目的条件没有改变，并且对于旧的报告，还需要生成新的其他报告（根据新的方法）。 这种矛盾在政府合同项目中尤为明显，其组织条件与
敏捷 ，
RUP或
PMBOK的成功应用直接冲突。
管理自动化的典范是为了满足一个大型州客户的利益而完善联邦级信息系统的项目。 作为该项目的一部分，客户自己使用了
HP Service Manager和
JIRA 。 HP Service Manager用于收集和分析软件错误。 在JIRA的帮助下，客户计划了与纠正这些错误和进一步开发系统相关的员工活动。 这些系统中的任务状态列表提供了处理它们的所有可能选项。 由客户的项目办公室（即不负责维护和开发的人员）组成的支持这些任务的详细过程已发布在
Confluence平台上。 允许承包商的员工使用这两种系统，并且他们被赋予支持事件和要求的责任（具有处理任务的临时准则和渐进的罚款额度）。 此外，在承包商现场部署了JIRA副本，并借助该计划计划了项目团队的活动。 这三个系统的活动同步都是手动进行的（为此，我必须在Excel中保留一个“工作表”，其中记录了任务及其当前状态的关系）。 此外，JIRA生成的报告不适合管理层，因此项目团队必须提供有关其活动的每小时报告，他们还可以在Excel中手动创建报告。 当开发团队的负责人或支持小组的负责人“挂断”工作直到深夜，并根据项目团队的结果生成有关项目状态的摘要报告时，情况并不少见。 该项目按时成功完成并被人们记住，除了创纪录的低生产率，神经衰弱的次数增加，职业倦怠迅速，以及从“幸存”员工的奖金来看，利润率出乎意料的低。 在进行了这些项目之后，这种想法困扰了我们很长时间：“如果我们创建能够极大地改善客户生活的工具，那么为什么要使用这些工具来使我们的生活变得如此复杂？”
国家发展特点
总结经验，我们可以得出结论，软件开发管理自动化的最大问题发生在国家命令项目上。
来源而且，根据软件开发的最佳实践反复尝试解决这些问题的结论是：这些不是问题，而是国有客户实施该项目的必然条件。 通过对几个项目的分析，我们可以确定这些条件的以下一般特征：
- 通常，技术规范的初始要求含糊地制定，随着项目的发展，客户在这些要求中赋予了新的含义（除其他外，这与管理自动化业务流程的当前法规框架有关）；
- 职权范围中记录的要求范围从“更正题词”到“实施用于监视和分析所有过程的子系统”，而所有要求都必须无条件地执行（通常，不接受改进措词的建议，您只能影响某些建议。实施方法的限制）；
- 有时，客户不知道如何解决问题，将这些问题“推”到承包商身上，包括要求，将其温和地说为“深奥的”（诸如“ ...子系统应提供主要货币汇率的预测”）。短期，中期和长期……”）；
- 如果合同与现有系统的完善相关，则客户需要在试运行之前引入单个组件，以保证整个系统的不间断运行（可以与旅途中完成汽车发动机相比较）;
- 客户由几个单位（组织）代表，其需求通常是矛盾的；
- 尽管有变更和增加要求，该项目的预算和最后期限仍保持不变；
- 客户不寻求与开发人员的合作（合作基于“先做，然后我们会看到”的原则）； 客户代表避免了就需求规格做出任何决定的责任，忽略了有问题的问题的协调时间，在开发开始之前要求协调是没有用的，因为 团队没有按时完成任务这一事实与客户无关（即这是我们作为表演者的问题）;
- 一方面，客户要求整个文档包完全符合GOST的正式要求，另一方面，要求开发用于解决特定问题的产品的其他说明。
通常，所有这些因素都引起项目团队对“客户不足”和“项目管理不当”的愤慨。 但是，考虑到上述条件的客观性和可重复性，在运输公司赢得了
北海路线运输的大标书之后，项目团队对国家客户“复杂性”的抱怨类似于船舶团队对极夜的寒冷和黑暗的抱怨。
事实证明，除了外部条件外，软件项目中涉及的员工团队还具有共同的特征。
- 项目团队的核心可以由5-12名员工组成：项目经理，分析师，测试人员，技术作家，程序员。 尽管事实上有些员工有时可以扮演多个角色，但这些项目团队的特点是“ 总线系数 ”低。 这本身也对使用敏捷方法施加了限制（例如，在这种条件下使用扑克调度不太可能有用）。
- 项目团队必须与软件开发流程一起，同时提供保修支持（纠正软件错误）和扩展支持（针对客户业务流程中的当前更改，各个系统模块的操作完成）。
- 作为执行单个任务的一部分，涉及公司相邻部门的员工以及分包商（客户强加的外部公司），项目任务通常是次要的。
希望的胜利
第二次婚姻是希望胜过人生经历。
塞缪尔·约翰逊（Samuel Johnson）
两年前，我作为首席分析师受邀参加了
LANIT根据政府命令实施的项目。 项目团队是较早成立的，该项目包括对已有十多年的自动化系统进行了重大改进。 通常，项目条件如上所述。 当时，开发团队在工作中没有使用任何现有的项目管理系统（尽管几乎所有员工都参与了使用此类系统的项目，并且对自动化管理的需求持怀疑态度）。 但是，当前的初始状况为“从头开始”测试项目管理的自动化提供了机会。
JIRA被选为自动化平台。 以下因素共同导致了此选择：
- 记录多对多任务之间关系的能力；
- 盒装版本的设置灵活性；
- 保存项目中所有更改的历史记录；
- 部分开放式体系结构，可以根据自己的需求进行细化；
- 与项目团队已经使用的外部系统（SharePoint，Git，SVN等）交互的能力；
- 在您的服务器上使用的能力（用于封闭项目）；
- 在该系统的管理方面具有丰富经验并有兴趣统一其应用程序的员工在单位中的存在。
从历史上看，JIRA版本6.4是在工作中使用的，但是，在我们的项目中针对该版本实施的解决方案的各个元素部分地出现在了新的JIRA版本中（即间接确认了所做决定的正确性）。
项目管理自动化最初追求以下目标：
- 提高项目团队员工的睡眠质量 （众所周知，休息的人工作效率更高）；
- 确保透明分配执行项目任务的责任；
- 提供项目团队的“多线程”，即 尽可能并行化工作；
- 自动提供有关执行每个客户要求的当前状态的信息；
- 提供对项目当前状态的监视，以便在早期阶段识别项目的问题和风险；
- 形成统一的会计方法，评估和比较各种软件开发项目状态的方法（类似于Google Analytics（分析）或Yandex.Metrica服务，可让您通过相同的指标评估任何网站）；
- 根据收集到的统计信息来提高估计任务时间的准确性。
为了避免“自动化实现自动化”，在JIRA中设计数据计费模型时还考虑了以下注意事项（限制）：
项目管理自动化不应惹恼项目团队。 考虑到以前在项目管理自动化方面的负面经验，关键的实施因素之一就是创造了这样的条件，即项目团队的每个员工都不认为JIRA是项目船上的额外负担，而是一个集体导航系统，可以及时通知团队迫在眉睫的危险并帮助实现目标以最短，最安全的方式进行项目。 此外，使用此导航系统应有助于所有团队成员的生活，而不仅仅是项目管理。 为此，最初计划与JIRA一起使用的程序要考虑到程序员，测试人员和技术作家所记录的数据量的最小化。 另一方面，目的是在JIRA中为所有项目员工创造一个舒适的工作环境，这将帮助他们确保有效地计划工作日。
保证连续性。 自动化项目管理的目标之一是确保连续性，以便任何合格的员工都可以在没有“试用期”且最小的头痛下“承担”退休团队成员的职责，以使“班长不会注意到战斗人员的损失。” 在这方面，我回想起一个客户告诉我的案例。 一旦他待在老板那里，他就去度假了，老板用复制品告诉他计算机上的密码：“好，那里的一切都清楚了，如果发生什么事，你会弄清楚的……”。 该员工度过了数个不眠之夜，其中包括几个名为“ xxxxx1”，“ xxxxx11”和“ xxxxx111”的文件夹的内容（为了礼貌起见，更改了文件夹的名称）。 要防止此类情况，需要向JIRA注册所有项目团队员工（包括项目经理）的工作结果。
极简主义 项目管理自动化的目标不是在一分钟内计算出特定员工在解决分配给他的任务上花费的工作时间，而是确保在给定的时间内解决给定质量的任务。 因此，在JIRA中部署项目时，采用了最小化系统中记录数据的原理。 即 为了做出明智的决定，控制系统中记录的参数集应该是最低限度必需的（“
完美的实现不是在没有要添加的东西时，而是在没有要删除的东西时实现 ”。 可以理解，采用的项目管理自动化模型应该在高度不确定性和不一致的条件下工作（例如，您可以知道文档的日期，但是不知道文档的编号，反之亦然）。 在键入记录的信息时，我们尽可能使用
Miller规则 ，该
规则指出，最佳类型（状态）的数量应在“七个正负两个”之内（这大大简化了员工对系统工作的理解）。 因此，例如，在设计任务（工作流）的生命周期时，最初假定状态数应遵守此规则。
一致性。 项目管理的自动化应有助于项目团队所有员工的行动的连贯性和连贯性（防止“天鹅，癌症和长矛”的状况）。
在我碰巧参加的一个项目中，一个分析团队在一个月内用
IDEF0表示法开发了一种自动活动模型。 看来，美国空军（！）创建的方法论的真正使用保证了这种方法的成功。 但是，当编程部门负责人研究多页分析报告时，他的第一个问题是：“那么，到底需要做什么？”。 事实证明，生成的模型不适合用作程序员对问题陈述的描述。 客户代表多次赞赏，跳过了许多方案，但也没有找到该模型的应用来优化他们的活动。 最后，这些方案修饰了工艺流程的描述，使该文档具有空前的厚度和坚固性，但是分析在此方面起到了积极作用。 该项目几乎没有要求数名分析师的一个月的工作结果。
有了这种经验，就可以在项目管理自动化中创建一个任务
传送器 ，以确保以最短的方式和最低的成本将客户需求协调地转换为最终软件产品。 同时，在监视该输送机的可用
参数的基础上，应该确定，测量和开发项目团队的紧急属性，从而可以判断项目各个阶段的状态。
看板从里到外
在我看来，控制自动化的成功很大程度上取决于在自动化系统中对控制对象进行建模的准确性。
由于应该自动执行软件创建过程的管理，因此对此过程进行了分析。我认为，创建单独的软件模块的过程始终代表着经典的瀑布式生命周期。首先，将显示所创建产品的需求列表。需求可以来自不同的来源，并且具有不同的详细程度。一些需求是相互联系的，另一部分是相对独立的。对于个别需求，您可以立即制定开发任务，而其他则需要澄清和具体化。即
总有一些与客户需求的收集，分类和澄清相关的作品（而各个需求的措辞可能直到项目结束时都是模棱两可的）。在需求尽可能具体之后，通常会为一组相互连接的需求形成所谓的任务定义，这些任务定义详细说明了这些需求的实现细节，并且是程序员开始工作的原始资料。编程后，将自动测试创建的模块，将其集成到系统中并进行重新测试。根据完成的软件更新，对设计和操作文档进行适当的更改，然后进行一些活动，旨在识别客户的愿望（要求）的完成以及随后在商业运营中开发的功能的实现。来源现实生活与美丽的瀑布方案之间的主要区别在于它的随机性（所有事情都不是阶段性的，而且是不一致的）。实际上，从一个开发阶段到另一个开发阶段的过渡不一定仅在上一个阶段的完整和成功完成之后发生。真正的瀑布有其自身的矛盾之源，死水和冷淡的浅滩，无处不在的沼泽，歧义的急流和漩涡，激流和光滑的石头，无拘无束的想象力，而且常常有喷泉甚至是有新要求的间歇泉。无法在项目框架内重新制作此元素，就像船队无法重新制作确保客户货物交付所需的河流一样。为了透明化项目管理自动化中的职责分配，实施了“ 1个任务-1个执行者”原则。 即
完成一项任务的过程显然并不意味着将其转移给其他表演者。由于工作状态主要是从任务执行者的角度确定的，因此该原理使得可以将相同的业务流程应用于所有类型的任务。标准JIRA工作流程已进行了少许修改。主要变化是将状态“重新发现”替换为状态“待处理”，即 指出何时出于任何原因暂停任务的工作。要注册重新发现的任务，已使用用户字段“重新发现计数器”。同时，详细说明了预期解决方案时任务转移的原因类型：- 与客户协调；
- 要求客户提供其他信息；
- 等待相关任务/子任务的解决；
- 需要澄清问题的陈述。
应该注意的是，引入“保留”状态实际上是为项目团队员工实施了“ 输送机停止按钮 ” ，从而确保了在项目早期阶段集体识别问题。
分析的结果是，实施了以下向JIRA注册项目信息的模型。项目中未使用JIRA表示的标准任务共享方法。创建了六种类型的任务，它们实质上与软件开发的主要阶段相对应：- “需求” -注册客户需求的任务类型（与新版本的JIRA类似-史诗）；
- «» – , ( ) ( ) ( JIRA – story);
- «» – ;
- «» – , ;
- «» – , ;
- “实施”是一种记录工作结果的任务，旨在将开发的软件引入客户的活动（进行测试，演示，发布版本/补丁/数据修复，在客户的服务器上部署软件，培训用户等）。
子任务用于解决主要任务执行过程中的特定问题（时间不超过两个小时）（例如，与程序员或项目经理协调设计决策，进行代码审查，准备测试数据等）。根据项目上建立的规则，要求的注册是计划其他任务的强制性基础。在对需求进行注册并向客户澄清之后（如有必要），形成了其他类型的任务，旨在实现此需求。换句话说，在采用的模型的框架内，其他任务应始终与满足其利益的需求相关联（使用连接类型“ cause”->“ action”）。为了实现一个需求，可以创建多个开发任务，另一方面，可以为满足多个需求而创建一个任务（用于分析，开发，测试，文档，实现）（与假定的标准JIRA方法相反）一项任务只能与一个史诗类型的任务相关联）。在提出的模型的框架内，还可以关联其他相关任务。一方面，这种方法确保了决策的一致性，另一方面，它提供了相当准确地反映项目实际状况的可能性。在这种情况下，组织工作的各种选择都是可能的，要理解它们的混淆似乎非常困难。反映JIRA中发现的任务的方法不能提供整个项目状态的方便视图（考虑到各种插件，也许我们只是没有足够的时间来找到所需的插件）。因此，为了简化提议的注册任务模型的工作，创建了我们自己的仪表板（最后，鞋匠必须能够自己缝制靴子）。从单独实现每个需求的角度来看，创建的仪表板使在项目上显示任务状态成为可能。乍看之下，创建的仪表板与经典看板板略有不同但是，在我们的案例中，列并不意味着任务的状态，而是它们的类型。在该仪表板中，为每个需求单独形成一行，其中与该需求相关的所有任务均按活动分组（按照经典的瀑布顺序）。如果创建任务是为了满足多个需求，那么在相关需求的每一行中都会重复执行此任务的卡片。任务的状态以创建“三维”的颜色反映在此仪表板上。在这种情况下，需求的就绪程度由与此需求相关的所有任务的就绪程度决定。事实证明，就像看板朝里一样。另一方面，从PMBOK的位置，生成的仪表板是经典的“需求跟踪矩阵”的改进版本。为了显示任务的状态，采用了以下颜色方案：- 蓝色-任务已包含在工作计划中；
- 蓝色-任务正在进行中；
- 粉红色-任务没有执行者；
- 黄色-任务待处理，需要解决方案；
- 灰色-任务已关闭（您可以忽略它）；
- 橙色-完成任务的截止日期已中断。
任务卡上出现红色铭文和标记表示需要立即就该任务采取措施（例如，如果未设置截止日期，则该铭文以红色显示）。除颜色外，随着项目的发展，仪表板上的任务卡还被其他标签围绕着，这些标签使您可以一目了然地评估项目上的工作状态。优先标签：
-正常；
-重要；
-严重；
-封锁。有关需求框架的标签：
-开发（旨在实质性修改现有系统的项目框架内的需求）；
-扩展的支持（对客户业务流程中当前变化的单个系统模块的操作完成要求）；
-保修支持（检测到软件错误）；
-非项目活动（项目经理对项目前活动，重构，预售，新技术开发，人员培训等的要求）。期望原因的标签：
-要求客户提供其他信息；
-与客户的协调；
-等待相关任务/子任务的解决；
-需要澄清配方。特殊标签：
-数据库已在任务中完成；
-与任务相关的需求数量（相关需求越多，任务越重要）；
-未解决的子任务数；
-重新发现任务。实际上，该仪表板已经成为每天接收项目管理问题答案的主要工具：“今天最重要的是什么？”，这又使我们能够及时对问题做出响应。从提议的模型的角度来看，为防止项目出现问题，有必要确保每天减少提议的仪表板中红色，橙色和黄色的数量。另一方面，引起关注的原因还在于缺少与需求相关的任务（即需求被计划并且没有工作来执行的情况）。通过为创建的仪表板使用过滤器，可以在综合体中根据选定的需求列表反映事务状态。在它的帮助下，可以快速协调整个项目团队的行动，将精力集中在最有问题的领域，而又不会丢失整个项目的整体情况。瀑布不能敏捷
为了记录所有类型任务的工作结果，部署了两个存储库（用于项目文档和软件代码）。在这些资源库中添加（更改）资料会自动反映在JIRA的相关任务中，并且是表演者报告的主要类型。使用提议的方法在JIRA中注册任务的工作安排被简化为以下方案。- JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
- , . , , , . () .
- , , . , , ( ), () , , , ( ).
- ( ) , , . . , . «» , ( ).
- 理想情况下，应在注册开发任务（指定程序员的目标）之前形成测试任务。在测试过程中，负责的测试人员不仅要保留检测到的错误的日志，还要在测试任务和用户手册中更正检测到的错误。
- 根据需求，计划了完整的工作清单，从而形成了执行任务（在注册过程中，JIRA再次指定了执行需求的优先级和截止日期）。
- 在交付给客户之后，可以将请求转移到“已关闭”状态，并带有接受文件详细信息的强制性指示。
应该注意的是，为执行单个需求而形成所有类型的任务并不是成功计划的前提。 例如，可以将诸如“更正字段名称中的错误”之类的简单要求直接分配给程序员。 同时，在项目的实施过程中，应注意的是，在初步测试和试运行期间，大部分意见是未形成设计决策的要求。
在所提出的方法的框架内，使用滚动波计划
方法进行
的工作计划已被很好地证明了自己。 同时，部分由于上述仪表板的出现，可以避免计划工作的分散化和不一致。 在注册的初始阶段，根据要求进行的选择就像一把
红伞 ，而对于大多数要求而言，还没有确定可用性日期和负责人，并且仅计划了其中的一小部分。 但是，需求仪表板逐渐变成了蓝绿色的地毯。 地毯上出现的红色和橙色斑点迫使我们对预期的任务进行日常调整，这有助于降低项目风险。
所提出的数据组织模型显示出良好的可伸缩性。 最初，项目团队中只有三名员工（一名分析师和两名程序员）在他们的工作中使用了JIRA，同时记录了各个子系统的需求。 但是，到项目结束时，JIRA已注册并监视了100％的开发和扩展支持要求，并有所有项目团队员工的参与。
尽管事实上项目管理自动化的思想是基于开发（瀑布）的级联模型的，但事实证明，在所提出方法的框架内，如果需要的话，可以毫不费力地使用敏捷元素。 通常，谁说瀑布不灵活？ 例如，要在建议的模型框架内应用
Scrum ，足以确保事件（任务）的规则性以实现软件，然后相应地，将“强制”与该事件相关的所有工作，以遵守以这种方式设置的冲刺规则。
此外，所建议的任务注册方法并不限制项目经理应用看板方法并使用JIRA提供的“开箱即用”的各种
敏捷仪表板 。
待续
结果如何？ 开发的软件已投入商业运行。 在初步测试，试用操作和验收测试期间，客户记录了有关已实施软件产品的许多评论。 但是，随后，根据澄清JIRA中存储需求的材料，客户被迫将25％的注释视为超出项目范围的新需求（满足这些需求的计划复杂性与完成的技术任务相称）。 与执行国家订单合同有关的问题并未消失，但是，使用JIRA监视对要求的遵守情况，可以在启动阶段识别中断风险并快速做出响应。 反过来，尽管有国家软件开发的特殊性，但这也确保了该项目在所有阶段的积极发展。 要指出的是，如果在JIRA上注册了客户需求，并在其上进行了分析，开发和测试的任务，则关于此类需求的分歧和争议要少得多。
在当前阶段（维护阶段），所有需求都反映在JIRA中。 项目团队的所有员工以一种或另一种方式在工作中使用JIRA。 程序员在JIRA中注册其工作结果的成本不到其工作时间的1％。 相比之下，对于分析人员而言，JIRA已成为主要工作工具之一。 为客户的任何需求找到一套完整的信息不到一分钟。 基于执行结果的报告文档将根据JIRA中包含的数据自动生成。 而且，基于这些数据，形成了随附的发行文档（更改列表和发行测试程序）。
在新规则下使用JIRA的两年经验证实了旧的真理：
- JIRA不能取代项目管理，但是可以帮助快速导航各种任务的流程。
- JIRA将帮助您在正确的时间将您的项目聚焦在正确的地方，但这不会帮您做到；
- JIRA不会为您解决项目中的问题，但会帮助您在早期阶段就识别出这些问题（同时，它将识别出您希望隐藏的那些问题）；
- 像任何自动化系统一样，JIRA可以帮助您快速执行您的任何决定，无论决定是好是坏。
- JIRA不会取代项目团队员工之间的沟通，而是将帮助您轻松解决纠纷；
- JIRA不会挽救一名雇员免遭解雇，但它将帮助另一位已取代退休人员的雇员迅速了解情况；
- JIRA将仅根据您提供的注册信息来帮助生成项目报告文档。
最重要的是-JIRA不会为您决定是否使用它的帮助。
乔布斯LANIT有兴趣