Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

ПМ гадит... разработчику. Как быть? Что делать?

Всем привет!

На выходных в компании друзей делали разборы полетов по работодателям и вот обнаружили такую вполне типичную рабочую ситуацию.

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

Лично сам сталкивался с таким в большей или меньше степени.

Есть ПМ, сертифицирован как Скрам мастер, но полный ноль в разработке: может в гугле поискать и найти статейку, чтобы показать как хочет, но профессиональные термины называет жаргоном.

Есть девелопер.

Есть Jira с описанием задачи на 1-3 предложения. С учетом, что проект «портируется», такого описания задачи вполне хватает + на этапе получения задачи в работу дополнительный инструктаж голосом с ответами на вопросы разработчика.

Девелопер тут, ПМ — там.

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

Потом ПМ начал показывать «фокусы»:
1. Для приемки работы им: нужно после переноса задачи в тест — еще лично сообщить по слаку. Позже добавилась личная демонстрация через шаринг экрана.
2. На этапе приемки работы он вдруг «вспоминал» о еще небольшом уточнении. Иногда уточнения шли сериями: по одному за приемку. В итоге приемка проходила с пятой попытки.
3. Через неделю таких уточнений стало больше 3-х за один раз и они стали требовать уже на 5 минут, а реально по пару часов. Договорились, что ПМ будет открывать новые тикеты на расширения задач.

Прошла еще неделя. ПМ «забыл» о договоренности уточнение задачи — новый тикет. После напоминания все расширения задач начал открывать их как баги.
Появились "баги«/доработки на «Решенные» задачи.

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

Через неделю наш девелопер потерял место на славной галере, формулировка от руководства была такая:
«очень много багов за последний месяц, нам так не нужно»
:)

И теперь вопросы:
1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
2. Как правильно показать некомпетенстность ПМа в приемке работы?
3. Как пресекать самодеятельность такого ПМа?
4. Как бы Вы «строили работу» с таким ПМом?
5. Как можно сохранить свою репутацию в таком «окружении»?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Есть хорошая книга «Съесть или быть съеденным», не совсем ИТ, но все же почитайте. Первое правило гласит — если начальник хочет вас съесть, он вас съест. Но вы можете удлинить этот срок записывая все в «свой дневник» — JIRA комментами, сохраняя себе все СС email-ов, высылая follow-up-ы на митинги — прикрывая жёпу по полной. И в случае такого кипиша можно показать что такого не было и не говорили. Но в наших реалиях захотят выгнять — выгонят.

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
А как вы думаете PM стал PM-ом? Кто его назначил и за какие заслуги? И тут приходите вы и косвенно указываете на то, что начальник PM-а некомпетентен (ведь он его назначил).
2. Как правильно показать некомпетенстность ПМа в приемке работы?
Да никак, пока он начальник это невозможно. Он — начальник, ты — дурак. Чем тупее начальник, тем больше он в это верит.

Пункты 3-5 ИМХО надо валить на другой проект/контору, а PM пусть дальше «рулит».

Выгнали да и слава богу. Нафиг надо с придурками работать.

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
Нет. Это не работа руководства разбираться, что там должно входить в рамки конкретной задачи, а что — нет. Для этого ПМа и наняли, чтобы он разбирался. Раз ПМ решил так — значит он так считает будет лучше. К руководству стоит обращаться, когда деятельность ПМа прямо приводит к потере качества/производительности на проекте и вы можете это показать на пальцах с конкретными цифрами, а не просто лить воду и делиться эмоциями.
Как правильно показать некомпетенстность ПМа в приемке работы?
Для начале научиться правильно формулировать вопросы: показать кому и для чего?
Показывать самому ПМу бесполезно, если только он сам не просит у вас фидбек — только наживете себе врага. Показывать другим разработчикам — они сами должны все видеть, если есть что видеть. Показывать руководству — руководство не интересует детали приемки отдельных задач, т.к. для этого и наняли ПМа чтобы у него голова болела по организации этого и других процессов. У руководства другие метрики оценки компететности ПМа, чем у вас.
Допустим вам удалось доказать некомпетентность ПМа всем, кому вы хотели доказать, что дальше? Какой результат вы рассчитываете в результате получить, и почему так уверены, что не можете получить этот результат без доказательства некомпетентности ПМа? Вы считаете, что руководство будет учить ПМа делать его работу? Нет, не будет. Уволит ПМа и заменит на другого — не факт, что новым вы будете довольны больше, совсем не факт...
Как пресекать самодеятельность такого ПМа?
Что вы подразумеваете под «самодеятельность»? ПМа наняли ставить процессы на проекте — он их ставит как считает нужным. «Самодеятельность» — это если бы ПМ принимал решения по технической архитектуре проекта или нарушал полиси компании(в отношении овертаймов, к примеру) по своей прихоти. Изменения же процесса работы на проекте — это в компетенции ПМа и не зависимо от того, согласны вы с этим или нет, «самодеятельностью» это точно не является.
Как бы Вы «строили работу» с таким ПМом?
Зависит от того, как это влияет на мою работу, как разработчика, и на проект в целом.
1) Если есть места, которые можно, по моему мнению, улучшить — начал бы разговор с ПМом на эту тему, чтобы либо изменить что-то к лучшему, либо понять, почему лучше оставить как есть.
2) Если в результате 1) становится понятно, что улучшения нужны, но их не будет из-за «человеческого фактора» и дальнейшие разговоры с ПМом не имеют смысла — попутился бы донести руководству ситуацию на преокте с конкретными цифрами и объяснением, какие проблемы могут быть. Руководство очень хорошо понимает, когда с ним говоришь на языке конкретных цифр, которые можно легко конвертировать в величину денежных потерь.
3) Не зависимо от результатов 1) и 2) смотрел бы по личному желанию оставаться в проекте или уходить из него.
4) Зная, что у ПМа всегда есть какие-то «хотелки» во время приема задач, добавил бы сразу +10-20% ко времени при оценке задач.
Как можно сохранить свою репутацию в таком «окружении»?
Никак: «Я не могу дать вам формулу успеха, но готов предложить формулу неудачи: попробуйте всем понравиться.» © Джерард Своуп
Если ПМ ударился в микроменеджмент с горой баг-тикетов, а руководство приняло решение об увольнении только на основании числа баг-тикетов, не поинтересовавшить в причине их возникновения и не спросив мнение о ситуации самого разрабочика.... то пытаться тут что-то доказывть — это как метать бисер перед свиньями.
---------------------------
ПС: Мне лично кажется, что ситуация описана слишко однобоко и есть много моментов, которые вызывают дополнительные вопросы:
1) Не понятно, с какой целью ПМ ударился в микроменеджмент с принятием задач лично через скрин-шаринг. Это более напряжно и затратно, чем если посмотреть самому в удобное время и потом дернуть разработчика сообщить фидбек голосом, если есть необходимость.
2) Из 1) — если разработчиков на проекте несколько, а микроменеджить начали только избранных — тут скорее что-то связанное с самими разработчиками.
3) Если речь идет о портировании проекта, значит впринципе этот функционал уже написан и работает. Врядли там так уж много глобальных изменений — иначе это уже не портирование и переделка проекта. Соответственно непонятно, откуда ПМ умудряется постоянно брать эти «хотелки»: основной функционал уже определен, а синьерный разработчик с нормальным requirements gathering навыком большинство неоднозначных моментов сможет прояснить и закрыть на этапе уточнения требований по задаче. Без конкретных примеров судить невозможно, но равнозначным остается вариант, что разработчик мог поверхностно подходить к уточнению требований, по принципу «я примерно понял что нужно, сделаю как понял, если что потом скажут что доделать». Это вторая сторона медали, которая не исключает наличия первой, но может привести к точно такой ситуации, как была описана.
4) Очень странная поспешность увольнения. То, что за последний месяц «много багов в джире» — это не показатель для принятия кардинального решения. Вот так вот с ходу, не интересуясь причинами у самого разработчика? Слишком не типично. На место уволенного нужно кого-то нанимать, потом обучать и вводить его в проект и все равно нет 100% гарантий, что не получатся те же грабли или хуже. Так ради чего создавать самим себе лишние трудности поспешным увольнением? Тут на вскидку могут быть 3 варианта:
а) Разработчика так или иначе планировали уволить, просто подвернулся повод уволить по такой причине.
б) На самом деле причина не только в числе багов за последний, но были и другие притенизии к качеству/скорости работы, которые тут не озвучены. Не зная картины с точки зрения ПМа и руководства судить не получится, но в большинстве «типичных» конфликтных ситуаций между ПМами и разработчиками все бывает не так односторонне, как тут было описано (хотя справедливости ради стоит признать, что и именно так односторонне тоже бывает, но это уже не типичный кейс)
в) Таки имеем случай «самодурства», что может иногда встретиться в маленькой молодой конторе с нетехническим руководством, когда вместо того, чтобы разбираться с проблемами и вникать их просто назначают виновного и рубят с плеча. В таком случае нет смысла расстраиваться и беспокоиться и «репутации», т.к. хороший специалист без труда сейчас может устроиться в другую контору, где такого самодурства уже не будет.
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чтоб такого не было — ПМ должен оцениваться подчиненными и анонимно. Ну или же груповая заява какая-то, что с этим чуваком мы работать не можем. К сожалению в IT много упоротых ребят.

К сожалению в IT много упоротых ребят.

думаете, в других отраслях их меньше?

Можно начать с лёгкого намёка скраммастеру — «почему у нас нет daily scrum?», это если его нет, если есть — уведомьте всех заинтересованных, что у вас начались проблемы. Точно такой же вопрос можно задать и по ретроспективе. Суть этих мероприятий как раз минимизировать и определить риски (с точки зрения заказчика). Если не поможет — доносить руководству информацию: скрама нет, продакт овнер не получает фидбек от команды, что не даёт реализовать потенциал команды и обеспечить эффективное использование ресурсов.

У вас скрам, он предполагает тесное общение команды и продакт овнера. У вас этого нет! Было бы, вы бы о «бантиках» знали не в час приёмки. У вас нет ретроспектив — иначе бы вы обсудили это всей командой после первого спринта. У вас нет скраммастера(судя по вашим словам, человек есть а функционала нет) так как его задача убирать препоны, в том числе и с руководством гутарить. У вас нет дневного скрам собрания — там бы уже на второй день видна была бы проблема того, что появились овера или отставания от плана. Можно много чего ещё назвать что не так, в целом скрама у вас нет, это приводит к тому что проблема проекта стала твоей. Будет построен процесс — не будет такой ситуации. Овертайм должен быть учтён, если соглашаешься оверить безвозмездно, то так будет часто.

Шикарный коммент.

А теперь вопрос:
Как это все объяснить в терминах девелопера руководству?
Объяснить именно так, чтобы они согласились и приняли меры, а не отписали:
«ты девелопер, что ты понимаешь в проджект менеджменте, мы вот сертифицированы!»

