Прожект-менеджмент, какие бывают проблемы

12 комментариев
Прожект-менеджмент, какие бывают проблемы
Здесь довольно часто обсуждается как в постах, так и в комментариях к компаниям отношения между разработчиком и топ-менеджментом, или если по-нашему, по –простому, с директором. Проблемы с увольнениями, пересчёты зарплаты и прочие не самые приятные вещи. Однако это уже обычно крайние случаи, когда конфронтация неизбежна и результатом боевых действий будут лишь испорченные нервы и трудовая книжка, а заодно и репутация обоих сторон. Гораздо чаще встречаются скрытые конфликтные ситуации, которые возникают в узком кругу команды, занимающейся конкретным проектом под начальством прожект-менеджера. Мне абсолютно неинтересно кого-то там обвинять или учить, просто хотелось поделиться некоторыми достаточно распространёнными случаями, а заодно может обсудить в комментариях подобные проблемы, поделиться опытом, чтобы их избегать. Прожект-менеджер это посредник между заказчиком и непосредственно самими девелоперами, который отвечает за организацию разработки и общую коммуникацию с клиентом. Итак, случай первый – небольшой проект у постоянного заказчика или же какая-то его отдельная часть, которая по планам разработки предусматривает загруженность только пары человек, ну максимум трёх. Заказчик, который как обычно хочет по максимуму сэкономить денег (а иначе, почему он вообще обращается к аутсорсерам, а не набирает себе толковых и дорогих спецов на родине), не очень хочет понимать, зачем ему платить за часы работы пиэма, который будет управлять буквально парой человек. Действительно, неужели они, два таких по утверждению компании классных спеца, между собой не договорятся? Наши компании со всех их опытом, в стремлении не упускать клиента зачастую идут навстречу клиенту и оставляют разработку на девелоперов, а пиэм на проекте существует максимум в формате куратора, который, по сути, только форвардит письма и претензии заказчика. В результате, чаще всего даже у хороших девелоперов такой проект идет, мягко говоря, не очень хорошо, а зачастую и просто валится. Заказчик, как обычно хочет всего и сразу и особенно от своих аутсорсинговых парней. Защищать их интересы особо некому, а прожект-менеджер, который в принципе не разбирается в чём корень самой проблемы, если клиент что-то требует, начинает тупо давить на программистов, неважно при этом насколько реальны и обоснованы требования заказчика. Ребята на проекте, если всё идёт нормально от пиэма не слышат ни слова, но если клиенту что-то взбредёт в голову, получают форвард его гневных глупых писем с добавкой "Что за фигня? Разберитесь, иначе останетесь без премии, и вообще вы там все охренели, бездельники ". Даже если засиживая на работе допоздна, девелоперы вытаскивают проект, в результате остаются недовольны все - и программисты, и куратор-менеджер, и заказчик. Атмосфера в команде никакущая, клиент подумывает об отказе от дальнейшего сотрудничества. Второй случай. Идёт разработка на проекте – получился какой-то косяк, по вине собственно команды, или кого-нибудь одного из программистов. Заказчик сильно недоволен и устраивает выволочку прожект-менеджеру, костеря его всеми возможными способами. Что делает нормальный менеджер и хороший человек? Нет, он не идёт и устраивает всем разнос и в свою очередь рассказывает всем, какие они идиоты и что должны теперь работать бесплатно круглыми сутками, чтобы вытянуть проект. Он пытается сгладить ситуацию, чтобы не портить атмосферу в команде, указать на ошибки и попытается как-нибудь договориться по-хорошему, чтобы программисты, поняв сложность ситуации, сами были настроены её исправить. Ну а что делают многие девелоперы в такой ситуации? Они банально отказываются что-то делать заново или сверху, возмущаются тем, что вообще их тут эксплуатируют и раз пиэм не может всё нормально сделать, за что он вообще деньги получает? Да без него только лучше было бы. И не важно, что при этом такому кодеру вчера было лениво, а сегодня нужно уйти пораньше, а код писать некогда, это ж не он отвечает за проект. В таких случаях даже жалко прожект-менеджера, который сталкивается с подобными, откровенно говоря "зажравшимися" программистами. Ещё вариант, глупый, конечно, но, тем не менее, и он встречается, причём нередко. Сложно представить, но иногда случайным образом выясняется, что кто-нибудь из программистов или тестеров, месяц или даже два, вообще ничего не делал. То есть он, конечно, делал, рылся время от времени в коде, что-то заливал на продакшн, что-то апдейтил. Но вот в результате получен ноль. Половина задач банально даже не реализована, а вторая половина сделана наспех за пару дней, и в принципе работать не может. Конечно, на крупных проектах такое сложно встретить или на срочных, но на мелких, а уж особенно внутренних, такое довольно часто бывает. Виноваты тут, конечно, оба, во-первых, лентяй девелопер, который в условиях перегретого рынка (по крайней мере до последнего времени, знал, что в крайнем случае он работу себе всегда найдёт), а во-вторых, прожект-менеджер, который не пытался вникнуть в проект, а лишь проверял отчётность и заполнение мсп. Тут можно долго рассуждать приводить ещё примеры, но вообще с моей точки зрения причина возникновения большинства проблем – это то, что на прожект-менеджменте часто любят сэкономить, а без него просто нельзя, какой бы не была сильной команда. А также то, что несмотря на все процессы и ИСО-сертификации, МС прожект и т.д., без погружения прожект-менеджера в проект, в котором он должен разбираться и каждую фазу понимать, ничего хорошего обычно не выходит.

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

