← Все статьи

Аудит проекта в работе: за две недели понять - ехать или остановиться

Проект второй год буксует, а решать - вам одному. Как за пару недель понять, в каком он состоянии на самом деле и стоит ли его спасать.

Представьте проект, который идёт уже второй год. Статус-отчёты приходят вовремя, и в них всё зелёное. Сроки вроде двигаются, подрядчик вроде работает. А у вас внутри сосёт. Запуск обещали прошлой осенью, потом этой весной, теперь снова «ещё немного» - и вы уже не очень понимаете, чем всё это кончится.

И сидите вы с этим ощущением один на один. Потому что вопросы, которые из него растут, - страшные. Менять подрядчика? Это заново, это деньги, это полгода на разгон. Остановить? А что тогда со всем, что уже вложено. Начать сначала? Ещё дороже. Каждый ответ пахнет большими деньгами, и ни один не хочется произносить вслух.

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

Чего аудит не делает

Сначала про то, чего боятся зря. Иначе вы меня дальше не услышите.

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

Аудит отвечает на один вопрос: что теперь со всем этим делать. И начинается он с самого простого - сесть и разобрать, что именно вас настораживает. Не с конфигуратора, не с кода. С разговора.

Мне, честно говоря, платят не за то, что я знаю 1С. Платят за то, что я уже видел проект, в котором вы сейчас находитесь, - десятки раз. Я знаю, где он ломается, как выглядит за месяц до срыва и что делать, когда сроки уже ушли.

Что мы смотрим за пару недель

Знать 1С вам для этого не нужно. Мы смотрим на то, по чему видно реальное состояние проекта, а не на строчки в конфигураторе. Если совсем коротко - семь вещей.

Статус-отчёты и таблицы рисков: что вам показывали и, главное, что замалчивали. Документы функционального моделирования: управляем ли проект в принципе или его ведут на ощупь. Методологические решения - на чём построены учёт и себестоимость, не заложена ли туда мина, которая рванёт на закрытии месяца. Вовлечение вашей команды: выделены ключевые люди или прислали «кого-нибудь». Работу управляющего совета - принимаются ли решения вовремя и на нужном уровне. Реальную стадию проекта против плановой. И договор с приёмкой - за что уже заплачено и что реально сдано.

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

Раньше я гнался за скоростью и гордился ей. Перестал. Спешка ради красивой цифры ничего ценного не вскрывает. Обычно на аудит уходит около двух недель, но точный срок задаёт масштаб и состояние проекта - гнать тут бессмысленно. Важен не срок, а порядок: что смотрим и в какой последовательности.

И сразу оговорюсь: это не «технический аудит 1С», которым на рынке называют что угодно. Мы не разбираем код на обновляемость. Вопрос, на который мы отвечаем, другой - можно ли этой системой вообще управлять.

Что я обычно нахожу

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

А из семи типовых бед, которые вылезают снова и снова, техническая - одна. Остальные шесть управленческие. Никто не знает, как процесс работает на самом деле, потому что он живёт в головах двух сотрудников. У системы нет владельца. «Готово» в реестре не равно «принято» вами. Регламентированный учёт отложили «на потом». Требования собирали как придётся. И только шестая беда - про самописный обмен, который тихо ломает данные.

Про «нет владельца» расскажу сценой, её узнают все. Сидим на одном проекте, разбираем с бухгалтерией заказы поставщикам. Бухгалтер спрашивает: а кто их должен вводить? Отвечаем - по логике отдел закупок. И тут звучит вопрос, который решает весь проект: «А кто их сможет заставить?»

Вот это «а кто заставит» - и есть отсутствие владельца в чистом виде. Настроить в системе можно что угодно. А заставить соседний отдел вводить данные - это уже не про 1С. Это про власть в компании, и у ИТ-службы её обычно нет.

И почти всегда главную беду находят не в коде, а в разговоре. У этого есть техника, я про себя называю её лестницей вопросов. Начинаешь с общего, сужаешь до данных, а последний вопрос - всегда про расхождение. На одном заводе ОПК мы так вскрыли неверную методологию раздельного учёта по гособоронзаказу: в одном контракте шифровка где восемь цифр, где десять, где двенадцать. Три уточняющих вопроса начальнику планового отдела - и стало понятно, что отчётность так не сдать. Цена этой ошибки была - полмиллиона штрафа и сорванный срок по ГОЗ.

Три исхода

Аудит заканчивается не отпиской, а одним из трёх решений - и всегда с обоснованием, почему именно оно.

