Subject:

Взаимозаменимость сотрудников vs Узкая специализация

Issue ID #125 

Reported at 15.02.2014

Reported byNatalya Rukol

Project Управление командой

Severity Major 

Tags ,

Последнее время популярно говорить про взаимозаменяемость сотрудников, при которой любой член команды может выполнять примерно одни и те же задачи. Этому нас учат lean и kaizen, об этом упоминается в Scrum’e. Действительно, кажется логичным — когда сотрудники взаимозаменимы, решается множество проблем:

  • Если кто-то уходит в отпуск — это не страшно, другие сотрудники тоже «в теме»;
  • Уволился сотрудник? Не беда!
  • Нужно перебросить ресурсы между задачами/проектами/командами? Отлично, у нас кто угодно справится с любыми задачами!

Результат, кажется, выглядит неплохо. НО!

Давайте представим, что интеллектуальные ресурсы каждого человека ограничены неким набором «пунктов квалификации». Тогда, примерно схожие «универсальные» сотрудники будут иметь примерно следующее распределение квалификации:

ОК, это может быть удобно, но давайте посмотрим на распределение квалификации в случае более узкой специализации сотрудников:

Каждый из сотрудников минимально дублирует одни и те же навыки, но в чём-то своём выступает более «крутым» специалистом. На выходе мы получаем суммарно значительно более высокую квалификацию команды.

Если раньше у нас все знали «как записывать автотестики через рекорд-энд-реплей», то теперь у нас есть ОДИН специалист, который может разрабатывать автотесты ХОРОШО. Если раньше мы все дружно тестировали безопасность «по чек-листу ручками», то теперь у нас есть человек, который умеет использовать сторонние утилиты, осуществляет те же простые проверки в 5 раз быстрее, а в освобождённое время находит ещё множество уязвимостей, которые «недоспециалисты» по безопасности и найти бы не смогли. Вместе неэффективного тест-дизайна мы теперь можем создавать действительно отличные тестовые наборы, с хорошим покрытием и маленьким количеством тестов… И мы можем помогать друг другу! Например, тест-дизайнер может помочь с тестами автоматизатору, автоматизатор поможет с фреймворком нагрузочнику, а юзабилист предоставит сценарии, роли и ментальные модели тест-дизайнеру.

Казалось бы, идиллия. НО!

Управлять командой из уникальных людей значительно сложнее:

  • Сложно решать проблемы из-за болезней, отпусков, отгулов и увольнений;
  • Необходимо грамотнее планировать для обеспечения равномерной загрузки
  • Важна слаженность в работе команды, умение договориться и принять превосходство ВСЕХ ДРУГИХ членов команды перед тобой… В не твоей специализации.

В результате, чтобы решить проблемы с управлением, многие менеджеры пытаются копипастить/клонировать каких-то «стандартных» сотрудников.

Но так вы существенно уменьшаете суммарную квалификацию команды! Команда — это слаженный организм. Хотите поменять свои сердце и печень на ещё парочку почек для стандартизации и взаимозаменимости?

Упс… А без сердца-то не получится… И без печени тоже?

