Ошибки начинающего project-менеджера на личном опыте

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

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

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

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

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

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

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

Третьей проблемой, я бы назвал отсутствие воспитания сотрудников. Я им никак не прививал чувство ответственности за проект, не объяснял цели компании, не объяснял почему мы это делаем и как нужно это делать, почему это важно заказчикам и соответственно компании. Я считал, что это и так всем понятно, конечно, ошибочно. Я придумывал модели поведения всех сотрудников у себя в голове и считал, что они должны их соблюдать, хотя им об этом не говорил. И даже когда они вели себя не по моей модели, я лишь жаловался себе, какие они плохие. Я только считал, что все они неспособные и вообще не такие, как нам нужны, и нужно менять сотрудников, я не видел, что проблема во мне, как в менеджере. Как кто-то сказал, существует лишь 10 процентов сотрудников, которые всегда делают все хорошо. Еще 10 процентов всегда делают плохо. Оставшиеся 80 процентов нужно направлять, и этим я не занимался. И, на самом деле, они просто делали так, как считали правильным. Ведь я им не говорил, что так неправильно. Сорвали сроки? Ну нам же ничего за это не было, значит, это нормально. Задача в десятый раз не проходит тестирование? Наверное, это нормально, мне ведь ничего об этом не сказали. Куча багов после тестирования? Нормально, зарплату ведь не понижают и претензий никаких нет, так зачем стараться? И вправду, зачем? Если разрешают работать плохо и за это платят деньги, так для чего выполнять больше нужного? Со стороны сотрудника выглядит это так, что им разрешается работать плохо и такая работа только поощряется. Ведь отсутствие каких-либо претензий, значит, что так можно и нужно. И мотивации сотрудникам я не давал никакой, таким образом никаких причин делать хорошо у них не было.

Собственно, как говорится в одной хорошей цитате: “Не бывает плохих работников — это плохие начальники не могут сделать так, чтобы все работали хорошо”. И только недавно я это осознал, может эта статья поможет вам осознать это раньше чем мне, не проваливая столько проектов и не срывая столько сроков.
Метки:
управление проектами, управление персоналом

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