Введение

Классическое начало дня нормального РПшника
Классическое начало дня нормального РПшника

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

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

О том, как это сделать – ниже.

Пример из жизни

Как-то я пришел в компанию спасать проект (обычно РП набирают именно так, имейте в виду). После быстрого анализа стало ясно, что сроки сдачи нереалистичные, команда – полторы калеки, а ТЗ согласовано на космолет. Причем, ТЗ уже подписали, потому что «так было надо» и пути назад нет: надо срочно разработать и сдать. Проектная классика.

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

То есть, надо было сделать:

  • быстро (потому что нужны деньги);

  • качественно (потому что бизнесу пообещали космолет);

  • недорого (потому что оценили MVP, а не космолет).

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

Как же так у меня получилось из смертельного проекта сделать историю успеха? Никакой удачи, это чистый опыт, которым я хочу поделиться.

Сделай или умри

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

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

Как видно из него, вариантов есть три:

1.      Путь героя – попробовать сделать 3 из 3х. Теоретически, это возможно. За счет того, что вы возьмете на себя работу аналитика, тестировщика, будете работать по 12 часов без обеда и заставите также работать всю вашу команду. Как итог, это приведет к вашему личному выгоранию, к выгоранию и недовольству команды (я не встречал людей, готовых работать без выходных на протяжении нескольких месяцев даже за очень большие деньги, потому что здоровье все равно дороже). И что самое «забавное», почти наверняка следующий проект вам дадут еще менее реалистичный и продавят на еще более дикие сроки и бюджет. Вы же один раз сделали, вдруг сделаете и во второй. «от работы дохнут кони, ну а я – бессмертный пони».
Конец в этой истории всегда будет печальный: вас уволят или вы уйдете сами, потому что поймете, что от вас хотят нереального.

2.      Путь администратора – пойти к руководителю и отказаться делать такой проект, потому что это невозможно. Формально, это самый верный путь, но есть проблема: я не встречал других проектов на старте, особенно крупных. Все хотят быстро и красиво, все любят «как в сказке» и никто не любит слушать ваши рассказы, что тут все не будет просто, «вот тут неясно, как интегрироваться с биллингом, вот тут миграция, а тут бизнес даже сформулировать требования не может». Вроде вы сказали все верно, но у людей будет ощущение, что вы просто боитесь и грузите всех оправданиями. Итог, почти наверняка будет печальным: вы покажете себя, как негативный РП и вас уволят. Зачем компании негативные люди, все любят позитивных ?

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

Если дипломат говорит «нет» — это не дипломат (с) из анекдота.

Была такая игра у меня в детстве: «черный с белым не носите, да и нет не говорите»: вам задают прямые вопросы, а ваша задача, не говорить ни «да», ни «нет». Отличная тренировка, чтобы научиться думать, искать варианты ответы, а не отвечать первое, что пришло вам на ум.

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

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

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

От этого понимания у вас в голове правильно встанут приоритеты. Если никто не умирает – ура, вам повезло, смещаем сроки вправо, проблема решена. Если кто-то умирает, аккуратно записываем, кто и почему и учитываем все эти факты в пункте 2 ниже.

2.      Фазирование (качественно).
Это основное оружие РП под давлением сроков. Принцип Парето: решить 80% боли пользователей за 20% сроков и потом сделать остальное. Но, чтобы предложить это бизнесу, вам потребуется детально вникнуть в проблему вашего заказчика, детально обсуждать ее с вашими разработчиками и аналитиками, иначе вы не сможете предложить хорошего решения. И именно поэтому работа РП – это не просто администрирование. Это выбор, в том числе, и технических решений. Да, вместе с командой. Но выбирать, обосновывать и потом отвечать - вам.

Зато, когда вы поймете проблемы бизнеса и варианты решения этих проблем – вы сами увидите, как быстро вы сами найдете те самые 80%, которые решают проблему вашего заказчика. И останется только разбить ваши работы на Этап 1 – он же Quick Win, он же MVP и Этап 2 – все остальное важное, но некритичное.

