Методология, по которой 11 проектов стали победителями «1С:Проект года»
Всё, что держится на конкретном сильном человеке, невоспроизводимо: он ушёл в отпуск - и проект просел. Рассказываю, как устроены правила, по которым у нас идёт каждое внедрение, и как проверить наличие таких правил у своего подрядчика - тремя вопросами на пресейле.
Лет двадцать назад мы делали проекты «как получится». Период был интересный: решения 1С резко усложнялись, и надо было решать, что с этим делать дальше. Мы решили идти в самое сложное - в автоматизацию производственных предприятий.
Опыт к тому моменту был приемлемый. А проекты всё равно шли по наитию: каждый руководитель проекта делал так, как привык. Хорошие люди вытаскивали их на себе - и пока людей хватало, это даже работало.
Проблема такой модели известна любому директору. Всё, что держится на конкретном человеке, невоспроизводимо. Сильный руководитель проекта ушёл в отпуск, заболел, уволился - и проект просел. А заказчику всё равно, какие у нас кадровые обстоятельства: у него запуск.
Так появилась наша методология управления проектами - корпоративная система, которую разработали в «Раздолье». Суть простая: это правила, по которым у нас идёт каждый проект внедрения. Не пожелания, а правила. С тех пор 11 наших проектов стали победителями конкурса «1С:Проект года» - и я связываю это не только с талантами руководителей проектов, но и с тем, что система делает результат повторяемым.
Расскажу, как она устроена и что это даёт вам как заказчику. Не всю кухню - методология рабочий документ, - но главное, по чему вы сможете проверить любого подрядчика, включая нас.
Проект - это семь этапов с проверяемыми выходами
В методологии проект разбит на семь этапов: функциональное моделирование, доработки, настройка прав, инструкции, обучение, перенос данных, опытно-промышленная эксплуатация. Сами по себе этапы вас удивлять не должны - похожий список вам покажет любой интегратор.
Разница в другом. У каждого этапа в методологии описаны три вещи: работы, результат и встречные обязательства заказчика.
Результат - это документ или состояние системы, которое можно предъявить заказчику. Не «проведено моделирование», а «документ „Функциональная модель“ согласован заказчиком». Не «выполнены доработки», а «дистрибутивы конфигурации переданы, протоколы тестирования подписаны». Если этап нельзя закрыть предъявляемым результатом - это не этап, а процесс с неясным концом.
Про встречные обязательства скажу отдельно, потому что об этом подрядчики на пресейле говорить не любят. На каждом этапе у заказчика есть своя работа: организовать интервью ключевых пользователей, согласовать проектные решения, протестировать доработки, подготовить данные из исторических систем, выверить их после переноса. Это записано в методологии не для красоты. Проект внедрения - совместная работа, и, если заказчик свою часть не делает, никакой подрядчик его не вытащит. Мы это проговариваем до старта, письменно. Кому-то это не нравится. Зато потом нет разговора «а мы думали, вы всё сделаете сами».
Кто за что отвечает - записано до старта
Вторая опора методологии - оргструктура проекта. Наверху Управляющий совет: кураторы проекта от заказчика и от нас. Это люди, которые обеспечивают проект ресурсами и принимают решения от лица своих организаций. Ниже - оперативный совет, рабочая группа: руководители проекта с обеих сторон, владельцы бизнес-процессов, консультанты-аналитики. Дальше - исполнители.
По каждой роли расписаны обязанности. Владелец процесса отвечает за информацию по своему процессу и согласование документов. Ключевые пользователи участвуют в интервью, проверяют перенос данных, принимают систему. Руководитель проекта от заказчика имеет право требовать информацию от подразделений - и это право записано, потому что без него он ходит по заводу как проситель.
Если вы читали мою статью про команду заказчика, вы узнаёте мотив: ключевые люди и их время - главный невидимый ресурс проекта. Матрица ответственности переводит этот ресурс из разговоров в документ, который подписан до старта.
Светофор, которому можно верить
Третья опора - регулярная отчётность. По каждому проекту еженедельно готовится статус-отчёт: зелёный, жёлтый или красный цвет по всем задачам, с реестром проблем и рисков.
Здесь важна одна тонкость. Светофор работает только тогда, когда жёлтый и красный - это нормально. Если за красный статус руководителя проекта бьют, через месяц все проекты в компании станут зелёными - и будут зелёными до самого… срыва. Я про это писал в статье о признаках подрядчика, который не справится: ровная зелёная отчётность на длинном проекте подозрительна сама по себе. Живой проект желтеет и краснеет, вопрос в том, видно ли это в отчёте и что за этим следует.
Реестр рисков и проблем - вторая половина того же инструмента. Риск, записанный в таблицу с ответственным и сроком, отличается от риска, о котором «все знают», примерно как задача от пожелания.
Зачем это знать заказчику
Методология - внутренний документ подрядчика, и может показаться, что вас она не касается. Касается, и вот почему.
Когда у подрядчика есть работающая система управления проектами, вы получаете предсказуемость. План-график с ресурсным планом существует с первого дня. Задачи детализированы максимум на неделю - значит, отставание видно через неделю, а не через квартал. Статус-отчёт приходит регулярно, а не когда вас надо успокоить. И главное - проект не зависит от того, насколько гениален конкретный руководитель проекта. Система страхует людей.
А проверить наличие такой системы можно тремя вопросами на пресейле, до всякого договора.
Первый: покажите структуру вашей методологии - этапы и результат каждого этапа. Не сам документ, его вам могут не дать, - оглавление и логику. Если в ответ звучит «у нас гибкий подход, всё обсуждаемо», перед вами не гибкость. Перед вами отсутствие правил.
Второй: какие встречные обязательства будут у нас? Подрядчик, который отвечает «да вы особо не понадобитесь, мы всё сделаем сами», либо не понимает, как устроено внедрение, либо понимает и говорит вам приятное. Оба варианта плохие.
Третий: покажите образец статус-отчёта с прошлого проекта, обезличенный. Есть ли там светофор, риски, проблемы с ответственными - или это письмо в свободной форме «работы идут по плану».
Методика у подрядчика либо живая - по ней реально работают, и тогда ответы на эти вопросы у него готовы, - либо бумажная, и тогда вы это почувствуете по паузе. Про то, чем живая методика отличается от мёртвого талмуда на 400 страниц, у меня есть отдельная статья. Короткая версия: дело не в толщине документа, а в том, отвечает ли его автор за то, что система в итоге заработает.
Мы по своей методологии работаем каждый день - и отвечаем за неё запущенными системами. Её обзор можно скачать на странице о методологии - там же форма, куда написать, если хотите обсудить свой проект.