29.11.2018 14:42
m1rko 167 44000 Источник


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

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

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.

Ниже приведены проблемные личности среди разработчиков программного обеспечения:


Примадонна


Разработчик настолько убеждён в своей незаменимости, что становится высокомерным и им невозможно руководить.


Проблема


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

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

Определить примадонну можно по типичным фразам:

  • «Это глупо — я не буду делать это таким образом»
  • «Мы должны делать это вот так»
  • «Если вам не нравится, то можете поговорить с моим менеджером»
  • «Ну, мы ещё посмотрим»
  • «Пойду поговорю с вашим начальником и посмотрим, что он скажет»

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

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

Решение


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

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

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

Единственная надежда примадонны сохранить ощущение статуса — это получить повышение на руководящую должность (см. разработчик типа метящий в менеджеры). Чем лучше его смекалка, тем раньше при появлении замены он попытается это сделать. Однако повышение не рекомендуется, поскольку вы, скорее всего, увидите увольнения разработчиков, за которых отвечает примадонна. Поэтому при отклонении запроса на повышение у него остаётся только два варианта: встать в один ряд с другими разработчиками или уйти. В любом случае, ваша проблема решена.

Идеалист


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


Проблема


Профессия инженера-программиста требует постоянного баланса двух противоположных задач:

  1. Желание принести пользу бизнесу (и получить зарплату).
  2. Желание написать отличный софт (и гордиться).

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

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

Вместо того, чтобы найти компромисс, он сосредоточился на создании идеальной системы. Он считает, что это лучше для бизнеса. Не путайте их с учёными, которые создают нечто «абсолютное» или «классное»: идеалисты искренне считают, что их идеальная система лучше всего подходит для развития компании. Именно из-за непоколебимости этой веры их так трудно исправить.

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

Решение


Резюмируем черты идеалиста:

  • Очень умный, опытный и профессиональный.
  • Искренне считает, что его система лучше для будущего компании.

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

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

Если у вашей компании есть эти три вещи, оставьте идеалиста в покое, пусть делает что хочет. Но если у вас, как и у большинства компаний, нет этих роскошных условий, то появляется реальная проблема, так как почти всё, что вы предпримете, приведёт к катастрофе:

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

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

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

Рок-звезда


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


Проблема


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

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

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

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

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

Решение


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

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

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

Метящий в менеджеры


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


Проблема


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

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

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

Решение


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

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

Захватчик заложников


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


Проблема


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

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

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

Решение


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

Слон в посудной лавке


Разработчик настолько сосредоточенный на завершении работы, что полностью отказывается от любого понятия качества.

  • Может мутировать в солдата
  • Опасен в сочетании с менеджером проекта типа тиран и тестировщиком типа пожарный шланг
  • Возможность исправления: высокая
  • Опасность для проекта: средняя

Проблема


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

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

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

Решение


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

  1. Объявить перерыв на проекте, чтобы дать некоторую передышку. Обычно это делается путём резкого сокращения объёма работ или значительного переноса сроков.
  2. Спокойный период способствует откровенному обсуждению, когда слон в посудной лавке имеет возможность высказать свои обиды.
  3. Сделать анализ первопричин ошибок и исправить их. Не спешите с этим. Убедитесь, что всё исправлено, прежде чем продолжить проект.
  4. Разобраться со всеми случаями выгорания среди разработчиков, заставить их взять внеочередные отпуски. Организации редко это делают, но это очень эффективно.
  5. Когда команда перегруппируется, выполнить комплексную оценку проекта, установить новые объёмы работ и сроки.

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

Некомпетентный


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


Проблема


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

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

  • В своей низкой продуктивности они обвиняют отсутствие корпоративных тренингов.
  • Оспаривают применение «слишком сложных» технологий, инструментов и методов.
  • Сильно переоценивают сроки выполнения работы (см. пессимист), а потом всё равно не сдают её в срок.
  • Выдают функции, не соответствующие спецификациям.
  • Реализованные функции полны ошибок.
  • Опытные разработчики избегают или отказываются работать с ними.
  • Когда их спрашивают о ходе работы, они оправдываются и часто занимают оборонительную позицию.
  • Претендуют на руководящую должность (см. метящий в менеджеры), чтобы приносить «больше пользы».

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

Решение


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

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

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

  1. Разрушение качества кодовой базы, появление нового глючного кода и внедрение багов в рабочий код (см. также слон в посудной лавке)
  2. Они отталкивают компетентных разработчиков, которым надоело работать с ними.

В конечном счёте, если проект зависит от некомпетентного разработчика, то проект не будет выполнен. Это приводит к печальному выводу, что таким работникам нужно покинуть организацию. Если они не соглашаются (обычно после всё более прямых намёков), то их следует уволить.

Оптимист


Разработчик, который постоянно недооценивает количество времени, необходимое для выполнения задачи.

  • Может мутировать в пессимиста
  • Опасен в сочетании с оптимистичным менеджером проектов
  • Возможность исправления: высокая
  • Опасность для проекта: средняя

Проблема


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

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

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

Решение


К счастью, оптимиста можно исправить, соблюдая нескольких правил:

  • Просить их об оценке только для кода, с которым они хорошо знакомы.
  • Просить об оценке только для технологий, с которыми они хорошо знакомы.
  • Никогда не просить оценить сроки реализации новых функций, а только улучшения существующих.
  • Необходимо позаботиться о том, чтобы они полностью понимали все требования — им нельзя свободно интерпретировать требования на лету.
  • Требуйте от оптимиста добавления комментариев «TODO» в тех областях, где им придётся вносить правки. Это усилит зависимость между сложностью программного обеспечения и оценкой сроков.
  • Сделайте их подотчётными: покажите их оценки группе, способной оспорить такие сроки.

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

Во время процесса реабилитации оптимиста обратите пристальное внимание на то, как он соблюдает свои сроки:

  • Страдает ли качество работы от повышенных обязательств (см. слон в посудной лавке). Если так, предложите добавить необходимое время для тестирования.
  • Работают ли они сверхурочно, чтобы соблюсти сроки (см. солдат)? В этом случае предложите добавить время для выполнения работы в рабочие часы, а сверхурочные должны остаться для непредвиденных обстоятельств.

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

Пессимист


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

  • Может мутировать в слона в посудной лавке
  • Опасен в сочетании с таким же пессимистом в качестве менеджера проекта
  • Возможность исправления: низкая
  • Опасность для проекта: нет

Проблема


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

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

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

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

Решение


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

  1. Работа в пессимистическом режиме гораздо менее стрессовая, чем нормальная работа.
  2. Пессимистов обычно вознаграждают и повышают намного чаще тех, кто пропускает важные сроки.
  3. Бизнес должен стать более терпим к опозданию. Когда устоялась определённая культура разработки, большинство компаний не способны на это.

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

Солдат


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

  • Может мутировать в слона в посудной лавке
  • Опасен в сочетании с менеджером проектов типа тиран
  • Возможность исправления: нет
  • Опасность для проекта: низкая

Проблема


С точки зрения менеджера, кто может быть лучше разработчика, который делает в точности то, что сказано? Действительно, ключевая проблема с примадонной заключается в том, что он не выполняет распоряжения. Безусловно, полностью послушный разработчик является благом для проекта. К сожалению, у солдата есть свой недостаток: он послушно прыгнет в пропасть, если ему так скажут, утащив с собой весь проект.

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

