Блог

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

Редакция Lodoss Team
0

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

Разработка MVP

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

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

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

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

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

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

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

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

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

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

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

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

Проведение аналитики

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

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

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

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

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

souqina

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

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

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

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

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

Вносить дополнительные требования по ходу проекта
Решать непредвиденные проблемы “на лету”
Реализовывать идеи, возникающие в процессе работы
Корректировать реализацию
Экономить ресурсы. Для тестирования гипотезы не нужно делать весь проект и тратить на него полностью бюджет - достаточно создать MVP.

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

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

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

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

trove

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Впервые опубликовано на Cossa.ru

0