Проект и тьма стейкхолдеров: как облегчить жизнь архитектору

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

Проекты с большим количеством участников, как правило, имеют следующие особенности:

1. Изначально невнятно поставленные цели и задачи. Большое количество согласующих у заказчика приводит к тому, что разные участники видят результаты проекта по-разному и на этапе подготовки и внутреннего согласования ТЗ нередко сходятся лишь на общих формулировках (как говорится, «для ясности замнём»), тем самым перенося проблему окончательного выбора и согласования решений на исполнителя работ.

2. Необходимость коммуникации с большим количеством стейкхолдеров. Часто их взаимодействие происходит через исполнителя работ — между собой они не общаются. Заказчик просто не видит своей ответственности за организацию эффективной коммуникации внутри проекта.

3. Размывание ответственности за конечный результат в целом по проекту. Большое количество заинтересованных сторон обычно говорит о важности решаемой задачи. Если у проекта много заинтересованных участников, то, скорее всего, проектируемая система, даже если нужна не всем, точно затрагивает интересы многих. Именно потенциально высокая значимость результата и много заинтересованных сторон формируют риски размывания ответственности.

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

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

Первое: действовать в русле методик адаптивной разработки (Agile). Для этого необходимо стараться вести техническую нарезку реализуемых задач проекта в соответствии со структурой стейкхолдеров. Это позволяет конкретизировать и решать задачи с каждой группой стейкхолдеров в рамках коротких циклов разработки (обычно 2–3 недели), а после — обеспечивать конкретизацию и согласование принятых решений по кругу ведения. Таким образом, стейкхолдер понимает и принимает зону своей ответственности, а мы уходим от ситуации, когда на этапе сдачи работ часть стейкхолдеров начинает делать замечания по всему проекту, выходя за пределы своей компетенции. Безусловно, выделение задач по стейкхолдерам сильно зависит от компетенции заказчика: сделать всех ответственными за всё гораздо проще.

Второе: процесс доставки ПО должен быть максимально простым. Иными словами, текущие изменения должны моментально попадать в тестовую или продуктивную среду. Обычно здесь требуется решить ряд вопросов:

1. Проблема хранения данных. Структура данных на начальном этапе может значительно изменяться. Кроме того, часто, действуя в русле Agile, мы побуждаем заказчика сразу пользоваться системой в каком-то объёме. При этом потеря данных становится нежелательной.

   Наше базовое решение — реляционная СУБД в самых простых конфигурациях и собственная разработка Celesta в качестве средства взаимодействия с СУБД. При выработке этого решения мы пользовались следующими аргументами:

   (а) Реляционные базы данных — самое на настоящий момент распространённое, достаточно скоростное и функционально наиболее зрелое решение для хранения данных.

   (б) Стандартную проблему автотестов и миграций в реляционных СУБД мы решаем при помощи Celesta, которая стала чуть ли не «серебряной пулей» во многих наших проектах.

   (в) Использование кластера реляционных СУБД — это сложности в развёртывании и обновлении БД, никому не нужные на начальных этапах проекта.

2. Процесс доставки должен быть быстрым и находиться в полной компетенции исполнителя. По сути это означает наличие процедуры автоматической доставки всех обновлений на сервер, где размещено разрабатываемое ПО. Варианты типа «приходи с дискеткой на выделенный компьютер и переноси» или «подключайся по VPN и заливай» мы считаем заведомо деструктивными. Понятно, что такой процесс должен стать результатом взаимодействия — как минимум, с ответственными за инфраструктуру и информационную безопасность (ИБ). Понятно также, что качество процесса должно поддерживаться согласованными технологическими и организационными мерами (но это обязательное условие успеха). Кроме того, исполнитель должен обладать определённой свободой в изменении архитектурных решений — безусловно, при полной прозрачности текущей архитектуры для всех участников. Здесь мы разделяем подходы, принятые в проекте DocHub.

3. Необходимо внимательно отнестись к проблеме информационной безопасности. Решения в части ИБ не должны блокировать принятие и корректировку архитектурных решений.

   Часто в условиях высокой регламентированности требований к ИБ возникает тенденция к формальным консервативным решениям — например, сертифицировать всё во ФСТЭК. Однако мы автоматизируем реальные бизнес-задачи, и такой подход к решению вопросов ИБ часто блокирует выработку и корректировку требуемых заказчику решений.

   Мы можем выбрать готовую платформу, обеспечивающую заданные параметры ИБ, например, решения «1С-Битрикс», сертифицированные ФСТЭК. Однако при всех возможностях «1С-Битрикс» мы должны понимать, что при таком подходе за рамки этого решения мы выйти не сможем.

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

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

Для свода мы используем AsciiDoc. Из простых текстовых разметок Asciidoc наиболее функционален. Также он позволяет представлять документацию практически без ограничений в форматах текстовых процессоров (docx/odt). Указанные форматы наиболее универсальны и привычны для ревизии и согласования, поэтому их использование на проектах с большим количеством стейкхолдеров неизбежно.

Четвёртое: на проектах мы стараемся максимально использовать широко распространённые открытые технологии, хотя бы на первых порах. Странно заплатить за лицензию, чтобы потом понять, что нужна другая. При необходимости выбрать программную технологию мы анализируем три показателя: активность вклада в код, количество скачиваний артефакта за последний период, количество упоминаний на Stack Overflow (если по технологии много обсуждений, значит, легче найти решение).

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

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

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

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