Идеальные требования, и как с этим бороться

В прошлых частях

В первой части цикла ^[1] я анонсировал серию статей о работах аналитика в предпроекте. Там перечислены проблемы, решения и некоторые принципы, о которых надо помнить при запуске ИТ-проекта.

В прошлой, второй части ^[2] я рассказал про частые проблемы предпроекта и получил в комментариях закономерные замечания: «Хорошо написано о проблемах, всё как в действительности. Но решение предлагается в стиле «Не делайте плохо, и будете делать хорошо» neskazhui ^[3], «Но это жизнь, она в целом в статье и написана. А как надо-то?» other_letter ^[4].

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

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

Среди них:

• Устройство ИТ-системы и классификация ИТ-продуктов
• Уровни V-модели, жизненный цикл системы и взгляд на систему как на финансовый актив
• Конус неопределенности и фазы проектирования
• Как работает оценка
• Полный состав задач предпроектной фазы и реализуемые при этом ценности
• Как получить достаточное количество ресурсов на предпроект

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

Классификация ИТ-продуктов

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

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

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

Полная иерархия ИТ-продуктов выглядит так:

• ИТ-сервис включает бизнес-структуру с интегрированной в нее автоматизированной системой.
• Автоматизированная система включает людей и программно-технический комплекс (информационную систему).
• Программно-технический комплекс — это программы, технические средства и данные, объединенные между собой.
• Программа, оборудование или данные могут сами по себе являться самостоятельным заказным или массовым продуктом с собственным циклом создания, развития и сопровождения.

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

• Математическое
• Программное
• Техническое
• Информационное
• Лингвистическое
• Метрологическое
• Эргономическое
• Организационное
• Методическое
• Юридическое
• Финансовое

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

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

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

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

Основной ответ на вопрос «что делать?» — это «понимать класс своего предмета поставки и видеть, как он вписан в вышестоящую систему».

Расширенная V-модель и жизненный цикл системы

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

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

Для иерархии ИТ-продуктов, показанной в предыдущем разделе мы можем построить расширенную V-модель.

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

На V-модели в зависимости от типа ИТ-продукта видно, сколько проектирования должно быть выполнено до старта нашего проекта. С другой стороны, видно, какие действия будут совершены для окончательной валидации нашего предмета поставки.

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

Классификация ИТ-проектов

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

На каждом из представленных выше уровней и видов решений планируется различное количество изменений.

Есть проекты по замене сервера на более производительный. Бывают проекты по переезду из одного дата-центра в другой. Бывает смена языка системы или просто поставщика услуг.
Есть проекты, создающие ИТ-сервис для массового потребителя с нуля. Есть проекты, меняющие бизнес-процессы и некоторые программные средства. Все это разные проекты со своей спецификой. И есть еще громадное количество вариантов.

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

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

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

В третьем столбце добавлена степень управляемости решений в ситуации «как есть». То есть нам важно, есть ли где посмотреть или спросить, как сейчас устроен тот или иной аспект сервиса.

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

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

Система, как финансовый актив

Последнее, что я хочу рассказать сегодня — это принцип, играющий для построения ИТ-систем роль Всеобщей формулы капитала К.Маркса для экономики или цикла Шухарта-Деминга для управления процессами.

Спонсор дает деньги под гарантии заказчика по преобразованию ожидаемого эффекта в отдачу инвестиций.

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

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

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

На каком бы уровне V-модели мы ни входили в проект, мы должны представлять себе, как сконфигурирован цикл возврата инвестиций:

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

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

Здесь я первый (но не последний) раз хочу утвердить основную цель аналитика в предпроекте: необходимо закрыть десять невыгодных проектов ради того, чтобы один выгодный получил достаточное финансирование.

В итоге

Выше мы рассмотрели принципы определения контекста проекта:

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

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

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

Автор: darkboatman

Источник ^[6]