Вернемся к стартапу. Мы включили повышенную передачу. Шесть месяцев мы вели нескончаемые разговоры, но теперь мы действительно должны выпустить продукт. Ничто так сильно не заставляет всех призадуматься, как четко поставленный дедлайн. Хорошая новость заключалась в том, что контроль качества делал свое дело: в нашей базе данных багов было полно работы. Плохая новость состояла в том, что никто не заглядывал в базу данных багов уже несколько месяцев.
В тот период у нас был «арендованный» вице-президент, и когда временные менеджеры ушли, он вдруг стал очень энергичным. Он быстро определил нашу цель — выпустить продукт бета-качества, но он так же быстро понял, что мы не имеем ни малейшего представления о качестве нашего продукта, потому что у нас осталась еще целая куча непроверенных багов.
Мы назначили совещание, на котором присутствовали руководитель по контролю качества, руководитель техподдержки и я. Рекомендация вице-президента звучала так: «Проверьте каждый баг вот таким образом и сообщите мне, сколько багов нам нужно устранить для того, чтобы выпустить бета-версию». После этих слов он покинул помещение.
Каждый баг? Но их 537! Это значит, что мы должны «прочитать» каждый баг, по возможности воспроизвести его, а затем принять по нему компетентное командное решение. Предположим, что в среднем на один баг уходит пять минут, значит, мы говорим… о каких-то несчастных… 45 часах сортировки багов! Это было невыполнимой задачей. У меня будет всё, что нужно для работы с багами; у меня будут люди, которыми я могу руководить, но солнца по субботам я не увижу в течение следующих двух недель.
Давайте сделаем небольшое отступление и поговорим о гигантской ценности, которой обладает база данных багов. Во всех компаниях, в которых я работал, единственным источником правдивой информации о продукте, выраженной в количественном виде, была именно база данных багов. Все маркетинговые документы быстро утрачивают свою свежесть. Планы тестирования ветшают. Базы данных тестовых вариантов медленно превращаются в бесполезный перечень задач для контроля качества. А база данных багов остается единственным источником данных о продукте.
Я это отлично знаю. Я знаю, что, хорошенько перелопатив базу данных багов, я смогу составить самое точное представление о продукте.
Но есть одно «но»!
Пятьсот тридцать семь несортированных багов? Сорок с лишним часов нудной работы с багами?
Простите, что? Мы должны выпустить продукт!
Обычно, когда я сталкиваюсь с невыполнимой задачей, я начинаю с анализа, потому что анализ дает данные, позволяющие принять взвешенное решение. Итак, я делаю то, что уже делал раньше: тщательно рассчитываю, сколько времени у меня уйдет на то, чтобы закончить эту работу. Пять минут × 537 = невозможно. Этот честный расчет обдает меня ледяной волной ужаса. Как, скажите на милость, я собираюсь выполнить свои другие пять задач, если я должен 40 часов сортировать баги? Когда я окончательно утопаю в своем страхе, я перестаю думать о выполнении задачи и думаю только о страхе.
Мой совет в данной ситуации: «Начните работу!»
«Но, Рэндс… Мне нужно сделать 300 тестов, а еще…»
Стоп! Идите и сделайте один тест. Прямо сейчас!
«Подожди, подожди, Рэндс. Послушай! Им нужна эта спецификация завтра в девять утра…»
Тссссссс! Тихо! Иди пиши. Один параграф. Прямо сейчас.
Добро пожаловать в Теорию капли.
Наш злодей
Традиционно мой первый шаг при выполнении невыполнимых задач — занести невыполнимую задачу в свой список дел.
«Вот так! Теперь она в моем списке. О да! Разве это не прекрасно? Она стоит в моем списке дел, а значит, однажды она будет выполнена, верно?» Нет, неверно! Мы вносим задачу в список дел только потому, что это помогает нам избавиться от
В каждой истории есть свой злодей. В нашей истории злодей — это
Именно он однажды сказал вам, что это предложение о работе слишком чудесно, чтобы быть правдой. Помните ту компанию? Именно он просто исчез на три месяца после того, как вы отказались от того удивительного предложения. Именно Критик сказал вам: «Как, черт возьми, они могут делать подобные предложения, если я даже не понимаю их бизнес-модель?»
Именно Критик был тем человеком, который шесть лет назад успокоил вашего внутреннего гика и убедил вас не покупать HD ТВ до тех пор, пока они не станут действительно хорошими. Именно он сказал вам однажды, что вы не должны верить тараторящему руководителю по разработке, который уверенным голосом гарантировал, что его команда выдержит все сроки. Критик сказал вам тогда: «Люди, которые так быстро разговаривают, так же быстро умеют маскировать пробелы в своих знаниях».
Критик был прав. Критик заслужил доверие. А еще Критик может усилить ваши страхи в самый неподходящий момент. Именно поэтому сейчас он все же выступает в роли злодея.