Как не надо релизить проекты. Работаем с требованиями, оценкой и оплатой
Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.
Мы старательно делали, наконец-то закончили, а стейкхолдеры почему-то не рады. Такое может случиться на любом проекте. По статистике, 2/3 больших IT-проектов неуспешны — закрылись либо оказались проблемными. Остается всего треть проектов, которые прошли гладко.
Данные статистики подтверждаются моими наблюдениями и опытом коллег — больше половины проектов проходят с какими-то отклонениями. Если трудности возникают так часто, возможно, стоит готовиться к ним заранее.
Сразу сделаю лирическое отступление к названию статьи. Мы все знаем, что релизят код, а проект заканчивают. Но мы будем говорить о том, как делать не надо. А за 8 лет в проектном менеджменте у меня, как и у каждого РМ’а, накопилось множество историй из серии «как лучше не делать». Думаю, мой опыт поможет коллегам подготовиться к возможным неприятностям и не совершать тех же ошибок.
Как не сделать ущербный проект
Об успехе проекта и продукта я больше писал в прошлой статье, здесь повторю коротко, чтобы сразу договориться о понятии «успешности». В контексте проджект-менеджмента благополучным будет проект, сданный вовремя, в рамках заданного объема и стоимости. Да, в этом случае менеджер хорошо сделал управленческую работу, но это как-то не о продукте, не о результате и не о миллионе пользователей.
Можно измерять результат успехом продукта, без привязки ко времени, срокам и деньгам. То есть мы успешны, если создали что-то нужное миллионам пользователей, продукт пошел, он «у всех в карманах». Для большинства заказчиков итоговый продукт очень важный, поэтому допустимы небольшие срывы сроков, изменения бюджета, объема работ. Можно не вписаться копейка в копейку, зато выпустить качественное решение.
Соответственно, если мы сосредотачиваемся на ценности, которую создаем в продукте, возникает впечатление, что часть, связанная со временем, сроками, деньгами — не важна. В итоге можем сделать успешный продукт, бизнес работает, заказчик доволен. И при этом совершенно ошибиться с бюджетом, временем — вообще со всем. Покажу, как это бывает, на реальном примере.
Сайт для продажи геральдических знаков
Полгода мы делали проект: контентный сайт для продажи геральдических знаков. Привлекли отличного UX-специалиста, дизайнера, сделали прекрасный UX и закрыли все задачи в оговоренные сроки. При этом релиз сайта отодвинулся на полгода. Давайте посмотрим, почему так получилось.
Основной контентной составляющей сайта были фотографии геральдических знаков. Изначально менеджеры, которые вели проект, приняли решение, как будем делать фото. Сделали около 500 картинок, дошли до самого релиза, зарелизились, и тут сайт увидел главный босс. Посмотрел и сказал: «Фотографии не подходят. Убирайте». Через полчаса мы все откатили, а потом ждали еще полгода, пока заказчик сфотографировал свои знаки в другом виде.
Процесс растянулся: они долго выбирали, какие должны быть ракурсы, виды, потом долго фотографировали, долго заливали, и только через полгода мы зарелизились вторично.
Достигли мы успеха или нет? Ведь наша часть проекта была своевременно выполнена профильными и глубоко погруженными специалистами. И даже заказчик в итоге был доволен результатом. Мы выполнили задачу, но затормозили со стороны контента, который был за рамками нашей ответственности. Клиент заранее знал, что будут нужны картинки.
Где-то со стороны заказчика случилась банальная ошибка: кто-то понял не то или передумал, или у кого-то возникла новая идея. И в момент релиза оказалось, что старые фото не подходят, надо переделывать. В теории есть проблема, но можно ли было ее решить или избежать?
Например, сделать так, чтобы босс подумал о фотографиях раньше, когда ставили эту задачу. Наверное, могли, но это было бы немного за рамками нашей ответственности. Получается, с одной стороны, проект не успешен, потому что была проблема со сроком и скоупом со стороны заказчика. А с другой — у нас все четко, мы молодцы и заказчик доволен.
Этот кейс — хорошая иллюстрация, как в проекте что-то может неожиданно посыпаться. Менеджер здесь вряд ли мог радикально повлиять на ситуацию, но это не значит, что вообще ничего делать не надо.
Расскажу еще один случай, а потом посмотрим, как действовать РМ’у, если проект рискует стать ущербным.
Беспилотный полет
В компании возник проект разработки мобильного приложения с темой real estate в Америке. Собрали несколько девелоперов и тимлида, дали список задач и 4 месяца на выполнение, а затем предоставили людям полный карт-бланш. Дополнительно сеньором поставили PHP, чтобы он был лидом и подсказывал разработчикам на React Native. Команде выдали «документ» на две страницы, с описанием проекта условно на тысячу часов, а вот менеджера не дали. Были получены требования, пусть не подробные и не декомпозированные, и работа началась.
В первых 5 недель число макетов, которые сделал клиент в соответствии с «документом», увеличилось в два раза. Некоторые поменялись, а команде об этом никто не сообщил и работа шла в непонятном направлении.
Итак, проект активно развивается, количество макетов растет как на дрожжах, и команда начинает ходить по кругу. Спустя месяц после начала разработки собственник понимает, что все идет как-то не так, поэтому зовет РМ’а и говорит: «Слушай, включись в проект и посмотри, что можно сделать». Какие действия может предпринять РМ в такой дурацкой ситуации, когда работа по проекту ведется месяц, но не известно, что люди делают, насколько продвинулись и когда это закончится?
Здесь нет времени создавать сложную систему требований, потому что проблемы уже происходят. Главный вопрос, который возникает в этой неразберихе: «Что конкретно нужно сделать, чтобы сдать проект?»
Создаем требования и оцениваем проект
Чтобы стабилизировать ситуацию, нужно понять задачи, оценить, запланировать. Это обычная процедура проджект-менеджмента. Тогда мы постепенно будем двигаться в нужном направлении, к окончанию проекта.
Список задач
В первую очередь надо понять требования и сформировать бэклог. Как минимум написать заголовки задач списком, потому что, если мы не знаем о существовании задачи, сложно ориентироваться, что осталось сделать. Как только появились списки, можно попробовать посчитать, сколько усилий надо, чтобы сдать проект.
На этом этапе важно равномерно и полно рассмотреть объем работы, например, с помощью практики story mapping и сбора технических требований. Технические ревью story maps и валидация с заказчиком помогут выявить нужное и убрать лишнее. Так вы найдете все задачи и не допустите провальных недосмотров в скоупе проекта.
Оценка
Команда, которая месяц работала на самообеспечении, с оценками не заморачивалась, что, в общем-то, логично: оценивать — это не делать. А так как делать все равно придется, надо просто раньше начать, тогда удастся быстрее все закончить, вот и вся логика.
Как РМ’у мне хотелось найти ответ на вопрос: «Что придется делать и как долго?» Но по «рабочему документу», в котором в одну строку помещалась куча фичей, сориентироваться было тяжело. Подробные оценки в такой ситуации считать долго и дорого, поэтому нужно хотя бы равномерно оценить то, что видим. Лучше приблизительно, чем вообще никак.
Идеально, когда у нас есть оценки даже по самым маленьким задачам, еще лучше, когда эти цифры точны и осмыслены. Но на самом деле такой скрупулезный подход нужен не всегда. На практике задачи в первом приближении можно оценить по укрупненным показателям с точностью от −25% до +50%. Задачи высокого уровня попробуйте измерить в человеко-днях. Уже чуть позже, по мере уточнения бэклога, можно будет и оценку поменять.
Качество
Как только мы получили требования, задачи и оценки, надо понять: а что вообще с качеством? Если оно не обеспечено, значит, будут баги и на них уйдет время, как и на техдолг.
Надо сказать, что четыре не очень опытных специалиста во главе с PHP сеньором на React Native почему-то создают огромное количество архитектурных ошибок и технического долга. Хотя поверить, что проекту месяц, а там уже есть техдолг, достаточно сложно, но именно так и было.
Качество — отдельная тема, и говорить о нем можно долго. Здесь выделю самое главное. Это ясное понимание, что такое баг и сколько их может быть в продукте, реестр всех багов приложения. И обязательно нужны процедуры тестирования по ходу работ и во время релиза, когда только QA решает, можно ли двигаться дальше.
Сдаем поэтапно
Когда стало понятно, сколько усилий понадобится, чтобы проект сдать, пора задаться вопросом: «Когда будем сдавать?» У нас может быть разная область видимости: например, видим только на
После стабилизации объема работы, понимания стоимости и сроков следующий шаг — разобраться с релизом. Надо выяснить, когда мы будем готовы релизить, что именно и в какой срок нужно. Дальше посмотрим, как зарелизиться вовремя, а не тогда, когда уже «не надо».
Опоздали с релизом
Есть несколько ситуаций, из-за которых можно сильно задержаться с релизом.
Не знали, что надо, а узнавали только в процессе работы.
Распустили команду. Такое бывает: что-то приостановилось, очередной платеж не прошел — и 10 человек команды рассредоточились по компании. Прошло три недели, деньги зашли, но люди вернулись не все. Обычно из прошлого состава остаются
Ошиблись в оценках. Например, сделали непроверенные предположения. Или оценки неустойчивые, меняются в процессе работы. Сначала было 500 часов, потом они превратились в 1000, а перед спринтом еще больше расползлись. Когда в контракте фиксированное количество часов, будет трудно изменять оценки, соответственно и риск опоздать повышается. Если же вы заранее оставили возможность уточнений по мере движения и ваш проект такое предполагает, наверное, сильно вы не опоздаете, потому что сможете сдвигать сроки.
Многократно переделывали. «Отличный» способ задержаться — делать много изменений, особенно глубоко в архитектуре. Например, уже три месяца создаете интернет-магазин, и вдруг клиент вспоминает, что ему нужны 5 валют, а это изменение на уровне архитектуры.
Не общались. Можно не разговаривать с заказчиком, не делать демо, не получать фидбэк и таким образом не валидировать свою работу. Естественно, в какой-то момент окажется, что мы долго делали не то, а теперь надо переделывать.
Не занимались бизнесом. Если бизнес не решает свои проблемы, проекты часто застревают.
Проиллюстрирую, почему так важны вопросы бизнеса. Клиент запускает блокчейн-проект, и нужно решить несколько задач:
- согласовать юридические вопросы легальности;
- договориться с платежными системами, чтобы они пропускали его деньги, потому что это блокчейн;
- решить ряд бизнес-задач.
Если заказчик не занялся этим своевременно, то, в конце концов, ничего не получится, потому что не решены вещи, которые дадут возможность заниматься бизнесом. У меня была серия проектов, спущенных на тормозах именно по таким причинам: сначала делали, потом оказалось, что бизнес не готов, проект «убрали на полку», он лежит там годами и никто к нему не возвращается. К сожалению, такое бывает.
Вот два примера проектов, которые «положили на полку».
Финтех и депозитные банки
Делали проект «Сберегательный брокер» — сервис, который автоматически оформляет вклады в банк. Прекрасная бизнес-возможность зарабатывать миллионы. Вкладчики имеют увеличенные ставки, а бизнес получает деньги от посреднических услуг, автоматизации и оформления заявок. На проекте понимали, что понадобится интеграция с банком и проверка спецслужб по работе с персональными данными, паспортами, договорами. Но банки и спецслужбы хитрые, пока не начнут что-то делать, не узнаешь, что у них на уме. Поэтому все долго подготавливали и еще дольше внедряли.
В итоге приблизительно в одну неделю с релизом банк-партнер обанкротился, директор оказался под уголовным преследованием — и бизнес-возможность закончилась. Полгода работы команды превратились в 15 GB архива на сервере, а восхитительное технологическое решение легло в бэкап. Мы создали качественный проект, закрыли вопросы с проверками и фискальными органами. Решили все, но делали это настолько долго, что бизнес-возможность ушла. Продукт был невероятно хорош, но недолго.
Импортное образование
Еще одна отличная бизнес-возможность, на которой можно было заработать деньги. Клиент отправлял людей на учебу в США, а потом помогал с дальнейшей иммиграцией.
Заказчик хотел получить сайт с описанием образовательных услуг. Начали делать продукт: создали классный UX-дизайн, все красиво. А потом оказалось, что клиент привык писать только длинные тексты в Word. И делать правильный лендинг или описывать услуги ему было непривычно, поэтому над каждой единицей контента трудился очень долго. При этом его заранее предупреждали, что нужен контент, и настойчиво спрашивали каждую неделю: «А вы что-то написали? Дайте тестовый материал, мы разместим».
Через пару месяцев после изначальной плановой даты релиза случилось неладное. Пока мы готовились, американское правительство закрыло программу по предоставлению учебных виз — и оформить людей на обучение в американском вузе стало проблематично. Проект остановился на три года.
Был тестовый сайт, туда кто-то имел доступ, люди приходили и уходили, пытались наполнять страницы. В итоге через три года получился продукт, нужный заказчику.
Итог: нет виз — нет импорта, и бизнес стал не нужен. Главным тормозом оказалась запоздало идентифицированная проблема контента. Здесь тоже возникает резонный вопрос: «А мы вообще справились или нет?»
Мы могли сделать идеально все, что нужно для управления проектом:
- понять и записать задачи;
- сделать оценки, планы, иерархическую структуру работ;
- организовать процессы определения требований к качеству и процессы контроля;
- создать действительно удобный интерфейс;
- вовремя сдать работу.
И все равно ничего бы не получилось, потому что бизнес был не готов. Это пример, как важно следить не только за своими внутренними делами, но и за тем, что происходит «с той стороны», особенно если события несут в себе фатальные риски для проекта.
Рынок не стоит на месте, поэтому нужно делать не только качественно, но и быстро. Трудность в том, что работать часто приходится с нечеткими требованиями либо они все время меняются. Возможно ли при этом сделать хорошо?
Как работать с размытыми требованиями
Существуют проекты, в которых непонятно до конца, что же надо сделать, потому что задачи постоянно меняются. Где-то требования не сформулированы с самого начала, где-то хотели одно, а потом передумали. Во всех таких случаях размытые требования. И здесь было бы неплохо получить какие-то направляющие, по которым вести проект.
Что поможет навести резкость и увидеть направление?
Общая система требований на проекте. Самый простой вариант — составить User Stories с эпиками. Если к ним дописать Acceptance Criteria, получатся хорошие функциональные требования. Можно создать спецификации, сделать BPMN-диаграмму для бизнес-процессов либо выстроить User Flow.
Главная цель — покрыть требованиями все этапы работ. Необязательно, чтобы это был талмуд на 300 страниц, но важно проработать весь обозримый ход проекта. Если на каких-то этапах вместо требований большие пробелы, вряд ли вы будете знать, когда эта стадия закончится и какие для этого потребуются усилия.
Demo/Review/Feedback sessions. Для контроля проекта применяют стандартные практики демонстрации, когда клиенту показывают сделанное, а он дает обратную связь. Либо проводят сессии фидбэков для группы лиц. Самый надежный способ убедиться, что мы идем вперед, — поговорить с живыми людьми, показать, что происходит и как идет работа.
Планирование изменений. Нужно понимать, что на проекте всегда будут изменения. И если мы знаем об этом, то планируем время, когда можно что-то менять. Ведь нам не нужны изменения, которые происходят перманентно по ходу проекта: взяли задачу на спринт, а она раз и превратилась в другую. Или изменения прилетели в конце работ, когда уже трудно что-то переделывать.
В идеале на смене этапов надо переопределять составы работ и вносить изменения. Тут же будет удобно перепланировать и переоценить. Но даже если на проекте каждую неделю все меняется и по каким-то причинам проекту так надо, можно просто формировать требования на неделю-две вперёд. Тогда нам и менять нечего.
Изменения приносят больше проблем, если мы их не ждем и при этом спешим следовать какому-то плану. Тогда можем споткнуться от какой-то нововыдуманной киллер-фичи. Все архитектурные решения принимайте с оглядкой на известную перспективу развития проекта, того, как его будут использовать и зачем. Иначе можно зарелизить точно в срок, но абсолютно ненужное. Или заказчик вовсе откажется платить.
С релизом и без оплаты
Бывает, мы работали, работали, а потом возник конфликт или клиент просто отказался за что-то оплатить. Поэтому хочу рассказать, как не остаться с релизом и без денег. Думаю, будет полезно узнать, почему люди попадают в такие ситуации.
При попытке сдать работу, отчитаться, получить очередной финансовый транш можно столкнуться с:
- Уклонением — человек уходит от прямых ответов и согласования.
- Затягиванием — заказчик искусственно замедляет работу.
- Манипуляциями — умышленное искажение информации, запутывание.
- Некомпетентностью — клиент просто не понимает, чем вы занимаетесь, и не хочет платить «неизвестно за что».
- Другими целями — собственные мотивы, которые не пересекаются с целями проекта. Например, менеджер со стороны заказчика решает вопросы позиционирования себя в компании. Просит выполнить несколько задач, которые компания затем не будет оплачивать.
- Саботажем — клиент просто саботирует проект. Бывает так, что менеджер со стороны заказчика вообще не заинтересован сдать проект, потому что ему назначили ежемесячную зарплату. Человеку было выгодно работать как можно дольше и он всеми средствами затягивал процесс.
Некоторые клиенты хотят минимизировать бюджеты, поэтому ко всему придираются и наседают, рассчитывая, что РМ почувствует себя виноватым, а заказчик сможет заплатить меньше.
Дальше расскажу о ситуациях, которые случились со мной и несколькими знакомыми проектными менеджерами. Давайте посмотрим, как это может выглядеть изнутри.
Накопительный долг
Самый болезненный кейс, который у меня был — накопительный долг плюс неконструктивные претензии. В итоге клиент отказался от обязательства с вопросом: «А почему так дорого?»
Как это получилось. Был отличный клиент, мы активно работали несколько месяцев, пилили проект, выпускали — все шло хорошо. В какой-то момент он говорит: «Вы все отлично делаете, поэтому отчеты больше присылать не нужно. В начале каждого месяца будете говорить мне сумму к оплате — этого достаточно».
Параллельно начались какие-то проблемы с оплатой: не доплатили 30% суммы, сдвинули платеж на неделю и тому подобное. Накопился финансовый долг более чем за полтора месяца работы. В этот момент появляется некий Джимми, и заказчик говорит: «Это Джимми, он проведет аудит проекта». Дальше Джимми начинает задавать вопросы: «Где отчеты? Чем вы занимались последние полгода?»
А у меня отчетов много, но все они на русском языке, а Джимми — англоязычный. Поэтому он просит перевести. Затем происходит абсолютно необъективная попытка разобраться в проекте и генерация бесконечного количества непонятных претензий, с которыми неизвестно, что делать.
Игнорировать происходящее нельзя, ведь позже может прийти заказчик и сказать: «Вот мой эксперт, которому я доверяю. Он говорит, что вы все делаете плохо, поэтому я платить не буду».
У меня было три подобных кейса, и только один удалось отстоять, правильно среагировав сразу. Поэтому, если в проекте вы видите, что накопительный долг растет и появляется список неконструктивных претензий, не спешите удивляться. Это может быть начало очень эффективной комбинации, в результате которой наступит отказ от финансовых обязательств.
Поэтому по всем вопросам заказчика, какими бы странными они не были, пишите максимально конструктивные и правильные ответы, чтобы потом любой эксперт — специалист в вашей области — согласился с этим. Это единственный путь, чтобы попытаться доказать, что все не так плохо.
Уклонение от фиксации соглашений
У меня был клиент, с которым мы работали быстро и эффективно. Однако все ключевые команды он говорил по телефону, несмотря на Skype, почту и длинный процесс согласования и правок в переписке. Когда, в конце концов, мы приходили к согласию, заказчик просто звонил и говорил: «Все хорошо, делаем дальше».
Получается, можно было согласовать дополнительные фичи и выставить ценник, но фокус в том, что не было фиксации, относительно чего заявлены изменения. Заказчик методично и тщательно всячески избегал такой ответственности.
Подобные ситуации заканчиваются тем, что клиент понимает, что именно ему надо. Затем приходит к РМ’у с окончательным запросом, который не совпадает с тем, что устно утвердили раньше. Начинается борьба, споры, вымогательство. Последний митинг по такому поводу занял у меня 4 часа, из которых 3,5 мы боролись за формулировки.
Самое противное, что пока РМ занимается спорами, он не может уделять время проекту, тратит усилия непонятно на что и не приносит денег компании.
Чтобы этого избежать, просто не допускайте ситуаций, когда заказчик уклоняется от фиксирования решений.
Запутывание источников коммуникации
Как это получается. Условный заказчик Миша — сформировавшийся специалист в своей сфере, занимается бизнесом, у него работает около 50 людей. И Миша делает вид, что он такой безалаберный: сначала пишет в Skype, а в другой раз — в Telegram или на почту. Одни и те же вопросы дублированы или размазаны деталями по всем источникам коммуникации.
Возможно, Миша реально такой неорганизованный, тогда его нужно попросить вести коммуникацию в одном канале. Если просьбы не действуют, просто копируйте все в один канал — пусть он апрувит.
Либо же Миша намеренно запутывает источники информации, позже может возникнуть следующий диалог:
— Ребята, — говорит Миша. — Я же четыре месяца назад просил переделать авторизацию с email на телефон. Почему этого до сих пор нет?
РМ отвечает:
— Я об этом не знал.
Коммуникация по задаче движется дальше, Миша возмущается, а РМ чувствует себя виноватым. Затем РМ идет к разработчикам и вежливо спрашивает:
— А переделать авторизацию — это сложно?
Разработчик отвечает:
— Вообще-то да. Нам надо около двух недель, чтобы это сделать.
РМ сообщает заказчику:
— Надо согласовать две недели работы команды.
А заказчик в ответ:
— Дружище, я четыре месяца жду от тебя эту правку!
И тут как-то говорить о деньгах, об оплате становится совсем неудобно.
Фича «в нагрузку»
Бывает, что вы с клиентом долго разговариваете, почти заключили контракт, человек уже готов оплачивать, ждет счет. И вот заказчик сидит у вас в переговорке и говорит: «Я готов этот проект стартовать, только давайте вот эту штучку вы сделаете „for free“, можете же бесплатно?»
И с одной стороны — переговоры, контракт, деньги и столько усилий уже приложили, но с другой — далеко не факт, что небольшая бесплатная штучка не превратится позже в большую проблему.
Поэтому самый правильный вариант в такой ситуации — это сказать: «Хорошо, мы посчитаем стоимость, исправим документы и передадим вам. Подпишете, а потом вышлите нам копии». Дальше люди обычно просто подписывают и оплачивают.
Как не остаться без оплаты
Когда вы знаете, к чему ведет определенный паттерн поведения заказчика, это поможет предвосхитить грабли и своевременно включиться в борьбу. Чаще всего, понимая ситуацию, РМ может такие вещи предотвратить.
Как не создавать прецедента?
Соблюдайте последовательность в работе с первичными документами: есть договор, выставлен счет, оплачен, есть акт, он подписан. И снова все сначала. Работа поделена на небольшие кусочки, и мы ее делаем отдельными этапами шаг за шагом.
Избегайте «больших мамонтов»: если в контракте написано 30 тысяч часов работы специалистов, возможно, завтра эта цифра превратится в 60 тысяч, а послезавтра — в 120 часов. Даже на проекте в 500 часов лишние 200 — это проблемы по бюджету и срокам.
Старайтесь работать поэтапно, даже если процесс строится по канбану с бесконечным потоком задач, пусть ваш этап будет в один месяц. Намного проще выполнить шесть спринтов или итераций по две недели, чем один этап в три месяца.
Контролируйте, чтобы все оплаты, акты, отчеты и сертификаты были подписаны и переданы либо чтобы было получено подтверждение. Так РМ знает, какая часть работы принята. Если появляется хаос, что-то не подписывают, это надо воспринимать как отказ от приемки работы. Потому что в письмах может быть сказано, что все окей, но если подписанного акта нет, значит, работа не принята.
Конечно, часто это не работа PM’а, но беспорядок в этих вопросах может сильно повлиять на проект. Поэтому менеджеру лучше следить за тем, чтобы нужные документы были подписаны и не возникало вопросов по работам.
Избегайте накопительных долгов — не выдавайте слишком много работы без оплаты. Если допускаете долг, пусть он будет небольшим. Тут есть исключение — вопрос на уровне бизнеса, когда руководство компании решило длительное время работать в кредит с конкретным заказчиком.
Сами не берите в долг больше, чем готовы отдать. К примеру, пришел клиент и говорит, что хочет заплатить сразу на полгода вперед, пока у него есть деньги. Если согласиться, позже это время придется возвращать. При этом совершенно не факт, что через два месяца вы вообще будете готовы работать по этому проекту. И не факт, что финансовые ресурсы компании позволят вернуть такие деньги.
Итог
Релиз — главное событие в жизненном цикле продукта. Приготовления к нему занимают много усилий и времени. Цель — в нужные сроки выпустить то, что ожидает заказчик.
Главный человек, которому нужен проект, — это РМ. Именно он руководит процессом, решает проблемы и следит, чтобы с вашей стороны и со стороны заказчика в итоге все было хорошо.
РМ способен как вытянуть проект, так и погубить его, если не будет готовиться к возможным рискам заранее. В статье я написал о своем опыте, как делать не надо, а в комментариях приглашаю коллег делиться собственными историями.
