Если хочешь развиваться, нужно уметь смотреть на себя со стороны, чтобы видеть изменения. Мы решили порефлексировать на тему IT-индустрии и попросили помочь в этом Антона Черноусова (golodnyj). А заодно поговорить о технологиях и инженерных практиках, принятых в разных командах.

Сторонний взгляд полезен не только новичкам, но и тем, кто привык работать в одной области или в компаниях с похожими принципами разработки. Даже если следишь за всеми трендами, то видишь в основном истории успеха и начинаешь забывать, что, например, code review не такая универсально полезная практика.

У Антона Черноусова более 15 лет собственного стажа в IT на разных ролях, сейчас он developer advocate в Яндекс.Облаке. Кроме того, Антон аж с 2008 года ведет подкаст «The Art Of Programming» и за 221 выпуск успел поговорить с огромным количеством интересных IT-специалистов из самых разных областей и компаний. Антон знаком с очень разными аспектами разработки и может поделиться рецептами внедрения инженерных практик для широкого круга читателей.



— У тебя большой опыт работы в IT, ты ведешь один из старейших IT-подкастов на русском языке и участвуешь в большом количестве конференций. Кажется, у тебя должно быть ясное и многогранное представление об IT-сфере. Каким ты видишь современный ландшафт индустрии и что думаешь об её эволюции?

Если постоянно следить за происходящим, то может показаться, что мы как индустрия развиваемся поступательно. Но если сейчас оглянуться назад, то окажется, что многое развивается по спирали: появляется технология, через какое-то время она становится мейнстримом, а позже она же повторяется уже на новом витке — пусть и с новыми особенностями, но по большому счету, в основе лежит та же самая идея. Мне кажется, что за последние 15-20 лет таких циклов в разных областях технологий было по 3-4.

Где-то период длиннее, потому что не успевает появиться ничего нового, где-то короче. В бэкенде, мне кажется, длина цикла 5 лет. Сейчас все самое модное-молодежное связано с платформами и discovery service, но мы это всё уже проходили.

В искусственном интеллекте этот цикл сильно длиннее. Достижения, связанные с применением ИИ, по большей части базируются на наработках 70-80-х, если не 60-х годов. Тем не менее, идет постоянно развитие. Я думаю, что самое интересное в этой области произойдет еще лет через 10. Сейчас закладывается фундамент будущих технологий, и те, кто сейчас этим серьезно занимается, возможно, как раз и сделают шаг, который позволит нам выйти на новый уровень.

— А что ты скажешь по поводу однородности или, скорее, неоднородности уровня развития IT-компаний? Например, работая в определенном сегменте или только в крупных и очень продвинутых технологических компаниях, видишь только часть индустрии и может показаться, что есть базовый набор практик, который применяется повсеместно. Что, скорее всего, не так.

Все компании разные. И не только потому, что применяют разные технологии, которые, в свою очередь, определяют методы ведения и организации процессов. Дело в том, что культура основателей очень влияет на состав команды, а люди в команде влияют на то, что и как будет устроено.

Если взять две похожие компании с примерно одинаковым числом сотрудников, то скорее всего они будут работать по-разному именно потому, что базовые подходы и используемые практики чаще всего очень коррелируют с идеями, заложенными основателем. Особенно сильно это заметно в небольших компаниях, различия ощущаются даже на уровне сленга и шуток.

Культура компании определяет и рабочие процессы, и их устройство.

Чем крупнее компания, тем сложнее поддерживать обособленную культуру. Когда основателям удается пронести культурный код через всю организацию, это очень круто. Один из способов поддержания внутренней культуры компании — это подбирать похожих людей. Но иногда, конечно, нужно нанимать людей с другими взглядами и другим опытом, чтобы они принесли в компанию свежие идеи.

С другой стороны, люди регулярно переходят из одной крупной компании в другую. Тогда эта культура понемногу начинает выравниваться.

Небольшие компании в этом смысле чаще монолитны. Поэтому можно выбрать для работы ту, которая будет подходить именно тебе, где будут люди, с которыми тебе приятно работать.

— А сильно ли отличаются компании с точки зрения внедрения инженерных практик? Кажется, что какие-то современные технологии используются просто везде.

Например, я вижу много докладов на наших конференциях, где фигурирует Kubernetes. И начинаю думать, что все, кому надо, уже с ним разобрались и отлично применяют. Потом, конечно, оказывается, что это неправда.

