Может ли хороший менеджер спасти провальный проект?

Как никогда не ошибаться в планировании ресурсов на проект? Как знать заранее, за какой срок и какую сумму ваша команда сможет выполнить текущие бизнес-требования? Это вопросы, которыми задаётся каждый проджект-менеджер, не уложившийся в сроки — а точнее, каждый второй из нас. 

Что делать менеджеру, чтобы не потерять доверие руководства, если проект сваливается в «долгострой»? Прежде всего — уметь договариваться со стейкхолдерами, у которых есть своё видение проекта. Часто руководители менеджеров слабо представляют себе процесс разработки ПО, из-за чего считают нужным мотивировать команду по-своему — урезая ресурсы. 

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

Правило пропорциональной компенсации

Если требования пользователей или высшего руководства включают изменение сроков в пределах 10%, бюджет также должен быть увеличен на 10%, чтобы сбалансировать условия. Если же сроки или бюджет сокращаются сильнее, практика показывает, что этот показатель должен быть возведён в квадрат. 

Например, конкурент запускает важную фичу уже через три месяца, а ваш релиз будет в лучшем случае через полгода. Высшее руководство принимает решение ускорить разработку вдвое, закрыв задачи за те же 3 месяца. В этом случае бюджет должен быть увеличен не в 2, а в 4 раза, иначе разрыв не покроет организационные расходы, затраты на адаптацию персонала, наём более квалифицированных людей и т. п. Приближение грубое: невозможно учесть все детали, но оно подтверждается на практике. Кроме этого, первоначальная позиция увеличить бюджет в 4 раза с большей вероятностью позволит в итоге сторговаться хотя бы вдвое. 

Правило обратного удвоения

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

Игра в числа

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

Немедленная оценка

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

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

Игра на понижение

Такая игра затевается, когда организация-разработчик ПО проигрывает своим конкурентам борьбу за право первыми вывести на рынок важную фичу. Это работает как на рынке B2C (например, публикацию коротких видео в социальной сети в 2020 году запустили сразу несколько крупных игроков), так и на рынке B2B (например, борьба за тендер, победа в котором сулит невероятный профит). Это вынуждает менеджера проекта не только ответить на вызов конкурента, но и превзойти его.

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

Поезд, который ушёл

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

Правило спрятанного качества или fake it until you make it

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

Эту тактику стоит использовать, если к нужному сроку важно именно наличие ПО, а не его стопроцентная работоспособность. Такое часто бывает, когда критичный срок устанавливает вышестоящий руководитель, чтобы проект был сдан в третьем квартале. А интеграция проекта в текущие процессы и отладка функциональности — это уже совсем другая история. 

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

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