Срыв сроков выпуска ПО – часто возникающая проблема, от которой не застрахован ни один проект. Причины такого явления кроются в разнообразных непредвиденных ситуациях, связанных с деятельностью заказчиков, разработчиков или тестировщиков. К счастью, эту проблему, как и большинство других, можно предотвратить.

Что такое «достаточность времени» и как ее рассчитать?

1. Определение
Итак, что подразумевается под «достаточностью времени», и чем «достаточное время» отличается от «номинального»? «Номинальное время» затрачивается на работу в идеальных условиях (без непредвиденных ситуаций). Но бывает ли так на практике?

Например, для установки компьютерной игры или программы в прилагаемой спецификации ПО приводятся номинальные и рекомендуемые (достаточные) характеристики ПК. Не следует ожидать от продукта высокой производительности, если технические параметры компьютера будут близки к номинальным требованиям. Именно поэтому рекомендуемые (достаточные) параметры для установки ПО всегда превышают номинальные.

В нашем же случае «достаточное время» – это время, которого гарантированно хватает для завершения поставленных задач даже в случае возникновения непредвиденных проблем. В этой статье я приведу реальные примеры из моей практики работы на двух проектах. Один из них обозначу «Отелем», а другой – «Утилитой».

2. Расчет
Для определения потребности времени и минимизации его нехватки предлагаю воспользоваться диаграммой Исикавы. Она проста и наглядна, с ее помощью можно визуально облегчить разбор причин, которые приводят к недостатку времени на тестирование. Сама диаграмма применяется для определения причин возникновения проблем, но в нашем случае она поможет просто и понятно систематизировать все потенциальные причины, приводящие к срыву сроков, а также обозначить их компенсаторы.

Для простоты и наглядности используемая мной для демонстрации диаграмма будет весьма краткой. Для вашей задачи она «ощетинится» и создаст хорошую базу для расчетов, как на иллюстрации ниже.

По клику на картинку откроется полная версия. 

После создания основы диаграммы мы проведем мозговой штурм и проанализируем проблемы.

Виды проблем

Наиболее характерными техническими проблемами являются «падение» сервера или неожиданное отключение интернета/электричества у тестировщика (это не так критично в том случае, когда тестировщиков много). Кто виноват и что предпринять? Поиск виновного не поможет делу. Если «упал» сервер, на котором «висит» проект, то работа останавливается полностью. Насколько долго? Если сервер контролируется заказчиком/разработчиком, то все не так страшно. Но вот если он принадлежит стороннему хостеру…

Пример из практики: «Утилита», проблема с сервером.
Первоначально на проекте хватало имеющихся мощностей и тестовых стендов, но от заказчика поступила специфическая задача, потребовавшая обращения к стороннему провайдеру с целью получения необходимых стендов. Был найден провайдер-хостер, передана необходимая для конфигурации окружения информация, обозначены сроки выполнения. Внезапно хостер стал «кормить завтраками», нарушая предварительные договоренности.

Время шло, сроки поджимали, работа стопорилась… Лихорадочно велись поиски других вариантов, НО ВРЕМЯ БЫЛО УПУЩЕНО! В итоге заказчик предпочел отказаться от наших услуг без развернутого объяснения причин. И это понятно: в конечном счете, именно мы как исполнители работ брали на себя возможные риски и должны были учесть их при подготовке и выполнении несложной задачи по организации стендов для проведения тестирования.

Нужно помнить, что технические проблемы в сфере IT – не редкость, они возникают в том или ином масштабе. И уж если мы подстраховываемся в бытовых вопросах (например, откладывая средства на непредвиденные расходы), то риск вероятного отказа оборудования должен быть учтен обязательно. Проблемы с сервером могут возникнуть при тестировании как сайта, так и софта (если ПО во время своей работы взаимодействует с сервером). Следовательно, нужно заранее предусмотреть запас времени с учетом простоя, в течение которого сисадмин будет восстанавливать работоспособность сервера. Вопрос с поломками ПК самого тестировщика я рассмотрю чуть позже.

По клику на картинку откроется полная версия. 

NB! Здесь и далее числовые значения я буду назначать условно, так как цель статьи – не мастер-класс по учету рисков времени, а рассмотрение проблемы как таковой.

По клику на картинку откроется полная версия. 

По клику на картинку откроется полная версия. 

Социальные проблемы
Фактор социальных проблем проявляется достаточно часто, но при этом почему-то нередко игнорируется при планировании времени работы. Проблемы эти сложны для расчета компенсации, но предусматривать их наличие нужно в любом случае: ведь, к примеру, тестировщик может заболеть, уйти в отпуск, уволиться или даже умереть.

