技术抵押:团队应承担的责任和义务

大家好! 我叫Alexander Afenov。 我是Lamoda Order Processing团队的团队负责人。 去年,我在TeamLead Conf 2018上发表了演讲。

在我的报告中,我将讲述我如何成为团队负责人,遇到的问题的故事,并且我将分享您可能个人熟悉的各种策略。 但是,我主要关注他们在综合大楼中获得了什么样的利润。

图片

该报告将分为三个部分:

  1. 在第一部分中,我们将简要介绍一下公司及其IT功能。 为了理解发生一切的上下文,这是必需的。
  2. 在第二篇中,我将讨论我在公司的发展道路。
  3. 第三部分-关于使用的方法,其优缺点。


Lamoda作为一家IT公司


拉莫达(Lamoda)主要是俄罗斯和独联体地区主要的流行服装,鞋子和配饰零售商。 但是,很少有人知道我们以一定百分比或固定金额为不同的企业/法人实体提供服务。

让我给你一个很好的例子。 假设您有一个用于缝制钱包的地下室。 您已经为您的产品创建了一个网站并成功地对其进行了推广。 现在,许多人都知道您,但是尽管如此,您在交付,存储和与客户沟通方面仍然遇到问题。

Lamoda可以通过以下方式解决这些问题:

  1. 提供您的送货服务。

    LM Express是我们自己的交付服务,长期以来,我们一直在自行开发和实现自动化。
  2. 提供与客户的沟通。 为此,我们有自己的呼叫中心。
  3. 将商品放在家里,甚至卖给您(佣金)。
  4. 市场。 合作伙伴的产品可以显示在我们的移动应用程序,网站或移动版本中,其余的由合作伙伴自己完成。

问题出现了:“您如何设法解决问题并满足合作伙伴的需求?” 我们根据自己的需求进行不断变化和发展的业务。 我们以某种方式改进,发展和前进。 同时,您仍然需要匹配来自外部的那些心愿单。 看来这需要自己的IT,而不是很小的IT。

自2016年以来,我们在所有会议上都在谈论内部开发。 我们自己使所有过程自动化。 这大约有一百种不同的服务:从处理订单和付款到处理地址对象和礼品券。 支持这一切的团队大约有300人。

我为什么要谈论我们的IT及其范围? 因为300人是很多团队。 当一些团队在单个技术堆栈上工作时,我们尝试重用所有这些开发。 它可以是捆绑软件,库,技术领域的实践。 但是,我们也试图挫败团队负责人之间成功的流程实践,我将在稍后讨论。

关键问题


我于2015年加入公司。 受雇三天后,我安排了一个新年公司聚会,但我决定不参加。 我的首要任务是在试用期内留下并考虑我的任务。

拉莫达的公司活动是每个人都喜欢准备的主题假期。 因此,在第十天,我部门的建筑师穿着大衣来到游行队伍里工作。 当时,我们的团队从事订单处理服务。 它是旧的Zend1框架的巨石。 我观察到了什么? 伙计们准备了一个强制释放并想解决一些问题。 确保一切正常后,我们收拾行装去度假。

我坐在这里。 该版本带有修复程序投入生产,在我眼前是一台漂亮的50英寸电视,上面装有某种仪表板。 仪表板上有一个图形,上面显示“兔子MQ问题”。 看来,如果上面有任何数据,则说明已损坏。 但是我不知道该去哪里检验这个假设。

您可能可以查看某种日志。 但是,我只是工作的第三天,不知道他们在哪里。 我想我可以找到grafana板的链接。 也许值得仔细研究一下指标的来源并在那里进行挖掘? 是的,但是太坎bump了。 我希望以某种方式对此进行记录。 再有一个问题是:这些坐在那里的人都是谁? 分布IT的两层或三层。 每个人都在做某事,如果发生问题,我不知道该与谁交流。 如果我意识到发行版已损坏,则没有任何数据透视表可以与谁联系。 或者也许有人值班,但我只是不知道?
*(他当然是)*

