Однажды клиент позвонил мне в субботу утром и сказал фразу, которую я потом слышал ещё десятки раз в разных вариациях: «Олег, у нас в системе баг. Как такое вообще возможно? Мы же заплатили за качество». Баг был в том, что на одном отчёте дата выводилась в американском формате. Система при этом уже третий месяц принимала заказы, считала склад и экономила отделу продаж по два часа в день. Но в голове у клиента жила идеальная система, и любая трещина в ней воспринималась как предательство. Я его понимаю. Я сам много лет строю системы для бизнеса и в молодости тоже мечтал выпустить что-то безупречное. Потом жизнь объяснила мне, что безупречных систем не бывает, а бывают системы, которые работают, и системы, которые так и не вышли из макета.
Баг не ошибка, а признак жизни
Посмотрите на любой живой организм. Наш с Вами организм каждый день производит мутировавшие клетки, ошибки копирования ДНК, сбои иммунитета. Мы не умираем от этого только потому, что в нас встроены механизмы обнаружения и исправления. Природа не стремится к идеалу, она стремится к устойчивости. Программная система устроена так же. Она живёт в среде, которую никто не может описать полностью: пользователи нажимают кнопки в непредсказуемом порядке, браузеры обновляются без спроса, банк меняет формат выписки, бухгалтер вводит в поле «телефон» слово «перезвонить». Каждое такое столкновение с реальностью рождает баг. И это НОРМАЛЬНО. Баг означает, что система соприкоснулась с жизнью, а не стоит под стеклянным колпаком.
Ошибок нет только в той системе, которой никто не пользуется. Я говорю это клиентам совершенно серьёзно. Если за месяц после запуска Вам не прислали ни одного бага, у меня для Вас плохая новость: скорее всего, системой никто не работает. Сотрудники продолжают вести учёт в Excel и тетрадке, а Ваш красивый интерфейс открывают раз в неделю, чтобы показать директору.
Как перфекционизм убивает проекты
Мечта об идеальной системе убила больше проектов, чем нехватка денег. Это не фигура речи, это моя личная статистика. Сценарий всегда похожий. Команда делает первую версию, показывает её владельцу, и тот находит десяток мелочей: отступ не такой, кнопка не того оттенка, в редком сценарии с тремя скидками сразу итог считается на копейку иначе. Вместо запуска начинается полировка. Через месяц находится ещё десяток мелочей, потому что глаз уже натренирован их искать. Через полгода выясняется, что рынок ушёл, конкурент запустился с кривым, но работающим продуктом и собрал первых клиентов, а бюджет потрачен на второстепенные элементы, которые никто из пользователей даже не заметил бы.
Это как художник, который двадцать лет пишет одну картину и не показывает её никому, потому что левая рука портрета ещё не совершенна. Ван Гог за свою жизнь написал около девятисот картин, и среди них много откровенно слабых. Но именно поток работ сделал его Ван Гогом. Вершина появляется из количества и обратной связи, а не из бесконечной шлифовки первого холста.
Цена перфекционизма складывается из трёх вещей, и все они бьют по бизнесу больнее любого бага:
- сорванные сроки выхода на рынок, а время на рынке нельзя докупить;
- избыточная сложность кода, потому что каждая «идеальная» деталь обрастает особыми случаями и костылями;
- раздутый бюджет на бесконечные правки того, что не приносит ни клиентов, ни денег.
Важно не наличие багов, а скорость и критичность
Взрослый вопрос звучит не «есть ли в системе ошибки», а «как быстро мы их находим и чиним, и насколько они опасны». Здесь я всегда предлагаю клиенту простую сортировку, которую можно провести за пять минут на любом созвоне. Есть баги, которые останавливают деньги: заказ не проходит, оплата не доходит, данные теряются. Их чинят немедленно, в выходные и ночью, и это правильно. Есть баги, которые мешают работать, но обходятся: сотрудник делает лишний клик или пересчитывает вручную. Их чинят в ближайшем спринте. И есть косметика: дата не в том формате, иконка съехала на мобильном. Её собирают в список и закрывают пачкой, когда до неё дойдут руки.
Тот самый субботний баг с датой относился к третьей категории. Когда мы вместе с клиентом разложили все его жалобы по этим трём корзинам, оказалось, что в первой корзине пусто, во второй две позиции, а в третьей двадцать. Настроение у клиента поменялось мгновенно. Система из «сломанной» превратилась в «работающую с мелкими недочётами», хотя в коде не поменялось ни строчки. Поменялся только взгляд.
Система, которая работает с ошибками, приносит деньги. Идеальная система, которая не запущена, приносит только счета.
Иммунитет вместо стерильности
Если баги неизбежны, значит, вкладываться нужно не в стерильность, а в иммунитет. В инженерном смысле это несколько очень приземлённых вещей. Мониторинг, который сообщает о падении раньше, чем позвонит клиент. Логи, по которым ошибку можно воспроизвести за десять минут, а не за два дня. Автоматические тесты на критические сценарии: деньги, заказы, права доступа. Быстрый и безопасный деплой, чтобы исправление уезжало на сервер за минуты, а не ждало «релизного окна» раз в месяц. И, что часто забывают, понятный канал, через который пользователь может сообщить о проблеме, не написав три письма и не дозвонившись до директора.
Город не строят без пожарных и скорой помощи только потому, что архитектор очень хорошо спроектировал дома. Пожары всё равно будут. Хороший город отличается не отсутствием пожаров, а тем, что пожарная машина приезжает за семь минут. В Ingello мы именно так и строим системы: сначала закладываем механизмы обнаружения и быстрого исправления, а потом уже наращиваем функциональность. Отчасти поэтому мы когда-то и начали делать Fractal: когда код генерируется из описания, целый класс рутинных ошибок просто не возникает, а исправление в одном месте описания расходится по всей системе. Но и там баги бывают, я не буду делать вид, что мы изобрели вечный двигатель.
Как жить с несовершенной системой
Перфекционизм часто прячется за благородными словами о качестве. Качество действительно важно, я сам могу полчаса спорить о названии одной переменной. Но качество системы определяется тем, насколько хорошо она решает задачу бизнеса, а не тем, насколько она похожа на картинку из головы. Поэтому мой практический совет такой. Завтра возьмите список всего, что Вас раздражает в Вашей системе (или в проекте, который Вы никак не можете запустить), и разложите его на три корзины: останавливает деньги, мешает работать, косметика. Всё, что в первой, чините сегодня. Вторую планируйте. Третью отложите и честно спросите себя, стоит ли ради неё откладывать запуск ещё на месяц.
А если запуска ещё не было, запускайтесь. С багами, с неидеальными отступами, с отчётом, где дата не в том формате. Живая система учится у пользователей, а идеальный макет под стеклянным колпаком ничему не учится и никому не помогает. Баги исправляются, упущенное время нет. Успешных Вам запусков, коллеги, и пусть Ваши баги будут мелкими и быстро пойманными.