ЗЫ ПМ сертифицирован, СТО сертифицирован.

ещё одно подтверждение, что с таких говноконтор нужно валить

Вались с такой конторы это стратегия, а дожить до зарплаты это тактика :)

Вот как петлять в подобной ситуации?
А если еще допустить, что это делается специально, чтобы не платить?

Вались с такой конторы это стратегия, а дожить до зарплаты это тактика :)

тут уже да, выкручивайтесь, раз позволили так гайки закрутить :)

А если еще допустить, что это делается специально, чтобы не платить?

вполне может быть

ИМХО что бы просто дожить до зарплаты достаточно просто не посылать тимлида нах :) Это если ты уже принял твердое решение доживать до зарплаты и не далее.

Давайте смотреть на ситуацию в динамике.

Тим лид был даже не был послан по настоящему.
Тим лида поставили на место.

Если:
1. тим лид принимает на веру описание ситуации от ПМа, без проверки фактов
2. говорит, лишь бы поговорить — обвиняет в багах, без фактажа
3. толкает на нарушение запрета от СТО

Разве это лим лид? Это так, сопля...

А как быть с багами ( которые по сути доработки ) ? Насколько я понимаю Agile процесс ( и исходя из того, с чем сталкивался на практике ) - scope в рамках итерации всегда фиксированный и не подразумевает каких-то внеплановых доработок задач ( с увеличением сроков самой итерации ) ? То есть даже если какой-то функционал и работает не так как ожидалось ( на этапе окончания итерации и представления результатов ПМ и stakeholders ) - задача должна быть включена в следующую итерацию ?

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

Мне кажется, что у Вас ПМ пытается совместить приемы классического проектного управления с Agile методиками. В случае Agile — если у Вас работа построена итеративно — команда не сдает проект/задачи в конце итерации, а презентует то, что было сделано. При этом вполне естественно, что функционал не включает в себя все, что нужно в конечном виде и все замечания/пожелания/изменения оформляются в виде задач на следующую итерацию.
В случае, если Agile не используется, то имеет смысл предложить его и обосновать это тем, что он наиболее подходит в данной ситуации ( минимальное планирование и приветствие последующих изменений функционала ).
Я не рекоммендую Вам впрямую критиковать кого либо, а лучше написать письмо ПМ и CC руководству с предложениями по улучшению процесса, но Вам в этом случае надо быть готовым уверенно обосновать зачем это нужно и что это принесет проекту.
Вы кстати не уточнили — ПМ из какой страны ? Если европеец ( франция, великобритания, ... ) то даже не вздумайте впрямую говорить что-то типа «это не верно» или «вы/он/она не правы/виноват/...» - это будет воспринято как грубость. Только обтекаемые фразы типа «выглядит нормально, но я бы предложил ...», «это работает, но возможно улучшить ...» и т.д.

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

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


Вы кстати не уточнили — ПМ из какой страны ? Если европеец ( франция, великобритания, ... ) то даже не вздумайте впрямую говорить что-то типа «это не верно» или «вы/он/она не правы/виноват/...» - это будет воспринято как грубость. Только обтекаемые фразы типа «выглядит нормально, но я бы предложил ...», «это работает, но возможно улучшить ...» и т.д.

может ещё и прямым текстом нельзя говорить идиоту, что он идиот, а надо в обтекаемой (о какое слово подходящее в данной теме) форме? :)

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

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

зачем матом отвечать?
мне плевать на культурные и ментальные различия, я априори отношусь к посторонним с уважением. До тех пор, пока они не начинают как-то неуважительно вести по отношению ко мне (или окружающим). А дальше по обстоятельствам, независимо от «культурных и ментальных различий». И да, мои интересы для меня важнее, чем «улучшить взаимодействие» и если от улучшения взаимодействия страдают мои интересы — я в первую очередь буду защищать их.

До тех пор, пока они не начинают как-то неуважительно вести по отношению ко мне
А Вам не приходило на ум, что из-за
мне плевать на культурные и ментальные различия
 Вы можете с точки зрения человека воспитанного в совершенно иной культурной среде — вести себя неуважительно по отношению к нему.
И да, мои интересы для меня важнее
 — Как и для любого человека, но Вы не думаете, что хорошие коммуникации с ПМ являются частью Ваших интересов ? Что для Вас более важно — сказать ПМ что он урод и дебил ( если он на самом деле урод и дебил ) или добиться постановки нормальных процессов к команде ?

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

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

погодите, я никогда никого не оскорбляю на ровном месте и никого матом не посылаю. Просто если человек не прав — я говорю, что он не прав. Если он обижается на подобное моё тактичное поведение — это его и только его проблемы.

— Как и для любого человека, но Вы не думаете, что хорошие коммуникации с ПМ являются частью Ваших интересов ?

если в коллективе здоровая обстановка, то да. Причём в таком случае обычно и не нарушаются мои интересы

Что для Вас более важно — сказать ПМ что он урод и дебил ( если он на самом деле урод и дебил ) или добиться постановки нормальных процессов к команде ?

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

погодите, я никогда никого не оскорбляю на ровном месте и никого матом не посылаю. Просто если человек не прав — я говорю, что он не прав. Если он обижается на подобное моё тактичное поведение — это его и только его проблемы.

Ну вот у японцев к примеру так не принято. Такое поведение считается оскорбительным и вызывающим. Привет от культурных отличий :)

Ну вот у японцев к примеру так не принято. Такое поведение считается оскорбительным и вызывающим. Привет от культурных отличий :)

А я, благодаря культурным отличиям, считаю, что жевание соплей типа «всё очень прекрасно, код вообще такой чудестный, что можно хоть к геморрою прикладывать, но есть один маленький момент...» не отражает проблему как она есть и не стимулирует вторую сторону на какие-то действия. Пусть они тоже учитывают культурные отличия :)

Вы кстати не уточнили — ПМ из какой страны ? Если европеец ( франция, великобритания, ... )

Поляки в Британии.

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

Это существенно.

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

всю жизнь говорил прямо и как-то работал и работаю, в том числе и с британцами.

А что Вы думаете — что Вам британский клиент даст в морду если услышит от Вас хамство ( с его точки зрения ) ? Напишете ему пару раз что-то типа «it is stupid» или «you are wrong» и он Вас не включит в следующий проект, а если у Вас в команде все будут общаться в таком стиле — выберет другую компанию. Вы даже не узнаете никогда причину решения .. С британцами вообще достаточно много разных моментов есть , с американцами проще — они ребята прямые если не сказать хамоватые ...

Напишете ему пару раз что-то типа «it is stupid»

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

или «you are wrong»

говорил (оборачивая в excuse me, естественно, моя цель сказать человеку, что он не прав, а не оскорбить в данном случае), включали. Вообще, честно сказать, я по-другому не умею. Меня претит от оборачиваний мнения о говнокоде в слюнявые выражения типа «код просто замечательный, но было бы лучше, если бы это было реализовано чуть по-другому, если я не прав, то извините...». Потому что если это говнокод — то теряется вся эмоциональная окраска того, что я хочу сказать.

И теперь вопросы:
1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?

Как бы да


2. Как правильно показать некомпетенстность ПМа в приемке работы?

Прямым текстом


3. Как пресекать самодеятельность такого ПМа?

Прямым текстом


4. Как бы Вы «строили работу» с таким ПМом?

Ткнул бы носом при первом выбрыке и сказал бы, что или работаем нормально, или не работаем вообще. Точка


5. Как можно сохранить свою репутацию в таком «окружении»?

Вам важна репутация в каждом жабовнике?

ЗЫ. Я иногда просто фигею с людей, его целенаправленно давят, он это позволяет делать длительное время, молчит как рыба об лёд, потом почему-то удивляется, когда вышестоящее начальство его увольняет. А как оно должно было поступить? Девелопер молчал? Молчал. Значит его всё устраивало, значит он соглашался с тем, что это были баги. Кто в этом виноват, как не сам девелопер?
Я помню, как, работая на одного заказчика, индус-тестер тоже решил наплодить кучу итемов (не помню, как они в jira называются) с пометкой баг везде, где реализация не соответствовала его представлению. Когда я обратился непосредственно к ПМ — он сослался на то, что у него нет времени разбираться и что он очень недоволен, что так много багов. Тогда я достучался вообще до инвестора, настойчиво попросил его уделить мне пару минут и, когда он их всё же уделил — описал ситуацию как есть и разнос пошёл и индусу-тестеру, и ПМу, которого вообще попёрли нафиг. Не знаю, какая тут «типичная рабочая ситуация», но у меня и в мыслях не было проглотить это, я лучше перестану сотрудничать, чем буду прогибаться под чьи-то интересы.

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

