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