Introduction to the ‘Fail Fast!’ Principle in Software Development
Whenever an error occurs in a running software application there are typically three possible error-handling approaches:
- The Ignore!approach: the error is ignored and the application continues execution
- The Fail fast! approach: the application stops immediately and reports an error
- The Fail safe! approach: the application acknowledges the error and continues execution in the best possible way
Which approach is the best one?
Which one should you apply in your application?
Before answering this vital question, let us first look at a simple example.
Suppose we have to write a (rudimentary) web application that displays a warning message near a water fountain to warn people that the water is polluted.
The following HTML code does the job:
The result displayed in the browser looks like this:
Now let us insert a small bug. Instead of </b> we write <b> after DO NOT , as shown below:
Two interesting questions arise:
- What should happen?
- What will happen?
The second question is easy to answer. We just have to feed our browser with the buggy HTML code. This is the result — as displayed in Chrome, Edge, Firefox, Internet Explorer, and Safari at the time of writing:
Before reading on, ask yourself: “Which approach has been applied by the browsers?” …
Obviously, the Fail fast! approach has not been applied because the application continued and did not report an error. The only difference to note is that more text is now displayed in bold. But the message as a whole is still displayed correctly and people are warned. Nothing to worry too much!
Let’s try another bug. Instead of <b> we write <b before DO NOT , as shown below:
This is the result — again as displayed in the browsers mentioned before:
Panic! Now the program does exactly the opposite of what it is supposed to do. The consequences are terrible. Our life-saving application has mutated into a killer-application (but not the kind of killer-application we all dream to write one day).
It is important to be aware of the fact that the above example is not just a theoretical, exaggerated example. There are a good number of real-life cases with ‘little bugs’ having catastrophic consequences, such as the Mariner 1 spacecraft that exploded shortly after lift-off due to a ‘missing hyphen’. For more examples, see: List of software bugs.
As we can see from the above example, the consequences of not applying the Fail fast! approach vary largely and can range from completely harmless to extremely harmful.
So, what is the correct answer to the important question “What should happen?”
Well, it depends on the situation. There are, however, some general rules.
The first rule is:
We should never “Ignore!” an error — unless there is a really good reason to do so.
This rule is well known and doesn’t need any further explanation.
Remember rule 6 of The 10 commandments for C programmers, eloquently written in old English by Harry Spencer:
- “If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ‘it cannot happen to me’, the gods shall surely punish thee for thy arrogance.”
The second rule is:
During development we should apply the Fail fast! approach.
The rationale behind this rule is easy to understand:
- The Fail fast! approach helps in debugging.
As soon as something goes wrong, the application stops and the error message helps to detect, diagnose and correct the error. Therefore the Fail fast! approach leads to more reliable software, reduces development and maintenance costs and prevents frustrations and catastrophes that would otherwise risk to appear in production mode.
Even if a bug doesn’t lead to a severe failure, it is always best to detect it as soon as possible, because the costs to fix a bug raise exponentially with the time passed in the development cycle (compile-, test-, production-time). - The consequences of bugs appearing during development mode are generally not harmful.
The customer doesn’t complain, money doesn’t go to the wrong account, and rockets don’t explode.
Failing fast is commonly considered as a good practice in software development. Here are a few supporting quotes:
- “Encourage good code habits … This has many corollaries, including ‘fail fast’ …”
The Google Guava team — Philosophy Explained - “… ‘failing immediately and visibly’ sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production.”
Jim Shore / Martin Fowler — Fail Fast - “Some of the hardest bugs to track down have (in part) been caused by code that silently fails and continues instead of throwing an error. … It is better to return an error as soon as a failure case is detected.”
Henrik Warne — 18 Lessons From 13 Years of Tricky Bugs - “We don’t wait long periods of time before learning that something isn’t working. We fail fast …”
Joshua Kerievsky — An Introduction to Modern Agile
However, the situation can change radically when the application runs under production mode. Unfortunately, there is no one-size-fits-all rule. Practice shows that it is generally better to also apply the Fail fast! approach by default. The final damage resulting from an application that ignores an error and just continues arbitrarily is generally worse than the damage provoked by an application that stops suddenly. For example, if an accounting application stops working suddenly, the user is angry. But if it silently ignores an error and continues and produces wrong results (such as an unbalanced balance sheet), the user is very angry. ‘Angry’ is better than ‘very angry’. Therefore, in this case the Fail fast! approach is better.
In our previous HTML example, the Fail fast! approach would also be much better. Suppose that, instead of continuing execution, the browsers displayed an error message. Then the developer(s) would immediately get aware of the problem and the code could quickly and easily be fixed, without causing any harm. But even if the buggy code went into production (for strange reasons), then the worst case scenario would be less terrible. Displaying “Please drink this water” can be dreadful. On the other hand, not displaying any message, or just displaying an (incomprehensible) error message, would probably just result in a very low percentage of people daring to taste a small quantity of water.
In practice, each individual case must sometimes be studied carefully. This is especially true if the greatest possible damage is high, such as in medical applications, money transfer applications or space invader applications. For example, applying the Fail fast! rule is obviously the right approach as long as a rocket to Mars didn’t take off. But as soon as the rocket has started, stopping the application (or, even worse, ignoring an error) is no longer an option. Now the Fail safe! approach must be applied in order to do the best we can do.
A good option is sometimes to fail fast, but minimize the damage. For example, if a run-time-error occurs in a text editor application, the application should first automatically save the current text in a temporary file, then display a meaningful message to the user (“Sorry, … but your current text is saved in a temporary file abc.tmp”), optionally send an error report to the developers, and then stop.
Hence, the third rule:
In critical applications the Fail safe! approach must be implemented in order to minimize damages.
- In development mode we should always apply the Fail fast! approach.
- In production mode:
We should generally favor the Fail fast! approach by default.
Critical applications that risk leading to high damages in case of a malfunction need customized, context-specific and damage-eliminating (or at least damage-reducing) behavior. Fail safe and react appropriately! approaches must be applied in fault-tolerant systems.
The same idea is expressed by the excellent Rule of Repair in The Art of Unix Programming, written by Eric Steven Raymond:
- “Repair what you can — but when you must fail, fail noisily and as soon as possible.”
Note: Further information and examples are available in Wikipedia under Fail fast, Fail safe, and Fault tolerant computer system.
In any case, it is always helpful to use a development environment that supports the Fail fast! principle. For example, a compiled language supports the Fail fast! rule because compilers can immediately report a whole plethora of bugs. Here is an example of a stupid bug that easily escapes the human eye and can lead to ‘unwanted surprises’, such as a hanging system due to an infinite loop:
Typos like this (i.e. writing row_indx instead of row_index ) are common and are immediately caught by any decent compiler or (even better) by an intelligent IDE.
Luckily there are a good number of very effective Fail fast! features that can be natively built into a programming language. They all rely on the following rule:
Errors should preferably be automatically detected at compile-time, or else as early as possible at run-time.
Examples of powerful Fail fast! language features are: static and semantic typing, compile-time null-safety (no null pointer errors at run-time!), design by contract, generic type parameters, integrated unit testing, etc.
Even better than detecting errors early is to not allow them by design. This can be achieved if the programming language doesn’t support error-prone programming techniques such as global mutable data, implicit type conversions, silently ignored arithmetic overflow errors, thruthiness (e.g. "" , 0 and null are equal to false ) etc.
Therefore, we should always prefer a programming environment ( = programming language + libraries + frameworks + tools) that supports the Fail fast! principle. We will debug less and we will produce more reliable and safe code in less time.
[Пост] Fail Fast
Наиболее раздражающая часть разработки — это поиск ошибок (дебаггинг). Не ошибок, поиск которых занимает пару минут, а ошибок, на поиск которых требуются часы, а их находка происходит при связана с нестандартной ситуацией, или же поиски ведут в тупик.
К счастью, существует методика, позволяющая резко сократить количество подобных багов. Она не уберет все баги, но позволит находить дефекты гораздо быстрее.
Безотлагательная и видимая ошибка.
Многие люди рекомендуют разрабатывать устойчивые приложения, посредством автоматической обработки ошибок. В результате, приложение ‘failing slowly’ падает тихо. Программа продолжает работать после ошибки, но ошибка еще даст о себе знать позже при странных обстоятельствах.
Система, написанная по методике Fail Fast ведет себя в точности до наоборот — если возникла проблема, то ошибка возникает немедленно и она абсолютно видна. Эта техника кажется неинтуитивной, так как ‘failing immediately and visibly’ звучит так, будто система будет непрочной, но по факту это сделает системы более устойчивой. Баги легче найти и исправить.
Для примера рассмотрим метод, который читает свойство из конфигурационного файла. Что случиться, если свойства не существует? Как правило это null или значение по-умолчанию.
Тот же метод, написанный по методике fail fast:
Представим этот метод как часть веб-приложения, которое подвергается небольшому обновлению. Представим, что разработчик случайно сделал опечатку в конфигурационном файле. Для кода, который возвращает значение по-умолчанию, все выглядит нормально. Но когда пользователь начнет использовать приложение, он заметит загадочную медлительность. Логично, что это займет целый день выдергивания волос.
Результат будет совершенно другим, если использовать методику Fail Fast. В тот момент, когда разработчик опечатается, приложение прекратит выполнение, сообщив об ошибке, причем очень подробно. Разработчик стукнет себя по лбу и исправит проблему за 30 секунд.
Методика Fail-fast
Ключ к методике — assert. Assert’ы — это очень маленькая часть кода, которая проверяет условие и останавливает приложение, если условие не выполнено. Итак, если кто-то начнет делать что-то неправильно, то assert’ы заметит проблему и сделает её видимой. Большинство языков имеет встроенные assert’ы, но они не всегда вызывают исключения. Также, они как правило довольно обобщенны, недостаточно выразительны и вызывают дубликаты. Методика предлагает писать собственные assert’ы.
Как бы то ни было, для собственного assert’а нужно дать знать, когда его добавлять. Самым простым способом сделать это — добавить поясняющий комментарий. Комментарии — множественные документированные допущения о том как код работает или как он должен быть назван. Когда вы пишете подобный комментарии, подумайте, как его можно поместить сам assert.
Когда вы пишете метод, избегайте написания подтверждения проблемы в самом методе (его стоит вынести). Тесты и практика TDD — лучший путь к обеспечению правильности отдельного метода. Красота assert’ов в их способности отлавливать проблемы на швах системы — взаимодействие остальной части с конкретным методом.
Написание assert’ов
Отличным примером, который покажет превосходство использования assert’ов — Assert.notNull(). NullPonterException возникает достаточно часто, поэтому было бы неплохо, чтобы программное обеспечение сообщало, когда пустая ссылка создается неправомерно. С другой стороны, если использовать Assert.notNull() повсеместно, то код превратиться в море из неиспользуемых assert’ов. Так что я ставлю себя на место незадачливого разработчика, отлаживающего систему. Когда происходит данная ошибка, как я могу легко предотвратить её?
Иногда, язык автоматически подсказывает нам, где произошла ошибка. Например, Java и C# вызывает исключение, когда имеет место быть указатель на null. В простом случае stack trace ведет нас к месту, где произошла ошибка.
Здесь мы приходим на строку 3, где обнаруживаем, что null был явно передан в метод. Ответ не всегда так очевиден, но, как правило, он обнаруживается после нескольких минут поиска.
Теперь рассмотрим более сложный случай, такой как:
Stack race ведет нас к линиям 6 и 22, тогда как реальная ошибка произошла на 17 строке — getProperty() вернул null. А на 22 строке была попытка использовать свойство Length. Stack trace привел нас в никуда, типичный ситуация для кода, написанного в стиле ‘failing slowly’.
В последнем случае имеет место быть то, что может предотвратить fail fast методика. Необходимо, чтобы программа давала больше информации для поиска ошибки. Итак, для кода можно применить следующее правило — если приложение применяет методику fail fast самостоятельно, то нет необходимости использовать что-либо дополнительное. То есть, если идет речь о вызове метода на объекте, который предположительно является null, то программа сама подскажет где это произошло. А вот если речь идет о присвоении пришедшего из вне значения в переменную, то необходимо проверить, не является ли значение null.
Это правило расстановки меток может помочь вашим программам тоже, но основная цель — чтобы задуманный процесс шел по плану. Добавляя assert’ы в код, необходимо рассудительно их размещать, подобно примеру выше. Думать о том какие ошибки могут возникнуть и почему. Размещать assert’ы так, чтобы приложение сразу же упало при их появлении, так проблемы будет проще найти.
Устранение дебаггинга.
Иногда stack race — это все, что нужно для обнаружения ошибки. В других случаях, нужно знать, что находится в переменной. Но даже если знать содержимое переменной, бывает тяжело воспроизвести ошибку. Не правда ли было бы лучше, если программа сразу же будет говорить, если что-то пошло не так?
Когда вы пишете assert’ы, необходимо думать о том, какая информация понадобиться для исправления ошибки, если та произойдет. Эту информацию необходимо включить в сообщение assert’а. Не надо повторять условие assert’а, stack race сам приведет вас туда. Вместо этого, включите ошибку в контекст.
Возвращаясь к чтению из конфигурации, сообщение об ошибке может выглядеть по-разному.
Но лучшим вариантом будет Assert.notNull(result, “can’t find [” + key + “] property in config file [” + file + “]”);. Данный вариант дает всю необходимую информацию.
Не нужно слишком стараться, при написании сообщений. Сообщения для разработчиков, они не должны быть дружелюбны для пользователя.
Прочная ошибка.
Fail fast выглядит так, словно приложение хрупко. Конечно, это делает дефект видимыми, что сказать о том, когда приложение окажется у пользователей. Никто не хочет, чтобы приложение сломалось из-за конфигурационного файла.
Типичное желание — не использовать assert’ы. Не делать этого! Запомните, ошибка, произошедшая у пользователя — прошла через тестирование. И скорее всего, у вас возникнут проблемы с её воспроизведением в данном случае. Такие ошибки сложно найти, а хорошо расставленные assert’ы помогут сэкономить дни напряжений.
С другой стороны, поломки приложения никогда не бывают уместны. К счастью, есть золотая середина. Можно создать глобальный обработчик ошибок, чтобы изящно отлавливать неизвестные ошибки, такие как assert’ы, и сообщать о них разработчикам. В частности, приложение может сказать пользователю, что произошла неизвестная ошибка, и неявно сообщить разработчику о ней. В некоторых системах, будет отправлено сообщение и приложение приступит к следующему процессу.
При использовании глобально обработчика ошибок, необходимо избегать перехват всех исключений в остальных обработчиках исключений. Они должны предотвращать достижение локальных исключений до глобального обработчика. В частности, если вы заняли ресурс, его необходимо освободить. Так, если ошибка произошла, приложение продолжит со свежим, рабочим состоянием.
Принцип «Fail Fast!» в разработке приложений
В далёком 2014 году уже был перевод этой статьи Кристиана Ньюманса, но впоследствии Ньюманс удалил старую статью, существенно дополнил её и опубликовал на Медиуме. Во-вторых, вероятно, после очередных обновлений Хабра, у старого текста поехало форматирование, и читать его стало тяжело. В общем, считаю, что статье необходимо дать второй шанс.
В этой статье описан принцип «Fail Fast!». Что это? Зачем он нужен? Как этот принцип поможет нам писать лучший код?
Всякий раз, когда в запущенном приложении происходит ошибка, есть три возможных подхода к её обработке:
Ignore! — ошибка попросту игнорируется, приложение продолжает свою работу как ни в чём не бывало.
Fail Fast! — приложение завершается с ошибкой.
Fail Safe! — приложение учитывает ошибку в своей работе и продолжает свою работу по наилучшему сценарию из возможных.
Какой подход является лучшим? Какой из них следует применять в приложении?
Прежде чем ответить на этот жизненно важный вопрос, давайте посмотрим на простой пример.
Допустим, нам нужно написать примитивное веб-приложение, которое будет отображаться рядом с фонтаном и показывать прохожим предупреждающее сообщение, о том, что вода в фонтане грязная. Вот код, который это делает:
Браузер покажет нам следующее сообщение:
Теперь добавим небольшой баг. Укажем <b> вместо </b> после фразы DO NOT:
Возникают два интересных вопроса:
Что должно произойти?
Ответ на второй вопрос получить довольно легко. Достаточно скормить наш код браузеру. Chrome, Edge, Firefox, Internet Explorer и Safari покажут нам следующее (на момент написания статьи):
Прежде, чем читать дальше, спросите себя: «Какой подход применяют браузеры?»
Очевидно, это не «Fail Fast!», поскольку приложение не сообщило об ошибке и продолжило, как ни в чём не бывало. Да, теперь больше текста стало отображаться жирным шрифтом, но текст по-прежнему корректен, и люди из фонтана не пьют. Не о чем беспокоиться!
Хорошо, давайте добавим другой баг. Вместо <b> мы напишем <b перед фразой DO NOT:
Упомянутые ранее браузеры покажут нам следующее:
Ужас! Теперь программа делает прямо противоположное, и последствия этому ужасны — приложение, призванное спасать жизни, превратилось в приложение-убийцу (но, к сожалению, не в то, которое каждый из нас мечтает когда-нибудь написать).
Важно осознавать тот факт, что приведённый выше пример не является преувеличением. Существует множество реальных случаев, когда мелкие баги приводили к катастрофе — например, космический корабль «Маринер-1», взорвавшийся через несколько мгновений после старта из-за пропущенного дефиса. Дополнительные примеры смотрите в Списке багов программного обеспечения.
Как мы видим, последствия отказа от «Fail Fast!» сильно отличаются и могут варьироваться от безвредных до катастрофических.
Итак, каков правильный ответ на вопрос: «Что должно произойти?»
Это зависит от ситуации. Но есть общие правила.
Правило первое:
Никогда не игнорируйте ошибку (не применяйте правило «Ignore!») — если для этого нет действительно веских причин.
В дополнительных пояснениях это правило не нуждается. Вспомним Заповедь Шестую из «Десяти Заповедей C-разработчика»:
Если провозглашается функция, возвращающая код ошибки в трудный час, ты должен обработать ошибку, даже если это утроит твой код и вызовет боль твоих пальцев, ибо, если ты уповаешь, что «это не случится со мной», боги обязательно накажут тебя за высокомерие.
Правило второе:
На этапе разработки применяйте подход «Fail Fast!».
Обосновать это правило легко:
Подход «Fail Fast!» помогает при отладке. При любой ошибке выполнение кода прерывается, а сообщение об ошибке помогает обнаружить её, диагностировать и исправить. Поэтому подход «Fail Fast!» помогает написать надёжный код, снижает затраты на разработку и поддержку и предотвращает катастрофы в продакшене. Даже если ошибка не приводит к серьёзному сбою, всегда лучше обнаружить её как можно скорее, поскольку стоимость багфикса растёт в геометрической прогрессии вместе со временем, прошедшим в цикле разработки (компиляция, тестирование, вывод в продакшен).
Ошибки, возникающие на этапе разработки, обычно не приводят к серьёзным последствиям. Заказчик не жалуется, деньги не зачисляются на неправильный счёт, ракеты не взрываются.
«Fail Fast!» считается хорошей практикой в разработке ПО. Вот несколько подтверждающих цитат:
Поощряйте хорошие практики кодинга. Следствий этому много, в том числе, и «fail fast!»
— Команда Google Guava, «Объяснение философии»
Может показаться, что «немедленный и явный сбой» сделает Ваше приложение более уязвимым, но на самом деле, он сделает его более надёжным. Такие баги легче находить и исправлять, и их меньше попадёт в продакшен.
— Джим Шор, Мартин Фаулер, «Fail Fast»
Некоторые из сложнейших для выявления багов были вызваны кодом, который молча падает и продолжает работу, вместо того, чтобы выбросить исключение. Лучше выбросить исключение, как только сбой будет обнаружен.
Хенрик Варн, «18 уроков после 13 лет работы с Tricky Bugs»
Зачем ждать, пока выяснится, что что-то не работает? Сразу падайте.
— Джошуа Кериевский, «Введение в современный Agile»
Однако, ситуация может радикально измениться с выводом приложения в продакшен.
К сожалению, здесь единого правила не существует. Практика показывает, что по умолчанию лучше использовать подход «Fail Fast!». Ущерб, нанесённый приложением, которое игнорирует ошибку, обычно значительно превышает ущерб, нанесённый приложением, которое внезапно падает. К примеру, если банковское приложение падает, пользователь злится. Но если банковское приложение отображает неправильный баланс, пользователь очень злится. «Злой» лучше, чем «очень злой». Поэтому, лучше использовать «Fail Fast!».
В нашем примере с HTML-кодом подход «Fail Fast!» так же более оправдан. Предположим, что вместо сообщения браузеры выводили бы сообщение об ошибке. Разработчики сразу бы узнали о проблеме и быстро её исправили. Но даже если глючный код по каким-то причинам попадёт в продакшен, последствия будут не так уж и страшны. Призыв «Please drink this water» может иметь катастрофические последствия, в то время, как отсутствие сообщения вообще или отображение непонятной ошибки приведёт к тому, что очень малый процент прохожих выпьют воду из фонтана.
На практике же, каждый конкретный случай требует индивидуального подхода. И это особенно касается приложений, способных нанести большой ущерб — например, в медицинских, банковских приложениях или приложениях для захвата космоса. Применение «Fail Fast!» обосновано ровно до того момента, пока наша ракета не начала взлетать. Как только произошёл старт, остановить приложение (или, хуже того, проигнорировать ошибку) уже не вариант. Тут в свои права вступает подход «Fail Safe!».
Иногда хороший вариант: упасть, но минимизировать ущерб. К примеру, когда падает ваш текстовый редактор, он сначала сохраняет текущий файл во временный, затем показывает пользователю сообщение: «Бла-бла-бла, Ваши изменения были сохранены во временный файл abc.temp», отправляет отчёт об ошибке разработчикам, и только потом падает.
Отсюда третье правило:
В критических приложениях подход «Fail Safe!» должен быть реализован для того, чтобы свести к минимуму ущерб.
Подведём итог.
На этапе разработки используем только «Fail Fast!».
В продакшене: по умолчанию используем «Fail Fast!»; критически важные приложения, несущие риск большого ущерба в случае сбоя, нуждаются в индивидуальном, зависящем от контекста и исключающем (или минимизирующем) ущерб поведении. В отказоустойчивых системах должны применяться подходы «Fail Safe!» и «React Appropriately!» («Реагируйте адекватно!»)
Та же идея выражена в великолепном «Правиле исправления» книги «Искусство программирования Unix» Эрика Стивена Реймонда:
Исправляйте всё, что можно — но если нужно упасть, падайте громко и как можно скорее.
В любом случае, очень полезно использовать среду разработки, поддерживающую принцип «Fail Fast!». К примеру, его поддерживают компилируемые языки, поскольку компиляторы сообщают об ошибках компиляции. Вот пример глупой ошибки, которая ускользает от человеческого глаза, но может привести к бесконечному циклу:
Подобные опечатки легко обнаруживаются приличным компилятором или (что ещё лучше) интеллектуальной IDE.
К счастью, существует огромное количество «Fail Fast!»-фич, встроенных в язык. Все они основаны на правиле:
Ошибки необходимо обнаруживать во время компиляции или как можно раньше во время работы приложения.
Вот примеры мощных «Fail Fast!» языковых фич: статическая и семантическая типизация, null-safety при компиляции, дженерики, встроенное модульное тестирование и так далее.
Но чем обнаруживать ошибки на ранней стадии, лучше не допускать их по замыслу. Это достигается, когда язык программирования не поддерживает уязвимые методы программирования — к примеру, глобальные изменяемые данные, неявная типизация, молчаливое игнорирование арифметических ошибок переполнения, достоверность (например, «», 0 и null равны false) и так далее.
Поэтому всегда нужно отдавать предпочтение окружению (языки программирования / библиотеки / фреймворки / инструменты), которое поддерживает принцип «Fail Fast!». Нам придётся меньше заниматься отладкой, а наш код будет надёжнее и безопаснее за меньшее время.
Принцип Fail Fast ⛔️ — почему нужно «Проваливаться быстро» в бизнесе
Это подход к работе, в основе которого лежит максимальная толерантность к ошибкам и фокусировка на эксперименты, в результате которых эти ошибки возникают.
Зачем нужен принцип Fail Fast
Такой подход позволяет командам очень быстро учиться и получать новые данные. В результате команда становится более эффективной, а бизнес может принимать решения на основе данных.
Как применить принцип Fail Fast
Начните фокусировать команду на эксперименты и проверку гипотез. Скорее всего, первые попытки будут провалами, и это нормально — покажите команде, что лояльно относитесь к этому, и продолжайте тестировать гипотезы до первых результатов, Полученные данные используйте для корректировки ваших активностей.
Принцип Fail Fast
Это ключевой принцип «бережливого» менеджмента. Используя этот принцип вы можете сократить риски, связанные с разработкой и запуском нового продукта, а также улучшить итоговое качество продукта.
У этого принципа есть ряд схожих, которые часто ставятся в одну линию вместе с ним:
- Fail Early — «Проваливайся рано»
- Fail Often — «Проваливайся часто»
- Fail Cheap — «Проваливайся дешево»
- Learn Fast — «Учись быстро»
Мы разберем, почему важны эти принципы и как они могут улучшить ваш процесс разработки и запуска продукта.
Fail Fast как принцип для получения обратной связи
В основе этого принципа лежит получение быстрой обратной связи. Именно поэтому рядом с Fail Fast часто также пишут Fail Often и Learn Fast («Проваливайся часто» и «Учись быстро») — ведь чем больше вы совершаете ошибок, тем больше у вас обратной связи и новых данных, тем быстрее вы можете научиться тому, что нужно вашим клиентам.
Современные подходы к управлению проектами и продуктами, особенно подходы базирующиеся на Agile философии, стремятся к тому, чтобы максимально быстро получать обратную связь, чтобы быть в контакте с реальностью здесь–и–сейчас в условиях быстро изменяющегося рынка и ситуации.
Основная идея состоит в том, что чем дольше мы не получаем обратную связь, тем больше возникает рисков.
Мы можем перестать попадать в потребности клиентов. Если мы не получаем обратную связь, или получаем её очень редко и мало, мы можем начать фантазировать и галлюцинировать то, чего на самом деле хотят клиенты.
Это значит, что мы можем потратить время и деньги на то, чтобы создать продукт, который на самом деле никому не нужен. Или нужен — но не такой, а значит, нужно будет потратить дополнительные деньги и время, чтобы его сделать таким, какой он должен быть.
Принцип Fail Fast для поиска прибыльных рынков
Большинство стартапов проваливается.
Даже если вы делаете все грамотно и ответственно, используете правильный подход к запуску нового продукта (например, используете подходы Lean Startup и Customer Development) — вы все равно можете обнаружить, что рынка здесь нет, или что вы не можете его обслуживать.
Это значит, что для того, чтобы найти что–то по–настоящему стоящее и прибыльное, ценное клиентам и возможное к осуществлению — скорее всего вам придется несколько раз провалиться, чтобы найти тот самый «голубой океан».
Что же делать, когда ряд неудач — это неизбежность?
На помощь приходит принцип Fail Fast. Ведь чем быстрее вы «проваливаетесь», тем вы вкладываете меньше ресурсов в нахождение и реализацию нужной идеи.
Если проваливаться медленно, это чревато довольно понятными рисками — у вас кончатся деньги и/или мотивация пробивать бетонную стену.
Именно поэтому рядом с Fail Fast часто ставят приставку Fail Early и Fail Cheap — «Проваливайся рано» и «Проваливайся дешево».
Это и понятно — если на разработку и реализацию идеи уходит, например, неделя и несколько тысяч рублей — провал здесь не такой уж драматичный, как провал стартапа с выделенным на разработку бюджетом в несколько миллионов и разработка которого шла в течение последних полгода.
Небольшой оффтоп. Вспоминается знаменитая цитата Томаса Эдисона: «Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают». Можно сказать, что это про «настойчивость», но подумайте о том, сколько бы времени и денег пришлось затратить, если бы каждая попытка была бы долгой и дорогой. Скорее всего, из этого бы ничего не вышло. Это скорее не про настойчивость, а про принцип Fail Fast!