Отделить знания от человека

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

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

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

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

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

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

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

Когда думаешь об этой доработке, вопросов возникает больше, чем ответов. Как такое можно было допустить? Почему никто не описал доработку? Где был руководитель проекта? Мы не стали искать ответы на эти вопросы, зато после окончания проекта встретились всеми участниками со стороны исполнителя и выпили.

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

@Константин Овчинников
Теги: #управление изменениями #документирование

Комментарии