LuckyBerrimor

LuckyBerrimor

Руководитель C-левела в бигтехах Веду канал https://t.me/anotCTO
Пикабушник
Дата рождения: 30 января
106 рейтинг 0 подписчиков 0 подписок 2 поста 0 в горячем
Награды:
Пикабу 17 лет!
6

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

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

Последняя часть плана так и не случилась.

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

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

Вы лучший разработчик. Наши соболезнования

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

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

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

Хорошее знание системы помогает. Только конфликт людей нельзя исправить ещё одним коммитом.

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

А внутри у человека вместо любимой работы — совещания днём и попытки догнать разработку вечером.

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

Проверять нужно не только человека, но и сам выбор

Поэтому я предпочитаю сначала дать попробовать.

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

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

И только после этого — решение о постоянной роли.

Самая важная часть этой схемы не в количестве этапов. А в том, можно ли честно сказать: «Попробовал. Хочу обратно».

Если единственный достойный итог эксперимента — согласиться стать начальником навсегда, никакого эксперимента нет. Есть назначение с отсроченным оформлением.

И это не должно быть двумя работами по цене одной: продолжай выдавать прежний объём кода, а людьми поруководи между делом. Иначе мы проверяем не интерес к профессии, а запас сил.

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

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

А у вас можно отказаться от руководства и остаться уважаемым специалистом — или после этого проще сменить компанию?


Я веду «будни неСТО» — короткие заметки о том, как управлять разработкой и не считать людей приложением к оргсхеме. Для тех, кому сейчас предлагают стать лидом, подготовил семь вопросов перед пробой роли: про полномочия, нагрузку, деньги и возможность вернуться. Памятка — в закрепе канала, её можно взять на разговор со своим руководителем.

будни неСТО — памятка в закрепе

Показать полностью
0

«Потом перепишем»: как временное решение становится вечным

«Сейчас быстро запустим, проверим гипотезу, а потом сделаем нормально».

В разработке это звучит примерно как «я только посмотрю рабочий чат перед сном». Намерения хорошие. Дальше как получится.

Я видел две противоположные истории.

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

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

Со вторым прощаться даже обиднее. Столько сил вложили, так хорошо сделали. Только «нам нравится, как мы это построили» — слабая причина продолжать финансирование.

Из этого легко сделать удобный вывод: пишите как попало, лишь бы продавалось.

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

Быстро — не значит плохо

На старте мы часто ещё не знаем, что именно нужно людям. Сценарии меняются, границы продукта двигаются. Можно полгода идеально проектировать то, что после первого запуска окажется никому не нужно.

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

Но сократить возможности и пожертвовать сохранностью пользовательских данных — совершенно разные способы ускориться. Безопасность и обязательную надёжность фразой «у нас MVP» не отменить.

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

Самое интересное начинается, когда получилось
Гипотеза выстрелила. И вместо обещанного «теперь сделаем нормально» появляются новые задачи: ещё один клиент, ещё одна интеграция, ещё одна возможность заработать.

У каждой понятная польза. А у переделки — расходы прямо сейчас и обещание, что потом станет легче.

На таком фоне временное решение может жить очень долго.

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

И тут бесполезно спорить, красивый код или некрасивый. Полезнее спросить:
— Сколько времени мы тратим на одни и те же поломки?
— Какие продуктовые изменения стало слишком дорого делать?
— Что произойдёт с поддержкой, если продукт вырастет ещё вдвое?

Ответ «зато всё работает» постепенно перестаёт успокаивать.

Переписывание — тоже не индульгенция

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

Иногда достаточно заменить один дорогой в поддержке участок. Иногда — перестать добавлять новые зависимости к старому решению. А иногда действительно нужна серьёзная перестройка.

Мне важно, чтобы мы могли объяснить, что именно покупаем этой работой: меньше аварий, дешевле эксплуатацию, возможность выпускать изменения без недели раскопок. «Будет современный стек» само по себе этого не объясняет.

И это общий выбор продукта и разработки. Не «вы заставили нас торопиться, теперь расплачивайтесь» и не «вы же инженеры, придумайте что-нибудь».

Самая сложная часть — вовремя признать: эксперимент закончился, а мы всё ещё обращаемся с ним как с времянкой.

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

А у вас по какому признаку становится понятно, что «потом перепишем» наконец наступило?


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

Показать полностью
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества