Pull to refresh

В защиту разработчиков

Reading time 2 min
Views 742
Хочу поделиться с хабровчанами некоторыми мыслями о организационных проблемах в современных АйТи-компаниях. Каждая мысль оформлена в виде социального анти-паттерна и дополняет собой известный список на Википедии..
  • Плохая команда
  • Неэффективная команда
  • Система взаимных претензий
  • Текучка кадров
  • Отсутствие исполнительной власти

Описание:
  • Плохая команда. Менеджеры делятся на 2 категории: хорошие и плохие. Плохой менеджер всегда винит разработчиков, они всегда во всём его подводят. Хороший менеджер всегда винит себя. Этому есть простое объяснение — хороший менеджер работает с командой, то есть учит команду, увольняет плохих сотрудников, трезво оценивает ситуацию в течении всего времени работы над проектом, чтобы не доводить до критической точки. Этому существует простое объяснение — хороший менеджер обычно имеет долю с проекта.

  • Неэффективная команда. Разработчик не обязан самостоятельно повышать свой профессиональный уровень. Нет, он конечно может это сделать, но требовать это от всех — глупо.

    Представьте себе, вы приходите на первый курс любого университета и говорите: «Ребята, вы можете стать велики режиссёрами, актёрами, певцами, политическими деятелями, учёными..., но только вам надо: учиться, повышать свой профессиональный уровень, быть взвешенными… и т.д.»; Все станут? Нет! Им были созданы условия? Безусловно!

    Так и разработчик, он работает в рамках созданных условий, но не обязан работать на максимуме. Хочешь повышать эффективность — работай с командой, работай над командой, увольняй в конце-концов неэффективных сотрудников.

  • Система взаимных претензий. На мой взгляд основной сдерживающий фактор роста любой компании. Разработчики думают так: «Чё я должен рвать попу для этой компании? Она постоянно нас обманывает и кормит обещаниями». В свою очередь менеджеры говорят разработчикам: «Пока не будете работать эффективно и ожидаемо мы не будем: повышать зарплату, улучшать условия труда...». Это путь в никуда, так как никто кроме тебя не начнёт идти на уступки.

  • Текучка кадров. Любые проблемы для себя разработчик решает банальным увольнением. Текучка кадров — лучший балансирующий фактор, так как на новом месте первое время сотрудника не трогают, а текучка лучше всего получается именно у рядовых сотрудников, поскольку они наименее привязаны к кормушке текущей компании. С текучкой не нужно бороться, нужно бороться с проблемами её порождающими.

  • Отсутствие исполнительной власти. Любые сложные бонусные системы, процессы, методологии разработки вводимые для решения проблем работать не будут. И этому есть одна простая причина — есть закон, нет исполнителя. А согласно принципу разделения властей законы сами по себе не работают, так как нужен исполнитель. А для того, чтобы исполнитель на своём месте соблюдал закон нужен аудит (судебная власть) и профсоюзы. Аудит защищает компании, а профсоюзы — разработчиков. Я думаю на западе не дураки сидят, раз они пользуются такой схемой довольно давно.

Ну ладно, повитали в облаках и хватит. Назад к работе, вперёд к новым свершениям.

P.S. Буду благодарен за любые мысли по этому поводу.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+2
Comments 9
Comments Comments 9

Articles