Когда работаешь разрабом, все время видишь, как тимлиды сидят на куче созвонов, отвечают за все, пишут столько же кода, сколько и ты, и при этом денег у них не больше. На такое пойдут или идейные, или идиоты.
Я не идиот, мои идеи не крутятся вокруг ценностей бизнеса, поэтому меня на такое не подпишешь. Вот только нас не всегда об этом спрашивают. Сначала меня наняли первым и единственным разрабом в возродившийся стартап, потом сказали нанять ещё людей, а потом я обнаружил, что отвечаю за трех разрабов, двух тестеров и одного аналитика.
Если коротко — все ещё хуже, чем выглядело со стороны.
Шесть человек каждый день ждут, что ты скажешь им что делать, потом скажешь как делать, а потом ещё и оценишь, хорошо ли сделали. Седьмой человек в конце дня ещё и спросит, что сделал ты сам. В смысле, что закодил ты сам, и что сделал каждый из людей, за которых ты отвечаешь.
Я тут как-то жаловался, что созвоны — это костыль, который позволяет управлять не вникая, и сейчас ещё раз убедился, что был прав. Ко мне приходят с вопросом — а я понятия не имею, что отвечать. Мы созваниваемся, и человек выпытывает из моих несчастных мозгов ответ без моего участия. Свои вопросы я тоже не готов формулировать — я понятия не имею, что у них спрашивать. Поэтому я просто звоню, и смотрю, как все разруливается само собой. А ещё лучше — делаю так, чтобы они созвонились друг с другом, вообще без меня. Я уже месяц не могу закрыть достаточно простую задачу, потому что мозг выматывается от управленческих обязанностей, причем больше всего от того, что я не знаю, как их выполнять.
Подумал — ну окей, так оно и должно быть. Я ведь не учился быть менеджером. Тут я посмотрел на свое прошлое, вспомнил всех своих лидов, и вдруг понял — да никто не учился! Никто из них не умел управлять. Они точно так же маскировали это бесконечными созвонами и откладываниями на потом. Они не знали, что мне отвечать, они не знали, куда мы идем, они не знали, что вообще происходит, и кто что делает.
Когда я делал простую таску два месяца, и каждый день врал, что у меня большие сложности, и там серьезная проблема — а потом делал пуллреквест на четыре файлика, набросанных за ночь — меня никто не отчитывал не потому, что жалели. Они просто понятия не имели, что я там делаю. И код мой они смотрели построчно — докопаться до нейминга и найти сочные антипаттерны — но не вникнуть. Потому что вникать некогда, не хочется, и не понятно зачем.
Все мои предыдущие боссы принимали и боготворили аджайл — ведь это один большой набор костылей, игра, которая помогает куче людей, которые понятия не имеют, что происходит, делать вид, что все хорошо и мы идем вперед.
Я работал с доморощенными провинциальными тимлидами, которых в серьезных командах не допустили бы даже до верстки, я работал с крутыми разрабами-менеджерами из топовых заграничных компаний, работал с людьми, которых кто-то считал настоящими гениями в программировании.
И все они, когда дело доходило до управления, садились на жопу. Я понял правила этой игры на своей первой работе с аджайлом. Мы каждое утро созванивались, и все говорили, что они сделали, делают и будут делать. На первый такой созвон я пришел с идеей, что должен отчитаться, и доказать, что не зря ем свой хлеб. Начал длинную, очень длинную речь про свою задачу, в деталях объяснял, почему ещё не готово, и над чем сейчас бьюсь. Меня оборвали на середине: «Фил, от нас что-нибудь надо? Нет? Окей, мы все поняли, кто следующий?».
Человеку, который нами управлял, надо было знать только одно — подкину я ему проблем на сегодня, или нет. Обязан ли он потратить на меня сегодня время. До того, как я начал говорить, у него в голове уже есть идеальная речь для меня: «еверифин гоус акордин ту план». Любое другое развитие событий для него — чистое зло.
Есть другой вариант. Когда проблему ему принес не я, а другие части системы — аджайл график протух, и вот уже он не может на своем митинге для лидов сказать, что все идет по плану — и тоже становится чьей-то проблемой. Это автоматически делает меня его проблемой, и он стучится в личку.
Мы начинаем что-то обсуждать, и оба понимаем — нам нужно найти способ перестать быть проблемами. Это не имеет никакого отношения к продукту или проекту. У нас есть гребаный тикет, который мы должны передвинуть. И мы его двигаем — самым простым из доступных способов. Чиним кодом, закидываем в норепро, ставим лейбл «blocked by» — да что угодно. В этот момент нам совершенно наплевать на продукт, у нас горит тикет. Или много тикетов.
В любой команде, где я работал, было две реальности. Одна реальность — это настоящий продукт, и настоящие люди, которые его улучшают, потому что хотят. А ещё была джира, которая существует абсолютно параллельно всему этому. И единственный человек, который может синхронизировать реальное состояние проекта с карточками — это тимлид.
Все тимлиды, с которыми я работал не знают как это сделать — да и не хотят. Они работают как работают, а джиру используют, чтобы считать свои менеджерские обязанности выполненными. Ведь люди, которые оценивают тимлидов, смотрят в джиру, а не на продукт. А люди, которые смотрят на продукт — могут только генерить новые тикеты для джиры. Оценивать программистов они не могут. Но джира ведь ни на что не влияет! Я видел ужасные продукты, у которых канбан доска была в идеальном состоянии, и отличные продукты, у которых в столбце «at work» по три месяца лежали тикеты с названием «сделать проект».
Аргумент «я видел» не очень то хорош, но он сойдет, потому что, я абсолютно уверен, вы тоже все это видели.
В широком смысле, тимлид должен делать так, чтобы у людей, которые очень хотят работать, не было никаких проблем. А людей, которые не хотят — или выгонять, или переводить в первую категорию. Вся боль менеджмента заключается во вторых — их намного больше. И вот с ними-то никто ничего и не делает. Адекватно определить, хорошо ли работает разраб может только разраб. Это очень понятная история — нужно хорошенько просматривать его пуллреквесты и вникать в его задачи, и тут одна проблема — это жрет столько же времени, сколько стоило бы сделать все самому. Короче, не вариант.
Поэтому определять плохих разработчиков взялись чистые менеджеры — не разработчики. Они напридумывали кучу систем с тикетами, графиками, всякими перфоманс ревью и вот такой шляпой. И это бы даже сработало, на каких-нибудь тупицах. Вот только даже худшие из разрабов достаточно интеллектуальны, чтобы обманывать эту систему. Ну, вы знаете как это делается. Они ведь меряют все в тикетах? Круто. Я декомпозирую «переработать интерфейс формы X» в десять задач в стиле «поправить надпись в кнопке Y». Работы столько же, тикетов больше. Тимлид надавал бы мне по роже за такие финты.
Но в существующей системе он никогда этого не сделает. Ведь во-первых, чем больше тикетов закрыто, тем у него меньше проблем. Во-вторых, он сам достаточно загружен, чтобы вникать в мои тикеты и мой код. В-третьих он и сам так делает — потому что из-за лидских обязанностеей ему тоже не хватает сил хорошо перформить. А в четвертых, и это самое главное — он вполне может сам быть из тех людей, которые не хотят работать.
Это мой опыт, опыт всех моих знакомых — но у него бывают исключения. Есть компании, где процесс разработки реально работает отлично. Я скажу вам почему — они выиграли в лотерею. У них оказалось намного больше людей, которые хотят работать — с такими, как не управляй, все будет идти хорошо. Даже манагерскую мишуру с бордами они используют для дела, а их перформанс и по джировым, и по интуитивным метрикам ясно виден. И когда их менеджеры-не-разрабы приходят мешать им, у них за спиной стоит шикарный продукт, который даёт им право посылать эти говорящие головы к черту.
Такие команды самовоспроизводимы — при процессе найма они интуитивно апрувят только таких же как они, и у них достаточный вес в компании, чтобы не давать решающих слов эйчарам, играющим в свои «метрики» и психологию.
Но такая команда — фантастическая удача. А обычно происходит вот что. На десять человек у тебя два, которые хотят работать. Один из них тимлид, а второй увольняется. Разработка работает плохо, и приходят менеджеры — чинить. И вот с этого момента никаких шансов уже не будет. Менеджеры построят процесс вокруг джиры, возьмутся управлять вещами, которых они совершенно не понимают. Построят найм людей, в работе которых ни черта не смыслят, начнут приглашать туда существующих разрабов, которые потешат ЧСВ, логнут это время в таймрепорте, и дадут рандомный фидбек. А потом решат, кого нанимать — тоже рандомно. Люди, которые хотят работать, будут время от времени попадать в такие команды, где или превратятся в бездельников, или не приживутся.
Я это не к тому, что менеджеры идиоты, и они ничего не умеют. Они ещё как умеют управлять. Но не разрабами. Разрабами может управлять только разраб, который действительно умеет управлять. Такой человек пофиксит команду с любым соотношением желающих и не желающих работать.
Жаль только, что их почти не существует. Чтобы стать неплохим разрабом, надо быть умным, и очень много учиться. Чтобы стать неплохим менеджером, надо иметь талант, и очень много учиться. И какой тогда шанс, что один человек будет сочетать эти два качества? То-то же. При этом большая часть тимлидов в индустрии стали ими, потому что, ну кто-то же должен. Абсолютно случайно.
Я думаю, нужно научится понимать, что разработка — это один скилл, менеджмент — это второй скилл, а управление разработчиками — это третий скилл, включающий части первых. И это надо изучать отдельно. Причем очень методично и качественно. А пока мы этого не сделаем, у нас будут разрабы, которые не умеют управлять разрабами, и менеджеры — которые не умеют управлять разрабами.
На правах рекламы
Многие клиенты уже оценили преимущества эпичных серверов от Вдсины.
Это недорогие VDS с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит реализовать практически любую идею — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Закажите и вы!