А тут вероломно все расширения задач стали открываться как баги и мои статсы испортились :(
Я не ожидал такого подлого хода со стороны ПМа.

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

Начальство вникать не захотело...

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

А тут вероломно все расширения задач стали открываться как баги и мои статсы испортились :(

чего же тогда ждали, почему сразу не высказали как есть?

Начальство вникать не захотело...

я бы на Вашем месте и не переживал :)

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

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

чего же тогда ждали, почему сразу не высказали как есть?

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

А в субботу я получаю втык от тим лида. Высказал как есть, но уже оказалось поздно :(
Мнение было составлено.

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

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

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

Я это уже понял :(

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

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

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

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

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

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

а где Вы «перегнули палку»? Наоборот же пишите, молчал до последнего

За неделю до моего выгона, в рамках защиты пришлось слить ПМа, публично сказав: «выполнять проверку моей работы не имея последней версии среды разработки и СДК + Ноль байт свободного места на винте (нельзя скачать свежие исходники) это крайне непрофессионально. И это обязательно нужно было указать рядом с упоминанием в моих багах».
В пятницу, за день до слива, я через тим вьюер на макбуке ПМа увидел описанные выше проблемы и мы договорились, что я ему помогу, как только он освободит место на макбуке.
Собственно рядом, что-то вякал тим лид о багах в девелоперской ветке — пришлось публино попросить написать факты: «баг — способ получения» — что его заткнуло до понедельника, ибо ему нечего было показать, он верил ПМу...

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

Ну хоть за отработанную часть месяца ты деньги то получил?

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

А минутки писать не пробовали?

А минутки писать не пробовали?

это как?

Позже добавилась личная демонстрация через шаринг экрана.
после таких созвонов писать письма с пунктами мол нужно сделать все эти «мелкие уточнения» можно ещё и комментарии со слека добавить в виде квот, а ещё в копию команду поставить.
И ваше детальное описание как вы все это видите и уточнение в виде «так ли это, все я правильно понял? это все что нужно исправить/добавить?» в конце письма. Тут уже не увильнешь если он ответит что все ок, то все ок, если не ответит вообще то это уже его проблемы.

Ну а дальше при появлении чего то ещё сверху поднимать переписку и вести беседы.

Я так делал.
Более того, писал спецификации на решения.

Но проблема оказалась глубже:
спецификации никто не читал как и мои коменты к тикетам в Жире :(

ЗЫ Это будет другой топик, на следующей неделе.

и на письма не отвечал?
Я так понял по

ПМ — там
, что это со стороны заказчика, а с вашей стороны есть кто то кто разбирает эти кейсы/решает подобные вопросы? Вам определенно стоит попробовать пролобировать свои интересны если решите вопрос то будет полезный экспириенс если нет, то всегда успеете/уволится/перейти в другую контору. Как по мне стоит попробовать решить конфликт прежде чем уходить, банально поговорить с человеков в виде «у нас есть проблема, давай решать».
и на письма не отвечал?
Я так понял по

Именно. Письма уходили в «неизвестность». Мои комменты в Жире игнорировались.

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

Я пробовал, не смог :(
Вот и задал вопрос к «коллективному сознательному», чтобы понимать так подобные проблемы решаются у других.

Скрам-Мастер? Плохой очень.
1. Скрам в принципе предполагает другой процес. 2 недели спринт, раз в 2 недели демо, потом пост-мортем, и дейли стендапы. Все. Никаких приемок между демо. Все уточнения на демо.
2. Истории и такски на 1-3 строки — полная лажа. Даже если приложение портируется. Раскапывать скрытые требования — не задача разработчика.

То есть процесс был поставлен крайне плохо.
Разработчику конечно может быть сложно правильно описать, что именно за проблемы.
Потому да, сначала можно поговорить с ПМом, что это какая-то лажа, пусть лучше описывает таски, ну и оценивать по вермени больше. Если ПМ ничего не меняет, то либо валить, либо идти к начальству.
Те кто пишут, что к начальству нет смысла идти, странные люди. Аргументы типа «а вдруг если выползти из болота еще хуже будет».

Велком ту реалити. Это сама жизнь!

Вот так и быть терпилой до пенсии?

Мне такое не подходит :)

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

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

Это не решает проблему.
Принципиально у меня поменяется ситуация.
Ко мне будет приходить девелопер и жаловаться на ПМа, а что мне ему говорить?
Паверное придется говорить «Терпи, не твое дело жаловаться на ПМа, я его нанял, чтобы снять этот головняк в себя. А не нравится — иди свой бизнес открывай, так Вадим Копанев советовал.» :)

Я пытаюсь понять как это принято решать сейчас. Увы многие готовы терпеть :(

Типичный рабочий момент, не более чем.

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

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

Задачи выдаются по одной. Либо делаешь то, что дали, либо куришь бамбук :(

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

Точно, что срам :)

Мне задачи выстроили по приоритетам.

Ну... и дальше твоя работа вместе с ПО проработать эти задачи до нужной степени детализации. И в соответствии с приоритетом нагребать в спринт.

Это будет тема другого топика :)

На следующей неделе будет.

У ПМ такая работа гадить девелоперам. А девелопер за это получает деньги. И все счастливы

Тоже вариант :)

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

А тут у автора есть трекер, в котором заведены баги «добавить функционал». Возможно тут имело место заочне увольнение по почте, но если нет, то что мешало прямо во время разговора с начальством продемонстрировать эти тикеты и определение слова баг из Википедии? Стучать — это кстати очень детсадовское слово. Если у меня проблемы с работой по вине другого звена — я обязательно сообщу об этом и ему и начальству, потому что мы не в Зарницу играем или сам-погибай-товарища-выручай, а делаем дело за деньги и проблема со смежниками находится в той же плоскости, что и отсутствие интернета или бумаги, а не в какой-то мифической реальности, где такое называется стучать по рабочим вопросам.

Автор на полном серьезе считает, что

Собственно софтверная фирма без СЕО и СТО может проработать, а вот без разработчиков никак :(
Любой человек с опытом реального управления, кому «повезло» пересекаться с такими исполнителями, может предсказать результат заранее. Формальная причина увольнения тут особой роли даже не играет.
Любой человек с опытом реального управления, кому «повезло» пересекаться с такими исполнителями, может предсказать результат заранее. Формальная причина увольнения тут особой роли даже не играет.

У Вас есть наверное есть фотка Тима Кука с паяльником?

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

Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
руководству ПМа не стоит стучать — им по большему счету пофиг — собственно для этого нанят этот ПМ, что бы оградить вышестоящее руководство от этих задач, но стоит рассказать тимлиду, если такой присутствует и он может быть попытаеться решить вопрос и как-то все замять
2. Как правильно показать некомпетенстность ПМа в приемке работы?
а смысл? вообще в таких случаях стоит вести переписку в комментариях в жире и прямым текстом просить ПМа дублировать все в комментариях, если он просит что-то сделать через диалог в скайпе, тогда все четко будет
3. Как пресекать самодеятельность такого ПМа?
пускай все пишет в жире, если задача не баг пиши, в комменте к таску, что бы поменял тип задачи на правильный с твоей точки зрения
4. Как бы Вы «строили работу» с таким ПМом?
попытаться найти общий язык, если все так сложно проситься на другой проект
а тут мне кажеться, что сам ПМ нажаловался руководству с формулировкой, что разработчик некомпетентный и не может сделать задачу с первого разу и у него одни бока, вот даже в жире видно..

Конечно виноват разработчик, что не телепат :)

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

Проверка работы:
(ПМ) — А экран скролится?
— нет не скролится.
(ПМ) — а почему?
— а потому, что экран эН не скролится.
(ПМ) — нужно чтобы скролился.
— ок сделаю.

Как я могу такое угадать?
Вы бы такое угадали?

За остальное спасибо!

та я бы и не угадывал, я бы ему сказал прямым текстом — «напиши это в жире, хотя бы в комментарии, и я все сделаю»

Вот об этом я и толкую :)

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

Супер.

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

Других задач нет.

Как правильно сказать, ну раз нет задач — я ушел домой :)

Или вариант 2:

Прожимают на выполнение задачи: «делают вид, что мои вопросы несущественны и я раздуваю из мухи слона», как быть в таком случае?

Сам був в дещо схожій ситуації, нажаль, занадто пізно пізно зрозумів, як необхідно поводитись.
Я б писав листа цьому ПМу з темою BLOCKER чи щось таке, в копію, по можливості, вставляв вашого мененджера, аби був в курсі. В литсі писати, що без необхідної інформації, якою не суттєвою для менеджера вона б не була, неможливо виконати задачу.

Именно так, если у ПМ простаивают девелоперы то скорее снимут голову ПМ чем девелоперу.

1 — Брать задачи только с четкими и понятными AC.
2 — Все пожелания на демо оформлять как подзадачи и увеличивать эстимейт. Чего не написано в джире — того делать не надо.
3 — не забывать всегда умножать эстимейт на 2.
4 — Не забывать логать время когда возвращаешь задачи обратно ПМ с комментарием о недостаточно ясных требованиях.
5 — Если нет задач, сделать себе тикет (или попросить начальство) на простой.

ps: летят головы таких ПМ на раз-два.

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

Вопрос в том что ПМ меня подставил тем, что расширения задач открывал как баги — это есть вся соль конфликта.

Я уже давно не мечтаю о спецификации по проекту, есть описание, хоть какое-то уверенное видение — уже хорошо :)

Как организована работа ? Итерации/Agile или классический waterfall ? Ставьте resolution ’won’t fix’ и в комментариях пишите, что это не баг и ссылку на описание функционала. Вы сами можете создавать в джире задачи ? Если да — создавайте ’Improvement’ задачу и ставьте ссылку на нее в коментах. Тестировщики есть на проекте ? Не соглашайтесь с багами которые не баги — закрывайте с соотв. комментариями — это абсолютно нормально, но будьте готовы аргументировать.

Именно такие дельные комменты мне и нужны.

Можно попробовать сначала так в Slack ( мой английский далеко не идеален, поэтому фразы просто для примера ) , лучше в публичном канале : «Can we change type of this issue to ’Improvement’ ? ПМ может начать говорить, что работает не верно , тут Вам нужно по пунктам доказать что вот так ’Expected’ судя по описания, а вот так ’Actual’ по функционалу . Если будет говорить что да, это формально соответствует описанию, но он ожидал по другому : ’ok, i’m trying now to find this in the specification, can you please send me the link ? ’ Если скажет, что это не описано, но он думал, что очевидно : ’yes, i understand but my implementation is based on this description .... ’ цитата или ссылка на функционал . Нормальный ПМ тут уже пойдет на встречу, если нет то : ’i prefer to change type of this issue to Improvement’. Это уже будет предконфликтная ситуация. Если не помогает, то можно дальше : ’yes, i understand but i can’t accept this issue as a bug because implemented functionality is matched to described in the specification so can we change this to Improvement/Change request ? ’ И главное если Вы уверены что баг это не баг и 100% можете аргументировать — не принимайте его как баг. Очень вежливо, используя «can you please», «can we change/discuss/review», «sorry but i think», ... стойте на своем. ПМ сдастся и будет дальше ставить ’Improvement’ только чтобы не ввязываться в подобные дискусии.

Буду пробовать в следующий раз.
Спасибо!!!

Нагадь ПМ — смени работу, в качестве причины спокойно опиши непонятки :)
Сильно удивишься освободившемуся времени на конструктивные дела вместо выяснения отношений со злобным буратиной.
Заодно добавишь +500 к бюджету.

П.С. Кейс годится только, если ты так хорош, как тебе кажется :) Если это не так — попытайся спокойно повыяснять концерны ПМ, принять, понять и простить :)
Его там тоже интенсивно теребит руководство/клиенты.

Есть хорошая книга «Съесть или быть съеденным», не совсем ИТ, но все же почитайте. Первое правило гласит — если начальник хочет вас съесть, он вас съест. Но вы можете удлинить этот срок записывая все в «свой дневник» — JIRA комментами, сохраняя себе все СС email-ов, высылая follow-up-ы на митинги — прикрывая жёпу по полной. И в случае такого кипиша можно показать что такого не было и не говорили. Но в наших реалиях захотят выгнять — выгонят.

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
А как вы думаете PM стал PM-ом? Кто его назначил и за какие заслуги? И тут приходите вы и косвенно указываете на то, что начальник PM-а некомпетентен (ведь он его назначил).
2. Как правильно показать некомпетенстность ПМа в приемке работы?
Да никак, пока он начальник это невозможно. Он — начальник, ты — дурак. Чем тупее начальник, тем больше он в это верит.

Пункты 3-5 ИМХО надо валить на другой проект/контору, а PM пусть дальше «рулит».

Выгнали да и слава богу. Нафиг надо с придурками работать.

Это уже конструктив.

Есть хорошая книга «Съесть или быть съеденным», не совсем ИТ, но все же почитайте. Первое правило гласит — если начальник хочет вас съесть, он вас съест. Но вы можете удлинить этот срок записывая все в «свой дневник» — JIRA комментами, сохраняя себе все СС email-ов, высылая follow-up-ы на митинги — прикрывая жёпу по полной. И в случае такого кипиша можно показать что такого не было и не говорили. Но в наших реалиях захотят выгнять — выгонят.

