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

Шаг 1. Определите владельца проекта и ответственного

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

Или даже те, кто участвует в задаче только косвенно, но влияет на принятие решения. К таким людям можно отнести, например, финансового директора, который «оплачивает банкет», но не имеет маркетинговых компетенций. Ваша задача — выяснить зоны ответственности всех ЛПР и их вовлечённость в проект.

Хорошо, когда владелец участвует в проекте и общается с вами — тогда обсуждать и вносить изменения можно через него. Если владелец не принимает участие в обсуждениях, говорите только с ЛПР. Иначе может получиться так: вы будете встречаться и принимать решения, а потом придётся всё переделывать, потому что это не устраивает ЛПР.

Спецпроект о цифровых инструментах, которые помогают банкам, стартапам и другим финкомпаниям. Тексты экспертов и ничего лишнего:

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

Всё про диджитал для «финансов» →

Реклама

Пример.

Основатель и генеральный директор. Владелец проекта.

Операционный директор. ЛПР.

Директор отдела маркетинга. Главный ЛПР.

Digital-маркетолог. ЛПР.

Штатный дизайнер. ЛПР.

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

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

Влияние — насколько человек влияет на развитие проекта, может ли он принимать участие в управлении.

Важность — насколько человек влияет на результат.

График влияния стейкхолдера

1. Партнёры — влиятельные и важные для проекта люди. К ним нужно прислушиваться, обсуждать вопросы, учитывать интересы.
2. Консультанты — влиятельные люди с низким уровнем важности. С ними менеджер проекта обсуждает важные вопросы, но не лезет с мелочами.
3. Поддержка — важные, но не влиятельные сотрудники, держите их в курсе новостей. Когда появляются новые идеи и пожелания, идите к ним и рассказывайте.
4. Рядовые сотрудники — люди с низким уровнем влияния и важности. Это дизайнеры, верстальщики, разработчики, над которыми стоят главные — поддержка.

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

Шаг 3. Сбор и формализация требований

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

В AIC на первой встрече мы проводим презентацию компании: рассказываем о наших подходах, показываем кейсы на тематику клиента. Объясняем, как работает аналитика и UX-исследования, демонстрируем шоурилы.

Пример шоурила для встречи с клиентом.

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

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

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

Шаг 4. Аналитика

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

Владелец банковского сайта обратился к нам с задачей на редизайн. Он сказал, что их клиенты — успешные взрослые женщины и мужчины с зарплатой больше 100 тысяч, которые приходят за автокредитом и ипотекой. Мы проверили, и оказалось, что целевая аудитория — девушки 20–25 лет с зарплатой до 50 тысяч, которые берут потребительский кредит на отдых.

Концепция — визуальный дизайн, CJM, пользовательские сценарии — зависит от аудитории, и для всех она разная. Этот случай показывает, что аналитика помогает улучшить результат ещё до старта.

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

«Иногда приходят клиенты и говорят: „Вот наш сайт, подскажите как эксперты, что хорошо и что плохо“. Мы говорим: „Нет, мы не целевая аудитория“. Например, мы не можем оценить сервис для ипотеки. Мы не подходим к оценке экспертно, а привлекаем реальную аудиторию продукта».

Шага 5. Планирование и декомпозиция задач

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

1 этап. Первичная аналитика и данные заказчика. Мы составляем портрет целевой аудитории, проектируем пользовательские сценарии и проводим клиентские воркшопы.

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

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

1. Василий — суперзанятый, некогда сходить на обед. Ему важно успеть заказать обед незаметно для коллег во время совещания, буквально двумя кликами.
2. Василиса — сидит дома с детьми, заботится о здоровье, готова к новому опыту. Может проводить в приложении много времени: изучать состав, калории и так далее.

2 этап. Детальное проектирование: разрабатываем прототипы интерфейса, тестируем их на лояльной аудитории. Для «Азбуки вкуса» приглашали клиентов в офис и тестировали прототипы.

3 этап. Дизайн-концепция: дизайн, интерактив — всё это тоже проверяем на группе и согласуем с заказчиком.

4 этап. Внутренние страницы, ресайзы и так далее.

Чем подробнее расписаны задачи, тем легче их будет оценить.

Шаг 6. Оцените задачи

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

1. которые вы делали раньше;
2. которые вы не делали, но знаете, как;
3. которые вы не делали и о которых вам нужно узнать больше.

