[кейс] Итерация вовремя или пол-команды?

    Друзья, ну что ж, раз первый кейс получил свои 15 минут внимания плюсов, то продолжим.

    Года четыре назад проводили мы в Москве третий семинар из нашей серии тогдашних семинаров. Чтобы разнообразить программу, мы решили выделить пару часов на разбор кейсов участников. Поскольку участников собралось человек 40, то понятно, что все кейсы тут не разберешь. Поэтому была наведена специальная демократия: сбор кейсов, голосование, подсчет результатов авторитетной комиссией в лице нас со slavapankratov.

    В итоге, в топ самых интересных кейсов попала следующая ситуация. Кейс реальный, взят из реального опыта наших студентов:

    Кейс «Уволим пол-команды»



    Disclaimer от коллеги slavapankratov. Обращаем ваше внимание, что после того реальная ситуация, которая используется для проектирования кейса, обрабатывается тренером (обезличивается, обрастает формальными вводными, усиливается фактами, без которых ее решение было бы невозможно), она может приобретать «пластиковый вкус»: то есть может казаться несколько искусственной и придуманной. Разбор проблемной ситуации сам по себе всегда несет определенный процент искажений реальности, а кейс, как модель временного отрезка реального мира, может казаться искусственной и притянутой за уши. Предлагаем вам рассматривать эту ситуацию как учебный тренажер, а саму ситуацию как спарринг-партнера, который в отличии от боксерской груши может дать сдачи но при это в его задачи не входит нокаутировать тренирующегося.

    Зачем мы сделали это вступление.

    Любой тренер, если он ведет именно тренинги, а не просто читает кусок лекции или пересказывает заученный семинар, сталкивается с сопротивлением обучающегося. Как только реальный опыт студента попадает в ситуацию критической оценки тренером или группой, человек склонен его защищать. В прошлом исправить ничего нельзя, а признавать, что когда-то ранее ты был не прав, даже если это было давно и, казалось бы, уже не важно, мы не любим. Другими словами, если в учебной ситуации студент узнает себя и видит, что ранее он мог в подобной ситуации вести себя не самым логичным или эффективным способом, возникает защита: «Кейс какой-то, явно, неправильный» или «Да что могут они знать со своим кейсом о реальной жизни?!!» или (самое любимое для тренеров) «Это вы мне специально кривой кейс подсунули, чтобы поглумиться». Почему любимое? Это хороший маркер запустившейся рефлексии, внутреннего обсуждения в голове у студента. А рефлексия это первый шаг в обучении.

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

    Поехали!

    Ситуация


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

    Команда проекта ведет разработку большой ИТ-системы, которая поставляется заказчику месячными итерациями. То есть, перед началом каждого месяца, команда выбирает и оценивает тот объем работы, который она сможет поставить заказчику. В работы входит анализ требований на итерацию, разработка или доработка кода системы, тестирование новой версии системы, ее развертывание и конфигурирование на стенде заказчика. Первый день-два каждого месяца команда проводит за анализом и оценкой требований, которые могут быть разработаны и протестированы в срок 1 календарного месяца. Работа с заказчиком ведется около года, на текущий момент, с учетом государственных праздников и сезонов отпусков, заказчику было поставлено 10 версий продукта.

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

    Несмотря на отлаженную процедуру оценки объема итерации, команда проекта в 4 итерациях из 10 срывала сроки поставки новой версии продукта (от 1 до 4-5 рабочих дней). Причины срыва каждый раз разные: проблема с развертыванием и обновлением ПО на инфраструктуре заказчика; возникшие критические ошибки, которые повлекли исправления и повторную поставку; изменения в составе реализуемых требований и недооценка сроков на реализацию изменений. Какой-то одной системной проблемы на ретроспективе после «проблемных» поставок выявить не удалось. Последствия от срыва сроков для бизнеса заказчика также каждый раз разные: проблемой является простой подразделения заказчика, а не просто сам факт задержки даты поставки.

    Последние 2 срыва сроков поставки случились подряд в двух месяцах один за одним. Срыв запуска новой версии на 3 дня привел к простою всех 400 сотрудников подразделения заказчика сроком на 3 дня. Разгневанный заказчик в ультимативной форме потребовал у руководства вашей компании принять меры по наведению порядка в проекте.

    Технический директор компании, в которой работает проектная команда, вызвал главного героя кейса и донес до него следующее управленческое решение:

    Если следующая итерация, в начале которой сейчас находится проект, будет сорвана по срокам, то с целью наведения дисциплины и создания показательного прецедента для других 15 проектных команд компании (всего в вашей компании работает более 1.000 сотрудников) из вашей команды будет уволена половина сотрудников, а проект будет переформатирован по составу людей и срокам будущих поставок.

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

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

    Вопросы:


    1. Говорить или не говорить команде о решение руководства?

    2.1 Если говорить, то что именно и какими словами говорить команде или отдельным ее членам?

    2.2 Если не говорить команде, то каким будут ваши дальнейшие действия? Будете работать? Не будете? Как будете вести проект дальше? К каким последствиям может привести выбранная вами модель поведения?

    Дополнительные данные


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

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

    [ПАУЗА ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ НАД КЕЙСОМ — ПУБЛИКОВАТЬ СВОЕ РЕШЕНИЕ В КОММЕНТАРИЯХ НЕ ОБЯЗАТЕЛЬНО, НО ВЫ, КОНЕЧНО, МОЖЕТЕ ЭТО СДЕЛАТЬ, ЕСЛИ ГОТОВЫ ПОКАЗАТЬ, КАК БЫ ВЫ РЕШИЛИ КЕЙС СЕЙЧАС И К КАКОМУ РЕШЕНИЮ ПРИШЛИ ПОСЛЕ РАЗБОРА КЕЙСА В ЭТОЙ СТАТЬЕ.]

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

    Обычно «сферический менеджер в вакууме» является слугой трех господ:

    image
    1. Бизнес — интересы заказчика, компании, руководства
    2. Интересы команды
    3. Собственные авторитет (неформальный и формальный) и репутация

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

    Если решение сделает хорошо команде, но при этом не будут учтены интересы бизнеса, то что случится с репутацией менеджера?

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


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

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

    Говоря условиями кейса — решение полететь к заказчику и путем шантажа или угроз убедить его отменить решение и повлиять на технического директора принимается как рискованное. «А у нас с ним замечательные отношения и бухаем вместе» — поправка, которой вы изменяете условия кейса и решаете его в своей реальности, а не в условиях нашего учебного тренажера.

    При этом и мы со своей стороны можем случайно изменить реальность кейса своим вариантом решения или сделанными допущениями. Правила и для вас, и для нас. И мы, и вы вправе сказать, что решение вносит изменение в первоначальные условия кейса.

    Готовы?

    Мы приведем несколько совсем неустойчивых, на наш взгляд, решений, которые чаще всего звучат от студентов в тренингах и наших онлайн-программах. Разбирая эти ответы, мы, заодно, приведем примеры того, что называем «не устойчивое решение».

    Пройдем по первой развилке дерева решений.

    Вариант №1. Команде не говорится про последствия.

    Аргументация разная: чтобы не сеять панику, чтобы никто не отвалился сам (как только узнает о нависшей угрозе), чтобы не возник раскол в команде (кого уволят?), чтобы никто не пошел вместо работы над своими задачами искать другую работу и так далее.

    С точки зрения теории систем, менеджер принимает на себя риск решения «Не говорим», оставляет команду без информации и надеется (другого слова тут не подберешь) что «Все как-то рассосется.» А надежда — не самый устойчивый управленческий план…

    Что чаще всего не учитывается при проектировании решения этого кейса?

    Достаточно часто не рассматривается, что информации об угрозе увольнения станет известна команде в середине итерации. При этом, на самом деле, в реальном мире, модель которого мы все-таки рассматриваем, информация ходит по компании самыми неожиданными путями в дополнение к официальным: «Ты только никому… но вас скоро порежут, ты присмотри себе работу» (как вариант, люди работали или учились ранее вместе), «Слышал у вас скоро сокращения будут, может давай к нам в проект? Как раз вакансия открылась» (случай внутренней конкуренции за ресурсы между менеджерами одной компании), «Эти из проекта А совсем офигели с такими задержками! Уволю половину, если попробуют еще раз такое вымочить!» (рассерженный тех.дир по секрету кому-то из доверенных менеджеров или просто вблизи ушей посторонних: секретари, HR, просто проходящие по коридору люди из числа сотрудников).

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

    Что будет делать менеджер в ситуации, когда он не сказал команде о возможном увольнении, а информация просачивается в команду? Говорить, что не знал? Говорить, что скрыл, чтобы не сеять панику? Люди не могут жить в условиях неопределенности. И осознание того, что менеджер по причине не информированности или (что еще хуже!) осознанно скрыл от команды информацию об общей участи с большой долей вероятности рвет доверие команда-менеджер. Заканчивать проект и работать дальше в такой ситуации менеджеру будет очень и очень сложно.

    Это не изменение условий кейса: мы не говорим, что обязательно узнают. Мы проверяем решение «Не говорить команде» на устойчивость. Устойчивость определяется возможностью ответить на вопрос «А что делать, если?» и иметь возможность продолжить реализацию решения в случае срабатывания подобного риска.

    Вариант №2. Сказать команде: «Если не справимся, половину разгонят».


    В чем могут быть риски этого варианта? В сериале «Интерны» была прекрасная серия, когда доктор Быков говорит 4 интернам: «В конце дня я уволю одного из вас. Я еще не решил кого. Ага, вот! Уволю того, то больше всех накосячит!»

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

    Будет ли в таких условиях итерация закончена в срок? Вряд ли. Люди думают не о том. как что-то сдать в срок. а о том, чтобы не оказаться в половине неудачников. Энергия направлена не туда.

    Вариант №3. Есть ли он?


    Постойте, скажете вы. Не говорить нельзя. Говорить тоже нельзя. Как так-то? Где решение?..

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

    Шаг №1. На общем собрании с командой описать ситуацию. И сообщить, что если итерацию не сдадим. то уволят всех. И меня. как менеджера, в первую очередь.

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

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

    Шаг №2. Тут же на общем собрании сказать буквально следующее: «Я понимаю, что эта информация может быть воспринята по-разному. Если вы для себя решите уйти до конца итерации — большая просьба в течение ближайших 2-3 дней сообщите мне об этом. После нашей встречи я хотел бы с каждым из вас встретиться один на один, чтобы понять, что вы по этому поводу думаете».

    Шаг №3, необходимый, чтобы вселить уверенность в сомневающихся. В конце общего собрания сказать: «Друзья, чтобы минимизировать риск нашего непопадания в сроки, я предлагаю целиться на 5 дней раньше. Просто чтобы подстраховаться. Более того, каждый день мы будем все вместе собираться и видеть общую картину как идем — успеваем или не успеваем».

    Шаг №4. Провести встречи 1:1 с каждым членом команды. И если кто-то таки собрался уходить, то сообщить об этом через пару дней на всех, и еще раз собраться вместе и решить, как будем справляться без уходящих.

    Успеет команда сдать релиз, не успеет — жизнь покажет. Но с точки зрения трех составляющих:
    • Бизнес
    • Команда
    • Авторитет и доверие


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

    Ну что же, за нашими с вами плечами остался второй кейс. Будем рады услышать ваше мнение — как позитивное, так и конструктивное.

    А мы параллельно с запуском закрытого кейс клуба «Системные люди» продолжим публикацию непростых ситуаций на Хабре.

    Стратоплан

    47,00

    Компания

    Поделиться публикацией
    Комментарии 47
      +3
      1. Сообщить, что мы провалили сроки два раза подряд и это очень плохо — пообещали расформировать отдел, неизвестно все ли при этом останутся в компании. Донести это ясно, но долго не останавливаться, чтобы руки не начали опускаться.

      2. Послушать предложения команды как исправить ситуацию с провалами.

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

      4. Несмотря на то, что вы говорите, что какой-то одной проблемы выявить не удалось, все указанные проблемы кроме срыва сроков (которые мы должны были учесть в п.3) так или иначе связаны с собственно деплоем — изменением работающей у заказчика версии (а также с воспроизводимостью продакшна локально у программистов и тестеров, но это более глобальная задача и часто требует отдельной большой работы и отдельного человека на нее)

      Здесь можно провести такие изменения:
      * отвести на деплой время в планировании как на отдельную задачу (если он долгий) — чтобы все фичи и их тестирование закончить к этому моменту, а не к формальному концу итерации
      * перенести время деплоя на время, которое создаст наименьшее количество проблем заказчику (например, ночью/в выходные — отдельно придется утрясти взаимозачет по этому времени с командой)
      * договориться, что во время деплое вся команда сидит и ждет багов, чтобы их экстренно фиксить (или дежурные люди, если у всех есть квалификация фиксить все)
      * В более дальней перспективе (если до этого доживем) исправить процесс стандартизирования конфигураций, тестирования, снятия метрик и мониторинга и собственно самого деплоя
        0
        Спасибо, хорошее решение. Формулировка «пообещали расформировать отдел, неизвестно все ли при этом останутся в компании» — очень удачная, имхо. Записал себе в блокнотик. )
          +1
          Заметил момент небольшой в вашем решении — если говорить «уволят меня в первую очередь», надо это еще донести и начальству. Иначе может выйти, что все провалили, а меня просто перевели на другой проект.
          Да и то, что часть людей может сразу из проекта начать выходить, тоже сразу нужно с начальством и, вероятно, с заказчиком обговорить, т.к. у нас по этой причине может возникнуть провал по производительности.
        +5
        Мой вариант ответа — уволится самому / передать дела более компетентному менеджеру. Регулярно ломать заказчику продакшен — верх некомпетентности. Тем более с позицией «Успеет команда сдать релиз, не успеет — жизнь покажет».
        После первого-же срыва надо брать и разбираться почему так произошло и как сделать чтобы не повторилось. Увеличить сроки на тестирование, организовать тестовое окружение, максимально приближенное к продакшену. Предусмотреть быстрый откат до предыдущей версии, если что-то пошло не так. Способов масса — было бы желание и бюджет.
          +3
          Да, да — и бюджет…
            0
            Я бы к этому добавил, что обязательно по результатам каждого серъезного прокола надо не только проводить работу над ошибками внутри команды, но еще и в деталях обсуждать случившееся с вышестоящим начальством, чтобы начальство видело, что дело не пущено на самотек, с проблемами борются. А если руководитель команды из раза в раз заметает мусор под ковер, то это действительно верх некомпетентности и наплевательского отношения и к заказчику, и к команде, и к своей компании. Опытный человек от подобного начальника сам уйдет не дожидаясь бесславного конца всей команды.
              0
              Вариант понятный. Но все-таки представим себе, что этот не вполне опытный менеджер таки должил до этой решающей итерации, и теперь у него есть шанс исправиться и начать делать как надо. Что ему делать в этой ситуации? Увольняться — вариант, но что тогда будет с выпуском итерации и командой?
                +1
                Первым шагом — посовещаться с деплоями и придумать способ не ломать заказчику продакшен. На мой взгляд — говорить разработчикам что их могут уволить нужно только если ничего вменяемого так и не придумали и никакого плана по решению проблемы нет. Чтобы люди могли начать искать себе другое место.
                Если какое-то решение всё же нашли — говорить об увольнении никому не нужно. Аргументы:
                1) Люди могут уйти. Особенно те, кто не имеет отношения к этой проблеме. Если бы мне сказали что могут уволить за то что накосячил другой — я бы подумал, стоит ли мне работать в такой компании. Даже если всё решится успешно — кто-то может всё равно уйти после этого.
                2) Под воздействием стресса кто-то будет работать эффективней, а кто-то наоборот начнёт косячить там где раньше всё было хорошо. Вероятность фейла увеличивается.
                3) Собственная репутация страдает. Фактически — признание своей ошибки и перекладывание ответственности на команду (даже если сказать что уволят в том числе и самого менеджера).
                По поводу слухов — всегда можно сказать «ничего не знаю, первый раз слышу, в любом случае — в этот раз мы приняли меры и релиз пройдет гладко».
              +1
              Друзья, чтобы минимизировать риск нашего непопадания в сроки, я предлагаю целиться на 5 дней раньше.

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

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

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

              И вы не разобрали риск сплетни о половине команды.
                0
                На каком-то семинаре слышал интересную мысль про оценку сроков — всегда стараться оценивать точно, а то, что нам часто требуется дополнительное время на багфиксы и доработки закладывать отдельной задачей с отдельными оценками сроков. Тогда эффекта переведенных часов не будет.
                +1
                В зависимости от степени человеческого фактора в данной ситуации (scope распухал, потому что заказчик через своё аффилированное в компании лицо проталкивал больше функционала в итерацию? заказчик не способен адекватно оценить сложность реализации и ссылается на Васю, который за полцены сделает в два раза больше? можно придумать мноого разных вариантов...), может иметь смысл пойти к человеку выше CTO (CEO, собственники, board members) и проговорить ситуацию. Прорываться в самые вершины. Кроме того, делать это надо, только сперва обговорив этот шаг с CTO. Возможно, что CTO согласится пойти говорить туда об этом вместе с вами, возможно что и от собственного лица. Всё это, в основном, человеческий фактор. В этом решении:
                1) вы действуете в интересах бизнеса,
                2) вы сохраняете авторитет,
                3) вы работаете на команду.
                Вариант, когда команда – отстой – не рассматриваю, потому что ну не бывает так, особенно в данной ситуации.
                  +6
                  Очевидно не говорить нельзя, потому что сильно подорвет доверие к менеджеру. Кстати в статье почему-то доверие обозвали авторитетом. Скажу по секрету, у линейного менеджера практически никогда нет авторитета перед инженерами, кроме случаев когда менеджер — очень крутой технарь в прошлом.

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

                  Поэтому если сказать что уволят всех — все побегут искать новую работу. Если сказать что уволят половину, побегут искать новую работу (сразу или через пару дней) подавляющее большинство, останутся только те, кто умеет хорошо лизать.

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

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

                  Но ситуация сама по себе странная, менеджеру было заранее известно о таком business impact деплоя. Почему нельзя было после первого фейла деплой починить?
                  Как минимум сделать его более гранулярным, чтобы можно было быстрее накатить.
                  Во-вторых сделать компоненты менее связными, чтобы проблема в одном не останавливала работу кучи народу.
                  В-третьих наладить тестирование деплоя на staging, возможно прямо у заказчика. Все это можно было бы сделать за одну-две итерации и проблема вовсе бы ушла.

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

                  Короче неадекватно как поведение участников, так и сам вопрос.
                    +3
                    Во-вторых сделать компоненты менее связными, чтобы проблема в одном не останавливала работу кучи народу.

                    А теперь как бывает в реальности — в наследство команде достались три тонны гавнокода где всё связанно со всем, при том через пятнадцать слоев абстракции (а как же, мы умеем проектировать, да), предыдущие три поколения тех кто в поте лица всё это высе создавал давно уволились. Так что сделать компоненты менее связными за месяц, да ещё и с новыми фичами — мягко говоря, не реально.

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

                    Суровая реальность — продакшн всегда отличается от стейджинга. Или потому что продакшеном занимается клиент, или свой отдел инфраструктуры, которым проблемы разработчиков не совсем близки. А ещё продакшн может сам по себе быть нестабильным, а клиент этого не понимает.
                      –2
                      А зачем трогать старое? Достаточно писать новое так, чтобы оно старое не трогало. это почти всегда можно сделать.

                      Сделать стейджинг похожим на продакшн легко. Бекап-ректор баз данных и накатывание кода. Даже в случае очень сложных платформ это решаемая задача.
                        0
                        Самый простой пример: данные клиента секретные, а на других данных некоторые баги не наблюдаются.
                          0
                          Можно договориться чтобы стейджинг был у клиента.
                    0
                    На кого ориентируетесь в продажах вашего кейс-клуба если не секрет? Например для жителя Москвы 11$ ерунда, а вот в моем регионе тратить эти деньги на что-то не совсем ясное — не хочется.
                      +1
                      Мы никогда не делали ценовой дифференциации по регионам. Во-первых, непонятно, как это отследить, во вторых как-то это и несправедливо, имхо. Москвичам — одну цену, сибирякам — другую, беларусам — третью и т.д. Тем более, что везде люди работают с разными зарплатами и возможностями.

                      При этом у нас даже на годовую программу стоимостью 24,000 руб. есть участники со всего СНГ — от Беларуси и Калинграда до Петропавловска Камчатского, от Мурманска до Одессы.

                      Мы как-то пришли к пониманию того, что если человек к нам не приходит, значит, сейчас для себя он не видит ценности в этом за эти деньги. Значит, либо мы эту ценность лучше покажем (клуб, правда, толковая идея, я в нее очень верю), либо человек для себя поймет, зачем ему это нужно.
                      +4
                      Нужно сказать команде правду, но вместе с тем предложить конкретный план, который не позволит допустить срыв сроков. Тогда команда будет знать, что их увольнение зависит не от нелепой случайности (развернется обновление ПО или заглючит), а от четкого следования плану каждым членом команды, если план представляется разумным, разработчики сделают все для его выполнения. Разумеется если на этот момент в команде уже царит атмосфера подозрительности и недоверия, то это не сработает и команду надо переформировывать.
                        0
                        Если в команде есть человек, способный сформировать план, то где он был во время предыдущих фэйлов? Если никто не видит закономерности в фэйлах, то никто не понимает их причину (например, 1)проблемы в коде или 2)отсутствие единого видения бизнесс-процессов заказчика и целей программы среди команды, из-за чего код вроде бы корректен, но противоречив или 3)жадность заказчика который хочет за итерацию больше фич чем может выкатить команда или ещё что угодно).
                        Ну ок, кто-то умный скажет, давайте писать n тестов, ревьюить код m раз и не уходить из офиса пока не выполним столько-то работ. А причина в жадности заказчика. Ну будете вы следовать плану, и как вам это поможет? Вспоминается поговорка — когда тысяча человек умирает по плану, то это нормально, когда внезапно умирает сто человек — то это трагедия. В данном случае план без понимания ситуации не гарантирует, что сроки будут выполнены.
                          0
                          Но отсутствие плана гарантирует, что все будет пущено на самотек, люди будут чувствовать что от них ничего не зависит, что резко уменьшит работоспособность. Во время предыдущих фейлов никто не задумывался над составлением плана, казалось что эти фейлы случайны и серьезных последствий для команды не влекут. В ситуации же когда представляется последний шанс необходимы особые меры по подготовке, в том числе конкретный план. Да он может не помочь, возможно причины проблем вне компетенции команды, но по крайней мере все будут знать, что сделали максимум возможного и ничего лучше придумать было нельзя.
                            0
                            Планировать необходимо, но также важна и импровизация. Автор книги «Программист-фанатик» утверждает, что в критических ситуациях наиболее важна именно импровизация (но она невозможна без хорошей квалификации). Какие в данной ситуации мне видятся проблемы — 1)заказчик теряет деньги, 2)если программисты лишатся работы то они возможно будут недовольны, 3)если манагер не разрулит ситуацию или не докажет что она неразруливаема при текущих ресурсах то понизится его авторитет. При этом непонятно, какую из этих проблем можно решить и как. Заранее неизвестно, можно ли как-то убрать зависимость между потерей заказчиком денег и сроком релиза, можно ли убедить программиста что увольнение это не плохо а хорошо и т.д. Не узнаешь, пока не попробуешь. Когда известен результат попыток, возможно придётся изменить план на 180 градусов. Может быть для решения проблемы и не нужно биться над тем, чтобы выкладывать релиз в срок. А может быть нужно биться как раз над этим. Как составить хороший план в условиях такой неопределенности? Да, нужно составить первоначальный план, но он может измениться после наступления первого же события. При этом если команде заранее сказать — мешайте чай по часовой стрелке, и будет вам счастье, то после этого сложно будет направить их в другую сторону. Как они отнесутся к тому, когда после ваших заверений что мешание чая по часовой стрелке гарантирует успех, на следующий день вы заявите: «я передумал, уволен ты, ты и ты!».
                            Вы рассуждаете с точки зрения работника, а не манагера и отвечаете на вопрос — какое развитие событий благоприятно для зоны комфорта работника, чтобы ему было на что валить вину когда сроки выкладки снова запаздают (а так скорее всего и будет). Давайте повнимательнее посмотрим на ваше предложение с точки зрения работника: зарплата та же, не уважают, а заставляют лезть из кожи вон ради плана, с которым работник может быть и не согласен (всем не угодишь). Работник то честно работает, а тут какие-то неприятности потому что его команда видите ли плохо работает (может дело и в нём, но он никогда себе не признается). Будет он эффективнее и более мотивирован из-за наличия плана? Вряд ли. Повышение мотивации работников как средство решения проблемы посредством плана скорее всего не сработает. А если плана нету, может хоть сами что дельное предложат. По крайней мере слова о том, что у вас есть план который поможет решить проблему, когда его у вас его нет — это такая же ложь, что и «никого не уволят». Ну, может быть, уличить вас будет чуть сложнее
                        0
                        Интересный кейс. Но по моему учтены не все составляющие.
                        Обычный сферический менеджер слуга 3-х господ (бизнес, команда, авторитет).
                        Но в данном кейсе два менеджера: PM и технический директор.
                        Технический директор выбрал стратегию перекоса под бизнес с риском потерять команду, т.е. PM.
                        Шаг 0:
                        Выяснить с техническим, почему он выбрал этот путь?
                        Возможно что именно его шаги по задабриванию заказчика способствовали провалу итераций.

                        Если технический твердо решил пожертвовать командой, тогда какой смысл идти против течения?
                        Руководство готово на этот шаг. PM получается пойдет против своего начальника и не факт, что его поймут другие PM.
                        Да, они сделают работу в срок. Команда останется, но PM c вероятностью 90% лишится работы.

                          0
                          Какое решение пришло мне в голову — 1.У начальства узнаём кого смогут выделить на замену, если кто то решит сбежать посреди итерации. Выбиваем как можно лучших спецов. 2.На собрании объявляем, что в случае срыва сроков половину уволят, и с какой формулировкой в трудовой — неизвестно. Но если кто-то проявит желание уволиться сразу, то договорюсь чтобы уволили по-нормальному, потом мол ничего сделать уже не смогу. 3.Увольняем тех кто пришёл первым (самых немотивированных и нервных), идём к начальству и говорим дескать пара человек уволилась, давайте отменим решение (пока все не разбежались, тем более что показательная кровь пролита) и немного отодвинем срок следующего релиза. 4.Независимо от того отменили или нет решение идём и говорим команде что вроде как начальство смягчилось и возможно репрессий не будет. 5.Пришедших новых (наверное где то троих) сотрудников просим свежим взглядом посмотреть на проект и оценить что не так. Мотивируем плюшками, премиями и рассказами о важности проекта новичков работать по выходным, дабы они воплощали свои идеи и предложения, которые у них возникли. Главное чтобы они не переусердствовали, улучшения ради улучшений — не выход. Возможно иногда мельком консультироваться с каким нибудь опытным архитектором (в компании на 100 человек хоть одна светлая голова должна быть), проверяя пользу от предложений. Старых сотрудников не заставляем работать сверхурочно и не перенапрягаем их — велик риск что они где-нибудь ошибутся, они итак морально истощены.

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

                          Интересно было бы узнать, какие недостатки у этого решения?
                            0
                            Недостаток в том, что не понятна причина.
                            А причина, например, в том, что Ген. директор компании рассчитывает на еще один проект от заказчика, но его планы не сбываются. Тех. директор рискует своим местом и вызывает на ковёр менеджера. Т.е. чтобы решилась проблема, нужно получить новый проект от заказчика.
                            Вариант 1: PM с командой уложились в итерацию. Заказчик стал доволен и заключил новый контракт. Как вы думаете чья заслуга в привлечении нового контракта перед Ген. директором будет выше технического или PM?
                            + Т.е. в лучшем случае вы не заработаете очки в лице Ген. директора и тех. директора.
                            — потеряли несколько человек в команде
                            — допустили переход команды из стадии производства в стадию формирования, и хорошо если миновали стадию конфликтов

                            Вариант 2: РМ провалил итерацию. Что бы вы сделали на месте технического?
                              0
                              Потеряли несколько человек в команде

                              А чем это плохо? Напомню, что ушли самые не лояльные. В команде не было звёзд. Их бы всё равно уволить пришлось, иначе бы сложилось впечатление что компания не держит слова. На вариант, что «повезёт» и не придётся, надежды мало. Почему тогда уж вы не рассматриваете шанс, что «повезёт», и никто не уволится, но приложит усилия чтобы вытащить проект? Лучше пусть хоть сами уволятся, так хоть имидж компании не сильно пострадает в глазах работников.

                              допустили переход команды из стадии производства в стадию формирования

                              А чем это плохо? Команда то всё равно не справлялась. И команда не «кристализованная», раз ультиматум «уйдём все» не предъявили. Да и решение «уволить половину» не было принято именно манагером, он в данном случае просто взял под контроль этот процесс.
                                0
                                Потеряли несколько человек в команде

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

                                Пока она будет формироваться, неизбежен провал в производительности. А это дополнительные риски.
                                  0
                                  в глазах команды этот шаг может выглядеть как выбор жертвы

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

                                  в его глазах вы или сплоховали или нужно обставить этот шаг

                                  Можно сказать: «Я не мог скрывать от команды положение вещей. Мы с тобой это обговорили когда я выбивал кадры. Неужели ты не предвидел ОЧЕВИДНЫЕ последствия СВОЕГО решения?»

                                  не ушли действительно ценные сотрудники

                                  По условию кейса в команде одни середняки.

                                  Пока она будет формироваться, неизбежен провал в производительности. А это дополнительные риски.

                                  Согласен, это риск. Но когда человек ищет новую работу, он неэффективен, может оставить после себя кучу багов, которые потом сложно будет исправить. Это гораздо больший риск. Имхо, лучше чтобы те кто хочет уйти заявили об этом как можно раньше. Когда провоцируем их на это, имеем возможность оценить, кто хочет уйти больше. Просто попросить людей сообщить о их намерениях — значит надеяться на удачу. Если человек не видит с вами общего будущего, то нет и сильных причин быть с вами полностью откровенными.
                                    +1
                                    Я писал немного о другом.
                                    В моей практике бывали случаи когда нужно было кого-то уволить по сокращению. Естественно команда никогда меня не упрекала и понимала что это не моя идея. Но за двумя уволенными уходили ещё два, которые просто решили перестраховаться. В принципе их всё устраивало в нашей компании, но у них исчезала уверенность что в компании всё и дальше будет хорошо.
                                    Так и здесь, программист может думать: «Срок провалили — это плохо. Но почему сразу не уволили? Наверное нам что-то не договаривают. Обновлю я пожалуй резюме».
                              0
                              Увольняем тех кто пришёл первым (самых немотивированных и нервных)


                              Не катит. Если уволится один — за ним пойдут все. Задача — любой ценой сохранить всю команду. Проходил через это :(
                              +7
                              Для затравки анекдот в тему:

                              В результате опроса «На что вы готовы в условиях кризиса чтобы сохранить место?», 80 % согласились на уменьшение зарплаты, 19 % согласились переспать с боссом, 1 % согласились переспать с собакой босса, и ни одна сволочь не согласилась работать лучше.

                              Мне кажется, что когда собираются менеждеры более 1 человека, то возникает эффект диссинергии. Я понимаю, что данный кэйс, это сферический конь в вакууме, но давайте рассмотрим реакцию такого же сферического mid то sr. разработчика…

                              Шаг №1. На общем собрании с командой описать ситуацию. И сообщить, что если итерацию не сдадим. то уволят всех.

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

                              Шаг №2.… Если вы для себя решите уйти до конца итерации — большая просьба в течение ближайших 2-3 дней сообщите ...

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

                              Шаг №3,… чтобы минимизировать риск нашего непопадания в сроки, я предлагаю целиться на 5 дней раньше

                              Ага, два раза подряд в сроки не укладывались, а тут на пустом месте получится даже лучше с меньшем количеством народа. Менеджеры — такие менеджеры! Срочно перечитываем ТК снова, и ищем работу более активно.

                              Как результат, с большой долей вероятности будет третий фэйл подряд.
                                0
                                Это понятно. :) А с точки зрения руководителя проекта что делать, когда до такой ситуации уже дошло?
                                  +3
                                  Краткий ответ: ничего.

                                  Развернутый ответ: В результате управления данным проектом был достигнут 40% fail rate, с большим негативным влиянием на бизнес заказчика. Данная активность подчеркивает некомпетентность менеджера (и только его), и шаги, предпринятые данным индивидом в «стрессовой» для команды ситуации, приведут к очередной неудаче.

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

                                  Шаги необходимые предпринять на уровне руководства компании:
                                  — уволить руководителя проекта;
                                  — договориться с заказчиком о переходном периоде за счет компании подрядчика, в результате которого, новым вменяемым руководителем проекта будет создан и реализован план уменьшения до нуля негативного влияния разработки на бизнес заказчика.
                                    0
                                    изменения в составе реализуемых требований и недооценка сроков на реализацию изменений

                                    А как такой вариант?
                                    Менеджер прогнулся под требования заказчика и получился фэйл. CTO устраивает этот менеджер, но решил дополнительно его промотивировать а заодно и всю команду (забыл что когда-то читал Де Марко :))
                                    Заказчик опять меняет требования и тут уже 100% либо фэйл, либо отказать заказчику. Заказчик на прямом контакте с CEO.
                                    Менеджеру сразу уволиться или героически работать всей командой по выходным?
                                      0
                                      Менеджер прогнулся под требования заказчика и получился фэйл.

                                      Заказчик опять меняет требования и тут уже 100% либо фэйл, либо отказать заказчику.

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

                                      Управление требованиями это достаточно понятный и простой процесс. И объяснить заказчику что нельзя где-то добавить, не убавив в другом месте может любой вменяемый человек. Так что, указанные 2 случая прекрасно ложаться в концепцию 40% fail rate — фэйл только управления.
                                      А вы, друзья, как ни садитесь,
                                      Всё в музыканты не годитесь.
                                    +1
                                    1. Если вина 90-100% менеджера, то взять вину на себя и договориться с техническим, что команда будет не в курсе угрозы увольнения. Ну или скрыть это от команды.
                                    2. Если технический хочет крови, то договориться что он её получит уже сейчас и дальше продолжать спокойно работать.
                                  0
                                  Тут есть по меньшей мере два косяка, подлежащих исправлению.

                                  1. Нет плана отката (на случай неполадок).

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

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

                                  Говорить об угрозе уволить половину надо, но не как о чем-то реальном, т.к. это увольнение вполне реально предотвратить путем перераспределения ресурсов между разработкой и тестированием. А также путем внедрения практик деплоя, допускающих быстрый откат. Думаю, месяца на рефакторинг деплоя хватит, а заказчик поймет, почему не сделано больше ничего.
                                    0
                                    Я думаю менеджер должен спросить себя «А зачем мне это нужно?». Зачем рвать жопу, пытаться выдавить результат которого нет, из затурканной команды, которая сейчас будет разбегаться с тонущего корабля своего проекта.
                                    Очевидно, что если никто из вышестоящего начальства не озаботился поиском конструктивного решения в стиле «придумайте как сделать так чтобы все было хорошо», вместо «давайте накажем всех причастных», то и дальше он будет действовать в такой канве. Ну и зачем менеджер и разработчики будут выбирать работать на глупого тирана, вместо того чтобы найти себе место на котором к ним будут относится как к людям.
                                      0
                                      Оплатил подписку на кейс клуб 4 часа назад. Пришло письмо от 2co.com об оплате, а письма от Стратоплана со ссылками, логинами и паролями не получал. Письмо будет позже, или это какой-то баг?
                                        0
                                        Написал в личку.
                                        +2
                                        Вы описали экзистенциальную проблему и ищете способ её решения в плоскости социальных взаимодействий. Однако, экзистенциальные проблемы решаются не через социальные отношения, а через осознание себя и своего пути. Руководителю проекта следует задаться вопросами «Кто я и что вообще здесь делаю? Профессионал ли я? К чему я стремлюсь? Куда я веду команду? Во что я верю?» (для сравнения, в вашем варианте руководитель проекта задаётся вопросом «как мне решить ситуацию с наименьшими потерями _для себя_?»).
                                        Подобные экзистенциальные кейсы (с внешним давлением) — это изменение характера в итоге и неизбежные потери в процессе. С этими потерями нужно просто смириться, каждый в команде что-то потеряет, нужно просто идти к конечной цели, выкладываться по полной. Вопрос только в том, какова она — конечная цель для каждого. Кому важнее быть профессионалом, кому — заработать денег, кому — уйти от ответственности, кому — проявить характер. Каждый в команде должен сам для себя найти ответ на этот вопрос, который поставит перед ним тимлид. Но прежде чем ставить этот вопрос перед командой тимлид должен решить его сам. А дальше как в этом видео youtu.be/UjQQVJWzlLI

                                        После этого у команды есть шанс отрастить яйца и выйти на новый уровень слаженности и результатов. Например, они могут подойти к техдиру и сказать:
                                        — Вы сами должны понимать, что запугивание — в долгосрочной перспективе демотивирующий фактор. Своей угрозой Вы фактически положили начало конца кадровому изобилию в компании, ибо никто теперь не сможет работать без оглядки. Если мы не сдавали проект в срок, а после ваших угроз сдадим — то это будет воспринято коллективом и начальством как зелёный свет угрозам. Если мы прогнёмся сейчас — что помешает вам угрожать увольнением в будущем? А жить и работать в страхе невозможно, и люди начнут уходить, начиная с лучших. Поэтому, чтобы избежать такого сценария, почему бы Вам не внести компенсаторный мотивирующий фактор, например, в виде бонуса за сданный в срок проект? В самом деле, если этот проект так важен для Вас, что мы должны работать в авральном режиме — то этот авральный режим нужно компенсировать. У нас жёны, дети. Мы могли бы форсировать проект, выходя на работу в субботу-воскресенье, но что мы за это получим? Вы пытаетесь переложить на нас Ваши риски — так риски предполагают компенсацию. Как насчёт +50% к з/п? Нет? Ну что ж, в нынешних условиях сдать проект в срок нет возможности, по итогам Вы уволите пол-команды, это точно не улучшит результативность по проекту, через какое-то время он закроется, и в итоге уволят уже Вас.

                                        Итого, последовательность шагов для тимлида:
                                        1. Решить для себя, кто он, и что делает на текущей должности и в текущей команде,
                                        2. Озвучить проблему коллективу и спросить «почему мы фейлим сроки? мы профи или кто? вы понимаете, что мы дошли до края, до ребра вопроса, так сказать? мы здесь нужны для решения конкретной задачи, а сделать мы её не можем. это вопрос даже не наличия работы, это вопрос профессиональной гордости.»
                                        3. Когда команда перебурлит и мнения начнут склоняться к «мы профессионалы и готовы это доказать, в первую очередь самим себе» — пойти к техдиру, объяснить механизм демотивации-мотивации и выбить компенсаторный мотивирующий фактор в виде увеличения зп для всей команды.
                                        4. После этого идти к команде и озвучивать им: «Зарплату нам подняли, теперь заживём. Но если не сдадим проект в очередной срок — уволят всех. И меня. Потому что мы либо решаем задачу, либо не нужны.»

                                        И тогда будет шанс уложиться в срок. Потому что главное во всей истории — укладываться в срок.
                                          +2
                                          Красиво, но не жизненно. Или мне редко встречались команды готовые встать и идти к техдиру. Скорее всего каждый будет решать проблему сам за себя. И если менеджер бросится грудью на амбразуру, то не факт что вся команда последует за ним. И всех жёны и дети. И кушать ещё никто не отменял.
                                            0
                                            Потому я и говорю, что вопрос экзистенциальный. Каждый сам должен решить, на что он готов ради того, что для него важно — тогда у него появятся силы за это бороться. А задача тимлида в этой ситуации — объяснить команде, что самое правильное — победить задачу, говоря примерно следующее: «Что бы вы, ребята, ни делали, вы — профессионалы, и ваш путь в жизни и на рынке — быть профессионалом, и если вы хотите лучшего будущего — направьте ваши усилия на оттачивание профессиональных навыков. Вы можете сменить место работы, но кому нужны сотрудники, бегущие от задач? Либо мы все вместе решаем эту задачу, либо это начало конца моей карьеры. И ваших тоже.»
                                            +2
                                            +50% очень смело и неожиданно. Но если спокойно разобраться, то с т.з. техдира это как выглядит: мы команда, оценили спринт и утвердили сроки. Но если мы в них уложимся, в свои же сроки, то давайте нам премию.
                                              0
                                              Прибавка может быть 10-20%. Это психологический момент. Члены команды должны иметь основание считать, что они стараются потому что их стали выше ценить, а не потому что их испугали.
                                            +1
                                            Странная ситуация при регулярной доставке, лучше какие-то задачи завершить, а какие-то перенести на следующую итерацию, чем торопиться и косячить.
                                              0
                                              Часть 1 — что и кому говорить.

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

                                              Такой подход и покажет серьезность ситуации, и даст понимание, что все сейчас зависит от команды.

                                              Если озвучить, что есть решение ополовинить команду, то начнутся перетягивания одеяла и подковерная возня, желательно, как можно дольше избегать этого.

                                              Так же нужно показать команде свою заинтересованность в сохранении команды.

                                              Часть 2 — так ли все безсистемно?

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

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

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

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое