- PVSM.RU - https://www.pvsm.ru -
Тимлид в стартапе — разом и Илон Маск, и Франкенштейн. Утром конструирует космические корабли, а к вечеру обращает к проекту крик: «Живи! Тебе нельзя умирать!» — и нездорово смеется. И все это в компании трех джуниоров.
Александр Поломодов руководит разработкой в управлении привлечением в Tinkoff.ru; ранее он был руководителем разработки / CTO в небольших компаниях. Мы попросили Александра вспомнить прошлое и рассказать, какие подводные камни могут ожидать тимлида, приходящего в стартап.
Под катом — ответы на важные вопросы:
Вы приходите тимлидом в стартап. Ожидание: сразу начинаете работать над новыми фичами. Реальность: хантите разработчиков, потому что сильная команда нужна еще вчера, а о том, чтобы ее собрать никто не позаботился.
Здесь возможны два варианта — потяжелее и полегче. Болезненный вариант: денег в ФОТ мало. Одно из лучших решений в такой ситуации — брать стажеров с чистой и светлой головой, и вкладывать в эту голову все нужные знания и навыки: рисовать каждому индивидуальный план развития, пошагово расписывать, какие знания ему нужно будет добрать, какие скиллы в каком порядке наработать. Прекрасный способ, но, к сожалению, он не ваш: это игра в долгую, и стартапы, которым нужно быстро показать результат, почти никогда на такое не идут.
Характерная фраза: «Нужны топовые спецы по Angular. Платим ниже рынка».
Вариант полегче: деньги есть, и вы готовы предложить хорошие рыночные условия.
Типичный кейс. Частая практика в IT-компаниях в этом случае — выставлять основным требованием к кандидату знание специфического стека технологий. Несколько лет назад в описаниях вакансий постоянно встречалось «ищем jQuery-ниндзя». Проблема в том, что многие из этих ниндзя как будто вышли из прокрустова ложа — могут писать только на jQuery (в новом проекте его нет? Ну извините). А если человек не просто отлично знает конкретный стек, но и имеет хорошую базу, то, скорее всего, ваше предложение по зарплате перебьет какая-нибудь корпорация.
Решение. Когда деньги на адекватные зарплаты есть, нужно искать людей, ориентируясь на наличие фундаментальных знаний и сложно нарабатываемых навыков вроде системного
Когда по зарплате вы не можете конкурировать за лучших специалистов, стоит нанимать людей со светлой головой, которые неудачно выбрали сферу. Человек проектировал микросхемы, а теперь решил сменить область на более денежную? Берем.
Вторая сложность, с которой может столкнуться тимлид в стартапе, — розовые очки CEO. Планы, которые уже представлены клиентам или инвесторам, не совпадают с реальностью. Команду прессуют по срокам, требуют побыстрее показать MVP, добавлять фичи, при этом постоянно ставят жесткие нереалистичные дедлайны. Нарастают новые и новые слои костыльного кода, копится технический долг, а создатель стартапа уверен, что все в порядке — просто разработчики то ли ленятся, то ли озвучивают пессимистичные прогнозы.
Часто такая ситуация возникает у руководителя-сейлза. Он уже продал воздушный замок, — а как этот замок теперь строить, его не особо волнует.
Характерная фраза: «Я продал эти фичи, они должны появиться к концу, недели, месяца, года» (нужное подчеркнуть).
Типичный кейс. CEO хочет релиз за три дня, разработчик оценивает задачу и сообщает тимлиду, что сможет сделать за пять. Объясняет: «API, с которым приходится работать, долго интегрировать. Если API будет работать так, как обещает партнер, то в три дня уложусь. Но, по моему опыту, API этого партнера часто не соответствует их обещаниям, потому — пять дней». СЕО отвечает: «Партнер обещает, что все будет отлично. У вас три дня», — а после встречи говорит CTO: «Я ничего в разработке не понимаю, а оценку задачи уменьшил почти вдвое».
Разработчик из этого кейса постарался и выполнил задачу за четыре дня. Все равно случился факап, но даже если бы он и уложился в сроки — долго так продолжаться не может, это терминальная стадия непонимания того, как должна работать нормальная, здоровая команда.
Решение. Обсуждать сроки — нормально, но это должна быть аргументированная дискуссия. Ответы в стиле Тони Роббинса: «Неделя — это слишком долго!» и «Надо больше стараться!» — индикатор розовых очков. Снять их — серьезная проверка коммуникативных навыков тимлида.
Речь не о том, чтобы сбить цену торгуясь, как на базаре, где есть нижняя стоимость и маржа, которая распределяется в игре с нулевой суммой между продавцом и покупателем. Здесь обсуждается инженерное решение, в оценку которого вы хотите попасть с учетом дополнительных факторов. Разработчик не выторговывает себе пять дней работы, а дает оценку, основанную на его знаниях. Если хорошо надавить, он уменьшит сроки, но скорее всего, сбросит со счетов все риски. А когда что-то пойдет не так, планы обязательно поедут. Это-то и важно донести до CEO, и, если вас не хотят понимать — бегите, глупцы.
Очень показательна история создания OS/360, рассказанная в книге Фредерика Брукса «Мифический человеко-месяц». Это должна была быть крутейшая операционная система того времени. IBM привлекла к проекту тысячи человек и все равно промахнулась по всем пунктам: по срокам, функциональности и возможности поддержки.
Из книги Брукса становится понятно, что тогда разработчики наступили на все возможные грабли, и это при том, что использовали Waterfall и достаточно ясно представляли этапы разработки. А сегодня, с повсеместным распространением Agile, у команды и архитектурного плана на дальнюю перспективу часто нет — только бэклог, состоящий из бизнесовых задач, и спринт на одну-две недели.Так что и архитектура выходит соответствующая.
Характерная фраза: «Перекрасить эту кнопку в синий? Понадобится неделя»
Условно, если в первом спринте запланирована постройка трех квартир, то во втором рядом строится барак или шалаш. Затем приходит новая задача — накрыть их общей крышей, а стоит кое-как установить кровлю, выясняется, что сверху будет еще один этаж и так далее.
Там, где настоящий дом давно бы развалился под грузом ошибок проектировщика, в разработке формируется технический долг. И если первое время работа над проектом идет по плану, и разложенных костылей никто не замечает, то в какой-то момент выясняется, что, простая фича, поначалу стоившая день разработчика, теперь занимает вдвое больше. А поскольку разложенные костыли приходится обходить снова и снова и добавлять к ним новые, через квартал фича будет стоить в пять раз дороже.
Решение. Нормальный руководитель принимает решения, основываясь на фактах и цифрах. Приходите с расчетами: покажите, во сколько будет обходиться незакрытый технический долг через месяц, через квартал, через год. Так у вас появится возможность корректировать планы, включая в спринты не только новые фичи, но и поэтапную «оплату долгов».
Конечно, это не исчерпывающий список проблем, с которыми сталкиваются тимлиды в стартапах, но эти три — из наиболее острых и сложно решаемых.
Александр Поломодов — куратор интенсива Teamlead Weekend [2] в Binary District; ближайший курс пройдет 15–16 декабря.
Автор: enidcoleslaw
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/301262
Ссылки в тексте:
[1] мышления: http://www.braintools.ru
[2] Teamlead Weekend: https://binarydistrict.com/ru/course/teamlead-weekend/?utm_source=blogs&utm_medium=habrhabr&utm_campaign=teamlead_pain
[3] Источник: https://habr.com/post/432128/?utm_campaign=432128
Нажмите здесь для печати.