На пути к «Великану» |

Эта статья будет полезна ПМам, в проектах которых царит беспорядок. Ты можешь и не заметить этого беспорядка. Тогда остановись и подумай, не про тебя ли это:

Хочешь усугубить ситуацию или вообще все порушить?

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

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

Не думай о KPI проекта и стратегии их достижения. Не планируй свой день и задачи по степени важности. Не нужно рассчитывать, сколько времени и на какие задачи ты потратишь. Зачем? Ведь на планирование и фокус тоже нужно тратить время. Лучше ориентироваться по ситуации, заниматься непонятно чем до 9–10 вечера. Через месяц такой работы растеряешь все силы и выгоришь.

Вот что говорится про такое заболевание у ПМа в книге “Вальсируя с медведями” по управлению рисков в проекте:

Это ограничение может развить в вас склонность к инфекционному заболеванию, называемому избирательная близорукость.

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

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

2. Не вовлекай заказчика в проект
Ударно работайте всей командой и результаты принимайте сами же, внутри команды, не нужно беспокоить заказчика. Ну ты же попробовал пару раз написать ему в слаке и даже позвонил. Времени у заказчика нет. Ничего, пусть команда сама решает то ли вы сделали, что от вас хотели. Пусть лучше за 2 дня перед дэдлайном заказчик проверит все и вернет вам на доработку 90% работы. Овертаймы и недосыпы — это ведь замечательно.

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

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

4. Не контролируй качество продукта
Сконцентрируйся на скорости выполнения задач, не проверяй ничего сам, не проси об этом тимлида. Нужно доверять исполнителю. Отдел QA, тесты? Это все для слабаков. Ну и что, что у нас просачиваются баги на прод, там и пофиксим. Просто жди, когда ваши пользователи сами начнут писать о проблемах, а заказчик уже будет не в состоянии терпеть это.

5. Трать на планирование как можно меньше времени, а лучше вообще обойтись без него
Просто умножай сроки, которые тебе дает исполнитель на 2. А если ты опытный ПМ, то на 3. Зачем дробить задачи, вчитываться в суть и узнавать недостающие детали у заказчика. Это бред.

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

Вчерашняя проблема — это сегодняшний риск. Именно так, а не «Сегодняшний риск — это завтрашняя проблема».

Управление рисками и опасения за свой проект — это не одно и то же.

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

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

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

Конфликтуйте, наличие конфликтов показывает “взрослость” команды. Правда, до определенного момента. Если переборщить, можно легко убить желание работать друг с другом.

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

10. Соглашайтесь на все доработки заказчика
Заказчика нельзя расстраивать, поэтому, если в середине спринта заказчик решил, что надо впихнуть 10 новых задач, надо это сделать и уверить его, что все будет сделано в лучшем виде. Зачем советоваться с командой, замещать задачи. Лучше обмануть клиента и все будут счастливы, пока не нагрянет Демо выполненных задач в спринте.

У тебя всегда будет время сдаться, все бросить, попробовать что то другое. А как насчет попробовать взять себя в руки и все исправить?

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

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

И главное — постоянство. Когда начнешь решать проблемы самым тяжелым будет не забить на полпути. (Сюрприз: для выработки привычки тоже существует много техник.)

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

Удачи, а еще терпения и придерживайся распорядка дня (об эффективном распорядке в следующей статье).