Функциональная и географическая этапность

Divide et impera! (лат)

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

Проблематика тривиальна. Если вы разрабатываете и внедряете сложную систему, то логично этот процесс построить так, чтобы эффект появился как можно быстрее и насколько возможно больший. Я верю в принцип Парето, поскольку ни раз сталкивался с его подтверждениями на практике. Исходя из него, вполне можно выделить 20% функционала системы, который даст 80% успеха. А раз так, пускай этот первичный набор "quick win-ов" и будет вашим первым функциональным этапом.
На второй функциональный этап можно отнести то, что не вошло в первый этап. Вроде бы тоже очень важные функции, но реализация их дорога и/или долга, т.е. это не будет "quick", или же, эффект от внедрения этих функций не будет столь искрометным по сравнению с другими, т.е. они не представляют собой "win".
Помня о том, что совершенство - недостижимо и можно вечно потчевать свой перфекционизм, мы получаем некоторую операционную историю постоянного совершенствования. Сюда же попадает развитие продукта, адресующее изменения в конъюнктуре рынка, вызовы времени и пр. факторы, требующие от продукта продолжать решать поставленные перед ним задачи с наилучшими показателями effectiveness и efficiency не смотря ни на что. Все это, и многое другое, включая плохо просматривающиеся, плохо понимаемые фичи, суть которых станет очевидней после появления практики использования функционала первых двух этапов, - можно отнести на третий этап, практически бесшовно переходящий в Operations.

Аналогичный подход можно применить и в географическом отношении, если вам надо внедрить проект во многих сотнях предприятий, расположенных во многих десятках регионах страны и Мира. Пусть первым этапом будут Пилоты - предприятия/регионы на которых можно собрать все возможные грабли и шишки с минимальными рисками. Скорее всего, внедрение вашей системы на предприятии будет отличаться в зависимости от особенностей предприятия (его технологической инфраструктуры, зрелости operations и т.п.). Поэтому, обычно выделяют "типовые площадки", отражающие все возможные сценарии внедрения/интеграции. Важно, чтобы в этап Пилотов попали площадки каждого типа.
Если в корпорации много дочерних предприятий, то, скорее всего, есть некий рейтинг, составленный по важным для бизнеса корпорации критериям. Это может быть прибыль, имидж, стратегический приоритет - да что угодно, важно, что сливками этого рейтинга являются Ключевые предприятия. Собрав все шишки на Пилотах и тем самым отработав порядок внедрения, можно рассматривать внедрение на Ключевых предприятиях следующим этапом, поскольку окучив их можно получить наибольший эффект от проекта в масштабах всей корпорации. Важно, однако, понимать, что характер разрабатываемой и внедряемой системы может определять внедрение на каких предприятиях даст больший корпоративный эффект. Поэтому, может сложиться так, что вторым приоритетом после Пилотов пойдут и не ключевые предприятия, но это как раз и есть тот самый контекст корпорации, с которым должна работать проектная команда, добиваясь как можно большего эффекта как можно скорее.
Отработав проблемы на Пилотах и добившись наибольшего корпоративного успеха на ключевых (или максимально релевантных проекту) предприятиях, оставшиеся предприятия - третий географический этап.

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

Что изображено на картинке?
I. Внедрение функционала первого приоритета в пилотных регионах/предприятиях.
II. Тираж функционала первого приоритета на Ключевые регионы/предприятия
III. Внедрение функционала второго приоритета там где, внедрен первичный. В остальных регионах/предприятиях – тираж функционала первого приоритета.
IV. В пилотных регионах/предприятиях – внедрение остального функционала. В остальных регионах – тираж функционала второго приоритета
V. Тираж остального функционала во всех оставшихся регионах

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

Время материализовать облака

Мы рождены, чтоб сказку сделать былью
("Марш авиаторов", Герман-Хайт)

Спешите порадоваться спуску с горы, ибо далее придется тащить на себе санки

(Личный опыт из детства)

