Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

разобьются в пух при встрече с реальными данными. Чтобы не было мёртворождённых макетов, дизайнеры с самого начала собирают данные у заказчика или «в поле». Если никто данных не даёт, почти во всех случаях можно прикинуть экстремальные значения для каждого блока или элемента (например, самые длинные и самые короткие строки, длинные непереносимые слова, самое больше разумное для этой системы число) и проверять макет на них.

Разработка и релиз

Разработка шла по Scrum[31] с итерацией в одну неделю. Интересно, что глобально проект разрабатывался по схеме Fixed price[32], так как этого требовали бизнес-процессы компании заказчика, но внутри разработка строилась по гибким методологиям.

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

Надеюсь, что описание конкретного проекта вдохнуло жизни в описанный мною процесс создания IT-продукта.

Почему это работает?

После общения с заказчиками и внутри команды мы решили, что основная сила такого подхода заключается в следующем:

1. В самом начале мы понимаем, что на самом деле надо продукту для успеха.

2. Работает постоянная обратная связь при полной прозрачности процесса.

3. Пишем качественный код, досконально тестируем и автоматизируем (но это же по умолчанию должно быть, верно?).

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

Глава 5. Когда надо прекратить писать техническое задание и начать делать продукт?

Как балансировать между чрезмерно подробным и дорогим ТЗ и слишком «сырым» и абстрактным

Люди не любят жить в неопределённости[33]. Нам хочется на 100% предсказать будущее, спланировать работу на год вперёд и идти по плану шаг за шагом без сюрпризов. С этой точки зрения подробное Техническое задание (ТЗ) – чудодейственное средство, которое предскажет, какие задачи, как, когда и за сколько будут сделаны.

При описании задач в ТЗ мы балансируем между двумя крайностями:

1. Переплатить временем и деньгами за чрезмерно подробное описание задач.

2. Описать задание недостаточно подробно, что приведёт к серьёзным рискам и ошибкам.

Как понять, что в ТЗ написано достаточно? Как понять, что критичные риски закрыты? Я расскажу, на какие критерии ориентироваться.

Затраты на прогноз к эффективности прогноза

По оси Х отложим вложенные деньги и время, которые мы тратим на написание ТЗ. По оси Y – уровень предсказания будущего, то есть точность прогноза (рис. 20).

Рис. 20. График точности прогноза

Вначале график идёт резко вверх, поэтому небольшое вложение времени и денег даёт хороший результат в 70–80% точности. Оценка на глаз опытным IT-архитектором обычно даёт довольно неплохой прогноз.

Чем больше мы вкладываем в оценку и описание задачи, тем меньший эффект получаем. До полной определённости не доходим никогда, потому что кривая асимптотически приближается к максимуму (рис. 21).

Рис. 21. Сравнение затрат на прогноз к точности прогноза

Получается, что всегда остаётся место риску и неопределённости, даже если мы будем писать ТЗ годами. Полная определённость будет достигнута только после окончания проекта, но не перед стартом.

Критерии, на которые стоит ориентироваться

Всем понятно, что в ТЗ нужно описать все задачи, оно из них состоит. Но что входит в полный перечень? Насколько подробно стоит описывать? Зависит от типа проекта и критичности рисков. Другой вопрос – в какой момент следует остановиться писать и начать делать проект. Я выделил три основные критерия.

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

Если от качества или успеха проекта зависит что-то важное, то приходится платить за снижение риска. Если ошибка приведёт к банкротству компании или к потере жизни человека (оборудование для поддержания здоровья) или многих людей (оружие), то изучение и снижение рисков может стоить больше, чем сам проект (рис. 22).

Рис. 22. Точность прогноза при высокой цене ошибки

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

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

Рис. 23. Нахождение баланса между оценкой и стоимостью оценки

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

Если проект находится в стадиях Старт или Рост[34] (подробности в видео Асхата Уразбаева «Как сохранить гибкость бизнеса»), то для него критично время эксперимента (рис. 24).

Рис. 24. Жизненный цикл продукта

На этих стадиях проект состоит из гипотез или просто идеи продукта. Гипотезы нужно проверить через эксперименты на рынке. Очевидно, что подробно описывать будущее рискованно для проекта, а порой оно настолько туманно, что описывать нечего. К тому же, пока мы пишем ТЗ, конкуренты могут успешно запустить эксперименты и забрать рынок первыми (рис. 25).

Рис. 25. Окно возможностей для написания эффективного ТЗ

С другой стороны, если мы делаем проект не в одиночку, то нужно общаться и ставить друг другу задачи. В таких проектах для постановки задач достаточно набросков на бумаге, общих описаний и постоянного общения без подробной документации.

Когда прекратить писать ТЗ?

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

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

Глава 6. Пять причин написать ТЗ

Что заставляет нас подробно описывать план работ до начала проекта

Перед заказчиком стоит почти