Поворот не туда: реанимация проекта новым архитектором

Проблематика неудачных IT-проектов

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

Казалось бы, в IT все должно быть хорошо, проекты должны успешно реализовываться. Но на практике до 30–50% IT-проектов не завершаются успехом. Только за последние четыре года в области моего внимания были три проекта, где уходил РП со стороны заказчика, уходил РП с нашей стороны, менялись архитекторы, менялись команды, и все сразу становилось не очень хорошо.

Эта статья о том, как правильно подхватывать дела в подобных проектах.

Роль архитектора на проекте автоматизации

Главная роль архитектора – быть стержнем проекта. Он замыкает на себе всю архитектуру. Его основная задача – построить целостную функциональную и интеграционную архитектуру системы.

На изображении вы видите показатели качества работы архитектора по этапам разработки. Очевидно, что на этапе моделирования мы не должны бегать и дообследовать систему. На этапе разработки мы не должны бегать и выстраивать модель. Если это происходит, значит, проект где-то повернул не туда.

Что должен делать хороший архитектор?

• Определить, каким будет системное решение, «стержень» решения,

• Донести свое представление о результате до команды,

• Показать, как достигнуть результата,

• Отладить совместную работу команды,

• Проконтролировать результат.

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

Плохой архитектор, в свою очередь:

• Пытается выполнять работу за аналитика на проекте,

• Замыкает на себе часть знаний о системе,

• Недостаточно формализует ожидаемый результат для команды,

• Поверхностно проверяет результаты работы команды,

• Не умеет проявлять гибкость, перестраиваться под реалии проекта,

• Не пытается быть немного менеджером.

Иными словами, он создает зону неопределенности на проекте, а это снижает качество осмысляемой системы.

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

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

Кто сталкивался с тем, что процессы, которые рисуются на проектах, потом непонятно как сопоставить с системой, и они ни к чему не привязаны? У меня был такой случай: в отчете по обследованию производства зафиксировали формулировку «Отдел технического контроля имеет сотрудников на производстве». Эту информацию невозможно корректно положить в систему.

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

Как не утонуть в новом проекте

Теперь перейдем к реанимации проекта.

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

При этом на практике вам придется делать все это одновременно. Проект, скорее всего, никто не остановит, и вам придется параллельно формировать свое видение того, как правильно работать, и постепенно закрывать хвосты прошлого проекта.

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

Первое – стандартные проектные проблемы. В этой статье мы не будем подробно разбирать все проектные проблемы. Об этом уже много сказано и написано. На изображении выделены те проблемы, которые должен держать под контролем архитектор. Именно они оказывают влияние на облик системы. Остальные проблемы также важны, но их можно решать совместно с руководителем проекта.

Аудит документации

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

• Оформлена небрежно.

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

• Оформлена поверхностно / не ориентирована на проект.

• Согласована формально. Заказчик не понял, что именно подписал. Кстати, производственный документ из примера выше был подписан заказчиком.

Это может говорить о том, что:

• Не было единых правил оформления. Команда не имеет опыта написания документации или имеет слабое представление о том, как делать это правильно.

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

• Знания команды не соответствуют поставленным задачам.

• Команда слабо погружена в специфику бизнеса заказчика. Команда плохо погрузилась, была перегружена, поверхностно изучила материал и ограничилась формальными описаниями.

• Команда не заинтересована в качестве выполнения работ. Команда могла утратить интерес к проекту и выполнять работу формально.

• Команда имеет другие представления о качестве.

Как с этим работать? Одна из задач архитектора – формализация ожидаемого результата. Эту задачу можно разделить на несколько этапов.

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

Второй этап – оперативный контроль. Например, перед встречей подготавливается шаблон. Сотрудник работает по этому шаблону, архитектор направляет его и помогает в процессе.

Третий этап – завершающий контроль. Даже когда сотрудник работает самостоятельно, требуется контроль и корректировки, так как не все может быть сразу понято и осмыслено.

Следующий этап – сбор обратной связи. Он проводится спустя ощутимый промежуток времени: месяц, несколько спринтов или этап проекта. На этом этапе проводится ретроспектива.

Приведу пример с реального проекта. В протоколе по моделированию продаж были зафиксированы формулировки в стиле «сделано», «сделано», «сделано» без конкретики. Если открыть такой протокол через месяц, невозможно понять, о чем договорились, и что именно было сделано на проекте.

Был подготовлен новый шаблон протокола. Аналитик был обучен работе с этим шаблоном, проведены дополнительные встречи, подготовка была серьезной. В результате был получен протокол, который на 90% мог лечь в итоговую документацию.

У аналитиков больше времени стало уходить на проработку протоколов, так как они перестали быть стенограммой.

Пример протокола:

• Открытые вопросы прошлой встречи,