Первую группу вы оцениваете как всегда. Вторую оцениваете на основе своего опыта и интуиции, умножаете на 1,5–2. То же самое с третьей, только умножаете уже на 2–3. Сначала может показаться, что это слишком много, но к концу проекта вы будете думать иначе.

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

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

7. Составьте план проекта

В 5 шаге вы получили задачи и подзадачи. Чтобы не выбиться из графика и сдать проект в срок, следите за выполнением задач. Воспользуйтесь программой по управлению проектами, например, Microsoft Project.

Интерфейс MS Project

В MS Project можно выбрать один из встроенных шаблонов и подстроить его под свой проект: поставить задачи, распределить их между командой, определить длительность и установить зависимости между ними. Здесь же можно делать отчёты — стандартные ежеквартальные или в режиме реального времени. Для наглядности можно использовать диаграмму Ганта.

Диаграмма Ганта. Источник: medium

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

Сейчас мы пользуемся таск-трекером Jira + Confluence. До этого был Trello и Basecamp, некоторые сотрудники пользовались другими трекерами — кому что удобно. Из-за работы сразу в нескольких трекерах сложно аккумулировать знания, которые мы получали на проектах, поэтому мы сделали общую систему.

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

К старту готовы

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

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

Что нужно сделать до старта проекта? Требования к результатам проекта

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

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

Давайте обсудим процесс сбора и анализа требований к продуктам (результатам) проекта.

• Для компании, которая платит за проект, создается некая ценность – в виде материальных или нематериальных результатов проекта.
• В ходе своих рассуждений я воспользуюсь определением термина «результат проекта», которое дает Свод знаний по управлению проектами PMBOK V:
• Поставляемый результат (Deliverable) – любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта.
• В статье речь пойдет о сборе требований и их анализе к поставляемым результатам проекта, но я позволю себе заменить термин «поставляемый результат» на термин «результат проекта», сохранив при этом определение термина.

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

Давайте рассмотрим ситуацию на примере проекта «Внедрение CRM-системы в компании». Заказчик сформулировал следующие цели:

1. стандартизировать действия сотрудников при работе с клиентами компании;
2. сократить трудозатраты на выполнение отдельных операций;
3. повысить достоверность данных о клиентах.

И отсюда результаты проекта:

1. Регламент, описывающий работу сотрудников с клиентами
2. Программный продукт, автоматизирующий правила работы с клиентами, описанные в Регламенте
3. Обученные работе в программном продукте сотрудники компании
4. Работающий сервис поддержки пользователей программного продукта

1. Для того чтобы удовлетворить ожидания заказчика, руководителю проекта необходимо уточнить требования к каждому результату проекта.
2. Что такое требование?
3. Существуют десятки определений этого термина.
4. Например, в ISO 9000 написано следующее: Требование – это потребность или ожидание, которое установлено, обычно предполагается или является обязательным.
5. В IEEE Standard Glossary of Software Engineering Terminology (1990) приведена такая трактовка: Требование – это условия или возможности, необходимые пользователю для решения проблем или достижения целей.
6. За основу возьмем определение из ISO 9000, при этом будем считать, что ожидание считается установленным, если оно записано в документе, который согласовал заказчик.
7. Классификация требований
8. Для некоторых продуктов уже разработаны классификаторы требований, которые позволяют снизить вероятность того, что некоторые важные требования к продукту могут быть упущены.
9. Например, существуют классификаторы требований к программному обеспечению. Один из них представлен на рисунке 1:

©Карл И. Вигерс «Разработка требований к программному обеспечению»

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

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

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

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

Рассмотрим, какие могут быть требования к регламенту, описывающему правила работы с клиентами компании. Как мне кажется, они могут быть такими:

1. Регламент процесса должен содержать описание процесса в нотации …..(здесь нужно уточнить название нотации)
2. Регламент должен содержать матрицу ответственности с перечислением функций каждого участника процесса (к матрице ответственности тоже можно предъявить требования)
3. Документ не должен превышать определенное количество слов (это является ограничением)
4. Документ должен быть написан определенным шрифтом (можно указать его название и кегль)
5. В документе обязательно должны быть следующие разделы (к каждому можно предъявить требования по содержанию)
6. Документ должен содержать раздел, описывающий внесенные изменения в документ и т.д.

Конечно, при наличии классификатора требований к документам типа «Регламент» аналитику было бы проще учесть все классы требований, но такого классификатора я пока не встречал.

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