Мне это ясно.
Скрытый мотив «повозиться» — это дожить каким-то чудом до зарплаты, чтобы потом свалить.

А как вы думаете PM стал PM-ом? Кто его назначил и за какие заслуги? И тут приходите вы и косвенно указываете на то, что начальник PM-а некомпетентен (ведь он его назначил).

Я пожалуюсь, еще несколько человек пожалуется. Глядишь, через период времени ПМ-самодур потеряет работу :)

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

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

Я пожалуюсь, еще несколько человек пожалуется. Глядишь, через период времени ПМ-самодур потеряет работу :)
Ты знаеш, рано или поздно награда все равно находит героев. Если ПМ слабый, это рано ли поздно вылезет и он за это получит по полной. Ну, тебя к тому времени уже там не будет конечно. Дожить до зарплаты — нормальный мотив

Вроде бы как все правильно, но я уже неоднократно вижу не совсем понятное для меня утверждение, что ПМ — начальник. Он менеджер проекта, а не людей, он не team manager, не team lead. ПМ выполняет ряд административных задач, чтобы разгрузить от них девелоперов. Он не начальник, он на то же ступени иерархии, он часть команды, но занимается другими задачами. Да и к тому же известна куча случаев команд без ПМ-ов, вполне успешно справляющихся, а вот что ПМ-ы делали проекты без девов (в ИТ, конечно же) как-то не могу вспомнить.
Возможно, попался ПМ с «индийской философией», с перепугу решив, что с такой лычкой он — полубожество. Но больше похоже на внутренний/личный конфликт, о настоящих причинах которого вряд ли хоть одна сторона конфликта прямо скажет. Кому руководство больше доверяет, тот и останется. Доносить до руководства суть проблемы без истерик и лишних эмоций тоже надо уметь.

Доносить до руководства суть проблемы без истерик и лишних эмоций тоже надо уметь.

Вот именно об этом и речь, что может считаться доказательной базой? Так чтобы даже уборщица поняла.

Цифры. Только не надо уборщиц, а то кажется, что вы хотите публичной расправы.
Руководству надо все точно и четко доносить в цифрах, не можете в денежных единицах, доносите в часах. Что, куда и почему. Сколько времени ушло не по адресу и по какой причине, как решать.
Как вам уже писали, герой свое получит, все-таки основная цель компаний — материальная прибыль. Если ПМ и правда такой Д’Артаньян, то долго его триумф не продлится.
Если же вы уверены на 100% в его некомпетентности, а на руководство не реагирует на ваши детальные доводы с почасовыми раскладками, валите оттуда.

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

«Базовые математичекие операции» — тоже нужно уточнить перечень :)

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

Ваше утверждение верно для энтерпрайза. А мир большой и разный.

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

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

Когда-то, один мой клиент мне сказал: «Программист 1С в наше время на проблема.» Они полгода себе искали другого чувака на поддержку своей системы. Полгода звонили раз в неделю, 2 цены предлагали :)

Доносить до руководства суть проблемы без истерик и лишних эмоций тоже надо уметь.

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

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
По моему мнению, вопрос поставлен некорректно изначально. Задача ПМа и есть определение «рамок задачи», и не исполнителю решать, выходит он за них или нет. А вот за правильным оформлением «новых бантиков» нужно следить исполнителю: если вместо фичи заводится баг — требовать от ПМа изменить тип таска. Если ПМ упорот (с вашей точки зрения) — всю переписку вести в JIRA, с аргументами.
2. Как правильно показать некомпетенстность ПМа в приемке работы?
Думаю, вопрос стоит в другом: как прикрыться исполнителю от «наказания невиновных». Скурпулезное сохранение деталей процесса в JIRA.
3. Как пресекать самодеятельность такого ПМа?
Судя по написанному Вами, ПМ выполняет свою работу. Как умеет. «Пресекание самодеятельности» будет расценено таким ПМом как агрессия, с соответствующими ответными шагами. И снова совет один: скурпулезное сохранение деталей самодеятельности в JIRA, словам не верим совершенно либо прикидываемся шлангом, что «забыли, о чем мы там говорили». Нет таска — нет проблемы.
4. Как бы Вы «строили работу» с таким ПМом?
Если не удается договориться по человечески — все общение в JIRA.
5. Как можно сохранить свою репутацию в таком «окружении»?
Профессионально и качественно выполняя свою работу, не соглашаясь на хождения в сторону от устоявшегося процесса разработки.

P.S. Данная ситуация — мрак. Если между ПМом и исполнителем нет общего языка (особенно, если Вы один такой) — самое лучшее решение для всех будет развести Вас и ПМа по разным проектам. Что и было сделано. Если ПМ не находит общего языка с большинством исполнителей — решение должен принимать руководящий персонал. А для этого должны быть «доказательства» — скурпулезное ведение истории в JIRA, написание докладной/объяснительной с детальным разбором ситуации на основании имеющихся фактов.

P.S.2. Исполнителю НИКОГДА не стоит вступать в словесную дуэль с ПМом либо объяснение своей позиции перед руководством на словах. Это поле ПМа, он там Вас переиграет, будь вы трижды правы. Иначе бы он не был ПМом...

Я вот тоже к этому пришел.

Внутрішній конфлікт ©

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

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

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

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

Вот вся соль в том, что сначала голосом как бы договорились, а потом ПМ видать понял свои пробелы и начал свои «забытые хотелки» оформлять мне «багами».

Репутацию вам не нужно сохранять, просто оставайтесь профессионалом.

В результате кучи открытых багов начальство решило, что это я виноват.

Я надеялся все объяснить в надлежащий момент.

Увы, время объяснений не наступило :(

Вот и стоит вопрос как сразу наиболее эффективно решить вопрос на этапе «ПМа понесло создавать баги»?

На других проектах вполне хватало просто поговорить.
Здесь ситуация вышла из-под контроля...

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

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

Навеяно www.youtube.com/watch?v=WOQIcaM3bag

И теперь вопросы:
Возможно ли ПМу пересадить голову разраба ?
Есть Jira с описанием задачи на 1-3 предложения. С учетом, что проект «портируется», такого описания задачи вполне хватает + на этапе получения задачи в работу дополнительный инструктаж голосом с ответами на вопросы разработчика.
Так делать нельзя, нужно переводить голос в текст и дописывать к тикету, потому что что-то забудется, что-то потеряется, а так оно оформлено документом перед глазами.
На этапе приемки работы он вдруг «вспоминал» о еще небольшом уточнении. Иногда уточнения шли сериями: по одному за приемку. В итоге приемка проходила с пятой попытки.
Пусть их документально оформляет, причём как усовершенствование, если создаёт багрепорты — переделывать их в story. Если продолжает создавать баги — закрывать с вердиктом wan’t fix — бла-бла.

Да это хорошее решение.

О переделке Бага в Стори я не подумал. Спасибо!!!

Мне не дали так сделать :(

Более того, мне поставили условие, что пока ветку с моей готовой работой по задаче не сольют с девелоперской веткой и после слияния ПМ повторно ее не проверит, то мне нельзя начинать новую задачу.

Это правило просуществовало ровно один день — вторник.
Во вторник я закончил задачу в 14 часов, отправил пул риквест и пишу в чат: «Пул риквест отправлен. В соответствии с правилом от понедельника я не могу начать новую задачу. Обычно время слияний занимает 1 час +/-, + дополнительная проверка, то я еду домой, а завтра если не будет замечаний, то я начну новый тикет.»

Это сработало во вторник.

А вот в среду, мне тим лид написал на это «Чувак, делай новую ветку в гите и бери новый тикет. » :(

Я на это огрызнулся, что правило поставил СТО и не тим лиду его отменять :) Раз СТО на месте не оказалось, то я уехал домой.

Понятно, что в пятницу мы уже прощались :)

По-моему еще пара постов, и вы отрефлексируете все истинные причины, по которым вас уволили с удобной отмазкой про «много багов»...
dou.ua/...orums/topic/18272/#971778 ©

Это такой троллинг?

Каждый может оказаться на моем месте.

А может быть еще хуже — Вы будете моим боссом в такой ситуации :)

Я на это огрызнулся, что правило поставил СТО и не тим лиду его отменять :)

Огрызаться, мне кажется, не стоило. Для таких случаев есть волшебная фраза — «под вашу ответственность». Твой непосредственный начальник — тим лид, и беседу с ним нужно было строить следующим образом: «на всякий случай хотел бы напомнить, что это противоречит инструкциям от CTO — но раз ты, как мой руководитель, считаешь, что так будет лучше для проекта — без проблем, возьму новый тикет под твою ответственность, только напиши мне это пожалуйста письмом, чтобы ко мне потом ни у кого вопросов не было»

Не все так просто.

Тим лид тоже придумывал то правило :)
Пусть тоже страдает от своей глупости.

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

Объявите публично об отмене правила, мне не нужно персональных одолжений и потом еще отправдываться «мне сказали так сделать». Я уже делал как говорил ПМ :)

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

Искренне желаю Вам на своей шкуре испытать такой «дружный коллектив».

Разница в нашем с Вами стаже существенна.

Когда у Вас будет 20 лет в АйТи посмотрим какой Вы будете «командный» и не «конфликтный» :)

Искренне желаю Вам на своей шкуре испытать такой «дружный коллектив».
да работал я в говноконторах, большая часть колектива обычно все равно дружественная
Когда у Вас будет 20 лет в АйТи посмотрим какой Вы будете «командный» и не «конфликтный» :)
характер от опыта работы не зависит

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

Тим лид тоже придумывал то правило :)
Пусть тоже страдает от своей глупости.

Не кажется, что это немного детская позиция?

В понедельник ограничим тебе з/п (пока ветки не слиты, новый тикет не брать в работу)

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

а) Простоя на несколько часов, и
б) Простоя, который произошел не по твоей вине

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

Тут или автор лукавит, или в этой конторе творится полный неадекват. Даже если всё так туго с оплатой часов, тим лид мог бы договориться с автором: ОК, сегодня мне тебя загрузить нечем, давай сегодня ты уйдешь пораньше домой, а завтра-послезавтра отработаешь эти часы? Хотя, обычно, все равно есть фоновые задачи типа поревьюить чей-нибудь код, дописать тесты, порефакторить...

Не кажется, что это немного детская позиция?

Вопрос не в детскости позиции.

Есть иерархия: СТО — тим лид — девелопер.
Если СТО делает «короткое замыкание» — командует девелопером — пусть прочувствует все на своей шкуре.

Было принято решение против меня — ограничение меня в заработке — одна задача за раз, пока ветки не слиты.

Руководитель принял решение. Позже руководитель понял, что таким решением он сам себе наступил на хвост — тормозится проект.

