23 мая 2018, 13:30

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

Lodoss Team делится опытом на примере реальных проектов.

A2SEVEN IT company, A2SEVEN

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

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

Разработка MVP

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

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

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

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

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

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

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

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

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

Через полгода он нашёл финансирование и захотел доработать проект. Ещё несколько месяцев мы дорабатывали мобильное приложение: реализовывали новые фичи, придуманные заказчиком. Аналитику своих гипотез он не проводил, MVP не тестировал, что привело к печальным результатам.

Деньги на проект опять кончились, проект закрылся, а мы даже не смогли положить его себе в портфолио.

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

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

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

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

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

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

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

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

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

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

Однажды мы взялись за реализацию проекта Souqina. Это iOS-приложение типа Instagram, с помощью которого можно напрямую покупать вещи у блогеров, брендов и сообществ. Мы дали заказчику первичную оценку стоимости и сроков работ по проекту. Сделали это для ознакомления — чтобы он понимал порядок цен. Сразу после старта мы погрузились в проект, проводили исследования и уточняли требования. Соответственно, корректировали и бюджет, что встречало жёсткое непонимание клиента. В его голове уже жёстко зафиксировалась озвученная нами цифра. Дальнейшая работа с заказчиком свелась к спорам о каждой новой копейке, появившейся в смете. Проект мы в итоге сдали, но потратили огромное количество нервов и лишнего времени на переговоры. После этого случая решили, что это — не наш вариант.

Проект Souqina

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

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

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

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

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

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

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

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

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

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

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

Проект TroveSkin

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

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

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

В 2017 году мы начали работу над проектом Sellsay. Изначально проект казался небольшим: необходимо было лишь дополнить офлайн iOS-приложение функциональностью для многопользовательского режима. Здесь мы объяснили клиенту, что помимо мобильного разработчика, для реализации серверного функционала и панели администратора ему понадобятся бэкенд- и фронтенд-разработчики.

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

С менеджером проекта мы поговорили, но ситуация не улучшилась, так что пришлось его поменять.

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

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

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

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

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

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

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

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

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

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

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

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

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