1. Сотрудники должны пройти обучение по работе с программным продуктом
2. Для обучения сотрудников должна быть разработана программа обучения (могут быть требования к содержанию программы)
3. Обучение должно проходить на реальных примерах компании. Примеры для обучения должны быть утверждены заказчиком проекта
4. По итогам обучения проходит тестирование знаний сотрудников. Средний балл по итогам тестирования на знание программного продукта составляет не менее ___ баллов (по 10-бальной шкале)
5. Требования к методике тестирования знаний сотрудников следующие…. и т. п.

Требования к работающему сервису поддержки программного продукта можно сформулировать так:

1. Стоимость сервиса поддержки в месяц
2. Время предоставления сервиса (например, с 8.00 до 20.00 по GMT+2)
3. Время реагирования на обращение в службу (к примеру, 30 минут с момента регистрации обращения в службе поддержки)
4. Время на решение проблемы, описанной в обращении пользователя (здесь нужно вводить классификацию обращений и по каждому из них определять норматив на закрытие обращения или на перевод его в другой статус)
5. Время на восстановление сервиса в случае сбоя
6. Возможность для пользователей отследить статус своего обращения
7. Возможность получить отчет по обращениям за определенный период и т. д.

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

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

Какие есть подходы к сбору требований к результатам проекта?

Самые распространенные подходы к сбору требований представлены на рисунке ниже:

Методы расположены на шкале сложности (отмечу, что расположение подходов на этой шкале – это мое субъективное мнение).

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

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

Анализ документов используется для выявления требований путем анализа существующей документации и идентификации информации, которая имеет отношение к требованиям. Существует множество документов, которые можно проанализировать для выявления требований.

Интервью — подход, используемый для получения информации у заинтересованных сторон путем диалога с ними.

В ходе интервью задают подготовленные и непосредственно возникающие вопросы и записывают ответы.

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

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

Мозговой штурм – подход, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к результатам проекта. Часто его используют вместе с другими подходами, которые предполагают приоритезацию собранных требований (например, метод номинальных групп, построение ассоциативных карт, диаграммы сходства и т. д.).

Инновационные игры – с помощью бизнес-игры модератор вовлекает заинтересованные стороны проекта в сбор требований к продукту и в ранжирование этих требований. Этот подход я уже описывал ранее в своей заметке: http://project-management.zis.by/uluchshenie-proektov/kak-povysit-tochnost-prognozirovanija-srokov-proekta.html

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

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

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

Моделирование процессов – метод используется для сбора требований к выполнению процесса (или некоторой деятельности).

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

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

QFD (quality function deployment) — подход, который помогает определить критически важные характеристики для разработки нового продукта, отталкиваясь от требований будущих пользователей.

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

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

После того как требования к результатам проекта собраны, их нужно проанализировать на предмет полноты, наличия противоречивых требований, наличия проблем с реализацией требований. Для решения этих задач аналитик требований может использовать такие инструменты, как реверсивный анализ требований, анализ систем-аналогов, ТРИЗ, Root Conflict Analysis Plus (RCA+), Value-Conflict Mapping +.

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

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

Итак, подведем итоги размышлений:

1. Успех проекта закладывается на его старте путем уточнения целей проекта, результатов проекта, требований к результатам.
2. Сбор требований к результатам проекта позволяет команде проекта понять, чего ожидают от результатов проекта заинтересованные стороны. На основании собранных и проанализированных требований команда может разрабатывать технические решения по реализации требований, определять список работ по проекту, прогнозировать трудозатраты работ проекта. Чем полнее требования к результатам проекта, тем точнее может сделать прогноз по трудоемкости проекта, срокам и бюджету руководитель проекта.
3. Собранные требования к результатам проекта нужно проанализировать на предмет их полноты, наличия противоречивых требований, наличия проблем с реализацией требований.
4. В проекте, в котором требуются сбор или уточнение собранных требований, нужно планировать использование аналитика требований, который должен владеть различными подходами к сбору и анализу требований.

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

Удачи вам при сборе и анализе требований в проектах!

С чего начинается любой проект ?

Когда вы сталкиваетесь с созданием проекта (неважно MVP это инновационной идеи или уже будущий highload сервис, который вам поручило реализовать руководство), он всегда будет проходить через ключевые точки. От того как вы расставите приоритетность этих точек, как подготовитесь к ним и как зафиксируете результат — будет зависеть успех проекта.

