​​В цикле разработки продукта есть периоды, когда времени мало и нужно сделать всё четко и без ошибок. Это время перед релизом. В таких ситуациях помогают чеклисты c порядком действий, которые должны предшествовать выпуску новой версии. в Virtuozzo у нас был годами отработанный чеклист, который для каждого нового релиза незначительно корректировался. Типичные действия из чеклиста: сборка была собрана с релизными флажками, "символы" для отладки выложены на внешний сервер, команды маркетинга и техподдержки уведомлены о предстоящем релизе, оф. сайт подготовлен для анонсирования новой версии и т.д. С таким чеклистом и рядовые инженеры и менеджеры были уверены, что если люди, ответственные за выполнение чеклиста, все по нему сделали, то релиз можно считать состоявшимся. И если в Virtuozzo чеклист представлял собой документ в Word или отдельный тестплан в TMS и не имел никакой юридической силы, то в некоторых компаниях прохождение релизного чеклиста это отдельный процесс, в который вовлечены юристы, отделы по безопасной разработке ПО и избежать выполнения всех пунктов релизного чеклиста можно только в исключительных случаях, одобренных руководством.

На выходных дочитал книгу "Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям." и ещё больше поверил в силу чеклистов. Автор рассказывает на примерах (их очень много в книге) как с помощью чеклистов снижают вероятность ошибок в хирургии и авиации. К примеру он рассказывает, что причиной, по которой никто не пострадал в аварийной посадке Airbus A320-214 на Гудзон, являются как раз чеклисты и слаженная работы экипажа воздушного судна.

На иллюстрации чеклист для пилота бомбардировщика B-32 из статьи NASA об использовании чеклистов.