Как решение принято — так пускай и отменяется — не нужно мне создавать еще хуже ситуацию:
подталкивать нарушать прямой запрет руководителя — так меня уже разводили, спасибо, больше не нужно :)


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

а) Простоя на несколько часов, и
б) Простоя, который произошел не по твоей вине

В конце недели заполняется табель: сколько работал, что делал.

Ну круто. ИМХО когда дела складываются так, при этом все равно кто именно виноват, ты или они, то лучьше уходить поскорее.

В понедельник ограничим тебе з/п (пока ветки не слиты, новый тикет не брать в работу),
Все интересней и интересней. А от этого ещё и зависела твоя зарплата? Оплата почасовая за отработанное по тикетам время? Тогда не понятна вообще твоя мотивация «доживать» до зарплаты. ты ж бы там много все равно не заработал.

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

Фирма, такие пункты обходит так:
1. Давайте поставим доровор на паузу, на месяц-два, временно нам Ваши услуги не нужны, но потом обязательно понадобятся.
2. Вы себя отвратительно ведете, много нареканий со стороны коллег, никто не хочет с Вами сотрудничать. Поскольку мы не видим как можно работать с Вами дальше, то договор прерываем прямо сейчас.

В обоих случаях фирма понимает, что лукавит и деньги оплачивает чаще чем в других случаях.

Если сотрудник разрывавет договор, то начинается:
1. З/п придержим пока не проверим весь твой код, вдруг там баги, чтобы ты исправил
2. Приведи нам замену, не будет замены — не будет з/п или вычтем гонорар рекрутера.
3. Зарплата задерживается, потому что стали «заняты».
+
как писали на ДОУ людям платят з/п с задержкой на 2 месяца — тоже хороший способ снизить текучку :)

Поэтому, как показывает жизнь, лучше чтобы тебя «выгнали» либо свалить потихому после получения з/п.

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

Это где такие старсти в Украине в начале 2000х или в «цивилизованном мире»?

Это события последнего года как ни странно...

И что, там нет юридических рычагов решить эту пробему? Или решать её себе дороже?

Вы хоть раз судились?

Да, с ЖЕКом, по их инициативе.

Я правильно понял, что в принципе можно, но очень накладно?

Можно, но не всегда это выгодно :(

как писали на ДОУ людям платят з/п с задержкой на 2 месяца — тоже хороший способ снизить текучку :)

эта фирма обсуждалась на ДОУ перед новым 2016 годом

Остальные я называть не буду НДА или мое или чужое :)

Если не веришь — считай, что я наврал :)

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

На выходных в компании друзей делали разборы полетов по работодателям
На выходных в компании друзей делали разборы полетов по работодателям

Более того мы это называем «постмортальный анализ» :)

1. Не писати таких тем під реальним іменем. Його будуть бачити hr наступного разу, ризикуєте поповнити блекліст.

2. Як я зрозумів з коментарів, автор не пройшов випробувальний? Ну ОК, компанії він не підійшов і не стали розбиратися. А може й ще що було.

3. Сидіти до 19-20 замість того, щоб йти в 18 на постійній основі? Я б на другий раз ввічливо направив погуляти в піше еротичне.

4. Ніяких других шансів. Знову ж таки, після другого разу — ескалейшен на його керівника. Це має бути ОК, інакше сідає на щию.

А взагалі добре, що попрощалися — непідходила вам контора.

1. Не писати таких тем під реальним іменем. Його будуть бачити hr наступного разу, ризикуєте поповнити блекліст.

Найстрашніше :)

2. Як я зрозумів з коментарів, автор не пройшов випробувальний? Ну ОК, компанії він не підійшов і не стали розбиратися. А може й ще що було.

Випробувальний термін було пройдено успішно. ПМ споганився десь через місяць після завершення випробувального.

3. Сидіти до 19-20 замість того, щоб йти в 18 на постійній основі? Я б на другий раз ввічливо направив погуляти в піше еротичне.

Це мені зрозуміло, просто коли новенький, то треба показати лояльність компанії... тим більше, коли треба зробити «тільки таку маленьку фішечку...». Зараз я вже бачу, що треба було після другого сигналу з «добавкою» кидати практику овертаймів.

4. Ніяких других шансів. Знову ж таки, після другого разу — ескалейшен на його керівника. Це має бути ОК, інакше сідає на щию.

А взагалі добре, що попрощалися — непідходила вам контора.

Що правда, то правда.

1. Не писати таких тем під реальним іменем. Його будуть бачити hr наступного разу, ризикуєте поповнити блекліст.

Коли я створював цей топік, то я розраховував, що ПіеМи з ТОПових компаній поділяться тим, як у них в компаніях вирішуються подібні «ситуації».

А так получається, що ТОПові компанії у нас є, видатні ПіеМи теж є, а от регламенту вирішення конфліктів немає :(

Прямо як в анекдоті:
(мовою оригіналу)
«Одесса. В трамвай входит дама. Сидячих мест нет. Дама вопрошает:
— Неужели в Одессе перевелись джентльмены?
В ответ:
— Джентельмены-то есть, местов нет.»

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

Пусть заносят в черные списки. Напугали :)

Что-то после прочтения мне на ум пришло вот это:

Если кто-то там наверху продает так, что ты не знаешь как делать, то нормальный мужик идет и тупо набычившись проговаривает это продажнику, шефу или вообще не берется делать ***ню, если не может. А ты берешься, так хули мне не продавать, если ты потом все равно делаешь? Кстати, врубись —сначала ты сказал что это нереально, а потом блять взял и сделал —кто тут кого ебет по срокам? Сделал раз —будешь делать и дальше, моя забота зарабатывать. Зарабатывать это получать больше, а тратить меньше —компренде?
© Черная книга менеджера

Очень в моем стиле :)

Что-то после прочтения мне на ум пришло вот это:

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

Как правильно донести «такое» до начальства, чтобы оно поняло проблематику?
Вот в чем вопрос...

У меня два вопроса: 1 — ПМ на стороне клиента или непосредственно их вашей родной компании ? 2 — Вы непосредственно с ПМ-ом пытались оговорить эту ситуацию?

1 — ПМ на стороне клиента или непосредственно их вашей родной компании ?

Компания продуктовая и ПМ ихний.

2 — Вы непосредственно с ПМ пытались оговорить эту ситуацию?

Да. Сначала договорились, и он выполнял договоренности.

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

Я тогда не понимаю, с чем Вы придете в своему руководству. У вас есть беклог, где каждый user story описана 1-3 сточками, и просто доказать, что вы выполняли требования четко по описанным критериями нет никакой возможности. Если у вас нет фиксации требований в каком-то виде, нет смысла даже идти к руководству с такими пояснением. Но зато есть четкий список багов и как вы будет доказывать, что это не баги ? Второй момент — это ПМ на стороне заказчика, и для Вас он выступает Product Owner-ом как я понимаю, т.е. это была ваша задача у него уточнять все требования, если вам было не понятно. Теперь, что вы хотите, чтобы сделало ваше руководство — пошло ругаться с клиентом ? Врядли это вообще случиться — аргументов нет никаких, и даже если бы они были, никто не пошел бы на конфликт. Поэтому поступили вполне рациональным способом — Вас убрали с проекта во избежания конфликта. Вы лучше опишите, как бы вы хотели, что бы поступило ваше руководство в этой ситуации?

Я тогда не понимаю, с чем Вы придете в своему руководству. У вас есть беклог, где каждый user story описана 1-3 сточками, и просто доказать, что вы выполняли требования четко по описанным критериями нет никакой возможности.

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

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

Именно это и оказалось проблемой на первом этапе.

Но зато есть четкий список багов и как вы будет доказывать, что это не баги ?

Да именно.
Вот ПМ хочет что бы было по другому, а раз это не так как ему нужно, то он считает что это баг :(

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

Задача меняется по мере выполнения.
Как было:
Сделай такой экран, стили возьмешь с экрана эН.

Проверка работы:
(ПМ) — А экран скролится?
— нет не скролится.
(ПМ) — а почему?
— а потому, что экран эН не скролится.
(ПМ) — нужно чтобы скролился.
— ок сделаю.

Как я могу такое угадать?

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

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

Чтобы я хотел чтобы сделало руководство:
1. Раз тим лид сливает в гите ветки, то он мог бы спросить: «А почему на эту задачу так много комитов, несоответсвующих постановке?»
2. Как минимум поставить на место ПМ, сказать, «Тебе сделали, то что ты просил. Нужно больше — через тикет».
3. Если полезли баги, то как правило это сигнал пану начальнику о разногласиях/конфликте в команде. Даже если команда из двух человек. Есть такое правило в управлении, что если подчиненный накосячил, то винован начальник: или поручил некомпетентному сотруднику задачу или плохо объяснил, что нужно сделать.
4. Выслушать обе стороны и принять решение. Пусть даже и показательно наказать обоих. Даже согласен на то, что биг босс в привате скажет ПМу: чувак, я тебя для близира поругаю, а ты прикинься, что тебе страшно :)
5. Тормознуть работу по проекту, пока текущие задачи не будет решены полностью. Т.е. «закрыть» все баги на «принятые» ранее работы. Публично получить от ПМ подтверджение, что все проблемы закрыты.
6. Рассказать ПМ различия между багом и расширением задачи.

Как-то так :)

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

2.Поймите, это вы хотите поставить заказчика на место. Основание для этого нет никаких.

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

4.Наказание уже пришло — вас убрали с проекта. Какой смысл руководству разбираться в этом повторно ?

5. Что значить тормознуть работу — а издержки по проекту, разбирательству Вы оплатите из своей зарплаты? Что значит публично получить от ПМ подтверждение — вы что хотите его поставить и позорно пристыдить при всеx, а потом поклятся на библии? Как уже сказали, на основании чего — у вас нет никаких аргументов.

6. Возможно так и будет сделано. Но без конфликта.
===========
Все что вы можете сделать — это попробовать составить четкий небольшой!!! документ для руководства, чтобы как-то разьяснить ситуацию. Смиритесь, что никто вашего ПМ наказывать не будет.

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

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

Тил лид просил делать комиты как можно чаще, чтобы «видеть динамику».

2.Поймите, это вы хотите поставить заказчика на место. Основание для этого нет никаких.

Понимаю что ситуация «Пан и холоп», но если потакать всем хотелкам, то можно и без денег остаться. Меня так разводили лет 10 тому назад. Порядок есть порядок. Раз работаем по тикетам, то работаем по тикетам.

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

А давайте допустим, что я сделал работу хорошо и именно в соответсвии с тем, как меня просили изначально ее сделать?

Поменялась картинка? :)

4.Наказание уже пришло — вас убрали с проекта. Какой смысл руководству разбираться в этом повторно ?

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

5. Что значить тормознуть работу — а издержки по проекту, разбирательству Вы оплатите из своей зарплаты? Что значит публично получить от ПМ подтверждение — вы что хотите его поставить и позорно пристыдить при всеx, а потом поклятся на библии? Как уже сказали, на основании чего — у вас нет никаких аргументов.

