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