PM-ы, как разруливать конфликтные ситуации?

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

тема скатилась в предметную область наказаний=) вопрос был другой, как выходить из задницы.
тут есть несколько нюансов — если у вас фиксдпрайс проект, то ,беда-беда и гнев заказчика оправдан, все остальные случаи это предмет к переговорам. к примеру можно сказать, что пм чтобы сроки не задирать не накинул риск буфер, в погоне за экономией времени и ресурсов для заказчика, но вышел форс-мажор, а время и ресурсы затраченные на фикс багов будет в любом случае ниже «цены» риск буфера. Ну, а в целом у любой ошибки есть имя, фамилия и адрес=) это я про пм

все есть предмет переговоров

Если хочешь чтобы конфликтные ситуации разруливались в один клик — ошибся профессией. Иди в военные!
Потому что всё, что ещё не война — разруливается дипломатией. И это искусство. Хотя бы по той причине, что конфликты нельзя «разруливать». Их нужно держать под контролем с момента зарождения, и что самое важное — их нужно допускать.

Основная причина практически всех серьёзных конфликтов на этой планете — это запрет конфликтов. И чем сильнее конфликты запрещаются, тем больше гарантия что пороховая бочка взорвётся. Если PM этого не знает, мой совет: объединяться против PMа и выносить эту бездарь из проекта ногами наизнанку.

PS. Если этот PM вы, возьмите три конверта...

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

"Главная проблема это дедлайн"©

www.youtube.com/watch?v=-uGdaKFboHo

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

Я вам могу предоставить универсальный источник конфликта — угроза личной безопасности. Все в конечном итоге сводится именно к ней. И кейс там один. Но, как всегда, дьявол в деталях.

Стратоплан читали? stratoplan.ru Підпишіться на їх розсилку, там багато безкоштовного і корисного. А взагалі в інтернеті купа матеріалів на цю тему а ви чекаєте що вам тут досвічені РМи будуть розписувати свої «кейси».
Крім того, розрулювання конфліктів не є чимось, що трапляється тільки в ІТ а значить що матеріалів в мережі ще більше є.

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

вы немного не с той точки зрения смотрите.

заказчик 100% заинтересован в продукте, работа была проделана, у вас сработал кейс от которого вы не застраховались (не учтенный риск).

вы ничего дополнительно сделать не должны, просто должны быть осторожны с эстимейтами на исправление

что в такой ситуации, кому пошее давать?!

то есть это чистая ошибка PM, что не уследил?

судя по всему чтото не так в процессе, если ошибку репортили, но ее не пофиксили.

Конечно да, ведь это обязанности ПМ, что бы проект был сделан в срок и идеальным. Другой вопрос, что где-то75% проектов все-равно затягиваются. Но если легкий и простой проект, то затягивания быть не должно.

Что теперь делать — получить урок, детальнее разделить на подзадачи и уточнять сроки в следующий раз. И ни в коем случае не давать буфера себе — он осложнит планирование.

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

Но важнее другое — что прописано в контракте? какие условия? что и как?

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

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

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

Но тут позвонил тебе ваш тестировщик и сказал что мол этот баг я находил и зарепортил.
а почему не пофиксили?
Но тут обнаружилась ошибка критическая
надо фиксить
Но тут позвонил тебе ваш тестировщик и сказал что мол этот баг я находил и зарепортил.
Детский сад какой-то, если бы репортал, вы бы увидели. Critical баг или блокер должен быть зарепортан в JIRA и пофикшен и протестирован еще до релиза. Либо QA заднем числом прикрыл себе задницу, но как быть с датой добавления бага?

Блокер или критикал любой QA может определить, да и девелопер тоже. В общем ситуация мне понятна — начались поиски козла отпущения и каждый пытается прикрыть себе зад.

Ну не вопрос, product owner легко меняет low на critical, все в JIRA это видят и фиксят (если это не в пятницу после обеда) или он поменял статус уже на проде ? В любом случае девелоперы тут ни при чем.

Это да к сожалению, потом все равно выставят программиста виноватым или косвенно подосрут потом.