А как по Вашему это можно решить еще? Проект сыпется... по крайней мере в соответствии с системой ведения проекта. На одну закрытую задачу открывается несколько багов. Как минимум нужно разобраться почему.

6. Возможно так и будет сделано. Но без конфликта.
===========
Все что вы можете сделать — это попробовать составить четкий небольшой!!! документ для руководства, чтобы как-то разьяснить ситуацию. Смиритесь, что никто вашего ПМ наказывать не будет.

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

Проблема в том, что не техарь оценивает технаря.

Очень вероятно, что в следующий раз я буду более жестким, не настолько «командным», чтобы взять «расширение задачи» с голоса. Более того, при повторных расширениях задач, я сразу буду поднимать вопрос качества постановки задачи.
Более того, очень вероятно, что за проект такого типа я больше браться не буду :)

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

:)

Это лишнее.

Мотив создания этого топика описан здесь:
в этом моем ответе dou.ua/...orums/topic/18272/#971785

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
Нет. Это не работа руководства разбираться, что там должно входить в рамки конкретной задачи, а что — нет. Для этого ПМа и наняли, чтобы он разбирался. Раз ПМ решил так — значит он так считает будет лучше. К руководству стоит обращаться, когда деятельность ПМа прямо приводит к потере качества/производительности на проекте и вы можете это показать на пальцах с конкретными цифрами, а не просто лить воду и делиться эмоциями.
Как правильно показать некомпетенстность ПМа в приемке работы?
Для начале научиться правильно формулировать вопросы: показать кому и для чего?
Показывать самому ПМу бесполезно, если только он сам не просит у вас фидбек — только наживете себе врага. Показывать другим разработчикам — они сами должны все видеть, если есть что видеть. Показывать руководству — руководство не интересует детали приемки отдельных задач, т.к. для этого и наняли ПМа чтобы у него голова болела по организации этого и других процессов. У руководства другие метрики оценки компететности ПМа, чем у вас.
Допустим вам удалось доказать некомпетентность ПМа всем, кому вы хотели доказать, что дальше? Какой результат вы рассчитываете в результате получить, и почему так уверены, что не можете получить этот результат без доказательства некомпетентности ПМа? Вы считаете, что руководство будет учить ПМа делать его работу? Нет, не будет. Уволит ПМа и заменит на другого — не факт, что новым вы будете довольны больше, совсем не факт...
Как пресекать самодеятельность такого ПМа?
Что вы подразумеваете под «самодеятельность»? ПМа наняли ставить процессы на проекте — он их ставит как считает нужным. «Самодеятельность» — это если бы ПМ принимал решения по технической архитектуре проекта или нарушал полиси компании(в отношении овертаймов, к примеру) по своей прихоти. Изменения же процесса работы на проекте — это в компетенции ПМа и не зависимо от того, согласны вы с этим или нет, «самодеятельностью» это точно не является.
Как бы Вы «строили работу» с таким ПМом?
Зависит от того, как это влияет на мою работу, как разработчика, и на проект в целом.
1) Если есть места, которые можно, по моему мнению, улучшить — начал бы разговор с ПМом на эту тему, чтобы либо изменить что-то к лучшему, либо понять, почему лучше оставить как есть.
2) Если в результате 1) становится понятно, что улучшения нужны, но их не будет из-за «человеческого фактора» и дальнейшие разговоры с ПМом не имеют смысла — попутился бы донести руководству ситуацию на преокте с конкретными цифрами и объяснением, какие проблемы могут быть. Руководство очень хорошо понимает, когда с ним говоришь на языке конкретных цифр, которые можно легко конвертировать в величину денежных потерь.
3) Не зависимо от результатов 1) и 2) смотрел бы по личному желанию оставаться в проекте или уходить из него.
4) Зная, что у ПМа всегда есть какие-то «хотелки» во время приема задач, добавил бы сразу +10-20% ко времени при оценке задач.
Как можно сохранить свою репутацию в таком «окружении»?
Никак: «Я не могу дать вам формулу успеха, но готов предложить формулу неудачи: попробуйте всем понравиться.» © Джерард Своуп
Если ПМ ударился в микроменеджмент с горой баг-тикетов, а руководство приняло решение об увольнении только на основании числа баг-тикетов, не поинтересовавшить в причине их возникновения и не спросив мнение о ситуации самого разрабочика.... то пытаться тут что-то доказывть — это как метать бисер перед свиньями.
---------------------------
ПС: Мне лично кажется, что ситуация описана слишко однобоко и есть много моментов, которые вызывают дополнительные вопросы:
1) Не понятно, с какой целью ПМ ударился в микроменеджмент с принятием задач лично через скрин-шаринг. Это более напряжно и затратно, чем если посмотреть самому в удобное время и потом дернуть разработчика сообщить фидбек голосом, если есть необходимость.
2) Из 1) — если разработчиков на проекте несколько, а микроменеджить начали только избранных — тут скорее что-то связанное с самими разработчиками.
3) Если речь идет о портировании проекта, значит впринципе этот функционал уже написан и работает. Врядли там так уж много глобальных изменений — иначе это уже не портирование и переделка проекта. Соответственно непонятно, откуда ПМ умудряется постоянно брать эти «хотелки»: основной функционал уже определен, а синьерный разработчик с нормальным requirements gathering навыком большинство неоднозначных моментов сможет прояснить и закрыть на этапе уточнения требований по задаче. Без конкретных примеров судить невозможно, но равнозначным остается вариант, что разработчик мог поверхностно подходить к уточнению требований, по принципу «я примерно понял что нужно, сделаю как понял, если что потом скажут что доделать». Это вторая сторона медали, которая не исключает наличия первой, но может привести к точно такой ситуации, как была описана.
4) Очень странная поспешность увольнения. То, что за последний месяц «много багов в джире» — это не показатель для принятия кардинального решения. Вот так вот с ходу, не интересуясь причинами у самого разработчика? Слишком не типично. На место уволенного нужно кого-то нанимать, потом обучать и вводить его в проект и все равно нет 100% гарантий, что не получатся те же грабли или хуже. Так ради чего создавать самим себе лишние трудности поспешным увольнением? Тут на вскидку могут быть 3 варианта:
а) Разработчика так или иначе планировали уволить, просто подвернулся повод уволить по такой причине.
б) На самом деле причина не только в числе багов за последний, но были и другие притенизии к качеству/скорости работы, которые тут не озвучены. Не зная картины с точки зрения ПМа и руководства судить не получится, но в большинстве «типичных» конфликтных ситуаций между ПМами и разработчиками все бывает не так односторонне, как тут было описано (хотя справедливости ради стоит признать, что и именно так односторонне тоже бывает, но это уже не типичный кейс)
в) Таки имеем случай «самодурства», что может иногда встретиться в маленькой молодой конторе с нетехническим руководством, когда вместо того, чтобы разбираться с проблемами и вникать их просто назначают виновного и рубят с плеча. В таком случае нет смысла расстраиваться и беспокоиться и «репутации», т.к. хороший специалист без труда сейчас может устроиться в другую контору, где такого самодурства уже не будет.

Благодарю за подробный коммент.
Добавил некоторые уточнения.

Нет. Это не работа руководства разбираться, что там должно входить в рамки конкретной задачи, а что — нет. Для этого ПМа и наняли, чтобы он разбирался. Раз ПМ решил так — значит он так считает будет лучше. К руководству стоит обращаться, когда деятельность ПМа прямо приводит к потере качества/производительности на проекте и вы можете это показать на пальцах с конкретными цифрами, а не просто лить воду и делиться эмоциями.

Знаете ли, по задачам предоставляются эстименты. И когда на задачу 1,5-2 дня «уходит» 5 дней из-за «добавок», это уже слишком. Поэтому, если добавляется еще 25 бантиков, то мне как разработчику нужно это зафиксировать и обратить внимание руководства до того момента, как оно меня спросит о причине овертайма.

Мой вопрос и состоит в том как это лучше всего/принято делать:
1. Сразу письмо с копией на Пма и тимлида, +(?)СТО
2. Письмо ПМу для фиксации договоренности

Более того, я тоже хочу планировать свою работу. Хотя бы для того, чтобы уходить домой в 18 часов, а не сидеть как дурень до 19/20 чтобы еще за «5 минут» добавить фичу и завтра начать новый тикет. А завтра день начинается с нового бантика :)

С таким раскладом (если бы я знал последствия своей доброты для выхода релиза в срок), я мог выключить ящик в 18 часов, доделать бантик завтра, получить новый и не отлизывать каждый раз код на чистовик, ибо я понимаю, что сейчас будет снова «бантик».

Для начале научиться правильно формулировать вопросы: показать кому и для чего?Показывать самому ПМу бесполезно, если только он сам не просит у вас фидбек — только наживете себе врага. Показывать другим разработчикам — они сами должны все видеть, если есть что видеть. Показывать руководству — руководство не интересует детали приемки отдельных задач, т.к. для этого и наняли ПМа чтобы у него голова болела по организации этого и других процессов. У руководства другие метрики оценки компететности ПМа, чем у вас.
Допустим вам удалось доказать некомпетентность ПМа всем, кому вы хотели доказать, что дальше? Какой результат вы рассчитываете в результате получить, и почему так уверены, что не можете получить этот результат без доказательства некомпетентности ПМа? Вы считаете, что руководство будет учить ПМа делать его работу? Нет, не будет. Уволит ПМа и заменит на другого — не факт, что новым вы будете довольны больше, совсем не факт...

В таком случае буду виноват не я. Начальство будет знать, что это накосячил некомпетентный ПМ. И искать работу будет он :)

Я тоже не хочу на следующем собеседовании бояться вопроса «а почему на этой фирме Вы проработали только 2 месяца» :)

Что вы подразумеваете под «самодеятельность»? ПМа наняли ставить процессы на проекте — он их ставит как считает нужным. «Самодеятельность» — это если бы ПМ принимал решения по технической архитектуре проекта или нарушал полиси компании(в отношении овертаймов, к примеру) по своей прихоти. Изменения же процесса работы на проекте — это в компетенции ПМа и не зависимо от того, согласны вы с этим или нет, «самодеятельностью» это точно не является.

Задача расширяется. Иногда менятеся настолько, что работу за «вчера» нужно удалять. Тим Лид Начинает задавать вопрос: а чем ты там занимался?

Вот мне и нужно каким-то чудом зафиксировать такие изменения. Даже вопреки причинам найма ПМа на этот проект. Понимаете в чем фокус: ПМ делает все правильно, а страдает разработчик.

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

Вот именно ради выяснения таких аргументов я и создавал этот топик. Какие «отмазки» здесь принимаются руководством?

Зная, что у ПМа всегда есть какие-то «хотелки» во время приема задач, добавил бы сразу +10-20% ко времени при оценке задач.