Вакансии для QA-инженеров на jobs.dev.by
Вакансии для QA-инженеров на jobs.dev.by
Вакансии для QA-инженеров на jobs.dev.by
Четверть айтишников готовят отъезд на ПМЖ уже сейчас. 5% не видят необходимости
Четверть айтишников готовят отъезд на ПМЖ уже сейчас. 5% не видят необходимости
Четверть айтишников готовят отъезд на ПМЖ уже сейчас. 5% не видят необходимости
54% белорусских айтишников хотели бы остаться в стране, но уедут, если ситуация ухудшится. 33% планируют отъезд уже сейчас, не дожидаясь развития ситуации: 24% — на ПМЖ, 9% — в длительную командировку. 5% не видят необходимости уезжать, у 4% нет возможности. 2% уже уехали. Таковы результаты опроса dev.by про релокейт. Мы поделили опрос на две части. Сегодня первая часть — о планах самих ИТ-специалистов. Во второй расскажем о релокейт-планах ИТ-компаний.
58 комментариев
ИТ-компании уволили за этот год 5,6+ тысячи человек
ИТ-компании уволили за этот год 5,6+ тысячи человек
ИТ-компании уволили за этот год 5,6+ тысячи человек
Вакансии для Python-разработчиков на jobs.dev.by
Вакансии для Python-разработчиков на jobs.dev.by
Вакансии для Python-разработчиков на jobs.dev.by

Обсуждение

-1

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

Однако много если :).

1

Ну да. Из 10 разработчиков есть шанс, что 1-2 станут сеньерами, или, что ещё лучше, тимлидами. А оставшихся 8-9 всегда можно будет назвать "неудачниками" и "слабаками".

Anonymous
Anonymous Lead Software Engineer в EPAM
0

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

Андрей Степанов
Андрей Степанов Lead PHP developer в EPAM
1

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

Андрей Степанов
Андрей Степанов Lead PHP developer в EPAM
1

ошибся, не второй, а третий

trinya
trinya Project Manager в Softeq Development
1

Работала по первому сценарию, почти год, в качестве девелопера и неформального лидера))
Менеджера конечно не хватало, причем иногда остро (формально он был, где-то на другом этаже, 20% времени из 120%, которые он отрабатывал), но со временем привыкли, каждый чувствовал ответственность за свою работу. И да, мы старались основную часть проблем решать самим и не выносить сор из избы.

И да, было очень обидно, за вот эти самые письма: "у вас все плохо, что за фигня", при всем том, что о проекте менеджер знал не так много.

1

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

1

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

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

Так что, ожидать от опытных программистов, что они так же опытны в борьбе со всякими "вампирами" производительсти - очень недальновидно.

Также опасно, планировать менеджеров парт-тайм. Если на одном направлении случаются проблемы, то на второе просто забивается.

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

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

Сорри за длинный пост (^:

Anonymous
Anonymous
0

Вариант номер два несколько странный. Почему если менеджер хороший человек , то надо молчать об ошибке?
По-моему, нужно грустно и трагично сказать об этой ошибке. Сказать что вот, так получилось, МЫ облажались (в смысле, не я облажался и не Вася, а именно команда). И что нужно эту ошибку исправить, и что он, менеджер, верит, что команда с этим достойно справится... Ну, в таком, примерно, стиле.
А случай когда разработчик отказывается исправлять свою ошибку означает, что кто-то явно совсем не на своем месте. Либо разработчик неадекватный, либо менеджер слабый и неавторитетный.

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

1

Судя по комментариям LIman, Trinya и моему опыту 1-й пункт весьма распространен в Итранзишн :).

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

trinya
trinya Project Manager в Softeq Development
1

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

А "испорченный телефон" всегда плохо, с одной стороны ПМ/БА должен экранировать заказчика от разработчиков, чтобы не мешал работать, а с другой стороны -- нужно доходчиво объяснять что же все-таки надо сделать, что не всегда удается, и разработчики начинают думать "зачем эти дополнительные уровни, давайте я сам с ним поговорю"...

Anonymous
Anonymous
1

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

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже