В прошлых частях
В первой части цикла я анонсировал серию статей о работах аналитика в предпроекте. Там перечислены проблемы, решения и некоторые принципы, о которых надо помнить при запуске ИТ-проекта.
В прошлой, второй части я рассказал про частые проблемы предпроекта и получил в комментариях закономерные замечания: «Хорошо написано о проблемах, всё как в действительности. Но решение предлагается в стиле «Не делайте плохо, и будете делать хорошо» neskazhui, «Но это жизнь, она в целом в статье и написана. А как надо-то?» other_letter.
Рассказ о том, как надо, я разделю на части:
1. Как правильно: то есть хорошо бы так делать, но обычно это получается лишь частично. Это будут следующие два рассказа.
2. Какие можно дать советы по каждой фазе работы с требованиями: чтобы облегчить ситуацию, когда что-то пошло неправильно, чтобы вписаться в реальные ограничения.
За ближайшие две заметки я опишу ряд простых принципов, касающихся устройства ИТ-систем, их жизненного цикла, организации аналитических работ и выстраивания отношений вокруг проекта. Их многие знают, но не всегда применяют в реальности.
Среди них:
- Устройство ИТ-системы и классификация ИТ-продуктов
- Уровни V-модели, жизненный цикл системы и взгляд на систему как на финансовый актив
- Конус неопределенности и фазы проектирования
- Как работает оценка
- Полный состав задач предпроектной фазы и реализуемые при этом ценности
- Как получить достаточное количество ресурсов на предпроект
Повторю для тех, кто не хочет ждать следующие части цикла. Есть видео моего доклада с митапа, послужившего толчком к написанию этих заметок. При этом я хочу не только переписать тезисы выступления, но и выйти из временных рамок доклада, добавив к тому, что уже было сказано, то, что не влезло по времени или возникло по итогам обсуждения после.
Классификация ИТ-продуктов
Вне зависимости от того, какой класс продукта производит ИТ-проект, необходимо помнить, что окончательная суть автоматизации заключается в передаче умственной работы от людей к машинам.
За какую бы мелкую часть системы мы ни отвечали, конечный результат будет получен после соединения человека, технических устройств, программных средств и информации в единое целое, называемое автоматизированной системой.
Запуск автоматизируемой системы, кроме получения и объединения всех компонентов, включает реорганизацию автоматизированной деятельности. И в последние пятилетки такая реорганизация все чаще сопровождается перестройкой административных, юридических и финансовых отношений сторон вокруг системы. В последнем случае мы уже имеем дело с ИТ-сервисом, в котором грань между бизнес-процессом и автоматизацией стерта.
Полная иерархия ИТ-продуктов выглядит так:
- ИТ-сервис включает бизнес-структуру с интегрированной в нее автоматизированной системой.
- Автоматизированная система включает людей и программно-технический комплекс (информационную систему).
- Программно-технический комплекс — это программы, технические средства и данные, объединенные между собой.
- Программа, оборудование или данные могут сами по себе являться самостоятельным заказным или массовым продуктом с собственным циклом создания, развития и сопровождения.
Если залезть глубже и учесть, что решения по сценариям взаимодействия частей и решения по соединению частей создают самостоятельную прибавленную ценность, мы должны учесть все виды обеспечения, которые могут быть заказаны отдельно:
- Математическое
- Программное
- Техническое
- Информационное
- Лингвистическое
- Метрологическое
- Эргономическое
- Организационное
- Методическое
- Юридическое
- Финансовое
Предметом поставки ИТ-проекта может быть любой из перечисленных видов продуктов, их часть, комбинация, а так же услуги по изменению/обслуживанию всего вышеперечисленного.
Казалось бы, описанный принцип невозможно нарушить. Если все компоненты системы не будут подходить друг к другу и к автоматизированной деятельности, то чуда не случится. Такое «отсутствие зажигания» происходит само по себе из-за различных проблем с требованиями, коммуникацией, проектированием и просто из-за ошибок.
При этом часто менеджеры проектов сознательно убирают из своего объема неудобные части системы. Например, «поставка оборудования — не наша задача», или «поддержкой пользователей занимайтесь сами», или «забывают» включить в план миграцию данных, обучение пользователей и опытную эксплуатацию. Это происходит по разным причинам: нет соответствующих ресурсов, непрофильные работы или продукты, не понятно, есть опасения, что встанет дорого и заказчик откажется от запуска проекта.
В любом случае каждый элемент системы вне объема твоего проекта — это внешнее неподконтрольное заинтересованное лицо, которое будет обеспечивать недостающую часть, канал коммуникации и необходимость согласования того, что делаешь ты, с тем, что будет делать смежник.
Сама коммуникация, согласование проектных решений со смежными частями — это работы и риски, которые явно должны появляться в плане проекта.
Основной ответ на вопрос «что делать?» — это «понимать класс своего предмета поставки и видеть, как он вписан в вышестоящую систему».
Расширенная V-модель и жизненный цикл системы
На самом деле выполнение разных частей работы по системе разными подрядчиками или разными подгруппами проекта — это нормальная ситуация. Для того чтобы части были согласованы между собой, ряд технических решений выделяют отдельно и называют архитектурой решения в западной терминологии или техническим проектом — в отечественной.
Решения бывают не только технические.
Для иллюстрации вложенности ИТ-продуктов, порядка принятия/проверки решений и взаимодействия их жизненных циклов можно использовать V-модель. Она отражает два простых факта: проектировать лучше от большого к малому, а собирать в единое целое и тестировать нужно в обратном порядке.
Для иерархии ИТ-продуктов, показанной в предыдущем разделе мы можем построить расширенную V-модель.
Если мы работаем по Agile, то все эти этапы выполняются внутри каждой пользовательской истории. Если у нас более длинные итерации, то по этим фазам проходит сразу целая очередь или подсистема.
На V-модели в зависимости от типа ИТ-продукта видно, сколько проектирования должно быть выполнено до старта нашего проекта. С другой стороны, видно, какие действия будут совершены для окончательной валидации нашего предмета поставки.
Соответственно, результаты предшествующего проектирования должны поступить нам на вход (причем, не всегда «самотёком»), а действия по валидации будут вызывать запросы на изменения, поддержку или дефекты, выявленные после поставки.
Классификация ИТ-проектов
Из понимания структуры ИТ-продукта, концепции V-модели и ее связи с жизненным циклом нашего продукта и его частей следует еще один вывод: перед тем, как «списать» план проекта, реестр рисков или какие-то практики работы у коллег или из интернета, надо убедиться, что конфигурация нашего проекта близка к «проекту-донору».
На каждом из представленных выше уровней и видов решений планируется различное количество изменений.
Есть проекты по замене сервера на более производительный. Бывают проекты по переезду из одного дата-центра в другой. Бывает смена языка системы или просто поставщика услуг.
Есть проекты, создающие ИТ-сервис для массового потребителя с нуля. Есть проекты, меняющие бизнес-процессы и некоторые программные средства. Все это разные проекты со своей спецификой. И есть еще громадное количество вариантов.
Чтобы видеть, насколько велико расстояние между двумя проектами, можно применять карту проектных решений, отражающую степень изменений по каждому виду решений и границы нашей ответственности.
Вот пример карты проектных решений по одному реальному ИТ-проекту, цель которого — глубокий рефакторинг и замена программного обеспечения массового сервиса, что должно было дать ускорение развития сервиса, новые фичи, замену визуального стилевого решения и некоторые другие улучшения.
Во втором столбце отражен профиль изменений по виду решений, который можно использовать для сравнения проекта с другими проектами.
В третьем столбце добавлена степень управляемости решений в ситуации «как есть». То есть нам важно, есть ли где посмотреть или спросить, как сейчас устроен тот или иной аспект сервиса.
Сочетая данные по масштабу изменений и степени неопределенности текущего положения дел, мы получили риски от масштаба изменений объекта, который был изначально неуправляемым. Сюда добавлены еще и риски от решений и объектов, которые не находятся в нашей власти и сейчас не находятся в управляемом состоянии, – это решения, по которым мы полностью зависим от смежников и заказчика.
Эту карту можно уточнять: раскрывать более детально виды решений, добавлять колонки, отвечающие за фиксацию источников информации и ответственности по решениям, добавлять данные по принятию решений для состояния «как будет» и анализировать соответствующие риски.
Система, как финансовый актив
Последнее, что я хочу рассказать сегодня — это принцип, играющий для построения ИТ-систем роль Всеобщей формулы капитала К.Маркса для экономики или цикла Шухарта-Деминга для управления процессами.
Спонсор дает деньги под гарантии заказчика по преобразованию ожидаемого эффекта в отдачу инвестиций.
Заказчик дает требования на систему, гарантирующие создание ожидаемого эффекта.
Исполнитель на основе требований делает систему.
Пользователи используют систему, это приносит ожидаемый эффект, который преобразуется в возврат инвестиций.
Этот круг должен быть замкнут. Если что-то не выходит: систему нельзя использовать, эффект не достигается, отдача вложений не получается — это проблемный проект. Если мы не можем даже спрогнозировать возврат инвестиций, эффект или порядок использования — это мина замедленного действия.
На каком бы уровне V-модели мы ни входили в проект, мы должны представлять себе, как сконфигурирован цикл возврата инвестиций:
- кто в ролях спонсора, заказчика, исполнителя и пользователей,
- в чем заключается возврат и вложения, из чего они складываются,
- как образуется эффект,
- в чем будет заключаться использование.
Картинку для конкретной системы обычно можно прикинуть на листе бумаги за один-два разговора. Все обрывы, вопросы и неясности должны быть преобразованы в риски. Пока ясность по финансовому циклу не наступит, запускать проект нельзя.
Здесь я первый (но не последний) раз хочу утвердить основную цель аналитика в предпроекте: необходимо закрыть десять невыгодных проектов ради того, чтобы один выгодный получил достаточное финансирование.
В итоге
Выше мы рассмотрели принципы определения контекста проекта:
- Определение класса продукта, и вышестоящей системы
- Определение предшествующих и последующих проектных решений и работ вне рамок нашего проекта
- Определение жизненного цикла финансового актива над нашим проектом
Уже само знание пробелов и нестыковок контекста позволяет устранить фатальные проблемы и заведомо не начинать провальный проект.
В следующей заметке мы закончим обсуждать основные принципы идеального запуска проекта, чтобы далее перейти к обсуждению, что делать с неидеальными ситуациями.
Автор: darkboatman