Да, это неправда, и поэтому мы на TechLead Conf попробуем сделать круглый стол по поводу использования Kubernetes.

Надо отметить, что с Kubernetes связан новый способ организации продуктов. Практики, которые вокруг него рождаются, — это новый заход на организацию кода. Они формируют способ разработки в целом.

Kubernetes, а через него микросервисы, а через них способы разворачивания программного продукта определяют то, как ведется вся разработка.

Если мы хотим, чтобы наша команда развивалась, мы вынуждены привносить в неё практики организации работы с кодом, тестирования, деплоя, работы с инцидентами. Воспитание внутри команды этих технологических практик напрямую коррелирует с тем, какие люди у нас в команде.

Если в нашей команде работают люди, которые готовы только кодировать, т.е. заниматься только разработкой функциональности, им будет тяжело примерить на себя эти актуальные практики. Но если все в команде понимают, что цель не просто написать код, а выпустить готовый продукт и донести функциональность до конечного потребителя, а потому готовы расширять свою зону ответственности, тогда они быстро впитают эти практики. Если команда состоявшаяся и в ней налажены процессы, то новый человек, пусть даже с небольшим опытом, но открытым умом, легко им научается.

В этом смысле очень хороши стажировки, которые организуют крупные компании. Это серьезный ресурс для любого техлида, потому что позволяет научить принятым практикам и инструментам с нуля. Переучивать состоявшихся специалистов сложнее. Если разработчик привык делать один вид работы от и до, если его не очень волнует, что происходит после того, как он закоммитил задачу, то изменить его способ мышления будет трудно.

Вызов каждому техлиду — привнести необходимые технологические практики, чтобы команда была достаточно однородная. Однородность позволяет значительно уменьшить риски, связанные с разработкой, отладкой ошибок, проблемами масштабирования и шарингом знаний. Если члены команды обладают всеми необходимыми навыками и инструментарием, то знания между ними передаются легче и легче усваиваются.

— Как тебе кажется, насколько компании преуспевают во внедрении актуальных технологий?

Сложно сказать. На конференциях мы чаще видим истории успеха, а если о проблемах и говорят, то о минорных. К сожалению, успеха достигают единичные продукты, а многие умирают, не успев насытить рынок. Поэтому мы не знаем, сколько инициатив погибло.

Я думаю, 10-15% команд используют хорошие практики, связанные с разработкой.

Причем, в каждой отдельной команде, конечно, будет использоваться разное подмножество этих хороших технологических практик. Набор практик, подходящих конкретной команде, может зависеть от технологических и бизнес-ограничений и от людей, которые работают в команде.

— Какие практики или даже домены инженерных задач сильнее всего отличают технологически продвинутые компании от менее развитых?

Внесем ясность: бездумное внедрение любых практик ведет к массе проблем.

Уровень зрелости команды может быть недостаточен, чтобы внедрять некоторые практики. Может быть очень маленькая, но при этом зрелая с точки зрения внедрения практик команда. А может быть огромная корпорация с большими ресурсами, но незрелой командой, в которой практически ничего не сделаешь. Именно технологической и организационной зрелостью команды надо оперировать, говоря о применимости тех или иных практик.

Во-первых, выделим практики, связанные непосредственно с разработкой. Подходы обеспечения качества кода можно выделить как отдельный домен и внедрять постепенно: некоторые на более ранних стадиях зрелости команды, а некоторые сильно позже.

Например, даже на самых ранних этапах зрелости команды можно внедрить практики написания автоматизированных тестов, которые позволят улучшить качество кода. Покрытие кода тестами — вопрос дискуссионный: от базовой функциональности или критических участков до тотального покрытия кода тестами.

Другая простая практика, которую можно внедрить, — это definition of done. Контроль исполнения постановки задач можно начать с того, чтобы к каждой задаче писать, как её будут принимать. Эта простая практика поможет улучшить наш производственный процесс с самого начала.

Или можно следить за качеством кода, внедряя code review. Это понятная практика, но она может не принести значимой пользы, а накладных расходов при этом будет много.

На самом деле внедрить code review как практику не так просто. Потому что, во-первых, она предполагает другую модель разработки с точки зрения постановки задачи и приемки результата. Раньше было нормально взять достаточно объемную задачу, написать огромный кусок кода и потом его закоммитить. Но для применения code review такой способ разработки не подойдет, потому что большой кусок кода проревьюить невозможно: ревьювер в нём потеряется и потратит слишком много времени.