还有其他问题。 第一个也是最荒谬的一个,我们将反复返回:“文档在哪里?”。 答案很简单:在经验丰富的员工的任何地方,任何地方和头脑中同时进行。 既然每个人都去参加公司聚会,但是我不知道码头在哪里,答案对我来说听起来“无处可走”。 我有一个自述文件,可以在笔记本电脑上部署该项目。 但这还不够。 我想获得其他许多问题的答案。 例如,开发人员的基本“行为”规则是什么?

让我解释一下:我决定请求访问战斗系统以进入用户界面。 这对我来说非常有用,因为在试用期内,我的任务是重新制作授权系统,并且我想拨动按钮,登录到生产摊位。 我向安全部门提出了要求,我很快收到一个简短的答复:“不,我们不会提供访问权限。” 事实证明,只有真正的用户才能使用战斗系统:仓库工作人员,呼叫中心等。 由于我以前在电信部门工作过,所以我习惯了对各种移动运营商的生产基地进行读写访问的事实。 事实证明,这是不可能的。 有一个协议。

另外,我遇​​到了团队负责人告诉我的许多其他条件和限制。 在早期,他让我专注于许多不同的迷人时刻。 这些信息太多,以至于无法记住和写下所有内容。

以下是我感兴趣的问题,涉及长期的观点。 例如,如何以及在哪里增长?

为什么这很重要? 因为从一开始我就需要以某种方式表现。 我来到中级PHP开发人员的位置。 接下来我该怎么做才能超出预期,并在将来获得更高的成绩,例如高级? 还有一个问题:“我对目前的成绩有什么期望?” 也就是说,我应该在代码审查,发布,职责等过程中参与多少?

我现在列出的所有问题均已由我们的团队负责人回答。 最后两个更具战略意义的问题通过绩效评估系统得到了回答。 我会告诉你更多。

绩效考核


一个人每六个月进行一次所谓的自我检查。 他谈论了他在指定时间内设法做的很酷的事情。 但是,有一个陷阱。 这与以下事实有关:人们通常在自我评估时指出这些成就,而他们在主观上倾向于将其视为。 关于业务的思考是不寻常的,即使常规项目使公司赚了很多钱,对于开发人员来说,他可能也不是挑战或兴趣。 有这样的危险,在这样的审查中将不会显示该项目。

下一步是同行评审。 随后是一系列委员会,团队负责人,部门经理,服务站以及人力资源总监(如有必要)之间进行沟通。 然后是关于结果的消息。

有什么可能的结果?

第一种选择:一个人设法在六个月内变得比开始工作前更糟。 似乎该说再见了。 这种情况极少发生,但是我们会现实的-它确实发生了。

另一种选择是平局。 似乎缺少了一些东西。 可能会有速度,可预测性和毅力。 有待改进。

三-他们所期望的,他们做到了。 一个人以适当的速度工作,并且在各个方面都与他的等级相对应。

四-超出了预期。 晋升/薪水的候选人。

五只毛狼。 似乎是时候筹集资金,发放奖金等等了。

我本人经历了几次这样的评论。 以前,它每季度举行一次,这不是很方便,因为三个月以来并不总是有机会证明自己。 现在,每六个月进行一次审核。

因此,起初我是从高级开发人员那里长大的。 然后,我的团队负责人决定,现在他想更多地从事技术工作,并转到技术团队(架构师)的职位,我成为了团队负责人。

那接下来呢? 我需要做一些事情,以某种方式掌握。

您遇到的第一件事是我们之前谈到的相同问题,只是现在略有不同。 也就是说,目前还不清楚:该文档在哪里? 现在,我需要以某种方式与其他部门进行沟通,与其他主管,架构师和其他人进行沟通,在更高层次上进行思考。 但是在这种文档级别上,可能两者都不是。

另一点是相同的“基本规则”。 我该怎么办

我想我可以跟进任务,进行代码审查。 也许我现在有能力更改流程,以某种方式与人沟通。

如何以及在哪里增长? 这个问题不会消失,因为那样的话您可能想成为部门主管(小组负责人)。

