• Подготовь мне оценки сбоев в нашем продукте следующего поколения.
• Я могу подготовить их, если вам нравятся цифры на основе галлюцинаторных предположений.
• Они мне как-бы нравятся.
• Думаю, у нас есть понимание.

Пару лет назад вышел у нас спор с одним проблемным сотрудником, который активно пытался выдвинуться на agile волне. Ему была поставлена задача разработать crash-recovery процедуру для семейства продуктов, которые разрабатывала наша группа.

Сотрудник упорно пытался отбрыкаться от этой задачи, убеждая нас, что это все пустая трата его времени и наших денег. YAGNI, YAGNI, YAGNI! – пытался он нас убедить – ведь это же функционал, который мы хотим видеть только потому, что мы боимся, что он нам в один день понадобиться. А если мы внедрим супер правильные agile техники в проект, то весь этот crash-recovery не нужен, потому что софт просто не будет сбоить. И делал все, что угодно, но только не то, о чем его просили. В итоге задачу отдали другому сотруднику, а с agile евангелистом пришлось расстаться.

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

Понятно, что глупо валить проблемы с сервером БД на нас, разработчиков прикладного ПО. Разумеется, что-то в наших приложениях вызывает этот сбой. Вряд ли мы сознательно делаем что-то «нелегальное». Соль ситуации в том что именно мы, разработчики ПО, а не производитель БД, отвечаем за обеспечение целостности данных для бизнес-пользователей. Это нам пользователи мечтают выставить счет за вынужденный простой, а не производителю БД. И именно наша задача выработать подход, как пользователям работать дальше с учетом возникшей проблемы.

Ситуация в цифрах: убытки от часа простоя одного пользователя с учетом всех задержек и простоев в бизнес-цепочке оценивается в 300 у.е. Таких пользователей 30-40 в день. Риски оперирования на нецелостных бизнес-данных 4000 у.е. на транзакцию, таких транзакций 20-30 тысяч в день. Производитель БД активно изучает проблему, но ничего не обещает. Но и о прекращение работы речь не идет, поскольку останавливать бизнес на неопределенный срок никто не собирается. Поэтому на повестке совещания по данному кризису стоит ровно один вопрос: как оперировать продуктами, чтобы не влететь в астрономические убытки?

Может ли в такой ситуации YAGNI-евангелист предложить что-то, кроме как открыть экстренный спринт с юзер стори «как пользователь, я хочу быть уверен, что я могу продолжать работу после аварии на сервере БД»? Да, может: например, размахивать руками и уверять, что авария сервера БД – это мелочь. Прикладной же софт очень надежный. Верьте мне… Ага, счас! «Слушай, на кону вот столько денег. Ты серьезно предлагаешь пользователям оперировать следующие пару недель с проблемами неизвестного характера и неизвестными последствиями?» ‑ спросят опытные эксплуатационщики? Вряд ли найдется, что ответить.

* * *

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

Что-то нам подсказывает, что Pointy-hair boss и Дилберт в этом комиксе друг-друга так и не поняли.