То есть, чтобы ввести в команде практику code review, нужно по-другому ставить задачи и внедрить практики небольших коммитов. Есть исследование, что оптимальная длина коммита — 100-200 строк. Приучить команду к такому изменению процесса не быстро. Более того, это только организационный вопрос.

Есть еще чисто технический вопрос. Для внедрения code review нужен хороший инструмент, который позволит писать комментарии, делать merge и т.д. Есть инструменты встроенные в среды разработки или в репозиторий кода — их нужно выбрать, начать пользоваться. Это займет время.

Кроме того, нужно решить, кто будет проводить ревью. В развитых командах есть хорошая практика, когда одно ревью делает кто-то из членов команды, а второе — кто-то извне. В крупных компаниях для внешнего ревью время от времени привлекают разработчиков из соседних команд, которые могут высказать какое-то мнение. Двойное ревью существенно усложняет цикл разработки, но зато повышает качество.

Поэтому важно определить стратегию того, как мы ведем разработку. В каждом домене можно выделить начальные практики и постепенно совершенствоваться. При этом собирать метрики о работе команды можно постепенно.

— Метрики — всегда очень дискуссионный вопрос. Нужны ли они и какие именно?

Очевидно, чтобы что-то контролировать, нужно что-то мерить. Если не меряешь — то не контролируешь.

Техлид, чтобы управлять такой сложной машиной как команда людей, должен оперировать набором метрик.

Например, можно собирать такую метрику как lead time — время от появления задачи до её поставки конечному потребителю, включая всё время, пока задача стояла в различных очередях. Это позволяет более качественно планировать работу команды и развитие продукта.

Для одной конкретной задачи эта метрика ничего не дает. Но она позволяет с некоторой вероятностью предсказать, через какое время поступившая задача станет доступна клиентам. Эта метрика уже связана не с самой командой, а с бизнесом, и помогает более аргументированно отвечать бизнесу на вопрос, когда что-то будет доставлено до клиента.

— Мы обсудили часть работы с кодом и практики повышения качества. Расскажи, какие методологии работы с задачами актуальны в технологически продвинутых компаниях и как они эволюционировали?

В какой-то момент времени задачи оценивались исключительно в часах. И вообще заказчики очень любят, чтобы задача была оценена в часах, потому что часы и деньги очень удобно связываются. Но команды начали проходить эту историю по-другому, у некоторых оценка в часах эволюционировала в оценку в условных единицах. Чтобы оценивать то, что одна задача чуть сложнее, чем другая, появилась промежуточная шкала. Потом случился следующий переход, когда начали оценивать задачи, просто раскидывая их по корзинам: сложные, полегче, простые и т.п.

То, какие практики применяют команды, сильно зависит от внешних условий. Например, в аутсорсе это тяжело сделать, а в продуктовой разработке, особенно в стартапах, эту практику внедрить довольно легко. Но это говорит не о зрелости или незрелости команды, а только об условиях, в которых находится команда.

— Применима ли к методологиям цикличность развития, о которой ты говорил?

Нет, я говорил о цикличности с точки зрения технологий, а не практик. Потому что практики на самом деле развиваются, регулярно появляются новые.

Например, раньше не было принято проводить ретроспективы. Этой организационной практики по сути не существовало. Если и был разбор полетов, то это не было регулярной практикой с прописанным сценарием. А сейчас для многих команд это один из естественных и обязательных ритуалов.

Другая практика, которой раньше не было, а теперь она активно используется во многих технологичных командах — постмортемы. Это практика описания инцидента: что произошло, как мы с боролись с инцидентом и что нужно сделать, после того, как преодолели кризисную ситуацию. На сегодняшний момент практика достаточно хорошо развита и есть хорошие паттерны организации постмортемов: как должна быть описана сама ситуация и предпринятые действия, как нужно завершить постмортем, какие дальнейшие действия команда должна предпринять чтобы не допустить подобных инцидентов в будущем (прим. ред.: подробнее можно прочитать, например, в докладе «Аварии помогают учиться»).

Насколько я понимаю, пока не многие команды в России пользуются практикой проведения постмортемов, хотя она позволяет серьезно повлиять на качество продукта и уменьшить риски, связанные с простоями или авариями.

— Какие могут быть критерии выбора подходящих для внедрения практик? Когда стоит пробовать хайповые новинки, а когда лучше дождаться успешного промышленного опыта у других?

