Для чего нужно моделирование?

Опубликовал Дмитрий Шатохин (user694964_olamikyw) в раздел Управление - Управление проектом

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

Классическая ситуация: Заказчик дает вводные данные и ждет от нас оценку проекта. Часто присылает документ, гордо именуемый «Техническое задание». Иногда, впрочем, это действительно Техническое задание. Только в большинстве случаев даже адекватный входной документ никоим образом не гарантирует адекватную оценку от потенциального подрядчика.

Почему подрядчик не может дать точную оценку проекта, если есть полноценное Техническое задание?

Если бы каждая конкретная фирма с конкретным финансовым директором или ИТ-директором не были уникальны вне зависимости от сферы деятельности, а любые, кроме совсем уже общепринятых, операции не делались как удобно начальству\как сложилось исторически – то да, ТЗ было бы достаточно. Но каждый раз, когда после ознакомления с документацией наши спецы начинают задавать вопросы, выясняется море нюансов, которых за день не зафиксируешь. И это если у нас намечается проект по какому-то одному контуру. А если их несколько?

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

Отсюда и рождается необходимость проведения обследования, которое редко проводится бесплатно, а порой стоит 10-15% бюджета будущего проекта.

Но жадным 1С-никам и этого мало! После обследования они в лучшем случае дают оценку будущему проекту с дельтой в 30-50%. Почему? Вы же все же выяснили, изучили, что еще нужно?

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

Но итог обследования – это собранная в отчет информация. Нет никаких гарантий, что руководству нужно именно то, что хотят ключевые пользователи, и даже то, что само руководство на словах поведало специалисту. Очень часто бизнес-заказчики хотят видеть, как будет выглядеть работа их подразделений в новой системе. Как будут отражены текущие операции, часть из которых, возможно, еще делается вручную. И нередко видение бизнес-заказчиков сильно отличается от реализации подобных функций в типовом варианте системы. И никакое обследование не сможет дать однозначный ответ – совпадают ли видения у будущего Заказчика и Исполнителя, или после первого показа доработанной системы ее придется на 50% переделывать, т.к. «Тут у вас не так, и вообще я не это хотел».  И этот риск обязательно будет включен в оценку проекта, опять же сильно ее увеличивая. Однако верхнюю планку после обследования обычно удается определить, хотя цифры очень часто пугают Заказчиков, вплоть до отказа от продолжения работы, несмотря на то, что это теоретический максимум – его часто воспринимают как итоговую оценку. 

Как быть? Необходимо сделать так, чтобы видение будущей системы Заказчиком и Исполнителем совпали до старта основных работ по проекту. Заказчик должен увидеть будущую систему, понять, как в ней будут отражаться его процессы, а проектная команда должна заранее выяснить, какие процессы «лягут» на типовой функционал, а под какие систему надо дорабатывать (или наоборот – какие процессы Заказчик готов адаптировать под типовой функционал).

Одним из вариантов достижения данных целей является этап моделирования – попроцессного сопоставления всех бизнес-процессов Заказчика с их отражением в предполагаемой к внедрению системе и демонстрацией сквозных примеров. На выходе обычно формируется документ под названием «Карта функционального покрытия», содержащий в табличном виде реестр процессов и все выявленные несоответствия действительности и реализации в системе, а также краткое описание будущих доработок, подробное описание которых будет представлять из себя, по сути, Техническое задание.

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

В целом, этот этап в первую очередь нужен для: 

- минимизации рисков сторон

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

По итогам проведения моделирования Подрядчик и Заказчик:

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

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

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

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

См. также

Комментарии
1. Руслан Миллер (rusmil) 80 17.02.17 20:30 Сейчас в теме
Вот если бы Вы привели пример как выглядит фрагмент заполненной «Карты функционального покрытия» и как ее заполнять, статья бы сразу прибавила в весе.
Ulus; Bassgood; Alex_grem; belchonokh; mulla1979; +5 Ответить
2. Кирилл Кожин (kuril) 21 23.02.17 09:58 Сейчас в теме
Присоединяюсь к вопросу Руслана
И технику/софт, которыми пользуетесь
3. Сергей Д (dddxddd) 01.03.17 10:20 Сейчас в теме
Я всегда настаиваю на проведении моделирования, т.к. за адекватные деньги обе стороны получат в итоге одинаковое видение будущего проекта.

Правильный подход по сути, но все равно не беспроблемный со стороны заказчика.
Армия фанчей разных квалификаций, во главе с самой 1С, за все время своего существования, не создала инструмента взаимодействия исполнителя с заказчиком и даже не выработала рекомендованного стандарта взаимодействия.
Да, были некоторые потуги, всякие заумные кейсы, которые не сильно прижились, да есть СППР, но он из "коробки" ориентирован на исполнителя и заказчик в нем не равноправный партнер по созданию документов проекта, да и трудоемкость его использования (до некоторого уровня) не соизмерима с практической пользой.
А стоны по написание ТЗ, вообще умиляют...
Кто его должен писать, как и в каком объеме, для проектов какой глубины и как собственно определить эту глубину... - причина, нет какого либо шаблонизирующего инструмента, для проведения этого, очень важного, этапа работы любых исполнителя и заказчиком, вот и мучаются все кто как может, но создать такой инструмент "за бесплатно" - никто не хочет. А в результате кучи неудач взаимное недовольство и обвинения в надумательстве друг друга.

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

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

Ну и таки присоединяюсь к предыдущим комментаторам, пример карты, статье бы неповредил...
Оставьте свое сообщение