• Кейс “Два в одном”

    Posted on September 18th, 2009 Александр Орлов 18 comments

    Новый пятничный кейс – о дублировании.

    Кейс “Два в одном”

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

    Час спорили про то, оставлять статус бага “LATER” в Багзилле или нет, потом обсуждали структуру пространства для кода тестовых сюит. И совсем не осталось времени на обсуждение тестовых скриптов. Дима, главный тестовый менеджер так и сказал напоследок: “Коллеги, не успеваем обсудить тестовые скрипты. Давайте послезавтра?”

    По пути на обед попался Иван, тех лид его команды. “О, вот и компания,” – обрадовался Леша и начал жаловаться подчиненному на менеджеров других городов: “Вообще ничего решить с ними не можем! Час, Ваня, час! Обсуждали статус LATER. Атас… Кстати, не посмотришь, как бы нам обустроить тестовые скрипты?”

    На следующий день Иван доложил, что все скрипты написаны, проверены и готовы к использованию. Это он после ужина посидел, пописал… Леша даже не удивился. Иван всегда отличался резкостью вкупе с производительностью. То, что другие делали неделю, он обычно укладывал в два часа.

    Леша решил не писать сразу о скриптах, а сначала их хорошенько самостоятельно оттестировать. Чтобы на совещании тестовых менеджеров ненароком так обронить: “Скрипты? А, кстати, мы тут посидели немного, и уже их написали.”

    На совещании, однако, случилась неожиданность. Оказалось, что московская команда тоже посидела и тоже написала аналогичные скрипты. Не на bash’е, как Иван, а на perl’е.

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

    Дима слушал их первые полчаса, после чего сказал: “Нет коллеги, так мы ничего не решим. Давайте сравним ваши скрипты между собой.” Попрошу вас обоих составить список метрик, по которым вы будете их сравнивать и провести сравнение.

    Вернувшись с митинга, Леша вызвал к себе Ивана: “Вань, может, ну их? Скрипты же делают одно и то же. Пусть будет их версия?” Ваня, конечно, обиделся: “Леш, а чего ты меня тогда просил их посмотреть? Я что, получается, зря их писал, что ли?”

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

    От такого компаранса Дима пришел в неописуемую ярость: “Значит так! Я смотрю, и там, и там есть свои плюсы. Ок. Пусть ваши инженеры садятся на телефон и сращивают эти скрипты между собой.”

    Началась процедура сращивания…

    Вопрос: сколько ошибок сделал участники истории, какие именно и как надо было сделать по-нормальному?

     

    18 responses to “Кейс “Два в одном””

    1. 1. У каждого митинга должна быть цель, повестка и человек в роли секретаря, который бы всех участников держал в рамках и не давал затягивать время.
      2. Желание бравировать на следующем митинге и умолчать о своем желании поправить ситуацию и создать таки скрипты привело только к конфликту и трате времени.
      3. Ошибка также состояла в умалчивании наличия скриптов, сказав пораньше можно было сэкономить кучу времени и своего и другой команды.
      4. Сталкивать лбом команды тоже малоэффективно, нужно было выбрать чьи-то скрипты для быстрого решения проблемы, а другие пообещать использовать в другой раз или для другой похожей задачи, или там еще что придумать, чтоб работа не оказалась в корзине.

      В общем как-то так…

    2. ИМХО – неправ больше всех Дима)
      Дима неправ в том, что если есть задача подготовить тестовые скрипты, то нужно было назначить ответственного за нее, чтобы он, например, подготовил к следующему митингу какую-либо инфу по этому поводу.
      Кроме того, если уже решать, чьи скрипты лучше, то это должна решать третья сторона, а не сами исполнители, которые, естественно, подгонят все метрики под свои скрипты)
      А вообще лучше бы взять чьи-то скрипты сразу без разбирательств, и назавтра забыли бы все про эту историю. А так получается – столкнули две команды, посеяли долгосрочный конфликт.
      Неправота Леши состоит в том, что он не сообщил сразу Диме о том, что у него есть готовые скрипты (мог бы мэйл разослать об этом Диме и другим лидам) – нужно в таком случае быть готовым к тому, что добровольцы найдутся еще. А еще лучше было бы, если б Леша сразу на митинге забил бы за своей командой приготовление скриптов, тем более, что у него есть такой прекрасный Иван)

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

    4. Вторая ошибка – следствие первой. Стремление быть последовательным сыграло злую шутку. Сначала Леша взял на себя роль Заказчика, затем попытался ее же отстоять перед… истинным Заказчиком. Конфликт. И тут на сцене появляется Заказчик Дима, который делает первую ошибку – просит конфликт разрешить самим конфликтующим сторонам. Далее, Дима хочет быть последовательным, и усиливает свою ошибку, попросив сращивать скрипты.

    5. Ошибки были допущены практически на каждом шаге кейса и, фактически, всеми её участниками

      1. Неверно организованное совещание. Если закрыть глаза на отсутствие прочих формальных признаков типа предварительно-разосланной агенды и секретаря, у совещания отсутствовала критическая вещь – понимание у организатора совещания (Димы?) о том, какой выход от совещания он ожидает и зачем он его организовал. Соответственно, по причине своего отсутствия, это понимание не было донесено до других участников, вследствие чего у Димы сложилось одно понимание результатов встречи (“тестовые скрипты обсудим послезавтра”), а у Леши и московского тимлида – другое (“имеется нерешенная проблема с тестовыми скриптами”).

      Дальнейшая попытка решить проблему своими силами – вполне предсказуемый шаг.

      2. Неверная постановка задачи. Учитывая, что Леша хорошо знал особенности Ивана, задача была поставлена некорректно: в первую очередь, не было выяснено, как Иван задачу понял, во-вторую – не был поставлен приоритет задачи. В результате – решение задачи по своим соображениям.

      3. Неверно организованные коммуникации в команде – помимо того, что телефонный разговор “по существу” на пятерых – это утопия (что многократно подтверждалось в данной команде, см. “как обычно, на два часа…”), между разными командами явно поддерживается антагонизм.

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

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

      6. “Пусть срастят”. Очередной косяк Димы. Если уж он решил остаться в стороне от технических аспектов решения проблемы, то не надо бы лезть вообще. В данном случае, вместо двух решений со своими плюсами и минусами, мы получили одно, обладающее только минусами.
      Решение надо принимать на своем уровне. Не говоря уже о том, что при принятии решений надо все-таки иметь холодную голову.
      Ну и тот факт, что все молча подчинились указывает, опять же, на качество организации коммуникаций и, вообще, микроклимать в коллективе, а также на мягкотелось Лёши и московского товарисча.

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

      Как надо:
      Диме: результаты совещания и принятые решения доносить сразу после совещания до всех участников, занимать проактивную позицию по управлению командами и выстраиванию коммуникаций
      Леше: быть смелее в общении с руководством, занимать позицию “мы нацелены на результат” (соответственно, самостоятельно предложить москвичам составить общую схему метрик). Здоровая конкуренция приветствуется, но не в ущерб общему делу.

    6. Что делать? Леше изначально надо было “застолбить” зону ответственности за разработку скриптов. Да, потратить на это время, но не в пустую (как получилось по кейсу), а с реальным результатом. В кейсе ничего не сказано про московскую команду (как они договаривались насчет скриптов), но, можно предположить, что Заказчик Дима уже с ними договорился, что они будут делать эти скрипты. Может быть такое? Вполне. А может и нет. Но это вариант Леша полностью упустил из внимания.

    7. Что делать Диме? Разрулить конфликт в пользу одной из сторон. Четко обозначить конкретного исполнителя по данной задаче. Это, в данной ситуации, авторитарное и правильное решение.

    8. И только Ваня не ошибся. Он знал, что Леше понравится то, как быстро он сделает свои скрипты.

    9. Ошибка митинга была не в процедуре и не в агенде. А в том, что цели себе никто не поставил и никто не достиг. Леша должен был поставить себе цель “выбить работу для команды по тестовым скриптам”. Соответственно, обсуждать надо было именно это.

    10. Хе-хе :-)
      Цели, митинги, “застолбить зону” ответственности, отдать приоритет в пользу одной из команд, привлечь 3ю сторону – это не решит проблему. Ситуации будут повторяться.
      А ошибок в кейсе (в действиях участников) всего 1 (одна) штука. :-)

      Сделайте сначала анализ ситуации.
      Задайте себе следующие вопросы:
      1. ПОЧЕМУ ОБА региональных менеджера ОДНОВРЕМЕННО “рвали попу на английский флаг” и делали скрипты НЕ ДОЖИДАЯСЬ обсуждения?
      2. ЧТО получил бы КАЖДЫЙ менеджер команды, ПОСЛЕ написания скриптов?

      P.S. Рекомендую посмотреть разбор предыдущих кейсов. Там можно найти подсказку для решения этого кейса.

    11. Я соглашусь с covrom: источник проблем в том, что есть две отдельных команды в разных регионах, которые, видимо, тестят один и тот же код.

      А отсюда уже и обсуждения, нужен ли статус в Багзилле, и разные тест-кейсы для одного и того же кода.

      Зачем???

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

    12. 1.
      Совещание длилось на два часа дольше запланированного (как обычно!). Похоже, повестка собрания туманная либо вообще отсутсвовала. Люди собрались с намерением спорить и обсуждать, а не принимать решения. Час потраченый на поле LATER это только иллюстрирует :) . Нет регламента либо человека следящего за его исполнением. В итоге обсуждение любого вопроса может занять любое время с неопределенным результатом. Не отслеживается даже время всего собрания, что выливается в 2*5=10 потерянных часов.

      стоило бы:
      - иметь ясный список вопросов, которые планируется обсудить
      - если возможно, по каждому вопросу иметь список основных потенциальных решений (с преимуществами и недостатками). Иначе все как раз и выльется в многочасовые обсуждения.
      - назначить на сложные вопросы ответственного человека, который проработал бы его глубже и представил бы результаты исследований
      - следить за временем. Хорошо бы запланировать N минут на каждый вопрос в зависимости от сложности и стараться не превышать лимит больше чем на пять минут. Если решения еще нет – смотреть, в чем конфликт, назначить соответствующие задачи соответствующим людям.
      - следить за временем. Если время собрания истекло, то собрание заканчивается. Можно договориться о возможном люфте в 10-15 минут, но его использование должно быть исключением, а не правилом.
      - после завершения собрания послать участникам его результаты – принятые решения, назначенные задачи, ответственные лица, сроки, etc.

      2. Вопрос про поле LATER, сливший час обсуждения. Имхо, это вообще ошибка выносить такой вопрос на широкое обсуждение. Аргументов за или против этого поля может быть 3-5, вряд ли больше. Вопрос можно было решить, обнародовав список аргументов и устроив голосование – в интернете или даже на том же собрании. Только в случае собрания голосование должно быть кратким – каждый говорит свое мнение в формате “оставить”/”убрать” и все. Решение будет принято за минуту. Если аргументы за и против неизвестны – можно их собрать на собрании, думаю 10ти минут должно хватить (я надеюсь, менеджеры умеют готовиться к собранию и сжато/внятно излагать свои мысли :) ).
      Понятно, решение с голосованием имеет смысл если голоса всех участников равноправны. Если одни равнее других, то можно и три часа спорить.
      Да, если бы участников было четное количество, то пришлось бы голосу главного тестового менеджера Димы дать больший вес.

      3. Леша жалуется на коллег подчиненному. Понятно, что С Ваней у него хорошие отношения; вероятно, Ване даже приходилось работать с другими офисами и он разделяет мнение Леши. Но узнав о том, что начальство час обсуждает какое-то поле, он вправе предполжить, что начальству делать просто нечего больше. Ну или что начальство не шибко компетентное. Пока Ване все нравится это не проблема, если вдруг возникнут накладки в работе, Ваня может подумать об уходе в другое место.

      стоило: подумать, почему потратили час и как в будущем управляться быстрее.

      4. Ребята начали решать задачу, по которой еще не было принято решение, причем в тайне от остальных команд и начальства, причем так поступают сразу в двух офисах.

      стоило: когда стало ясно, что Ваня решает проблему тестовых скриптов, Леше стоило ответить на письмо с итогами последнего собрания и сообщить остальным, что решение проблемы близко и новгородский офис берет ответственность за эту задачу на себя. А лучше – когда возникла мысль решить проблему скриптов своими силами – получить аппрув у Димы.

      5.
      Ваня выполняет какую-то левую таску, поставленную ему по пути на обед, буквально на следующий день, причем, судя по всему, в свое свободное неоплачиваемое время. Любить свою работу это здорово, но переработки как норма – сомнительное благо. Начальство может привыкнуть к этому и воспринимать как должное. Уже воспринимает, судя по всему: “Леша даже не удивился”. Даже спасибо не сказал?

      стоило:
      Ване: уточнить, что значит “посмотришь, как бы нам обустроить тестовые скрипты” – что требуется, видение, готовое решение, набор требований? Уточнить сроки и приоритеты.
      Леше: как минимум поблагодарить Ваню на месте, а не “не удивляться”
      (возможно, они оба все это и сделали, из текста неясно :) )

      6.
      Дима слушал спор, чьи скрипты лучше, полчаса, прежде чем велел сравнить их между собой. Можно было и побыстрее среагировать

      7. Дима велел сравнить скрипты между собой. Вообще, их стоило “сравнивать” с набором требований, которым скрипты должны были удовлетворять. Судя по тому, что Дима велел для сравнения составить метрики, требований не было. То есть обе команды сделали неизвестно что на основе своих каких-то представлений. Надо было начать с требований, да.

      8. Дима поручил сравнение заинтересованным сторонам, которые и так уже спорили полчаса до хрипоты. Какого результата он ждал?

      9. Леша спорил до хрипоты при том, что сам согласен, что скрипты делают одно и то же. Одновременно он готов отступить – предлагает Ване, “может ну их?”. Похоже, он сам не знает, чего хочет – то ли он и вправду верит, что скипты Вани лучше, то ли хочет признания заслуг своей команды, то ли просто поорать захотелось.

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

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

      11. Дима пришел в ярость от компаранса. Зачем он туда пришел? Возможно, и стоит порой демонстрировать подчиненным свой гнев, но это явно не та ситуация. В данном случае гнев Димы помешал другим участникам собрания оспорить его сомнительное решение насчет слияния скиптов.

      12. Дима велел срастить скрипты. Вообще непонятное решение. Есть два решения, оба работают, результаты сравнения неясны. Можно сравнить заново, поручив это третьему лицу. Можно выбрать любое решение, просто ткнув пальцем наугад (плохой способ, конечно). Можно предложить всем использовать любое из решений в течение двух недель, потом собрать мнения. На деле предлагается сделать из двух работающих решений какого-то монстра, причем делать это будут авторы исходных скриптов. Атмосфера, мягко говоря, недружелюбности обеспечена (+ люди будут тратить время на какую-то странную, ненужную задачу)

      13. Вообще, не факт, что кто-то из участников истории сделал хоть одну ошибку – все зависит от их целей.

    13. 1. Самое первое, что бросается в глаза, это окончание совещания на 2 часа позже и один так и не решенный вопрос, т.е. первая ошибка это организация совещания.
      Было бы более продуктивно, заранее ознакомить всех порядком вопросов на совещании – иначе говоря повестка дня. Если вопрос скриптов более важен чем статус в багзиле, то наверняка с него и следовало бы начать. т.е. расставить вопросы в порядке их приоритетов.
      Далее в процессе проведение, похоже было очень много споров и дебатов, и не хватало конструктивности в обсуждении. Так как самый большой начальник Дима, то это ему и минус.

      2. Ошибка не ошибка, но жаловаться на других менеджеров подчиненному, это признание некомпетентности управленческого состава. Возможно потом и появится вопрос, а почему это подчиненные не считаются с менеджерами и возможно довольно таки часто приходится повторять задачи\распоряжения.
      Лешу можно понять, такие непродуктивные совещания бесят, однако продуктивность совещания зависит от всех участников.

      3. Что именно Леша хотел, что бы Ваня посмотрел по скриптам? Но получилось так, что Ваня написал скрипты. Если надо было посмотреть и придумать стратегию, в плане подготовки к совещанию, то так и надо выдавать задание.

      4. Если уже так вышло, что Ваня написал скрипты, это требует незамедлительного действия и в первую очередь на коммуникационном уровне. Даже если скрипты будут потом, не пригодные.
      А Леша сделал, ошибку многих, вначале сам проверит потом только скажет всем. Многих пугают такие фразы типа: Ваня написал скрипты на bash-е, сейчас Леша их тестирует. А еще они находятся тут.
      Однако, уже с этого момента, идет исправление менеджерских промахов.

      5. Дебаты по поводу чьи скрипты лучше и прочее, но тут уж однозначно ошибка. Это уже попытка скрыть свои менеджерские промахи, за счет бурной деятельности. Как в этом случае поступить сложно сказать. Многое зависит от людей и обстоятельств. Однако, Диме не помешало бы в первую очередь надо признать свой промах, и вместе с менеджерами решить этот вопрос не привлекая эмоции. Думаю, Ваня понял и простил :) .

    14. Впроса “что делать в уже сложившейся ситуации” не прозвучало, но я отвечу)

      Как вариант: поскольку мы не знаем количества разработчиков и их уровень в московской команде, предположим, что ВОЗМОЖНО их скрипты НЕ ХУЖЕ ваниных. Отсюда, Диме говорим, что все срастили, используем только московские скрипты, а Ване большую конфету.

    15. Хотел немного пояснить. Для проекта губительным окажется сращивание скриптов. Следовательно, использовать можно только один набор.

      А что же делать с демотивацией разработчиков отвергнутого набора скриптов? Выдать всем конфету. Вот почему имеет значение количество разработчиков в команде.

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

    16. Дима ошибся вообще, по всем пунктам. А Леша ошибся в том, что до сих пор не сместил Лешу со своего поста, ведь это так просто:)

    17. 1.
      Cудя по первым 3-м абзацам кейса была и повестка совещания, и понимание проблемы у Ивана.
      Об этом говорят слишком короткие фразы между участниками (Димой, Алексеем, Иваном).
      Вот если бы Дима сказал что-то вроде: “На этом совещании я предполагал обсудить вопрос
      текстовых скриптов, которые …. Но сейчас не успеваем, поэтому перенесем этот вопрос.”
      Тогда можно было бы предположить, что повестки совещания не было. К тому же Иван понял
      Алексеея с полуслова. А это значит, что вопрос ранее поднимался и обсуждался.
      Предполагаю, что на совещании Дима планировал принять решение кто конкретно будет заниматься скриптами,
      но не успел.

      2.
      Лично я не считаю затягивание совещания ошибкой. Все эти регламенты, слежение за временем
      хороши в теории, но на практике не всегда работают. Что хорошо работает на практике – так это
      предварительная повестка совещания. Не забывайте, что люди общаются по телефону. И скажем,
      задача нарисовать элементарную схему, показать что-то на бумажке превращается в большую проблему.
      А это один из факторов затягивания времени.

      3.
      Дальше с Ваней в кейсе есть “скользкий” момент. С Ваней может быть 2 варианта: либо сотруднику
      действительно нравится его работа и он готов решать любые поставленные задачи, либо сотрудник
      специально сделал больше, чем ему поручено
      (аттестации из прошлого кейса никто не отменял). Я предполагаю, что имеет место нечто среднее между
      2-мя озвученными вариантами.

      4.
      А дальше Алексей делает всё ПРАВИЛЬНО :-) Только надо понимать, что цели у Алексея – закрепить
      за своей командой эту задачу и выполненный объем работ.
      Тот факт, что московская команда делала тоже самое говорит о том, что есть СКРЫТАЯ КОНКУРЕНЦИЯ
      между командами!
      bpgz совершенно прав. Всё зависит от целей (см. у bpgz п. 13). А цели у Алексея совершенно не соответствуют
      общим целям и целям Димы.
      В таких случаях (управленческой борьбы) важно предоставить ГОТОВЫЙ и ПРОВЕРЕННЫЙ продукт, поэтому он всё досконально
      проверяет. Если Алексей на совещании скажет: “А вот мы написали скрипты, сейчас тестируем.”
      Я почти уверен, что в ответ прозвучит от московской команды: “А у нас скрипты написаны и проверены”.
      ДАЖЕ если это неправда. (ложь должна быть правдоподобной и труднопроверяемой). И тогда будет ожидаемое
      решение Димы: “Так, у москвы всё уже сделано, поэтому
      не тратьте время на тестирование, берем московский вариант”.

      5.
      Я думаю, что скрытая конкуренция обусловлена системой оценки работы команд/сотрудников с помощью KPI.
      Здесь нужно сделать небольшое отступление и рассказать об одном большом недостатке системы BSC (ССП) и KPI (КПЭ).
      Заключается он вот в чём. Как только вводится оценка работы сотрудника по KPI, сотрудник перестает
      работать на цели компании, непосредственного начальника и т.д. Он начинает работать только на свои
      показатели и каждое задание будет оценивать только с точки зрения улучшения СВОИХ показателей.
      В клинических случаях народ начинает работать так, что KPI остаются в норме, но реальных результатов нет.
      Именно поэтому инженерам не говорится методика оценки их работы (см. ответы Александра Орлова на предыдущий кейс).
      НО! менеджер команды знает об методике оценки!

      Алексей, зная о методике оценки, и, имея готовые скрипты, готовится их продемонстрировать их на
      совещании. Не забудьте, что если москвичи найдут ошибки в скриптах, то это будет поводом
      сказать: “А вот он предоставил непроверенное решение, у нас возникли проблемы и т.д. и т.п.”
      Таким образом при наличии ошибок работа команды Алексея будет дискредитирована в глазах главного менеджера Димы.
      В случае успеха команда Алексея и сам Алексей получили бы “плюсик” в репутацию. И возможность
      предоставить на следующей аттестации “железный” аргумент подтверждающий, что его команда работала больше
      московской. Успешная аттестация -> повышение зарплаты.

      Подчеркиваю, именно из-за совершенно других целей и условий, действия Алексея ПРАВИЛЬНЫЕ.
      Да, был риск, что его опередят. Но это другой этап борьбы :-)

      6.
      А вот Диме пришлось столкнуться с описанным выше недостатком системы BSC, точнее с её следствием.
      Его поставили перед фактом, что 2 команды сделали одно и тоже.
      Дальше, нужно разруливать ситуацию. Конфликта ещё нет. Есть противоречия (это скажем более мягкая форма
      конфликта. Некоторые источники выделяют до 5 уровней противоречий, разделяя их по напряженности).

      В ситуацих с противоречиям, конфликтами между Вашими подчиненными нужно помнить одно правило:
      “НИКОГДА, никогда не выступать третейским судьей для Ваших подчиненных. Либо они договорятся
      САМИ между собой, либо обоим будет плохо.”

      Зная это правило, становится понятным, что Дима в целом выбрал правильное направление своих действий.
      Он стал ЗАСТАВЛЯТЬ команды ДОГОВАРИВАТЬСЯ между собой. Мало того, ему необходимо принять ОБОСНОВАННОЕ решение.
      Поэтому он и слушает спор в течение получаса, и заставляет их провести сравнения.
      И вот здесь он сделал ОДНУ небольшую ОШИБКУ (я считаю это единственной ошибкой за весь кейс).
      Вместо: “Попрошу вас обоих составить список метрик, по которым вы будете их сравнивать и провести сравнение”.
      Ему надо было сказать: “Попрошу обоих составить список метрик, провести сравнение и предоставить ОДИН, СОГЛАСОВАННЫЙ
      вариант сравнения”.
      Из мирового опыта известно, что результат исследования всегда тянется к заказчику :-)
      Поэтому команды воспользовались возможностью провести отдельное свое исследование и сделать выводы
      в свою пользу.

      Следует отметить, что несмотря на сделанную ошибку в дальнейшем он всё равно придерживался правильной линии поведения.
      Фразу “сращивайте скрипты между собой” нужно понимать как: “Я не собираюсь погружаться в технические детали
      и решать чьи скрипты лучше. Не можете договориться сразу, значит трахайтесь как хотите, но в результате
      должно быть ОДНО решение”. Т.е. командам в любом случае придется договориться.

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

      Подводя итог: ошибка и решение указаны в п. 6 , профилактические действия указаны в п. 7

    18. [...] Чужие ошибки искать всегда интересно. Я так понимаю, именно поэтому получилось столько ответов на кейс  ”Два в одном”. [...]

    Leave a reply

    You must be logged in to post a comment.