3.      Больше ресурсов (недорого).
Да, это тоже вариант. У меня была история, когда меня спросили на проекте в 15 человек и полгода (по оценке), что надо, чтобы я его сделал за 4 месяца? Я внимательно оценил и запросил +аналитика, 5 разработчиков и 1 сильного тест лида. И всех – до конца недели (был вторник). Я думал, что не дадут, отстанут. А мне дали. И пришлось сделать, и мы сделали. И хороший проект получился. Вполне рабочий вариант. Главное тут – помните, что на ваш «нереальный» запрос ресурсов могут ответить «да» и вам придется ответить за ваш запрос.

Решение задачи

Итого, мы получаем один из трех вариантов решения для вашего проекта:

Вариант 1: от изменения сроков никто не умирает, это просто «желательно сделать поскорее». Выход: увеличиваем сроки и делаем «недорого и качественно».

Вариант 2: мы разбили объем на критичное и просто важное и делаем «быстро и недорого».

Вариант 3: мы докинули ресурсов и делаем «быстро и качественно»

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

Точно также получилось и у меня на том проекте, о котором я говорил вначале. Он был сделан и успешно сдан в три фазы + часть доработок мы сделали для заказчика бесплатно, в виде подарка. В итоге довольны оказались все, получилось win-win.

Мораль

Ясно, что путей решения на самом деле будет больше. Для каждого проекта они будут более-менее уникальны, так как вообще ваш проект (по определению этого слова) уникален. Да, если нет опыта, будет непросто их использовать. Да, вам понадобится очень много коммуницировать со всеми участниками вашей проектной команды, от спонсоров, до разработчиков. Именно поэтому, я считаю, что, если вы не любите общаться с людьми – вам не надо в РП. Работа РП – это не передвигать задачки в Гантте или Джире. Это поиск компромиссов между заказчиком и командой, между «быстро», «недорого» и «качественно» и тому подобных.

На пересечении этих коммуникаций вы получите вариант, который неидеален, но устроит всех. Да, это потребует от РП огромного количества коммуникации. Гораздо больше, чем написать письмо. Здесь надо писать, звонить, собирать встречи с каждым по отдельности и потом всем вместе для утверждения. Это потребует от РП дополнительных усилий, которые формально он делать не должен. Но именно это и отличает начинающего РП от сильного РП. И именно за это, а не за расстановку задач на диаграмме Гантта руководителям проектов платят зарплаты 350+

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

Комментарии (2)


  1. Mavenrad
    17.08.2024 17:14

    Коммуникация, безусловно, важна, в процессе ведения проекта, но описанный здесь вариант реализации - MVP(быстро и недорого) + доработки(качественно), используется в индустрии настолько давно, что уже считается чуть ли не стандартом.
    Каким образом, увеличение количества коммуникаций позволит данному паттерну лучше вписываться в треугольник ограничений?
    Кмк, когда надо пилить быстро, созвоны не добавляют ценность, а отбирают время у команды


    1. peterzh Автор
      17.08.2024 17:14

      MVP + допилить - да, стандарт. А я считаю, что это только один из трех вариантов. Когда приходит 10 задач, а ресурсов есть на 5 (а так часто бывает и в проектных офисах и во внутреннем ИТ), просто запилить MVP по всем можно и не успеть - все равно ресурсов то только на 5.

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

      Что до коммуникаций - все просто. Заказчик считает, что MVP - это одно, команда считает - другое. РП надо поговорить и с теми, и с теми (о да, заказчиков бывает много и у каждого свое представление о счастье). С разрабов желательно получить несколько вариантов, чтобы была переговорная вилка для заказчика. Далее идем по заказчикам, получаем замечания, затем к команде, к линейному (сроки, приоритеты), затем к заказчику...

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