Ход проекта

Ссылки по методологии ведения проектов

https://studfile.net/preview/9442443/page:24/

https://www.itpedia.nl/ru/2019/01/16/wat-heeft-een-functioneel-ontwerp-te-bieden/

https://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework#%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2_MSF

 

 

Необходимые условия успешности проекта

• • Четкий формализованный план каждого этапа
  • Харизма
  • Не обещать невозможного
  • Всем понятная целесообразность - зачем мы делаем этот проект. Деньги понятны всем.

Риски

• • Риски со стороны Заказчика
    • Основной риск - потеря интереса к проекту - по двум основным причинам
      • Сомнения в целесообразности проекта 
      • Сомнения в выборе Исполнителя
  • Риски Исполнителя
    • Не уложиться в сроки
    • Превысить объём работ и стоимость проекта
    • Пассивность в проекте (Исполнителя или Заказчика)
    • Изменение приоритета проекта (для Исполнителя или Заказчика)
    • Смена состава Рабочей группы в процессе выполнения проекта
    • Формальный подход со стороны Исполнителя (отсутствие заботы)

 

Цель предпроекта: 

Определить Цели проекта и Заказчика

• • Необходимое для входа в проект
    • Кто наш Заказчик?
    • Общее понимание целей Заказчика
      • Цель - чего мы должны достичь в результате. (ответ на вопрос "Для чего вам это нужно")
  • Предложить Заказчику понятный и приемлемый способ достижения этих целей
    • ТЗ с описанием бизнес-процессов

Как достичь взаимопонимания относительно целей клиента?

• • Совместная с клиентом приёмка результатов предпроекта
  •  

Поддержание заинтересованности Владельца проекта в проекте

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

Как уладить

• • • • • Постоянно поддерживать заинтересованность КС в проекта
          • Как?
          •  
        • Только через ключевых сотрудников - "Если моим сотрудникам это надо - пускай будет"
        • Ключевые сотрудники компании должны постоянно транслировать ВП свою заинтересованность
        • Поддерживать постоянный контакт с неким перечнем ключевых сотрудников
        • Нужно понимать, а кого ВП будет слушать - определить перечень ключевых сотрудников
        • Нужна первоначальная, где каждый из КС подтвердит свою заинтересованность в проекте
          • чтобы под протокол все сказали "Да" проекту
          • когда? - это нужно вообще для того, чтобы начать проект. Пока мы не удовлетворим всех КС проект не может быть начат.
        • Нужные постоянные встречи, где они будут подтверждать свою заинтересованность

Критерии успеха проекта

• • Деньги
    • Соблюсти юридическую сторону вопроса
      • Всё выполнить
      • Всё правильно оформить
  • Удовлетворённость клиента
    • Соответствие ожиданиям
      • Выполнение в срок (именно что они понимают под сроками)
      • Полнота выполнения работ (без косяков, без недоработок - чтобы можно было пользоваться)
      • Уложиться в оговоренный в начале бюджет
    • Эмоциональная составляющая (приятно общаться. не напрягать друг друга, быть нетоксичными)

 

 

Термины и определения

Продукт - это то, что хочет получить Заказчик.

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

Проект - это процесс создания Продукта. То, что делает команда, чтобы выдать Заказчику Продукт.

Цель проекта - клиент получил то, что хотел получить. Свою реализованную потребность.

РП - его цель - получить деньги. Гасить конфликты, поддерживать коммуникацию.

 

Общие принципы

Нельзя продавать идеальную картину.

Идеальных проектов не бывает. Это нужно обязательно донести до клиента. Не заниматься шапкозакидательством.

На выходе должен быть конкретный объём работ в оговоренные сроки.

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

 

Обязательно выходить на первых лиц компании

• • оцифровать их ожидание
  • услышать их мнение
  • ваши ребята классные
  • давайте сформулируем цели
  • совпадают с ЦиЗ рабочей группы - супер
  • сдали работы рабочей группе
  • обучили сотрудников
  • "Мы сделали большое количество объектов, у нас большой опыт. но вы должны чётко понимать, что есть промежуточный результат, который назвается "Пилот" и он обязательно будет иметь какие-то баги и ошибки. Нельзя учесть вообще всё. Проблемы будут. Наша задача на этапе Пилота понять, что мы сделали правильно, а что мы не учли. Когда мы завершим пилот, мы сделаем встречу и отчитаеся о достигнутых результатах проекта."
  • Всё заканчивается финальной презентацией "Успехи проекта"
  • Что мы сделали правильно, где допустили ошибки, что нужно бы сделать

 