Виноват однозначно прогер, раз допустил баг. Но он лишь исполнитель, а реальный виновки, конечно же ПМ — он не проследил, что бы продукт был идеальным. На то и нужен ПМ, что бы за такими вещами следить. Я бы сказал, что ПМ виноват на 90%. Прогер на 10%. ПМ должен выругать прогера на те самые 10%, а себя на 90%, да так, что бы в следующий раз ПМ не допускал этой ошибки.

Я так же допускаю ошибки, просто виню себя. Мы однажды выпустили проект не работающей кнопкой — мультиплеер в игре не работал вообще. А обнаружили спустя почти месяц после релиза. Кто виноват? куа на 10%, а 90% я. Когда руководство начало насиловать куа — я вступился и сказал, я как менеджер виноват, что не проследил, что бы куа все протестировал. После чего меня насиловали не за то, что есть бок, а за то, что заступился за куа виноватого. До сих пор понять не могу — что не так? Менеджер для того и нужен, что бы следить за всем.

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

Виноватый должен быть наказан, иначе он продолжит быть виноватым
ээээээ?

блин отвлели. Иначе он продолжет так косячить не задумываясь о вреде

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

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

зачем?

Не совсем так. Если про ответртку, то она кривая — либо специально ее погнули, что бы она выполняла другие задачи. Либо же она испорчена и надо чинить.

Если же мы говорим о человеке который допустил ошибку — его надо наказать АДЕКВАТНО. Если человек случайно пропустил баг сказать «ай-яй-яй, Петя, ты же такой классный специалист, и не учел такой пустяк. Все в следующий раз учти. Давай, ты молодец.» — Итог, человек доволен, его похволили, но понял, что он допустил ошибку и может исправиться.
Если же, как у меня — просто отличный прогер был — делает быстро, код отличный, но часто спешит, не проверяет простые вещи и баги лезут по полной. Благо куа выявлял почти все. То его пришлось серьезно пожурить — сразу сроки выполнения работ выросли процентов на 10, но переделок более, практически не было.
Тут задача ПМ — умень наладить диалог. Если не умеешь общаться — Проджект хреновый.

Более того, иногда можно даже слегка обрубить мотивацию сотрудника, но потом это компенсировать другой мотивацией.

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

Ну так куа репортил.
Еще раз прочитайте мой пост — 90% вины на менеджере.

просто дев не факт что в этом виноват.

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

в итоге в реальном использовании бага проявляется у него нет.

за утечками памяти не уследишь, зато есть понятие стресс-тестов.

такая бага не вина дева. его ругать не за что (за исключением если они не происходят на регулярной основе)

Ок, хорошо, согласен. Но опять же вина дева, что что не предположил те самые утечки памяти, и, завершив задачу, не отправил на тест.
Но тут тогда не 10% его вины, а 3%. Но опять же. есть куа. который зарепортил. а дев не пофиксил, кто виноват? менеджер, что не проследил. что бы дев пофиксил. И если мы исходим из того, что куа зарепортил. то вина дева снвоа 10%

И если мы исходим из того, что куа зарепортил. то вина дева снвоа 10%
вот это говорит о 100% вине менеджера (может быть ТЛ).
ибо процесс поломан, а это как раз задача менеджера заставить его работать.

другой момент если разраб чето сделал, и не уверен что все гуд, и молчит как партизан — тогда он реально виноват.

вообще не проекте за все отвественнен ПМ или ТЛ (зависит от организации). соотвественно вина — почти всегда их, но есть исключения.

Верно, только я считаю, что 90% — их, а 10% все же сотрудник сам мог предположить о баге.

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

был у меня случай, заказчик/директор попросил срочно запилить функционал новый (было веб приложение) для показа, время в обрез, я с 9 утра до 3 ночи в течении 4 дней пилил это функционал добавил.

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

мне потом рассказали какой я не хороший человек, подвел его, ибо не пофиксил.

на следующий неделе я пошел на собеседование.

Я вас прекрасно понимаю. Так вот. в этом и задача ПМ, что бы наказать АДЕКВАТНО.
То есть не лишать всей премии, но сделать маленький диалог «типа ты учти в следующий раз». Тут сложно по вам сказать как было лучше, но пм должен был знать. Он должен был проследить, что бы куа протестил. И тут опять ошибка менеджера — 5% вы не знали, 10% куа не протестил, а 85% — менеджер не проследил.

