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

Fix Time and Budget, Flex Scope (FFF)

1. Зафиксированы три точки проектного треугольника: срок, деньги и внутреннее качество системы.

2. Оплата происходит в конце проекта с возможной предоплатой.

3. В контракте описываются задачи, но достаточно масштабно, чтобы можно было флексить объём работы без переписывания контракта.

4. Объём работы оговаривается в начале проекта, но является предметом дискуссии.

5. Во время разработки нужно следить за сжиганием бюджета, приближающимся сроком релиза и оставшимися задачами, чтобы всё самое важное успеть к сроку. Глубина проработки задач и конечный список этих задач могут меняться во время работы прямо на планированиях или стендапах.

6. Риски делятся поровну: разработчики обязуются поставить ценность в срок и в рамках бюджета, а заказчик старается выбрать/урезать задачи, исходя из приоритетов бизнеса и текущей ситуации.

7. Внутреннее качество системы становится очень важным: объём работ может меняться, но срок и бюджет двигать никто не собирается. Поэтому код, тесты, внутренний дизайн, архитектура и автоматизация должны быть высокого качества, быть гибкими и в конечном итоге помогать быстро подстраиваться под любые изменения.

Time and Materials (T&M)

1. Зафиксированы деньги и внутреннее качество системы, хотя вторым частенько пренебрегают из-за халатности или неопытности с обеих сторон.

2. Заказчик берёт в аренду ресурсы исполнителя по фиксированной ставке и управляет ими по своему усмотрению.

3. Исполнитель отвечает за максимально качественный продукт за счёт своей компетенции.

4. Оплачивается при этом время, которое сотрудники исполнителя были заняты на проектах заказчика. Это происходит в конце отчётного периода, например, раз в месяц.

5. Основные риски берёт на себя заказчик.

6. Если у заказчика есть чёткое понимание задач и организован контроль работы (в том числе собственных ресурсов, особенно Product Owner'а), то это самый оптимальный и быстрый вариант управления, потому что он наименее бюрократизирован: все заняты только разработкой без лишних отвлечений на ритуалы согласований.

Fixed price

1. Зафиксированы три точки проектного треугольника: срок, деньги и объём работы.

2. Основные риски берёт на себя исполнитель, и, как следствие, эти риски отражаются на оценке. Кроме этого, создаются риски и для заказчика (раздел l, глава 7).

3. Большим плюсом этого подхода является предопределённые до начала работ параметры проекта. Очень часто бизнесу/государству нужно прописать в договоре срок, деньги и объём работы.

4. Внутреннее качество при этом редко фиксируют. Зато почти всегда именно качеством жертвуют, чтобы в нашем изменчивом мире умудриться попасть в срок с фиксированным объёмом работы. Почему так происходит и что является корнем проблемы, обсудим чуть дальше.

5. Оплата происходит в конце проекта с возможной предоплатой в начале.

Повышаем качество работы
Основные идеи, которые помогут повысить качество работы:

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

Чтобы уменьшить неопределённость, надо предсказать будущее, построить план и двигаться согласно плану. Как сказал Джокер в фильме «Тёмный рыцарь»: «Люди охотно соглашаются действовать согласно плану, каким бы он ни был, даже если план ужасен».
С этой точки зрения, идеальный уменьшитель неопределённости – техническое задание.

• Снизить риски, уменьшить неопределённость

• Задача «бездумному» исполнителю

• ТЗ требуется согласно регламентам

• Нет доверия с одной из сторон

В какой момент следует остановиться писать и начать делать проект. Я выделил три основные критерия.

• Высокая цена ошибки

• Важно не превысить бюджет

• Важна скорость проверки гипотез

• Нет доверия с одной из сторон

• Прокси-менеджер

Структура Impact Map. Идея этого подхода в том, чтобы прорисовать связь от задач (Deliverable) к цели (Goal). По задумке, задачи оказывают воздействие (Impact) на какую-то группу (Actor), и это воздействие приводит бизнес к цели. Таким образом, нет бесполезных задач, и чётко видно, что и зачем мы собираемся делать.

Goal – здесь нужно описать измеримый результат. Ключом к этой части будет ответ на вопрос, который вы зададите себе и заказчику: «По каким критериям мы поймём, что достигли успеха?» Такой вопрос помогает перенестись в будущее и подумать, как мы собираемся оценивать результат. Формулировка выбрана так, чтобы человек начал рефлексировать, и это не то же самое, что спросить «какая у вас цель?». Цели могут быть разные, а вот конечный результат в будущем оценят по каким-то критичным для бизнеса параметрам. Это и есть Goal.

Actor – на кого мы собираемся оказывать воздействие. Обычно сюда предлагают писать тех, кто нам может помочь или помешать в достижении цели. Так можно делать, это неплохой совет, но он недостаточно нас фокусирует. Я предлагаю думать о том, чью жизнь мы хотим поменять с помощью воздействия, чтобы это изменение жизни привело нас к цели. Трюк в том, что мы не просто собираемся воздействовать, а надеемся, что сможем изменить поведение людей в нужную сторону. Такой взгляд заставляет точнее очерчивать границы для Actor и приходится тщательно обдумывать Impact.

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

Deliverable – это список задач или историй. 

Синонимами кнопочного мышления можно назвать экранное мышление или преждевременную концептуализацию. Суть мышления кнопками можно раскрыть на десятке примеров из практики, но пока – история, которая наверняка случалась с каждым. Представьте: к вам приходит клиент и рассказывает о падении конверсии на сайте. А вы в ответ: «Давайте кнопку покупки сделаем побольше и поярче!» Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Это и есть кнопочное мышление.