Конечно, опытный ПМ уже наперед предусматривает варианты замены людей в том или ином случае. Но, например, поручив Пете работу его коллеги Васи, неожиданно выбывшего из проекта, он вряд ли сможет заставить Петю работать по 16 часов в день. Даже если такое и удастся – скорее всего, Петю очень скоро придется заменять другим тестировщиком (если, конечно, кто-то выразит желание выполнять обязанности троих человек и работать 24 часа в сутки). Следовательно, нужно учитывать, что даже при замене людей тестирование замедляется.

Можно, конечно, попросить кого-то перенести законный отпуск (хотя, дело это довольно трудное, особенно если речь идет о семейных сотрудниках). Но если сотрудник заболел или уволился, придется жертвовать временем, отведенным для тестирования – ввод другого сотрудника в проект сразу не поможет стабилизировать ситуацию, так как ему нужно войти в курс дела. И если смерть и увольнение – относительно редкие случаи, то отпуск, а особенно болезнь сотрудника или семейные обстоятельства, – обычные явления.

Примеры из практики: «Отель», увольнение сотрудников.
В течение нескольких месяцев из проекта по ряду причин ушли ПМ (со стороны заказчика), ведущий тестировщик и команда разработки (третья сторона).

Система отслеживания ошибок Jira, которая также использовалась в качестве системы управления проектом, была развернута на сервере команды разработки. После ухода этой команды из проекта нам довелось столкнуться с целым рядом проблем. Мы остались без заведенных багов и созданных задач. В спешном порядке пришлось подбирать удобные для использования системы багтрекинга и ведения документации. Параллельно с этим мне приходилось оформлять свеже-найденные баги в багтрекере нашей компании, а после установки нужной системы у заказчика – переносить все уже заведенные баг-репорты к нему. Кроме того, я заводил новые баг-репорты и восстанавливал «утраченные», а также проводил регресс исправленных.

В условиях постоянного цейтнота мы все-таки уложились в сроки. Из этого эпизода были сделаны выводы, и сейчас подобные ситуации станут лишь досадной неприятностью, но существенных проблем не принесут.

Пример из практики: «Утилита», болезни, отпуск, уход из проекта.
Сначала интересный проект развивался неплохо, работа шла слаженно… В июле один из тестировщиков ушел из проекта, команда сократилась до 3 сотрудников (включая ТМ). В конце июля – начале августа я сначала заболел на 2 недели, а затем ушел в двухнедельный отпуск. На следующий день после моего возвращения ТМ ушел в отпуск, а затем заболел (в сумме — месяц). Мне пришлось заменять его, но это получилось не слишком удачно.

Итого: 8 недель работы команды, теоретически состоящей из трех человек, а практически – из двух. Реальная история. При этом заказчика не должно заботить, кто и чем болеет или на сколько уходит в отпуск. Обязанности по соблюдению заявленных сроков лежат на нас.

Пригодилось то, что наш ТМ взял хороший запас по времени для выполнения задач, причем использовал сложные насыщенные таблицы расчета рисков и времени. Тут уж никуда не денешься: либо мы грамотно учитываем риски, либо овертаймим, чтобы как-то не упустить дедлайн. Расчет всегда полезен: если мы запросим неоправданно много времени, заказчик может найти кого-то «побыстрее», если слишком мало – мы с большой вероятностью накажем сами себя. Из опыта других фирм я наслышан об иных проблемах. Например, сотрудник мог просто без предупреждения уйти на лучшую работу, не волнуясь за трудовую книжку, или сотрудника могли с треском уволить по разным причинам.

Практически все упомянутые случаи (кроме отпуска), предугадать невозможно, но все они ведут к нарушению обычного режима работы. Поэтому их необходимо предусмотреть (с учетом собственного или чужого опыта), и выделить определенное количество времени для искоренения негативных последствий.

Если мы чего-то не учтем – кому-то придется работать по ночам, а у кого-то будет «гореть под ногами земля».

Теперь рассмотрим случай отпуска сотрудника. Допустим, в среднем по календарю отпуск длится 2 недели. Замена отпускника другим работником повлечет за собой те же 6 часов затрат. Учтем также, что в это же время нам придется помочь коллегам на другом проекте, потратив 4 рабочих дня. Суммарно по всем рискам выходит 6 часов + 6 часов + 32 часа = 48 часов.

По клику на картинку откроется полная версия. 

Я не рассматриваю такие критические случаи, как увольнение или смерть сотрудника, чтобы не перегружать статью сложными подсчетами (приходится искать нового сотрудника в проект на постоянной основе). Учитывать такого рода случайности или нет – зависит от вас, но в правильном расчете мы должны учитывать все более или менее реалистичные инциденты.

На диаграмме видно, что у нас набежало 170 «красных» часов. И не обольщайтесь «зеленой» суммой: она показывает, насколько мы можем компенсировать риски по времени в идеальном случае. В реальной практике компенсаций может и не быть, поэтому мы должны рассчитывать на худший вариант и быть готовыми к нему.

Пример из практики: «Отель», ТЗ и переоценка своих сил.