Ехать дальше - основа здоровая, надо поправить план, управление и приёмку и довести до запуска. Скажу, что именно исправить.

Перезапуск - проект сошёл с курса, но спасаем: пересобираем команду, план, договорные рамки.

И остановка - самое дорогое решение и иногда единственно верное. Если продолжать дороже, чем остановиться, я скажу это прямо и с цифрами.

Про остановку отдельно, потому что её боятся больше всего. И даже остановка - это управляемый выход. Пара недель на аккуратное сворачивание, и вы забираете то, за что уже заплачено: функциональную модель, базу настроек, инструкции, материалы обучения, документацию по интеграциям. Это активы, а не пепелище.

Но до остановки доходит редко. Чаще - другое.

Как я включаюсь: три истории

Аудит показывает не только диагноз, но и глубину вмешательства. И почти никогда это не «поменять всех». Обычно мягче, по нарастающей. Покажу на трёх реальных проектах.

Иногда сломан только руль. Очень крупное предприятие, окологосударственное - настолько крупное, что заходило в налоговый мониторинг, а туда берут не всех. Проект шёл с другой командой и к нашему приходу буксовал месяца три. Позвали знакомые: тревожно, а ткнуть пальцем, что не так, заказчик не может.

Стали разбираться - а команда-то нормальная, люди в теме. Всё упиралось в руководителя проекта. Он на ходу менял согласованные планы, расставлял приоритеты, которых кроме него никто не понимал. Каждое совещание у заказчика начиналось с одной фразы: «мы не понимаем, что происходит». Люди просто перестали делать свои задачи - не из вредности, они не видели ни графика, ни цели. Жалобы дошли до генерального.

Мы поменяли ровно одно - управление. Команду оставили, менять её было бы долго и дорого, да и незачем. Вернули понятный график, цели, приёмку - и проект доехал за четыре месяца. Сломался руль, а не машина.

Иногда достаточно закрыть один узел. Предприятие космической отрасли, больше пяти тысяч человек, сложные приборы, филиалы по стране. ERP они внедрили сами, и внедрили неплохо: оперативка работала, больше сотни пользователей в системе. Ломалось в одном месте, зато в самом больном - в финансах. Себестоимость не считалась, месяц не закрывался. Полгода бились своими силами и не могли свести баланс ни за один период года, а цифры ждала управляющая компания. По ходу сверху ещё прилетело МСФО.

Систему никто не ломал - ломать нечего, она здоровая. Надо было закрыть один узел, финансовый, где своей экспертизы команде не хватило. Мы не встали вместо их ИТ-службы, встали рядом: они ведут своё, мы взяли себестоимость, закрытие периода и отчётность. Подняли расчёт с начала года, переделали весь год. Сейчас месяц закрывается за пару недель после окончания, в рабочем режиме. А без этого предприятие управлялось бы вслепую в самой чувствительной части - дорогие приборы, про которые непонятно, сколько они стоят.

А иногда нужен перехват. Самый тяжёлый случай. Радиоэлектроника, оборонка, выручка тринадцать миллиардов, шестьсот пользователей. До нас там два года внедряли с другим интегратором и результата не получили: требования менялись, программу переделывали столько раз, что запутались все, деньги кончались.

Позвали нас «немного помочь со сдачей регламентированной отчётности». За пятнадцать лет я вывел правило: чем мягче формулировка на входе, тем глубже яма. Стали разбираться - учёт в системе фактически не ведётся. Главный бухгалтер, кстати, не знала, что её бухгалтерия уже десять месяцев не ведёт в 1С учёт материалов. Просто не знала!!!

Дальше была демонстрация в актовом зале - двести человек, все топы, генеральный. Мы показали систему на их же кейсе, и генеральный при всех сказал: «Я Наталье Ивановне верю, она справится». С этой фразы проект и поехал. Переключили всё на типовой функционал вместо «уникального под себя», переработали справочники, свели противоречивые требования в одно. Доработок системы - ноль. С нуля до сдачи РСБУ - четыре месяца, командой из двух человек. А дальше четыре договора за четыре года и два новых клиента, которых заказчик сам нам и привёл.

Про этот проект ИТ-директор потом сделал публичный доклад. И причину первого провала сформулировал лучше, чем смог бы я: «Они делали то, что мы хотели. А мы не знали, чего хотели». Весь наш метод - про то, чтобы перестать делать «что хотят», и начать делать то, что нужно. Даже если за это сначала не любят.

С чего начать

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

Дорого стоит не аудит. Дорого стоит тянуть вслепую ещё квартал в надежде, что само устаканится. Не устаканится...