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