Основные проблемы в управлении ИТ-проектами, и как их избежать

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

Разработка MVP

Заказчик часто не понимает, почему важно максимально быстро выпустить продукт. В Lodoss Team мы сразу предлагаем клиенту начать работу с запуска MVP.

MVP — minimum viable product — минимальная рабочая версия продукта, которую можно быстро создать и протестировать на пользователях. Это помогает собрать данные и понять готовы ли пользователи покупать продукт, насколько он им интересен. MVP позволяет быстро запустить продажи и получить представление о коммерческой ценности разрабатываемого продукта. Это лучше, чем через год сделать идеальный с точки зрения разработчика, но никому не нужный на рынке продукт. Заказчик с помощью MVP может:

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

• сэкономить деньги и время;
• протестировать свой продукт на живых пользователях;
• скорректировать стратегию и роадмап;
• собрать пул лояльных пользователей.

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

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

Сбор исходных требований

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

На этом этапе часто возникает проблема — убедить клиента, что ему необходимо зафиксировать свои требования и пожелания к проекту в ТЗ. Как правило, многие не понимают, зачем это нужно, или просто не могут составить грамотное техзадание. Вместо ТЗ приносят просто список неоформленных желаний, без структуры, ви́дения и целей, которых необходимо достигнуть. Для чего нужно техзадание?

Когда работа идёт по гибким методологиям (почему для работы мы выбрали их, читайте дальше), ТЗ — это не жёсткий монолит, от которого нельзя отступить ни на шаг. Этот документ помогает расставить приоритеты и определить главные задачи, выделить функциональность MVP и разделить её на майлстоуны.

Предпроектная аналитика

Подобных проблем позволяет избежать предпроектная аналитика. С её помощью можно выявить скрытые сложности и подводные камни проекта, о которых может не подозревать сам клиент. Часто заказчик не видит необходимости проводить аналитику, он считает, что досконально знает проект и может чётко описать необходимый объём работы. Наш опыт показывает, что в 90% случаев это не так.

Оценка проекта

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

Проект Souqina

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

Выбор методологии

Управление ИТ-проектами отличается такими особенностями, как сложность, быстрая изменяемость и высокие риски. Это накладывает определённые требования к подходам, применяемым при их реализации. Существует два основных: проектный (модель водопада) и процессный (гибкая методология). Возможны различные сочетания этих подходов в зависимости от целей, задач и содержания проекта. Оба имеют свои плюсы и минусы, как с точки зрения заказчика, так и со стороны подрядчика. Главная проблема, которая встречается на старте проекта, — клиент не понимает, какой подход лучше выбрать. Более того, он, как правило, вообще не знает о существовании подходов, а хочет действовать, как в магазине: узнать цену проекта, заплатить и получить гарантированный результат. К сожалению, с ИТ-проектами обычно так не получается.

В Lodoss мы используем гибкую методологию и работаем по scrum-модели: реализуем проект спринтами по две недели. Каждый спринт заканчивается измеримым результатом: выпуск MVP, релиз или исправление пула багов.

Такой подход даёт клиенту возможность:

• вносить дополнительные требования по ходу проекта;
• решать непредвиденные проблемы «на лету»;
• реализовывать идеи, возникающие в процессе работы;
• корректировать реализацию;
• экономить ресурсы. Для тестирования гипотезы не нужно делать весь проект и тратить на него полностью бюджет — достаточно создать MVP.

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

Такой подход работает, когда объясняешь клиенту, что несмотря на то, что он всё продумал заранее, он всё равно захочет вносить изменения в процессе работы. Это наш выстраданный опыт — не было ни одного клиента, который бы не хотел что-нибудь изменить при реализации проекта. Поэтому нам нужна гибкость в разработке, чтобы мы могли вносить правки в новый майлстоун.

Выбор эффективных инструментов

Берясь за конкретный проект, важно уже на старте понимать, какими инструментами вы будете пользоваться. Кому-то удобно работать в связке с CRM, а кому-то — строить диаграммы Ганта. Важно продумать, где и как вы будете общаться с заказчиком, как будете фиксировать договорённости и этапы реализации проекта. Будут ли используемые в компании инструменты эффективны на проекте большого масштаба или новой для вас специфики.

Проект TroveSkin

Тогда мы решили ввести инструмент для общения с клиентом по новым фичам, который поможет решить эти проблемы. Мы выбрали Trello: в первый столбец клиентом или менеджером вводились хотелки, затем они проходили ряд преобразований: оформлялись в задачи, задачи помечались тегами — какую платформу они затрагивают, по каждой задаче шло прикреплённое к ней обсуждение. В итоге к каждой задаче прикреплялась оценка и выставлялся приоритет. Из таких готовых тасков менеджер совместно с клиентом составляли очередной спринт и потом его утверждали. Такой спринт уходил в приложение к договору, а также помещался в Jira, где с ним работала техническая команда.

Плохой менеджмент и ошибки при проработке требований заказчика

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

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

Синхронизация и тестирование

Когда на проекте задействованы специалисты разных платформ, то всегда есть риск рассинхронизации: исполнители по-разному понимают задачу или реализуют какой-то функционал совершенно разными средствами. В результате, если потребуются какие-то незначительные изменения, то сделать их для одной платформы может быть легко, а для другой потребуются много временных затрат. Чтобы не допустить подобного, проджект-менеджер ежедневно проводит синхронизацию с командой. Она занимает 5–10 минут и представляет собой обсуждение текущей работы и проблем.

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

После публичного релиза, мы уделяем особое внимание тестированию приложения: перед заливкой проект тестируется на стейджинг-сервере, повторно проводятся все тест-кейсы.

Учёт изменений на проекте и документация особенностей

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

Обязательно нужно вести документацию хотя бы на уровне бизнес-логики — как бы ни казалось, что всё понятно и в головах менеджера/разработчика/тестировщика всё есть, вам не хватит ни воспоминаний, ни переписки, ни комментариев в Jira, чтобы выяснить «почему мы сделали именно так полгода назад». Это достаточно ресурсозатратно, но поверьте, стоит того.

Главные рекомендации

Мы составили чеклист рекомендаций, которых необходимо придерживаться при работе над ИТ-проектами:

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

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.