С чего должна начинаться разработка проекта
С чего лучше начать проект или как сделать так, что бы не было потом мучительно больно
Доброго всем времени суток. Настала очередь поговорить о проектировании проектов. По собственному опыту знаю, что иногда сложнее создать проект с нуля, чем привести в порядок то, что уже есть. Во многом это связано с тем, какое наследие Вы или Вам, оставляют после себя. В этой статье постараюсь рассказать на что стоит обратить особое внимание и предложить краткий план следования.
Понимание проекта
Прежде чем что-то планировать, вам необходимо понять какой проект нужно реализовать. Для себя я выделил несколько категорий проектов, таких как:
Все градации условны и чаще всего встречаются перетекающие типы. Хочу заметить, что все типы могут мутировать друг в друга, единственный нюанс — в стоимости модернизации. Например, проект изначально был “одноразовая поделка”, а потом эволюционировал в “замкнутая система”. Обычно, подобное приводит к полному или почти полному переписыванию системы или ее рефакторингу. Как вы понимаете, это экономически нецелесообразно. По этой же причине желательно понять какой именно проект вам необходимо создать с нуля, и попытаться определить его дальнейшую судьбу.
Для определения типа проекта, ниже я привел вопросы, получив ответ на которые вам станет понятно, чего от Вас хотят:
Как вы видите, перечень не такой уж и большой. Правда, по какой-то неведомой причине, мало кто задаётся подобными вопросами до того, как начать что-либо делать. Вы спросите зачем мне понимать тип проекта?! Всегда надо делать так, чтобы проект жил вечность?! По большому счёту, вы правы, но есть нюансы, как в скабрезном анекдоте. Эти нюансы — ресурсы и сроки. Не стоит забывать, что мы трудимся на благо бизнеса и выполняем поставленные задачи. Когда вам известен тип проекта, вы можете без зазрения совести чем-то пожертвовать для достижения поставленных задач.
Выбор технологий
В выборе лучше придерживаться правила: технология не должна быть суперновой, но и устаревшей тоже. Если технология или фреймворк новые, это может обернуться такими проблемами как:
Данный перечень проблем актуален не только относительно технологий, но и к сторонним зависимостям. Всё вышеперечисленное может похоронить проект на корню.
Перед тем как выбрать что-то конкретное, подумайте несколько раз. Составьте пресловутую таблицу преимуществ с коэффициентами важности для проекта.
Данный пример составлен для вымышленного проекта:
Работа с проектом: этапы, особенности и артефакты
Начинаем серию статей для быстрого погружения в проджект-менеджмент. Весь курс в видеоформате можно бесплатно пройти на 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. Желаем удачи!
С чего начинается любой проект
От того, как вы расставите приоритетность этих точек, как подготовитесь к ним и как зафиксируете результат, будет зависеть успех проекта.
Для начала немного теории. Что же такое проект?
Это выполнение уникальной работы. У вас есть начало и конец + некий путь между этими двумя точками. Этот путь вы представляете себе как прямую линию (или почти прямую линию), из точки А в точку Б, где вы и должны получить результат, по которому измеряется успешность вашего проекта.
Хотим отметить, что регулярные (рутинные) процессы, которые вы ежедневно выполняете — не равны проектной деятельности. Проектные и процессные задачи не должны перемешиваться между собой. Проектные задачи должны регламентироваться отдельными правилами и нормами в вашей компании или команде.
Итак, чем мы можем управлять в проекте:
Мы любим сравнивать IT проект со строительством. Так понятнее становятся многие вещи для Заказчика (ведь они превращаются в осязаемые процессы).
Давайте представим себе конструирование загородного дома. Его проектирование можно оптимизировать, выполнив адекватное планирование. Если создавать все в неверном (пусть даже местами) порядке — трудно будет создавать, тестировать и отлаживать процесс постройки (идея, проект, закупка материалов, закладка фундамента, возведение стен и т.д).
Очень часто причиной закрытия так и не вышедшего в свет проекта — является нехватка бюджета. Большая часть этой нехватки — связана с неверным планированием в начале пути.
Тщательное планирование необходимо.
«Вы можете спланировать основные структурные компоненты и позднее решать, чем покрыть пол, в какой цвет покрасить стены, какой использовать кровельный материал и т. д. Хорошо спланированный проект открывает больше возможностей для изменения решения на более поздних этапах работы.» (Цитата С. Макконнелл «Совершенный код»)
Разные проекты (CRM, ERP, e-commerce, агрегаторы объявлений и т.д.) — требуют разного подхода в планировании. Существуют классические и гибкие методологии (постепенность процессов против коротких повторяющихся итераций) для управления проектами. Все методологии помогают нам расставить приоритеты и минимизировать потери на проекте, но не дают «серебрянной пули».
Невозможно реализовать проект быстро, дешево, с максимально возможной функциональностью, без рисков для вас и с наивысшим качеством. Так или иначе, все аспекты придут в баланс и будут друг другу соответствовать.
Любой проект проходит через фазы развития. Каждую из них можно пройти циклично по несколько раз, перед тем как переходить к следующей.
Какие фазы проекта вас ожидают?
Если на предварительном этапе выработки требований к проекту, можно описать только малую часть, то рекомендуется придерживаться более гибких методологий разработки и управлять проектом фрагментарно, определив на старте минимальные жизненно важные требования к проекту. Дополнительные требования добавляются по мере развития проекта. 
Определите и зафиксируйте антирисковые мероприятия.
«Помните о бизнес-модели проекта. Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Требования, которые сначала казались прекрасными идеями, могут оказаться ужасными, когда вы оцените затраты» (Цитата С. Макконнелл «Совершенный код»)
Обращайтесь за помощью к специалистам из финансовой, юридической, экономической, технической сферы, чтобы верно спланировать проект и не столкнуться в середине пути с тем, что нужно было решить вначале. Рекомендуем обращаться к потенциальным подрядчикам, т.к. это поможет определиться с выбором подрядчика и включиться им в работу.
«Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и тестов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок» (Цитата С. Макконнелл «Совершенный Код»)
Функциональные области в проекте это сроки, бюджет (стоимость), задачи (качество их выполнения), риски, выгоды, команда, интеграция (объединение всех областей). Всё нужно описать еще на старте и дальше переходить к выполнению этапов проекта.
Заказчик отвечает за грамотную постановку цели, а Исполнители — помогает в достижении этой цели, делиться своим опытом. Грамотное управление и планирование приведет проект к поставленной цели (но помните, что есть еще внешние факторы и держите «руку на пульсе»).
Этап подготовки проекта в теории
В данной статье рассмотрены теоретические основы важнейшего этапа в управлении проектами – именно его подготовки. Это должно быть интересно как новичкам в таком непростом деле, как менеджмент проектов, так и начинающим стартаперам, и возможно, опытным менеджерам.
Что же такое проект?
Проект – одноразовая, неповторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели.
В определенном смысле все проекты одинаковы. У всех есть потребитель (и) и \ или покровитель (и), которые ждут от реализации проекта достижения в определенное время результатов. Проекты часто реализуются с целью создания чего-то нового или осуществления больших изменений, которые можно рассматривать как завершенный вид деятельности. Проект может возникнуть исходя из новых запросов потребителей или пользователей услуг, либо из возможности получить выгоды для организации, либо на основании новых потребностей организации.
Не существует единственно «правильного» способа управления проектом. Традиционные подходы к управлению проектами сфокусированы на технических аспектах, и влиянию людей на реализацию проекта нередко уделяется меньше внимания. Однако именно люди заказывают и поддерживают проекты, поэтому лидерство, мотивация и управление вовлеченными в проект людьми так же важны, как и использование подходящих методов планирования, контроля и мониторинга.
Часто встречающиеся недостатки в реализации проектов:
На основании своих исследований Элбейк и Томас указали 10 факторов, которые многие определяют как критические для успеха проекта (расположены в соответствии с приоритетами):
Определение границ проекта
Проект начинается с идеи и возникает с целью удовлетворения потребностей человека. Идея состоит в том, чтобы сделать что-то, что кажется необходимым. Преобразование идеи в проект начинается с понимания природы потребности как движущей силы. Поэтому потребности являются основной движущей силой проекта.
Проблемы недостаточно точного определения потребностей:
Для того, чтобы понять масштабы проекта необходимо иметь следующую информацию:
ЗС и их потребности
В зависимости от особенностей проекта многие другие группы или отдельные люди могут быть заинтересованы в нем:
После того, как установлены основные ЗС, эту информацию необходимо использовать для того, чтобы обеспечить проекту максимально возможную поддержку. Обязательно нужно проверить, как реагируют на проект люди до того, как в процессе планирования будут исключены другие варианты его реализации. Если эту возможность использовать в полной мере, то команда проекта узнает о многих потенциальных препятствиях и будет хорошо информирована о приоритетах каждой группы. Один из способов понять реакции разных ЗС является анализ их точек зрения на каждое из ключевых измерений проекта – бюджет, время и качество.
Определение предназначения и целей проекта
Предназначение проекта является широким понятием и может быть соотнесено с миссией и ценностями организации, тогда как цели проекта определяют более точно, чего стремятся достичь, реализуя проект, и каким образом можно определить его успех.
Цели должны соответствовать критериям SMART:
Поставленные цели дают возможность определить шаги, с помощью которых может быть реализовано предназначение проекта и не позволить сбиться с правильного пути; использоваться для того, чтобы убедиться, что проект хорошо вписывается в деятельность организации.
Ясность целей важна для понимания того, что должно быть сделано. Если поставлены четкие цели, то это значит, что имеется определенная система взглядов на конечный результат. На основании поставленных целей происходит структурирование проекта с тем, чтобы его можно было эффективно контролировать и управлять им. Однако иногда возникает необходимость в пересмотре целей, поскольку в процессе осуществления проекта могут возникнуть новые обстоятельства, неизвестные на стадии планирования. Поэтому цели не должны быть «каменными».
Возможности и угрозы
Исследование возможностей и угроз на начальной стадии проекта может быть важным для определения его масштаба. Постоянные обсуждения с ЗС могут выявить многие потенциальные возможности и угрозы, связанные с проектом. Управление рисками (возможными угрозами проекту) будет рассмотрено ниже.
Проверка осуществимости проекта
Затраты и выгоды для оценки проекта
Риски и ситуационное планирование
Существует несколько способов выявления риска. Это в первую очередь обсуждение проекта с ЗС и рассмотрение различных перспектив, в ходе которых отдельные ЗС могут увидеть угрозы их интересам. Очень важно оценивать риск на каждом этапе реализации проекта и планировать возможные способы уменьшения его влияний. Там, где риск можно предвидеть, необходимо разработать ситуационный план, который можно применить, если ситуация риска реализуется.