Это решилось добавкой фразы «если не будет расширения задачи»

1) Не понятно, с какой целью ПМ ударился в микроменеджмент с принятием задач лично через скрин-шаринг. Это более напряжно и затратно, чем если посмотреть самому в удобное время и потом дернуть разработчика сообщить фидбек голосом, если есть необходимость.

Объяснение предельно простое.
В какой-то момент я предложил свою помощь ПМу в настройке его макбука. Подключившись по тимвьюеру я обнаружил, что все свободное место на винте у него сожрали «танчики» :) Очень жалею что не сделал скриншот.
Отсутсвие места на его винте и оказалось тем драйвером, который сподвиг его на шаринг экрана моего компа: он не мог скачать новый код из репозитория....

3) Если речь идет о портировании проекта, значит впринципе этот функционал уже написан и работает. Врядли там так уж много глобальных изменений — иначе это уже не портирование и переделка проекта. Соответственно непонятно, откуда ПМ умудряется постоянно брать эти «хотелки»: основной функционал уже определен, а синьерный разработчик с нормальным requirements gathering навыком большинство неоднозначных моментов сможет прояснить и закрыть на этапе уточнения требований по задаче. Без конкретных примеров судить невозможно, но равнозначным остается вариант, что разработчик мог поверхностно подходить к уточнению требований, по принципу «я примерно понял что нужно, сделаю как понял, если что потом скажут что доделать». Это вторая сторона медали, которая не исключает наличия первой, но может привести к точно такой ситуации, как была описана.

«Эталонный» проект идет на 2 недели впереди по разработке и тоже меняется. Вот на этапе создания тикета хотелки в эталонном проекте еще не придуманы, а когда тикет берется в работу «хотелки» «эталонного проекта» только начинают тестироваться другим ПМом. Окончание моей работы по моему тикету совпадают с выкатом новой версии «эталонного» проекта.

а) Разработчика так или иначе планировали уволить, просто подвернулся повод уволить по такой причине.

Очень похоже на правду.

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

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

Как оказалось потом, все эти библиотеки были внедрены по настойчивой рекомендации СТО предыдущим разработчиком.

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

Я не расстраиваюсь. Просто хочется понять для себя как лучше поступить в следующий раз.
Однозначно я будут собирать доказательную базу и со своей стороны: фиксировать расширения задач, смотреть за «эталонным проектом» и брать в работу устаканенные фичи, и т.д.

Выводы сделаны.

Пока я игрался в благородного девелопера, меня смешали с «г...».

Поэтому и возник вопрос:
как можно отстоять свою правоту при самодурстве ПМ-тестера?

Если никак,то я буду просто сваливать на следущий день, после теста на адекватность ПМа :)

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

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

Константин, здесь не стоит вопрос о рефлексии.

В менеджменте есть такой подход «Учим-Лечим-Калечим», он очень хорошо описан в книге «45 татуировок менеджера».

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

Вот суть этого поста и сводится к тому как этот самый второй третий шанс им дать... допустим таки я неправ... но увы я вижу "

Репутация? Простого раба на галере? Я вас умоляю... Вы можете ее даже поджечь и затопить, через месяц все забудут.
" © Artyom Krivokrisenko и "
Нет. Это не работа руководства разбираться, что там должно входить в рамки конкретной задачи, а что — нет. Для этого ПМа и наняли, чтобы он разбирался. Раз ПМ решил так — значит он так считает будет лучше
" © Andrusenko Dmitry Team Leader / Project Manager в DataArt

Также я вижу много лайков под их постами. В любом случае больше чем под моими.

Как бы между прочим, я тоже сертифицированный ПМ с 2006 года и немножко таки понимаю в обсуждаемой теме :)

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

Поэтому к сожалению, прихожу выводу, что второй шанс им не нужен.

Как бы между прочим, я тоже сертифицированный ПМ с 2006 года и немножко таки понимаю в обсуждаемой теме :)

Тот самый случай, когда знаешь как надо, но сделать не можешь :) Знакомо кстати.

Мотив создания этого топика описан здесь:
в этом моем ответе dou.ua/...orums/topic/18272/#971785

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

Мне вот интересно, какие могут быть жесткие способы решения после того как тебя уволили?

Что бы я мог посоветовать на собственном опыте удачном и неудачном:
1. Не попадать в такие ситуации. Понятно, что гарантии дает только гос страх но
— смотри внимательно за тем с кем предстоит работать
— следи за тем, что получается. Если через месяц работы видно, что конструктивного сотртудничества не получается — лучше расстаться по собственной инициативе. Даже в случае если у них все в порядке а это ты чудак на букву М. Не выходит работать вместе — не мучайте себя и других

2. Это стартап? каких сертифицированных ПМ-ов и процессов ты там ждал то?

3. Если вдруг таки работать — то сделать все что бы работа получалась. Не самая правильная работа по тикетам, так как ты это умеешь а просто достижение общего результата.
Скрам там у вас был? А скрам не запрещает брать в работу тикеты в которых не понятно что делать? ПМ пишет не понятные тикеты? Так сделай их понятными. Расспроси его обо всем что надо. Постарайся сделать так, что бы найти максимум его пожеланий с первого раза. Все равно меняются требования? тогда показывай ему свою работу почаще. Договорись о коле каждый вечер, или 2 раза в день и показывай ему что есть, даже недоделанное. Если вечером он накидал тебе рабты на 3 часа — договорись с ним о следующем коле в обед, что бы показать то, что ты доделал. Напряжно? Ну так ты сам выбрал с ними работать. Ты хотел сертифицированных процессов? иди работать в большую корпорацию а не в стартап. Ты сказал, что вы отстаёте от «эталона» (айфона?) на 2 недели, что там дизайн меняется сразу как только ты заканчиваешь работу.. может есть смысл отстать на 3? ну так что бы там дизайн устаканивался к тому моменту как ты будешь браться за работу?

4. Если вдруг что-то идет не так с ПМ — обсуди это с кем-то сразу. Не обязательно «стучать и показывать его некомпетентность» просто попроси совета как тебе быть.

5. Ты тут рассказал что поссорился с ПМ, послал нафиг тимлида, при этом отказавшись брать тикет, и наезжал на дизайнерские решения от СТО. Тебя удивляет, что тебя уволили? А есть ли кто-то с кем ты там не поссорился?

6. Ну и в заключение расскажи о своих «жестких методах»

Мне вот интересно, какие могут быть жесткие способы решения после того как тебя уволили?

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

Поэтому доказательная база не собиралась, до конца не додавливались отвественные лица на ответы.

1. Не попадать в такие ситуации. Понятно, что гарантии дает только гос страх но
— смотри внимательно за тем с кем предстоит работать
— следи за тем, что получается. Если через месяц работы видно, что конструктивного сотртудничества не получается — лучше расстаться по собственной инициативе. Даже в случае если у них все в порядке а это ты чудак на букву М. Не выходит работать вместе — не мучайте себя и других

Вот подножка номер раз, уйти посреди проекта летом :)

2. Это стартап? каких сертифицированных ПМ-ов и процессов ты там ждал то?

Они дейстительно сертифицированные скрам мастера. Даже дипломы у них есть.

3. Если вдруг таки работать — то сделать все что бы работа получалась. Не самая правильная работа по тикетам, так как ты это умеешь а просто достижение общего результата.
Скрам там у вас был? А скрам не запрещает брать в работу тикеты в которых не понятно что делать? ПМ пишет не понятные тикеты? Так сделай их понятными. Расспроси его обо всем что надо. Постарайся сделать так, что бы найти максимум его пожеланий с первого раза. Все равно меняются требования? тогда показывай ему свою работу почаще. Договорись о коле каждый вечер, или 2 раза в день и показывай ему что есть, даже недоделанное. Если вечером он накидал тебе рабты на 3 часа — договорись с ним о следующем коле в обед, что бы показать то, что ты доделал. Напряжно? Ну так ты сам выбрал с ними работать. Ты хотел сертифицированных процессов? иди работать в большую корпорацию а не в стартап. Ты сказал, что вы отстаёте от «эталона» (айфона?) на 2 недели, что там дизайн меняется сразу как только ты заканчиваешь работу.. может есть смысл отстать на 3? ну так что бы там дизайн устаканивался к тому моменту как ты будешь браться за работу?

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

4. Если вдруг что-то идет не так с ПМ — обсуди это с кем-то сразу. Не обязательно «стучать и показывать его некомпетентность» просто попроси совета как тебе быть.

Не самая эффективная техника. Приводит к «падлянкам по тихому» с другой стороны.
Значительно уступает комплейну, когда вскрываются проблемные куски.

5. Ты тут рассказал что поссорился с ПМ, послал нафиг тимлида, при этом отказавшись брать тикет, и наезжал на дизайнерские решения от СТО. Тебя удивляет, что тебя уволили? А есть ли кто-то с кем ты там не поссорился?

Это уже результат на третьей-четвертой неделе, когда запас любви/терпения кончился.
Сколько можно терпеть чужую дурь? Тебе ставят правила, и тебе же толкают на их нарушение? Где логика?

6. Ну и в заключение расскажи о своих «жестких методах»

А все предельно просто.

Собственно софтверная фирма без СЕО и СТО может проработать, а вот без разработчиков никак :(

Вариантов масса:
1. Свалить сразу же. Более того можно еще с подарком — не выходить на связь пару дней, пусть понервничают. Или наоборот выходить на связь и обещать завтра выйти на работу. Завтра снова просить о завтра. Как результат проект буксует.
2. Поступить подло — запороть проект. Как правило в 40% случаев тим лид реальный лох в ряде технологий как и СТО. Некоторые нюансы он/они могут не знать. При правильно построенной работе разработчик это выясняет через 1-2 недели + чтение кода на откровенные ляпы, иногда даже архитектурные. Как правило каша в голове = каша в решении = каша в коде. Задвоить переменную, с дальнейшим переопределением или небольшой штришок в логику приложения... И самое главное выглядит оно случайно: я а думал, но не учел. В каждом проекте есть реальные узкие места, которые понимает один — два человека.
3. Публично «унизить» при команде. Не нужно обкладыватьего матом, упаси Боже. Сделать это нужно деликатно, дать запутаться. Показать, где он чего не знает. Сначала хвалить его решение, зная что оно фейловое, а потом через 2 недели показать где оно валится, снова таки при всех, а еще лучше если парниша за соседним столом будет матюкаться на это решение. А потом случайно вспомнить «А это же его решение. Вот он лошара!» или «Мне набо было таки громче кричать о своем варианте».
4. Можно задать кривые параметры сторонних библиотек либо использовать глючащие режимы используемых версий этих же библиотек. Как правило любители быдлокодинга свято верят в мощь сторонних библиотек. И используют их вместо средств продеставлемых средой.
5. Можно наоборот, сделать менее гибкие настройки своих кастомных решений.
6. Делать кастомные решения в уникальных сферах, в которых никто в команде больше не разбирается.

Это так слету :)

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

