请注意，标题中没有问号。 我不想争论现代软件开发中是否需要项目经理。 实践证明没有。 我只是想找出原因。
在IT行业工作了20多年，我开始从项目办公室构建每个新开发项目。 而且，我不得不几次向管理层解释为什么要聘用馅饼。 考虑到部门负责人的存在，要向不直接参与软件开发的人员解释项目经理将要做什么的工作并不容易。 我必须克服明显的阻力。
但是对我来说，项目办公室和项目经理是成功的基础是一个公理。 并告诉我大约五年前不需要项目经理的情况，直到最后我都会与他争论。
编者注：本文是Piemnaya集会上Arrival的Dmitry Kruglov报告的结果。
还是你还需要
让我们从保护这个职业开始。 仅仅是因为在最后工作地点取得了成果，包括感谢成功建立的项目办公室。
项目管理不是IT的特权。 这是一门已有50多年历史的科学。 有自己的圣书的科学。 当然，PMBoK不是那种，有PRINCE ，也许还有几本书，或多或少地称赞桂冠。 但是PMB®K是国际标准的基础，这表明它的认可度很高。 因此，我们将以此为基础。
让我们玩这个游戏：如果您是项目经理，那么尝试从国际标准和拥有50多年历史的机构的角度回顾一下您的主要活动领域，而不用展望未来？
例如，管理项目需求。 或管理期望。 也许您还记得时间安排。 当然，代表企业的同事会定期询问确切何时可以完成此任务。 也许您会回想起利益相关者的管理，这种情况很少见。 还有什么 通讯管理。 后者与利益相关者一样罕见。 但这是我们时代的一项重要而艰巨的任务，当时所有项目参与者都希望在Telegram上共享重要信息，而不是章程草案要求的电子邮件。 如果您根本不被邀请参加讨论其工作质量的聊天，该如何管理通信？
将您回忆的内容与PMBoK的列表进行比较：
所有项目都很理智。 似乎确实需要每个项目经理来完成此活动。 其中一些可能不太明显，例如项目集成。 但是，如果您使用多个团队的力量来制作一个非常重要的功能，并且需要在发布之前将其放在一起，那么您将了解这一点。 顺便说一下，尚未并行解决在多个团队中同时开发一种功能的任务。
甘特图
如果有活动，那么一定会有结果。 我个人认为该工作是使用适当的工件完成的。 对于程序员来说，这是工作代码。 对于测试专家，开发或执行的测试脚本，系统中引入的错误或创建的自动测试。 对于设计师-图形布局。
什么是项目经理工件？ 在所有可能的工件中，包括电报中的消息：“最后，将我添加到您的聊天中，如果没有它，我将无法管理该项目！”，我首先要注意甘特图。 这是一个很好的工具，可以回答有关项目的许多问题，并有助于可视化项目经理的大部分活动领域。 毕竟，一个好的甘特图包含时间，资源，成本和依赖性。 您可以在此处将通信需求添加为任务。 您甚至可以通过里程碑和对预期结果的描述，为利益相关者及其期望添加控制。 事实证明，它适用于所有场合。
这些领域中的大多数任务是通过管理一个实体-甘特图来解决的。
允许您创建图表的工具和服务的数量证实了它的流行性和多功能性。 尝试搜索“在线甘特图”，查看每种口味和颜色所对应的链接列表有多长时间。
结果是：作为结果，我们有一个专业，有一项活动，并且有一件好事。 那么有什么收获呢？
这都是关于细微差别的。 例如，对于甘特来说，并非一切都那么好。
首先，大型项目的图迟早会变得不可读。 我曾在Microsoft Project从事过“一年以上”项目的经验。 要打印他的计划，必须粘贴六张A4。 在一页纸上，文字太小。
其次，大型项目的图维护非常费力。 通常只能由作者本人进行更改，否则该计划由于复杂的依赖系统而崩溃。
第三，必须承认，除了许多项目经理以外，没有人会阅读许多图表。 事实证明，该工件是由PM产生的，仅他一个人就需要并了解它。
在现代软件开发中，甘特大部分时候都被放弃了。 我们在创建产品时不再使用此工件，我们真的需要它的作者吗？
如果您尝试搜索有关IT项目经理的有用性的话题，那么很显然，这种讨论已经进行了很长时间了。 她成功地成为了另一个喜剧演员，例如iOS和Android，Windows或OS X的恋人之间的对抗。只有搜索结果中的引号更加让人激动：“我们需要PM吗？”，“我们为什么决定摆脱PMs”，“ PM的工作不值钱吗？”
我并不是要说全球争端的平衡是赞成拒绝总理，但至少这种观点的支持者很多。
敏捷方法
我开始在一家公司工作，而我的任务是从头开始建立一支开发团队，我意识到在接下来的六个月到一年中，我没有PM的任务。 起初，我出于习惯将其添加到组织结构中。 然后他用手踢了出去。 直观地划掉了，但想知道：“为什么会发生？”。
我对原因的研究使人们了解到，IT具有许多独特的品质，可以实施灵活的方法。 有一个经典的比较：盖房子并开发软件。 这些是有些相似的学科，并非没有道理，在这两者中建筑师都扮演着角色。 既存在又存在一组功能和非功能需求，其中包括基础架构，内部通信，组装，交付和集成。
但是，该构造是在现实世界中进行的，并且在进行首次测试之前，在接收到第一条反馈之前，在接收到结果之前，生产周期非常长且昂贵。 施工错误的代价很高。
IT产品是数字的。 而且生产周期可能非常短。 在过去的二十年中，我们能够创建工具和技术，从而带来了灵活的开发方法。 在这里，我准备提出因果关系就是这样：快速进行实验并获得工作结果的能力导致了如何做到这一点的方法论的出现。 当然，这是一个简短的积极反馈，并且工具也在不断发展。 然后再次确定了方法论。 以此类推，我们急于缩短上市时间。
的角色
敏捷方法论已成为事实上的标准，并为软件开发过程带来了新的作用。 这些新角色开始带走项目经理的活动和工件。
产品负责人（PO）
有些项目有几个客户，几个所有者和几个决策者。 对他们而言，下午是寻求妥协的人。 他将所有人员聚集在一起，帮助确定优先顺序，和好。 他对某人说：“不，”某人的游说。 但是企业了解到，在不断寻求折衷方案的过程中，资源浪费效率很低。 最宝贵的资源是所有时间中最宝贵的时间。
因此，灵活的方法就是这样做的-他们向企业中的一个人说出了一种精神：“对于金钱，流量和转换，您是极端的。 老实说，我们不在乎您在产品中执行的工作以及优先级。 最主要的是，到今年年底，转换率将从1％增加到1.1％，否则该项目将无利可图。” PO有权单独做出决定，PO可以确定优先级，创建相应的工件（计划，路线图，需求），并由PM负责。
Techlide（TL）
大约十年前，IT开始更改已建立的体系结构。
在进行这些更改之前，主要为“分层体系结构”（数据库层，业务流程层，聚合层，客户端层）创建技术和工具。 但是，一旦这种方法成为经典，公司就收购了相应的部门，便有了灵活的方法。 每个人都一致认为“粉扑派”不好，因此有必要组建跨职能的团队。
更不用说这是一个新主意。 通用开发人员叫什么？ 全栈 采访中一位30岁以上的开发人员说：“当时我还不是一个全栈开发人员，而术语全栈还不存在。” 一旦我们都坐满了，因为我们必须做所有事情，包括数据库管理和设置控制器的计算机。
跨职能团队带来了新角色：技术幻灯片。 Tehlid不仅吸引了部门负责人，还接管了PM工作的技术部分。 首先，一切都与评估复杂性和时序有关。 在过渡到灵活的方法时，许多人已经接受了这样一个事实，即开发团队必须自己评估其工作条件。
系统分析师（SA）
系统分析员不是新角色，许多敏捷方法论不是。 我不敢肯定地说，但是有可能在SAFE中明确提供它。 但总的来说，外管局是一个临界方法。 但是，此角色非常有用且有趣。 就像复杂机构中的润滑剂一样，它可以使其安静，平稳地工作。 系统分析师部分是产品的所有者，部分是架构师。 它阐明和详细说明了特定功能级别的业务需求。 最好的系统分析人员可以结合技术素养和软技能，在两个方向上提高他们的想法和远见。 在系统分析师工作的地方，项目经理被剥夺了需求管理活动。
Scrum Master（SM）
Scrum Master极大地挤压了项目经理的角色。 可惜的是，现在SM本身已经成为灭绝的候选者。
认真地说，Scrum Master迟早会在学校教书。 将会有关于敏捷的课程，Scrum Master会告诉12岁的学生敏捷方法如何工作以及存在哪些实践。 敏捷经验现在已成为无处不在的开发经验。 在一次采访中，每20个人中有19个人进行了为期两周的迭代，谈论流程变成了其参数列表：
-什么是评估？
-故事点。
-什么是速度？
-68。
-您如何计划项目？
-在S，M，L的“ T恤”等级中。
这是一个非常快速的对话。 使用最新技术，可以在一小时内讨论所有工艺参数。 之后，他们将与团队一起工作，因此不需要Scrum Master。 该行业几乎消化了这一角色，并且还在继续发展。
当然，并非到处都是这样。 当然，有许多公司需要达到市场标准，这不是一个快速的过程。 在俄罗斯，十年后，当该组织决定将其三名程序员转移到敏捷团队时，就有可能在某种“ Lenoblkhozpromlespoval”中找到Scrum Master的工作。
在流行期间，Scrum Master设法完全消除了PM项目团队的所有问题。 他们认为这不是他们自己而是团队成员，从而促进了他们参与设计工作。 顺便说一下，这在企业眼中大大提高了IT成熟度。
还是还是不需要
还剩下什么？ 我大胆地强调那些在采用灵活方法时要由其他角色解决的任务。
此后，项目经理还有什么？ 剩下的沟通，整合和采购。 似乎没有什么可以让热心的人担任这个角色？ 是时候说不需要PM了。 但是没有
还需要
在IT项目的类别中，几乎可以确保没有专职管理人员的失败。
现实世界中的项目
那些从事移动开发工作的人都知道，随着更改的速度和错误的代价，事情变得不太顺利。 如果您错过了移动开发中的一个错误并没有立即注意到它，那么将很难为整个受众进行更新。 某些用户将不会更新其应用程序，并且错误仍然存在。 例如，从这个问题出发，已经有了对移动应用程序功能进行远程控制的方法。
但是，这是管理软件开发的PM的痛苦的一百分之一，例如，管理规模为500万件商品的仓库中的分拣输送机。 在这样的项目中，数十个设备供应商的依赖关系，迭代以几个月为单位进行衡量，并且错误的代价增加了一个数量级。
与设备相关的项目使我们从数字世界回到现实，而经典的PMBoK控件仍然与现实息息相关。
伞项目
在总体项目中，灵活的方法学停滞了。 这样的项目既大又复杂。 复杂性意味着显式和隐式依赖性，并且在一定程度上，如果没有专门的项目经理，开发效率将非常低下。 在此类项目中，PM的主要任务是项目集成，依赖性和时序管理。
错误成本高的项目
总是存在必须最大程度消除错误的行业-医药，航空，航天工业和军事领域。 在这些区域中，当发生错误时，人们要么死亡要么损失大量金钱。 在Internet上很容易找到示例。 从有关Arian-5欧洲导弹的故事开始。
在这些领域中，PM仍将是需求，但在能力和经验方面将对它们提出很高的要求。 而且，此类项目的比例越小，对候选人的选择就越严格。
没有角色的项目
生活是一件艰苦的事情，要担任每个角色总是不可能有一个专职的人。 直到世界变得完美为止，将剩下负责产品负责人的PM。 或实际上起技术作用的PM。 这样的组合通常是创业公司的特征。
如果我们及时延长现在该行业中正在发生的趋势，那么我们将有一个未来，其中PM的纯粹形式仍然与少数软件开发项目相关，这些项目的工作我们还不知道如何实现自动化或分发。团队成员。
编写人：
作者-德米特里·克鲁格洛夫（Dmitry Kruglov）
编辑-Eugene Shklyar，Denis Vonsarovsky
作者在某些问题上的观点可能与博客和Yandex.Money公司的编辑委员会的观点不一致。