好了,问题-对我的期望,在我看来也很容易理解。

现在,您不仅需要回答自己所有的问题,还需要回答整个团队的问题。 就我而言,该团队几乎是从头开始招募的。 事实证明,对于五个或七个人,我必须说出一切,解释,设定目标。 这需要时间和精力。 这些事情需要计划和考虑。 那么,组长的职责是什么?

团队应该领导什么?


首先,它是与任务一起工作的任务的制定,调整,对年级下接受任务的人的描述。 例如,对于大三学生,我希望做一个非常详细的描述,并希望他写正确的代码和测试。 作为高年级学生,我将传达技术或业务目标,他将自由决定如何实现该目标。 无论如何,这一切都需要时间。

当然,当过程中发生冲突时,您需要进行代码审查 。 监视正在发生的事情,按状态移动任务。 我还定期执行发布工程师的职责。 您需要经常考虑我们的部署如何影响其他所有人,我要做的服务是订单处理。 它与几乎所有Lamoda系统相关联,因此能够在其发行期间影响许多业务流程。

另一点是与此相关的监视,警报和转变 。 如果出现了业务功能,则有必要对其进行监视,引入新的指标,挂断通知,通知支持服务等等。 这些都是架构问题。 我的部门目前没有专门的建筑师。 当您在特定任务/项目的框架内需要某些特定解决方案时,我会执行他的职责。

仍然需要注意沟通 。 这包括大约每两周与每个开发人员举行一次个人会议; 回顾,计划,与经理和其他部门的沟通。 但是仍然最好不要犯规。

许多人说,经过10年的发展,将“管理与发展”的比率提高到80到20左右将是一件很不错的事情。 结果,您将不可避免地失去专业知识并脱离当前趋势。 有必要继续进一步增长。

有一些策略可以提高您的职位。 在下一节中,我们将讨论团队中的角色轮换如何帮助增加总线系数。

角色轮换


我将与那些不认识的人取得联系,并告诉您公交的因素是什么。

总线系数是一个数字,表示如果一定数量的开发人员“敲门”,那么该项目的工作将停止。 它可以在各种级别上体现出来。 例如,对于某些特定的复杂系统元素,它可能是总线因素。

假设有一种情况,我们需要整理某种报告系统。 开发人员花了5天的时间完成此操作。 该错误很复杂,但已修复,一切都很好。 然后,在同一模块中出现另一个问题,同一开发人员发现自己请病假。 这意味着下一个人应该花相同的时间来解决问题。 您必须从头弄清楚,因为没有文档(哈哈)。

将进一步讨论的恰恰是增加总线系数的策略。 他们将以一张令人愉快的画面汇聚在一起,与团队负责人的所有先前职责相关,我刚才谈到了这些职责。

除了文档,还需要实际经验。 也就是说,您需要一个已经设法接触系统不同部分并且现在准备应付任何任务的团队。 但是,如果团队只是团结在一起,那么所有这一切都不会从无到有。 我的主要目标是告诉我们如何组合几种不同的方法,以解决文档和经验上的问题。

支援工程师


每个人都听说过虚拟开发人员。 但是,我们不会谈论VR-kit,也不会谈论远程站点上的人员,而是谈论支持工程师的角色。

谁是支持工程师?

我们有一个解析支持积压工作的人。 他来上班,他没有一项任务。 他在任务跟踪器(Jira)中打开了待办事项以提供支持,并且在那里按重要性对任务进行了排序。 他采取了最重要的措施,并开始进行维修。 在解决所有问题之后,他写下了为什么会损坏以及将来如何避免它。 如果他没有其他支持(这很有趣,因为支持永无止境),那么他将查看技术积压案,该积压案已经很大。

有点分散注意力:我们正在谈论的是在旧的Zend 1框架上有一个十五万行的系统。 以前的团队架构师曾经说过,根据我们的系统,我们有这么大的债务-这不是技术债务,而是技术抵押。 因此,报告的标题。

