Как упростить разработку IT-продуктов: 4 совета

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

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

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

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

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

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

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

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

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

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

Можно проигнорировать: и так все понятно, как-нибудь заработает.

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

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

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

Идем дальше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надеемся, было полезно, и вы избежите перечисленных ошибок.