С чего начинается выполнение проекта
С чего начать работу над проектом — памятка проект-менеджеру
Показывайте этот чеклист новичкам в проект-менеджменте. Материал подготовил Александр Яковлев, руководитель проектов AIC.
Проект — это всегда сложный процесс с несколькими сторонами и совместной работой. Сложности могут возникнуть разные: недостаток опыта, упрямый клиент или срыв дедлайнов. От всего не уберечься, но если подготовиться, будет попроще. Рассказываем о 7 базовых шагах подготовки к проекту, которые сэкономят силы и время.
Шаг 1. Определите владельца проекта и ответственного
В начале проекта сразу найдите владельца, именно он принимает решение о запуске проекта. Например, это может быть собственник бизнеса или руководитель отдела маркетинга. Помимо владельца определите ЛПР — лиц, принимающих решения. К ним могут относиться сотрудники ниже рангом: маркетинг, PR. Или даже те, кто участвует в задаче только косвенно, но влияет на принятие решения. К таким людям можно отнести, например, финансового директора, который «оплачивает банкет», но не имеет маркетинговых компетенций. Ваша задача — выяснить зоны ответственности всех ЛПР и их вовлечённость в проект.
Хорошо, когда владелец участвует в проекте и общается с вами — тогда обсуждать и вносить изменения можно через него. Если владелец не принимает участие в обсуждениях, говорите только с ЛПР. Иначе может получиться так: вы будете встречаться и принимать решения, а потом придётся всё переделывать, потому что это не устраивает ЛПР.
Всё, что нужно знать о рекламе в мобильных играх
Аналитический обзор Gameloft: рекламные форматы, портрет аудитории, надёжные бенчмарки.
Основатель и генеральный директор.
Владелец проекта.
Операционный директор.
ЛПР.
Директор отдела маркетинга.
Главный ЛПР.
Штатный дизайнер.
ЛПР.
Шаг 2. Определите стейкхолдеров
Стейкхолдеры — это заинтересованные в проекте люди, которые могут повлиять на владельца, руководителя, команду, конечных пользователей или других участников проекта.
Лучше выбрать отдельную тактику работы с каждым из заинтересованных лиц. Тактика зависит влияния и важности стейкхолдера.
Влияние — насколько человек влияет на развитие проекта, может ли он принимать участие в управлении.
Важность — насколько человек влияет на результат.
График влияния стейкхолдера
Когда все роли понятны, можно встречаться с заказчиком и собирать требования.
Шаг 3. Сбор и формализация требований
Каждая студия собирает требования клиента по-разному. Менеджер проекта присутствует на всех встречах, чтобы быть в курсе — именно ему предстоит уточнять, собирать дополнительные сведения, перепроверять и доносить мысли от заказчика команде и обратно.
В AIC на первой встрече мы проводим презентацию компании: рассказываем о наших подходах, показываем кейсы на тематику клиента. Объясняем, как работает аналитика и UX-исследования, демонстрируем шоурилы.
Важно подробно уточнить, как клиент видит будущий продукт. Часто клиент приходит и просит переделать сайт, потому что он плохо выглядит. Соберите максимум информации — что не нравится, почему, какие элементы вызывают негатив.
Продумайте все вопросы заранее, чтобы ничего не упустить при обсуждении. Посмотрите схему интервью Виктора Ченга, бывшего консультанта McKinsey & Company, — она поможет структурировать знания и передать их команде.
После того как вы собрали и уточнили требования, их нужно проверить.
Шаг 4. Аналитика
Иногда клиенты сами не понимают, что им нужно. В таком случае поможет предпроектная аналитика.
Владелец банковского сайта обратился к нам с задачей на редизайн. Он сказал, что их клиенты — успешные взрослые женщины и мужчины с зарплатой больше 100 тысяч, которые приходят за автокредитом и ипотекой. Мы проверили, и оказалось, что целевая аудитория — девушки 20–25 лет с зарплатой до 50 тысяч, которые берут потребительский кредит на отдых.
Концепция — визуальный дизайн, CJM, пользовательские сценарии — зависит от аудитории, и для всех она разная. Этот случай показывает, что аналитика помогает улучшить результат ещё до старта.
По итогу этого и предыдущего этапов у нас вырисовывается ряд проблем, которые проект должен решить. Самое время переходить к задачам.
«Иногда приходят клиенты и говорят: „Вот наш сайт, подскажите как эксперты, что хорошо и что плохо“. Мы говорим: „Нет, мы не целевая аудитория“. Например, мы не можем оценить сервис для ипотеки. Мы не подходим к оценке экспертно, а привлекаем реальную аудиторию продукта».
Шага 5. Планирование и декомпозиция задач
Если проект для вашей команды новый и уникальный, начните с конца. Представьте, как должен выглядеть готовый продукт и что нужно сделать для его воплощения в жизнь. Получится список стандартных задач: прототипирование, фронтенд, бэкенд, тестирование и так далее. Поделите задачи на подзадачи и распределите между командой. В AIC мы делим проект на 4 этапа, внутри каждого — свои задачи:
1 этап. Первичная аналитика и данные заказчика. Мы составляем портрет целевой аудитории, проектируем пользовательские сценарии и проводим клиентские воркшопы.
«Клиент понимает, что мы должны работать в одной команде. Внутри рабочей группы есть клиент и исполнитель, у каждого своя зона ответственности. Мы обсуждаем риски, как их устранить, эскалировать ситуацию. Прорабатываем MVP, разбиваем на составляющие, расставляем приоритеты: что делаем вперёд, что потом».
Количество воркшопов зависит от специфики проекта. Когда мы работали над «Азбукой вкуса», провели два. На первом обсуждали мобильное приложение для доставки готовых блюд, на втором — промоактивности на сайте. Условные клиенты были такие:
2 этап. Детальное проектирование: разрабатываем прототипы интерфейса, тестируем их на лояльной аудитории. Для «Азбуки вкуса» приглашали клиентов в офис и тестировали прототипы.
3 этап. Дизайн-концепция: дизайн, интерактив — всё это тоже проверяем на группе и согласуем с заказчиком.
4 этап. Внутренние страницы, ресайзы и так далее.
Чем подробнее расписаны задачи, тем легче их будет оценить.
Шаг 6. Оцените задачи
Чем больше проектов у вас за плечами, тем проще оценить время и стоимость каждого следующего. Менеджер оценивает задачи не в одиночку, он также опирается на опыт команды. Если проект в новинку для всех, разделите задачи на 3 группы:
Первую группу вы оцениваете как всегда. Вторую оцениваете на основе своего опыта и интуиции, умножаете на 1,5–2. То же самое с третьей, только умножаете уже на 2–3. Сначала может показаться, что это слишком много, но к концу проекта вы будете думать иначе.
Другой способ оценить неизвестные задачи — спросить у более опытного коллеги, который уже занимался подобными проектами. Согласуйте бюджет и сроки с клиентом, подписывайте документы и переходите к составлению плана.
По поводу согласования документов у нас довольно жёсткая позиция. Если видим в пункте договора потенциальные риски, наши юристы сразу их исключают или делают прозрачные формулировки. Иногда заказчик сопротивляется: «Мы не принимаем правки», — это тревожный звоночек. В таком случае мы можем и отказаться от проекта.
7. Составьте план проекта
В 5 шаге вы получили задачи и подзадачи. Чтобы не выбиться из графика и сдать проект в срок, следите за выполнением задач. Воспользуйтесь программой по управлению проектами, например, Microsoft Project.
Интерфейс MS Project
В MS Project можно выбрать один из встроенных шаблонов и подстроить его под свой проект: поставить задачи, распределить их между командой, определить длительность и установить зависимости между ними. Здесь же можно делать отчёты — стандартные ежеквартальные или в режиме реального времени. Для наглядности можно использовать диаграмму Ганта.
Диаграмма Ганта. Источник: medium
В диаграмме Ганта можно визуализировать задачи на графической шкале времени. Вы можете смотреть, что делает команда: кто когда должен начать и закончить задачу. Для наглядности можно использовать даже таблицы Excel.
Сейчас мы пользуемся таск-трекером Jira + Confluence. До этого был Trello и Basecamp, некоторые сотрудники пользовались другими трекерами — кому что удобно. Из-за работы сразу в нескольких трекерах сложно аккумулировать знания, которые мы получали на проектах, поэтому мы сделали общую систему.
Приготовьтесь к тому, что не все задачи будут завершаться вовремя, однако иногда это не плохо. В процессе работы у команды иногда появляются стоящие идеи, ради них можно немного сдвинуть сроки. Для этого изначально заложите небольшой запас времени.
К старту готовы
Если вы прошли все шаги, подготовку можно считать завершённой. Непредвиденные обстоятельства случаются всегда — невозможно предусмотреть всё, но с помощью грамотной подготовки можно минимизировать потери. Помните, что сложности в проекте — это опыт, который поможет вам подготовиться к следующему проекту ещё лучше.
С чего лучше начать проект или как сделать так, что бы не было потом мучительно больно
Доброго всем времени суток. Настала очередь поговорить о проектировании проектов. По собственному опыту знаю, что иногда сложнее создать проект с нуля, чем привести в порядок то, что уже есть. Во многом это связано с тем, какое наследие Вы или Вам, оставляют после себя. В этой статье постараюсь рассказать на что стоит обратить особое внимание и предложить краткий план следования.
Понимание проекта
Прежде чем что-то планировать, вам необходимо понять какой проект нужно реализовать. Для себя я выделил несколько категорий проектов, таких как:
Все градации условны и чаще всего встречаются перетекающие типы. Хочу заметить, что все типы могут мутировать друг в друга, единственный нюанс — в стоимости модернизации. Например, проект изначально был “одноразовая поделка”, а потом эволюционировал в “замкнутая система”. Обычно, подобное приводит к полному или почти полному переписыванию системы или ее рефакторингу. Как вы понимаете, это экономически нецелесообразно. По этой же причине желательно понять какой именно проект вам необходимо создать с нуля, и попытаться определить его дальнейшую судьбу.
Для определения типа проекта, ниже я привел вопросы, получив ответ на которые вам станет понятно, чего от Вас хотят:
Как вы видите, перечень не такой уж и большой. Правда, по какой-то неведомой причине, мало кто задаётся подобными вопросами до того, как начать что-либо делать. Вы спросите зачем мне понимать тип проекта?! Всегда надо делать так, чтобы проект жил вечность?! По большому счёту, вы правы, но есть нюансы, как в скабрезном анекдоте. Эти нюансы — ресурсы и сроки. Не стоит забывать, что мы трудимся на благо бизнеса и выполняем поставленные задачи. Когда вам известен тип проекта, вы можете без зазрения совести чем-то пожертвовать для достижения поставленных задач.
Выбор технологий
В выборе лучше придерживаться правила: технология не должна быть суперновой, но и устаревшей тоже. Если технология или фреймворк новые, это может обернуться такими проблемами как:
Данный перечень проблем актуален не только относительно технологий, но и к сторонним зависимостям. Всё вышеперечисленное может похоронить проект на корню.
Перед тем как выбрать что-то конкретное, подумайте несколько раз. Составьте пресловутую таблицу преимуществ с коэффициентами важности для проекта.
Данный пример составлен для вымышленного проекта:
С чего начинается любой проект
От того, как вы расставите приоритетность этих точек, как подготовитесь к ним и как зафиксируете результат, будет зависеть успех проекта.
Для начала немного теории. Что же такое проект?
Это выполнение уникальной работы. У вас есть начало и конец + некий путь между этими двумя точками. Этот путь вы представляете себе как прямую линию (или почти прямую линию), из точки А в точку Б, где вы и должны получить результат, по которому измеряется успешность вашего проекта.
Хотим отметить, что регулярные (рутинные) процессы, которые вы ежедневно выполняете — не равны проектной деятельности. Проектные и процессные задачи не должны перемешиваться между собой. Проектные задачи должны регламентироваться отдельными правилами и нормами в вашей компании или команде.
Итак, чем мы можем управлять в проекте:
Мы любим сравнивать IT проект со строительством. Так понятнее становятся многие вещи для Заказчика (ведь они превращаются в осязаемые процессы).
Давайте представим себе конструирование загородного дома. Его проектирование можно оптимизировать, выполнив адекватное планирование. Если создавать все в неверном (пусть даже местами) порядке — трудно будет создавать, тестировать и отлаживать процесс постройки (идея, проект, закупка материалов, закладка фундамента, возведение стен и т.д).
Очень часто причиной закрытия так и не вышедшего в свет проекта — является нехватка бюджета. Большая часть этой нехватки — связана с неверным планированием в начале пути.
Тщательное планирование необходимо.
«Вы можете спланировать основные структурные компоненты и позднее решать, чем покрыть пол, в какой цвет покрасить стены, какой использовать кровельный материал и т. д. Хорошо спланированный проект открывает больше возможностей для изменения решения на более поздних этапах работы.» (Цитата С. Макконнелл «Совершенный код»)
Разные проекты (CRM, ERP, e-commerce, агрегаторы объявлений и т.д.) — требуют разного подхода в планировании. Существуют классические и гибкие методологии (постепенность процессов против коротких повторяющихся итераций) для управления проектами. Все методологии помогают нам расставить приоритеты и минимизировать потери на проекте, но не дают «серебрянной пули».
Невозможно реализовать проект быстро, дешево, с максимально возможной функциональностью, без рисков для вас и с наивысшим качеством. Так или иначе, все аспекты придут в баланс и будут друг другу соответствовать.
Любой проект проходит через фазы развития. Каждую из них можно пройти циклично по несколько раз, перед тем как переходить к следующей.
Какие фазы проекта вас ожидают?
Если на предварительном этапе выработки требований к проекту, можно описать только малую часть, то рекомендуется придерживаться более гибких методологий разработки и управлять проектом фрагментарно, определив на старте минимальные жизненно важные требования к проекту. Дополнительные требования добавляются по мере развития проекта. 
Определите и зафиксируйте антирисковые мероприятия.
«Помните о бизнес-модели проекта. Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Требования, которые сначала казались прекрасными идеями, могут оказаться ужасными, когда вы оцените затраты» (Цитата С. Макконнелл «Совершенный код»)
Обращайтесь за помощью к специалистам из финансовой, юридической, экономической, технической сферы, чтобы верно спланировать проект и не столкнуться в середине пути с тем, что нужно было решить вначале. Рекомендуем обращаться к потенциальным подрядчикам, т.к. это поможет определиться с выбором подрядчика и включиться им в работу.
«Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и тестов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок» (Цитата С. Макконнелл «Совершенный Код»)
Функциональные области в проекте это сроки, бюджет (стоимость), задачи (качество их выполнения), риски, выгоды, команда, интеграция (объединение всех областей). Всё нужно описать еще на старте и дальше переходить к выполнению этапов проекта.
Заказчик отвечает за грамотную постановку цели, а Исполнители — помогает в достижении этой цели, делиться своим опытом. Грамотное управление и планирование приведет проект к поставленной цели (но помните, что есть еще внешние факторы и держите «руку на пульсе»).
Работа с проектом: этапы, особенности и артефакты
Начинаем серию статей для быстрого погружения в проджект-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь первый урок в текстовом виде — для тех, кому удобнее читать.
Этапы проекта
Любой проект состоит из четырёх этапов: инициализации, планирования, реализации и завершения. Рассмотрим каждый подробнее.
Инициализация. Заказчик приходит к проджект-менеджеру с запросом. Менеджер анализирует бизнес-идею (определяет содержание и длительность проекта), разрабатывает проектное задание и выполняет стратегическое планирование.
Планирование. Проджект-менеджер определяет, из каких специалистов будет состоять команда, каковы объёмы проекта, его этапы и контрольные точки для сверки с заказчиком. Также выявляет возможные риски и рассчитывает ресурсы.
Реализация. Проджект помогает команде создать конечный продукт или его часть — для этого отслеживает и контролирует каждый из этапов, решает проблемы, информирует заказчика о ходе проекта и управляет изменениями.
Завершение. Проджект-менеджер сдаёт продукт заказчику, оценивает уровень удовлетворённости клиента и приобретённый опыт. Фиксирует успехи, неудачи и их причины, чтобы стать эффективнее и избежать негативного опыта в будущем.
Проектные артефакты
Артефакты проекта — это физические носители информации, которые подтверждают договорённости и позволяют всем членам команды следить за ходом проекта. Например, договор, коммерческое предложение, техническое задание, сопроводительные документы, исполняемые файлы, исходные тексты, веб-страницы, файлы с данными и справочной информацией. При этом универсального набора артефактов не существует — на каждом проекте он свой.
Рассмотрим, как распределяются артефакты на каждом из этапов проекта. При этом от проекта к проекту набор будет немного разным.
Инициализация: техническое задание, коммерческое предложение, договор и приложение к нему, дополнительное соглашение.
Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.
Реализация: акт сдачи-приёмки работ, замечания и доработки.
Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.
Так могут выглядеть основные артефакты по IT-проекту:
Сбор артефактов
Проджект-менеджер собирает артефакты проекта во время согласования требований с заказчиком и уточнения деталей — лучше показаться дотошным и избежать недоразумений, чем поскромничать и недопонять клиента.
Проджект обсуждает требования с командой, чтобы быть уверенным, что каждый понял свою задачу и выполнит работу корректно. Это ещё один этап, на котором формируются артефакты проекта.
Проджект-менеджер согласовывает результаты с конечными пользователями — это подтверждает, что команда делает именно то, что нужно заказчику.
Результаты каждой встречи фиксируются — это позволяет избегать многих неприятных ситуаций. Например, если заказчик попросит разработать новую фичу, которая не была прописана в изначальном техническом задании, — будет возможность обсудить условия дополнительной оплаты и новые сроки. Клиент не сможет сказать, что он говорил о ней ранее и вы обещали реализовать её в рамках стандартной оплаты. Также это не позволит заказчику выставить одни требования, а затем сказать: «Я видел это совсем иначе». У вас всё зафиксировано!
После встречи проджект рассылает её итоги всем участникам проекта, а клиента просит подтвердить, что он тоже ознакомился с ними. Если он не отвечает, то менеджер не стесняется напомнить о письме.
Виды артефактов
Артефакты делятся на формальные и неформальные.
Формальные — обязательные, прописанные в договоре, на которых стоят реквизиты заказчика и исполнителя. Также к формальным артефактам относится документация и элементы, которые указаны в официальных документах. Если в договоре написано, что исполнитель обязан предоставить результаты исследования, то они будут формальным артефактом.
Неформальные артефакты — вся остальная информация: итоги переписок, сообщения в мессенджерах, записи с флипчарта, на котором команда фиксирует ход проекта, стикеры с канбан-доски и даже матрица RACI.
Виды заказчиков
Заказчиков принято разделять по двум принципам. Первый — по традиционному объёму документации, который необходимо вести по проекту. Второй — с точки зрения того, как происходит процесс взаимодействия до запуска проекта. В этой классификации выделяют четыре вида заказчиков:
Есть и другая категоризация заказчиков — по ней они могут быть внутренними и внешними. Внутренний заказчик — это смежный отдел. Если GeekBrains закажет IT-решение у отдела разработки, входящего в Mail.ru Group, то станет для него внутренним заказчиком — всё будет происходить в рамках одной компании. Если GeekBrains поставит задачу разработать IT-решение стороннему подрядчику, то выступит для него внешним заказчиком.
Зона ответственности заказчика
Работая в любом проекте, нужно понимать, к кому и с каким вопросом обращаться: что может решить заказчик, что руководитель, а когда стоит получить больше информации от команды. Чтобы не растеряться в самый неподходящий момент, на старте нужно распределить зоны ответственности. Один из классических инструментов для этого — матрица RACI.
Матрица RACI — это таблица, в которой проджект-менеджер по горизонтали вписывает зоны ответственности, а по вертикали — исполнителей и другие действующие лица на проекте (заказчиков, членов команды, подрядчиков). Этот инструмент помогает распределить ответственность ещё на этапах инициализации и планирования проекта.
В матрице выделяется четыре зоны ответственности: R — responsible (исполняет), A — accountable (несёт ответственность) C — consult before doing (консультирует до исполнения), I — inform after doing (оповещает после исполнения). Рассмотрим это на примере.
По горизонтали прописаны зоны ответственности, а по вертикали — действующие лица. Анна разрабатывает устав, а Бен несёт ответственность за выполнение этой задачи. Если у кого-то из членов команды появится вопрос про устав, он сразу поймёт, к кому обратиться.
Чтобы составить матрицу RACI, нужно выполнить следующие шаги:
При этом важно соблюдать основные принципы:
Удержать все эти вещи в голове непросто, но благодаря практике можно стать эффективным проджект-менеджером. Попробуйте начать свой путь в профессии с бесплатного курса GeekBrains. Желаем удачи!
Начинаем серию статей для быстрого погружения в проджект-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь первый урок в текстовом виде — для тех, кому удобнее читать.
Этапы проекта
Любой проект состоит из четырёх этапов: инициализации, планирования, реализации и завершения. Рассмотрим каждый подробнее.
Инициализация. Заказчик приходит к проджект-менеджеру с запросом. Менеджер анализирует бизнес-идею (определяет содержание и длительность проекта), разрабатывает проектное задание и выполняет стратегическое планирование.
Планирование. Проджект-менеджер определяет, из каких специалистов будет состоять команда, каковы объёмы проекта, его этапы и контрольные точки для сверки с заказчиком. Также выявляет возможные риски и рассчитывает ресурсы.
Реализация. Проджект помогает команде создать конечный продукт или его часть — для этого отслеживает и контролирует каждый из этапов, решает проблемы, информирует заказчика о ходе проекта и управляет изменениями.
Завершение. Проджект-менеджер сдаёт продукт заказчику, оценивает уровень удовлетворённости клиента и приобретённый опыт. Фиксирует успехи, неудачи и их причины, чтобы стать эффективнее и избежать негативного опыта в будущем.
Проектные артефакты
Артефакты проекта — это физические носители информации, которые подтверждают договорённости и позволяют всем членам команды следить за ходом проекта. Например, договор, коммерческое предложение, техническое задание, сопроводительные документы, исполняемые файлы, исходные тексты, веб-страницы, файлы с данными и справочной информацией. При этом универсального набора артефактов не существует — на каждом проекте он свой.
Рассмотрим, как распределяются артефакты на каждом из этапов проекта. При этом от проекта к проекту набор будет немного разным.
Инициализация: техническое задание, коммерческое предложение, договор и приложение к нему, дополнительное соглашение.
Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.
Реализация: акт сдачи-приёмки работ, замечания и доработки.
Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.
Так могут выглядеть основные артефакты по IT-проекту:
Сбор артефактов
Проджект-менеджер собирает артефакты проекта во время согласования требований с заказчиком и уточнения деталей — лучше показаться дотошным и избежать недоразумений, чем поскромничать и недопонять клиента.
Проджект обсуждает требования с командой, чтобы быть уверенным, что каждый понял свою задачу и выполнит работу корректно. Это ещё один этап, на котором формируются артефакты проекта.
Проджект-менеджер согласовывает результаты с конечными пользователями — это подтверждает, что команда делает именно то, что нужно заказчику.
Результаты каждой встречи фиксируются — это позволяет избегать многих неприятных ситуаций. Например, если заказчик попросит разработать новую фичу, которая не была прописана в изначальном техническом задании, — будет возможность обсудить условия дополнительной оплаты и новые сроки. Клиент не сможет сказать, что он говорил о ней ранее и вы обещали реализовать её в рамках стандартной оплаты. Также это не позволит заказчику выставить одни требования, а затем сказать: «Я видел это совсем иначе». У вас всё зафиксировано!
После встречи проджект рассылает её итоги всем участникам проекта, а клиента просит подтвердить, что он тоже ознакомился с ними. Если он не отвечает, то менеджер не стесняется напомнить о письме.
Виды артефактов
Артефакты делятся на формальные и неформальные.
Формальные — обязательные, прописанные в договоре, на которых стоят реквизиты заказчика и исполнителя. Также к формальным артефактам относится документация и элементы, которые указаны в официальных документах. Если в договоре написано, что исполнитель обязан предоставить результаты исследования, то они будут формальным артефактом.
Неформальные артефакты — вся остальная информация: итоги переписок, сообщения в мессенджерах, записи с флипчарта, на котором команда фиксирует ход проекта, стикеры с канбан-доски и даже матрица RACI.
Виды заказчиков
Заказчиков принято разделять по двум принципам. Первый — по традиционному объёму документации, который необходимо вести по проекту. Второй — с точки зрения того, как происходит процесс взаимодействия до запуска проекта. В этой классификации выделяют четыре вида заказчиков:
Есть и другая категоризация заказчиков — по ней они могут быть внутренними и внешними. Внутренний заказчик — это смежный отдел. Если GeekBrains закажет IT-решение у отдела разработки, входящего в Mail.ru Group, то станет для него внутренним заказчиком — всё будет происходить в рамках одной компании. Если GeekBrains поставит задачу разработать IT-решение стороннему подрядчику, то выступит для него внешним заказчиком.
Зона ответственности заказчика
Работая в любом проекте, нужно понимать, к кому и с каким вопросом обращаться: что может решить заказчик, что руководитель, а когда стоит получить больше информации от команды. Чтобы не растеряться в самый неподходящий момент, на старте нужно распределить зоны ответственности. Один из классических инструментов для этого — матрица RACI.
Матрица RACI — это таблица, в которой проджект-менеджер по горизонтали вписывает зоны ответственности, а по вертикали — исполнителей и другие действующие лица на проекте (заказчиков, членов команды, подрядчиков). Этот инструмент помогает распределить ответственность ещё на этапах инициализации и планирования проекта.
В матрице выделяется четыре зоны ответственности: R — responsible (исполняет), A — accountable (несёт ответственность) C — consult before doing (консультирует до исполнения), I — inform after doing (оповещает после исполнения). Рассмотрим это на примере.
По горизонтали прописаны зоны ответственности, а по вертикали — действующие лица. Анна разрабатывает устав, а Бен несёт ответственность за выполнение этой задачи. Если у кого-то из членов команды появится вопрос про устав, он сразу поймёт, к кому обратиться.
Чтобы составить матрицу RACI, нужно выполнить следующие шаги:
При этом важно соблюдать основные принципы:
Удержать все эти вещи в голове непросто, но благодаря практике можно стать эффективным проджект-менеджером. Попробуйте начать свой путь в профессии с бесплатного курса GeekBrains. Желаем удачи!