Без уникальных, сильных профессионалов в своём деле тоже невозможно достигать действительно высоких результатов!

  • Maxim Zakharov

    Сужу по себе — добавил бы еще вот что.
    Лидить такую группу — задача нетривиальнейшая.
    У айтишников иерархия часто строится на скиллах и от лида могут ждать что он лучший безопасник, дизайнер и юзабилист и автотестер…
    В свое время победил это тем что был лучше — на старте, но ввиду наличия практики бойцы быстро обходили, по старой памяти все еще уважая.

    Еще момент — кроме осознания превосходства коллеги в не своей специализации, нужно уметь принимать ограничения бизнеса, которые руководитель лид транслирует в твою:
    - это разовая задача для неприоритетного клиента, костыляем прототип без документации,
    - с этим нам жить три года минимум, мы все знаем, что ты программист, сиди и пиши в вики архитектуру…

    По выводам полностью согласен. Такая группа сложнее, своенравней, гнет всех под себя и плюет на догмы, но именно она приближается к наличию смысла в своем существовании и именно в ней возможна самореализация.

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

    • http://natalyarukol.ru Natalya Rukol

      Да, согласна со всем написанным.

      Да, с такой командой сложнее по всем фронтам, и работать, и удерживать.

      Что же касается авторитета руководителя — то быть «круче всех и во всём сразу» всё равно невозможно. Если лид успешно выполняет свои менеджерские задачки и всем в команде понятно, зачем он, как менеджер, нужен, то таких проблем не возникает. А если менеджер пересылает туда-сюда письма и считает это управлением, то конечно сильная команда такого бесполезного манагера не примет.

  • Марина Селиванова

    Поделитесь, где такая команда есть? Ну чтобы не полтора тестировщика, которые пытаются объять необъятное, а чтобы и тест-дизайн, и безопасность, и нагрузка :)

    Есть предположение, что во многих компаниях задачи по той же безопасности (юзабилити, нагрузке и т.п.) возникают эпизодически, поэтому держать крутого специалиста в этой области постоянно смысла нет (т.к. задач у человека не будет, а зарплату, причем немаленькую, платить придется). Поэтому «в среднем по больнице» и стараются найти «стандартных» сотрудников, которые будут делать средние задачи на среднем уровне за средние деньги

    • Maxim Zakharov

      Лично знаком с командой, где были специализации: тест-аналитика, тестирование производительности, администрирование тестовых сред. Задачи по специализации отнимали от четверти до половины времени.

    • http://natalyarukol.ru Natalya Rukol

      Такие команды последнее время, к счастью, не редкость.

      Не все спецы оправданы — согласна. Но я вообще схему очень упростила, и навыков в тестировании не 5, а в десятки раз больше, а ещё есть знание продукта, технологий, прикладных областей. Что именно важно в вашей компании, что критичнее всего и на чём надо специализироваться — решать только вам.

    • http://xwizard-test.blogspot.ru/ Timur Nurlygayanov

      Такие существуют, вот у нас сейчас 5 Senior QA инженеров, активно развивающийся проект )

  • Рина Ужевко

    Все это круто. НО — решение проблем то где?
    Когда каждый делает что-то — ок, проблема в том, что делают это толпой и их надо организовавывать (при этом я б добавила, каждый еще «лезет» в чужой монастырь с своими советами и не всегда это клево)

    такого подбора сотрудников придерживается большинство.
    Но, второй вариант мне нравится больше.

    но в нем я вижу только один способ решения трех проблем (в части увольнения, больничного и пр) — должна быть замена тому специалисту. т.е. автоматизаторов нужно хотя бы 2. И в отпуска обоих не отпускать.
    НО один может уйти в отпуск, а второй заболеть.
    как в этом случае быть? Заказчику врядли понравится, что сроки сдвигаются.

    Вобщем, как решать проблему человеческого фактора таки непонятно.

    Как вариант стремится к второй команде, но перекрывать, хотя бы, критические части тестирования. Хотя их выделить будет сложно также.

    Короче, вопрос философский. И ответа так и нет. ( Особенно, если вы не крупная компания где есть целый отдел тест-дизайнеров, команда автоматизаторов и т.д.

    • http://natalyarukol.ru Natalya Rukol

      Ты приходишь в магазин, у тебя в кошельке последние 50$ и ты хочешь купить себе подарок за 50$, но последние деньги жалко. Какое решение этой проблемы? Ты либо не покупаешь (плохо), либо остаёшься без денег (плохо).

      Всему своя цена. Либо в команде работают чайники и она медленно развивается, либо растут риски в пиковые нагрузки / отпуска и значительно сложнее управлять.

      Сытых волков и целых овец не бывает :(

      • Екатерина Гайнутдинова

        > Ты либо не покупаешь (плохо), либо остаёшься без денег (плохо).

        А как насчет варианта 20/30? — купил подарок, но меньше. оставил себе деньги, но меньше.

        И команда не полностью уникальная,а с небольшим дублированием. Всегда есть кто подхватит, конечно сделают не на 100% как раньше, а на 70%, но за отпуск основного, редко, надо все переписать всё с нуля, а для поддержки системы хватит и меньших скилов.

    • valerii potokov

      Да, Однозначного ответа нет. Как вы отметили, это вопрос в чем-то философский и связанный с общими вопросами культуры. В моем понимании это процесс требующий адаптации и терпения, как ни скучно это звучит. Первоначальную оценку сроков можно достаточно уверенно умножить на два. Потому что работают реальные люди, они могут временно отсутствовать и «обязательно» встретятся «маленькие» непредсказуемые технические моменты требующие преодоления. 20% времени это создание базового функционала, 80% (приблизительно конечно) отладка, стабилизация процесса, текущее сопровождение. От того как проект архитектурно спроектироват зависит очень многое. Иначе нет конца исправлениям с печальным результатом. Кто-то сказал — Если сделаешь быстро, но плохо, то быстро забудут что сделано быстро, но всегда будут помнить что плохо; если сделано хорошо, но дольше по времени, то поймут и забудут срок, но будут знать что сделано хорошо.

  • http://devprom.ru Evgeny Savitsky

    Наташа, привет! Отличная визуализация и наглядно показывает в чем реальность сильно отличается от желанной для некоторых модели (универсальные винтики производства ПО)

    Однако, я бы предложил разобраться в терминах, у меня сложилось ощущение, что про разное написано.

    Например, существует отдельная управленческая проблема: среднячки vs «звезды», назовем ее №1

    Эта проблема не связана с кроссфункциональными командами (если говорить про Scrum), то есть такими, в которых представлены все роли, необходимые для выпуска программных продуктов.То есть появляется проблема №2: кроссфункциональность vs выделенность (отдел девелоперов, отдел тестеров, отдел аналитиков, все со своими начальниками, которые подчинены чуть ли не ген. диру)

    С другой стороны, кроссфункциональность часто путают с взаимозаменяемостью, что типа любой девелопер должен делать тест-дизайн так же хорошо как и специально обученные для этого люди. Этой проблеме лучше дать название №3: взаимозаменяемость vs уникальные специализации.

    Так вот, «звездность» и уникальность специализации ортогональны. В моей команде может быть очень «юный» автоматизатор, а все остальные не умеют (и не хотят!) писать тесты.

    На мой взгляд, самая правильная команда:
    а) является кроссфункциональной,
    б) содержит как минимум одного специалиста высокого уровня по своей дисциплине,
    в) члены команды хотят учиться и хотят учить.

    Такая команда сможет противостоять временным неурядицам (болезням или уходу людей)

    • valerii potokov

      Интересная статья. Но вот позволю себе небольшой комментарий по поводу последнего предложения.

      «Без уникальных, сильных профессионалов в своём деле тоже невозможно достигать действительно высоких результатов!»

      Получается как бы что «они» есть зло, но с этим приходится мириться. Этот момент всегда присутствует у менеджеров, даже вне зависимости «наших» или «ненаших». Идеально когда менеджер не позиционирует себя как технический лидер. Есть и способные к этому, но это исключение, в больших организациях у них не будет времени для совмещения. Он очень опытный технологически и мудрый организатор, знающий бизнес-задачи своего подразделения, заниманимающийся оценкой приоритетов, сбалансированностью команды, внешними сношениями, обосновывающий сроки в сторону интересов группы. Это трудно само по себе. Идеи и воплощения исходят все же от команды.

      • http://natalyarukol.ru Natalya Rukol

        Я не считаю, что «сложно» равно «зло». Да, сложно. Нет, не зло :)

        • valerii potokov

          Да конечно. Это неправильное слово которое я использовал. С уважением.

    • http://natalyarukol.ru Natalya Rukol

      Отлично сказано, подписываюсь:

      На мой взгляд, самая правильная команда:
      а) является кроссфункциональной,
      б) содержит как минимум одного специалиста высокого уровня по своей дисциплине,
      в) члены команды хотят учиться и хотят учить.

  • Timur Nurlygayanov

    Профессионалы обычно сами «разделяются» по обязанностям кто на чем специализируется. другое дело что хочется заниматься не «только своим», может быть уже надоевшим куском, а взять и пробовать что-то новенькое, запуская руки в чужую область ) Но договориться прокаченные инженеры всегда могут )
    Менеджить их, конечно, сложно, но никто не говорил что будет легко ) тут главное четко разделить роли и взять позицию что вы не будете каждому говорить как ему надо делать свою работу, а будете решать именно менеджеркие вопросы и со всеми договариваться. Быть тех. лидом среди прокаченных в разных областях специалистов это вообще сложно — всего не охватишь, но зато точно можно охватить требования продукта и его проектирования — кто способен это взять на себя, тот и будет в итоге тех лидом в такой команде, если тех лид им вообще нужен.

Social Widgets powered by AB-WebLog.com.