Все зависит от того, насколько есть настроение «пошалить» :)

Решил, что раз я новенький, то наверное многого не понимаю

А даже если ты новенький и многое понимеш многое ты вообще можеш изменить? Я был в похожей ситуации, видле что сыпеться и что плохо, но ничего с этим поделать не мог.

Они дейстительно сертифицированные скрам мастера. Даже дипломы у них есть.
Слушай, ну давай мухи отдельно а котлеты отдельно. Сертифицированный скрам мастер и проджект менеджер сертифицированный по каким нибудь ISO и CMMI это ведь разные вещи... хотя фейлят конечно и те и другие. Сертифицированного скрам мастера дают за участие в 2-х дневном семинаре + 100 уе взноса с носа + формальный экзамен. В Украине, не думаю что у вас все сильно по другому.
Все зависит от того, насколько есть настроение «пошалить» :)
Слушай, ну тебя же вовремя распознали и уволили, до того как ты начал шалить, это ж мудрое управленческое решение :)

С точки зрения нанести вред эти вещи реально еффективны, вот только какой твой выигрыш в этом?

А даже если ты новенький и многое понимеш многое ты вообще можеш изменить? Я был в похожей ситуации, видле что сыпеться и что плохо, но ничего с этим поделать не мог.

Нет идеальных ситуаций. С возрастом понимешь, что либо ищешь идеал сам, либо идешь на компромис: вин-вин.

В данном случае в меня вин-вин не получился :)

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

На самом деле, они меня не раскусили.

С точки зрения нанести вред эти вещи реально еффективны, вот только какой твой выигрыш в этом?

Чтобы навсегда меня запомнили :)

«Раскусили, пошалить, публично наказать, парниша матюкаться, чтобы запомнили» — батенька, да это какая-то сплошная эмоциональная нестабильность. Такое ощущение, что тебя не интересует спокойное профессиональное решение проблемы, а вендетта. Даже название темы намекает.

Такое поведение — не профессионально и не этично, будь даже твой ПМ сто раз не прав.

Ты сам прописал себе черную метку для любого адекватного работодателя прочитавшего эту тему. Никому не нужны неуравновешенные неадекваты.

«Раскусили, пошалить, публично наказать, парниша матюкаться, чтобы запомнили» — батенька, да это какая-то сплошная эмоциональная нестабильность. Такое ощущение, что тебя не интересует спокойное профессиональное решение проблемы, а вендетта. Даже название темы намекает.

Как это не профессионально? Сам сталкивался с таким не раз и мне так делали, и такие проекты мне заходили, где находил закладки.

Как там в песне поется «умные мальчики ставят капканчики» :)

Есть такие варианты:
1. «Схавать» — как говорится не удивляйтесь потом, отношению к себе.
2. Получить зарплату и уйти — тупо и очевидно. Правда в зеркало может быть будет противно на себя смотреть, что пришлось впитывать.
3. Можно отыграться — была бы написанная спецификация + тестер был бы специалистом — гадодейство не прошло бы => сами себя переиграли
4. Попробовал поговорить — проиграл — собственно в этом топике с делаю работу над ошибками. Благо, сегодня начали появляться конструктивные посты.

Такое поведение — не профессионально и не этично, будь даже твой ПМ сто раз не прав.

Знаете, с хорошим людям такое не делают.

А если коллектив «дружный» против кого-то, ну выходите на субботник с вокрестником :)


Ты сам прописал себе черную метку для любого адекватного работодателя прочитавшего эту тему. Никому не нужны неуравновешенные неадекваты.

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

Кто-то готов терпеть, кто-то не готов, это личный выбор каждого :)

Чёрный список шалунов с волчьим билетом на всю жизнь ;) Фриланс и девичья фамилия!

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

Но недостаточно, видимо, чтобы понимать, что ваша оценка никого не интересует в данном случае. Вы не проджект, не тим лид, и не эти «некоторые другие». И тем более не консалтер со стороны, которого наняли чтобы оценить качество пиэма, тим лида и некоторых других.

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

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

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

Вопрос же в том и состоит, как правильно озвучить, что правила нарушаются.
На этот счет в треде советов надавали, повторяться смысла не вижу. Другое дело что все это сработает только в том случае, если речь идет действительно о нарушении писанных и неписанных правил, а не отклонении от чьей-то идеальной картины мира. Если ПМ все таски формулирует так, что требования приходится уточнять дополнительно (мой опыт свидетельствует о том, что если речь идет о предметных экспертах, то их требования нужно уточнять в 99,99% случаев) — и всегда так делал, ведь «это работает» потому что исполнитель принял правила игры — вся команда приспособилась с этим работать, и только вас что-то перестало устраивать через 3-4 недели, то ежу же очевидно, чем все закончится.

ПМ может быть в 100500 раз слабее чем вы в этой же роли, но именно он представляет заказчика, который платит деньги. И если в целом и компания-исполнитель устраивает заказчика, и заказчик в целом вполне адекват — платит и сильно мозг не пипчит, то даже если вы будете нотариально заверять все косяки ПМа, то уволят все равно вас. Чтобы форсить клиенту тему о профнепригодности его же пиэма нужны основания посерьезнее, чем неудовлетворенность системой работы одного разработчика (тем более, вообще нанятого чуть ли не месяц назад).

К сожалению, если не получается договориться, то остается только валить и побыстрее :)

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

Как оказалось потом, все эти библиотеки были внедрены по настойчивой рекомендации СТО предыдущим разработчиком.

Это шутка такая, что ли?! Ну вот я CTO. Если бы я посоветовал какую-то библиотеку, а потом ко мне пришли разработчики с крэш-репортами, мне бы уж точно не пришло в голову на них злиться. Либо стали бы вместе искать решение, либо, если проще выкинуть глючную библиотеку и заменить своим кодом — наверное, так бы и поступили.

Это не шутка.

К сожалению многие СТО заняли эту должность потому, что они собственники.

Собственник — это синоним неадекватности или синдрома «короны на голове»?
Если я собственник (на самом деле нет), я автоматически теряю способность признавать свои ошибки?

Вот только пожалуйста не нужно перекручивать мои слова :)

Мои слова

К сожалению многие СТО заняли эту должность потому, что они собственники.

нужно понимать так:
СТО это как-то так ru.wikipedia.org/wiki/CTO

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

Есть много СТО, которые сами себя на эту позицию назначили, потому, что они (со)собственники компании, однако не имеют необходимых для этой позиции знаний и навыков. По моей оценке таких СТО около 40%, с кем мне приходилось общаться.

Такое самоназначение без знаний создает «инфляцию авторитета» для должности.

Не более чем :)

Есть много СТО, которые сами себя на эту позицию назначили, потому, что они (со)собственники компании, однако не имеют необходимых для этой позиции знаний и навыков.

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

О чем я и толкую. Адекватный руководитель обратит на такое внимание и наверное напишет спасибо за бдительность :)

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

Если же этот ПМ «случайно» набрешет с три короба новому работодателю — получит раскрытие всего процесса, с указанием конторы, ФИО ПМ, и конечно же ФИО его шефа — ведь это именно по его поручению и под его руководством такая ситуация сложилась, и некомпетентный ПМ был принят по его блату.

Да, виновен не жираф.

В данном случае оказалось, что для начальства такой способ ведения дел приемлемый :(

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

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

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
Эти дорабокти оплачиваются? Если да, можно проинформировать начальство, в конце концов, вам какая разница куда грести? Весло в руки и вперед
2. Как правильно показать некомпетенстность ПМа в приемке работы?
Вопросы компетентности ПМ — это не ваша задача. Более того, с чего вы взяли, что вы способны оценить компетентность ПМ?
3. Как пресекать самодеятельность такого ПМа?
Если работа оплачивается — никак не пресекать.
Если работа не оплачивается — стучать погонщику на галере. Если ПМ сломал погонщика и он заставляет вас грести бесплатно — прыгать за борт самому, и дальше вплавь
4. Как бы Вы «строили работу» с таким ПМом?
Если доработки оплачиваются — никак бы не строил. Если не оплачиваются — см пункт 3.
5. Как можно сохранить свою репутацию в таком «окружении»?
Репутация? Простого раба на галере? Я вас умоляю... Вы можете ее даже поджечь и затопить, через месяц все забудут.
В общем, если чувак настолько бесполезен на галере, что его выбросили за борт, то возмущаться и делать что-либо бесполезно.

Чувак начал поздно возмущаться.

Эти дорабокти оплачиваются? Если да, можно проинформировать начальство, в конце концов, вам какая разница куда грести? Весло в руки и вперед

Есть такой момент под названием репутация.
Обидно видеть свою статистику одни «баги» не настоящия а напомню по вине недопоставленной задачи ПМом.

Вопросы компетентности ПМ — это не ваша задача. Более того, с чего вы взяли, что вы способны оценить компетентность ПМ?

Когда «плохо пахнет», но не обязательно быть «дегустатором», чтобы сказать чем :)

Под задачу делается решение. Иногда не один день. Из-за «небольшого уточнения», все приходится переделывать, причем замечу не по своей вине.

Если работа оплачивается — никак не пресекать.Если работа не оплачивается — стучать погонщику на галере. Если ПМ сломал погонщика и он заставляет вас грести бесплатно — прыгать за борт самому, и дальше вплавь

Очень странная фраза от коллеги девелопера. Специально посмотрел Ваш профиль, думал Вы ПМ :)

Если доработки оплачиваются — никак бы не строил. Если не оплачиваются — см пункт 3.

Вопрос не в деньгах, вопрос в репутации.
Как говориться «лучше с умным потерять,чем с дураком найти» :)

Репутация? Простого раба на галере? Я вас умоляю... Вы можете ее даже поджечь и затопить, через месяц все забудут.

:)

Давно читаю Ваши комменты, был бы очень удивлен другим Вашим ответом :)

Репутация? Простого раба на галере? Я вас умоляю... Вы можете ее даже поджечь и затопить, через месяц все забудут.
:)
Давно читаю Ваши комменты, был бы очень удивлен другим Вашим ответом :)
Так это чистая правда. В компании вы — «ресурс» и это не скрывается даже. Какая есть репутация у двигателя или стальной заготовки? Работает — хорошо. Плохо работает — заменить.
Как можно быть таким наивным, при этом не будучи джуниором, и верить в репутацию ума не приложу.
Так это чистая правда. В компании вы — «ресурс» и это не скрывается даже. Какая есть репутация у двигателя или стальной заготовки? Работает — хорошо. Плохо работает — заменить. Как можно быть таким наивным, при этом не будучи джуниором, и верить в репутацию ума не приложу.

Не знаю как Вы, но я как-то привык, чтобы со мной считались :)

Ибо глубоко убежден, что это личное дело каждого «Быть ресурсом или не быть ресурсом» :)

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