Все записи
МОЙ ВЫБОР 18:41  /  16.08.18

542просмотра

Как управлять командой айтишников, если ты ничего не понимаешь в программировании

+T -
Поделиться:

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

Риски

Первое на что следует обратить внимание, так это на набор самых распространенных рисков, связанных с разработкой программного обеспечения. Они существенно отличаются от тех, с которыми вы обычно встречаетесь в других областях. Так в разработке программного обеспечения помимо классических рисков срыва сроков и некачественной реализации продукта есть и те, с которыми я встретиться не ожидал.  Среди таких стоит выделить неудачную архитектуру программного продукта, которая выражается в сложности нововведений в исходный код, вовлечения новых членов команды и передачи им кода. Неудачная архитектура сродни программе, написанной человеком на языке, который знает только он сам. Вникнуть в него и поддерживать такой код потребует существенных временных затрат, а соответственно, и денежных. Это буквально парализует работу над проектом в ущерб текущему развитию до тех пор, пока неудачный участок не будет переработан.

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

90% команды и 10% экспертизы

Любой успешный проект- это 10% работы и 90% команды, а формирование успешной команды- это во многом везение. Нужно быть готовым, что за хороших специалистов предстоит побороться- важно заручиться поддержкой опытного HR или специалиста с релевантным опытом работы в Яндексе или Гугл- он поможет составить тестовое задание, чтобы быстро отсеивать неподходящих кандидатов. На качестве программного продукта экономить бессмысленно, потому что, во-первых, подобная экономия обернется колоссальными затратами на переписывание программного комплекса после, а, во-вторых, сама по себе команда- ваш новый актив.

При поиске специалистов в технологический стартап с небольшой командой ни в коем случае не стоит принимать стажеров, вчерашних выпускников и людей из других стартапов без опыта работы в крупных профильных компаниях,- это неизбежно выльется в то, что обучаться, если им это в конечном итоге удастся, им предстоит за ваш счет, что повлечет реализацию вышеуказанного риска некачественного программного продукта, не говоря уже о сроках и “пожирании времени” других специалистов в вашей команде. Ваша правильная команда- это опытные специалисты, обученные “правилам хорошего кода”, коллективной работе над программным продуктом, выходцы из крупных ИТ-компаний. Такие специалисты подойдут к процессу разработки ответственно и даже решив сменить место работы не оставят вас разбираться с абракадаброй. И будьте готовы переплатить за них- подобные специалисты хорошо знают себе цену.

Несомненно вам нужна техническая экспертиза (те самые 10%), так что приготовьтесь завести аккаунт на «Хабре» (крупнейшем на постсоветском пространстве интернет-сообществе ИТ-специалистов), к посещению тематических конференций и форумов или даже курсов по программированию. Без способности продемонстрировать достаточной уровень компетенции в области, в которой вы работаете, вам может не хватить профессионального авторитета, что может помешать вашему успеху в управлении. От вас требуется уважение к тем, кем вы управляете, и часть этого уважения должна быть заработана тем, насколько хорошо вы знаете свой бизнес. Помимо грамотного делегирования в ИТ-бизнесе важен ментор из профильной сферы, который будет держать руку на пульсе- это может быть и ваш советник или партнер. Важно понимать это с самого начала, а не прийти к этому, когда бизнес уже столкнется с проблемами и выбирать партнера с недостающей для вас компетенцией, а лучше с несколькими сразу.

Продайте команде свой продукт

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

Поэтому в своем проекте я выработал для себя простые правила- не обсуждать с командой разработки планы по внедрению нового функционала. Общение с клиентами- ваш основной канал информации, по которому следует принимать решения. Порой тот или иной функционал сложно встраивается в текущую инфраструктуру из-за сложных внутренних зависимостей в коде, или разработчику это покажется просто неинтересной задачей, иными словами, всегда найдется 100 причин этого не делать. Второе- разумно дистанцироваться от команды в вопросах мониторинга сроков, мотивации и прочих аспектов, которые могут повлиять на независимую оценку ситуации со стороны, пусть этим займется ваш помощник или советник из профильной области. Важно сохранять рассудок и не принимать стратегические решения, основываясь на том, какой плохой код остался после предыдущего разработчика или том, что сейчас было бы интереснее решить другую задачу.

И не мешайте программистам программировать

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