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

Несколько слов о том, как поступать не следует.

Первая ошибка — чувствовать, что вы достойны большей зарплаты, но молча терпеть и не предпринимать никаких действий. Руководитель не телепат, он очень занят и почувствовать ваши страдания не может. Люди так терпят неделю, месяц, год, а потом в разгорячённом состоянии предъявляют руководству претензии. Договориться таким образом никак невозможно, потому что переговоры о повышении — это бизнес-переговоры, об этом ниже.

Вторая ошибка — при входе в компанию допустить договорённость вида: «Ты сначала поработай, а потом мы посмотрим» или: «Для начала будет вот такая сумма, а потом определимся». Никто ничего не посмотрит и ни в чём не определится. Обязательно и сразу нужно договариваться, когда конкретно наступит потом и на основании каких критериев (лучше задать их в виде конкретных цифр) будем определяться.

Третью ошибку допускают, в основном, менеджеры по продажам и другие переговорщики. Они своими методами прогибают компанию так, что она начинает им платить сильно больше, чем они на самом деле стоят. Ну, руководитель может поддаться на профессионально организованное давление и повысить, а потом у него перестанут сходиться бюджеты и он вас просто уволит, так как понижать зарплату в СНГ не принято.

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

Как действовать не надо, разобрали. Теперь как надо.

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

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

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

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

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

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

Болтолог

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

Раскусывается легко. Спросите на собеседовании: «А что конкретно вы сделали для достижения этих результатов?». Он ответит: «Ну как же, я руководил, куча сотрудников мне подчинялась». А вы ещё раз спросите: «А можете перечислить конкретные управленческие манипуляции, которые вы производили?» Тут болтолог начнёт нервничать и придумывать, что сразу станет заметно. 

Теоретик

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

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

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

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

Псевдоспециалист

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

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

Летун

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

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

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

Токсик

Модное слово. Под токсиком я понимаю человека, у которого есть внутренняя обида на всё человечество и желание ему нагадить. И так как такому сотруднику нужно как-то жить и в общество интегрироваться, он учится улыбаться, грамотно отвечать на вопросы и всячески изображать дружелюбие. Я имел опыт взаимодействия с таким сотрудником и могу сказать, что день, когда он таки написал по собственному, стал праздником для компании. 

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

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

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

⛔️ Неправильно: Нужно принести, пожалуйста, в жертву козла, а затем прыгнуть в портал. Сергей, сделаешь?!
✅ Правильно: Сергей! <пауза для пробуждения Сергея> Принеси, пожалуйста, в жертву козла и прыгни в портал. 

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

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

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

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

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

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

Вот ещё цитата из книги «Чистый Agile» Роберта Мартина:

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

Также должен сказать, что существует четыре вида задач:

• Атомарная задача
• Агрегационная задача
• Веха
• Гамак

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

Вот четыре задачи, связанные End-to-Start, в рамках которых проводятся некие работы:

А теперь представьте, что существует работа, которая должна проводиться всё время, пока проводятся задачи 2 и 3. Например, если в рамках этих задач проводятся работы по проведению публичного мероприятия, нам нужно дополнительной задачей обеспечить охрану и эта охрана должна работать ровно столько, сколько продолжаются мероприятия. Эту работу обязательно нужно включить в план, так как она требует трудовых ресурсов (время охранников).

Это делается так:

Задача 2 соединяется с задачей-гамаком связью Start-to-Start, задача 3 — связью End-to-End. Главное — не забудьте стереть у задачи-гамака оценку, иначе она будет отображаться неправильно.

Вот для таких случаев разработчики прожектовского софта и запасли для нас экзотические типы связей. Для скриншотов использовал Merlin Project.

«Эксперт — это человек, который совершил все возможные ошибки в очень узкой специальности.»

—  Нильс Хенрик Давид Бор

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

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

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

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

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

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

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

И напоследок бонус. Чтобы определить базовые приоритеты заказчика, можете ему подсунуть на заполнение вот такую простенькую табличку:

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

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

Дело в том, что логирование времени исполнителями — это нормально. Рядовой разработчик касается в день, максимум, трёх задач. Тестировщик тоже. У дизайнера тоже плюс-минус фиксированное количество задач и честное логирование времени не представляется проблемой, будь то ведение табличек в экселе или трёхкратное нажатие кнопочки в джире.

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

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

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

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

— Sergey Voskoboynikov (@voskoboynikov) November 11, 2022

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

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

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

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

Эта статья может быть полезна начинающим PM-ам.

Снизу вверх

Я применяю этот метод чаще других. Он сводится к тому, что ТЗ декомпозируется до атомарных (или не очень атомарных, но относительно мелких) задач и каждая из этих задач оценивается. Затем оценки суммируются и мы получаем достаточно точную калькуляцию.

Недостатки метода в том, что он не работает, когда нет чёткого ТЗ и в том, что он относительно медленный.

Сверху вниз

Этот метод мной применяется чуть реже. Он работает, когда бюджет уже известен. Заказчик, к примеру, готов выделить на проект от 2 до 2,5 миллионов рублей и не более полугода срока. И тут уже исходя из этой суммы нужно определить доли, сколько каким специалистам уйдёт и какие работы мы в рамках данного бюжета можем сделать.

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

Оценка по аналогам

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

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

Параметрическая оценка

Усложнённый вариант оценки по аналогам. Например, если мы говорим о вёрстке, вы можете по опыту предыдущих проектов понять, что, например, блок обратной связи ваш верстальщик делает за 3 часа, а классический слайдер с кружочками и стрелками по бокам — за 4 часа. Таким образом, можно рассчитать стоимость достаточно быстро и точнее, чем при оценке по аналогам.

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

Анализ предложений

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

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

Экспертная оценка

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

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

Подавляющее большинство проектов проваливается. Понять, что данный проект провалится, не очень сложно. Есть несколько маячков.

Дедлайн спущен сверху

В практике постоянно натыкаюсь на ситуации, когда высокое начальство поговорило и решило, что срок 15 октября этого года. Или 2 ноября. Или 28 декабря. Как оно это посчитало — непонятно, потому что никаких планов нет даже близко, ещё даже не вполне понятен набор фич продукта.

Иногда дата, действительно, оправдана. Например, с 15 октября меняется форма отчёта, а продукт как раз и делается, чтобы генерить отчёты по новой форме. После 15 октября делать отчёты по старой форме бессмысленно.

Чаще же она привязывается к старту какой-нибудь маркетинговой активности или ещё какой-нибудь ереси из мира высокого начальства. У РМ-а же, как правило, возможности отказаться делать проект к данной дате нет и приходится выкручиваться.

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

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

Планируют и реализуют разные люди или даже подразделения

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

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

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

Руководитель проекта недостаточно квалифицирован или мотивирован

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

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

С недостаточной квалификацией всё ещё прозрачней. Джуну РМ-у лучше ограничиться лендингами за 3000 руб. или простенькими интернет-магазинами и копить опыт. Если действовать по принципу отца, сбрасывающего сына с лодки, всегда есть риск провала. Ну, или того, что сын научится писать и напишет на незадачливого отца заявление в милицию.

Не определились с особенностями реализации проекта

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

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

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

Не определены специфические критерии успешности проекта

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

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

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