Платформы не умеют делать демо

Короче, я за свой опыт уже 3-й раз учу платформенные команды делать демо. Изменения в платформенных продуктах - одни из самых дорогих. Потому что влияют на потребление ресурсов, могут повысить когнитивную нагрузку, привести к дорогим инцидентам. Однако именно платформенные команды не умеют проводить демо 😩

Вот список типичных отговорок:

«У нас слишком низкоуровневая работа, там нечего показывать». «Мы ещё не готовы, у нас рефакторинг фреймворка внутри пайплайна». «Мы делаем задел на будущее, вот через квартал…»

Что скрывается за этими фразами? «Мы не умеем показывать, чем мы тут занимаемся и не умеем объяснять бизнес-ценность».

Почему это важно? 1. Выбор без обратной связи = трата времени. Платформенные команды часто «строят на опережение». Без демо это превращается в «строим в темноте». Через 3 месяца оказывается, что это никому не надо. 2. Прозрачность — это тоже Developer Experience. Если продуктовая команда не понимает, чем занимается платформа — начинается недоверие, «они там что-то копают», приоритизация летит в мусорку.

Ааааааа, это ваще огромная отдельная тема!

Че делать-то???

Как приучить к демо (и не убить мотивацию): 1. Показывать не фичи, а прогресс. Демо — это не «запуск релиза», это «что мы делали, что решали, к чему пришли». Даже скрин логов с коротким объяснением — это демо. 2. Делать демо для своих. Пусть сначала это будут свои — внутри платформы, без внешних команд. Главное — войти в ритм. Без оценки. Без пафоса. Просто ритуал. 3. Завести шаблон демо. Что мы планировали? Что получилось? Что поняли? Что мешало? Что дальше? 4. Демо - это не презентация в PowerPoint. Это может быть запись скринкаста, консолька с логами, объяснение архитектурного решения на Miro. Инструмент не важен. Важно делиться.

Какой итог?

Научитесь показывать промежуточные результаты — и получите:

• Быстрее обратную связь
• Повышение доверия к платформе
• Меньше боли на релизе
• И, возможно, даже благодарность от продуктовых команд (да-да, бывает).

@badtechproject