Солдаты рождаются несколькими способами:

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

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

Решение


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

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

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

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

Фанат технологий


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


Проблема


Для успешного запуска продукта необходимо выбрать технологию. Это тщательный выбор с вниманием к конкретному набору бизнес-проблем, которые необходимо решить. А фанат технологий просто любит новые игрушки.

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

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

Решение


Фанаты технологий исправляются сами собой, если компания установила стандартный технологический стек. Затем требуется всего лишь следить, чтобы разработчики не отклонялись от него. Если у вас нет установленного стека технологий, настоятельно рекомендуется определить его заранее, так как будет неудобно вводить его после того, как фанат технологий начнёт активничать.

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

Хранитель легаси-кода


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


Проблема


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

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

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

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

Решение


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

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

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

Комментарии (167)


  1. dimoff66
    29.11.2018 18:38
    #19433606
    +3

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


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

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


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

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


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

    PS В остальном очень жизненно. Спасибо. =))


    1. Fracta1L
      30.11.2018 10:02
      #19435396
      +1

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

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

      Каким образом хорошая архитектура и совершенство кода может помешать бизнесу?

      Хорошее — никак, идеальное/совершенное — тем, что на его воплощение требуется чуть менее, чем бесконечное количество времени.


      1. dimoff66
        30.11.2018 14:13
        #19436576
        +1

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


        1. pesh1983
          01.12.2018 00:04
          #19438872

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


    1. glestwid
      30.11.2018 15:08
      #19436824

      Каким образом хорошая архитектура и совершенство кода может помешать бизнесу?


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


      1. dimoff66
        30.11.2018 15:22
        #19436878

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


        1. mandrozz
          30.11.2018 18:38
          #19437874

          Дело не в хорошей или плохой архитектуре, а в том, что человек сделал хорошо, потом подумал, и решил переделать еще лучше, переделал, посмотрел, решил сделать еще лучше. Он будет по 10 раз переписывать код, чтобы найти совершенство, но и тогда не факт, что это будет действительно совершенство.


          1. dimoff66
            30.11.2018 19:11
            #19438008

            Если в статье имеется ввиду именно такой случай, тогда да.


  1. time2rfc
    29.11.2018 18:42
    #19433618
    +13

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


    1. ValeraUff
      30.11.2018 13:34
      #19436406

      У каждого хорошего менеджера в списке прочитанных книг есть парочка про воспитание деней и общение с ними :)


    1. AWSVladimir
      30.11.2018 17:39
      #19437574

      Не расстраивайтесь, очень хорошо что есть такие статьи по «управлению» программистами
      Мне хотелось сразу 3 комментария написать на нее)))
      1. Автор как кот которому нечего делать начинает лизать… изучать программистов.
      2. Это одна из «техник» как нагнуть программиста, и что даже техничка может управлять программистами.
      Кстати про техничку это не шутка, была такая реальная методика и эта бы статья плавно бы вошла туда как отдельная глава )))
      3.БРАВО!!! СУПЕР!!!
      Чем больше будет таких учений, менеджеров которые им следуют, тем больше будет работы для Программистов и выше будут зарплаты!
      Никто не отменял правило озвученное Бруксом несколько десятков лет в его книге «Мифический человеко-месяц».
      Если Владельцу или менеджеру нравится гнобить программистов, тем лучше, стОящий и знающий программист может уйти в другую компанию и строить с нуля новую систему, на крайняк сделать свой стартап, а в компании в которой гнобят (нет нет, конечно же управляю программистами <ха-ха 3 раза>), вместо одного наймут 10, которые в конечном итоге угробят систему или будет стогнация.
      Если менеджерам нужна «игра в управление», а по факту в гнобление с сокращением зарплаты, то еще существуют фирмы, где на первом месте стоит разработка ПО, его качество, отказоустойчивость, расширяемость, гибкое управление проектом, а не программистами. )))
      Первый критерий программиста это его код(!), скорость, профессионализм.
      Потом работа в коллективе (тк программист в одиночку писать высокопроизводительные библиотеки, сервисы), умение работать с несколькими программистами над одним проектом. Придерживание стандартам компании в написании кода и т.д. и т.п.
      В статье озвучиваются ярлыки, но тот кто их навешивает сидит читает спецификацию по выходным? Дебажит сутки на пролет выискивая неточность? Днем и ночью продумывает архитектуру даже в ущерб своему здоровью?
      Тот кто не любит программировать, но идет в программисты за деньгами, не выдержит никакой конкуренции с фанатами-профессионалами. Менеджер просто не в состоянии понять глубину знаний и без программистов он НИКТО! Пустышка с деньгами и огромным самомнением, что за пару тысяч ему будут лизать ботинки. Может в других сферах это так, но не у программистов к которым приходит волшебная палочка выручалочка -Интернет.
      И сейчас все больше и больше команд основное время работает по удаленке.
      Пусть менеджеры эту крысиную возню с ярлыками оставят для себя, написав себе эти ярлыки на бейджиках и приколят их к своей груди. )))
      А мы будем писать код благодарному работодателю или для своего бизнеса, под пальмами у моря или в том месте где душа поет и из под пальцев выходит код который хочется поцеловать.


      1. JuniorIL
        30.11.2018 19:48
        #19438146

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


        1. AWSVladimir
          30.11.2018 19:51
          #19438160

          Да да, я знаю, простая техничка может управлять отделом программистов )))


          1. MiklR
            30.11.2018 21:08
            #19438398

            Фантазии у Вас и обиды. Как правило изобретатель это плохой инженер который во что-то «тупо верит». Их полно сейчас — с двигателями с супер КПД, альтернотивной физикой и пр.


            1. AWSVladimir
              30.11.2018 22:39
              #19438626
              -1

              Да я разве спорю.
              Изобретатель конечно плохой инженер, который «тупо верит»
              ( Блин в мемориз надо этот перл ))) )
              Программист конечно же обычный скот который надо поставить в стойло, что бы не брыкался и зарплату не просил, ярлычок навесить и знать как пнуть больнее.
              Зарплату в вашей конторе не снижают еще «опущенным звездам»?
              Девиз висит «Не заменимых людей нет»?
              «Верной дорогой идете товарищи» (с)
              И я конечно же фантазер и обижаюсь, на кого, на вас?
              Ой рассмешили, только мало. ))))
              Как говорят? «Пиши исчо!»
              Чем больше будут придерживаться менеджеры этой идеологии тем лучше.
              Когда менеджеры сядут в лужу, не прав конечно останется только скот программисты, но пусть на грабли наступают и по чаще, может просветление будет. )))
              Еще Крылов да-авным давно написал басню Квартет, как раз подходит под ваше управление.
              PS:
              Программист, когда ему становится не комфортно может сменить релокацию на любой город или страну не выходя из дома. Люди в команде могут не видеть друг друга годами, но при этом слаженно работать.
              Пусть ваши менеджеры потешат свое ЧСВ ярлыками и методами «опускания звезд», если им не хватает мозгов управлять командой. Так как при разработке ПО другие ярлыки и оценки применяются.
              Так что пилите пишите Шура, пишите.


              1. MiklR
                30.11.2018 22:46
                #19438646

                Это Вы вываливаете свои обидки.
                Я консультант и работаю со многими организациями и да я «вершитель судеб» и таких как Вы и менеджмента, с крайне высоким КПД.
                Незаменимых, действительно нет. Есть стоимость замены.
                Большинство — простые ремесленники, начинающие визжать, когда только достал линейку, для объективных измерений. Устраивающие истерики при увольнении о их незаменимости, а потом отказывающееся забирать трудовую…


                1. AWSVladimir
                  30.11.2018 22:59
                  #19438704

                  Я консультант
                  Я это понял )))

                  Незаменимых, действительно нет. Есть стоимость замены
                  Я про это же.
                  Очень часто «стоимость замены» IT специалиста может не только о-очень больно ударить по карману владельцев бизнеса, но и уничтожить сам бизнес. И бизнес совершенно не относящийся к IT сфере. А у IT бизнеса риски еще выше при смене ключевых специалистов.
                  Кто не наступал на эти грабли, пусть наступает, каску им давать не обязательно )))
                  PS:
                  Из-за не грамотного админа или из-за не протестированного продукта простой в ОДИН день может вылиться в недополучении прибыли в десятки миллионов рублей.
                  2-3 дня таких в год и владельцы, которые умеют считать деньги понимают что принять «супер-звезду» с максимальной зарплатной планкой всегда выгоднее, чем иметь 10 середнячков, которые не в зуб ногой, не в…


                  1. vsb
                    01.12.2018 00:35
                    #19438948
                    +1

                    Звезду может сбить автобус. Выгодней иметь команду взаимозаменяемых винтиков.


                    1. AWSVladimir
                      01.12.2018 01:52
                      #19439094

                      Завтра м/б война, метеорит, ссора учредителей и продажа бизнеса с выкидыванием на улицу всех, включая «эффективных менеджеров».
                      Сегодня важно использовать ресурс который у тебя есть и если у тебя более ценный ресурс, то более эффективно его можно использовать. Новые библиотеки, архитектуру, алгоритмы, все что может «Головастик» ( это мой ярлык Специалиста с большой буквы). Что будет потом, то будет, потом и будем решать проблемы которые будут, а не которые мы придумываем в своей голове. Винтики нужны на конвейере, саппорте продукта, разработке мелких фич, но не на архитектуре проекта и не на ключевых ветках.
                      Ведь информационная разработка и поддержка это ряд методологий и правил сугубо технических. Если для менеджера важен продукт, его качество, расширяемость, поддержка, продвижение — это один порядок правил и методик.
                      Если для менеджера важно как выглядят IT специалисты, их манера речи, распорядок дня, стиль общения, их социальная мотивация то это другой ряд правил и методик, менеджеров которые бит от байта не отличают. Они с этими методиками хороши когда уже есть продукт с «жировой прослойкой» и устоявшаяся команда. Какое то время они будут управлять, могут даже увеличиться продажи, но в конечном итоге они обескровят команду, снизят мотивацию разработчиков и свалят на новое место, а контора за-агнется ибо Специалисты — штучный продукт. И даже высоко классному специалисту нужно время «въехать» во все тонкости существующего продукта. И срок «въезда» идет на месяцы, а ему зарплату все это время платят (возможно больше, чем ушедшему специалисту), а продукт стоит или клепаются только заплатки.
                      Для стартапа, когда надо творить их методика не подойдет, потому что продукт всегда штучный и в нем заложено все понимание главного разработчика (ов), как оно должно быть. И от уровня компетенции основного разработчика напрямую зависит жизнь продукта. Кто будет делать скелет? Команда винтиков или Головастик? Головастик в данном случае предпочтительней с любой стороны, как с финансовой, так и с технической. Да с ними трудно, да тяжело, но выхлоп результата значительно больше чем от винтиков.
                      Вот «эффективному менеджеру/консультанту» дать Х денег и срок, набрать команду, сделать продукт (все циклы силами набранной командой). Что бы он не пришел консультировать как руководить в команду, а пришел создавать ее с нуля. То в его голове что то бы и прояснилось.
                      Но только не подумайте, я не отговариваю от методологии технички с изучением проблемных личностей разработчиков, боже упаси.
                      Наоборот, пусть побольше таких менеджеров будут, после них растет зарплата. Потому что те кто считает деньги, они готовы принять на работу хоть дьявола с чертями, лишь бы увеличился доход.
                      А менеджеры пусть играют в свои крысиные игры )))


              1. FoxCanFly
                01.12.2018 10:25
                #19439496

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


                1. AWSVladimir
                  01.12.2018 12:01
                  #19439708

                  Я рад за ваши «здоровые» фантазии и ваш комплекс удачника )))
                  Если серьезно, то с точки зрения профессионализма есть градации и вы их знаете. Но сравнивать программиста и электриком в офисе просто глупо.
                  Любой мужчина в офисе может поменять розетку или лампочку от директора до дворника. Но посадите этих же мужчин за комп и пусть они сделают по ТЗ продукт. Вот и весь ответ.
                  Есть конечно конторы в которых программисты ремесленники, но в которых написаны тонны кода и применяются типовые решения или на двери табличка «Программист», а по факту за ней работает сисадмин.
                  И если у вас все работает и разрабатывать ничего не надо, я вам открою секрет. Вы можете уволить всех программистов и эффективных менеджеров в куче и забыть про них как страшный сон. )))


                  1. sn00p
                    01.12.2018 15:30
                    #19440168

                    Сравнивать программиста и электрика в офисе можно и нужно.
                    С точки зрения владельца бизнеса и тот, и другой — обычные наемные рабочие.
                    А что — электрик, это только лампочку менять? Про силовые кабели в 6кв что-нибудь слышали? В некоторых офисах разобраться в проводке и сделать так, чтобы все не сгорели, куда сложнее, чем по заранее известным алгоритмам писать программы.
                    Как вы относитесь к другому офисному персоналу? Офис-менеджер, например, либо HR?


                    1. AWSVladimir
                      01.12.2018 17:15
                      #19440420

                      Отвечу почти по Маршаку:
                      Люди разные нужны, Люди разные важны.
                      И хороший HR и хороший электрик, как ген.дир и менеджер проекта ценны сами по себе. Но хороших специалистов к сожалению мало. А хороший специалист, он знает себе цену и не каждый будет терпеть подковерные гнобления.

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


                      1. sn00p
                        01.12.2018 19:52
                        #19440816
                        +1

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


          1. JuniorIL
            01.12.2018 01:32
            #19439050

            Не передёргивать, пожалуйста. Быть воспитателем в детском саду (менеджером) очень непростая задача. Не знаю какие вы задачи решаете, но я не вижу что такого "изобретательного" в том, чтобы дёрнуть за пару АПИ в правильной последовательности. Зато вижу, что надо это протестировать, написать логи и объяснить в документации почему надо дергать за эти два, а не те; что всегда и делали инженеры.


      1. Ben2112
        01.12.2018 10:02
        #19439470

        Ну, наконец-то.
        Автор, спасибо вам душевное за статью.
        Спасибо — по нескольким причинам.
        99% статей о разработчиках в контексте управления можно свести к одному тезису: “Как тяжело жить/решать задачи/доставлять ценность разрабу в условиях постоянно сопровождающих его внешних, отвлекающих факторов”.
        Я, безусловно, чуть-чуть утрирую, но, почему-то, в подавляющем большинстве таких статей суть сводится к тому, как тяжело именно программисту. И задачи, чаще всего, не решаются или решаются с трудом, поскольку все время есть что-то, что отвлекает/не дает работать.
        Причем, во многих из таких статей, как правило, виноват менеджер/бизнес/ или стейкхолдер, не пишущий код, а творящий вокруг себя хаос и разнообразный “микроменеджмент”.
        А между тем, в адрес не-разработчика летят так им любимые “Я это делать не буду!”, “У меня все работает!”, “Ненене, мне пораньше уйти нужно — завтра задачки перетащу в code/review” и еще куча приевшихся, остоездивших фразочек из очередного стикерпака в телеграмме.
        Одним словом — редко можно “проблемные статьи” о самих мастерах кода.
        Это причина, скажем так, лирическая — о наболевшем.
        И, поверьте мне, тут не работают аргументы в стиле “Да это просто чувак с нормальными кодерами работать не умеет, вот и слышит это постоянно”. Не работают т.к. с такими вот фразочками сталкивался далеко не один мой коллега из стана pm’ов, сейлзов, аналитиков и прочего так некоторыми нелюбимого комьюнити “не-программистов”.

        Далее — о комментариях выше.
        Уважаемый, AWSVladimir. Вас послушать/почитать, так это получается что у нас каждый 2й, если не 1й разраб — гений пера и кода, за которым просто очереди стоят и бизнес их носит на руках.

        Менеджер просто не в состоянии понять глубину знаний и без программистов он НИКТО!

        Естественно. Менеджер — это такая смесь интерфейса, вашей личной секретарши-напоминалки и пожаротушителя. Он — ничтожество. Просто потому что код не пишет.
        Можно просто сказать: “Ты — менеджер? Иди пол мой и составляй свои доки, общайся на переговорах! Ты же — из стана бизнеса, подлец!”.
        Вот здорово, правда? Вы же на работу ходите/растите свой бизнес исключительно ради кода, верно? ЗП/прибыль тут максимум на третьем месте.

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

        Позвольте, а кто бегает и улаживает косяки программиста, когда баг на баге? Кто согласовывает переносы срока и новые “подводные камни”, которые не были оговорены разработчиком, что называется, на берегу?
        Конечно, всего не распознаешь заранее и не продумаешь. Так-то оно так. Только вот какая штука:
        1. Обычно за описанное вами и платят деньги. Если речь идет о труде и задачах программиста. Это называется — зарабатывать деньги. Продумывать архитектуру (ой-ой-ой) в ущерб своему здоровью.
        Вы не поверите, но в свой выходной/больничный/день свадьбы/похорон любимого котика руководитель проекта тоже может приходить в офис или, болея, с сизым горлом читать и писать доки, пересогласовывать новые сроки, улаживать тут и там возникающие пожары, просто потому что кто-то из ведущих программистов думал, что подойдет вот такое решение, а оказалось — что это не решение, а говно. А кроме того, там вообще айсберг пилить нужно.
        За эту работу точно также платят деньги, как и вам.
        А еще деньги платят за неудачные дни. Это когда исполнители косячат и нужно что-то порешать, как говорится, in-real-time. Потому что виноват же у нас, прежде всего, не исполнитель. А тот, кто так напланировал и надоговаривался. Просто по той причине, что “ПРОГРАММИСТ-НЕ-СОВЕРШАЕТ-ОШИБОК”.

        … на крайняк сделать свой стартап

        Да, у нас каждый второй — Ричард Хэндрикс с потенциально прорывной идеей и соткой пройденных посевных раундов. Ну вот сейчас, еще чуть-чуть, позвонит по скупе Уоррен Баффет или Юрий Мильнер и скажет: “Дружище! У нас для тебя ярд завалялся! Нам очень нужен очередной notepad! Это просто бомба!”.

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

        Оукеееееей.
        Г-споди, что вам за менеджеры-то попадались.
        Вероятно, вы лучше меня знаете, что любой бизнес — это, прежде всего бизнес. Фундаментальная задача любого бизнеса — каким бы технологичным и легаси-ориентированным (уж простите за каламбур) он бы ни был — прибыль. Это банально, пыльно, пошло и зазорно, но это просто факт. Исходя из этого, в корне неверно полагать, что больше чем к 3-5% компаний в мире есть практически неисчерпаемые ресурсы и космический объем терпения у акционеров/собственников/наемного топа, который может бесконечно переносить выпуск в прод “гениальной архитектуры ради архитектуры”.

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

        Не хочется придираться и занудствовать, но…… откуда такое мнение? Есть пруфы? Все больше и больше по сравнению с чем/когда?
        Я руководствуясь ровно такой же логикой могу утверждать, что еще лет 10-15 и появятся наконец решения, которые позволят создавать функционал движением пальца!
        И нам больше не придется писать бесконечные доки и терпеть этих наглецов, которые понакодили вот-этого-вот-всякого! Просто потому что грядет время святых Цукербринов, которые вернут все на круги своя!

        И, напоследок.
        Вам не приходило в голову, что концепция “Заказчик-администратор/менеджер-исполнитель” существует далеко не первый год ровно по той причине, что не глупа и имеет право на существование?
        Ну….просто так получается, что кто-то занимается решением конкретных задач и использованием технологий, а кто-то — планированием, распределением ресурсов, контролем и результатами производства?
        Форд был не дурак, вероятно. И, возможно, вспоминать это в очередной раз было бы глупо, если бы это не было так актуально по сей день.
        А вас послушать: ежкин кот, разработчик — это самая важная деталь организма под названием “Бизнес”.
        Без фактических исполнителей, естественно, никакое производство, ни один механизм не сдвинется — это факт. Просто не стоит недооценивать и преуменьшать роль тех, кто по стечению обстоятельств не роется в коде.
        А то создается ощущение, что вы — это один из персонажей описанных в статье.


        1. AWSVladimir
          01.12.2018 12:46
          #19439828

          ЕсВам не приходило в голову, что концепция “Заказчик-администратор/менеджер-исполнитель” существует далеко не первый год ровно по той причине, что не глупа и имеет право на существование?

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


  1. g6uru
    29.11.2018 19:11
    #19433728

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


    1. UberSchlag
      30.11.2018 11:39
      #19435778

      Чтобы круг замкнулся в каждой статье этого цикла, описывающей следующий уровень иерархии, надо бы иметь отдельный повторяющийся стереотип персонажа: Доверяющий Стереотипным Описаниям в Управлении Персоналом.


    1. K0styan
      30.11.2018 11:43
      #19435792

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

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

      То есть говорить, что в России все поголовно едят оливье на Новый Год — глупость.
      Говорить, что россияне в НГ делятся на тех, кто ест оливье потому, что нравится, кто ест потому, что традиция, и тех, кто вообще не ест — вполне себе корректно.


      1. balexa
        30.11.2018 12:51
        #19436170
        +2

        Проблема в том, что это деление исскуственно, оно не имеет никакого смысла.

        Все животные делятся на 10 классов:
        1. Животные, принадлежащие императору;
        2. Бальзамированные (чучела);
        3. Прирученные;
        4. Сказочные;
        5. Бездомные собаки;
        6. Неисчислимые (звери);
        7. Нарисованные тонкой кистью верблюжьей шерсти;
        8. Молочные поросята;
        9. Издали кажущиеся нам мухами;
        10. Прочие.


      1. g6uru
        30.11.2018 13:11
        #19436300

        Делить по паттернам поведения тоже не верный подход.


        Все люди делятся на две категории: те, у кого револьвер заряжен, и те, кто копают. Копай.

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


        Все люди делятся на две категории: те, кто мыслит стериотипами, и те, кто умеют думать. Копай.


      1. i0000
        30.11.2018 13:29
        #19436378

        То есть говорить, что в России все поголовно едят оливье на Новый Год — глупость.


        Отчего же? Почти все едят — не поголовно, конечно, но подавляющее большинство-таки едят.

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


        1. Barbaresk
          30.11.2018 13:41
          #19436436

          Подавляющее большинство не может быть подавляющим хотя бы потому, что в России есть большое число тех, у кого Новый год попадает на Рождественский пост.


          1. Skerrigan
            30.11.2018 13:49
            #19436478

            Ну тут уже надо быть занудой и делать уяснения для всех сторон, скажем:
            — большинство, это когда 40% едят оливье, 20% спят в оливье, 10% затрудняются ответить (раз на раз не приходится) и 30% не едят оливье.
            Т.е. логике не будет никакого противоречия, если даже только эти 40% стабильно едят оливье на НГ — все равно получается самая большая группа из прочих остальных.
            Если спросоня я не прав — прошу извинить.


  1. ArsenAbakarov
    29.11.2018 19:41
    #19433826
    +1

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

    Представил робота, впадающего в ступор от логического парадокса =)


  1. HepBo3
    29.11.2018 19:42
    #19433844
    +3

    Некомпетентный
    …
    Возможность исправления: нет

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


    1. andvary
      30.11.2018 13:03
      #19436262

      а вы уверены, что у вас просто синдром?


      1. HepBo3
        30.11.2018 13:11
        #19436296

        Хороший вопрос. Только как бы еще понять, синдром это, или нет. На то он и синдром (или нет?!), чтобы нагонять жути и расшатывать скрепы.


        1. ardentum
          30.11.2018 14:12
          #19436570
          +3

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


  1. vchslv13
    29.11.2018 19:48
    #19433874
    +1

    Так как m1rko не отвечает, продублирую своё сообщение здесь:

    Я думаю, «aspiring manager» в данном случае не «честолюбивый менеджер» (он ещё не менеджер, а разработчик всё же), а «стремящийся стать менеджером» или «метящий в менеджеры».
    Забейте в Google Translate «aspiring» — первое определние слова и пример:
    >«directing one's hopes or ambitions toward becoming a specified type of person.
    >»an aspiring artist""


    1. m1rko Автор
      30.11.2018 09:51
      #19435376

      Да, вы правы, спасибо!


      1. vchslv13
        30.11.2018 14:53
        #19436746

        Не за что, рад был помочь :)


  1. evilgeek
    29.11.2018 20:58
    #19434086
    +1

    Очередь пальцев в небо. Всё зависит от задачи, организации работы и погоды на Марсе.

    Стороны разработчика софта и эксплуатации софта (часто с доработками) требуют совершенно разных подходов. Разный софт требует разных подходов (для примера можно выполнить мысленный эксперимент сравнивая oracle db, поделку на php и 1С). Кроме того, есть вполне актуальный торгуемый софт, чуть более чем полностью состоящий из легаси кода (тот же oracle db).

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

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


  1. BD9
    30.11.2018 01:16
    #19434688

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


    1. MiklR
      30.11.2018 09:50
      #19435370

      Забавная статья. Я хоть и не ITшник но много лет занимаюсь персоналом и НОТ.
      Соглашусь с BD9 — заниматься подобным должен специалист. Только не психолог — их квалификация притча во языцех. Они, скорее, натурфилософы и пишут подобную галиматью.
      Правы в общем то все комментаторы.
      Например «Честолюбивый менеджер», из всего написанного, верно только:

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

      Остальное — неверно, например, это может быть и разочаровавшийся «идеалист», (по этому предложенный пример работы с «идеалистом» спорен — может привести к подобным изменениям).
      А выдавать плохой код (плохо работать)он может из-за исчезновения мотивации. Как из-за смены парадигмы, так и из-за выгорания.
      «Солдатом» становятся многие после 30 — это связанно в основном с некоторыми физиологическими изменениями в человеке и частично с социальными.
      Люди не должны работать сутками — это физиологически не возможно. Резерв по способности к переработкам индивидуален и то же не безграничен. В таких случаях проблема всегда в менеджменте, но в любой отрасли управленцев наказывают не охотно.
      Это не касаясь таких проблем, как «отыгрыш» наказанных на подчинённых.
      Метод внеочередных отпусков неплох, но работает только на уставших людях. На выгоревшем это не работает, с ним, лучше попрощаться.
      Ну и т.д.


      1. ITurchenko
        30.11.2018 11:12
        #19435654
        +1

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

        Поматросить и бросить? Ну такое… оставшаяся команда быстро словит мессендж что ждёт их самих в будущем, когда они сломаются и выгорят.


        1. MiklR
          30.11.2018 11:17
          #19435676

          Выгоревший сотрудник будет портить атмосферу. Т.к. находиться в депрессии, имеет низкую производительность труда и много брака. Если команда полна альтруистов, могут скинуться ему на годовалый отпуск (и это минимум). Никто ж не говорит о том, что его надо «выкинуть». Человеку надо выдать все положенные выплаты по полной. В РФ это 3 мес. з/п + что набежало по отпускным.


          1. ITurchenko
            30.11.2018 11:32
            #19435744

            могут скинуться ему на годовалый отпуск (и это минимум)

            Человеку надо выдать все положенные выплаты по полной. В РФ это 3 мес. з/п + что набежало по отпускным

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


            1. MiklR
              30.11.2018 11:38
              #19435770

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


              1. ITurchenko
                30.11.2018 11:40
                #19435782

                Спасибо за честность.

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


                1. Simplevolk
                  30.11.2018 11:42
                  #19435788
                  +2

                  Это из серии: когда нам от вас что-то надо, что мы команда и вообще уже давно в коммунизме и коллективизме.
                  Когда вам что-то надо (или вы не нужны)- это просто бизнес, ничего личного.


                1. MiklR
                  30.11.2018 11:45
                  #19435804

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


                1. balexa
                  30.11.2018 13:10
                  #19436288

                  Мне не очень понятна ваша позиция. Там где вы работаете нельзя выгореть? Вы уверены?

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


          1. justboris
            30.11.2018 15:29
            #19436916

            В европейских странах есть такое понятие как Саббатикал: https://en.m.wikipedia.org/wiki/Sabbatical


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


            1. fedorez
              30.11.2018 18:24
              #19437786

              В СССР и РФ как минимум до нулевых такое в некоторых профессиях тоже есть/было, правда отпуск этот без содержания. Берут его редко, запасы на год редко у кого есть, но вот мой отец, например, воспользовался и провёл в таком отпуске последний год перед пенсией по выслуге лет. Просто физически работать не мог, выворачивало, классически выгорел.


              1. justboris
                30.11.2018 18:43
                #19437886

                отрадно слышать, что и у нас такое бывает!


            1. alexeykuzmin0
              30.11.2018 21:54
              #19438508

              Обычно все же неоплачиваемый. По крайней мере, в компаниях-гигантах, типа Google.


            1. andvary
              30.11.2018 23:11
              #19438746

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


              1. justboris
                01.12.2018 00:25
                #19438936
                +1

                Значит, либо я не так понял своих знакомых, либо мне что-то напарили.

                Спасибо вам и alexeykuzmin0 за пояснения!


      1. playnet
        30.11.2018 18:45
        #19437896

        А что делать выгоревшим?


        1. MiklR
          30.11.2018 19:44
          #19438128

          Я напишу алгоритм для идеального случая. На практике, конечно по разному.
          При проявлении симптомов сотрудник должен идти/быть направлен к психиатру через психоневролога. Бояться психиатра не надо. Да, вы не псих, но отнюдь не здоровы. Адекватный специалист, как правило ставит на ноги за 6 — 10 сеансов. Редко, когда нужно больше. Как минимум, он должен найти источник.
          Одним из направлений восстановления в любом случае будет длинный отпуск и занятие чем-то совсем другим. Возможно, сменить род деятельности придётся навсегда. Если повезёт, то только место работы.


  1. kagetoki
    30.11.2018 06:59
    #19435018

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

    Вот тут тонкий момент. Большинство людей, управляющих ИТ проектами, на моем опыте с легким сердцем ставят клеймо идеалиста на любом разработчике, которому не насрать на долгосрочную перспективу и который не хочет делать одну и ту же работу 10 раз. У них постоянно "заказчик хочет это вчера" и хоть трава не расти, а когда ты начинаешь объяснять, что кроме краткосрочной выгоды нас ждут тяжелые долгосрочные лишения, ты сразу идеалист и не понимаешь, как делать бизнес по-взрослому.


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


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


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


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


    1. shanlove
      30.11.2018 08:54
      #19435198

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


      1. kagetoki
        30.11.2018 11:17
        #19435674

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


    1. lotse8
      30.11.2018 12:47
      #19436136

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

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


    1. justboris
      30.11.2018 15:39
      #19436956
      +1

      Можно попробовать завоевать доверие менеджмента постепенно. Найти какие-либо easy win улучшения в проекте и попросить на них немного времени. Потом показать результат: «смотрите, как быстро мы запилили фичу X, а все потому, что мы заранее порефакторили вон там».


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


  1. halted
    30.11.2018 09:06
    #19435226
    +1

    Прямо карточную игру на основе таких типов можно сделать


  1. Beshere
    30.11.2018 09:09
    #19435232

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

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


    1. dimoff66
      30.11.2018 10:27
      #19435474

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


    1. abar
      30.11.2018 10:55
      #19435578

      Есть хорошая фраза «Глупо держать тех, кто вами управляет за дураков. Они как минимум не глупее вас».

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


      1. Simplevolk
        30.11.2018 10:58
        #19435590

        Ну да, вот у Мизулиной зарплата в 100 раз больше, значит она в 100 раз умнее меня. Я так считаю.


      1. Beshere
        30.11.2018 11:04
        #19435622

        Хороший вопрос. Размер зарплаты — вполне себе объективный показатель, который легко измерить и легко сравнить. Правда проститутка или наркодиллер примерно сравнимо с программистом зарабатывают, об этом вы видимо не успели подумать.

        Если честно, мне пофиг, кто там умнее-глупее. Главное чтобы эти умственные инвалиды не лезли в вопросы, связанные с проектированием ПО. А они пытаются это делать — вот только из-за этого я этот вопрос обсуждаю вообще. Не хватает чёткого знака — «Дальше умственным инвалидам ходить опасно!».


        1. abar
          30.11.2018 11:35
          #19435756

          Уборщица тоже лезет в вопросы проектирования ПО чтоб вы её за инвалидку считали?

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

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

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


          1. Murat1992
            30.11.2018 14:46
            #19436722

            Мне кажется, речь велась не о том, «что» делать, а о том, «как» делать.


          1. balsoft
            30.11.2018 14:59
            #19436772

            Уборщица тоже лезет в вопросы проектирования ПО чтоб вы её за инвалидку считали?

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


            1. balexa
              30.11.2018 15:14
              #19436844

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


              1. j-ker
                30.11.2018 21:13
                #19438406

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


              1. balsoft
                30.11.2018 22:58
                #19438698

                снобизм

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

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


          1. tandzan
            30.11.2018 17:46
            #19437606

            Я был свидетелем, когда верующая уборщица увидела у программиста на мониторе логотип FreeBSD (чертик с вилами) и начала утверждать, что мы все (программисты) попадем а Ад.


      1. dimoff66
        30.11.2018 11:30
        #19435738

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


        1. Skerrigan
          30.11.2018 11:59
          #19435870

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

          Это моя проф.деформация?

          UPD: Отвечу сразу — да, живется мне порой «ой как не просто».


          1. balexa
            30.11.2018 13:03
            #19436264

            Это моя проф.деформация?


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


            1. Skerrigan
              30.11.2018 13:42
              #19436440

              у них были причины сделать так

              — Намеренное плохое UX в продуктах Atlassian путем принудительного сброса авторизации через N-часов (в разное время по разному, от 12 до 36) (толлерантное описание… но в голове одни маты). Был очень серьезный дискусс между представителями компании и сообществом, в результате которого таки удалось продавить «нашу» позицию. Но стоило это «тонны крови».
              — Критические баги в google-драйвере (систематически)
              — Ну очень плохой скайп

              Это были отсылки к «миру IT-шников». Про «мир простых людей» я просто вообще не могу описывать ситуации — пригорает так сильно, что на луну ненароком улечу.


              1. playnet
                30.11.2018 19:08
                #19437990

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


                1. KevlarBeaver
                  30.11.2018 22:38
                  #19438624

                  и изменения ради галочек

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


                  1. playnet
                    01.12.2018 17:10
                    #19440400

                    в том и дело что часто работает не очень. Но хоть как-то значит нафиг поддержку.
                    habr.com/post/429018


      1. justboris
        30.11.2018 15:46
        #19436980

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


      1. andvary
        30.11.2018 23:18
        #19438768

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


  1. dididididi
    30.11.2018 10:11
    #19435424

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


    1. Trediol
      30.11.2018 10:55
      #19435576

      Вероятно имеется в виду «слишком сложные» технологии для него самого


      1. dididididi
        30.11.2018 13:11
        #19436298

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


        1. Trediol
          30.11.2018 13:41
          #19436434

          Яму можно вырыть лопатой, а можно экскаватором. Полагаю, что первый вариант значительно проще с точки зрения «технологичности». Но что, если яма нужна большого размера? А что, если их нужно N-штук? Или сроки сжаты? В таком случае более простая технология не подойдет.

          А оспаривать более сложную технологию человек может, например, из-за того, что не умеет её готовить.


          1. dididididi
            30.11.2018 16:12
            #19437092

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

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

            Допустим человек может сделать все нативным sql запросом, а ему говорят используй ОРМ. Зачем если он может сделать все быстрее так, это будет работать быстрее и надежней?
            Или он может сделать монолит, а ему говорят: микросервисы и кибернетес и блокчейн.


            1. KevlarBeaver
              30.11.2018 22:36
              #19438620

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


            1. michael_vostrikov
              01.12.2018 12:09
              #19439726

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

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


              я скорее докопался до слова «сложных». Если б было применено слово «эффективные технологии» или «производительные технологии»

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


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

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


              Далее. Нативный SQL-запрос в большинстве случаев гораздо не надежнее при изменениях кода, и часто не быстрее из-за возможности lazy loading в ORM. ORM не в последнюю очередь используют из-за буквы R, маппинга связей между объектами. Это очень упрощает код. Поэтому да, используй ORM.


              1. playnet
                01.12.2018 17:26
                #19440460

                Упрощает код (не всегда) и порой существенно замедляет его. Хотя бонусом обычно идёт безопасность запросов.


          1. Holmax
            30.11.2018 16:48
            #19437260

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


            1. Trediol
              30.11.2018 16:54
              #19437316

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


              1. Holmax
                30.11.2018 17:02
                #19437358

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


              1. dididididi
                30.11.2018 17:14
                #19437430

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

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

                У вас почему-то сложность = производительность. Это отнюдь не так.

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


                1. Trediol
                  30.11.2018 17:22
                  #19437494

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

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


    1. ValeraUff
      30.11.2018 13:34
      #19436414

      Тоже заметил за собой несколько симптомов «некомпетентного» разработчика. Даже задумался, а не я они ли — он? :)


      1. Simplevolk
        30.11.2018 14:06
        #19436546

        Сначала проверьтесь на «синдром самозванца».


      1. dididididi
        30.11.2018 14:45
        #19436720

        Я некомпетентный солдат-оптимист)))


  1. anonymous
    30.11.2018 10:21
    #19435456

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


  1. dmitry-suffi
    30.11.2018 12:00
    #19435878

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

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


    1. lotse8
      30.11.2018 12:53
      #19436188

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


  1. feligz
    30.11.2018 12:05
    #19435898
    -1

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


    1. Skerrigan
      30.11.2018 13:56
      #19436506

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


      1. mapron
        30.11.2018 15:33
        #19436928
        +1

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

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


      1. feligz
        30.11.2018 16:32
        #19437184

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


        1. kagetoki
          30.11.2018 17:45
          #19437596
          +1

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


          • Отказался перерабатывать нахаляву — плохо относится к компании.
          • Не хочет больше подтирать за одним и тем же сотрудником — нет эмпатии/соучастия
          • Требует законный отпуск, хотя просят не уходить — не может войти в положение, выслушать
          • Устал от бесконечных костылей, говорит, что время инкрементального рефакторинга давно упущено, теперь только выбросить и переписать, а продолжать так жить больше нельзя — истерит и закапывается в перфекционизм, не может предложить решение
          • Разработчик объясняет срыв сроков тем, что руководитель проекта постоянно меняет требования в последний момент — не может взять ответственность на себя

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


          1. Skerrigan
            30.11.2018 17:54
            #19437666

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

            И для этого вовсе не требуется быть «плохим».


            1. KevlarBeaver
              01.12.2018 01:51
              #19439092

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


      1. KevlarBeaver
        01.12.2018 01:47
        #19439086

        Да, это примерно так и работает. Когда с тебя можно что-то поиметь и ты позволяет это делать, ты – "хороший человек". Но стоит скинуть нахлебников со своей шеи – сразу становишься плохим. Иными словами "хороший"/"плохой" – это вообще не характеристика по сути, а способ манипуляции.


    1. methanol
      30.11.2018 19:56
      #19438166

      Скорее всего, встреченные вами программисты то же самое думают и про вас, так что всё довольно субъективно.


    1. KevlarBeaver
      01.12.2018 01:43
      #19439076

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


  1. Falland
    30.11.2018 12:09
    #19435910

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

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


    1. Simplevolk
      30.11.2018 14:19
      #19436610

      А тогда также было?


      1. KevlarBeaver
        30.11.2018 22:30
        #19438606
        +1

        Ещё чума гуляла… но до некоторых менеджеров ей далеко.


  1. AllexIn
    30.11.2018 12:17
    #19435958

    Рекрутёры будут звонить рок-звезде каждый день по несколько раз. Их репутация опережает их.

    Телепатию уже изобрели, а я это пропустил…
    Каким волшебным образом кто-то в другой компании узнает что «Я, три года тянущий проект на себе» — рок-звезда?
    — Конференции? 9 из 10 рок-звезд не ездят на конференции, а работают над проектами.
    — Руководство? Руководство рок-звезд делать больше нечего, как обсуждать с конкурентами своих программистов. Тем более что чаще руководство тупо ничего не знает о винтиках в своей организации. А рок-звезда — ровно такой же винтик. Просто большой и мощный.
    — Коллеги? Ага, коллегки программисты идут бухать с руководителями соседних компаний и там рассказывают о человеке, который делает всё работу в их компании.
    — Телепати! Вот как они узнают, не иначе.


    1. Neikist
      30.11.2018 12:43
      #19436104

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


      1. AllexIn
        30.11.2018 12:45
        #19436122

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


        1. Neikist
          30.11.2018 12:50
          #19436164

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


          1. AllexIn
            30.11.2018 15:47
            #19436988

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


            1. Neikist
              30.11.2018 16:00
              #19437046

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


    1. slamon
      30.11.2018 15:24
      #19436888

      Каким волшебным образом кто-то в другой компании узнает что «Я, три года тянущий проект на себе» — рок-звезда?
      Значит, Вы и не рок-звезда :) Рок-звезд хорошо знают


      1. AllexIn
        30.11.2018 15:26
        #19436896

        Рок-звезд хорошо знают

        Через телепатию?


        1. slamon
          30.11.2018 15:37
          #19436946

          Нет, через их известность в мире IT


          1. AllexIn
            30.11.2018 15:45
            #19436976

            А известны они в мире IT через телепатию?

            P.S.
            Это я вам «тонко» намекаю на то, что не плохо было бы уже раскрыть, каким волшебным образом компании конкурентов узнают о существовании крутых спецов у своих противников.


            1. slamon
              30.11.2018 15:50
              #19437010

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


              1. AllexIn
                30.11.2018 15:55
                #19437028
                -1

                Известный потому что известный. Серьезно?


            1. balexa
              30.11.2018 16:12
              #19437096

              Откуда вы знаете про Кармака, например? Через телепатию?

              А конкретно про вас и кредитсы. Я ни в коем случае не сомневаюсь в вашей компетенции, но вы не рок звезда. Вы в близзарде работаете? Или в Валве? Рок-звезды не работают в малоизвестных компаниях, которые боятся указать имя людей в кредитсах.


              1. AllexIn
                30.11.2018 16:15
                #19437120

                О, я и не намекал на то что я рок-звезда, там речь шла не про переманивание разработчика, а про продажу проекта, увидите это если внимательно прочитаете.
                А Кармак — он в первую очередь владелец, также как Гейтс, например. Лицо компании.
                НУ и кстати, с Кармаком сделаи провальный Rage, а без Кармака выстрелевший Doom. Так что большой вопрос, является ли Кармак сейчас рок-звездой(в терминах разработки, а не известности).

                P.S. Ну и в целом вы ерунду пишите, рок-звездность не связано с размером компании. Рок-звездность — это уровень квалификации и способностей. Такие люди работают в самых разных компаниях. Опять же — прочитайте внимательнее раздел про рок-звездв в статье.


                1. balexa
                  30.11.2018 16:55
                  #19437320

                  Ок, не нравится Кармак — давайте возьмем кого нибудь вроде Шипилева (мне просто ближе джава-мир). Он не владелец, насколько мне известно.

                  прочитайте внимательнее раздел про рок-звездв в статье.

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


                  1. AllexIn
                    30.11.2018 18:33
                    #19437834

                    Мне Кармак не нравится? Это вам он перестал нравится, когда я указал, что он, очевидно, не рок-звезда сейчас.

                    Да, вот я вижу — рок звезда это тот кто тащит и кто известен.

                    Я вот целиком определение привел, покажите там слово, в котором вы увидели «известность»:
                    Разработчик настолько талантлив, настолько продуктивен, настолько важен, что если он уйдёт, весь проект рухнет.


              1. NaName
                01.12.2018 09:59
                #19439464

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


    1. andvary
      30.11.2018 23:26
      #19438782

      Вы отрицаете наличие репутации в принципе.
      А она есть, пойдем от противного — Билл Гейтс, Павел Дуров,…


    1. tyomitch
      01.12.2018 11:09
      #19439570
      +1

      — Телепати! Вот как они узнают, не иначе.

      Телепати — это вечеринка телепатов, что ли?


      1. MikailBag
        01.12.2018 21:09
        #19441008

        или телепузиков


  1. zim32
    30.11.2018 12:21
    #19435988

    Ждем похожую статью про типы менеджеров и всякого рода управленцев среднего звена.


    1. true_id1
      30.11.2018 16:46
      #19437254

      Так там же есть уже ссылки.


  1. DIOLLIA
    30.11.2018 13:19
    #19436332

    еще бы указать, сколько опыта за их килл дают…


  1. drafff
    30.11.2018 13:40
    #19436432

    Не хватает опроса в конце статьи — узнали ли вы себя в одном из этих типов?


    1. m1rko Автор
      30.11.2018 14:07
      #19436548

      Добавил.


  1. superyateam
    30.11.2018 14:54
    #19436752

    … поскольку им приносит удовлетворение именно сам процесс, а не цель

    Счастливые люди


    1. KevlarBeaver
      30.11.2018 22:11
      #19438556

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


  1. x67
    30.11.2018 15:03
    #19436798

    В каждом из психотипов нашел частичку себя. Учту)


  1. RusMikle
    30.11.2018 15:04
    #19436802

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


  1. cbrlx
    30.11.2018 15:06
    #19436810

    Вот и в кибернетике мягко добрались до темы личностных «корон». Ура)

    Кому вопрос интересен более развернуто — я подчерпнул много здесь: evo-lutio.livejournal.com


  1. methanol
    30.11.2018 15:06
    #19436812

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


    1. m1rko Автор
      30.11.2018 15:06
      #19436818

      OK, работаем над этим. )


  1. rgrits
    30.11.2018 15:23
    #19436884

    Вот не пойму, автор оригинального текста, солдат-метящий в менеджеры, или некомпетентный-пессимист?


  1. dsmv2014
    30.11.2018 15:47
    #19436990

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


    1. m1rko Автор
      30.11.2018 16:05
      #19437068

      Будет.


  1. Mugik
    30.11.2018 16:04
    #19437060

    «Некомпетентный»

    Блин, у меня и так проблемы с самооценкой и я прошу всегда мало денег. А тут ещё такое. Теперь я считаю, что вообще не достоин работать и получать даже то, что мне платят.

    Этот пост вообще мою самооценку снизил. Ну за что же вы так. И что же мне делать теперь.


    1. dsmv2014
      30.11.2018 16:31
      #19437182

      Считать себя рок-звездой


    1. KevlarBeaver
      30.11.2018 22:08
      #19438548
      -1

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

      Давай, каждый раз, перед тем, как просить денег, ты будешь звонить/писать мне. Я буду тебя подбадривать — ты будешь просить больше и ещё 10% сверху накидывать для меня.


  1. Nikolka0000
    30.11.2018 16:48
    #19437264

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


    1. KevlarBeaver
      30.11.2018 22:07
      #19438546

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

      image


  1. KevlarBeaver
    30.11.2018 22:04
    #19438536

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


  1. arielf
    30.11.2018 22:29
    #19438600
    -1

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


    1. Daddy_Cool
      01.12.2018 01:08
      #19438990
      -1

      Думается это не совсем так.
      aanechaev.livejournal.com/239663.html
      Вчера я летел из Москвы в Берлин. На подлете капитан корабля порадовал нас, что в германской столице хорошая погода, но еще минут через 10 начали твориться чудеса. Вместо посадки самолет стал кружить над аэропортом, а командир сообщил, что мы не можем сесть по погодным условиям и должны ожидать посадки в воздухе. Пару раз пилот вроде пытался сесть, но потом с натужным ревом двигателей машина вновь взмывала в небо. Согласитесь, не самые приятные ощущения.
      В итоге этих экспериментов капитан корабля уведомил нас, что сесть мы не сможем и полетим в Прагу, что и было проделано.
      Дальше началось самое интересное. После посадки пассажиры с доступом к интернету без труда выяснили, что самолеты других авиакомпаний прекрасно приземлялись в том же аэропорту Шенефельд Берлина до и после наших попыток. В Праге нам заменили пилотов. При замене удалось перемолвиться с летчиками парой слов. И выяснилось, что летчики нашего экипажа просто плохо умеют пилотировать самолет. Ну, конечно, не совсем не умеют (хотя при посадки в Праге они так грохнули машину о полосу, что и подобное подозрение имело под собой основание). Просто на этой модели самолета они не имеют опыта садиться в тумане, который опустился на Берлин. Летчики других авиакомпаний имеют, а наши нет. Справедливости ради замечу, что новый экипаж в тот же туман в Берлине все-таки сел.

      Что касается хирургов — про кардио не знаю, а вот в онкохирургии — весьма разные есть. А истинный уровень хирурга понятен только коллегам.
      Вот кстати история про плохого хирурга — со всеми объяснениями:
      www.anekdot.ru/id/977482
      В общем… все люди — в каждой профессии, и никто не идеален.


      1. arielf
        01.12.2018 01:39
        #19439068

        И тем не менее и они лучше, чем 90% «вкатившихся» в 30 л за большой зп «программистов». Ну, по крайней мере их учили и проверяли, у них были экзамены и в вузе, и в компании. И цена их ошибки — не выговор, а человеческие жизни.


      1. river-fall
        01.12.2018 15:04
        #19440116

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

        habr.com/company/tuturu/blog/425983


        1. Daddy_Cool
          01.12.2018 15:44
          #19440192

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