Ловушка незаменимого
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Еще в свою бытность разработчиком, встречал нескольких забавных ребят, которые считали себя незаменимыми, а по факту вели мало интересные для компании, но пока еще не закрытые проекты. Все как один писали на Perl. И жизнь у ребят была хороша (по их меркам). Переписывать проекты никто не будет, а пока их надо поддерживать, их не уволят, новых изменений почти нет. Насколько я знаю, проекты в итоге закрыли и куда ребята подались потом мне неизвестно. Но допустим, это случай не самый редкий, особенно в телекомах. Есть много “мертвых” стеков и систем, которые не хотят переписывать: работают и работают.
Но мы поговорим о более обыденной истории. Люди, которые не хотят делиться знаниями, чтобы их нельзя было уволить. В целом, стратегия понятная и работает до определенных пределов. Такие ребята обычно наглеют и леняться до такой степени, что в итоге вылетают за какой-то громкий косяк, который доходит до руководства (например сложат систему надолго и т.д.) и более высокое руководство, не погружаясь в детали их незаменимости, примет решение (видел такое не раз). Либо достанут своего руководителя так сильно, что он примет все возможные риски. Те, кто сидят тихо и не особо создают проблемы, и правда могут сидеть долго, держа в “заложниках” отдел или компанию.
Такие истории плохи в обе стороны, те, кто считают себя незаменимыми очень быстро теряют квалификацию и для них может стать большой проблемой поиск новой работы, когда такое случится.
Для компаний проблема будет в медленном развитии и сложностях с масштабированием, потому что пул задач может решить только один человек.
Лично я стараюсь выявлять таких людей на старте работы с командой. Дальше проводим беседы по необходимости передачи знаний, ставим задачи, выделяем людей, которые будут перенимать знания. Если знания передаются, то никаких проблем нет. Если знания держатся в человеке и он держится за них, то я явно предупреждаю его о грядущих проблемах. Дальше, при отсутствии прогресса, с человеком расстаемся, как бы тяжело это не было на начальных этапах. В этом году я расстался с такими людьми в двух командах, без передачи от них знаний. Сложности были в течении трех месяцев, но оно того стоило, в результате мы ушли от людей с уникальными знаниями.
Незаменимость вещь обманчивая, все когда-то кончается. А если вы руководитель, то это одна из зон повышенного внимания с вашей стороны, от таких зависимостей нужно избавляться.
Максим Шаламов
#советы #разработчику #руководителю
Лучшее враг хорошего. Как сделать так, чтобы инициатива не была наказуема?
Часто можно столкнуться с ситуацией, когда исполнители, из благих намерений, делают вещи, которые в рамках их задачи не ожидаются. Например: “а сделаю ка я рефакторинг проекта” или “поменяю методы, чтобы было удобнее” и т.д. В итоге, мы получаем либо срыв сроков, либо неожиданное поведение функционала, либо новые ошибки, а часто и комбинацию всего перечисленного. Как-то мы принимали дизайн для своего проекта и вместо дизайна лендинга нашего приложения, мы получили наброски персонажа для приложения. И вроде и идея хорошая, но и что делать с этим не понятно. Сроки дизайна лендинга сорваны и сделано не то, что надо было, а вроде идея то была хорошая.
Обычно тут случается неприятный разговор между руководителем / заказчиком и исполнителем. Оба остаются недовольными друг другом, а мотивация исполнителя подрывается.
Что делать руководителю
Ситуация и правда непростая, потому что людей, которые правда хотят делать хорошо, улучшать и развивать проекты, вкладывая сверхусилия, не так и много. Поэтому руководителям я рекомендую проводить разъяснительные беседы, как нужно такие вещи делать. То есть говорим, что рады старанию и вовлечению, но нужно сначала сделать свою запланированную часть, а дополнительные работы обсудить и согласовать, чтобы оно как минимум ничего не сломало и не противоречило заказу.
Что делать исполнителю
Исполнителям я бы посоветовал не забывать, что все таки наша основная цель - решать поставленные задачи. Непредсказуемое поведение, срывы сроков и тому подобное все равно будет идти в минус и вам, и проекту, для которого вы стараетесь. Хотите сделать больше - обсудите, что и как вы будете делать и вперед. Не делайте неприятных сюрпризов команде, заказчику и руководству, тогда ваши усилия принесут много пользы и вам и проекту.
Максим Шаламов
#советы
Часто можно столкнуться с ситуацией, когда исполнители, из благих намерений, делают вещи, которые в рамках их задачи не ожидаются. Например: “а сделаю ка я рефакторинг проекта” или “поменяю методы, чтобы было удобнее” и т.д. В итоге, мы получаем либо срыв сроков, либо неожиданное поведение функционала, либо новые ошибки, а часто и комбинацию всего перечисленного. Как-то мы принимали дизайн для своего проекта и вместо дизайна лендинга нашего приложения, мы получили наброски персонажа для приложения. И вроде и идея хорошая, но и что делать с этим не понятно. Сроки дизайна лендинга сорваны и сделано не то, что надо было, а вроде идея то была хорошая.
Обычно тут случается неприятный разговор между руководителем / заказчиком и исполнителем. Оба остаются недовольными друг другом, а мотивация исполнителя подрывается.
Что делать руководителю
Ситуация и правда непростая, потому что людей, которые правда хотят делать хорошо, улучшать и развивать проекты, вкладывая сверхусилия, не так и много. Поэтому руководителям я рекомендую проводить разъяснительные беседы, как нужно такие вещи делать. То есть говорим, что рады старанию и вовлечению, но нужно сначала сделать свою запланированную часть, а дополнительные работы обсудить и согласовать, чтобы оно как минимум ничего не сломало и не противоречило заказу.
Что делать исполнителю
Исполнителям я бы посоветовал не забывать, что все таки наша основная цель - решать поставленные задачи. Непредсказуемое поведение, срывы сроков и тому подобное все равно будет идти в минус и вам, и проекту, для которого вы стараетесь. Хотите сделать больше - обсудите, что и как вы будете делать и вперед. Не делайте неприятных сюрпризов команде, заказчику и руководству, тогда ваши усилия принесут много пользы и вам и проекту.
Максим Шаламов
#советы