Советы Заказчику: Разделяемая Задача

English  Русский 

Разделенная команда

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

Я неоднократно рассказывал о том, какие проблемы есть при общении команды со стороны Заказчика и удаленной командой разработки. Рассматриваю некоторые типичные проблемы на примере реальных кейсов, выступаю на конференциях (видео с Software People  11). И если в своих выступлениях делал акцент на действиях команды-исполнителя, то сейчас хочу остановиться на том, что может сделать Заказчик или менеджер для лучшего взаимодействия команд.

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

Но в этой практике (как и в любой другой) есть и свои большие недостатки.

Вся команда не проходит стадии Forming – Storming – Norming – Performing

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

В дополнение к этому, из-за ограниченных коммуникаций (программисты сказали бы интерфейсами), конфликты (которые неизбежны на стадии Storming) будут скорее затухать и тлеть, а не разрешаться. И при любом удобном случае будут вспыхивать снова.

Потенциал команд будет не полностью раскрыт

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

Каждая из команд не будет заинтересована в успехе другой. Главным аргументов в этом будет: «Мы свою часть сделали, проблемы на их стороне». А вторая команда вряд ли попросит помощи, так как это будет признание (пусть даже неявное) их слабости.

Усиливается обособленность команд

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

Команды знают только одну часть проекта

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

Но нельзя рассматривать такой метод ведения бизнеса как однозначно неправильный. Ведь так уже работают множество команд. И самое важное – они добились успеха при такой схеме работы.  Специализация и простые коммуникации внутри команды однозначно помогали и помогают делать задачи быстро и хорошо.

Когда стоит делать упор на специализацию?

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

Как сохранить специализацию команд и при этом не добавить рисков?

Самый простой способ – иногда давать кросс-функциональные задачи нескольким сотрудникам из разных команд. При этом главное условие – цель может быть достигнута только при взаимодействии друг с другом. Оправдание «Я свою часть сделал» не принимается и задача сделана только тогда, когда все ее части выполнены.

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

В этом разделе можно прочитать еще несколько интересных “Советов Заказчику”

Aug 28th, 2011
  1. Aug 30th, 2011 at 06:13 | #1

    А по моему опыту, команды не любят периодическую кросс-функциональность. Люди вполне справедливо заметят – “а какого он меня дергает?То то, то это. Оно мне нужно?”

    Нацеленность на “мы все единая команда” чаще всего не работает, и обычно раздражает. Не бывает единой команды, если все сидят на мягких стульях в разных местах. Единая команда бывает не более 2-5 человек. В танке, за орудием, в бизнесе, в семье.

    Также умные люди – индивидуалисты. И часто любят пилить свою одну гайку, а не участвовать в “учебных тревогах и кружках самодеятельности”.

    Да и последний пункт очень спорный. Колхоз одним словом. Ктоме того это справедливо “С самого начала такие задачи будут решаться сложнее и с большими потерями на коммуникации, но после нескольких попыток …” 80% что или следующих попыток не будет, ибо народ свалит, или доверие к менеджеру будет полностью подорвано и будет еще хуже.

  2. Aug 30th, 2011 at 19:25 | #2

    Андрей,

    главная мысль как обычно в конце: такие задачи нужно давать ИНОГДА. При постоянном ассайменте они будут раздражать.

    А иногда – они будут объединять и стимулировать.

    Менеджер существует не только, чтобы делать “хорошо всем” ему еще нужно думать о многих вещах будь то обмен знаниями, налаживание связей с другими командами и т.д.

  3. Andrey
    Aug 31st, 2011 at 03:59 | #3

    Именно. О многих вещах -)

    Сергей, я вас понимаю, и я с вами не согласен.

    Возможно, мы под кросс-функциями понимаем ее разную степень.

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

    И возможно не стоит на эту же задачу ставить человека пишущего модули красивой визуализации (канва и тп…).

    Я лично видел, как попытка ввести кросс-функциональность, а по мне так просто желание поднять маржу и сесть одной попой на два стула, привело к полной дезинтеграции группы из 14 человек за пол года. Про маржу даже не упоминаю -).

    As end. ИМХО. Очень осторожно и договорившись. Есть серьезные риски. Ибо если брали человека на одно, а потом еще ему сваливают общественную нагрузку, стоит передоговориться вначале

    ps/ в таких делах я стараюсь использовать психологический портрет (Маерс-Бригс + Адизес) и степень квалификации/специализации.

  4. Aug 31st, 2011 at 20:57 | #4

    По поводу этой статьи идет еще интересный тред дискусии на LinkedIn: http://linkd.in/oQjO9p

  5. Александр
    Sep 2nd, 2011 at 10:46 | #5

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

    Об этом говорят такие фразы как:
    - “Поэтому мы идем по пути наименьшего сопротивления и «разделяем» задачи на максимально независимые друг от друга.”
    - “В итоге каждая команда будет знать только «свои части системы».”
    - “Если одна команда хорошо делает какую-то часть проекта, то со временем уже даже не возникнет мысль о передаче части этой работы кому-то из другой команды.”
    - “Несмотря на то, что работают над одним проектом, они просто не будут знать того, как устроена другая часть системы.”
    - “стратегия «разделяй и властвуй» вероятно, привнесет больше рисков, чем доходов.”

    Судя из выше перечисленного вам вероятно неведомо почему существует специализация (не только в разработке ПО, но и в промышленности, науке) и что означают понятия “синтез” и “декомпозиция”

    Единственное что внушает надежду так это ваша фраза что “нельзя рассматривать такой метод ведения бизнеса как однозначно неправильный. Ведь так уже работают множество команд. И самое важное – они добились успеха при такой схеме работы. “. Если высумели обратить внимание на успешность существующей схемы, значит сможете разобраться и в причинах этого успеха. Так что удачи.

    • Sep 9th, 2011 at 16:44 | #6

      Александр,

      Был в отпуске, поэтому запоздал с ответом.

      Вместо вступления: За всю свою практику прекрасно понимал весь жизненный цикл ПО (образование как-никак техническое). Да и последние лет 5 работаю только с Enterprise level системами, которые разрабатываются большими командами. /вступления

      Почему такая задача не попадает под определения “Де-композиции” я не понимаю. Есть спецы из разных областей, которым поставлена общая задача. Почему их совместная работа нарушит хоть какой-то принцип декомпозиции (специально перечитал Вики о значении этого термина). Декомпозиция – метод решения, а разделяемая задача – просто специфическая цель.

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

      Кстати, раз мы заговорили о синтезе в науке, то хочу обратить Ваше внимание, что самые последние достижения науки как раз сделаны на пересечении разных наук (синтез, синергия, …).
      Кроме этого, узкая специализация – это грустно. Роберт Хайнлайн сказал: “Specialization is for Insects”

Leave a comment