- PVSM.RU - https://www.pvsm.ru -
В пустыне квалифицированных талантов как вода востребованы разработчики программного обеспечения, пусть их носят на руках или оскорбляют, но это факт. Без них не будет индустрии, и им самим это отлично известно. Это приводит к такому захватывающему чувству собственного права, какое редко встречалось в истории человечества. В результате на свет появился целый спектр очень ярких проблемных личностей.
Хороший разработчик может стоить на вес золота — буквально [1]. В немногих профессиях возможны такие доходы. Некоторые из богатейших людей на планете раньше были программистами, поэтому оказаться разработчиком в нужное время в нужном месте — это один из самых простых и прямых путей к огромному богатству.
Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.
Ниже приведены проблемные личности [2] среди разработчиков программного обеспечения:
Разработчик настолько убеждён в своей незаменимости, что становится высокомерным и им невозможно руководить.
На определённом уровне для управления работником он должен делать то, что вы говорите. Примадонной нельзя управлять, потому что он по своей сути не верит, что работает на вас. По его мнению, это у вас привилегия работать с ним. Он считает себя совершенно незаменимым и правым в любой дискуссии.
Вопреки собственному убеждению, примадонна не обязательно является квалифицированным разработчиком (см. тип рок-звезда [5]). Его высокомерие основано на представлении своего места в организации, а не на фактических технических навыках. В результате примадонны слишком часто оценивают свой уровень мастерства намного выше, чем у коллег, хотя на самом деле это не так. Это обычно приводит к тому, что примадонну обычно не любят коллеги.
Определить примадонну можно по типичным фразам:
Примадонна не приемлет руководства. Он рассматривают любую попытку руководства как оскорбление, поскольку он выше того, чтобы нести ответственность за свои действия. Такая личностная проблема обычно встречается среди давних разработчиков, которые глубоко вовлечены в ранний успех компаний. Теперь, годы спустя, благодаря многолетним отношениям с основателями компании, он считает своё мнение выше мнения простого менеджера среднего звена.
Примадонна не представляет материальную опасность для проекта, поскольку обычно ничего не делает, а только качает права. Однако он отрицательно влияет на мораль коллектива, особенно на новых, более продуктивных разработчиков. Поэтому его нужно поставить на место, чтобы проект протекал гладко.
Решение для примадонны состоит в опровержении основного убеждения: что он незаменим и поэтому может делать всё, что хочет. Самый прямой способ опровергнуть это убеждение — нанять замену для тесного сотрудничества с ним. Чтобы адекватно донести до примадонны, что это действительно его замена, должны быть выполнены два условия:
Чем быстрее замена соберёт все знания о легаси-коде, которыми может обладать примадонна (см. типы разработчиков хранитель легаси-кода [14] и захватчик заложников [7]), тем быстрее примадонна вернётся под контроль. Эффект может быть драматичным: всё может измениться буквально за несколько дней. По форме примадонна начинает выполнять дополнительную функцию к своей замене. В конечном счёте, он больше не незаменим, и поэтому больше не примадонна, а просто плохой сотрудник.
Единственная надежда примадонны сохранить ощущение статуса — это получить повышение на руководящую должность (см. разработчик типа честолюбивый менеджер [6]). Чем лучше его смекалка, тем раньше при появлении замены он попытается это сделать. Однако повышение не рекомендуется, поскольку вы, скорее всего, увидите увольнения разработчиков, за которых отвечает примадонна. Поэтому при отклонении запроса на повышение у него остаётся только два варианта: встать в один ряд с другими разработчиками или уйти. В любом случае, ваша проблема решена.
Разработчик настолько одержим достижением архитектурной элегантности и совершенства кода, что забывает, что его работа должна приносить пользу бизнесу.
Профессия инженера-программиста требует постоянного баланса двух противоположных задач:
Идеалист полностью проигнорировал задачу приносить пользу бизнесу, а вместо этого сосредоточился исключительно на написании отличного ПО.
Идеалистический разработчик, как правило, очень умный, опытный и профессиональный. Он действительно знает, о чём говорит. Он действительно знает, как писать отличное программное обеспечение, и если ему дать достаточно времени, то сможет создать идеальную систему. Проблема в том, что он верит, что у него есть всё время в мире и полная свобода, хотя это далеко не так.
Вместо того, чтобы найти компромисс, он сосредоточился на создании идеальной системы. Он считает, что это лучше для бизнеса. Не путайте их с учёными, которые создают нечто «абсолютное» или «классное»: идеалисты искренне считают, что их идеальная система лучше всего подходит для развития компании. Именно из-за непоколебимости этой веры их так трудно исправить.
Идеалисты особенно опасны для проекта, потому что обычно имеют власть над другими ключевыми разработчиками, ведь они представляют идеал, к которому стремятся разработчики, поэтому так легко собирают других программистов на свою сторону, ведь все разработчики хотят гордиться программным обеспечением, которое пишут. Таким образом, они берут в заложники всю команду разработчиков, а вы теперь в их власти. Если вам повезёт, они начнут предоставлять ценность для бизнеса, но это будет только случайным побочным эффектом в их стремлении создать отличное программное обеспечение. По сути, польза для бизнеса появится только по окончании работы, но они не могут назвать вам сроки или оценить эту пользу. По правде говоря, они даже не заинтересованы в завершении, поскольку им приносит удовлетворение именно сам процесс, а не цель.
Резюмируем черты идеалиста:
Во многих отношениях это очень хороший сотрудник, и если посмотреть на самые инновационные компании на земле, у них много идеалистов в отделах исследований и разработок. Однако у самых лучших компаний есть три вещи, которые отсутствуют у остальных:
Если у вашей компании есть эти три вещи, оставьте идеалиста в покое, пусть делает что хочет. Но если у вас, как и у большинства компаний, нет этих роскошных условий, то появляется реальная проблема, так как почти всё, что вы предпримете, приведёт к катастрофе:
Чтобы заставить идеалиста изменить поведение, нужно найти кого-то, кто сможет убедить его. Этот человек должен продемонстрировать идеалисту, что он тоже может создать отличную систему. Это важно, так как человека без технической компетенции просто проигнорируют как неспособного понять гениальность идеального дизайна.
Если найден человек с таким доверием, ему придётся медленно и методично выводить идеалиста из его идеалистического образа
Разработчик настолько талантлив, настолько продуктивен, настолько важен, что если он уйдёт, весь проект рухнет.
В софтверной индустрии термин «рок-звезда» часто используется рекрутёрами, которые пытаются привлечь разработчиков, раздувая их эго, то есть «мы ищем нескольких разработчиков рок-звёзд». Настоящих же рок-звёзд найти сложно, так как они идеальные программисты:
К сожалению, однажды нанятые, они становятся незаменимыми в проекте.
Рок-звезда похож на чёрную дыру: работа скапливается вокруг них и в конечном итоге неизбежно всасывается внутрь, чтобы быть сделанной. Может доходить до того, что они отнимают работу у более медленных разработчиков, чтобы уложиться в срок — ко всеобщему облегчению. Если проект окажется в затруднительном положении, они спасут положение. Если случается что-то драматическое и неожиданное, они будут знать, что делать. Они действительно замечательные — и каждый рекрутёр это знает.
Рекрутёры будут звонить рок-звезде каждый день по несколько раз. Их репутация опережает их. Компании всегда хотят переманить рок-звёзд, потому что понимают их ценность, а во многих случаях сделают почти всё, чтобы их заполучить. Поэтому складывается ситуация, что существует некто незаменимый для вашего проекта, которого хочет переманить каждая вторая компания. Если они это сделают, то проект сорвётся. Классический случай, когда слишком много яиц кладутся в одну корзину.
Для рок-звезды нет «решения». В конце концов, только глупец захочет «исправлять» его, поскольку он является вашим самым продуктивным разработчиком на сегодняшний день. Всё, что вы можете сделать, это смягчить ущерб, создав вокруг команду, которая сможет эффективно функционировать в случае его ухода. Скорее всего, вам понадобится несколько разработчиков, чтобы заменить производительность одной рок-звезды, но вы хотя бы сможете пережить его уход.
Чтобы проверить, насколько плоха ваша ситуация, обратите пристальное внимание на производительность разработчиков, когда рок-звезда уходит в отпуск. Если при его недельном отсутствии вся разработка останавливается, то нужно удвоить усилия в доведении других разработчиков до уровня, при котором они могут удержать развитие проекта в отсутствие рок-звезды.
Это может быть непросто, если разработчики привыкли к тому, что он справляется со сложными проблемами, они стали ленивыми и самодовольными. Есть шанс, что с внезапным уходом рок-звезды другие разработчики начнут действовать. Но, скорее всего, они настолько его любят, что последуют за ним в новую компанию.
Разработчик, который решил избежать трудностей программирования и стать одним из менеджеров.
Программированию трудно обучиться. Оно требует навыка быстрого решения проблем, большого объёма знаний и ещё большего количества реального опыта. В отличие от сопоставимых профессиональных областей, эти знания и опыт устаревают гораздо быстрее (иногда в течение месяцев), что требует постоянного освоения новых методов, технологий и инструментов. Начинающий менеджер хочет избавиться от этой суеты, и выход видит в управлении.
Как правило, для менеджеров по разработке ниже требования к навыкам программирования, чем для разработчиков. Время тратится на собрания, отправку электронных писем или вообще на прогулки и общение с другими людьми. Менеджеры также, как правило, зарабатывают больше, чем кодеры, а со статусом приходят полномочия. Это очевидный выбор для разработчиков, которые хотят избавиться от написания программного обеспечения.
Проблема с разработчиком, который стал честолюбивым менеджером, заключается в том, что он стремится продемонстрировать свои навыки управления в надежде на повышение, а не думает о программировании. Чтобы практиковаться в навыках управления, честолюбивый менеджер пытается командовать коллегами-разработчиками: назначает работу, выступает на собраниях и, как правило, стремится участвовать в принятии более стратегических решений. Поэтому их не любят в равной степени и коллеги-разработчики, и другие менеджеры, которые видят угрозу своей работе.
Невозможно решить проблему честолюбивого менеджера, потому что он уже сделал чёткий карьерный выбор. Как только решение принято, пути назад нет. Вы не можете заставить его опять писать программы. Даже если заставить, то вскоре вы обнаружите причину, по которой он стал честолюбивым менеджером: парень не очень хорош в программировании. Из-за сложности этой ситуации так много честолюбивых менеджеров получают то, чего хотят: повышаются до должности менеджера, при наличии свободной вакансии.
Как правило, разработчики в этом положении не особенно вредны проекту, потому что их производительность слишком низка, а они обычно не владеют особым доверием ни разработчиков, ни менеджеров. Часто эти люди на протяжении всей карьеры болтаются по организации, а высшее руководство изо всех сил пытается найти им применение. В этом качестве они могут стать опасными, если им поручена критически важная задача, но поскольку этого можно полностью избежать, они могут безопасно оставаться просто мелким раздражающим фактором.
Разработчик, который написал часть критически важного программного обеспечения и не даёт никому работать над ним, чтобы сохранить свою незаменимость.
Любому человеку с финансовыми обязательствами важно обеспечить сохранность своего рабочего места и зарплаты. Кроме того, работать со знакомым кодом намного проще, чем с незнакомым. Из сочетания этих двух желаний рождается захватчик заложников — разработчик, который написал и единолично владеет критической частью программного обеспечения, отказываясь работать над чем-то ещё.
Как правило, это плохой инженер-программист, что по иронии становится важным преимуществом: его код обычно не понятен больше никому, так что другие разработчики боятся залазить в такое болото, опасаясь причинить больше вреда, чем пользы. Поэтому все новые работы над критически важной системой переходят к захватчику, тем самым продолжая порочный круг.
Захватчик заложников обычно занимает оборонительную и конфронтационную позицию, он абсолютно закрыт для критики или сотрудничества в отношении его кодовой базы. Если его действительно загнать в угол, он будет угрожать уйти, а поскольку никто другой не хочет брать на себя плохо спроектированный и написанный продукт, такой блеф редко наказывают. Они могут стать узким местом в проекте, так как вся судьба проекта будет зависеть от их желания и умения выдать код.
Как ни опасен захватчик заложников, решение простое: возложить на двух или более разработчиков ответственность за часть системы захватчика, его перевести на другую часть. Некоторое время производительность будет низкая, пока новые разработчики попытаются понять и переработать код, но по окончании этого периода захватчик полностью нейтрализован и больше не представит проблемы.
Разработчик настолько сосредоточенный на завершении работы, что полностью отказывается от любого понятия качества.
На разработчиков всегда оказывается огромное давление. «Интернет никогда не спит» означает, что часто разработчики тоже не спят. Чтобы вернуть подобие баланса между работой и жизнью, слон в посудной лавке хочет как можно быстрее завершить свой список задач и вернуться домой к семье.
Программистов такого типа создаёт давление проекта. Независимо от того, насколько хорош разработчик, если давление возрастёт до определённой степени, он неизбежно прекратит тестирование собственной работы и вместо этого понадеется на отдел тестирования (см. тип тестировщика обвинитель [24]) в качестве единственного средства для поиска ошибок. Кроме того, для удобства они откажутся от коллегиальной проверки кода, автоматического тестирования и рефакторинга, оставив код в аварийном состоянии. Это плохо разработанное программное обеспечение затем вызывает новые ошибки, и кодовая база быстро превращается в болото багов, которые невозможно исправить полностью.
Слон в посудной лавке живёт в постоянном стрессе из-за давления начальства. Он — жертва плохо спланированного проекта, но проблемой всё равно считают разработчика. Именно в отношении слонов в посудной лавке используется фраза «выгорание и замена», так как постоянный стресс в конечном итоге сломает их, и они либо уйдут, либо будут уволены из-за их кажущейся некомпетентности.
Поскольку проблема не в человеке, организация должна предпринять следующие шаги:
Хотя эти шаги позволяют чётко решить проблему, их почти никогда не предпринимают. То есть менеджмент остаётся причиной проблемы, а не источником решения. Но если руководство признает свою роль в появлении слонов в посудной лавке, то через несколько недель ущерб можно компенсировать, а разработка проекта вернётся в нормальное русло.
Разработчик, которому не хватает интеллекта или навыков для написания программного обеспечения.
Не каждый способен стать профессиональным спортсменом или опытным музыкантом, или врачом. Также есть люди, которые просто не созданы, чтобы быть разработчиками программного обеспечения. Эти некомпетентные разработчики часто отрицают свою некомпетентность и отказываются уходить из профессии из-за высокой зарплаты и большого количества доступных вакансий.
Менеджеру без технического образования может быть сложно распознать некомпетентного разработчика, но есть несколько признаков:
Вся индустрия программного обеспечения страдает от проблемы некомпетентности. Это простой пример спроса и предложения, когда на рынке труда не хватает квалифицированных разработчиков.
Когда менеджер замечает некомпетентного разработчика, то естественное чувство сопереживания часто подталкивает назначить ему задачи полегче. К сожалению, так же как нельзя быть полуграмотным кардиохирургом или частично компетентным пилотом, никто не может быть лишь частично компетентным разработчиком программного обеспечения. Если вам не хватает компетенции для разработки программного обеспечения, то вы не сможете хорошо выполнять даже простые задачи.
Когда простые задачи оказываются слишком сложными, следующим шагом обычно становится выделение бюджета на обучение. Здесь основная проблема в том, что если бы некомпетентный разработчик мог научиться, он бы уже это сделал — как его более компетентные коллеги, поскольку компетентные разработчики обучаются сами.
Существует мысль, что наличие не очень продуктивного разработчика в штате не причиняет вреда, но это большая ошибка. Они вызывают два очень разрушительных эффекта:
В конечном счёте, если проект зависит от некомпетентного разработчика, то проект не будет выполнен. Это приводит к печальному выводу, что таким работникам нужно покинуть организацию. Если они не соглашаются (обычно после всё более прямых намёков), то их следует уволить.
Разработчик, который постоянно недооценивает количество времени, необходимое для выполнения задачи.
Недооценка сроков является настолько распространённым симптомом в индустрии программного обеспечения, что многие даже не считают это проблемой. Все всегда недооценивают сроки, а во многих случаях это принимается как часть бизнеса. Тем не менее, разработчик-оптимист выводит проблему на совершенно новый уровень, так как он практически всегда сдаёт работу намного позже.
Оптимист влияет на предсказуемость проекта: без хороших оценок невозможно планировать будущее. Выпуск программного обеспечения иногда связан с договорными обязательствами с клиентами и/или партнёрами, что делает предсказуемость бизнес-необходимостью. Конечно, всегда можно ожидать немного непредсказуемости, так как в реальности вся индустрия программного обеспечения построена вокруг того факта, что нельзя точно предсказать, сколько времени займет написание софта. Оптимист злоупотребляет этой терпимостью за срыв сроков, выполняя свои задачи за несколько недель вместо обещанных пары дней; или, что ещё хуже, за несколько месяцев вместо обещанных пары недель.
Оптимист фундаментально не понимает негативное влияние такого рода задержек на общий успех проекта. Он может также считать, что сама оценка является бесполезной практикой, поскольку ничто никогда нельзя точно оценить. Таким образом, он может вальяжно отнестись к оценке или выдать произвольное число без какого-то анализа.
К счастью, оптимиста можно исправить, соблюдая нескольких правил:
Когда оптимист прошёл несколько раз через этот процесс и выполнил свои обязательства, вы можете начать доверять его оценке сроков для новых функций, а также для кодовых баз и технологий, с которыми он менее знаком.
Во время процесса реабилитации оптимиста обратите пристальное внимание на то, как он соблюдает свои сроки:
Если оптимист серьёзно относится к своей реабилитации, он может вырасти в пользующегося высоким доверием члена команды, ведь доверием пользуются разработчики, которые выдают соответствующий требованиям код достаточного качества в согласованные сроки. Как только они докажут, что могут стабильно делать это, то могут получить повышение в должности или в зарплате, что само по себе можно предложить в качестве стимула для их реабилитации.
Разработчик, который настолько боится пропустить сроки, что просит максимально возможное время на выполнение задачи.
Если есть возможность выбора, большинство менеджеров проектов предпочли бы пессимистов, чем оптимистов. Хотя они могут работать долго, но они хотя бы предсказуемы. Пессимист очень хорошо это знает и в полной мере использует данное обстоятельство, запрашивая для своей задачи максимальное время вместо того, чтобы рассмотреть реалистичные сроки.
Пессимистов иногда невозможно заметить. Их можно ошибочно принять за зрелых и ответственных, поскольку в отличие от своих, казалось бы, менее опытных коллег-разработчиков, они никогда не пропускают дедлайн. Но есть некоторые признаки:
Пессимист может уменьшить конкурентоспособность компании. Если вы вовлечены в гонку с конкурентом, то всегда будете медленнее него.
Пессимисты рождаются по вине организации, которая наказывает за срыв сроков. Естественная реакция людей — запрашивать как можно больше времени, чтобы свести к минимуму вероятность наказания. Может показаться, что это легко исправить, но против вас работают три вещи:
Поэтому проблема исправима, но обычно нет воли для её исправления. По своей природе пессимисты не представляют угрозы проекту, но потенциально очень опасны для будущей жизнеспособности компании.
Разработчик, который делает именно то, что ему говорят, без вопросов, независимо от того, правильно ли это.
С точки зрения менеджера, кто может быть лучше разработчика, который делает в точности то, что сказано? Действительно, ключевая проблема с примадонной заключается в том, что он не выполняет распоряжения. Безусловно, полностью послушный разработчик является благом для проекта. К сожалению, у солдата есть свой недостаток: он послушно прыгнет в пропасть, если ему так скажут, утащив с собой весь проект.
Солдат может быть любого уровня компетентности: от некомпетентного [9] до рок-звезды [5]. Ключевой характеристикой является его послушание: каждый раз он будет делать в точности то, что вы ему скажете. Легко ошибиться, посчитав это эффектом фантастического лидерства, но превосходные начальники встречаются очень редко.
Солдаты рождаются несколькими способами:
В результате, как бы приятно ни казалось иметь в своём подчинении солдата, это вряд ли хорошо.
Если вы даёте правильные распоряжения, солдат не доставит никаких проблем. На самом деле при сильном руководстве наличие отряда солдат — весьма эффективное оружие. Но если вам нужна обратная связь от разработчиков, чтобы помочь совместно вести проект, вы не получите такого сотрудничества. Это оставляет вас в ситуации неизвестности, когда вы даже не знаете о том, что нечто упускаете. А солдат не расскажет.
Если вы можете определить причину, почему солдат беспрекословно вам подчиняется, то есть шанс её исправить. Однако по своей природе он не скажет открыто, почему стал таким. Как правило, солдат предпочитает общаться на конкретные рабочие темы. Если нажать и спросить, есть ли проблема, наиболее вероятный ответ «Нет», независимо от его истинных чувств.
Вы можете надеяться только на то, что о солдате расскажут его коллеги, но тогда они предадут его доверие, что вряд ли произойдёт. Даже если вы определите истинную проблему, то придётся её исправить, что может быть трудно. Затем после устранения первопричины остаётся надеяться, что солдат изменит свое поведение. Только он сам может изменить себя.
В целом, их практически невозможно исправить. Таким образом, это обычно хорошие работники для поддержки сильного лидера.
Разработчик, который так рад попробовать новые технологии, что будет внедрять их в проект, уместно это или нет.
Для успешного запуска продукта необходимо выбрать технологию. Это тщательный выбор с вниманием к конкретному набору бизнес-проблем, которые необходимо решить. А фанат технологий просто любит новые игрушки.
Все разработчики в какой-то степени влюблены в технологии: они должны быть такими, чтобы поддерживать свои навыки. Но когда разработчик путает свою профессиональную ответственность и личное любопытство, вы можете в итоге остаться с технологическим стеком, который дико не соответствует бизнес-задачам.
Влюблённого в технологии разработчика очень легко выделить из толпы. Он будет часто и публично выступать за использование новой технологии, часто с неубедительными аргументами. Он также внезапно меняет технологии посреди работы, никому не говоря, застигая других врасплох. Во многих случаях это может быть действительно превосходное техническое решение конкретной проблемы, но поскольку технология не прошла надлежащей проверки, она может фактически плохо подходить для проекта в целом.
Фанаты технологий исправляются сами собой, если компания установила стандартный технологический стек. Затем требуется всего лишь следить, чтобы разработчики не отклонялись от него. Если у вас нет установленного стека технологий, настоятельно рекомендуется определить его заранее, так как будет неудобно вводить его после того, как фанат технологий начнёт активничать.
Новость о том, что нельзя использовать свою новую технологию, скорее всего, повредит моральному духу любителя технологий, но этот моральный дух можно быстро восстановить, попросив его сделать презентацию об этой новой технологии. Это чрезвычайно здоровое решение, потому что после презентации команда может совместно обсудить, есть ли смысл расширить стек корпоративных технологий. Большинство любителей технологий будут удовлетворены таким судилищем, даже если им не понравится окончательное решение.
Разработчик, единственной способностью которого является обслуживание устаревшего программного обеспечения, и поэтому он не в состоянии взять на себя новую работу.
Когда в компанию приходит новый разработчик, он обычно полон огня и страсти, пытается всячески проявить себя. Но со временем место страсти занимает самоуспокоенность: разработчик считает, что стаж в компании даёт ему некие привилегии. За собой он признаёт обязанность поддерживать свои системы, но не браться за разработку новых частей.
Проблема с хранителем легаси-кода связана с масштабированием: они просто не входят в пул доступных ресурсов для новой работы. В этот момент возникает вопрос, можете ли вы позволить себе держать их в штате, то есть могут ли другие разработчики взять на себя их задачи по обслуживанию легаси-кода. Обычно трудно убедить других разработчиков сделать это по двум причинам:
Вот почему старые мейнтейнеры остаются в компании так долго. Часто они были в компании с момента её создания и являются авторами программного обеспечения, на котором построена компания. Однако по мере роста компании они не продвигались по службе или не пытались овладеть новыми навыками или новыми частями системы, в результате чего прочно привязались к единственному известному им коду.
Хранитель легаси-кода не создаёт проблем, если понимать, что он не входит в число ресурсов для работы над новыми проектами. В лучшем случае его можно попросить исправить ошибки и реализовать небольшие улучшения функций. Единственная проблема возникает, если они запрещают другим ознакомиться со своей частью системы (см. захватчик заложников [7]).
Хранителя невозможно исправить, потому что у него нет такого желания. У него менталитет как у рабочего на заводе: крутить одну и ту же гайку каждый день на протяжении всей карьеры, а затем уйти на пенсию. Такое отношение невозможно изменить, поскольку оно составляет суть человека.
Один из вариантов, который может изменить такое отношение — если человек переживёт значительные события в жизни (свадьба, рождение ребёнка, покупка дома и т. д.), что потребует дополнительного заработка. В этом случае он поймёт, что поддержка устаревшего программного обеспечения не приведёт к повышению. К сожалению, вы не контролируете этот фактор.
Автор: m1rko
Источник [28]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/300657
Ссылки в тексте:
[1] буквально: http://onlygold.com/Info/Value-Your-Weight-In-Gold.asp
[2] проблемные личности: https://neilonsoftware.com/books/personality-patterns-of-problematic-projects/
[3] Примадонна: #1
[4] Идеалист: #2
[5] Рок-звезда: #3
[6] Честолюбивый менеджер: #4
[7] Захватчик заложников: #5
[8] Слон в посудной лавке: #6
[9] Некомпетентный: #7
[10] Оптимист: #8
[11] Пессимист: #9
[12] Солдат: #10
[13] Фанат технологий: #11
[14] Хранитель легаси-кода: #12
[15] капитан команды: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/project-managers/the-cheerleader/
[16] мышления: http://www.braintools.ru
[17] оптимист: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/project-managers/the-optimist/
[18] бывший технарь: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/development-managers/the-formerly-technical/
[19] карьерист: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/development-managers/the-ladder-climber/
[20] статистик: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/project-managers/the-statistician/
[21] планировщик встреч: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/project-managers/the-meeting-scheduler/
[22] тиран: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/project-managers/the-tyrant/
[23] пожарный шланг: https://neilonsoftware.com/books/personality-patterns-of-problematic-projects/quality-assurance/the-firehose/
[24] обвинитель: https://neilonsoftware.com/books/personality-patterns-of-problematic-projects/quality-assurance/the-blamer/
[25] без технической подготовки: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/development-managers/the-non-technical/
[26] пессимистом: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/project-managers/the-pessimist/
[27] креативным: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/designers/the-artist/
[28] Источник: https://habr.com/post/431534/?utm_campaign=431534
Нажмите здесь для печати.