и?
речь о поиске виноватого?
все. вместе. несут. ответственность.
если в ваших процессах под «ответственностью» понимается «в кого кидаем дерьмом» — эффективность будет под вопросом.
если под «ответственностью» понимать «кому будет больше других не пофиг в случае проблемы» — то и результат будет вместо прикрывания задниц.

Первый вопрос, на который надо найти ответ — это как, в принципе, заказчик пришел к такому состоянию ?

Обычно, процентов так в 95% случаев, его до такого состояния довели. И если это так, то поднимайте свою попу с дивана и исправляйте свои косяки. Причем, я сейчас не столько о работе команды, сколько о том, чтобы вы менеджмент врубали на полную
А если он в тех 5% процентов, которые априори неадекватны — то ситуацию надо знать поконкретней, чтобы вам помочь

95% случаев, его до такого состояния довели
из которых 100% вины на менеджере

я бы сказала 99%
был у меня как-то разраб, который тупо печатную форму в 1с дорисовать 3 недели не мог

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

задача менеджера как раз такие проблемы решать, при чем самыми разнообразными методами и инструментами.

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

как бы да
но в фирмах 1С-франчайзи по-другому работают
тут не применяются нормальные практики управления проектами

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

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

потом где-то, какой-то кастомер в истерике бьется)

Смогут, если взять тех кто на 8 месяце :)

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

но больше, конечно, права тема о бодишопах и от этого никуда

самое обидное — это когда ты ничего не можешь сделать для того, чтобы защитить хорошего спеца от ухода просто потому, что фирма решила на нем поэкономить

это косяки вышестоящего менеджмента

бай зе вей, есть ситуации, когда реально менеджмент может «ускорить рождение ребенка», а разработчик нет.
за счет бюджета таки взять дополнительных людей и делегировать на них часть багов(не требующих глубокого знания проекта + код-ревью, которое быстрее дебага), привлечь спецов с узкой и критичной для проекта специализацией вместо «закладываем 1 неделю на то, чтоб с этим разобраться и навряд ли будем быстро продвигаться», отказаться от части требований(с ребенком не прокатит «выпустим MVP с половиной функционала, а там будет видно»), выделить деньги на какую-то крутую библиотеку с платной техподдержкой по интеграции в комплекте.
могу еще нагенерировать.

это к чему?
я не говорю, что _всегда_ можно решить проблемы таким образом.
а лишь намекаю, что в своей категоричности вы не рассматриваете путь переформатирования.
а только «молчать, терпеть, педалить, ходить с гордым видом а-я-же-говорил».

не в любой компании такое возможно. Более того, мне давали подобного человека — у нас проект простой, пусть пилит. А когда говоришь, что проект то простой, но прогер совсем совсем джун, то тебе говорят — у нас для этого проекта нет бюджета брать опытнее человека. А потом когда сроки (хотя изначально говорилось, что в сроки не вложимся и вот реальные) горят, то с тебя спрос почему он не уложился в сроки и плевать, что ты репортил о факте, что сроки сверху фантазии. Благо у нас проект не критичный был.
Конечный итог — спустя 4!!! месяца у нас этот джун более не работал. Не в любой компании руководство понимает, что оно делает. А иногда они на авось надеятся. А главное, что все эти 4 месяца ответственный конечно же ПМ, хотя и все 4 месяца бил в колокола.

Нет, виноват не ягненок, а СЕО, который одобрил реально джуна на проект где нужен сильный мидл.

Не совсем верно, скорее ягненка вернули туда, где ему место. Ну нет у нас работы для ягненка. А СЕО финансовыми показателями и сроками поплатился

ну почти. СЕО был совладельцем — так что недополучил прибыль и потратил в пустую деньги на оплату джуна.

хотя и тут можно увидеть ошибку менеджера :D
в том, что специалиста не поменяла
а когда уже поняла «клинику» — было довольно-таки поздно — клиент уже бился в истерики
но и тут договориться получилось в конце концов

вот теперь вы правильно мою мысль уловили))

Клиента до истерики довел своей бездеятельностью менеджер, а не специалист.

1) decline
2) lower the scope
3) make the team suffer (и не забыть лизнуть заказчика).
Угадайте с 3-х раз какой в 99% случаев выбирается?

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

Подписаться на комментарии