Антихрупкость в IT

Продукт – SaaS-инструмент для партнёров топовой e-commerce России. Диалог с IT-подразделением заказчика:

– Давайте выведем договоры в интерфейсе, – говорит разработчик со стороны заказчика.

– Чтобы что? – отвечаем мы.

– Они уже лежат в БД, можно легко вывести.

– Как это поможет достигнуть целей продукта?

– Без договоров невозможно заплатить!

– Чтобы заплатить, нужно начать пользоваться продуктом, а он ещё не существует.

В таких случаях помогает только возврат к целям проекта и фильтрация с помощью Impact Mapping (раздел l, глава 2).

Рефлексия и душевный покой

Чтобы уберечь ваши нервы, делюсь выработанной стратегией борьбы с кнопочным мышлением:

1. Когда к вам пришли с кнопочной идеей, спросите себя, почему они принесли такое решение, почему оно не нравится вам, какие вопросы выявят корень проблемы. Только после этого начинайте говорить.

2. Поймите, что коллеги не со зла лезут с кнопочными идеями. Никто не хочет навредить или саботировать. Все пытаются принести пользу.

3. Управляйте на уровне достижения бизнес-целей, а не задач.

4. Ставьте перед командой проблемы, а не приходите с решениями.

5. Делайте короткие итерации (одна неделя или короче), постоянно собирайте обратную связь от команды и от клиентов.

6. Проводите валидацию идей как можно раньше, убивайте идеи до этапа реализации.

Рекомендации одинаково банальные и действенные. Мне в работе помогает.

Здесь самое важно, что мы фильтруем «хрупкие» идеи, которые со временем разрушат целостность нашей системы. Мы требуем фильтровать входящие задачи вопросом «чтобы что?», а это создаёт в системе запас прочности и позволяет ей оставаться гибкой по отношению к новым изменениям.

Замечайте кнопочное мышление за собой, замечайте за коллегами, рассказывайте бизнесу и учитесь работать с запросами пользователей. Помогайте друг другу в преодолении недуга.

Глава 2. Impact Mapping на практике

Трассировка от задач до целей

Когда читал книгу Impact Mapping[11] первый раз, было желание бросить её на середине, настолько в ней всё очевидно. Я нашёл в себе силы и дочитал, благо книга короткая и с большими картинками. Как впоследствии оказалось, вся соль была в применении советов на практике. Я не применял. В моей практике заказчик иногда писал бизнес-цели в официальных документах к проекту; иногда мне казалось, что я и так понимаю цели бизнеса – они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.

История появления Impact Mapping

Раньше на старте проекта у нас были технические задания, схемы работы системы и в лучшем случае прототипы интерфейса. В этих документах не хватало понимания динамики развития проекта и приоритетов в работе.

Мы начали писать User Story[12] и делать User Story Mapping. Эти практики добавили понимание логики развития проекта и наших приоритетов, дали возможность плодотворнее общаться с заказчиком. Чего не хватало? Продукты существуют не в вакууме: нужно уметь видеть более глобальные задачи, которые лежат где-то выше историй использования системы. Не хватало простой игровой практики по постановке целей проекта, из которых потом будут появляться Story Mapping и список User Story.

Mijo Balic и Ingrid Ottersten в 2007 году написали статью «Effect Managing IT» (подробнее Agile product management using Effect Maps[13]

). Через четыре года Gojko Adzic[14] выпустил книгу «Specification by Example»[15], где в главе «Deriving scope from goals» упоминает о технике под названием Effect mapping. Эта техника призвана помогать командам фокусироваться на бизнес-целях, выявлять заинтересованные стороны и их потребности.

Gojko Adzic со временем добавляет в Effect mapping несколько усовершенствований, таких как: приоритизация целей и воздействий, возможность уходить от технических деталей на уровне What, цикличность в предположениях и экспериментах. На мой взгляд, это действительно важные изменения, они помогают в реальной жизни. После этого техника стала называться по-новому – Impact Mapping.

Руки без головы

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

Получается, что заказчик пришёл к вам с готовыми решениями каких-то своих проблем. В такой ситуации заказчик купит только руки разработчика, но не голову. Разработчик не сможет критически оценить предложенные решения. Будет ли успешным проект с подходом, где купили только «руки»? Шанс невысок .

Зато в наших силах увеличить шансы на успех за счёт того, что каждый в команде будет понимать и разделять цели бизнеса. Тогда любое решение – от именования переменной в коде до выбора архитектуры – будет приниматься с учётом реальных потребностей бизнеса.