Схема: варианты для ценности от внутреннего деврела
 
Когда идёшь договариваться про цели деврела со стейкхолдерами, часто в первом приближении речь заходит про истории внешние. "Сделать компанию заметнее", "помочь с наймом", вот это вот всё.
 
Тем интереснее поговорить про ценность от деврела внутреннего – там в пересчёте на деньги может получаться весьма любопытный ROI.
 
Посмотрите на схему на картинке.
 
Прямым текстом там речь идёт о маркетинге продуктов для разработчиков. Но между строк можно разглядеть про внутренний деврел.
 
Может ли переиспользование технических решений, инженерных практик и, например, кодовой базы уменьшить дублирования, снизить вероятность ситуации "каждый пилит один и тот же велосипед", сделать интереснее наши затраты на разработку?
 
Могут ли наши инженеры, объединённые общим контекстом внутреннего сообщества, помочь быстрее делать внутренние инициативы технические – "месяц автотестов", "внутренний хакатон про экспериментальные бизнес-фичи"?
 
Как насчёт шаринга знаний в поддержке, есть ли там потенциал больше шаблонизировать, автоматизировать и тем самым снижать косты саппорта? Лучшие практики взаимодействия с пользователями раскатывать по всей поддержке, децентрализовать экспертизу?
 
===
 
Подсмотрел эту схему в рамках книжного клуба деврел-бюро.

До финиша книги пока не добежал; не могу сказать, дворецкий ли убийца, но по той части, которую успел побороть – решительно рекомендую!

Если надумаете почитать книгу с такими схемами, приходите в личку – подскажу, где можно заполучить.