В крупных компаниях, где много разных команд и разных технологических проектов, одна из стратегий — это снижение числа различных технологий, которые одновременно применяются внутри компании. Это нужно, чтобы не размывался технологический стек. Но при этом, конечно, нужно пробовать и что-то новое, чтобы не закостенеть и не отстать от прогресса.

Хорошая практика в этом случае — техрадар. Практика ведения техрадара стала популярной с легкой руки Мартина Фаулера и позволяет оценить готовность технологии для применения в новых продуктах. На радар попадают условно перспективные технологии, и мы с его помощью пытаемся понять, насколько они пригодны для применения конкретно в наших условиях.

Внутри команды это может выглядеть так: у техрадара есть один владелец или ответственные за отдельные зоны (фронтенд, бэкенд, хранение данных, облачные технологии и т.д.). Владелец регулярно проводит обзор новых технологий и иногда пытается применить их в некоторых небольших продуктах, именно тогда эти технологии появляются на техрадаре. Если их удалось успешно применить и кажется, что технология подходит для команды, знания распространяются внутри команды, и этот продукт или технология приближается к центру техрадара. Что дает возможность другим командам более серьезно её рассматривать для использования в своих задачах. Когда технология находится в центре техрадара, то её можно и даже нужно использовать для любого проекта внутри команды.

То же самое и с технологиями, которые должны исключаться из оборота компании. Они постепенно отодвигаются дальше от центра радара.

— С позиции практик сильно ли отличаются технологии от инструментов, например, сред разработки и практик и методологий управления? Стоит ли их разделять?

Да, мне кажется, их стоит разделять. Для технологий техрадар — прекрасный инструмент (правда, не стоит забывать, что у него обязательно должен быть владелец).

Что касается инструментов, то здесь, мне кажется, дело обстоит так: если инструмент помогает разработчику делать его работу эффективнее, то задача компании обеспечить им инженера, если это возможно. Например, купить среду разработки, соответствующий инструмент для организации разработки ПО или для хранения артефактов.

А применение практик, как я уж говорил, зависит от зрелости команды. Чем более зрелая команда, тем проще внедрять некоторые практики.

— В другом интервью другой спикер TechLead Conf Дмитрий Масленников высказал такой тезис: если мы знаем, что у других практика сработала, то она точно должна сработать и у нас. Что думаешь по этому поводу?

Я думаю, что разработка в некотором смысле похожа на земледелие: мы выращиваем наш код.

И очень сильно зависит от того, на какой почве мы это делаем. Одной почве нужны одни химикаты и удобрения, а другой — другие. В принципе, можно одним и тем же всё посыпать, но результат будет очень разный. Так же и с практиками: где-то они будут хорошо работать, а где-то не очень. Возможно, именно потому, что уровень зрелости команд разный. Это не зависит от количества людей в команде, скорее от «качества» и культурного бэкграунда.

Например, в командах, привыкших работать в заказной разработке, где все измеряется в часах, очень просто внедряются практики измерения рабочего времени. Но если туда попадет человек, который никогда в этой сфере не работал, то для него это будет ломка. А если человек, привыкший оперировать временем на задачу, окажется в продуктовой разработке, где оценка времени как таковая не очень используется, первое время он будет недоумевать, как потом отчитываться.

Это просто разный майндсет, и поменять его быстро не получится.

Блиц. Кто такой техлид

Закончить хотелось бы небольшим блицом о том, кто такой техлид и где его место в этом великолепии инженерных практик. Когда мы то же самое спрашивали у Программного комитета TechLead Conf, мнения разделились, поэтому интересно узнать, кем ты видишь техлида.

— Техлид — это роль или должность?

Мне кажется, не роль и не должность, а качество человека.

У Фредерика Брукса в книге «Мифический человеко-месяц» есть замечательный пример, как должна быть устроена команда разработки. Он проводит аналогию с хирургической бригадой, в которой есть главный хирург. В нашей ситуации это тот самый техлид, то есть человек, который определяет правила работы и стиль поведения внутри всей команды. Он достаточно авторитетен с технической точки зрения, чтобы к нему прислушивались. И мне кажется, это качество, присущее человеку независимо от того, какую должность он занимает.

— В чем ценность техлида для бизнеса?

Ценность в том, что техлид формирует правила, по которым работает сложная система.

Любая сложная система обычно иерархическая и работает по правилам. Техлид формирует или очень сильно влияет на правила, по которым она работает. Чем эффективнее работает система, тем больше прибыли получается.

