Главная » Хабрахабр » Костыли, Нарния, прокрустов ниндзя: три боли тимлида в стартапе

Костыли, Нарния, прокрустов ниндзя: три боли тимлида в стартапе

Тимлид в стартапе — разом и Илон Маск, и Франкенштейн. Утром конструирует космические корабли, а к вечеру обращает к проекту крик: «Живи! Тебе нельзя умирать!» — и нездорово смеется. И все это в компании трех джуниоров.

Мы попросили Александра вспомнить прошлое и рассказать, какие подводные камни могут ожидать тимлида, приходящего в стартап. Александр Поломодов руководит разработкой в управлении привлечением в Tinkoff.ru; ранее он был руководителем разработки / CTO в небольших компаниях.

image

Под катом — ответы на важные вопросы:

  • как выжить в условиях, когда процессы взаимодействия не налажены (или не существуют вовсе);
  • как собрать крутую команду, когда ФОТ ограничен;
  • как понять, что из проекта нужно бежать.

1. Идей полно, делать некем

Вы приходите тимлидом в стартап. Ожидание: сразу начинаете работать над новыми фичами. Реальность: хантите разработчиков, потому что сильная команда нужна еще вчера, а о том, чтобы ее собрать никто не позаботился.

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

Платим ниже рынка».
Характерная фраза: «Нужны топовые спецы по Angular.

Вариант полегче: деньги есть, и вы готовы предложить хорошие рыночные условия.

Несколько лет назад в описаниях вакансий постоянно встречалось «ищем jQuery-ниндзя». Типичный кейс. Частая практика в IT-компаниях в этом случае — выставлять основным требованием к кандидату знание специфического стека технологий. Ну извините). Проблема в том, что многие из этих ниндзя как будто вышли из прокрустова ложа — могут писать только на jQuery (в новом проекте его нет? А если человек не просто отлично знает конкретный стек, но и имеет хорошую базу, то, скорее всего, ваше предложение по зарплате перебьет какая-нибудь корпорация.

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

Человек проектировал микросхемы, а теперь решил сменить область на более денежную? Когда по зарплате вы не можете конкурировать за лучших специалистов, стоит нанимать людей со светлой головой, которые неудачно выбрали сферу. Берем.

2. CEO из Нарнии

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

Он уже продал воздушный замок, — а как этот замок теперь строить, его не особо волнует.
Часто такая ситуация возникает у руководителя-сейлза.

Характерная фраза: «Я продал эти фичи, они должны появиться к концу, недели, месяца, года» (нужное подчеркнуть).

Типичный кейс. CEO хочет релиз за три дня, разработчик оценивает задачу и сообщает тимлиду, что сможет сделать за пять. Объясняет: «API, с которым приходится работать, долго интегрировать. Если API будет работать так, как обещает партнер, то в три дня уложусь. Но, по моему опыту, API этого партнера часто не соответствует их обещаниям, потому — пять дней». СЕО отвечает: «Партнер обещает, что все будет отлично. У вас три дня», — а после встречи говорит CTO: «Я ничего в разработке не понимаю, а оценку задачи уменьшил почти вдвое».

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

Ответы в стиле Тони Роббинса: «Неделя — это слишком долго!» и «Надо больше стараться!» — индикатор розовых очков. Решение. Обсуждать сроки — нормально, но это должна быть аргументированная дискуссия. Снять их — серьезная проверка коммуникативных навыков тимлида.

Здесь обсуждается инженерное решение, в оценку которого вы хотите попасть с учетом дополнительных факторов. Речь не о том, чтобы сбить цену торгуясь, как на базаре, где есть нижняя стоимость и маржа, которая распределяется в игре с нулевой суммой между продавцом и покупателем. Если хорошо надавить, он уменьшит сроки, но скорее всего, сбросит со счетов все риски. Разработчик не выторговывает себе пять дней работы, а дает оценку, основанную на его знаниях. Это-то и важно донести до CEO, и, если вас не хотят понимать — бегите, глупцы. А когда что-то пойдет не так, планы обязательно поедут.

3. Технический долг под проценты микрокредита

Очень показательна история создания OS/360, рассказанная в книге Фредерика Брукса «Мифический человеко-месяц». Это должна была быть крутейшая операционная система того времени. IBM привлекла к проекту тысячи человек и все равно промахнулась по всем пунктам: по срокам, функциональности и возможности поддержки.

А сегодня, с повсеместным распространением Agile, у команды и архитектурного плана на дальнюю перспективу часто нет — только бэклог, состоящий из бизнесовых задач, и спринт на одну-две недели.Так что и архитектура выходит соответствующая.
Из книги Брукса становится понятно, что тогда разработчики наступили на все возможные грабли, и это при том, что использовали Waterfall и достаточно ясно представляли этапы разработки.

Понадобится неделя»
Характерная фраза: «Перекрасить эту кнопку в синий?

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

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

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

Конечно, это не исчерпывающий список проблем, с которыми сталкиваются тимлиды в стартапах, но эти три — из наиболее острых и сложно решаемых.

Александр Поломодов — куратор интенсива Teamlead Weekend в Binary District; ближайший курс пройдет 15–16 декабря.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Интервью с Дэвидом Гобелем

Дэвид любезно согласился дать LEAF очень интересное интервью. Дэвид Гобель – изобретатель, филантроп, футурист и ярый сторонник технологий омоложения; вместе с Обри де Греем он известен как один из основателей Methuselah Foundation и как автор концепции Longevity Escape Velocity (LEV), ...

10 долларов на хостинг: 20 лет назад и сегодня

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