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

Именно.

Кто захочет, может сделать выводы

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

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

Да-да, а то часто забывают.
Вот «все менеджеры — козлы» — никто не забывает, тут всё четко :)

А как же ЧСВ.

Вот это в точку — Вы даже, наверное, не представляете, насколько :)

1. Способность выполнять задачи в сроки хотя бы рядом с пределами собственных оценок
2. Отсутствие повторяемости одних и тех же, известных и объясненных неоднократно, косяков
3. Способность делать мимнимальный research при возникновении технических проблем
4. ... блин думал как-то вкратце выделить главное, ну чую тут еще на полчаса можно разливаться.

Я лучше задам встречный вопрос: а по-Вашему, как-то вообще можно (и вообще, нужно) судить о продуктивности программиста? Не с точки зрения программиста — а вот для менеджера, предложите, как вы себе это видите. Ну кроме конечно вопроса «ну как, ты сегодня продуктивно поработал?» :)

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

Я собственно что хотел сказать. Тут 99% комментов — «менеджеры дураки, программисты правы, PM-ы их недостаточно обхаживают и улавливают их настроения». Но может быть, не все так однозначно, на самом-то деле? Тем более если человек уже не джун, а имеет несколько лет опыта — значит тоже должен был уже научиться чему-то, кроме написания красивых строчек кода?

И в конце концов, во всех этих историях, кто пострадал-то? Дураки-менеджеры, или недопонятые гении-инфанты-программисты?

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

Ребят, это сильно долго не продлится. Есть два очень вероятных варианта развития событий. Либо наши славные правители-камикадзе убьют этот бизнес (в числе прочих), и рабочих мест просто не станет — либо нынешняя лавина джунов перейдет из количества в качество (и это — «страховка» на случай несбывания первого варианта) — в обоих случаях маятник на рынке труда качнется в другую сторону, и всем кто считает себя пупом земли, придется слегка попуститься в своем мировоззрении. А тракторов на всех не хватит, не питайте иллюзий. На Западе рынок тоже не резиновый, и чем ближе к насыщению, тем менее привлекательным для нашего брата он будет становиться. И это только кажется, что с годами будет легко перестроиться и начать смотреть на жизнь иначе — а без этого можно вдруг, внезапно и неожиданно, есть риск оказаться на обочине никому не нужным «непризнанным гением, которого почему-то все недооценивают»...

Конкретно по пунктам.

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

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

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

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

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

С другой стороны, прежде чем начинать рефакторить, внедрять и переделывать, нужно в проект вникнуть. Зачастую выполнение небольших рутинных задач на первом этапе — один из неплохих способов для этого. Ну и несколько месяцев (кстати, «несколько» это сколько? 2? 3? 5? 10?), прежде чем позволить человеку вносить принципиальные изменения (тем более на свое усмотрение, ни с кем не согласовывая), в зависимости от масштаба проекта (об этом тоже ни слова) — это вполне нормально. Если человек этого не понимает — значит он не дорос до «рефакторинга и внедрения лучших практик», даже если он наизусть декламирует все талмуды от гуру рефакторинга и энциклопедически помнит все API всех фрейморков.
Ну и да, понимать что бинезс-потребности не всегда равнонаправлены с тягой к перфекционизму — тоже совсем нелишне.

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

Случай 2.
а) Всё-таки, причина увольнения была — вот один раз отказался ночью бежать исправлять — и давай до свиданья — или перманентные косяки, которые известны но не исправляются (а отказ исправить свой косяк вечером — последняя капля)? Сколько времени человек был осведомлен о своем косяке и не желал (или не мог) его исправить, зная дедлайн? Это всё важные детали, на самом же деле.

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

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

Случай 3.
Рискую быть нудным, но снова: информации маловато. Из той пары фраз которой описан случай — вполне возможно, что тут ошибка менеджмента. Опять же, вопросы без которых трудно судить:
а) Каков объем кода написан, насколько продвинут проект, на момент возникновения ситуации? Условно говоря, человек сделал рисёч и прототип — или человек дошел до первой рабочей версии?
б) Человека не пробовали выдвинуть на лид-позиции, при расширении команды? Вплоть до PM, но вообще гармонично говорить об архитекте? Или к нему просто добавили исполнителей в горизонталь и поставили ими управлять кого-то, до того не имевшего отношения к проекту? В таком случае, разумеется, описанное поведение неизбежно, если человек не полный пофигист без амбиций — а его менеджер просто дурак.
Эти вопросы взаимосвязаны, на самом деле — в зависимости от ответов на первые по порядку, закономерны те или иные из следующих.

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

американские в 20%.

То вы, кстати, с французскими не работали.
3 из 3 проектов вытащены исключительно благодаря наличию здесь своего PM, работавшего прокладкой и нивелировавшего их идиотизм. Но там и проекты были маленькие, по паре человеколет.

здесь связь внунаправленная

А?
Што. ©

1y Materialise/R&D center(~80), 1.5y Epam/Barclays(~500), 3y GL/BMC(~150) — я знаю о чём говорю.

Ну разумеется, а я из пальца на диване высасываю.

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

А мое с потолка.

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

А точно не наоборот? :)

Аутсорс — выдали рейт, разработали, отдали, ну может следующая версия и\или поддержка.

Это если компания делает на потоке мелкие проекты для кучи сменяющих друг друга клиентов.
А если в работе 3-4 проекта на много десятков человеколет с устоявшимися командами — картина немножко другая.

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

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

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

Чепуха.

Описанные пункты — очень характерны для аутсорс\аутстаф моделей, где связи затраты — результат почти нет

Хм. Ну за аутстаф судить не могу, а в аутсорсе — Вы точно уверены в этом тезисе?