Метка: solution architect

Воронка инициатив

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

Можно было бы взять за основу традиционную Stage-Gate модель. Такую, например, как представлена на рисунке ниже.

Но я предпочту остановиться на картинках Дина Леффингуэлла, которые показывал в недавнем голосовом чате в нашем telegram-канале «Архитектор ИТ-решений». И хотя состояний в упомянутой модели совсем немного, характеристик у инициативы может быть существенно больше. Я расширю модель несколькими дополнительными характеристиками, постараюсь совместить с моделью водоворота исследований (Model Exploration Whirlpool) Эрика Эванса и сопровожу собственными комментариями и наблюдениями.

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

Сразу же перечислю основные этапы. Первый этап часто так и называет воронка(funnel). Реже innovation frontend. В него попадают все так или иначе обозначенные инициативы: идеи новых фич или полноценных продуктов, предложения по улучшению существующих, предписания регулятора, новые технологические диковины, залетевшие в компанию с выставок, конференций или принесенные поставщиками решений. Здесь же оказываются идеи, реализованные или еще только планируемые к осуществлению конкурентами. В общем любая, так или иначе обозначенная инициатива должна оказаться в воронке. Собственно, воронка представляет собой простейший список идей. Далее каждую из них надо хотя бы в общих чертах осмыслить. Те строчки списка идей, до которых у нас дошли руки, мы берем в проработку и концептуализируем (ideation). Чаще всего этой деятельностью занимаются аналитики, создавая верхнеуровневое описание проблемы или возможности. Обычно, второй этап называется анализ. Третий этап – оценка реализуемости подтверждает, что идея может быть так или иначе воплощена в жизнь и здесь лидирующая роль принадлежит архитектору решений. На четвертом этапе к анализу альтернативных вариантов реализации подключается значительно более широкий круг заинтересованных лиц и заканчивается этот этап выбором варианта реализации и фиксацией границ инициативы.

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

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

Нормальный процесс предполагает, что на всех этапах кроме воронки есть достаточный ресурс времени имеющихся у организации экспертов. Для исключения поспешности и субъективности при принятии решений обозначены четкие правила перехода с этапа на этап. Решения принимаются на альтернативной основе, а достигнутые договоренности доводятся до всех заинтересованных лиц. Часто на этапе анализа (этап номер 2) инициатива классифицируется по целому ряду независимых параметров. Я встречал несколько шаблонов оценки идей, включающих ряд простых вопросов инициатору: на какой сегмент клиентов нацелена идея, в какой временной интервал продукт или фича будут актуальны, не замещают ли они уже существующие предложения и как вписываются в существующую продуктовую линейку в целом. Финансовые и прочие ограничения в таком шаблоне тоже будут уместны. Я нахожу такие инструменты полезными, позволяющими очень быстро разметить портфель инициатив, что посмотреть его в разных разрезах, увидеть схожие или взаимодополняющие идеи, например, для конкретного сегмента клиентов, обозначить приоритеты сразу по нескольким независимым измерениям. Но это работа аналитика или даже маркетолога. Архитектор решений подключается обычно на третьем этапе, когда требуется подтвердить реализуемость инициативы, особенно с учетом финансовых и ресурсных ограничений. Обязательным условием этого этапа является рассмотрение альтернативных вариантов реализации, нахождение quick win, отказ от избыточных требований, разделение идей на части и стадии реализации или же группировка нескольких идей в общую инициативу. Нередко с третьего этапа идея возвращается на второй для полного пересмотра концепции и это вполне нормально. Часть инициатив растворится или существенно поменяется на втором и третьем этапе. Только инициативы, в которых потребности и возможности максимально друг другу соответствуют прорвутся на четвертый этап. К этому моменту удельный вес неподкрепленных фантазий и пустых мечтаний в идее существенно сократится, а рассмотрение вариантов ей реализации позволит чётко выделить контуры продукта на фоне прочих предложений компании и её конкурентов.

Тем не менее и с четвертого этапа инициативы могут посыпаться на третий (рассмотрите ещё и этот вариант – скажут топ-менеджеры на комитете по инициации продукта) и даже на второй.

Наилучшим образом весь процесс работы с инициативами описывает метафора Эрика Эванса Model Exploration Whirlpool. Независимые потоки анализа потребности, проектирования решения, разработки сценариев пользователей и даже прототипирования закручиваются в общий водоворот сливаясь и разделяясь друг с другом так же, как это происходит при исследовании предметной области (Domain Driven Design). В ходе него, зачастую меняются не только подходы к реализации, но появляется другой взгляд на цели и потребности, корректируются цели инициативы. К сожалению, Эванс не выразил свою идею текстом. Нам доступны лишь записи его выступлений и приведенная выше картинка. Тем не менее метафора водоворота полезна и убедительна. А кроме того она подсказывает нам, что не всё пойдет гладко в таком процессе. Его непременно будут сопровождать подводные течения, побочные завихрения потока, разнообразные водяные бочки из которых непросто выбраться и прочие неожиданные эффекты. И о том, что может пойти не так, каковы характерные искажения, поджидающие организации у воронки инициатив мы поговорим в следующий раз

Архитектор ИТ-решений

Архитектор ИТ-решения (Solution architect) отвечает за проектирование одного или нескольких приложений или сервисов в организации, обычно являясь участником команды проекта или услуги. Он должен иметь сбалансированное сочетание технических и деловых навыков и часто будет работать под методическим руководством архитектора предприятия (Enterprise architect)…

Не стану полностью переводить более чем внятное описание позиции Архитектора ИТ-решений с страницы What does a solution architect do? сайта СareerExplorer. Но всегда готов обсудить этот профиль деятельности и ответить на ваши вопросы.

ИТ-архитектор с точки зрения ITSM

01-01-perspective-boat-land-perspective-714026

Пару месяцев назад в блоге компании AXELOS (владелец портфеля ITIL и PRINCE2) появилось сообщение The ‘technical leader’ of the IT realm: the IT Architect. Появилось оно конечно не просто так, а как анонс описания роли ИТ-архитектор в деле создания и управления ИТ-услугами, включающем перечисление видов деятельности, знаний и навыков, а так же полезных для архитектора квалификаций ITIL. Продолжить чтение «ИТ-архитектор с точки зрения ITSM»

Вакансия Solution Architect (ИТ в телекоме, Москва)

ArhitektorУважаемые читатели, в нашем дружном коллективе открылась позиция Solution Architect (SA). Суть работы SA заключается в преобразовании бизнес и функциональных требований в архитектуру решения. Мы называем такую архитектуру High Level Design. HLD – это документ в формате wiki-страниц (см. Архитектура в формате Semantic Web), включающий описание вариантов использования, архитектурные модели и перечень ИТ-активностей будущего проекта. Продолжить чтение «Вакансия Solution Architect (ИТ в телекоме, Москва)»