Разработать IT-продукт ОЧЕНЬ просто. Достаточно лишь

Привет! Меня зовут Сергей, я управляющий партнер в KTS.

Уже больше 6 лет мы с партнерами создаём IT-компанию. Мы помогаем бизнесам эффективно запускать разработку продуктов. За 6 лет мы занимались кучей разных проектов с разными клиентами: от совсем маленьких до крупных корпораций. Работали и с техническими менеджерами со стороны клиентов, и нетехническими заказчиками. У всех была разная специфика проекта и отношение к разработке. Мы видели много историй успеха и провала.

В этой статье хочу рассказать, как же запускать свою разработку и так ли это просто.

Начало работы

Начнём с того, что же включает в себя разработка.

Предположим, вы менеджер и должны реализовать новый проект. Вам выделили бюджет, обрисовали задачу, KPI и все остальное. Какие варианты?

Для начала нужно запроектировать будущую систему. Стоп, прежде чем проектировать, нужно понять, зачем она вообще? Что она делает, какие проблемы решает? Например, вы делаете внутренний продукт компании, и ваши «заказчики» находятся внутри. Вы уже их опросили, выявили общие проблемы и поняли, какие процессы лучше всего автоматизировать. Возможно, даже составили какой-то CJM и набросали прототипы. Теперь нужно как-то это все обрисовать в понятное формальное ТЗ, чтобы все поняли, что нужно делать.

Совет №1: уделите время аналитике

Уже на этом этапе вам нужен как минимум аналитик.

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

Конечно, можно все это собрать самостоятельно (нет).

Можно проигнорировать: и так все понятно, должно работать «как у вон тех».

Первая ошибка — игнорирование этапа аналитики. Делая так, вы рискуете просто потратить деньги и время. Не секрет, что информация при передаче от человека к человеку сильно искажается и может менять смысл. Вам же нужно, чтобы все детали будущего проекта были учтены, а расхождения понимания действий у вас и команды были минимальны. Чем меньше информации теряем на каждом этапе, тем лучше. Соответственно, нужно структурировать, продумывать и формализовывать все аспекты будущей системы.

В своём опыте я встречал клиента, который пришёл к нам с проектом, который уже делал с разными командами (включая инхаус) не один раз. Но в итоге так и не получил стабильно работающую, решающую все задачи систему. Жизнь научила этого клиента, и он пришёл с детальной аналитикой, чуть ли не проработанной архитектурой и всеми нужными для стартапа артефактами. А можно было делать это с самого начала и не тратить деньги.

Совет №2: возьмите хорошего менеджера

Идём дальше.

Сейчас у нас есть понятное расписанное ТЗ, сторимапы, описания интеграций, утверждённые прототипы, а дизайнеры уже нарисовали дизайны по этим прототипам. Можно запускать разработку, так что нам нужны ее ключевые участники: менеджер и тим+техлид.

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

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

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

Сам процесс разработки довольно сложен и включает как минимум этапы: to do, in progress, review, test, stage, release. То есть менеджер не только собирает митинги и обсуждает задачи, но и планирует работу таким образом, чтобы весь этот «конвейер» выпускал релизы бесперебойно, в нужном темпе и не выходил при этом из заданных бюджетом и сроками рамок. Чем больше команда, тем больше ответственность, и тем больше опыта требуется от менеджера.

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

На практике я иногда встречаю непонимание роли менеджера: «Зачем он нужен, задачки в jira переставлять?» Но отсутствие на проекте опытного менеджера может вылиться в растрату высоких зарплат разработчиков на простои и переделки задач из-за неэффективного планирования.

Совет №3: помните про проектирование системы и налаживание команды

Следующие — архитектор (техлид) и тимлид.

Формально эти роли разные: тимлид отвечает за эффективность команды разработки и процессов внутри; техлид — за техническое проектирование и систему в целом. И тот, и другой — опытные разработчики, которые пошли по разным веткам развития. В небольших командах архитектор и тимлид может быть одним человеком, хотя на практике для них нужны разные человеческие качества.

Тимлид должен быть эмпатичным, хорошим управленцем, «интегратором» в терминах Ицхака Адизеса. Его задача налаживать развитие внутри команды, выстраивать процесс разработки, отвечать за релизы, ревью, технические практики. Техлид/архитектор должен быть в первую очередь опытным, чтобы учесть все мелочи, граничные случаи, узкие места будущей системы и спроектировать ее. Подробнее о тимлиде и архитекторе вы можете прочитать в посте нашего Телеграм-канала.

Но допустим, мы только стартуем проект, и сейчас нам скорее важен грамотный архитектор, который не допустит ошибок. Ошибки на этапе проектирования (особенно, в крупных системах со множеством интеграций) приводят к колоссальным потерям.

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

Думаю, уже понятно, что третья ошибка — не брать опытного лида, а надеяться, что его функции возьмёт какой-нибудь самый умелый разработчик… который напроектирует так, как считает нужным. К сожалению, здесь палка о двух концах: найти опытного лида без собственного опыта разработки или помощи каких-нибудь знакомых СТО почти нереально. На практике на ведущие технические позиции со стороны наших заказчиков не раз брали не самых опытных людей.

Совет №4: ведите практики разработки

Ну что ж, задачи описаны максимально четко, бэклог побит на спринты, сервис запроектирован. Запускаем разработчиков!

Казалось бы, это самое простое! Но нет: разработчиков много, все люди разные и у всех разная экспертиза. Я уже не говорю о том, что найти разработчиков — дорого и долго. А собрать слаженную команду, которая будет понимать друг друга с полуслова и работать в одном темпе — примерно то же самое, что тренировать хоккейную команду: пробовать разные варианты пятёрок и искать, кто с кем и как лучше взаимодействует.

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

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

Вернёмся к выгоранию. Чтобы его предотвратить, существуют разные практики, от HR-мероприятий, доп. активностей внутри компании и до проведения one-to-one. И здесь лид, выступающий в роли наставника, как никогда кстати. В его задачи входит проведение всех личных встреч, работа «психологом» и т.д. Он должен сначала выстроить план развития для сотрудника, чтобы у него была мотивация двигаться, а потом вовремя почувствовать, когда сотрудник устал или чем-то обеспокоен, чтобы предотвратить его уход.

А ещё очень важен код. Да, просто код. Вам может показаться, что программисту без разницы, с каким кодом работать, это же код. Но нет. Одному программисту редко нравится код другого. Обычно у всех возникает желание «все переписать», чтобы стало красиво и правильно. Техдолг, отсутствие практик код-ревью, выбранный стек и другое — все это может стать факторами выгорания или более медленного найма людей по сравнению с тем, как могли бы.

Поэтому четвёртая ошибка — пренебрежение практиками разработки: код-ревью, рефакторингом, написанием тестов, ретроспективами, 1-to-1 и т.д. К сожалению, заказчики часто не понимают важность этих процессов и их влияние на команду и проект. А это в конечном итоге напрямую влияет на расходы.

Подведем итоги

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

В этой статье я не затрагиваю другие аспекты создания IT-проекта: тестирование, devops и прочее. Сегодня на самых базовых принципах ведения разработки я постарался показать сложность построения команды. Надеюсь, было полезно, и вы избежите перечисленных ошибок.

Или просто обращайтесь к нам, если хотите сделать хорошо — мы развиваем команды разработки уже много лет и собаку на этом съели.