Костыли, Нарния, прокрустов ниндзя: три боли тимлида в стартапе
Тимлид в стартапе — разом и Илон Маск, и Франкенштейн. Утром конструирует космические корабли, а к вечеру обращает к проекту крик: «Живи! Тебе нельзя умирать!» — и нездорово смеется. И все это в компании трех джуниоров.
Александр Поломодов руководит разработкой в управлении привлечением в Tinkoff.ru; ранее он был руководителем разработки / CTO в небольших компаниях. Мы попросили Александра вспомнить прошлое и рассказать, какие подводные камни могут ожидать тимлида, приходящего в стартап.
Под катом — ответы на важные вопросы:
- как выжить в условиях, когда процессы взаимодействия не налажены (или не существуют вовсе);
- как собрать крутую команду, когда ФОТ ограничен;
- как понять, что из проекта нужно бежать.
1. Идей полно, делать некем
Вы приходите тимлидом в стартап. Ожидание: сразу начинаете работать над новыми фичами. Реальность: хантите разработчиков, потому что сильная команда нужна еще вчера, а о том, чтобы ее собрать никто не позаботился.
Здесь возможны два варианта — потяжелее и полегче. Болезненный вариант: денег в ФОТ мало. Одно из лучших решений в такой ситуации — брать стажеров с чистой и светлой головой, и вкладывать в эту голову все нужные знания и навыки: рисовать каждому индивидуальный план развития, пошагово расписывать, какие знания ему нужно будет добрать, какие скиллы в каком порядке наработать. Прекрасный способ, но, к сожалению, он не ваш: это игра в долгую, и стартапы, которым нужно быстро показать результат, почти никогда на такое не идут.
Характерная фраза: «Нужны топовые спецы по Angular. Платим ниже рынка».
Вариант полегче: деньги есть, и вы готовы предложить хорошие рыночные условия.
Типичный кейс. Частая практика в IT-компаниях в этом случае — выставлять основным требованием к кандидату знание специфического стека технологий. Несколько лет назад в описаниях вакансий постоянно встречалось «ищем jQuery-ниндзя». Проблема в том, что многие из этих ниндзя как будто вышли из прокрустова ложа — могут писать только на jQuery (в новом проекте его нет? Ну извините). А если человек не просто отлично знает конкретный стек, но и имеет хорошую базу, то, скорее всего, ваше предложение по зарплате перебьет какая-нибудь корпорация.
Решение. Когда деньги на адекватные зарплаты есть, нужно искать людей, ориентируясь на наличие фундаментальных знаний и сложно нарабатываемых навыков вроде системного мышления. Даже если человек не знаком с конкретным языком или стеком технологий, он при желании освоит все основное за квартал.
Когда по зарплате вы не можете конкурировать за лучших специалистов, стоит нанимать людей со светлой головой, которые неудачно выбрали сферу. Человек проектировал микросхемы, а теперь решил сменить область на более денежную? Берем.
2. CEO из Нарнии
Вторая сложность, с которой может столкнуться тимлид в стартапе, — розовые очки CEO. Планы, которые уже представлены клиентам или инвесторам, не совпадают с реальностью. Команду прессуют по срокам, требуют побыстрее показать MVP, добавлять фичи, при этом постоянно ставят жесткие нереалистичные дедлайны. Нарастают новые и новые слои костыльного кода, копится технический долг, а создатель стартапа уверен, что все в порядке — просто разработчики то ли ленятся, то ли озвучивают пессимистичные прогнозы.
Часто такая ситуация возникает у руководителя-сейлза. Он уже продал воздушный замок, —, а как этот замок теперь строить, его не особо волнует.
Характерная фраза: «Я продал эти фичи, они должны появиться к концу, недели, месяца, года» (нужное подчеркнуть).
Типичный кейс. CEO хочет релиз за три дня, разработчик оценивает задачу и сообщает тимлиду, что сможет сделать за пять. Объясняет: «API, с которым приходится работать, долго интегрировать. Если API будет работать так, как обещает партнер, то в три дня уложусь. Но, по моему опыту, API этого партнера часто не соответствует их обещаниям, потому — пять дней». СЕО отвечает: «Партнер обещает, что все будет отлично. У вас три дня», —, а после встречи говорит CTO: «Я ничего в разработке не понимаю, а оценку задачи уменьшил почти вдвое».
Разработчик из этого кейса постарался и выполнил задачу за четыре дня. Все равно случился факап, но даже если бы он и уложился в сроки — долго так продолжаться не может, это терминальная стадия непонимания того, как должна работать нормальная, здоровая команда.
Решение. Обсуждать сроки — нормально, но это должна быть аргументированная дискуссия. Ответы в стиле Тони Роббинса: «Неделя — это слишком долго!» и «Надо больше стараться!» — индикатор розовых очков. Снять их — серьезная проверка коммуникативных навыков тимлида.
Речь не о том, чтобы сбить цену торгуясь, как на базаре, где есть нижняя стоимость и маржа, которая распределяется в игре с нулевой суммой между продавцом и покупателем. Здесь обсуждается инженерное решение, в оценку которого вы хотите попасть с учетом дополнительных факторов. Разработчик не выторговывает себе пять дней работы, а дает оценку, основанную на его знаниях. Если хорошо надавить, он уменьшит сроки, но скорее всего, сбросит со счетов все риски. А когда что-то пойдет не так, планы обязательно поедут. Это-то и важно донести до CEO, и, если вас не хотят понимать — бегите, глупцы.
3. Технический долг под проценты микрокредита
Очень показательна история создания OS/360, рассказанная в книге Фредерика Брукса «Мифический человеко-месяц». Это должна была быть крутейшая операционная система того времени. IBM привлекла к проекту тысячи человек и все равно промахнулась по всем пунктам: по срокам, функциональности и возможности поддержки.
Из книги Брукса становится понятно, что тогда разработчики наступили на все возможные грабли, и это при том, что использовали Waterfall и достаточно ясно представляли этапы разработки. А сегодня, с повсеместным распространением Agile, у команды и архитектурного плана на дальнюю перспективу часто нет — только бэклог, состоящий из бизнесовых задач, и спринт на одну-две недели.Так что и архитектура выходит соответствующая.
Характерная фраза: «Перекрасить эту кнопку в синий? Понадобится неделя»
Условно, если в первом спринте запланирована постройка трех квартир, то во втором рядом строится барак или шалаш. Затем приходит новая задача — накрыть их общей крышей, а стоит кое-как установить кровлю, выясняется, что сверху будет еще один этаж и так далее.
Там, где настоящий дом давно бы развалился под грузом ошибок проектировщика, в разработке формируется технический долг. И если первое время работа над проектом идет по плану, и разложенных костылей никто не замечает, то в какой-то момент выясняется, что, простая фича, поначалу стоившая день разработчика, теперь занимает вдвое больше. А поскольку разложенные костыли приходится обходить снова и снова и добавлять к ним новые, через квартал фича будет стоить в пять раз дороже.
Решение. Нормальный руководитель принимает решения, основываясь на фактах и цифрах. Приходите с расчетами: покажите, во сколько будет обходиться незакрытый технический долг через месяц, через квартал, через год. Так у вас появится возможность корректировать планы, включая в спринты не только новые фичи, но и поэтапную «оплату долгов».
Конечно, это не исчерпывающий список проблем, с которыми сталкиваются тимлиды в стартапах, но эти три — из наиболее острых и сложно решаемых.
Александр Поломодов — куратор интенсива Teamlead Weekend в Binary District; ближайший курс пройдет 15–16 декабря.
