Термин «факап» (от англ. «fuck up» – проиграть, провалиться) в общем смысле означает неудачу, поражение. Как правило, факап – это не просто досадная ошибка, а некий масштабный провал, неудовлетворение чьих-либо желаний или ожиданий.
Жизнь как один большой факап
Неудачи преследуют нас всю сознательную жизнь. В детстве мама много раз просила тебя помыть посуду и выбросить мусор. Ты раз за разом не выполнял ее просьбу, делая свои «очень важные» дела. Вечером тебя ждал скандал и неделя без приставки. В школе, а потом и в институте, ты частенько не оправдывал ожидания своих учителей и преподавателей. Невыполненные домашние задания влекли за собой проваленные сессии. Факап следовал за факапом.
Во взрослой жизни ситуация редко улучшается, крупные и мелкие провалы продолжают настигать нас на каждом шагу. Не сдал отчет на работе, забыл поздравить подругу/друга с днем рождения, опоздал на автобус, не выполнил просьбу «второй половины», не покормил кошку, три месяца забывал полить фикус… Список можно продолжать бесконечно.
Почему мы факапим?
Недооценка рисков
Планируя работу, мы часто недооцениваем ее сложность и переоцениваем свои возможности. Когда мы ставим задачу кому-то другому, то совершаем ту же ошибку: считаем задание слишком легким и забываем, что выполнять его будет такой же человек, как и мы.
Несколько лет назад мы должны были портировать игру из Вконтакте на Facebook. Весь функционал должен был остаться прежним. Предельно легкая задача, не правда ли? Менеджер проекта считал так же. Он был твердо уверен, что в новой версии не будет обнаружено много багов. Возможно, возникнут небольшие проблемы с версткой, но с этим разработчики справятся очень быстро. Откуда взяться ошибкам в игре, которую непрерывно тестируют отдел профессионалов и тысячи игроков? Исходя из этого, он заложил на тестирование и исправление ошибок одну неделю. При первом тестовом прогоне было найдено 119 (!!!) багов (из них 10 блокеров, которые не позволяли пройти в игре дальше). Результат: игра была выпущена только через месяц, еще полгода шла доработка и исправление миноров.
Форс-мажоры
Ничто никогда не происходит так, как мы изначально задумали. Исполнители болеют и увольняются, заканчиваются заложенные в бюджете деньги, метеориты падают на Челябинск. Да и закон Мерфи никто не отменял: если есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдет.
Нужно было срочно протестировать новые фичи, которые на следующий день планировали отправить в продакшн. Новость о сроках выхода релиза висела на официальном сайте, а менеджер проекта лично сообщил о дате обновления нескольким стратегически важным клиентам. В 11:15, когда рабочий день только начался, сработала пожарная сигнализация. Всех вывели из здания. Тестирование было остановлено. Бдительный посетитель БЦ, в котором располагалась организация, обнаружил подозрительный пакет. Всех эвакуировали до приезда саперов, затем пакет долго проверяли на наличие взрывчатки. День был потерян, релиз на следующий день не состоялся.
Человеческая природа
Все мы сталкивались со сладостным чувством лени и с тем, как порой сложно заставить свой мозг работать более 20 минут, не отвлекаясь на «котиков в фейсбуке». И дело не только в лени и ее проявлениях, как может показаться на первый взгляд. Причина гораздо глубже: так уж устроен наш мозг. Он очень изобретателен в выдумывании миллиона причин для того, чтобы не выполнять тяжелую и особенно монотонную работу. Полагаясь на других, мы также сталкиваемся с их прокрастинацией.
Приложение было переведено на 6 иностранных языков. Любая фраза отдавалась переводчикам, а затем перевод вставлялся в админку, из которой подтягивался в приложение. Проблем никогда не возникало, но в тест-кейсах всегда был прописан пункт с проверкой на каждом языке. После нового релиза из одной страны начали приходить сообщения в техподдержку о том, что вместо некоторых фраз на экране появляется нечто странное. Расследование показало, что тестировщик проигнорировал проверку локализации, так как в это время все его мысли были заняты выбором новой гитары. После этого случая тест-менеджер более пристально следил за работой этого тестировщика и старался ставить его на проекты вместе с более ответственными коллегами.
Неправильное планирование
К сожалению, при планировании все вышеперечисленное учитывается не всегда. Мы рассчитываем, что все пойдет как надо, и в этот раз все будет сделано правильно и вовремя. У каждого есть своя формула расчета времени на проекте. К примеру, я использую формулу «3,14*R+2 недели», где R – это идеальное время выполнения проекта без учета непредвиденных обстоятельств; 2 недели – срок, за который может быть сделан практически любой работоспособный проект, пусть и не в лучшем виде; 3,14 – число Пи.
Тест-менеджер получил запрос от руководителя проекта: в понедельник необходимо выделить трех тестировщиков для срочного тестирования новой фичи. Менеджер согласовал с другими проектами отсутствие тестировщиков в понедельник и вторник, за выходные было подготовлено тестовое окружение. Началась неделя, три тестировщика были готовы приступить к работе. Но, как оказалось, художники не успели нарисовать новые окна, а программисты не закончили фичи. Два дня тестировщики не могли приступить к полноценному тестированию, так как ПО «падало» даже на смоук-тестах. В среду стабильная версия была наконец передана в тестирование, но тестировщикам пришла пора возвращаться на свои проекты. Дедлайн был сорван, многим сотрудникам пришлось работать сверхурочно.
Что делать?
Железные дедлайны
Практика доказывает: если нет конкретной даты, к которой задача должна быть сделана, то задача не будет сделана никогда. Вспомни все свои сессии: каждые полгода приходил дедлайн, и ты экстренно делал все, что должен был сдавать, писать и учить на протяжении 6 месяцев. После экзамена ты, конечно, обещал себе, что это был последний раз, и в следующем семестре ты будешь ежедневно усердно работать и сдавать все вовремя. На следующей же сессии все повторялось. Все понимают, что делать все в последний момент – это очень плохая практика. Но раз за разом большинство студентов (и не только) собирают волю в кулак и делают финальный рывок. Дедлайн работает.
Для повышения эффективности лучше назначать один дедлайн и несколько промежуточных точек, к которым должны быть достигнуты определенные результаты (вспомни промежуточные контрольные и коллоквиумы). Если «промежуточный дедлайн» был сорван – не стоит скрывать этот факт от заинтересованных сторон, и тем более надеяться все наверстать к следующей контрольной точке. Оцени последствия и влияние их на стратегические сроки, продумай решение (а лучше несколько), затем приди к начальнику (или заказчику) и обсуди с ним возникшую ситуацию и возможные варианты решения.
Учет предыдущего опыта при планировании
Учиться на своих ошибках намного полезнее, чем на чужих, но те тоже всегда нужно учитывать. После окончания проекта сядь и проанализируй: что именно пошло не так, чего можно было избежать, что забыли предусмотреть, что ты мог сделать, чтобы исправить ситуацию. Используй полученный опыт в будущем планировании.
Читай чужие истории успеха, следи за проектами коллег, делись своим опытом. Многие проектные команды для этих целей проводят ретроспективы. Например, в Scrum-командах ретроспектива проводится после каждого спринта. Если твоя компания работает по другой методологии – не беда, проектные ретроспективы также широко распространены и проводятся после сдачи проекта.
Зачем проводится ретроспектива? Затем, чтобы ответить на 3 основных вопроса:
- Что понравилось?
- Что не понравилось?
- Что мы могли сделать лучше?
Эта процедура позволяет собрать и проанализировать мнение коллег, сформулировать и высказать свои мысли, а также продумать заранее, каких ошибок можно избежать в будущем. Подробнее о проведении ретроспективы можно прочитать в книге Норма Керта «Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться вперед».
Концентрация внимания
Повторюсь: наш мозг изобретателен и хитер в вопросах отлынивания от обязательной рутинной деятельности. И для борьбы с этим заложенным самой природой свойством мозга разработан ряд методик:
- «метод помидора» – предполагает разбиение задач на 25-минутные периоды, сопровождаемые короткими перерывами;
- «техника пустого инбокса» – помогает освободить мозг, отделить «думать» от «делать» и разложить все по местам;
- «обман мозга» – пообещать себе поработать всего 5 минут (обычно самое сложное – начать, потом все втягиваются в процесс и работа идет), напугать себя последствиями («не сделаем и на нас рухнут все кары небесные»), заинтересовать себя поощрением (например, известный метод чтения скучного учебника – раскладывать мармеладки по абзацам и съедать очередную, когда дочитываешь до нее);
- блокировка всех развлекательных ресурсов на время работы. Для этого придумали множество полезных утилит. Можно выбрать ту, которая подходит именно тебе (например, Internet Security Controller);
- еще множество психологических уловок и методов, помогающих сделать то, на что часто не хватает мотивации или сил…
Ранняя диагностика
Любая глобальная проблема вырастает из маленькой ошибки. Чем раньше ты ее заметишь, тем быстрее сможешь исправить, и тем менее катастрофическими будут последствия. Никогда не скрывай проблему. Если у тебя что-то не получается – иди к руководителю. Если член твоей команды пришел к тебе и честно сказал, что он не справляется, – не впадай в истерику и не ругай его. В противном случае он предпочтет в следующий раз промолчать, а проблема всплывет перед дедлайном, когда решить ее будет уже сложно. Если сроки срываются – сообщи об этом заказчику, ведь у него тоже есть обязательства перед кем-то. Вместе вы сможете придумать приемлемое решение.
В заключении
Смирись с тем, что факапы случаются со всеми. Ты не исключение. Будь готов к этому и предупреди того, кто поставил задачу тебе. Предусмотри самые печальные сценарии (вся твоя команда уволилась, что ты будешь делать), обязательно расскажи об этом заказчику. Возможно, ты далеко не первый, кто хочет минимизировать ущерб от провалов.
Используй современные методологии:
- «Waterfall», «Scrum», «Kanban» и т. д. – выбери свою методологию разработки и используй ее инструменты по максимуму.
- «Метод прогрессивного джипега» предполагает, что в любой момент времени общий вид проекта ясен, меняется только степень его готовности.
- «ФФФ» (fix time, fix budget, flex scope) позволяет расставить приоритеты и всегда отдать заказчику проект в оговоренные сроки (возможно, придется урезать функционал, но сроки не будут сорваны и бюджет не увеличится).
Главное – помнить, что факапы на проектах неизбежны. Но в наших силах минимизировать последствия и извлечь из этого уроки на будущее.