如果无事可做,支持工程师可以从那里执行一些非优先级的任务,这很可惜退出并返回到新出现的支持。 这通常会发生。 而且他不这样做超过一个星期,因为这将是挫败的直接途径。 如果在整个两周的迭代过程中,您仅提供耙支持,那么这将极大地激励您。 您修理,修理,修理,而且没有止境。 因此,我们每周都会将支持工程师的角色移交给下一个人。

发布工程师


还有一个虚拟位置对于卸载团队主管非常方便-这是发布工程师。 他为预定的修订版本准备发行版,收集分支,准备构建,运行所有测试。 如果测试自动运行,则仅控制结果。 在他的职责范围内,为依赖我们的系统选择无中断停机和特殊效果的滚动效果如何。

碰巧我们需要在部署之前与其他团队进行沟通,以警告他们更改。 结果,发布工程师推出了所有内容,并查看是否发生了破裂。 为此, SentryPrometheusIcinga使用Kibana来查看Elastic 。 发布工程师决定出现问题时应采取的措施。 也就是说,决定是否需要某种修补程序是他的责任,还是我们都破产了,亏了钱,需要做回滚。 回滚的决定仅是在万不得已的情况下做出的,但这也发生了。

他(发布工程师)记录了出现的问题。 如果有什么破烂,那将是您从错误中学习的好方法。 为此,他指出了发布日期和导致问题的错误。 这使下一版本的工程师可以查看常见问题并避免它们。 是的,是的,他连续一周没有这样做,因为收集发行版很昂贵。

如果发布的内容很大,那么半天就很容易消失,很难及时地切换到您的任务上。 例如,您开始了一些组装,该组装需要20分钟。 在组装过程中,您可以抽烟或思考生活。 但是,如果您返回任务,并且组装成功,则需要再次切换。 通常,这是一个沉闷的过程,退出了正常的发展并且不允许进入潮流。 因此,发布工程师在下个星期是另一个人。

特赫利德


另一个更有趣的虚拟职位是技术主管。

当完成一项重要的重要任务或启动一个新项目时,架构师(有时称为这种方式)会加入竞争。 这意味着他负责设计,开发和发布。 他被赋予与团队负责人和团队经理沟通,制定技术决定的权利,并记录这些决定的义务。 如果一开始就发生垃圾,它将以与发布工程师或支持工程师相同的方式记录所有已发生的问题及其原因。

结论


结果是什么?

长时间(至少六个月)的团队轮换使得即使是没有经验的大三学生也可以掌握处理系统的各个部分和任务类型的技能。

在开始时,我谈到了文档和实际经验可以帮助解决典型问题的事实。 应用上述方法后,并不是解决文档问题的事实,而是开发团队的所有参与者都将获得高质量和多样化的经验。在虚拟角色的长期轮换中,一个人可以作为支持工程师来接触系统的各个部分。 作为发布工程师,他学会快速部署,沟通,观察和决策。 如果他担任技术专家,那么他正准备独立推动更大,更重要的项目。

从这一刻起,团队负责人可以并且应该将他的任务委托给下属,因为,如果您还记得的话,团队负责人的任务是不要表现出自己的个性并在某个地方成长。

由于这样的做法,最终可以使某人的工作成为一部分。 例如,发布。 这是每周4-8个小时,不时突然释放。 现在,您可以将它们用于开发,阅读文章或解决其他问题。 一个很大的错误就是不要在日历上嗡嗡作响,而将其花费在不太有用的会议上。 尽管通常会发生这种情况:)现在,团队领导者可以感到高兴,因为他有机会减轻紧张感并将工作的一部分信任员工。 如果他发生了任何事情,项目将无法启动。

结果,我们增加了团队领导的巴士系数。 反过来,团队可以确定,如果团队负责人出了什么问题,那么他们中的任何一个都将准备好进行工作并加以处理。

当然有局限性。 如果您独自一人做所有事情(人事部门),则不可能采用这种方法。 , . — .

5 , . , . , .

– . , , , . , . . , - “” , - . , , , , . , . , .

, : « , , , ” . , , , . . , . - .

Source: https://habr.com/ru/post/zh-CN448278/


All Articles