Еженедельные встречи Рабочей группы

Раз в неделю в одно и то же время нужно назначать встречи совместной Рабочей группы. И по её итогам корректировать сроки и объём работ.

При изменении сроков нужно высылать новую диаграмму Гантта всем членам рабочей группы с комментарием "По итогам совещания от ... изменились сроки и объём работ по таким-то причинам"

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

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

 

Клиент поддерживается в нормальном состоянии путём управления:

 

 

DRAFT

 

Стадии проекта:

• • Начало
  • Выполнение/мониторинг
  • Завершение

 

 

Удовлетворённость Заказчика зависит от управления:

• • сроками
  • стоимостью
  • содержанием работ
  • риски
  • ожидания
  • настроения
  • коммуникация

                

 

Управление настроениями

Возможно - согласованная отчётность

...

...

 

Управление изменениями

 

Управление конфликтами

Это задача Руководителя проекта - через рабочие встречи, постоянную корректировку и согласование изменений в плане проекта

 

Документы проекта

Паспорт проекта

• • • • Цели и задачи проекта (??)
        • ...
        • ...
        • ...
      • Владелец проекта (спонсор проекта) - собственник компании, тот, кто даёт деньги.
        • После согласования проекта (???) и перед подписанием договора нужно встретиться и:
          • Рассказать о целях и задачах проекта, согласованных с рабочей группой и спросить, насколько они совпадают с его целями и задачами.
          • Он подписывает договор, приложением которого является Паспорт проекта.
          •  
        • Нужно обязательно выйти на него и зафиксировать его ожидания от проекта.
          • Шамса:
            • Всё производство, которое есть в торговой сети должно работать в одном информационной системе, которая должна отвечать следующим требованиям:
              • всем актуальным требованиям со стороны законодательства
              • вся согласованная отчётность должна своевременно передаваться в 1С в согласованном формате
              •  
            •  
        • Он должен чётко понимать, что он получит на выходе
        • Если мы видим расхождения ожиданий, то мы не должны это пропускать, нельзя продавать воздушный шарик.
        • В ходе реализации и движения по контрольным точкам возвращать клиента к целям и задачам проекта.
        •  
      • Заказчик
      • Рабочая группа
        • Руководитель рабочей группы
        • Состав рабочей группы со стороны Заказчика и со стороны Исполнителя
        • Контактные данные
        • Способы коммуникации
      • Сформулированный результат проекта, который соответствует ожиданиям клиента и который мы сможем сдать.
      • Что нужно дать клиенту, чтобы проект считался завершённым успешно.
      • Объём работ (?)

План проекта

• • • • Диаграмма Гантта

 

 

Шамса

1. Себестоимость - чтобы не было плановой себестоимости, а была реальная.
2. Меркурий - чтобы работал автоматически при отгрузках (сейчас делают через 1С вручную)
   1. проставление даты отгрузки в строках - нужно автоматически, сейчас в каждой строке проставляют вручную (2000 строк/день)
3. Инвентаризация
   1. автоматическое разбиение п/ф на ингредиенты (сейчас вручную раскладывают по рецептам, тратят на это 3-4 дня)
4. уменьшение расхождений при инвентаризации - сейчас платят с них 30% налогов, нужно спрятать их в реализацию.

 

История проекта

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

 

Риски проекта

...

...

 

 

Порядок выполнения проекта:

1. Зафиксировать ожидания клиента от реализации проекта.
2. Предоставить дорожную карту проекта
3. Согласовать стоимость работ
4. Согласовать сроки
5. Сформировать перечень промежуточных результатов, достижение которых будет считаться достижением результата проекта - что мы будем сдавать. 

 

Нам нужен протокол, интерфейс взаимодействия с клиентами:

 

 

МП - менеджер по продажам

 

Порядок действий по проекту

 

