И так, вот команда растёт, растёт и дорастает хотя бы до 15+ человек. В этот момент вы неожиданно понимаете, что у вас 3 бекенд-разработчика или даже 5. Здесь возникает неудержимое желание сделать одного из них Самым-Главным-Бекенд-Разработчиком-Проекта. Это желание понятно, и даже логично:
Человек уже погружен в предметную область проекта.
Доказал способность реализовывать задачи.
У него высокий уровень лояльности к проекту и возможно к вам лично.
Кто-то должен заниматься процессами на бекенде. Ну там gitflow внедрить или merge-request’ы. А может даже какой-нибудь CodeStyle выбрать и ему следовать. Ну и в конце концов кто-то должен ответить однозначно на вечный вопрос: Laravel, Yii или всё-таки перейдем на Python?
Эту роль на самом деле часто выполняет технический директор. Но вопрос в количестве – при росте количества проектов и программистов, техдир уже не сможет нести ответственность за конкретные технологические решения в каждом проекте.
На всякий случай небольшой дисклеймер: история с бэкендерами рассматривается сугубо, как пример повышения линейного работника до руководителя и не является рекомендацией к способу организации команд. В целом я считаю, что всё что написано ниже можно отнести к любому случаю повышение до руководителя, вне зависимости от профессии и сферы.
И так, по причинам выше вы решили не звать “варяга”, а сделать программиста Петю руководителем. И он даже согласен и уже строит планы по внедрению SOLID всем, и чтобы никто не ушел обиженным.
Но вас на этом замечательном пути к прекрасной архитектуре с нулём legacy ждёт ряд препятствий. И это, даже не считая недостижимости нуля legacy на живом проекте :)
На самом деле большинство препятствий обусловлены одним простым фактом — когда Петя становится руководителем - у него меняется конечный продукт. О конечном продукте рассказал здесь — тема, конечно, не такая интересная, но методологически очень важная.
Если проще — вчера Петя отвечал за то, чтобы качественно выдать свои задачи в срок, а сегодня он отвечает за то, чтобы это делал весь отдел. И давайте вместе угадаем какой самый простой способ этого добиться в глазах вчерашнего, возможно весьма достойного, разработчика? Конечно, сделать все задачи самому! Ну или в крайнем случае — сделать самому всё самое сложное.
Самое плохое, что Петя не осознаёт смены конечного продукта. Для него ситуация выглядит просто — эти товарищи работают хуже, а я - человек ответственный, всё сделаю. О, ещё и зарплату повысили, да сверхурочные платят — фантастика просто. Я тут теперь не просто самый умный, а самый умный за деньги. Петя, конечно, ноет, но по большому счёту Петя чувствует себя комфортно. Более того, если Петя пробудет в этой ситуации пару месяцев — вытащить его уже не получиться, он будет отбиваться руками и ногами. С другой стороны, Пете хорошо, а кому плохо? Начнём перечислять :)
1. Бизнесу
Дисклеймер: Напоминаю, я пишу про малый и средний бизнес, находящийся в реальных рыночных условиях. Когда такой бизнес растет, это всегда связано с большим количеством проблем и задач. Поэтому вещи, который кажутся очевидными в структурно изложенном тексте, в реальной жизни, могут быть совершенно непонятны. Они ловко прячутся за бесконечной борьбой с кассовыми разрывами и срывами сроков.
Я знаю несколько ситуаций, когда заставить много работать такого Петю, дав ему должность — было хитрым планом начальства. Ничего не скажу о мозге таких товарищей — просто о мертвом либо хорошо, либо никак. Но это хороший управленческий пример “выстрела себе в ногу”, потому что:
а) Петя становится незаменимым — любая болезнь, отпуск, что угодно, что мешает Пете работать менее 10 часов в день приводит к срывам сроков.
б) Петя теряет требовательность к своей работе — ошибки будут объяснены 10 часовым рабочим графиком (что, кстати, справедливо).
в) Петя становится не предсказуемым, по факту вы не знаете — будут ли задачи сделаны и если сделаны — то, когда?
Итого — мы очень быстро получаем незаменимого и непредсказуемого халтурщика, вместо ценного специалиста. И это я ещё не говорю о полной невозможности к масштабированию. Внимание, господа руководители! Это происходит не потому, что Петя плохой! Любой человек поставленный в ситуацию, когда он вынужден работать по 10 часов в день станет таким. Так что, если вы это сделали не специально, а просто не осознавали, как смена конечного продукта влияет на специалиста — срочно исправляйте. А если сделали специально, потому что вам так сиюминутно выгодно — горите в аду.
2. Коллегам
Беря на себя все самые сложные и интересные задачи — Петя забирает у коллег ценный опыт. В результате люди, которые оказались под его началом имеют только две возможности:
Имитировать бурную деятельность за деньги, когда реальную нагрузку на себе несёт Петя.
Менять работу.
Напоминаю, что мы с вами не в линейной RPG, где этот выбор вам дадут в качестве ветки диалога. Это жизнь. Люди, которые находятся в этой ситуации не осознают её. Петя крутой? Крутой. Начальник? Начальник. Логично что он делает больше меня? Логично. Вопрос только в том, что так на рынке появляются “сеньоры” с 10 летним стажем, не способные связать двух строчек кода во вменяемый результат. И абсолютно не осознают, что есть какая-то проблема. На прошлой работе нормально всё было. У нас один товарищ так и не понял, зачем в высоко нагруженном проекте 2 базы данных. Ну ничего, рынок IT сейчас дикий, даже такие работу находят :) Но хотите ли вы быть таким?
3. Лично Пете
Работать по 10 часов в день может казаться классно примерно лет до 27.
А потом ты:
Полностью выгорел.
Вместо приобретения полезных навыков решал собственные косяки (и иногда своих лоботрясов).
Скорее всего имеешь нормальные такие проблемы со здоровьем.
Можешь работать только в конкретных, созданных специально для тебя условиях.
В общем по факту - позитивный эффект от такой ситуации только краткосрочный. В итоге, проигрывают все. Хотя я знаю конторы, где такая ситуация тянется десятилетиями. Но там это просто медленное загнивание и жизнь на проедание когда-то заработанных связей, сделок, продуктов и т.д.
Как сделать правильно?
Приготовьтесь — если вы делаете хорошего линейного специалиста руководителем — придётся много с ним работать и проходить определенные стадии. Пройдемся по ним.
Стадия объяснения
На этой стадии Пётр ещё толком не понимает, что с ним произошло. И вам необходимо объяснить ему как минимум четыре вещи.
Ожидания от него изменились. Теперь вы ждёте того, чтобы все остальные товарищи на проекте будут работать также хорошо, как и он. И что самое важное — готовы к падению ЕГО персональной эффективности. Потому что Пете теперь от 30 до 70 процентов времени надо будет уделять руководству. И это нормально. Под “готовы к падению его личной эффективности” - я имею в виду, что вы пересмотрите сроки выполняемых Петей задач, с учётом новых реалий. А вы как хотели? Только так :)
Не только программирование является работой. При том говорить это придется не один раз. Петра очень и очень долго будут преследовать флэшбеки по этому поводу. Вы вполне можете застать его очень грустным после вполне удачного релиза. На вопрос, чё он такой грустный Пётр ответит: “А чё я сегодня делал то? Ну там с тем поговорил, ну с этим. Ну постоял над душой пока ветку в прод толкали. Но я же не работал.” И не важно, что Пётр случайно выстроил всю коммуникацию между аналитиками, тестерами и бекендерами. Если он сам не кодил — значил не работал.
Уровень конкретности задач стал ниже, и Петя — именно тот человек, кто должен их сделать более конкретными для своих ребят.
Петя отвечает не только за то, как работают его ребята, но и за то, как он взаимодействует с другими. К примеру, как передаются задачи фронтендерам, или как должна приходить аналитика.
Стадия договоренности
Окей, Пётр понимает, что он теперь руководитель и занимается своей командой. Теперь вам очень важно договорится с ним о том, чего вы конкретно хотите от Пети. А то может выясниться, что переход на Python будет затеян в самый неподходящий момент. Для того чтобы договорится вам надо сделать несколько “простых” действий:
Расскажите о проблемах, которые вы хотите, чтобы Пётр решил. Чем конкретнее вы сможете их сформулировать, тем лучше. Ну там чтобы релизы не задерживались, или нулевой даунтайм на продакшене, или чтоб багов было поменьше. Даже если у вас есть технические компетенции, старайтесь говорить именно о проблемах, а не предлагать сразу решение. Но и диалог в угадайку не превращайте :)
Поставьте сроки. Только, пожалуйста, не волюнтаристским образом, а исходя из бизнес-задач.
Спросите, что Пете необходимо чтобы всего этого добиться. Начиная от полномочий, до ресурсов. Не пропускайте этот пункт! Сам он скорее всего вам не скажет и в конце выяснится, что надо было нанять ещё двух бэков, но он не знал, что так можно.
Подкорректируйте свои желания исходя из Петиных возможностей и тех ресурсов которые вы можете ему предоставить.
Поздравляю, вы договорились!
Стадия выполнения
На этой стадии главное помнить — ничего и никогда не идет ровно так, как задумывалось. Особенно когда у Пети нет опыта. Поэтому сделайте самое главное: помогите Петру с собственным рабочим графиком. Он как “играющий тренер” всё время будет выглядеть примерно так:
Надо объяснить, что чем больше Петр уделяет внимание подготовке задач и организации работ — тем меньше его будут неконтролируемо дергать. То есть, если:
Подробности технических решений оговариваются во время постановки задач.
Налажена нормальная схема поставки кода (нормальной считается любая, хоть git pull на продакшене прямо из репозитория /*черт, даже писать больно*/, которая объяснена людям и отработана с ними).
Договорено как должны приходить задачи бэкендерам и в каком виде они должны уходить (ну там описание API, и прочее).
Технические и архитектурные решения регулярно обсуждаются с командой и подробно разбираются.
Налажен перекрестный CodeReview.
И всё что угодно, что вам ещё нужно сделать для простого программерского счастья.
При таком подходе работу руководителя можно свести к 30 процентам своего времени. А вот если Пётр как руководитель сделает следующие:
Любой push в любую ветку строго через Merge Request, который принимает лично Пётр. (Петя ответственно относится к качеству, поэтому строго всё контролирует!)
По любому вопросу надо подходить к Пете. Если бэку что-то непонятно в аналитике — сначала к Пете. И наоборот. Если аналитику нужно что-то объяснить - он объясняет Петру и никому другому. (Петя понимает важность коммуникаций, поэтому не доверят их подчиненным)
Все самые сложные вещи делает только Петя. (Потому что Петя лучше всех знает систему. Неудивительно — смотрите пункты выше)
При таких раскладах работа руководителя будет занимать 70% рабочего дня. И еще 70% работа программиста сверху :)
Также сильно рекомендую на этой стадии регулярно встречаться с Петей и корректировать цели или ресурсы.
Стадия ретро
Ну собственно про эту стадию даже писать как-то неловко — уж сильно она очевидная. Но и не написать нельзя! Напоминаю, на Стадии договоренности вы должны были обсудить четкие цели и сроки. Вот по результату — обязательно надо встречаться и по сути проводить классическую ретроспективу. Что получилось, что не получилось и почему. Ещё неплохо бы, если Петя реально сильно повысил производительность (не разово, а принципиально) по результатам такой ретро поднимать ему зарплату. Тогда вы с Петей будете жить долго и счастливо.
Собственно цикл повторять до …
Наступление прекрасного момента
Когда Пётр станет полноценным руководителем, и вы поймете, что уже не сами ставите ему цели, а рассеяно киваете на предложения, потому что уверены, что он лучше вас разбирается во вверенном ему участке работ.
Ради этого прекрасного мига все и затевается. До его чудесного наступления нужен примерно год. Поэтому крепитесь и:
Объясните человеку, что вы от него хотите и в какой срок.
Дайте человеку необходимые ресурсы и полномочия.
Сбейте свои желания с возможностями :)
Регулярно общайтесь и корректируйте цели и ресурсы.
Вместе анализируйте результаты деятельности.
Повышайте заработную плату, по достижению видимого результата.
И тогда у вас появится надежный понимающий человек, которому вы можете доверять. Это бесценно :)
Всем добра!
