Плохой Project Артём Арюткин

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

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

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

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

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

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

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

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

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

Какой итог?

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

@badtechproject

www.tgoop.com/badTechProject/1326

4.3K viewsMay 6 at 05:01

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

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

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

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

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

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

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

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

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

Какой итог?

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

@badtechproject

BY Плохой Project Артём Арюткин