Действие	Кто делает	Результат	Документ на выходе
Принять звонок, получить бриф	Менеджер1	Узнал, что за клиент, каковы  первичные задачи и потребности. Тут же отправляет бриф с вопросами и договориться, когда клиент его пришлёт. Договорился, когда можно перезвонить клиенту. Передать клиенту прямой телефон МП.	Создать карточку клиента в планфиксе. Отразить в карточке клиента то, что выяснил о клиенте и его потребностях. Создать себе  в планфиксе задачу получить бриф. После получения брифа создать задачу на МП, прикрепить к задаче заполненный бриф.
Договориться на презентацию	МП	Созвониться, представиться как менеджер проекта, подтвердить  данные в брифе и интерес клиента. Выяснить более подробно что за клиент и что ему надо. Согласовать дату и время презентации и тайминг - что нужно не менее часа времени для проведения качественной презентации.	Создать задачу на проведение презентации на себя. Создать задачу подготовить презентацию.
Подготовка презентации	МП	Прогнать презентацию, убедиться, что презентация отвечает интересам клиента	Дополнить или закрыть задачу на подготовку презентации.
Проведение презентации	МП	Познакомиться со всеми участниками, установить контакт, попросить клиента немного рассказать о себе. Рассказать о себе. Вкратце. Задать цель встречи и выяснить тайминг. Резюмировать результат брифа, подтвердить, что у клиента  именно такие вопросы. Проводим презентацию продукта. Проводим презентацию проектного подхода (отвечаем на вопрос клиента " - Как вы работаете"). Спрашиваем, остались ли вопросы Договариваемся о следующем действии - КП, либо пресейл. Согласовываем протокол - о чём договорились, какие вопросы остались. Отправляем клиенту протокол.	Протокол встречи (прикрепить к задаче на проведение презентации). Задачи на дальнейшие действия.
Подготовка подробной презентации под клиента	Эксперт	1. Согласование затрат на подготовку подробной демонстрации. 2. Подготовка подробной демонстрации по итогам которой клиент принимает принципиальное решение о том, что мы ему подходим.	Задача на подготовку подробной демонстрации
Подробная демонстрация с выведением клиента на принятие решения о том, что мы ему подходим	Эксперт	Проведение подробной демонстрации под клиента: Знакомство Тайминг Презентация Повторная презентация проектного подхода Согласование дальнейших действий Согласование протокола Отправить протокол	Протокол презентации (приложить к задаче) Создать задачи на дальнейшие действия - либо доп.презентация, либо КП
КП	МП	Отправляем предварительное КП (оценка стоимости проекта). Позвонить, спросили получили ли, есть ли вопросы, сколько времени на ответ. Получить решение клиента.	КП
Стандартный договор на предпроект (не гарантирует выполнения проекта)	МП	Встреча с владельцем проекта (кто  принимает решение о финансировании проекта). Согласовать условия предпроекта. Добиться подписания договора на предпроект.	Договор на предпроект
Получить предоплату за предпроект	МП	Получить предоплату за предпроект	Зачисление не счёт
Проведение предпроектного обследования, составление Концептуального проекта.	Эксперт	Составить описание текущего/будущего документооборота и бизнес-процессов. Предложить и утвердить архитектуру ИС. Утвердить у заказчика Концептуальный проект.	Концептуальный проект : 1. Описание бизнес-процессов. 2. Общая архитектура ИС.
Составить Рабочий проект	Эксперт	Рабочий проект описывает способы, какими  будет реализован Концептуальный проект, не углубляясь в детали реализации. 1. Составить Рабочий проект с разбивкой на этапы. 2. Для каждого этапа сделать оценку сроки и стоимость.	1. Рабочий проект, этапы. 2. Оценка сроков и стоимости по этапам.
Согласование Рабочего проекта, порядка финансирования и порядка сдачи-приёмки.	МП	1. Согласовать с клиентом Рабочий проект, этапы, оценку сроков и стоимости по этапам. 2. Определить порядок финансирования  этапов проекта - фиксированная стоимость этапа или по объёму выполненных работ; - порядок оплаты - размер предоплаты и окончательный расчёт; - порядок сдачи-приёмки работ по этапам проекта.	1. Согласованный с клиентом Рабочий проект. 2. Согласованный с клиентом порядок оплаты по этапам проекта. 3. Согласованный с клиентом порядок сдачи-приёмки работ по проекту.
Составление ТЗ на доработки, по этапам Рабочего проекта, в разрезе используемых в проекте продуктов, расчёт их стоимости.	Владелец Продукта (ВП)	1. Составить перечень доработок. 2. Рассчитать длительность и стоимость доработок.	ТЗ по этапам проекта. (конкретные работы, длительность, стоимость)
Финальное КП		Лицензии Доработки Внедрение Поддержка	КП
Инициация проекта.		Подготовка документов Паспорт проекта План проекта Формирование Рабочей группы. Проведение установочной встречи Рабочей группы.	Документы проекта. Протокол о создании РГ. Протокол установочные встречи.
Заключение основного договора на проект		Встреча с собственником. Подписание лицензионного договора. Подписание договора на доработки. Договор на внедрение Выставление счетов.	Подписанные договора.
Первоначальное внедрение (функционала, возможное без доработок)		Установить систему клиенту. Перенос справочников. Запуск для демонстрации работоспособности, что уже в принципе можно работать, играться, привыкать. Первоначальное обучение (IT). Демо-стенд.	Акт передачи прав по лицензионному договору.
Выполнение доработок (параллельно с внедрением)
Внедрение		1. Отправка требований к оборудованию 2. Установка тестовой и контрольной базы 3. Обучение ИТ и менеджера продукта с работой основного функционала (заведение карточек и пр.) 4. Клиент заполняет контрольную базу документами (товары / цены / договоры) 5. Передача клиенту выполненных доработок в виде сервис-пак 6. Клиент на тестовой базе проверяет что все фичи сделаны в соответствие с изначальными требованиями - подписание акта сдачи/приёмки по доработкам. 7. Согласовывается дата старта пилотного объекта 8. Организация выезда тех специалиста для проведения авторского надзора (2-3 дня) на момент страта 9. Старт пилота (первого объекта)	Акты сдачи/приёмки по доработкам
Завершение проекта		10. Установочная встреча с РГ по результатам и замечаниям 11. Подготовка презентации по итогам проекта 12. Проведение презентации перед РГ и спонсором проекта
Сдача/приёмка проекта		13. Подписание акта-передаче работ 14. Закрытие проекта 15. Передача на саппорт (остальные объекты запускаются в рамках техподдержки)	Акты по договору на внедрение.
Поддержание проекта в живом состоянии		Заказчик должен назначить сотрудника, ответственного за достижение задач проекта после этапа внедрения. Чтобы остальные сотрудники не перестали пользоваться программой, чтобы наладить сбор требований и пожеланий с тех сотрудников, которые непосредственно работают в программе. В целом, чтобы проект был полезным бизнесу и бизнес достиг тех результатов, которые планировались. Цель - чтобы владелец бизнеса получил не только программу, но тот результат, на который рассчитывал. Должен быть подписан документ("Пост-проект"), который устанавливает ответственных со стороны заказчика исполнителя и порядок коммуникации между ними. Документ должен предусматривать регулярное информирование Исполнителя со стороны Заказчика об успешности проекта и возникающих трудностях.	Пост-проект

 

 

