Есть такая профессиональная ловушка: выучить PMBOK, обвешаться сертификатами, разобраться в Jira и при этом терять команду проект за проектом. Потому что управление проектами формально про сроки и бюджеты, а по факту про людей.
Переводчик, а не оратор
PM чаще всего занят не презентациями, а переводом. Заказчик говорит «хочу, чтобы было удобно». Разработчик слышит «хочу непонятно чего». Между ними — менеджер, который должен из «удобно» вытащить пользовательские сценарии, не обидев никого.
Это не красноречие. Это эмпатия, помноженная на аналитику. И ещё — привычка фиксировать договорённости письменно после каждой встречи. Банально, но через две недели именно этот файлик спасёт от «мы совсем другое обсуждали».
Про конфликты
Разработчик считает оценку нереалистичной. Аналитик уверен, что требования менялись трижды. Тестировщик молча ставит «критично» на каждый второй баг. Знакомая картина?
Плохой PM давит авторитетом или делает вид, что проблемы нет. Хороший — выясняет, что стоит за позицией. За фразой «невозможно за спринт» часто прячется не лень, а техдолг, о котором менеджер даже не подозревает.
Кстати, если в команде вообще нет разногласий — скорее всего, люди просто молчат.
Решения без полной картины
Полной информации не бывает. Бывают дедлайны, размытые требования и три варианта, каждый компромисс. Ждать идеальной ясности значит не решить ничего.
Навык тут не в безошибочности. А в том, чтобы принять достаточно хорошее решение вовремя и скорректировать курс, когда появятся новые данные.
Про делегирование коротко
«Проще самому написать ТЗ, чем объяснять» — путь к выгоранию.
Делегирование — не слепое доверие, а осознанное. Понимать сильные стороны людей, давать задачи по уровню. И самое болезненное — не переделывать результат, если он достаточно хорош, просто потому что вы бы написали иначе.
Как это прокачать? Только практикой. Собирать обратную связь от команды. Разбирать сложные ситуации. И периодически задавать себе вопрос: «Мне было бы комфортно работать с таким PM, как я?»