|
Классическая ситуация: Заказчик дает вводные данные и ждет от нас оценку проекта. Часто присылает документ, гордо именуемый «Техническое задание». Иногда, впрочем, это действительно Техническое задание. Только в большинстве случаев даже адекватный входной документ никоим образом не гарантирует адекватную оценку от потенциального подрядчика. Почему подрядчик не может дать точную оценку проекта, если есть полноценное Техническое задание? |
||
| Если бы каждая конкретная фирма с конкретным финансовым директором или ИТ-директором не были уникальны вне зависимости от сферы деятельности, а любые, кроме совсем уже общепринятых, операции не делались как удобно начальству\как сложилось исторически – то да, ТЗ было бы достаточно. Но каждый раз, когда после ознакомления с документацией наши спецы начинают задавать вопросы, выясняется море нюансов, которых за день не зафиксируешь. И это если у нас намечается проект по какому-то одному контуру. А если их несколько? | ||
|
Могут возразить – дайте оценку сразу, вы же опытные, вы всякое видели. Все верно. Только если специалист будет оценивать сразу, он заложит все мыслимые риски, вспомнит всех самых проблемных своих клиентов и проекты, и накинет еще процентов 20 сверху, чтобы гарантированно не работать бесплатно, и не воевать под конец с Заказчиком, выбивая у него доп. финансирование.
|
||
|
Отсюда и рождается необходимость проведения обследования, которое редко проводится бесплатно, а порой стоит 10-15% бюджета будущего проекта. Но жадным 1С-никам и этого мало! После обследования они в лучшем случае дают оценку будущему проекту с дельтой в 30-50%. Почему? Вы же все же выяснили, изучили, что еще нужно? Действительно, на этапе обследования специалисты в режиме интервьюирования выясняют, что происходит у Заказчика, как ведется работа сейчас, какие есть пожелания к будущей системе, что нравится, что нет. |
||
| Но итог обследования – это собранная в отчет информация. Нет никаких гарантий, что руководству нужно именно то, что хотят ключевые пользователи, и даже то, что само руководство на словах поведало специалисту. Очень часто бизнес-заказчики хотят видеть, как будет выглядеть работа их подразделений в новой системе. Как будут отражены текущие операции, часть из которых, возможно, еще делается вручную. И нередко видение бизнес-заказчиков сильно отличается от реализации подобных функций в типовом варианте системы. И никакое обследование не сможет дать однозначный ответ – совпадают ли видения у будущего Заказчика и Исполнителя, или после первого показа доработанной системы ее придется на 50% переделывать, т.к. «Тут у вас не так, и вообще я не это хотел». И этот риск обязательно будет включен в оценку проекта, опять же сильно ее увеличивая. Однако верхнюю планку после обследования обычно удается определить, хотя цифры очень часто пугают Заказчиков, вплоть до отказа от продолжения работы, несмотря на то, что это теоретический максимум – его часто воспринимают как итоговую оценку. | ||
|
Как быть? Необходимо сделать так, чтобы видение будущей системы Заказчиком и Исполнителем совпали до старта основных работ по проекту. Заказчик должен увидеть будущую систему, понять, как в ней будут отражаться его процессы, а проектная команда должна заранее выяснить, какие процессы «лягут» на типовой функционал, а под какие систему надо дорабатывать (или наоборот – какие процессы Заказчик готов адаптировать под типовой функционал).
|
||
| Одним из вариантов достижения данных целей является этап моделирования – попроцессного сопоставления всех бизнес-процессов Заказчика с их отражением в предполагаемой к внедрению системе и демонстрацией сквозных примеров. На выходе обычно формируется документ под названием «Карта функционального покрытия», содержащий в табличном виде реестр процессов и все выявленные несоответствия действительности и реализации в системе, а также краткое описание будущих доработок, подробное описание которых будет представлять из себя, по сути, Техническое задание. | ||
|
Я всегда настаиваю на проведении моделирования, т.к. за адекватные деньги обе стороны получат в итоге одинаковое видение будущего проекта.
В целом, этот этап в первую очередь нужен для: - минимизации рисков сторон - получения максимально адекватной оценки и формирования единого видения результата будущего проекта у всех его участников. |
|
По итогам проведения моделирования Подрядчик и Заказчик:
- окончательно понимают, какие будут сложности в работе с данными конкретными людьми с другой стороны - получают финальную оценку, которая с очень большой долей вероятности будет меньше чем та, которую дали по результатам обследования. |
||
|
И хотя стоимость данного этапа порой может доходить до 30% бюджета всего проекта, выгода от его проведения в первую очередь для Заказчика, как показала практика, весьма существенна и в финансовом, и в функциональном плане. В последнее время при прочих равных я не продаю этап обследования как отдельный – сразу предлагаю моделирование с включенным в него обследованием. Выходные формы такого этапа (карта функционального покрытия) намного информативнее как для Заказчика, так и для любого подрядчика. |
||
| Есть вопросы – обращайтесь! | ||
|
Дмитрий Шатохин, аккаунт-менеджер ООО "Кодерлайн" |
