Почему же. Статья описывает несколько конфликтных кейсов без деталей, и я бы скорее сказал, что она вообще ничего не описывает — ни в одном кейсе нельза сказать по написанному, кого же винить-то.
«Американский пирог» смотрели? Вот это оно, видимо :)
И главное не забыть добавить «все мужыки программисты козлы».Да-да, а то часто забывают.
А как же ЧСВ.Вот это в точку — Вы даже, наверное, не представляете, насколько :)
1. Способность выполнять задачи в сроки хотя бы рядом с пределами собственных оценок
2. Отсутствие повторяемости одних и тех же, известных и объясненных неоднократно, косяков
3. Способность делать мимнимальный research при возникновении технических проблем
4. ... блин думал как-то вкратце выделить главное, ну чую тут еще на полчаса можно разливаться.
Я лучше задам встречный вопрос: а по-Вашему, как-то вообще можно (и вообще, нужно) судить о продуктивности программиста? Не с точки зрения программиста — а вот для менеджера, предложите, как вы себе это видите. Ну кроме конечно вопроса «ну как, ты сегодня продуктивно поработал?» :)
+ клиническая неспособность ужиться в коллективе, было и такое, к счастью едиинично.
Да-да. Вот об этом я и говорю в параллельных комментах :)
Да, согласен, слишком долго позволять новичку (в проекте я имею в виду, а не джуну) вариться в собственном соку, не контроля что и как он делает — в этой детали явный фейл.
Я собственно что хотел сказать. Тут 99% комментов — «менеджеры дураки, программисты правы, PM-ы их недостаточно обхаживают и улавливают их настроения». Но может быть, не все так однозначно, на самом-то деле? Тем более если человек уже не джун, а имеет несколько лет опыта — значит тоже должен был уже научиться чему-то, кроме написания красивых строчек кода?
И в конце концов, во всех этих историях, кто пострадал-то? Дураки-менеджеры, или недопонятые гении-инфанты-программисты?
Ниче, я за двоих осилил :)
Читаю комменты — грустно улыбает. Программист всегда прав, менеджер всегда неправ. Мда. Выступлю адвокатом дьявола (иначе тут это не воспримется :))
Ребят, это сильно долго не продлится. Есть два очень вероятных варианта развития событий. Либо наши славные правители-камикадзе убьют этот бизнес (в числе прочих), и рабочих мест просто не станет — либо нынешняя лавина джунов перейдет из количества в качество (и это — «страховка» на случай несбывания первого варианта) — в обоих случаях маятник на рынке труда качнется в другую сторону, и всем кто считает себя пупом земли, придется слегка попуститься в своем мировоззрении. А тракторов на всех не хватит, не питайте иллюзий. На Западе рынок тоже не резиновый, и чем ближе к насыщению, тем менее привлекательным для нашего брата он будет становиться. И это только кажется, что с годами будет легко перестроиться и начать смотреть на жизнь иначе — а без этого можно вдруг, внезапно и неожиданно, есть риск оказаться на обочине никому не нужным «непризнанным гением, которого почему-то все недооценивают»...
Конкретно по пунктам.
Случай 1.
Слишком мало деталей, чтоб судить кто прав, и упущена самая главная. А именно, что же все-таки ему было сказано на собеседовании, когда описывалось чем он должен будет заниматься?
оказалось, что этот программист полагал, что его наняли на рефакторинг проекта и внедрение лучших практик.Программист так полагал, потому что ему так сказали на собеседовании — его задача будет рефакторить и внедрять практики, и больше ничего? На свое усмотрение, как он сам считает лучшим? Тогда упорно делать то что хочется а не то что сказано в поставленной задаче — это, возможно, один из способов коммуникации, в расчете на мудрость менеджера и его навыки психолога-воспитателя, который таким образом должен понять, что загружает человека не той работой которая ему была обещана, и человек недоволен...
Хотя немножко умнее было бы сделать задачу, но сказать менеджеру что вообще-то он слегка не таких задач ожидал, исходя из того что ему говорили на собеседовании и что он читал в профиле вакансии. А если несвойственные задачи повторяются, а профильных всё нет и нет, только расплывчатые обещания «когда-нибудь» — ну так испытательный срок — он обычно в обе стороны, надо просто уходить.
В таком случае конечно же очевидно, что человеку рассказали интересные сказки чтоб завлечь, а использовать его как было рассказано — никто не собирается. Надо уходить, не дожидаясь уволения (а оно последует обязательно, при такой политике как описано в кейсе). Либо надо подстраиваться и делать то что вменяется — если такой поворот устраивает (ну прочие условия слишком хороши, например, чтобы свалить самому).
С другой стороны, прежде чем начинать рефакторить, внедрять и переделывать, нужно в проект вникнуть. Зачастую выполнение небольших рутинных задач на первом этапе — один из неплохих способов для этого. Ну и несколько месяцев (кстати, «несколько» это сколько? 2? 3? 5? 10?), прежде чем позволить человеку вносить принципиальные изменения (тем более на свое усмотрение, ни с кем не согласовывая), в зависимости от масштаба проекта (об этом тоже ни слова) — это вполне нормально. Если человек этого не понимает — значит он не дорос до «рефакторинга и внедрения лучших практик», даже если он наизусть декламирует все талмуды от гуру рефакторинга и энциклопедически помнит все API всех фрейморков.
Ну и да, понимать что бинезс-потребности не всегда равнонаправлены с тягой к перфекционизму — тоже совсем нелишне.
В противном случае (это я к началу, о том что человеку рассказывалось при приеме на работу), это идиотизм программиста и ничего более. Хоть он семи пядей в науке кодирования и знает все-все модные фреймоврки — нахрен такого работника, который считает себя самым умным и лучше всех знающим, что нужно для проекта (тем более, если не он его начинал и подключается на поздних стадиях!), и тупо игнорит задачи, которые ему ставит руководство. Вместо того, чтобы хотя бы их обсудить, прежде чем делать не то что его попросили.
Случай 2.
а) Всё-таки, причина увольнения была — вот один раз отказался ночью бежать исправлять — и давай до свиданья — или перманентные косяки, которые известны но не исправляются (а отказ исправить свой косяк вечером — последняя капля)? Сколько времени человек был осведомлен о своем косяке и не желал (или не мог) его исправить, зная дедлайн? Это всё важные детали, на самом же деле.
б) Опять же, при приеме на работу, человек был осведомлен об овертаймах, рашах, ненормированном рабочем дне? Вознаграждение достаточно для него для таких условий? Обоюдное согласие было при достаточной информированности?
Без ответов на оба вопроса, пытаться вынести суждение — глупость.
Случай 3.
Рискую быть нудным, но снова: информации маловато. Из той пары фраз которой описан случай — вполне возможно, что тут ошибка менеджмента. Опять же, вопросы без которых трудно судить:
а) Каков объем кода написан, насколько продвинут проект, на момент возникновения ситуации? Условно говоря, человек сделал рисёч и прототип — или человек дошел до первой рабочей версии?
б) Человека не пробовали выдвинуть на лид-позиции, при расширении команды? Вплоть до PM, но вообще гармонично говорить об архитекте? Или к нему просто добавили исполнителей в горизонталь и поставили ими управлять кого-то, до того не имевшего отношения к проекту? В таком случае, разумеется, описанное поведение неизбежно, если человек не полный пофигист без амбиций — а его менеджер просто дурак.
Эти вопросы взаимосвязаны, на самом деле — в зависимости от ответов на первые по порядку, закономерны те или иные из следующих.
Ну по остальным всколь упомянутым, вообще нечего сказать, и всё по той же причине. Каждый из упомянутых кейсов, каждым читателем натягивается на свой опыт (или свои представления), при этом, конечно же, исходя из этого дорисовывается полная картина, деталями которые в описании кейса не существуют. В итоге делается суждение, которое не основано ни на чем, кроме собственной фантазии :)
Иное это то что ваши цифры верны с точностью до наоборот. А правда, возможно — где-то посередине — ни ни я ни вы не можете это сказать сколько-нибудь определенно, потому что наши выборки не репрезентативны.
Ну а мой личный опыт говорит иное. Вот такая незадача...
американские в 20%.То вы, кстати, с французскими не работали.
здесь связь внунаправленнаяА?
1y Materialise/R&D center(~80), 1.5y Epam/Barclays(~500), 3y GL/BMC(~150) — я знаю о чём говорю.Ну разумеется, а я из пальца на диване высасываю.
Мое мнение основывается на данных из первоисточников.А мое с потолка.
О, снова статистика :) Один раз на вопрос об источнике и репрезентативности выборки меня высмеяли, мол я не умею в гугле строить запросы с несколькими уровнями вложенности. Куда сейчас отправите? :)
Да, не повезло вам в жизни с манагерами. А может, они и правда все такие? Наверное, там такой специальный отбор существует — на манагеров выдвигают всегда только идиотов.
Скажем так, связь затраты-результат в аутсорсе ниже чем в продуктовой компании.А точно не наоборот? :)
Аутсорс — выдали рейт, разработали, отдали, ну может следующая версия и\или поддержка.Это если компания делает на потоке мелкие проекты для кучи сменяющих друг друга клиентов.
Соответственно, в контексте статьи, при такой модели у вас нет большого финансового плеча, чтобы мотивировать команду — опционы например.Всё зависит, и не одними только опционами ограничиваются возможности мотивации.
Ну и строчка в резюме — участвовал в разработке убер-мега продукта (как аутсорсер), тоже слегка блекнет по сравнению с перманентными сотрудниками компании для которой и разрабатывали продукт.Чепуха.
Да-да, ужасный подход. Надо всегда всё делать только на самой новейшей и моднейшей технологии, а если вдруг в процессе разработки появилась еще более новейшая и моднейшая — не откладывая начинать переписывать всё на ней. И разработчиков из прошлого века увольнять не раздумывая (лучше всего ввести возрастной ценз, скажем лет 30, а лучше 27 — а то после этого способность обучаться новому резко падает). Набирать людей не по критерию интеллекта и/или опыта, способности работать в команде и т.п., а по критерию жажды изучать и применять всё новое. Задачи между разработчиками распределять исключительно по критерию того, как конкретная задача поможет изучить что-то новое конкретному девелоперу. Ни в коем случае не позволяйте мыслям о продуктивности, сроках, качестве и надежности кода, и эффективности работы, закрадываться и сбивать вас с правильного пути! Тогда и только тогда, ваша компания/команда будет процветающей, разработчики буду мечтать в нее попасть (а те кто есть — дорожить своим местом как ничем в жизни), а на улице всегда будет стоять очередь из жаждущих с вами сотрудничать клиентов!
Описанные пункты — очень характерны для аутсорс\аутстаф моделей, где связи затраты — результат почти нетХм. Ну за аутстаф судить не могу, а в аутсорсе — Вы точно уверены в этом тезисе?
Отличный подход для ни от кого не зависящего (в том числе и финансово) фрилансера, имеющиего пул ждущих своего шанса обратиться заказчиков с небольшими задачками на одного человека.
А в команде, на серьезном проекте, не пробовали применять такой подход?
И это будет глупостью. Почему — в параллельных комментах я уже порасписал.