Абстрагируемся на время чтения этой заметки от того, что любая автоматизация всегда ведет к увеличению операционных затрат, - как бы там ни было, автоматизация - явление правильное и полезное, выводящее наши процессы на новый уровень. Разумно желание концентрироваться на основном бизнесе и не отвлекаться на различные инфраструктурные задачи, которые, собственно, и ведут к увеличению OpEx-ов, снижение которых - подтверждение эффективности разрабатываемых и обеспечиваемых нами бизнес-процессов. Однако, История держит свой путь по спирали и, несмотря на необратимость времени, мы с синусоидальной периодичностью приходим все в те же ситуации, то отвергая, то принимая вновь уже ранее обдуманные понцепты: железным инфраструктурам пришли на смену облачные, затем - гибридные, и сейчас мы становимся свидетелями балканизации, что снова нас возвращает к полностью on premise решениям, но уже на новом витке времени и понимания причин.

По моему субъективному мнению (лишний раз отмечу, что все статьи этого блога заключают в себе исключительно субъективное мнение) текущая кристаллизация on-prem из облаков создает удобную тенденцию создания хороших корпоративных продуктов из решений, ранее доступных только из облака. Посудите сами: огромная часть продуктовой инфраструктуры скрыта от глаз потребителя в облаке, что позволяет экономить на целом ряде вещей, малозначительных с точки зрения функционала, но принципиальных для on-prem решений: пользовательских интерфейсах, оптимизации аппаратных мощностей, алгоритмах обработки данных... - в целом, облачное решение даже может быть менее зрелым в функциональном плане, и все его недостатки могут быть скомпенсированы архитектурой бизнес-процессов, избытком инфраструктуры, дополнительными расходами на обслуживание. Говоря проще, - если интерфейс неудобный и требуется больше времени на решение каких-то задач - это можно скомпенсировать увеличенным количеством людей, если решение нестабильно - это можно скомпенсировать как многократным резервированием, так и усиленной ИТ-поддержкой, если код плохо оптимизирован - можно взять мощнее железо и т.д. Кроме того, в облаке можно делать полноценный Agile разработки - функционал можно расширять максимально быстро, так как связанные с этим риски можно временно скомпенсировать теми же немного завышенными расходами на людей и железо. И вот уже когда решение в облаке достигло требуемой зрелости, его можно материализовать в коробочный продукт, отвязанный от инфраструктуры вендора. Собрав все шишки и грабли в облаке, уже можно построить стабильное, красивое, удобное решение on premise, воплотившее в себе весь опыт облачного использования, решение, основанное на практике, обкатанное в "боевых" условиях. При этом, облачная инфраструктура по-прежнему останется логичной исследовательско-тестовой лабораторией для нового функционала on-prem решения, где все по тому же сценарию вызревшие в облачной эксплуатации фичи можно с минимальными рисками переносить в изолированные корпоративные инфраструктуры.

Обратный путь, - от on-prem к облаку, - нелогичен, так как несравненно сложнее, поскольку на первом же этапе надо обеспечить стабильность на миллионе комбинаций возможных инфраструктур Заказчика, с непредсказуемым operations и квалификацией персонала, более того, эти сложнейшие инфраструктурные проблемы не позволят как следует сконцентрироваться на функционале, отнеся эти, с точки зрения конечного потребителя, более важные задачи на второй план (действительно, когда там думать об удобстве пользования лопатой, если она рассыпается как только пользователь берет ее в руки!)... Поэтому правильным стратегическим решением сейчас может быть инвестирование в продуктивизацию до состояния качественного on-prem ранее исключительно облачных предложений со всеми сопутствующими артефактами успеха: обучением, документацией, сервисом продуктовой поддержки и поддержки на уровне бизнес-логики, а также процессами создания, отработки/вызревания нового функционала в облаке с последующим переносом его в изолированные корпоративные инфраструктуры. Спешите "оседлать" балканизацию, быть может, скоро спираль Истории изменит свое направление и вместо спуска по синусоиде, придется карабкаться в нее...