6 ошибок управления проектом из личного опыта

1. Считал себя начальником
   Это была одна из первых ошибок. Я решил, что я руководитель. У меня есть власть определять процессы и то, как они должны быть реализованы. Это вызывало напряжение и конфликты с участниками команды. Со временем я понял, что менеджер это наоборот сильно зависимый от команды человек, поэтому его сила в том, чтобы поддерживать со всеми хороший контакт. И в целом - никто никому ничего не должен. Этот подход, по моим ощущениям, помогает и правильно оценивать риски и быть готовым ко всему.

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

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

4. Невнимание к техническим навыкам
   Изначально я был уверен, что для того, чтобы руководить технические знания не нужны. Уж тем более, понимание кода, архитектуры и прочее. Проблемы тут часто в 2 случаях: джуны-разработчики и сеньорные разработчики. По первым вы не можете отследить скорость работ, если вас никто не подстрахует. А даже, если отследите, то они вам навешают лапши на уши, что делали вот то-то и то-то, а это очень много времени занимает. Вторые могут просто не уважать руководителя, который не разбирается в том, что они делают. Эти факторы, а также просто любопытство и интерес побудили интерес к коду. Оказалось, что там всё не так сложно как кажется. Но, конечно, изучение требует времени. Достигнув какого-то уровня можно остановиться и далее уже копать, когда потребуется конкретный навык (SQL, нейронки, информационная безопасность и т. д.).

5. Неумение делегировать
   Поначалу я руководствовался принципом “хочешь сделать хорошо - сделай сам”. К тому же, я думал, ну там немного. Сейчас сам этот документ сделаю и ту схемку оформлю. Но в реальности операционка у менеджера съедает очень много времени. Также есть много отвлекающих факторов: уточнение у аналитика по поставленной задаче, вопрос от заказчика, отчёт для руководителя. Времени делать самому не остаётся.
   Также у меня перед глазами был пример генерального директора, который все процессы замыкал на себе и работал по 80 часов в неделю. Со временем он смог делегировать большинство задач на своих подчиненных. Сейчас у него адекватный work-life баланс. Выручка компании при этом выросла в 2 раза, а процессы не сломались. Так что умение делегировать это одна из ключевых возможностей, которой может пользоваться менеджер. Не стоит ею пренебрегать)

6. Неумение ставить задачи
   Постановка задач это отдельная проблема. Где-то была статья на РБК, что в России более 25% менеджеров не умеют ставить задачи. С цифрой могу ошибаться, но процент был значительный. Я ставил задачи так, что видел непонимание в глазах коллег или делалось не совсем то, что я хотел. Нужно ставить задачи ясно и понятно (кэп). Здесь поможет Максим Ильяхов и его книги. Также помогает любая визуализация - схемы, рисунки. И любую постановку желательно устно проговорить, чтобы создалось впечатление понял человек задачу или нет. А также, чтобы у него была возможность спросить. Так как иногда люди постесняются спрашивать лишний раз. При устном разговоре это сделать проще. В дополнение статья на тему постановки задач