Методика взаимодействия по задачам в проекте

1. Формирование рабочей группы с участием представителей заказчика и исполнителя.
2. Назначение руководителей рабочей группы с обеих сторон. Руководители несут ответственность за результативность проекта.
3. Проведение установочной встречи между рабочими группами для обсуждения целей, задач проекта и установки приоритетов.
4. Организация рабочего пространства в Битриксе для управления задачами проекта.
5. Планирование встреч для каждой задачи. Определение объема работ, сроков и стоимости.
6. Создание задачи в Битриксе с использованием чек-листа. В процессе реализации задачи будут возникать вопросы, которые будут фиксироваться внутри самой задачи.
7. Демонстрация и приемка работы. Разработчик предоставляет готовый функционал и фиксирует его в Битриксе в рамках задачи. Проводится онлайн встреча с рабочей группой заказчика для демонстрации нового функционала. Рабочая группа заказчика принимает работу и подтверждает соответствие реализации изначальным требованиям.
8. Установка нового функционала на тестовом контуре системы. Рабочая группа заказчика должна продемонстрировать новый функционал персоналу, провести соответствующее обучение и сообщить рабочей группе разработчика о готовности внедрения функционала на боевой базе.
9. Установка нового функционала на боевой базе.
10. РГ Заказчика в течение месяца мониторит использование нового функционала, проводит обучение, меняет внутренние инструкции, добивается внедрения нового функционала в текущие бизнес-процессы. В процессе использования могут возникать различные вопросы или пожелания от персонала, которые должны быть адресованы рабочей группе заказчика. РГ заказчика собирает эти требования и принимает решение о дальнейших действиях. Если необходимо внести доработки в новый функционал, эти пожелания отражаются в задаче.
11. Если в течение этого времени со стороны РГ Заказчика не будет пожеланий о доработках, задача считается успешно выполненной и закрывается в Битриксе.