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

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

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

    image

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

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

    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 декабря.
    • +27
    • 10,5k
    • 9

    Binary District

    200,00

    Курсы, хакатоны и конференции по новым технологиям

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


      А вот это было больно…
        0
        Упущен момент с опционами. Если вдруг выстрелит, то можно получить больше по итогу. Но как и везде, выше риски.
          +1
          С опционами основной риск, что про них забудут или отморозятся :-)
            0
            Решение. Нормальный руководитель принимает решения, основываясь на фактах и цифрах. Приходите с расчетами: покажите, во сколько будет обходиться незакрытый технический долг через месяц, через квартал, через год.

            Это Александр тимлиду советует? Т.е. техническому специалисту? Может он и прибыли/убытки должен посчитать для «нормального руководителя»?
              0
              Честно говоря, совет хорош, только его нужно понимать немного в другой плоскости — возрастание трудозатрат людей (а оценку трудозатрат тимлид сделать должен) * среднюю ставку часа = сумма денег, которую придется платить людям. А вот дальше «нормальный руководитель» должен считать:
              Если новая машина, произведенная компанией, на которую я работаю, выехала из Чикаго со скоростью шестьдесят миль в час, и тут у нее заклинило дифференциал, и она улетела в кювет, разбилась, бензобак взорвался и все, кто были в салоне, сгорели заживо, должна ли компания отозвать все проданные автомобили этой модели на доработку?
              Возьмите общее количество проданных на настоящий момент автомобилей (А), умножьте на среднее количество серьезных отказов (В), а затем умножьте произведение на среднюю стоимость урегулирования иска родственников пострадавших во внесудебном порядке (С).
              А х В х С = X. Вот во сколько нам обойдется проблема, если мы не будем отзывать модель на доработку.
              Если Х превышает стоимость доработки, томы производим доработку, и аварий больше не бывает.
              Если Х меньше, чем стоимость доработки, то мы доработку не производим.
                0
                Полностью согласен. Тимлид максимум может соорентировать по времени разработки, но никак по стоимости, тем более по убыткам
                0
                потому — пять дней

                Если речь о дельте, которая меньше 50% от начального, то можно уложиться почти всегда. Особенно если нормальные ребята работают. Особенно, если есть экономическая выгода по факту завершения.
                Так что пеняйте на себя и команду. Как ПМ садился порой и верстать, и кодить, лишь бы сдать в срок. Чаще всего конечно отсекали лишнее или шли костылями(вставляй тут кусок логики прямо в шаблон или делай это на фронте вместо бека, так будет быстрее), но кейсы, когда верстальщик заболел, а не хватает только верстки — решаемы. Садишься сам или отдаешь в 3rd-party.

                В целом — реалии бизнеса таковы, что всегда будет ASAP, если бизнес растущий. И вы даже с сертификатом Agile и MBA ничего не сможете сделать. Точнее так — все, что вам нужно делать, это производство(писать код в нашем случае). Поэтому всех за станки и вперед. Не спать ночами, нанимать фрилансеров/бывших/etc.
                  0
                  Мда, а потом внезапно таким образом оказывается, что либо дальше двигаться долго и мучительно, и команда разбегается от такого франкинштейна, или каждый релиз приносит кучу багов, и уже клиенты разбегаются. Но вариант когда разбегаются и те и другие гораздо более реалистичный.
                    0
                    Вы путаете регулярный аврал и локальный asap.
                    Если осознано вставляются костыли, чтобы быстрее сдать, и добавляются в техдолг, то не вижу ничего в этом плохого.

                    Вы же увидели только негатив, не думаю, что от такого человека не разбегается команда и клиенты. Спасибо, что поделились своим опытом :)

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

                Самое читаемое