— Как коррелирует наличие техлида в команде и его успешность и качество конечного продукта?

Для того чтобы продукт состоялся, нужно выполнение нескольких условий: востребованность на рынке, достаточное количество ресурсов для реализации продукта и собственно качественная реализация.

На востребованность техлид никак повлиять не может, здесь сильна роль продактов. На ресурсы техлид влияет косвенно, например, через найм подходящих людей. Наиболее значительна его роль как человека, формирующего правила, по которым реализуется продукт. Задача техлида в том, чтобы продукт создавался качественно. В итоге продукт все равно может иметь какие-то проблемы, связанные с бизнес-функциональностью или несоответствием рынку, — но это не зона ответственности техлида.

При наличии необходимых ресурсов и потребности на рынке техлид может существенно повлиять на качество продукта.

— Что должен уметь техлид, должен ли он работать руками?

Техлид прежде всего хорошо и глубоко разбирается в технологиях, умеет разобраться в новых технологиях и применить навыки, полученные в одних технологиях, при работе с другими технологиями.

Кроме того, техлид должен влиять на планирование с точки зрения тех самых метрик, которые он собирает в рамках технологического процесса.

И на мой взгляд, он должен работать руками. Иначе он просто перестанет понимать и технологии, и их ограничения.

— Должен ли техлид быть самым крутым специалистом в команде?

Не обязательно. Самый классный эксперт языка в команде может не обладать лидерскими качествами. А для техлида лидерские качества важны.

— Техлид — это уровень компании или команды?

Это один из неформальных лидеров внутри команды.

— Может быть несколько техлидов в команде?

Конечно. Например, техлид бэкенда и техлид фронтенда, потому что это очень разные технологические стеки.

— Это нормально, если в команде нет техлида?

Нормально, если есть кто-то, кто приглядывает снаружи, и кто-то, кто выращивает внутри команды следующего техлида. То есть человек с потенциалом техлида все-таки должен быть.

Без техлида система перестанет быть устойчивой.

— Чем техлид отличается от senior-инженера?

Это не обязательно один и тот же человек. Потому что senior — это человек, который может сделать продукт от начала до конца и обладает всеми необходимыми техническими компетенциями. Но, возможно, не обладает лидерскими качествами по организации процесса. Он может быть прекрасным бойцом и отлично делать свою работу, он даже может быть ментором или реализовывать отдельные самостоятельные проекты, но, например, влияние на всю разработку целиком может быть вне зоны его комфорта.

— Чем техлид отличается от тимлида?

Тимлид направлен на то, чтобы выращивать людей, а техлид — процессы внутри команды.

Один человек может совмещать оба направления, но как правило есть перекос в одну сторону.

— Техлид и СТО — разный уровень?

Кажется, техлид — это маленький СТО. Хотя СТО гораздо больше думает о бизнесе и больше погружен в бизнес-составляющую команды. СТО должен думать и о зарплатах, и о стоимости владения кодом, и о накладных расходах. Но по технологической составляющей СТО и техлид очень похожи и сильно пересекаются. Из этих людей, мне кажется, как раз и должны вырастать хорошие СТО.

— Как стать таким человеком?

Однажды журналист спросил Нобелевского лауреата, как стать Нобелевским лауреатом. Ответ был такой: «Для начала нужно поучиться у Нобелевского лауреата». Мне кажется, с техлидами та же самая история.

На конференции TechLead Conf, которая пройдет 8–10 июня, Антон Черноусов проведет круглый стол «Как выкатить легаси-проект в Kubernetes и не поседеть». Это будет взгляд с разных сторон на очень актуальную технологическую задачу.

Переезд инфраструктуры на другие производственные мощности, например, из своего дата-центра в облачный — одна из тех сложных ситуаций, которые переживают команды и продукты. Она особенно сложна для легаси-проектов. Детали такого переезда и трудности, с которыми может столкнуться команда и проект, мы обсудим на нашем круглом столе. Разработчики облаков и платформ, представители DevOps-компаний и инженеры обсудят вопросы миграции в облако, использование Kubernetes и проблемы команд, работающих с легаси-продуктами.

Присоединяйтесь! Онлайн, из любой точки мира. Расписание специально достаточно разреженное, чтобы вы послушали доклады, приняли участие в дискуссиях, понетворкались и при этом не пропустили рабочие дедлайны.