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

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

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

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

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

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

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

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

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

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

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

Аналитики vs. Архитекторы

Рискну поделиться субъективным мнением, надеясь, что его обсуждение не выльется в холивар. Есть много хороших бизнес/системных аналитиков, которым более-менее регулярно приходится заниматься проектированием ИТ-решений. ИТ-архитекторам тоже регулярно приходится заниматься анализом. Причем речь идет не только о технологиях, но, в не меньшей степени, о погружении в предметные области, концептуализации присущих им вещей и операции, конкретных практик деятельности организации. Может быть разделение профессий аналитика и архитектора необоснованно? Думаю, что нет. Я знаю хороших аналитиков, которые не хотят быть архитекторами, а также архитекторов, которые не смогут, да и не станут работать аналитиками. О том, как разобраться в собственных предпочтениях этот текст. Продолжить чтение «Аналитики vs. Архитекторы»

Микросервисы. Обратный билет

Из telegram-канала Архитектура ИТ-решений

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

Open Agile Architecture (запись вебинара 5 ноября 2020)

Первые впечатления от нового стандарта архитектуры предприятия Open Agile Architecture™ от международного технологического консорциума The Open Group

Слайды в telegram-канале «Архитектура ИТ-решений» https://t.me/it_arch/946

Коротко об обучении ИТ-архитекторов

Сейчас в образовании популярна новая тема: обучение через большие идеи или дидактика «больших идей». Не знаю, как скоро этот подход проникнет в среднее образование, но для своих курсов по ИТ-архитектуре я нашел его, как говорится методом проб и ошибок. Ну, например, архитектуру ИТ-решений (solution architecture) и микросервисы можно изучать отдельно. Хотя изучать просто ИТ-архитектуру немного скучно. А изучать микросервисную архитектуру, особенно после большого и долгого хайпа, довольно сложно. Все, вроде бы, и так всё уже об этом знают. Ну, может быть, в общих чертах и недостаточно глубоко. Хотя буквально в каждой группе, первая же из девяти характеристик микросервисной архитектуры по Льюису-Фаулеру оказывает сюрпризом хотя бы для одного из слушателей. А вот изучать и то и другое одновременно полезно и с точки зрения поддержания интереса, и для приобретения конкретных компетентностей. Продолжить чтение «Коротко об обучении ИТ-архитекторов»

Как понять, что вы разговариваете с настоящим ИТ-архитектором

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

Как нам разобраться кто из них настоящий ИТ-архитектор, суждениям которого можно доверять, а чьи рекомендации стоит перепроверить? Я бы не стал делить ИТ-архитекторов на настоящих и фейковых. Внимание к архитектуре системы, решения или организации в целом – это уже хорошо. Тем не менее, полезным будет иметь некоторую шкалу, характеризующую уровень доверия к предложенным тем или иным экспертом архитектурным решениям(architecture decision). Примерно так же, как в свое время Леонард Ричардсон предложил использовать модель уровней зрелости для проверки соответствия API архитектурному стилю REST. Продолжить чтение «Как понять, что вы разговариваете с настоящим ИТ-архитектором»

Микросервисы. Закат хайпа?

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

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

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

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

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

Тень цифрового будущего 2.0

К середине десятых годов над нашим миром нависла Тень цифрового будущего. Все уже знали, что скоро наступит время беспилотных автомобилей, умных холодильников и микроволновок из интернета домашних вещей и прочих диковин нового индустриального уклада. Мало кто с ними сталкивался вживую, но никто не сомневался, что они есть. Я даже написал небольшую заметку в конце 2016 года ИТ стратегия в переходный период, в которой посетовал, что тень цифрового будущего над нами нависла, а само оно все никак не приходит. Почему-то не утешали слова Уильяма Гибсона: «Будущее уже наступило. Просто оно еще неравномерно распределено».

Сегодня, медленно, но неотвратимо приходит время разобраться с целями и задачами текущего кризиса года 2020. И кажется: где ты теперь, новая индустриальная революция, ау-ау!  — но не все так просто.

Продолжить чтение «Тень цифрового будущего 2.0»