Как уменьшить производительность отдела, увеличив численность.

А расскажу-ка я байку. Нельзя сказать, что в ней все придумано. Но все совпадения с ситуацией в реальной компании случайны.


Жила была команда программистов. Для простоты предположим, что они не выполняли никаких работ связанных с аналитикой, архитектурой, GUI и написанием технической документацией, т.к. писали они расчетные модули и всю аналитику и описание API им спускали сверху. И было их 8 человек. Нормальная такая agile команда.Надо сказать, что модуль расчета квартплаты или трафика сотового оператора - вещь сложная и закодировать это дело без ошибок удается редко. Я бы даже сказал, исчезающе редко. Соответственно, тестированием тоже приходилось заниматься. И тратилось на тестирование половина времени программистов. Иногда больше, иногда меньше. Естественно, что такое положение дел никого не устраивало.Но узнало начальство, что в деле тестирования тестировщики более производительны, нежели кодировщики.  Для простоты будем считать, что в два раза [1]. Другими словами - один тестировщик в деле тестирования двух программистов накормит. Прошу прощения, заменит.
И вот настал замечательный день. В коллектив влился тестировщик. Начальство обнародавало приказ, что с текущего дня каждый занимается своим делом. Кодировщики, пардон, программисты - кодируют, а тестировщики - тестируют. Программисты вздохнули с облегчением и пошли заниматься любимым делом. И зажили они в ладу и свокойствии.

А что стало с общим выхлопом отдела? Ведь не просто так все затевалось.

Элементарный расчет показывает, что совокупный выхлоп отдела упал в два раза.Вдумайтесь в это. Был принят еще один человек, т.е. увеличены расходы, и … И производительность отдела сократилась вдвое. Опана.

Такое уменьшение неспособен вызвать ни один “активно невовлеченный”. Да и для профессионального  диверсанта такой результат является едва ли не мечтой. Но ведь не было, не было диверсанта! И люди все были хорошие. По настоящему радеющие за успех.

А объяснение простое. Некомпетентность руководства (незнание основ управления производством) привело к тому, что сочетание факторов:

  • Положение “каждый занимается своим делом”
  • Несоответствие между  соотношениям трудоемкостей операций и обеспечением сотрудниками

привело к катастрофе. Скажете так не бывает? Еще как бывает. Встречается сплошь и рядом [2].

Что можно сделать в данной ситуации. Про курсы повышение квалификации или замену руководство все понятно. А что хороший руководитель должен сделать?

Вариантов решения несколько.

  1. Сохранить кроссфункциональность. Т.е. программисты все равно будут не только кодировать, но и тестировать тоже. Иными словами это ликвидация парадигмы: “Для достижения максимальной эффективности каждого сотрудника, каждый сотрудник занимается только своим делом”.
  2. Нанять  еще тестировщиков. Кстати, вопрос к знатокам. Сколько должно быть тестировщиков с учетом рисков заболевания/увольнения и девиаций трудоемкостей от проекта к проекту?

Вышеописанная ситуация - это замечательная питательная среда, для появления 10 признаков активно невовлеченного в компанию сотрудника, как утверждает Алена. Я же утверждаю, что это 10 признаков, указывающих, на возможную некомпетентность топ менеджмента и сотрудников отдела по борьбе с персоналом. А в остальном это хорошая реакция хорошего сотрудника на плохую рабочую обстановку.


[1] Мои наблюдения показывают, что скорее в 3-5 раз.

[2] Падение выхлопа из-за безграмотного управления всего в два раза - это еще отличный результат. Даже падение в 10 раз не редкость.

Комментариев: 4

  1. astenix написал:

    Сколько должно быть тестировщиков с учетом рисков заболевания/увольнения и девиаций трудоемкостей от проекта к проекту?

    Если учесть указанный размер команды, то не меньше двух ;)

  2. SALar написал:

    > Если учесть указанный размер команды, то не меньше двух.

    Неверно. В этом случае выхлоп команды будет чуть меньше, чем до принятия тестировщиков.
    Если же считать без рисков и без девиаций, то производительность останется той же, при возросшей себестоимости.

    PS. На этом блоге премодерация.

  3. Little_CJIOH написал:

    4 будут успевать за 8 разработчиками, при этом выхлоп команды “должен” удвоится.
    5-й даст возможность “проглатывать” всплески загрузки, отпуска и больничные, но не одновременно. Только отпуска дадут уже 5 месяцев работы команды тестирования на пределе. и в эти 5 месяцев не будет защиты от больничных. Хотя, 7 месяцев в году разработчиков будет не 8, а 7.
    Но все-равно, чтоб совсем надежно и с возможностью работать на развитие и опережение их должно быть 6.

  4. SALar написал:

    2Little_CJIOH
    Пятый тестировщик дает запас прочности как раз в те самые 20-25%. Достаточен ли такой запас или нет - зависит от необходимой скорости обратной связи. В большинстве случаев будет достаточно.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.