Журнал о разной технике

Негативные последствия ориентации на поиск недочетов в проекте: выводы и решение проблемы.

Дата публикации: 11.02.2016  

Хочу поделиться одной из своих PM’овских шишек, которая так сильно болит, что решил рассказать. Вдруг кто пожалеет, поймет, хорошо, а если вы узнаете себя и перестанете биться об эту же стену, буду очень рад.

Речь пойдет о контроле содержания проекта.
 

Быть или не быть?

Будучи PM’ом постоянно ощущаешь себя на линии фронта между разработчиками, тестировщиками, дизайнерами, заказчиками и пользователями мобильных приложений, переваривая требования к проекту в техническое задание, которое все равно приобретает законченный вид только к выпуску приложения (если хватает терпения и времени по ходу проекта).

Причем не важно, продуктовый ты менеджер или проектный, одна из ключевых задач — управление содержанием проекта с ограниченными сроками и ресурсами.

Под содержанием имеется ввиду не только набор крупной функциональности, как авторизация через соц. сети или push-уведомления, но и решение тысячи мелких деталей вида:

А должно ли показываться пользователю уведомление об успешной отправке отзыва, и какой текст там будет?

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

Пионер

Менеджер проекта обычно первый пользователь. Получая очередную, только что собранную Дженкинсом версию со старательно реализованной разработчиками фичей, сразу в глаза начинают бросаться всевозможные недочеты, которые свойственны первым версиям, и даже не замечаешь, как внутри просыпается тестировщик!
 

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

Что происходит на самом деле?

Синдром тестировщика

Рабочее время менеджера на проекте ограничено и должно тратиться на управленческие задачи, а недочеты и падения — работа отдела QA.

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

Поначалу было лестно слушать отзывы о своей хорошо проделанной работе, о гладко прошедшем этапе тестирования, о слаженном взаимодействии разработчиков с отделом QA, о хорошем уровне тестирования сборок разработчиками. Однако, финансовые показатели проекта упорно утверждали, что проект выплыл в плюс только из-за заложенных нереализованных рисков, а превышенные на 20% календарные сроки о лояльности заказчика.

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

После этого случая сделал вывод: проверяя задачу после разработчика, менеджер должен:

Фиктивные приоритеты

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

В результате исправление всех подряд багов без приоритетов приводит к неконтролируемому раздуванию сроков проекта, инициатором которого становится сам менеджер.

Сложная приемка

Ориентация на недочеты может негативным образом сказаться на отчетности заказчику, особенно если от очередной сборки приложения зависит промежуточная оплата проекта.

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

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

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

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

Такой подход позволяет сэкономить время проекта, деньги заказчика и поставщика, а также нервы всех участников.

В заключении

Будучи проектным менеджером при управлении содержанием следите, в первую очередь, за полнотой функциональности, а поиск недочетов оставьте компетентным людям из отдела контроля качества.

Успешных релизов, а главное, занимайтесь на работе своим делом!