该会议是“工程师走进一家酒吧”系列的一部分，来自不同IT公司的工程师讨论专业非工程主题。在Dolgushev和Storozhilov DevRel-bureau的支持下，Miro公司的工程师组织了一系列活动。
该系列的第二次聚会将于8月20日举行。主题是团队，公司和行业的毒性。演讲者-来自Miro，SEMrush，Parma TG和Xsolla的工程师和技术负责人。注册已经开放。
目录：
公司的具体情况和当前工程师专业发展体系
Miro产品软件工程主管Artyom Susekov。我们创建了一个用于团队在线协作的产品，一个在线协作白板平台。该公司拥有400名员工，工程师不到一半。产品开发办公室-在彼尔姆和阿姆斯特丹。这些团队是跨职能的：工程师，产品经理，设计师以及（如有必要）营销人员。他们使用scrum，有些使用看板。进行规划-在广告系列级和单个团队级的OKR。
我们有等级，每个等级的期望都以行为（行为模式）的特定示例形式制定。这样做是为了不仅仅停留在形式上的期望上（“要做很多任务，得到某某证书”）。将获得的知识应用到日常工作中更为重要，这正是在针对每个年级描述的特定示例中所显示的。
标准成绩：初中，中级，高级，每个年级都有几个步骤。在高级职位之后，有机会成长为技术专家或成为团队负责人，然后成为方向经理。
我们每年进行两次绩效评估。在此过程中，您会从队友那里获得反馈，团队负责人会从直接为其报告的人员那里得到反馈。另外，员工写自我评价，即他独立地评估他的工作。
对结果进行总结，然后进行职业对话：结果很好，结果很好，将来应该强调什么，应该使用什么。然后，经理帮助制定下一个六个月或一个季度的发展计划。
Career onversation ( , , ), : , , .X5零售集团Innopolis技术能力中心负责人Alexander Borisov。大概大多数人都熟悉X5。我们拥有Perekrestok，Pyaterochka和Karusel连锁店。如果三年前我们是一家销售西红柿的公司，现在我们正在努力成为一家销售西红柿的IT公司。
大部分利润来自我们的IT服务。 Pyaterochka的工作方式和价格如何，可能是由于完善的物流和这一大型流程的管理系统所致。我们公司拥有两千多名IT专家，仅在Innopolis就有近150名员工。
在过去的一年中，所有这些都开始从部门格式转换为产品团队格式。我们已将服务和产品细分为微服务和子产品，一个团队可以负责。现在，我们有每个产品的产品负责人，跨职能团队，每个团队都有开发人员，测试人员，分析师以及部分职能，人们可以在其中相互重叠。
自然，我们有一对一的会议，OKR，360反馈，有趣的是资源池所有者功能。这些人负责Java，JS，Python，测试，分析等。公司中的每个工程师都有一位业务负责人（产品负责人），他了解一个人在产品上投资了多少，以及他的工作带来了多少利润，并且由一个人负责其特定能力的技术开发。
我们拒绝正式定义各年级之间的过渡，例如“从初中级减至中级减级，您需要这样做。” 我们担心，如果我们给出明确的过渡标准，那么人们将开始过于正式地采用这一方法。但是这里的手续是有害的，因为在每个团队中，每个人都可能是非常个人的：一个人和一个人可以承担更多的责任，并且由于这种发展，或者注入我们特定的一小部分技术，因此对企业更有价值。
对于高级职位，知识传播是成长的重要前提。您不是处于真空状态的大四，而是与团队分享您的经验，并与他人一起发展。
Funbox首席技术官Sergey Averyanov。十多年来，我们一直在为三大运营商开发软件。目前，我们有大约200名各种配置文件的开发人员以及相当多的技术支持技术专家。
一方面，我们没有整个团队都参与的单个产品，另一方面，没有像外包那样的大量项目和任务。这就是我们特定的工程师专业发展的地方。我们故意放弃了正式的评分系统：也许这是管理层和员工自己想要的，但这是一个非常僵化的系统，试图用相同的笔刷来样式化每个人，但这在实践中并不总是可能的。取而代之的是，我们使用相当标准的东西：对员工进度的定期评估和一对一的对话。我们有机会客观地评估每个任务跟踪器的贡献。所有这些加在一起使我们对每位工程师的水平都有了了解。
另一方面，我们的主要目标之一是使每个人都了解自己的成长方式和发展方向。我们尝试考虑所有人的不同之处：某人有兴趣担任技术专家，与人之间的交流很少，不涉足行政事务；有人想要交流，与人合作，参与同事的发展。所有这些都是正常的，所有开发选项都是可能的。
我们正在尝试建立一个系统，使我们能够提高工程师的水平，并为他们提供明确的指导，以帮助他们了解业务需求以及下一步的发展方向。我们也非常重视内部增长。我和整个团队都认为，最好的专家就是我们在团队中培养的专家。因此，我们正在积极投资内部发展，聚会，内部和外部会议。这也是主要目标之一-我们所有工程师的全面，高质量发展。
抽象开发部门不应参与员工发展。这是直属经理的职责之一。
这种方法对我们和员工本身都有好处。一方面，我们在员工中不断保持有机增长。另一方面，我们可以让高级大三和团队领导者从前大三辈中脱颖而出，而员工本人则认为他的直属上司是四年前担任该项目大三的人，这意味着在合作之前，现在有相同的机会和可理解的步骤增长。
ManyChat工程主管Mikhail Mazein。我们正在开发一个SaaS营销平台，可让您安排企业与其客户之间的交流。公司正在积极发展：三年前，团队中有15个人，现在我们有120多人。在第一阶段，我们与经典的职能团队合作：后端，前端，测试，设计团队。每个团队都有一个团队负责人，负责冲刺计划和任务分解。
在成长的过程中，我们意识到这阻碍了我们以期望的速度前进，并将工作重新格式化为跨职能团队。现在我们有9个这样的跨职能团队，没有团队领导，因为这些团队原来是自组织的，可以对他们的工作方式负责。
为了使功能事物同步，我们开发了通用的方法，以使开发不会变成无政府状态。例如，当后端开发人员分布在不同的团队中，但是使用一个项目，一个代码库并在那里提交代码时，这是必需的。我们组织功能性社区来解决这些问题。随着时间的流逝，非正式领导人出现在推动流程和沟通的社区中。结果是一个扁平的结构，该结构不将开发人员的角色限制为只编写代码的工程师的角色，而是允许您做对公司有用的各种事情，同时又对个人有益。
由于我们放弃了团队领导的角色，因此我们需要一个流程来使我们能够清晰透明地为工程师建立增长轨道。为此，我们使用了一个指导系统：每个员工都有一个指导者，负责他在公司内的成长和发展。
您不能随便走到一个随机的人面前说：“让自己成为一名导师”。首先，必须收集以下几个因素：个人本人的欲望；团队对个人的高度信任；来自公司本身和管理层的信任。导师的任务之一是培养新的导师。事实证明，这样的萌芽，从导师到导师。
我们区分了三个主要的发展载体：
- 第一个主要途径是产品团队在产品开发方面的更深入工作，对业务价值和指标有更深入的了解。
- – , , .
- – , .
我们还尝试创建一个评分系统：我们尚不能正式描述所有评分，因此该系统是建立在人员贡献，团队水平和整个公司水平上的。我们用清晰的例子描述了每个级别的期望，对一个人期望的责任领域或影响领域。另一方面，导师可以告诉一个人需要达到什么技能才能达到期望的水平。
MadRobots开发主管Anton Grishin。乍一看，我们公司是一家处理小工具的电子商务公司，但总的来说，我们从事俄罗斯的分销和凉爽品牌的开发。
我们的团队最近才聚集在一起，因此我们仍然没有与公司内部工程师的发展相关的头痛。在加入Madrobots之前，我在外包领域工作了6年，其中有3年直接由代理机构负责生产，我想向您详细介绍这种经验。
在外包中，我们的痛苦是大量的项目和人员流动，在外包中，情况总是如此。我们认为我们需要以某种方式克服这一点，并开始投资于员工发展。
是的，我们有一个评分系统，每六个月有一个人收到技术经理的反馈，并在接下来的六个月与他建立自己的道路。
, . , . , , , .
随后，我们又痛苦了。在经常有很多项目的项目流中，人们失去了对个人发展的关注。这不是因为他们没有足够的时间，而是因为他们对必须完成的任务数量感到厌倦。我们介绍了每月一次的一对一会议的做法，该会议的目的是与一个人交谈并提醒他们您有发展计划，并且确实应该遵守该计划。如果您需要一些时间来解决这个问题，并且应该从例行工作或经常性的异地工作中解放出来，请让我们讨论一下，因为您的检查站正在接近，您需要为此做些事情。有帮助。通常，这是由团队的项目经理完成的，因为谁（如果不是他们的话）会更好地计划未来的资源。
当前开发系统中的挑战
米罗·阿特姆·苏塞科夫（Artem Susekov）。很难立即使评分系统保持平衡，因此我们进行迭代。例如，团队负责人的第一个版本原来是超载的：期望值过高，是一名通用超级战士，这在生活中几乎是不可能的。
我们目前正在尝试简化进入团队领导角色的门槛，以使人们更容易从纯工程分支转换为经理分支。我不想夸大其词，我们需要有能力平稳地进入这一新的活动领域。
另一个困难是该过程过于正式。例如，“我在计划中的10分中有8分，这意味着我达到了预期，可以升至下一个水平。”我们不想将所有这些都变成清单，而只需要关闭清单就可以进入游戏中的下一个级别。
我希望人们能够在计划的基础上思考潜在客户，自己思考他们感兴趣的领域，也就是说，使他们以此为战略而不是正式任务清单。
X5零售集团的Alexander Borisov。人们通常不完全了解如何在公司中成长，因为没有明确的算法。同时，那些真正可以被提升的人会发现自己可以并且应该成长的事物，那些可以自我承担并变得更好的事物。但是碰巧的是，有必要“公正成长”。但是，要像这样在公司中成长可能是不可能的，因为您想要成长。
只有承担更多责任，承担新项目时，您才能成长。
Sergey Averyanov，Funbox。自我们工作多年以来，我们遇到了许多问题和挑战。首先，是要了解我们想与谁合作，我们要发展谁。结果，我们得出的结论是，我们想与知道如何做好某事的人一起工作，而对于什么事情，这并不重要。我们愿意从任何堆栈中聘请准备使用我们所使用的专家。事实证明，这是一种相当成功的做法：培养已经在相关主题领域具有能力的人总是很愉快和方便的。他们所拥有的知识鸿沟不是致命的缺陷，而是一个人的新动力，对新活动领域的研究。
第二个挑战是了解公司工程师的成长方式。为了发展，您需要创造舒适的工作条件：正常的办公室，清晰，简单但严格的程序和工作规定，遵守《劳动法》，不喜欢过度劳累。所有这些使一个人充满信心，他可以轻松地完成工作，而不必着急。他们会告诉他，告诉他，帮助他。
您可以随心所欲地对土豆大喊：“土豆，长大！西红柿，来吧！”-但它们不会因此而长大。他们需要良好的土壤和浇水。
最后的挑战是，并非所有人都希望在我们希望他们成长的地方成长。碰巧一个强大的专家在任何情况下都不想处理行政负担并与年轻同事一起工作。这里的问题不是正式的东西，不是薪水，而是一个人的兴趣和爱好。因此，在所有工程师中，我们都非常重视激情，因为他们具有完成一项复杂任务并从头到尾完成多个步骤的能力。通常，任何能够做到这一点的工程师对我们来说都是有趣而愉快的。但是，正如我说的那样，与此同时，我们总是会留下一个人成为技术专家的机会，而不会陷入行政和管理职能。
Mikhail Mazein，ManyChat...正式确定等级要求非常困难，并且我们也没有尝试严格地将其正式确定下来，而是集中在期望我们在不同开发阶段从工程师那里看到的期望的示例。所有这些都封装在人们对团队或公司级别的流程产生的特定影响中。
这造成了困难。一方面，我们不限制人们的成长，在他们面前出现一块空白的画布，他们可以在上面绘制自己的发展轨迹。但是在一张空白的纸上画一张新图片要比沿着人迹罕至的道路困难得多。我们通过指导解决了这个问题。指导者可以根据人们的需求构建跟踪，并使其与公司需求同步。我们还尝试开发问题搜索的思维方式，以便工程师在过程中发现问题并尝试自行启动解决方案。在这方面，导师再次提供帮助。
MadRobots的Anton Grishin。有些人需要增长，而有些人则因为增长是建立在周围的，为此创造了条件。但是他们都周期性地有一个问题-为什么呢？学习新事物，促进发展的个人动力已经丧失，因为这可能不适用于当前现实或当前同事。
作为解决方案之一，我们举行内部聚会，但不是作为一个业余小组，而是作为内部会议，真正准备了一个新主题。由此产生了一个积极的故事，这些家伙开始相互了解，例如，如果前端可以做一些新的事情，那么我们，设计师和设计师可以重新考虑我们的方法并尝试新的工具。事实证明，彼此的自然动机是尝试一起做一些新的事情。
痛苦总是导致每个人的个性化方法发展自己。
在新团队开始时如何实施发展文化
Sergey Averyanov，FunBox：公司成长的事实帮助了我们。当工程师不多时，他们都在一起做饭，他们彼此了解，并且完成相同类型的任务。而且，一旦不同类型的项目和其中的角色开始衔接起来，所有人就会拥有不同的权力。某人执行任务，某人参与部署，集群，某人参与产品设计。
对于我们而言，重要的是每个团队成员都了解他需要升级的内容，以便从开发人员升级为更高级别的开发人员或团队负责人。
, 125 , , , , .
内部聚会非常有用。当一家公司有许多团队和几种产品时，每个人都用自己的酱汁做饭，在聚会上他们会说，说出自己在做什么很棒的事情，交流知识。这不会在团队之间产生竞争，而是追求卓越。
Artem Susekov，Miro：在团队成长的一个阶段，围绕技术形成的各种行会非常有用：后端，前端，质量保证。在行会中，知识在不同团队之间交换。
内部事件也有帮助：聚会，公开的Sprint评论（团队共享共同情境的人）讨论结果。在这里重要的是要帮助工程师为这种性能做准备。
X5零售集团的Alexander Borisov：您不能希望您会说需要聚会，然后人们开始组织自己。他们也需要处理。就我们的规模而言，挑选出负责组织的负责人是有意义的。团队内部常常有很酷的东西，但是他们自己做饭，只是没有足够的时间来组织聚会和分享他们的最佳实践。看来我们本来应该花半个小时，聚集在会议室里，然后度过，但没有。有一些细微差别。
Mikhail Mazein，ManyChat：针对新人员的结构合理的入职流程使我们能够向他们传达一般性原则和方法，以正确地形成团队和项目的图片。因此，随着新人们的到来，这种文化将得以积累和传承。
关于钱的热门问题
观众提出的问题是： “您并未触及组织的财务状况。如何确定员工在工作时间内读书所需的公司费用份额？第二个例子是一个示例，让一个已经解决了该问题的开发人员花80小时解决问题，而对于不熟悉上下文的开发人员花150小时才能解决相同问题的问题，但与此同时他也会长大并投入工作。问题是，谁来支付70个小时的开发时间差？”
X5零售集团的Alexander Borisov：在我们的情况下，没有客户。我们开始积极组建内部团队，而不是继续外包一些东西，因为我们知道，能力对我们来说非常昂贵，并且会导致最终成本，增加您家附近某个特定Pyaterochka的业务边际性。这是对未来的投资。
但是，如果一个人花了150个小时而不是花三个小时去做一本书，那么问题将仅仅来自产品的所有者或资源池的所有者。如果这是对一个人成长的事实的理解的投资，那么再以这两个人的水平，这很容易解决。例如，在其中的一个sprint计划中，我们放下了一些需要阅读的内容，然后放入其中，这是正常的情况。
米罗（Arto Susekov），米罗：在公司一级达成了一项协议，我们将在工作时间内在课程和讲习班的帮助下帮助工程师进行开发。也就是说，公司为之付出了代价，这是对每个团队成员的投资，因为我们认为这种投资将帮助整个团队在未来更快地行动。
在特定的团队级别上讨论为工程师保留的用于冲刺教育的特定时间。在这里重要的是，在另一个方向上没有扭曲，在冲刺期间，我们一直都只学习并且不做任何其他事情。
Sergey Averyanov，FunBox：我认为，关于80和150小时的问题对于外包来说更为尖锐，您可以问-如果一个经验丰富的开发人员为我做超过80小时的服务，为什么没有经验的开发人员应该为我做150小时的客户服务？我不能说外包如何解决这个问题，因为我们不是外包。在产品公司的框架内，这可以通过以下事实解决：合并预算，并且由于团队成员提高自己的水平，开始更好，更快地工作，因此将开发的人工成本表示为利润。
关于在工作时间阅读书籍。我们的实践是，学习某些东西是解决问题的完全自然的一步。我们不会让开发人员陷入混乱，设置诸如“读一本书”或“研究没有最终目标的技术”之类的任务。一个人坐下来思考不应该这样-我是否已经学习过这项技术，或者我需要学习更多？脱离上下文，脱离目标的任务会导致拖延，导致一个人失去自信，不知道何时该做什么。
研究和阅读文学作品，研究任何事物都应该是任务的一部分，但是应该有一个最终的有形目标可以应用。
MadRobots的安东·格里申（Anton Grishin）：我来自世界，每个小时都有人赚钱，而有人却赔钱。通常，会诚实地告诉客户：“我们不会再从您那里拿钱，但是我们会做更长的时间。”公司，他的雇主，无论如何都要为工程师的发展付费。客户只是稍等一会儿，但是在将来，他了解到现在不是一个，而是两个开发人员从事其产品的开发，一切都更快地解决了，实现的规模正在增加。
在通常建立流程的工作室和代理商中，开发人员永远不会从事客观上不会拉扯他的项目，因为与开发相比，他给公司带来的损失将更大。
X5零售集团的Alexander Borisov：除了在X5上的工作之外，我还有自己的小型外包工作室。我非常了解它的经济。我们设定了80个带薪小时，但我们知道是150个带薪小时数和开发时间，它们经常会有所不同。我们总是拿某种股票，我们只是用自己的钱支付了这笔股票。如果某处发生某种不可抗力，则意味着它是用自己的钱支付的。
Mikhail Mazein，ManyChat：在没有外部客户的情况下进行产品开发，这极大地束缚了我们的双手。通常，我们不跟踪每个人的绩效，而是衡量团队的绩效。
每个团队都有自己的能力和速度，它们可以相差很大，但是总的来说，我们专注于整个团队的整体绩效。对于我们来说，特定工程师在当前sprint中有多少空闲时间对我们而言并不重要，因为这个时间始终用于培训，并且从sprint到sprint，原则上每个工程师都不同。在sprint中的某个地方，前端将有更多的负载，在下一个sprint中，后端将有更多的负载，并且从长远来看，整个过程将会平稳。
如果我们谈论评估每个人的绩效，那么团队本身对此负责，就像一个自我调节的结构。在某些情况下，例如来自此人的指导者的反馈会导致绩效出现问题，或者来自功能社区的同僚反馈。
, ?
, Miro: , , . , , … , .
Sergey Averyanov，FunBox：我认为可能有一些公司专注于固定水平的专家，他们总是拥有相同的工作并且拥有相同的资格，他们不想培养任何人。这可以通过以下事实解决：营业额大，可以长大的员工可以找到新工作。我们要么投资于员工的发展和公司的扩张，要么我们有营业额。
Artiro Susekov，Miro：这已经可以计算出来，如果我们谈论营业额，那么我们将坚持这一指标，如果涉及金钱，对吗？吸引每个新人的成本，招聘人员花了多少时间，我们在招聘上花了多少钱，以及当这个人离开时，我们又花了多少钱，我们再次填补了空缺。所有这些都可以用金钱来计算。
Sergey Averyanov，FunBox：顺便说一句，一个有趣的指标，甚至对自己有用的指标，是公司的工作时间中位数。它使我们能够估计营业额，即在我们的中位数中有多少人工作。当您看到中位数很大并且在这种分布的边缘时，有些人已经工作了八到十年，没有精疲力尽，他们做得很好，每个人都彼此满意，这让我感到高兴。
MadRobots的安东·格里申（Anton Grishin）：在我看来，现在企业无需解释所有这一切，很显然，开发智力产品的人固有地需要自我发展。因此，我什至无法想到需要同级别专家的示例，因为我们所使用的技术决定了我们需要开发的技术。
密山Storozhilov，DevRel局：在我看来，这不仅涉及具有固定性能和固定技术的人员。我认为这个故事也涉及到大量的重构，大量的技术债务。我们与了解开发工程师需求的公司合作，但始终存在合理的教育和开发成本问题。
Sergey Averyanov，FunBox：在这里听起来“重构”一词很有趣。许多人错误地认为，尤其是非技术专家，这是毛衣什么都不花钱的怪异姿态。这里的问题恰恰是在沟通中，也就是说，经理必须了解，今天没有发生的重构是明天增加的开发时间。今天我们将节省一些工时，明天我们将花费它们。
我们已经在内部达成共识，团队负责人有权说完成任务的必要条件是进行重构，没有他，我们会胡说八道，无法合作。
自然，这最终是一个协议问题，但是我们不认为重构是附带活动和浪费资源，而是工作流的一部分。
Artiro Susekov，Miro：如果我们谈论产品开发，那么协议很重要。例如，产品经理根据得分确定优先级，而团队或团队，技术负责人或团队负责人的声音则精确地确定了执行方法。产品说明了现在最重要的事情，工程师说明了我们将如何做。
重构是自然过程。今天的重构将使我们的成本比四分之一的重构便宜得多。这就像贷款一样-如果您不付款，那么下次您必须支付更多。
X5零售集团的亚历山大·鲍里索夫（Alexander Borisov）：有一个术语“技术债务”，在团队与产品之间的交流阶段，我们知道如果我们现在不这样做，那就是技术债务。因此，通过冲刺，技术债务将增加，在六个月内甚至会更多，您将不得不以该百分比支付。实际上，与定期贷款一样，如果您希望更快或更人性地使用产品，则团队会与产品讨价还价。如果速度更快，那么有一天您将不得不支付更多。就像借钱一样。
DevRel-bureau的Mishanya Storozhilov：这笔债务要么变成了“技术抵押”。
我们召集了五名工程师，他们只聊了一个半小时，而且已经开始谈论重构。
* * *该
系列的第二次聚会将于8月20日举行。主题是团队，公司和行业中的毒性。演讲者是来自Miro，SEMrush，Parma TG和Xsolla的工程师和技术主管。
注册已经开放。