Без них не будет индустрии, и им самим это отлично известно. В пустыне квалифицированных талантов как вода востребованы разработчики программного обеспечения, пусть их носят на руках или оскорбляют, но это факт. В результате на свет появился целый спектр очень ярких проблемных личностей. Это приводит к такому захватывающему чувству собственного права, какое редко встречалось в истории человечества.
В немногих профессиях возможны такие доходы. Хороший разработчик может стоить на вес золота — буквально. Некоторые из богатейших людей на планете раньше были программистами, поэтому оказаться разработчиком в нужное время в нужном месте — это один из самых простых и прямых путей к огромному богатству.
Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.
Ниже приведены проблемные личности среди разработчиков программного обеспечения: К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины.
Разработчик настолько убеждён в своей незаменимости, что становится высокомерным и им невозможно руководить.
Проблема
На определённом уровне для управления работником он должен делать то, что вы говорите. Примадонной нельзя управлять, потому что он по своей сути не верит, что работает на вас. По его мнению, это у вас привилегия работать с ним. Он считает себя совершенно незаменимым и правым в любой дискуссии.
тип рок-звезда). Вопреки собственному убеждению, примадонна не обязательно является квалифицированным разработчиком (см. В результате примадонны слишком часто оценивают свой уровень мастерства намного выше, чем у коллег, хотя на самом деле это не так. Его высокомерие основано на представлении своего места в организации, а не на фактических технических навыках. Это обычно приводит к тому, что примадонну обычно не любят коллеги.
Определить примадонну можно по типичным фразам:
- «Это глупо — я не буду делать это таким образом»
- «Мы должны делать это вот так»
- «Если вам не нравится, то можете поговорить с моим менеджером»
- «Ну, мы ещё посмотрим»
- «Пойду поговорю с вашим начальником и посмотрим, что он скажет»
Примадонна не приемлет руководства. Он рассматривают любую попытку руководства как оскорбление, поскольку он выше того, чтобы нести ответственность за свои действия. Такая личностная проблема обычно встречается среди давних разработчиков, которые глубоко вовлечены в ранний успех компаний. Теперь, годы спустя, благодаря многолетним отношениям с основателями компании, он считает своё мнение выше мнения простого менеджера среднего звена.
Однако он отрицательно влияет на мораль коллектива, особенно на новых, более продуктивных разработчиков. Примадонна не представляет материальную опасность для проекта, поскольку обычно ничего не делает, а только качает права. Поэтому его нужно поставить на место, чтобы проект протекал гладко.
Решение
Решение для примадонны состоит в опровержении основного убеждения: что он незаменим и поэтому может делать всё, что хочет. Самый прямой способ опровергнуть это убеждение — нанять замену для тесного сотрудничества с ним. Чтобы адекватно донести до примадонны, что это действительно его замена, должны быть выполнены два условия:
- Замена должна быть более квалифицированной.
- Необходимо дать понять примадонне, что у его замены нет другой работы, кроме как следовать тенью за примадонной и обучаться в качестве его замены.
Чем быстрее замена соберёт все знания о легаси-коде, которыми может обладать примадонна (см. типы разработчиков хранитель легаси-кода и захватчик заложников), тем быстрее примадонна вернётся под контроль. Эффект может быть драматичным: всё может измениться буквально за несколько дней. По форме примадонна начинает выполнять дополнительную функцию к своей замене. В конечном счёте, он больше не незаменим, и поэтому больше не примадонна, а просто плохой сотрудник.
разработчик типа честолюбивый менеджер). Единственная надежда примадонны сохранить ощущение статуса — это получить повышение на руководящую должность (см. Однако повышение не рекомендуется, поскольку вы, скорее всего, увидите увольнения разработчиков, за которых отвечает примадонна. Чем лучше его смекалка, тем раньше при появлении замены он попытается это сделать. В любом случае, ваша проблема решена. Поэтому при отклонении запроса на повышение у него остаётся только два варианта: встать в один ряд с другими разработчиками или уйти.
Разработчик настолько одержим достижением архитектурной элегантности и совершенства кода, что забывает, что его работа должна приносить пользу бизнесу.
Проблема
Профессия инженера-программиста требует постоянного баланса двух противоположных задач:
- Желание принести пользу бизнесу (и получить зарплату).
- Желание написать отличный софт (и гордиться).
Идеалист полностью проигнорировал задачу приносить пользу бизнесу, а вместо этого сосредоточился исключительно на написании отличного ПО.
Он действительно знает, о чём говорит. Идеалистический разработчик, как правило, очень умный, опытный и профессиональный. Проблема в том, что он верит, что у него есть всё время в мире и полная свобода, хотя это далеко не так. Он действительно знает, как писать отличное программное обеспечение, и если ему дать достаточно времени, то сможет создать идеальную систему.
Он считает, что это лучше для бизнеса. Вместо того, чтобы найти компромисс, он сосредоточился на создании идеальной системы. Именно из-за непоколебимости этой веры их так трудно исправить. Не путайте их с учёными, которые создают нечто «абсолютное» или «классное»: идеалисты искренне считают, что их идеальная система лучше всего подходит для развития компании.
Таким образом, они берут в заложники всю команду разработчиков, а вы теперь в их власти. Идеалисты особенно опасны для проекта, потому что обычно имеют власть над другими ключевыми разработчиками, ведь они представляют идеал, к которому стремятся разработчики, поэтому так легко собирают других программистов на свою сторону, ведь все разработчики хотят гордиться программным обеспечением, которое пишут. По сути, польза для бизнеса появится только по окончании работы, но они не могут назвать вам сроки или оценить эту пользу. Если вам повезёт, они начнут предоставлять ценность для бизнеса, но это будет только случайным побочным эффектом в их стремлении создать отличное программное обеспечение. По правде говоря, они даже не заинтересованы в завершении, поскольку им приносит удовлетворение именно сам процесс, а не цель.
Решение
Резюмируем черты идеалиста:
- Очень умный, опытный и профессиональный.
- Искренне считает, что его система лучше для будущего компании.
Во многих отношениях это очень хороший сотрудник, и если посмотреть на самые инновационные компании на земле, у них много идеалистов в отделах исследований и разработок. Однако у самых лучших компаний есть три вещи, которые отсутствуют у остальных:
- Управленческий персонал столь же компетентен, как и идеалисты, предлагая сдержки и противовесы для их технических решений.
- Ожидание, что определённое количество проектов потерпит неудачу, что является обычными затратами на ведение бизнеса.
- Большой бюджет, чтобы продолжать финансировать проекты, которые являются убыточными.
Если у вашей компании есть эти три вещи, оставьте идеалиста в покое, пусть делает что хочет. Но если у вас, как и у большинства компаний, нет этих роскошных условий, то появляется реальная проблема, так как почти всё, что вы предпримете, приведёт к катастрофе:
- Если сразу уволить его, то лояльные разработчики могут вскоре последовать за ним.
- Если установить жёсткие правила, то он может мысленно отключиться от проекта, что оставит вас без технического руководства.
- Если оставить его в покое, то начальство в итоге устанет от отсутствия ощутимого прогресса.
Чтобы заставить идеалиста изменить поведение, нужно найти кого-то, кто сможет убедить его. Этот человек должен продемонстрировать идеалисту, что он тоже может создать отличную систему. Это важно, так как человека без технической компетенции просто проигнорируют как неспособного понять гениальность идеального дизайна.
Это требует, чтобы высокоинтеллектуальный, опытный профессионал был готов делать то, что считает правильным. Если найден человек с таким доверием, ему придётся медленно и методично выводить идеалиста из его идеалистического образа мышления. Шансов на это мало, а значит, и мало шансов на исправление идеалиста.
Разработчик настолько талантлив, настолько продуктивен, настолько важен, что если он уйдёт, весь проект рухнет.
Проблема
В софтверной индустрии термин «рок-звезда» часто используется рекрутёрами, которые пытаются привлечь разработчиков, раздувая их эго, то есть «мы ищем нескольких разработчиков рок-звёзд». Настоящих же рок-звёзд найти сложно, так как они идеальные программисты:
- Нет проблемы, которую они не могут решить (и быстро).
- Они работают всю ночь, чтобы успеть к дедлайну.
- В их коде практически нет багов или любые баги быстро устраняются.
- Они берут на себя самые сложные части проекта.
- Их обычно очень любят коллеги.
К сожалению, однажды нанятые, они становятся незаменимыми в проекте.
Может доходить до того, что они отнимают работу у более медленных разработчиков, чтобы уложиться в срок — ко всеобщему облегчению. Рок-звезда похож на чёрную дыру: работа скапливается вокруг них и в конечном итоге неизбежно всасывается внутрь, чтобы быть сделанной. Если случается что-то драматическое и неожиданное, они будут знать, что делать. Если проект окажется в затруднительном положении, они спасут положение. Они действительно замечательные — и каждый рекрутёр это знает.
Их репутация опережает их. Рекрутёры будут звонить рок-звезде каждый день по несколько раз. Поэтому складывается ситуация, что существует некто незаменимый для вашего проекта, которого хочет переманить каждая вторая компания. Компании всегда хотят переманить рок-звёзд, потому что понимают их ценность, а во многих случаях сделают почти всё, чтобы их заполучить. Классический случай, когда слишком много яиц кладутся в одну корзину. Если они это сделают, то проект сорвётся.
Решение
Для рок-звезды нет «решения». В конце концов, только глупец захочет «исправлять» его, поскольку он является вашим самым продуктивным разработчиком на сегодняшний день. Всё, что вы можете сделать, это смягчить ущерб, создав вокруг команду, которая сможет эффективно функционировать в случае его ухода. Скорее всего, вам понадобится несколько разработчиков, чтобы заменить производительность одной рок-звезды, но вы хотя бы сможете пережить его уход.
Если при его недельном отсутствии вся разработка останавливается, то нужно удвоить усилия в доведении других разработчиков до уровня, при котором они могут удержать развитие проекта в отсутствие рок-звезды. Чтобы проверить, насколько плоха ваша ситуация, обратите пристальное внимание на производительность разработчиков, когда рок-звезда уходит в отпуск.
Есть шанс, что с внезапным уходом рок-звезды другие разработчики начнут действовать. Это может быть непросто, если разработчики привыкли к тому, что он справляется со сложными проблемами, они стали ленивыми и самодовольными. Но, скорее всего, они настолько его любят, что последуют за ним в новую компанию.
Разработчик, который решил избежать трудностей программирования и стать одним из менеджеров.
Проблема
Программированию трудно обучиться. Оно требует навыка быстрого решения проблем, большого объёма знаний и ещё большего количества реального опыта. В отличие от сопоставимых профессиональных областей, эти знания и опыт устаревают гораздо быстрее (иногда в течение месяцев), что требует постоянного освоения новых методов, технологий и инструментов. Начинающий менеджер хочет избавиться от этой суеты, и выход видит в управлении.
Время тратится на собрания, отправку электронных писем или вообще на прогулки и общение с другими людьми. Как правило, для менеджеров по разработке ниже требования к навыкам программирования, чем для разработчиков. Это очевидный выбор для разработчиков, которые хотят избавиться от написания программного обеспечения. Менеджеры также, как правило, зарабатывают больше, чем кодеры, а со статусом приходят полномочия.
Чтобы практиковаться в навыках управления, честолюбивый менеджер пытается командовать коллегами-разработчиками: назначает работу, выступает на собраниях и, как правило, стремится участвовать в принятии более стратегических решений. Проблема с разработчиком, который стал честолюбивым менеджером, заключается в том, что он стремится продемонстрировать свои навыки управления в надежде на повышение, а не думает о программировании. Поэтому их не любят в равной степени и коллеги-разработчики, и другие менеджеры, которые видят угрозу своей работе.
Решение
Невозможно решить проблему честолюбивого менеджера, потому что он уже сделал чёткий карьерный выбор. Как только решение принято, пути назад нет. Вы не можете заставить его опять писать программы. Даже если заставить, то вскоре вы обнаружите причину, по которой он стал честолюбивым менеджером: парень не очень хорош в программировании. Из-за сложности этой ситуации так много честолюбивых менеджеров получают то, чего хотят: повышаются до должности менеджера, при наличии свободной вакансии.
Часто эти люди на протяжении всей карьеры болтаются по организации, а высшее руководство изо всех сил пытается найти им применение. Как правило, разработчики в этом положении не особенно вредны проекту, потому что их производительность слишком низка, а они обычно не владеют особым доверием ни разработчиков, ни менеджеров. В этом качестве они могут стать опасными, если им поручена критически важная задача, но поскольку этого можно полностью избежать, они могут безопасно оставаться просто мелким раздражающим фактором.
Разработчик, который написал часть критически важного программного обеспечения и не даёт никому работать над ним, чтобы сохранить свою незаменимость.
Проблема
Любому человеку с финансовыми обязательствами важно обеспечить сохранность своего рабочего места и зарплаты. Кроме того, работать со знакомым кодом намного проще, чем с незнакомым. Из сочетания этих двух желаний рождается захватчик заложников — разработчик, который написал и единолично владеет критической частью программного обеспечения, отказываясь работать над чем-то ещё.
Поэтому все новые работы над критически важной системой переходят к захватчику, тем самым продолжая порочный круг. Как правило, это плохой инженер-программист, что по иронии становится важным преимуществом: его код обычно не понятен больше никому, так что другие разработчики боятся залазить в такое болото, опасаясь причинить больше вреда, чем пользы.
Если его действительно загнать в угол, он будет угрожать уйти, а поскольку никто другой не хочет брать на себя плохо спроектированный и написанный продукт, такой блеф редко наказывают. Захватчик заложников обычно занимает оборонительную и конфронтационную позицию, он абсолютно закрыт для критики или сотрудничества в отношении его кодовой базы. Они могут стать узким местом в проекте, так как вся судьба проекта будет зависеть от их желания и умения выдать код.
Решение
Как ни опасен захватчик заложников, решение простое: возложить на двух или более разработчиков ответственность за часть системы захватчика, его перевести на другую часть. Некоторое время производительность будет низкая, пока новые разработчики попытаются понять и переработать код, но по окончании этого периода захватчик полностью нейтрализован и больше не представит проблемы.
Разработчик настолько сосредоточенный на завершении работы, что полностью отказывается от любого понятия качества.
- Может мутировать в солдата
- Опасен в сочетании с менеджером проекта типа тиран и тестировщиком типа пожарный шланг
- Возможность исправления: высокая
- Опасность для проекта: средняя
Проблема
На разработчиков всегда оказывается огромное давление. «Интернет никогда не спит» означает, что часто разработчики тоже не спят. Чтобы вернуть подобие баланса между работой и жизнью, слон в посудной лавке хочет как можно быстрее завершить свой список задач и вернуться домой к семье.
Независимо от того, насколько хорош разработчик, если давление возрастёт до определённой степени, он неизбежно прекратит тестирование собственной работы и вместо этого понадеется на отдел тестирования (см. Программистов такого типа создаёт давление проекта. Кроме того, для удобства они откажутся от коллегиальной проверки кода, автоматического тестирования и рефакторинга, оставив код в аварийном состоянии. тип тестировщика обвинитель) в качестве единственного средства для поиска ошибок. Это плохо разработанное программное обеспечение затем вызывает новые ошибки, и кодовая база быстро превращается в болото багов, которые невозможно исправить полностью.
Он — жертва плохо спланированного проекта, но проблемой всё равно считают разработчика. Слон в посудной лавке живёт в постоянном стрессе из-за давления начальства. Именно в отношении слонов в посудной лавке используется фраза «выгорание и замена», так как постоянный стресс в конечном итоге сломает их, и они либо уйдут, либо будут уволены из-за их кажущейся некомпетентности.
Решение
Поскольку проблема не в человеке, организация должна предпринять следующие шаги:
- Объявить перерыв на проекте, чтобы дать некоторую передышку. Обычно это делается путём резкого сокращения объёма работ или значительного переноса сроков.
- Спокойный период способствует откровенному обсуждению, когда слон в посудной лавке имеет возможность высказать свои обиды.
- Сделать анализ первопричин ошибок и исправить их. Не спешите с этим. Убедитесь, что всё исправлено, прежде чем продолжить проект.
- Разобраться со всеми случаями выгорания среди разработчиков, заставить их взять внеочередные отпуски. Организации редко это делают, но это очень эффективно.
- Когда команда перегруппируется, выполнить комплексную оценку проекта, установить новые объёмы работ и сроки.
Хотя эти шаги позволяют чётко решить проблему, их почти никогда не предпринимают. То есть менеджмент остаётся причиной проблемы, а не источником решения. Но если руководство признает свою роль в появлении слонов в посудной лавке, то через несколько недель ущерб можно компенсировать, а разработка проекта вернётся в нормальное русло.
Разработчик, которому не хватает интеллекта или навыков для написания программного обеспечения.
Проблема
Не каждый способен стать профессиональным спортсменом или опытным музыкантом, или врачом. Также есть люди, которые просто не созданы, чтобы быть разработчиками программного обеспечения. Эти некомпетентные разработчики часто отрицают свою некомпетентность и отказываются уходить из профессии из-за высокой зарплаты и большого количества доступных вакансий.
Менеджеру без технического образования может быть сложно распознать некомпетентного разработчика, но есть несколько признаков:
- В своей низкой продуктивности они обвиняют отсутствие корпоративных тренингов.
- Оспаривают применение «слишком сложных» технологий, инструментов и методов.
- Сильно переоценивают сроки выполнения работы (см. пессимист), а потом всё равно не сдают её в срок.
- Выдают функции, не соответствующие спецификациям.
- Реализованные функции полны ошибок.
- Опытные разработчики избегают или отказываются работать с ними.
- Когда их спрашивают о ходе работы, они оправдываются и часто занимают оборонительную позицию.
- Претендуют на руководящую должность (см. честолюбивый менеджер), чтобы приносить «больше пользы».
Вся индустрия программного обеспечения страдает от проблемы некомпетентности. Это простой пример спроса и предложения, когда на рынке труда не хватает квалифицированных разработчиков.
Решение
Когда менеджер замечает некомпетентного разработчика, то естественное чувство сопереживания часто подталкивает назначить ему задачи полегче. К сожалению, так же как нельзя быть полуграмотным кардиохирургом или частично компетентным пилотом, никто не может быть лишь частично компетентным разработчиком программного обеспечения. Если вам не хватает компетенции для разработки программного обеспечения, то вы не сможете хорошо выполнять даже простые задачи.
Здесь основная проблема в том, что если бы некомпетентный разработчик мог научиться, он бы уже это сделал — как его более компетентные коллеги, поскольку компетентные разработчики обучаются сами. Когда простые задачи оказываются слишком сложными, следующим шагом обычно становится выделение бюджета на обучение.
Они вызывают два очень разрушительных эффекта: Существует мысль, что наличие не очень продуктивного разработчика в штате не причиняет вреда, но это большая ошибка.
- Разрушение качества кодовой базы, появление нового глючного кода и внедрение багов в рабочий код (см. также слон в посудной лавке)
- Они отталкивают компетентных разработчиков, которым надоело работать с ними.
В конечном счёте, если проект зависит от некомпетентного разработчика, то проект не будет выполнен. Это приводит к печальному выводу, что таким работникам нужно покинуть организацию. Если они не соглашаются (обычно после всё более прямых намёков), то их следует уволить.
Разработчик, который постоянно недооценивает количество времени, необходимое для выполнения задачи.
- Может мутировать в пессимиста
- Опасен в сочетании с оптимистичным менеджером проектов
- Возможность исправления: высокая
- Опасность для проекта: средняя
Проблема
Недооценка сроков является настолько распространённым симптомом в индустрии программного обеспечения, что многие даже не считают это проблемой. Все всегда недооценивают сроки, а во многих случаях это принимается как часть бизнеса. Тем не менее, разработчик-оптимист выводит проблему на совершенно новый уровень, так как он практически всегда сдаёт работу намного позже.
Выпуск программного обеспечения иногда связан с договорными обязательствами с клиентами и/или партнёрами, что делает предсказуемость бизнес-необходимостью. Оптимист влияет на предсказуемость проекта: без хороших оценок невозможно планировать будущее. Оптимист злоупотребляет этой терпимостью за срыв сроков, выполняя свои задачи за несколько недель вместо обещанных пары дней; или, что ещё хуже, за несколько месяцев вместо обещанных пары недель. Конечно, всегда можно ожидать немного непредсказуемости, так как в реальности вся индустрия программного обеспечения построена вокруг того факта, что нельзя точно предсказать, сколько времени займет написание софта.
Он может также считать, что сама оценка является бесполезной практикой, поскольку ничто никогда нельзя точно оценить. Оптимист фундаментально не понимает негативное влияние такого рода задержек на общий успех проекта. Таким образом, он может вальяжно отнестись к оценке или выдать произвольное число без какого-то анализа.
Решение
К счастью, оптимиста можно исправить, соблюдая нескольких правил:
- Просить их об оценке только для кода, с которым они хорошо знакомы.
- Просить об оценке только для технологий, с которыми они хорошо знакомы.
- Никогда не просить оценить сроки реализации новых функций, а только улучшения существующих.
- Необходимо позаботиться о том, чтобы они полностью понимали все требования — им нельзя свободно интерпретировать требования на лету.
- Требуйте от оптимиста добавления комментариев «TODO» в тех областях, где им придётся вносить правки. Это усилит зависимость между сложностью программного обеспечения и оценкой сроков.
- Сделайте их подотчётными: покажите их оценки группе, способной оспорить такие сроки.
Когда оптимист прошёл несколько раз через этот процесс и выполнил свои обязательства, вы можете начать доверять его оценке сроков для новых функций, а также для кодовых баз и технологий, с которыми он менее знаком.
Во время процесса реабилитации оптимиста обратите пристальное внимание на то, как он соблюдает свои сроки:
- Страдает ли качество работы от повышенных обязательств (см. слон в посудной лавке). Если так, предложите добавить необходимое время для тестирования.
- Работают ли они сверхурочно, чтобы соблюсти сроки (см. солдат)? В этом случае предложите добавить время для выполнения работы в рабочие часы, а сверхурочные должны остаться для непредвиденных обстоятельств.
Если оптимист серьёзно относится к своей реабилитации, он может вырасти в пользующегося высоким доверием члена команды, ведь доверием пользуются разработчики, которые выдают соответствующий требованиям код достаточного качества в согласованные сроки. Как только они докажут, что могут стабильно делать это, то могут получить повышение в должности или в зарплате, что само по себе можно предложить в качестве стимула для их реабилитации.
Разработчик, который настолько боится пропустить сроки, что просит максимально возможное время на выполнение задачи.
- Может мутировать в слона в посудной лавке
- Опасен в сочетании с таким же пессимистом в качестве менеджера проекта
- Возможность исправления: низкая
- Опасность для проекта: нет
Проблема
Если есть возможность выбора, большинство менеджеров проектов предпочли бы пессимистов, чем оптимистов. Хотя они могут работать долго, но они хотя бы предсказуемы. Пессимист очень хорошо это знает и в полной мере использует данное обстоятельство, запрашивая для своей задачи максимальное время вместо того, чтобы рассмотреть реалистичные сроки.
Их можно ошибочно принять за зрелых и ответственных, поскольку в отличие от своих, казалось бы, менее опытных коллег-разработчиков, они никогда не пропускают дедлайн. Пессимистов иногда невозможно заметить. Но есть некоторые признаки:
- Их коллеги-разработчики при такой же оценке дают значительно более короткие сроки выполнения.
- Если назначить им крайний срок, они сразу соглашаются, без какой-то формальной оценки.
- Когда они быстро согласились, если немного переместить дату на более ранний срок, они согласятся и на этот срок. Это означает, что между двумя датами действительно не требуется дополнительного времени для завершения задачи.
Пессимист может уменьшить конкурентоспособность компании. Если вы вовлечены в гонку с конкурентом, то всегда будете медленнее него.
Решение
Пессимисты рождаются по вине организации, которая наказывает за срыв сроков. Естественная реакция людей — запрашивать как можно больше времени, чтобы свести к минимуму вероятность наказания. Может показаться, что это легко исправить, но против вас работают три вещи:
- Работа в пессимистическом режиме гораздо менее стрессовая, чем нормальная работа.
- Пессимистов обычно вознаграждают и повышают намного чаще тех, кто пропускает важные сроки.
- Бизнес должен стать более терпим к опозданию. Когда устоялась определённая культура разработки, большинство компаний не способны на это.
Поэтому проблема исправима, но обычно нет воли для её исправления. По своей природе пессимисты не представляют угрозы проекту, но потенциально очень опасны для будущей жизнеспособности компании.
Разработчик, который делает именно то, что ему говорят, без вопросов, независимо от того, правильно ли это.
- Может мутировать в слона в посудной лавке
- Опасен в сочетании с менеджером проектов типа тиран
- Возможность исправления: нет
- Опасность для проекта: низкая
Проблема
С точки зрения менеджера, кто может быть лучше разработчика, который делает в точности то, что сказано? Действительно, ключевая проблема с примадонной заключается в том, что он не выполняет распоряжения. Безусловно, полностью послушный разработчик является благом для проекта. К сожалению, у солдата есть свой недостаток: он послушно прыгнет в пропасть, если ему так скажут, утащив с собой весь проект.
Ключевой характеристикой является его послушание: каждый раз он будет делать в точности то, что вы ему скажете. Солдат может быть любого уровня компетентности: от некомпетентного до рок-звезды. Легко ошибиться, посчитав это эффектом фантастического лидерства, но превосходные начальники встречаются очень редко.
Солдаты рождаются несколькими способами:
- Вы столько раз отвергали их возражения, что они просто перестали жаловаться: не видят смысла. Если возражения были обоснованы, то вы потеряли ценный источник информации о том, что можно улучшить.
- Солдат хочет сделать минимум работы, а если делать только и именно то, что от них просят, то это по определению минимум.
- Они знают, что вы просите сделать неправильные вещи, и хотят, чтобы вы пострадали от последствий.
- Они так устали, что ищут другую работу, и просто тянут время, пока что-нибудь не найдут.
- Им не хватает знаний и опыта, чтобы видеть ошибки, поэтому солдат слепо марширует вперед.
- Страх наказания за ошибки заставляет думать, что лучший способ избежать наказания — делать только то, о чём просят.
- Они убедили себя, что полное подчинение — путь к карьерному росту, что весьма печально, поскольку это почти никогда не бывает верно в инновационной области разработки программного обеспечения.
- Это действительно бывшие военные, которые принесли с собой специфический менталитет.
В результате, как бы приятно ни казалось иметь в своём подчинении солдата, это вряд ли хорошо.
Решение
Если вы даёте правильные распоряжения, солдат не доставит никаких проблем. На самом деле при сильном руководстве наличие отряда солдат — весьма эффективное оружие. Но если вам нужна обратная связь от разработчиков, чтобы помочь совместно вести проект, вы не получите такого сотрудничества. Это оставляет вас в ситуации неизвестности, когда вы даже не знаете о том, что нечто упускаете. А солдат не расскажет.
Однако по своей природе он не скажет открыто, почему стал таким. Если вы можете определить причину, почему солдат беспрекословно вам подчиняется, то есть шанс её исправить. Если нажать и спросить, есть ли проблема, наиболее вероятный ответ «Нет», независимо от его истинных чувств. Как правило, солдат предпочитает общаться на конкретные рабочие темы.
Даже если вы определите истинную проблему, то придётся её исправить, что может быть трудно. Вы можете надеяться только на то, что о солдате расскажут его коллеги, но тогда они предадут его доверие, что вряд ли произойдёт. Только он сам может изменить себя. Затем после устранения первопричины остаётся надеяться, что солдат изменит свое поведение.
Таким образом, это обычно хорошие работники для поддержки сильного лидера. В целом, их практически невозможно исправить.
Разработчик, который так рад попробовать новые технологии, что будет внедрять их в проект, уместно это или нет.
Проблема
Для успешного запуска продукта необходимо выбрать технологию. Это тщательный выбор с вниманием к конкретному набору бизнес-проблем, которые необходимо решить. А фанат технологий просто любит новые игрушки.
Но когда разработчик путает свою профессиональную ответственность и личное любопытство, вы можете в итоге остаться с технологическим стеком, который дико не соответствует бизнес-задачам. Все разработчики в какой-то степени влюблены в технологии: они должны быть такими, чтобы поддерживать свои навыки.
Он будет часто и публично выступать за использование новой технологии, часто с неубедительными аргументами. Влюблённого в технологии разработчика очень легко выделить из толпы. Во многих случаях это может быть действительно превосходное техническое решение конкретной проблемы, но поскольку технология не прошла надлежащей проверки, она может фактически плохо подходить для проекта в целом. Он также внезапно меняет технологии посреди работы, никому не говоря, застигая других врасплох.
Решение
Фанаты технологий исправляются сами собой, если компания установила стандартный технологический стек. Затем требуется всего лишь следить, чтобы разработчики не отклонялись от него. Если у вас нет установленного стека технологий, настоятельно рекомендуется определить его заранее, так как будет неудобно вводить его после того, как фанат технологий начнёт активничать.
Это чрезвычайно здоровое решение, потому что после презентации команда может совместно обсудить, есть ли смысл расширить стек корпоративных технологий. Новость о том, что нельзя использовать свою новую технологию, скорее всего, повредит моральному духу любителя технологий, но этот моральный дух можно быстро восстановить, попросив его сделать презентацию об этой новой технологии. Большинство любителей технологий будут удовлетворены таким судилищем, даже если им не понравится окончательное решение.
Разработчик, единственной способностью которого является обслуживание устаревшего программного обеспечения, и поэтому он не в состоянии взять на себя новую работу.
Проблема
Когда в компанию приходит новый разработчик, он обычно полон огня и страсти, пытается всячески проявить себя. Но со временем место страсти занимает самоуспокоенность: разработчик считает, что стаж в компании даёт ему некие привилегии. За собой он признаёт обязанность поддерживать свои системы, но не браться за разработку новых частей.
В этот момент возникает вопрос, можете ли вы позволить себе держать их в штате, то есть могут ли другие разработчики взять на себя их задачи по обслуживанию легаси-кода. Проблема с хранителем легаси-кода связана с масштабированием: они просто не входят в пул доступных ресурсов для новой работы. Обычно трудно убедить других разработчиков сделать это по двум причинам:
- Древний код обычно плохо написан и с ним трудно работать.
- Поддержка — это тупиковый путь карьеры, поскольку вы не делаете ничего нового или инновационного, за что вас могут отметить.
Вот почему старые мейнтейнеры остаются в компании так долго. Часто они были в компании с момента её создания и являются авторами программного обеспечения, на котором построена компания. Однако по мере роста компании они не продвигались по службе или не пытались овладеть новыми навыками или новыми частями системы, в результате чего прочно привязались к единственному известному им коду.
Решение
Хранитель легаси-кода не создаёт проблем, если понимать, что он не входит в число ресурсов для работы над новыми проектами. В лучшем случае его можно попросить исправить ошибки и реализовать небольшие улучшения функций. Единственная проблема возникает, если они запрещают другим ознакомиться со своей частью системы (см. захватчик заложников).
У него менталитет как у рабочего на заводе: крутить одну и ту же гайку каждый день на протяжении всей карьеры, а затем уйти на пенсию. Хранителя невозможно исправить, потому что у него нет такого желания. Такое отношение невозможно изменить, поскольку оно составляет суть человека.
В этом случае он поймёт, что поддержка устаревшего программного обеспечения не приведёт к повышению. Один из вариантов, который может изменить такое отношение — если человек переживёт значительные события в жизни (свадьба, рождение ребёнка, покупка дома и т. д.), что потребует дополнительного заработка. К сожалению, вы не контролируете этот фактор.