Для начала немного теории. Что же такое проект?

Это выполнение уникальной работы. У вас есть начало и конец + некий путь между этими двумя точками. Этот путь вы представляете себе как прямую линию (или почти прямую линию), из точки А в точку Б, где вы и должны получить результат, по которому измеряется успешность вашего проекта.

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

Итак, чем мы можем управлять в проекте:

Мы любим сравнивать IT проект со строительством. Так понятнее становятся многие вещи для Заказчика (ведь они превращаются в осязаемые процессы).

Давайте представим себе конструирование загородного дома. Его проектирование можно оптимизировать, выполнив адекватное планирование. Если создавать все в неверном (пусть даже местами) порядке — трудно будет создавать, тестировать и отлаживать процесс постройки (идея, проект, закупка материалов, закладка фундамента, возведение стен и т.д).

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

Тщательное планирование необходимо.

“Вы можете спланировать основные структурные компоненты и позднее решать, чем покрыть пол, в какой цвет покрасить стены, какой использовать кровельный материал и т. д. Хорошо спланированный проект открывает больше возможностей для изменения решения на более поздних этапах работы.” (Цитата С. Макконнелл “Совершенный код”)

Разные проекты (CRM, ERP, e-commerce, агрегаторы объявлений и т.д.) — требуют разного подхода в планировании. Существуют классические и гибкие методологии (постепенность процессов против коротких повторяющихся итераций) для управления проектами. Все методологии помогают нам расставить приоритеты и минимизировать потери на проекте, но не дают “серебрянной пули”.

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

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

Какие фазы проекта вас ожидают?

• Первая и самая начальная фаза, это зафиксировать для себя требования. Описать проект: его историю (описать как он возник), изменение бизнес-среды (может быть связано с экономикой, конкуренцией и т.д.), какой путь развития выбран для проекта и пояснить причину выбора. Определить конкретные результаты и выгоды, которые будут достигнуты.
• Планирование бюджетов и сроков. Обязательно установите временные рамки, в которые ожидается достижение целей. Желательно зафиксировать бюджет на риски, взять от максимальной планки около 30% (пусть это и будет запас на “Черный День”). Зарезервировать ресурсы (не только финансовые, но и временные, а также, необходимые специалисты — тоже являются ресурсами) для рисков, которые могут повлиять на проект. Если рисков слишком много, то необходимо переосмыслить задачу в голове.
• Содержание проекта. Представляете себе финальную точку и начинаете декомпозицию работ (это всегда должен быть актуальный и регулярно обновляющийся документ) или иерархическая структура работ (выписать все шаги по проекту, объединив в блоки).
• Этапы работы над проектом. Подходы к разработке зависят от предварительного понимания всех требований к системе, если на этапе проектирования возможно определить около 80% требований, то процесс будет более последовательным (скорее всего, это будут проекты, с уже отработанным бизнес-процессом, перенесение проекта на новые технологии, либо системы, которые влияют на здоровье/жизнь людей).

Рис.1 «Последовательный подход» (С. Макконнелл «Совершенный код»)

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

Рис.2 . «Итеративный подход» (С. Макконнелл «Совершенный код»)

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

• Управление рисками. Рисковое событие — это все факторы, влияющие на ход развития проекта. Произведите взвешивание по категориям: вероятность — случится это событие или нет, и влияние событий — низкое / высокое. Зарезервируйте ресурсы для рисков. Если рисков слишком много, то необходимо переосмыслить весь проект.

Определите и зафиксируйте антирисковые мероприятия.

• Зафиксируйте, что входит в проект и что выходит за его границы. Если вы меняете содержание — меняются сроки и бюджет. Нельзя внезапно захотеть делать вещи, которые изначально не предполагались.“Помните о бизнес-модели проекта. Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Требования, которые сначала казались прекрасными идеями, могут оказаться ужасными, когда вы оцените затраты” (Цитата С. Макконнелл “Совершенный код”)
• Зафиксируйте план управления вехами (события) — ориентиры, чтобы понять прибыли ли вы в точку, которая отражает необходимый результат или ещё нет. Веха — это результат события, но никак не процесс. Будьте внимательны! Перечислите и кратко опишите важные достижения проекта, которые будут служить основными контрольными точками оценки хода выполнения проекта и его стоимости. Как правило, это точки, в которых выполнение какого-либо действия или группы действий приводит к тому, что проект достигает вехи, производя очень заметный или значительный результат.

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

“Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и тестов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок” (Цитата С. Макконнелл “Совершенный Код”)

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

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

Какие же это будут этапы?

• Бюджетирование проекта. От чего зависит стоимость разработки?
• Техническое задание. Как правильно составлять?
• Проектирование и прототипирование проекта. Как правильно собрать данные и спроектировать понятный интерфейс с минимальным количеством переделок/доработок.
• Реализация проекта (как двигаться из точки А в точку Б). Первый релиз (альфа/бета/полноценный запуск)
• Поддержка проекта. Что входит и сколько это должно стоить ?

Заказчик отвечает за грамотную постановку цели, а Исполнители — помогает в достижении этой цели, делиться своим опытом. Грамотное управление и планирование приведет проект к поставленной цели (но помните, что есть еще внешние факторы и держите “руку на пульсе”).

P.S

Книга, которую мы так часто упоминали: https://www.bookvoed.ru/book?id=406093

Что нужно сделать до старта проекта. Часть 1

• – К чему в первую очередь сводится задача руководителя проекта? Размышляя над этим, я пришел к убеждению, чтоуправление проектом – это снижение
• неопределенности в нем.

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

Начинать снижать неопределенность нужно

1. еще до подписания устава проекта или контракта на проект.
2. Определение продуктов (результатов) проекта, а также проработка требований к каждому из них – одни из самых действенных способов, которые помогают снизить неопределенность. Чем точнее проработаны эти требования, тем легче руководителю
3. проекта и его команде спрогнозировать объемы работ, сроки и бюджет проекта.

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

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

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

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

3. После составления списка гипотез определяется, можно ли их уточнить и проверить до старта проекта. Если это возможно сделать только в ходе проекта и

1. команда проекта не может повлиять на гипотезы, то они являются допущениями.
2. Рассмотрим, как определить допущения на примере проекта «Внедрение в компании CRM-системы». Например, руководство компании сформулировало следующие цели
3. проекта:
4. * стандартизировать действия сотрудников при работе с клиентами компании; * сократить трудозатраты на выполнение отдельных операций;
5. * повысить достоверность данных о клиентах.
6. Заказчик проекта на основании целей определил продукты проекта:

1. Регламент, описывающий работу сотрудников с клиентами.

2. Программный продукт, автоматизирующий алгоритмы, описанные в Регламенте.

3. Обученные работе с программным продуктом сотрудники.

4. Работающий сервис поддержки пользователей программного продукта.

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

Как вы заметили, часто возникают сложности в вопросе: может ли команда проекта проверить гипотезу до старта проекта? Если она касается внешнего по отношению к проекту фактора, то ответить на него просто: команда проекта не может повлиять на природные явления, экономические или политические условия. Поэтому все, что

связано с действием этих факторов, будет допущениями проекта.

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

и их трудно изменить).

Как только мы сформулировали допущение, нужно поставить под сомнение его достоверность и сформулировать риски. Что, если сотрудники компании будут тратить на проект не 10% от рабочего времени, а гораздо меньше? В этом случае можно сформулировать риск: «Выделение ресурсов на проект в объеме, меньше чем

• планировалось, приведет к срыву сроков по задачам проекта».
• А что, если наше допущение о том, что руководители компании понимают, какие именно процессы входят в систему CRM, и имеют согласованную точку зрения по этому вопросу, неверно? Это приведет к тому, что при сборе требований к программному продукту топ-менеджмент не будет понимать границы системы CRM, а
• значит, и рамок проекта.
• Итак, идея работы с допущениями следующая:

1. Руководитель проекта генерирует гипотезы относительно целей и продуктов проектов, а также задач по его реализации.

2. Из гипотез отбираются допущения по проекту – по правилу, описанному выше.

3. Проводится анализ допущений с целью поиска пропущенных или неверных допущений.

4. Каждое допущение ставится под сомнение: «Что будет если оно не оправдается?» и формируется список рисков по допущениям.

5. Эти риски попадают в Реестр рисков, с ними проводится работа по антирисковому планированию.

1. Помните, что работа с рисками приводит к тому, что в проекте появляются дополнительные задачи. Это, скорей всего, приведет к увеличению сроков и
2. бюджета – по отношению к варианту проекта, в котором риски учтены не были.
3. Таким образом, анализ допущений помогает нам идентифицировать риски проекта и уточнить список работ по нему. Это помогает сделать расписание и бюджет более
4. адекватными.