Получилось найти свое место в цепочке создания продукта клиента с точки зрения Системной Инженерии (3е поколение).

Какие продукты (сервисы) мы продаем клиентам

Мы выделили 3 категории продуктов, которые может предоставлять компания, которая занимается Professional Services в IT.

1) Продукты стратегического уровня: какие capabilities нужно создавать и развивать, чтобы достичь стратегических целей.

2) Продукты уровня развития: как создавать и растить такие capabilities (на стороне клиента). Тут все вокруг практик+методов.

3) Продукты уровня разработки (система создания): команды, которые встраиваются в команды клиента, которые (команды клиента) создают IT систему, которая встраивается в систему создания Business продукта клиента, результатом которого является бизнес-продукт (например Страховка).

На картинке ниже показано наше место в цепочках создания для продукта 3го уровня (Dev Team):

Продукт второго уровня (Technology Consting Team) будет встроена в систему создания левея Dev Team.

Продукт первого уровня (Strategy Technology Consulting Team) еще левее (туда нужно добавить еще квадрат).

Результат который я ожидаю от этого понимания

Улучшенное понимание “а что же мы делаем?”. Мы сейчас командой расписываем наше предложение для продуктов стратегического уровня и уровня развития. Разработчиков мы “продавать” умеем, это не так горит.

Самое главное понимание: кому на стороне клиента что предлагать в соответствии с его ролью.

Мы не будем “продавать” Engineering Manager-у, отвечающему за создание и развитие IT системы, менять практики и методы. Мы будем это делать соответствующим руководителям на CTO/CIO уровне, который отвечает за конкретные Capabilities.

Соответственно таким руководителям (уровня IT-capability) мы не будет предлагать команды разработки. Мы будем предлагать экспертизу, CoE (Centers of Excellence), создание Guilds, Enabling Teams, … .

Это на мета-уровне. На уровне реальности нужно предлагать “продукты” в зависимости от того с кем мы разговариваем. За какую конкретную capability отвечает эта роль? А для этого нужно проанализировать типичный value stream типичного клиента и понимать с чем мы можем работать (note: этот value stream у нас уже давно описан).

Тогда мы будем наполнять этот мета-уровень конкретикой (в соответствии с Value Stream):

• как планировать/дизайнить такие API, как создавать такие API-based продукты,
• как тестировать API-based продукты (привет куча практик тестирования в применении к API,  как продукта),
• как вводить в эксплуатацию, как “онбордить” пользователей API-продуктов,
• как монетизировать API-продукты, как их мониторить,
• как развивать,
• как их закрывать/”тушить” (переводить пользователей на новые продукты при выключении старых),
• …

Интересные выводы

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

• Т.е. одно из будущих изменений будет: «наши сэйлзы (как роль, как акторы это мы) говорят новые слова (старые, но по-другому) людям в соответствии с их ролями». И оно же, но зеркальное: «перед нами такая-то роль, поэтому показываем только те наши возможности, которые этой роли интересны».

• Все движение DevOps направлено на то, чтобы вот этот “OpsTeam” квадратик (из цепочек-создания выше) стал “холодной и темной фабрикой”.