• Концепция модели НСИ / их назначение в целевой системе,

• Реестр бизнес-процессов с порядком их отражения в системе,

• Реестр отчетности по модели учета,

• Концепция переноса НСИ и остатков,

• Описание концепции реализации функциональных дефицитов,

• Вопросы по ролевой модели учета,

• Вопросы по интеграциям раздела учета.

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

Оценка команды

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

Однако это нужно проверить. Самый простой способ проверить погруженность аналитиков – провести собеседование с каждым из них. При этом вопросы не должны сводиться к рассказу о личном опыте или перечислению выполненных задач. Разговор должен быть ориентирован на систему.

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

Что могут выявить такие собеседования:

• Команда плохо понимает, как выстроен текущий учет заказчика.

• Команда не проводила анализ доработок текущей системы с точки зрения соответствия целевому решению (FIT-GAP анализ). Часто бывает, что на этапе обследования заказчик говорит: «У нас все типовое, как у всех, давайте не будем делать обследование». Это заблуждение. Системы заказчика необходимо изучать всегда и анализировать их с точки зрения соответствия целевому решению. Количество типовых решений в 1С ограничено. Если внедряется производство, скорее всего в качестве целевой выбрана или предполагается система ERP, и уже на этом этапе можно проверить, насколько текущий учет заказчика укладывается в типовую модель.

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

• Команда не общается между собой, каждый блок стоит особняком.

Какие у этого могут быть причины:

• Команда недостаточно уделила времени изучению текущих систем заказчика.

• Команде недостаточно данных для моделирования / у заказчика не запрашивалась вся необходимая информация.

• Компетенции команды не соответствуют сложности проекта. Например, на сложный блок учета назначили молодого аналитика, и он с ним не справился.

• Команда неверно интерпретирует проектную технологию и не понимает, какой должен быть результат этапа.

• Не была налажена работа команды.

Пример из практики. На этапе моделирования аналитик ведет встречу. Ему задают вопросы: «Как мы будем это делать? Как будем реализовывать этот процесс?» Аналитик отвечает: «Давайте разберем это на проектировании», «Давайте отложим», «Это сделаем на разработке». В результате аналитик сознательно отодвигает результат проекта и создает зону неопределенности.

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

Чем точнее донесен результат выполнения работ до аналитика, тем выше качество. После этого необходимо устранять белые пятна. На этом этапе, скорее всего, потребуется провести дополнительные встречи с заказчиком, так как сформировалась зона неопределенности. Через корректную документацию фиксируется вся информация, необходимая для системы, и перестраивается работа команды.

Еще пример. По одному блоку работ было два аналитика: по продажам и по логистике. При проверке результатов они постоянно ссылались друг на друга. Аналитик по продажам говорил, что вопрос относится к логистике. Аналитик по логистике утверждал, что это зона продаж.

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

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

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

Когда стоит менять людей в команде:

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

• Еще один критерий – низкая вовлеченность в проект, когда работа выполняется формально.

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

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

Пример из практики. По блоку себестоимости проводилось моделирование. При анализе документации было видно, что встречи сводились к демонстрации правил распределения расходов, принципов закрытия месяца и работы типовой системы на производственном предприятии. То есть аналитик по себестоимости просто показывал, как работает типовая система на производстве компании.

Это не является моделированием. Необходимо моделировать расходы с точки зрения их отнесения на производственный цикл конкретной компании.

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

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

На следующий день мы прекратили сотрудничество. Протокол по результатам встречи пришлось оформлять самостоятельно.

Как дополнительно проверить модель учета

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

• Обучите заказчика порядку работы с технической документацией. Часто подрядчик передает заказчику документы, и заказчик не понимает, что именно в них нужно проверять. Если мы обучаем аналитиков работе с документацией, значит, необходимо обучать и заказчика. Нужно объяснить, для чего пишется документация, какие цели она преследует и зачем готовится каждый конкретный документ.

• При передаче сложных документов целесообразно проводить совместную вычитку с заказчиком. Например, передается отчет по моделированию блока «Склад», документ открывается совместно и по тексту поясняется: что для чего написано, на какие моменты следует обратить внимание, какие выводы важно проверить. Такой подход существенно повышает качество взаимодействия с заказчиком.

• Организуйте контрольную демонстрацию результатов работы для заказчика / продемонстрируйте интеграционную модель. Если после этого остаются сомнения, используется контрольный пример. В IT-сфере, не связанной с 1С, этот подход называется интеграционным тестированием. Несмотря на то, что каждый блок был промоделирован отдельно, подготавливается общий кейс.

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

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

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

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

Такое мероприятие позволяет обеим сторонам проекта убедиться, что модель учета построена корректно и результат действительно соответствует ожиданиям.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.