Все мы знаем, что задачи должны быть предельно внятно описаны и грамотно поставлены, и тогда тестировщику останется просто сделать свою работу. В данном случае картина была иная, но заказчику был нужен результат, а не разбор полетов. Пришлось, применив метод обратной инженерии, выяснять, как что работает, и какие формулы задействованы. В итоге мы разобрались в задаче и составили в Гугл-Таблицах калькулятор для расчета конечной цены. Правда, времени это заняло очень много.

Второй случай относился не столько к тестированию, сколько к составлению документации. По обоюдной договоренности между заказчиком и нами была поставлена задача привести ТЗ в порядок, чтобы самим иметь под рукой детально описанные требования, которые можно показать и другим в случае необходимости. Я озвучил заказчику срок выполнения работ – 3 недели, которые в итоге растянулись на 6 недель. Я просчитался на 100%, переоценив свои силы и не имея опыта в подобных расчетах. К счастью, это не имело последствий, так как на проекте были задержки со стороны разработки. Меня никто не трогал, и я спокойно завершил свою задачу.

Да, мы не всегда можем объективно оценить свои силы и определить реальные сроки. Ошибка в большую сторону – это еще не беда, но при ошибке в меньшую сторону кому-то придется наверстывать упущенные дни. Большой удачей будет, если наверстать их получится. Ну а если нет?

Как рассчитать необходимое время и учесть опыт на будущее
Конкретные расчеты по этому виду рисков я не буду вписывать в диаграмму, так как не рассматривал типичные случае. Это не означает, что таковых не бывает, – просто по ним трудно предусмотреть затраченное время. Каждый инцидент по-своему уникален и может «украсть» разное время: от 0,5 часа до 7 часов работы (последняя цифра взята из реального случая, когда через 7 часов работы ТМ понял, что выдал сотрудникам для теста не ту версию продукта).

При невозможно проведения точного расчета я советую увеличить номинальное время на 10-15%. Конечно, не факт, что введенной прибавки хватит, но, как показывает практика, такой буфер является оптимальным: это все-таки лучше, чем не учитывать риски вообще (диаграмму смотрите в следующем подразделе).

Форс-мажоры
Сюда я отношу остальные проблемы, которые при рассмотрении всех известных рисков не учитываются просто потому, что их невозможно представить.

Пример из практики: «Отель», излишний учет.
На проекте «Отель» у меня была таблица, где учитывалось среднее количество багов, времени, потраченного на их обнаружение и репорт, и времени на внесение изменений в чек-листы. Благодаря этой таблице можно было предусмотреть, сколько времени может занять тестирование того или иного функционала, нового или уже внедренного, но обновленного. Все было бы хорошо, но выдавались дни, когда заводилось по 25 (плюс-минус 2-3) репортов. Исходя из ряда обстоятельств, нужно было регрессить все ошибки, не забывая о проверке нового функционала и прочих не менее приоритетных задачах. Сроки сдвигались, так как физически сложно было обработать весь этот массив в оговоренное время.

Сроки есть сроки, и если они не соблюдаются, нужно подключать других работников. Проект должен быть сдан вовремя. Следовательно, нужно вновь учитывать время по аналогии с ситуацией заболевания/увольнения тестировщика. Слишком много учета? Но вряд ли вы предпочтете «бешеный темп работы перед дедлайном».

По клику на картинку откроется полная версия. 

Выглядит сложно? Да, но опыт вскоре позволит вам определять нужный запас времени почти на интуитивном уровне (хотя, конечно, отказываться от расчетов не следует). Вы скажете, что «другие не занимаются этой «ерундой» и у них «все ок»? Я могу привести в пример совсем другие случаи, когда игнорирование этой «ерунды» приводило к печальным последствиям.

Заключение

Подведем итоги. Возможно, ранее нам казалось, что любые возникающие при тестировании проблемы можно решить за два-три дня, лишь слегка превысив заявленные сроки. Теперь, прочитав статью и взглянув на диаграмму, вы видите, что планируемый дефицит времени достигает значительных величин (в нашем случае – более 56%) даже при учете только самых типичных случаев.

Эта цифра подтверждается неоднократными наблюдениями: во многих случаях для качественного тестирования проекта приходится добавлять к планируемому времени 50-100% – смотрите «Управление рисками в высокотехнологичных проектах: состояние и подходы управления» (М.Д. Годлевский, А.А. Поляков). Но даже и эти проценты, как я уже говорил, – всего лишь средние величины, потому достаточное время необходимо рассчитывать для каждого конкретного проекта.

Да, у нас может быть определенное количество времени на компенсации (в нашем примере – 106 часов), но его использование не всегда возможно. Если мы подготовимся к дефициту времени без учета компенсации, то наличие компенсации в том или ином объеме станет для нас приятным бонусом. Но, не учитывая всех факторов риска и не выделяя достаточно времени на проведение тестов, мы с большой вероятностью получим проваленный дедлайн.