Семь факторов, которые влияют на сроки и бюджет проекта

Если их не допускать, проект с большей долей вероятности попадет в 31% успешных.

Успех проекта определяют подходы к разработке. От выбора методологии зависит то, на основе чего будут выстроены процессы реализации проекта.

Если говорить обобщенно, то существует два основных вида методологий:

• Традиционная модель — классический подход. Используют, когда сроки, бюджет, технологии точно определены. Не предполагает существенных изменений цифрового продукта в процессе разработки. Обычно работают по Fix Price.

• Гибкая модель — agile development. Подходит в двух случаях: если нужно быстро разработать MVP продукта и дальше его дорабатывать, и если идет работа с объемным проектом, имеющим длинный жизненный цикл. При гибкой модели обычно работают по T&M.

Традиционная или гибкая. Что лучше?

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

На качество проекта влияют факторы, исходящие как со стороны заказчика, так и со стороны исполнителя. Даже если продукт разрабатывает собственная in-house-команда.

Недопонимание на этапе планирования

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

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

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

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

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

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

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

Недостаточный контроль

Когда согласуются спринты — промежуточные результаты — заказчику сложно понять, все ли в порядке, получается ли задуманное.

Эту ситуацию исправляет project-менеджер (PM) — переводчик и главный помощник заказчика на проекте. Именно он отвечает за ход работы, отчитывается по спринтам, помогает разобраться в деталях проекта. На больших проектах, например, при разработке сложных корпоративных CRM-систем, задача которых автоматизировать работу входящей информацией, может быть несколько project-менеджеров. Каждый из них отвечает за свою часть проекта. Проекты с опытными project-менеджерами редко выходят из-под контроля.

Зона ответственности исполнителя

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

Фактор 1. Управление проектом

За это отвечает project-менеджер.

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

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

Читайте также

Цифровой маркетинг для развития личного бренда ИТ-директора

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

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

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

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

Фактор 2. Скорость погружения специалиста в проект

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

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

Вот несколько наших лайфхаков, которые помогают нам сократить время погружения специалистов в проект:

• Соблюдаем единые стандарты ведения проекта для всех проектов компании.

• В каждой задаче описываем все требования и условия, необходимые для выполнения задачи.

• Соединяем связанные задачи. Группируем все, что относится к одному юзкейсу/странице.

• Соблюдаем версионность документов.

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

• Тщательно и скрупулезно документируем историю проекта.

Фактор 3. Размер задач

Важно не просто планировать основные этапы работы над проектом, но и разбивать объемные задачи на подзадачи, за сроком исполнения которых тоже нужно следить.

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

Если оставить большую задачу недекомпозированной, то есть риск, что она не будет выполнена к дедлайну поскольку:

• нет никакого ощутимого результата за целый рабочий день;

• неизвестен фактический процент выполнения задачи.

Еще один плюс такого решения — возможность оперативно реагировать на любые отклонения от графика.

Фактор 4. Порядок выполнения задач

Здесь в полной мере следует использовать инструменты планирования, которых сейчас очень много: «Битрикс24», Jira, Asana, ActiveCollab, Slack, Wrike, Trello, MS Project и другие. Их инструментарий позволяет вести отчетность по проекту, где исполнители фиксируют результаты своей работы, этапы, на которых находятся, сообщают о возникших сложностях, способных повлиять на ход реализации проекта.

При этом в своей работе мы придерживаемся ряда правил:

• Нельзя ставить дедлайны по всем задачам на одну дату, чтобы не сорвать дедлайн по всем сразу.

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

• Порядок выполнения задач должен регулировать project-менеджер после того, как обсудит весь проект с заказчиком. Иногда бывает критично важно запустить основной блок проекта — к примеру, сайт. А уже потом можно дорабатывать дополнительные функции: форму регистрации, обратную связь, отзывы и т д.

Фактор 5. Приоритезация задач

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

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

Вот несколько лайфхаков, которые помогают нам расставлять приоритеты в задачах:

• Составьте список всех задач в работе. Ранжировать задачи по приоритетности можно только тогда, когда перед глазами есть все задачи, которые должны быть выполнены в рамках проекта. Каждая задача должна быть подробно описана: сроки, ответственные, связь с другими задачами

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

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

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

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

• Пост по задаче. Так руководитель всегда будет знать о фактической загруженности команды.

• Используйте календарь для планирования задач. Если перед глазами есть конкретный список дел на тот или иной день, ориентироваться в сроках проще. А если что-то пошло не по плану — сразу можно скорректировать расписание на следующие дни.

Фактор 6. Регулярный контроль

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

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

Читайте также

Корпоративная культура как актив. Важны ли корпоративная культура и этические стандарты для ИТ-специалистов?

IT-World разбирался, что есть корпоративная культура для ИТ-специалистов и команд? Насколько айтишники готовы быть частью бизнес-команды, решать совместно с другими профи-задачу? Что делать, когда вы работаете в регионе, где нет ярких «культурных» лидеров?

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

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

Фактор 7. Актуальная документация

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

• техническое задание;

• протоколы изменений каждой версии ТЗ;

• версионность прототипов/макетов;

• протоколы изменений прототипов/макетов.

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

Этого достаточно?

Нет. Разработка любых проектов — живая среда, в которой в любой момент все может выйти из-под контроля.

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

• дополнительное время на согласование промежуточных итогов с заказчиком — до 20%;

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