Комментарии 47
1. Сообщить, что мы провалили сроки два раза подряд и это очень плохо — пообещали расформировать отдел, неизвестно все ли при этом останутся в компании. Донести это ясно, но долго не останавливаться, чтобы руки не начали опускаться.
2. Послушать предложения команды как исправить ситуацию с провалами.
3. Выяснить какая неучтенная работа помешала выпустить каждую из продуктов вовремя и выделить ее как отдельную задачу с отдельными же оценками. При спуске сверху новых требований всегда явно давать заказчику выбор — сроки или новые требования и обозначать риски.
4. Несмотря на то, что вы говорите, что какой-то одной проблемы выявить не удалось, все указанные проблемы кроме срыва сроков (которые мы должны были учесть в п.3) так или иначе связаны с собственно деплоем — изменением работающей у заказчика версии (а также с воспроизводимостью продакшна локально у программистов и тестеров, но это более глобальная задача и часто требует отдельной большой работы и отдельного человека на нее)
Здесь можно провести такие изменения:
* отвести на деплой время в планировании как на отдельную задачу (если он долгий) — чтобы все фичи и их тестирование закончить к этому моменту, а не к формальному концу итерации
* перенести время деплоя на время, которое создаст наименьшее количество проблем заказчику (например, ночью/в выходные — отдельно придется утрясти взаимозачет по этому времени с командой)
* договориться, что во время деплое вся команда сидит и ждет багов, чтобы их экстренно фиксить (или дежурные люди, если у всех есть квалификация фиксить все)
* В более дальней перспективе (если до этого доживем) исправить процесс стандартизирования конфигураций, тестирования, снятия метрик и мониторинга и собственно самого деплоя
2. Послушать предложения команды как исправить ситуацию с провалами.
3. Выяснить какая неучтенная работа помешала выпустить каждую из продуктов вовремя и выделить ее как отдельную задачу с отдельными же оценками. При спуске сверху новых требований всегда явно давать заказчику выбор — сроки или новые требования и обозначать риски.
4. Несмотря на то, что вы говорите, что какой-то одной проблемы выявить не удалось, все указанные проблемы кроме срыва сроков (которые мы должны были учесть в п.3) так или иначе связаны с собственно деплоем — изменением работающей у заказчика версии (а также с воспроизводимостью продакшна локально у программистов и тестеров, но это более глобальная задача и часто требует отдельной большой работы и отдельного человека на нее)
Здесь можно провести такие изменения:
* отвести на деплой время в планировании как на отдельную задачу (если он долгий) — чтобы все фичи и их тестирование закончить к этому моменту, а не к формальному концу итерации
* перенести время деплоя на время, которое создаст наименьшее количество проблем заказчику (например, ночью/в выходные — отдельно придется утрясти взаимозачет по этому времени с командой)
* договориться, что во время деплое вся команда сидит и ждет багов, чтобы их экстренно фиксить (или дежурные люди, если у всех есть квалификация фиксить все)
* В более дальней перспективе (если до этого доживем) исправить процесс стандартизирования конфигураций, тестирования, снятия метрик и мониторинга и собственно самого деплоя
Спасибо, хорошее решение. Формулировка «пообещали расформировать отдел, неизвестно все ли при этом останутся в компании» — очень удачная, имхо. Записал себе в блокнотик. )
Заметил момент небольшой в вашем решении — если говорить «уволят меня в первую очередь», надо это еще донести и начальству. Иначе может выйти, что все провалили, а меня просто перевели на другой проект.
Да и то, что часть людей может сразу из проекта начать выходить, тоже сразу нужно с начальством и, вероятно, с заказчиком обговорить, т.к. у нас по этой причине может возникнуть провал по производительности.
Да и то, что часть людей может сразу из проекта начать выходить, тоже сразу нужно с начальством и, вероятно, с заказчиком обговорить, т.к. у нас по этой причине может возникнуть провал по производительности.
Мой вариант ответа — уволится самому / передать дела более компетентному менеджеру. Регулярно ломать заказчику продакшен — верх некомпетентности. Тем более с позицией «Успеет команда сдать релиз, не успеет — жизнь покажет».
После первого-же срыва надо брать и разбираться почему так произошло и как сделать чтобы не повторилось. Увеличить сроки на тестирование, организовать тестовое окружение, максимально приближенное к продакшену. Предусмотреть быстрый откат до предыдущей версии, если что-то пошло не так. Способов масса — было бы желание и бюджет.
После первого-же срыва надо брать и разбираться почему так произошло и как сделать чтобы не повторилось. Увеличить сроки на тестирование, организовать тестовое окружение, максимально приближенное к продакшену. Предусмотреть быстрый откат до предыдущей версии, если что-то пошло не так. Способов масса — было бы желание и бюджет.
Да, да — и бюджет…
Я бы к этому добавил, что обязательно по результатам каждого серъезного прокола надо не только проводить работу над ошибками внутри команды, но еще и в деталях обсуждать случившееся с вышестоящим начальством, чтобы начальство видело, что дело не пущено на самотек, с проблемами борются. А если руководитель команды из раза в раз заметает мусор под ковер, то это действительно верх некомпетентности и наплевательского отношения и к заказчику, и к команде, и к своей компании. Опытный человек от подобного начальника сам уйдет не дожидаясь бесславного конца всей команды.
Вариант понятный. Но все-таки представим себе, что этот не вполне опытный менеджер таки должил до этой решающей итерации, и теперь у него есть шанс исправиться и начать делать как надо. Что ему делать в этой ситуации? Увольняться — вариант, но что тогда будет с выпуском итерации и командой?
Первым шагом — посовещаться с деплоями и придумать способ не ломать заказчику продакшен. На мой взгляд — говорить разработчикам что их могут уволить нужно только если ничего вменяемого так и не придумали и никакого плана по решению проблемы нет. Чтобы люди могли начать искать себе другое место.
Если какое-то решение всё же нашли — говорить об увольнении никому не нужно. Аргументы:
1) Люди могут уйти. Особенно те, кто не имеет отношения к этой проблеме. Если бы мне сказали что могут уволить за то что накосячил другой — я бы подумал, стоит ли мне работать в такой компании. Даже если всё решится успешно — кто-то может всё равно уйти после этого.
2) Под воздействием стресса кто-то будет работать эффективней, а кто-то наоборот начнёт косячить там где раньше всё было хорошо. Вероятность фейла увеличивается.
3) Собственная репутация страдает. Фактически — признание своей ошибки и перекладывание ответственности на команду (даже если сказать что уволят в том числе и самого менеджера).
По поводу слухов — всегда можно сказать «ничего не знаю, первый раз слышу, в любом случае — в этот раз мы приняли меры и релиз пройдет гладко».
Если какое-то решение всё же нашли — говорить об увольнении никому не нужно. Аргументы:
1) Люди могут уйти. Особенно те, кто не имеет отношения к этой проблеме. Если бы мне сказали что могут уволить за то что накосячил другой — я бы подумал, стоит ли мне работать в такой компании. Даже если всё решится успешно — кто-то может всё равно уйти после этого.
2) Под воздействием стресса кто-то будет работать эффективней, а кто-то наоборот начнёт косячить там где раньше всё было хорошо. Вероятность фейла увеличивается.
3) Собственная репутация страдает. Фактически — признание своей ошибки и перекладывание ответственности на команду (даже если сказать что уволят в том числе и самого менеджера).
По поводу слухов — всегда можно сказать «ничего не знаю, первый раз слышу, в любом случае — в этот раз мы приняли меры и релиз пройдет гладко».
Друзья, чтобы минимизировать риск нашего непопадания в сроки, я предлагаю целиться на 5 дней раньше.
Если уж врать про пол-команды, то и тут тоже стоит — не говорить, давайте фантазировать, что срок ближе, а просто, соврать про него. Это как с переведенными часами, все равно это помнишь и мозг ориентируется на правильное время.
Может быть это вообще решило бы все проблемы? (не лучший вариант, но раз менеджер не в состоянии разобраться «что не работает», то для него устойчивый вариант).
А что если «команда узнает про реальные сроки»? Ничего страшного — сказать, что оставшееся время он будет проверять проект сам или что-то в этом духе. Так как ЗП и стабильности людей ничего не угрожает, то подрыва доверия не будет — это вообще обычная практика, делать запас.
На общем собрании с командой описать ситуацию. И сообщить, что если итерацию не сдадим. то уволят всех. И меня. как менеджера, в первую очередь.
И вы не разобрали риск сплетни о половине команды.
В зависимости от степени человеческого фактора в данной ситуации (scope распухал, потому что заказчик через своё аффилированное в компании лицо проталкивал больше функционала в итерацию? заказчик не способен адекватно оценить сложность реализации и ссылается на Васю, который за полцены сделает в два раза больше? можно придумать мноого разных вариантов...), может иметь смысл пойти к человеку выше CTO (CEO, собственники, board members) и проговорить ситуацию. Прорываться в самые вершины. Кроме того, делать это надо, только сперва обговорив этот шаг с CTO. Возможно, что CTO согласится пойти говорить туда об этом вместе с вами, возможно что и от собственного лица. Всё это, в основном, человеческий фактор. В этом решении:
1) вы действуете в интересах бизнеса,
2) вы сохраняете авторитет,
3) вы работаете на команду.
Вариант, когда команда – отстой – не рассматриваю, потому что ну не бывает так, особенно в данной ситуации.
1) вы действуете в интересах бизнеса,
2) вы сохраняете авторитет,
3) вы работаете на команду.
Вариант, когда команда – отстой – не рассматриваю, потому что ну не бывает так, особенно в данной ситуации.
Очевидно не говорить нельзя, потому что сильно подорвет доверие к менеджеру. Кстати в статье почему-то доверие обозвали авторитетом. Скажу по секрету, у линейного менеджера практически никогда нет авторитета перед инженерами, кроме случаев когда менеджер — очень крутой технарь в прошлом.
Если сказать, то часть команды сразу напишет заявление, и даже дорабатывая две недели покажет в разы меньшую продуктивность чем ранее. Рассчитывать на то, что такой негативный стимул даст положительный эффект — нельзя, скорее всего не даст. Оба эти фактора недвусмусленно намекают на то, что успеть в срок не получится вообще и в любом случае половину команды разгонят. Инженеры не лохи и прекрасно понимают ситуацию.
Поэтому если сказать что уволят всех — все побегут искать новую работу. Если сказать что уволят половину, побегут искать новую работу (сразу или через пару дней) подавляющее большинство, останутся только те, кто умеет хорошо лизать.
В любом случае менеджер не сможет выполнить обязательства и скорее всего также будет уволен, тем более он уже умудрился зафейлить несколько деплоев подряд (типа как без явных проблем, ага).
В итоге для менеджера два нормальных варианта:
1) Если его ценят в организации и доверяют, то надо шантажировать техдира тем, что менеджер прямо сейчас уйдет и некому будет вытягивать проект и заказчик один хрен останется недовольным, естественно при условии что если не вытянет релиз, то уйдет сам. Короче взять всю ответственность на себя, изолировав команду от негатива.
2) Если менеджера и команду вообще не ценят, то сразу попытаться продаться все командой в другую компанию, объясняя это хреновой позицией со стороны руководства (показательные расстрелы, невозможность договориться с заказчиком итп).
Но ситуация сама по себе странная, менеджеру было заранее известно о таком business impact деплоя. Почему нельзя было после первого фейла деплой починить?
Как минимум сделать его более гранулярным, чтобы можно было быстрее накатить.
Во-вторых сделать компоненты менее связными, чтобы проблема в одном не останавливала работу кучи народу.
В-третьих наладить тестирование деплоя на staging, возможно прямо у заказчика. Все это можно было бы сделать за одну-две итерации и проблема вовсе бы ушла.
Странное поведение техдира. Зачем увольнять инженеров, их довольно сложно потом будет набрать. А если это был раздутый штат, то зачем устраивать «показательные расстрелы»? И почему после второго-третьего фейла не уволили менеджера.
Короче неадекватно как поведение участников, так и сам вопрос.
Если сказать, то часть команды сразу напишет заявление, и даже дорабатывая две недели покажет в разы меньшую продуктивность чем ранее. Рассчитывать на то, что такой негативный стимул даст положительный эффект — нельзя, скорее всего не даст. Оба эти фактора недвусмусленно намекают на то, что успеть в срок не получится вообще и в любом случае половину команды разгонят. Инженеры не лохи и прекрасно понимают ситуацию.
Поэтому если сказать что уволят всех — все побегут искать новую работу. Если сказать что уволят половину, побегут искать новую работу (сразу или через пару дней) подавляющее большинство, останутся только те, кто умеет хорошо лизать.
В любом случае менеджер не сможет выполнить обязательства и скорее всего также будет уволен, тем более он уже умудрился зафейлить несколько деплоев подряд (типа как без явных проблем, ага).
В итоге для менеджера два нормальных варианта:
1) Если его ценят в организации и доверяют, то надо шантажировать техдира тем, что менеджер прямо сейчас уйдет и некому будет вытягивать проект и заказчик один хрен останется недовольным, естественно при условии что если не вытянет релиз, то уйдет сам. Короче взять всю ответственность на себя, изолировав команду от негатива.
2) Если менеджера и команду вообще не ценят, то сразу попытаться продаться все командой в другую компанию, объясняя это хреновой позицией со стороны руководства (показательные расстрелы, невозможность договориться с заказчиком итп).
Но ситуация сама по себе странная, менеджеру было заранее известно о таком business impact деплоя. Почему нельзя было после первого фейла деплой починить?
Как минимум сделать его более гранулярным, чтобы можно было быстрее накатить.
Во-вторых сделать компоненты менее связными, чтобы проблема в одном не останавливала работу кучи народу.
В-третьих наладить тестирование деплоя на staging, возможно прямо у заказчика. Все это можно было бы сделать за одну-две итерации и проблема вовсе бы ушла.
Странное поведение техдира. Зачем увольнять инженеров, их довольно сложно потом будет набрать. А если это был раздутый штат, то зачем устраивать «показательные расстрелы»? И почему после второго-третьего фейла не уволили менеджера.
Короче неадекватно как поведение участников, так и сам вопрос.
Во-вторых сделать компоненты менее связными, чтобы проблема в одном не останавливала работу кучи народу.
А теперь как бывает в реальности — в наследство команде достались три тонны гавнокода где всё связанно со всем, при том через пятнадцать слоев абстракции (а как же, мы умеем проектировать, да), предыдущие три поколения тех кто в поте лица всё это
В-третьих наладить тестирование деплоя на staging, возможно прямо у заказчика. Все это можно было бы сделать за одну-две итерации и проблема вовсе бы ушла.
Суровая реальность — продакшн всегда отличается от стейджинга. Или потому что продакшеном занимается клиент, или свой отдел инфраструктуры, которым проблемы разработчиков не совсем близки. А ещё продакшн может сам по себе быть нестабильным, а клиент этого не понимает.
На кого ориентируетесь в продажах вашего кейс-клуба если не секрет? Например для жителя Москвы 11$ ерунда, а вот в моем регионе тратить эти деньги на что-то не совсем ясное — не хочется.
Мы никогда не делали ценовой дифференциации по регионам. Во-первых, непонятно, как это отследить, во вторых как-то это и несправедливо, имхо. Москвичам — одну цену, сибирякам — другую, беларусам — третью и т.д. Тем более, что везде люди работают с разными зарплатами и возможностями.
При этом у нас даже на годовую программу стоимостью 24,000 руб. есть участники со всего СНГ — от Беларуси и Калинграда до Петропавловска Камчатского, от Мурманска до Одессы.
Мы как-то пришли к пониманию того, что если человек к нам не приходит, значит, сейчас для себя он не видит ценности в этом за эти деньги. Значит, либо мы эту ценность лучше покажем (клуб, правда, толковая идея, я в нее очень верю), либо человек для себя поймет, зачем ему это нужно.
При этом у нас даже на годовую программу стоимостью 24,000 руб. есть участники со всего СНГ — от Беларуси и Калинграда до Петропавловска Камчатского, от Мурманска до Одессы.
Мы как-то пришли к пониманию того, что если человек к нам не приходит, значит, сейчас для себя он не видит ценности в этом за эти деньги. Значит, либо мы эту ценность лучше покажем (клуб, правда, толковая идея, я в нее очень верю), либо человек для себя поймет, зачем ему это нужно.
Нужно сказать команде правду, но вместе с тем предложить конкретный план, который не позволит допустить срыв сроков. Тогда команда будет знать, что их увольнение зависит не от нелепой случайности (развернется обновление ПО или заглючит), а от четкого следования плану каждым членом команды, если план представляется разумным, разработчики сделают все для его выполнения. Разумеется если на этот момент в команде уже царит атмосфера подозрительности и недоверия, то это не сработает и команду надо переформировывать.
Если в команде есть человек, способный сформировать план, то где он был во время предыдущих фэйлов? Если никто не видит закономерности в фэйлах, то никто не понимает их причину (например, 1)проблемы в коде или 2)отсутствие единого видения бизнесс-процессов заказчика и целей программы среди команды, из-за чего код вроде бы корректен, но противоречив или 3)жадность заказчика который хочет за итерацию больше фич чем может выкатить команда или ещё что угодно).
Ну ок, кто-то умный скажет, давайте писать n тестов, ревьюить код m раз и не уходить из офиса пока не выполним столько-то работ. А причина в жадности заказчика. Ну будете вы следовать плану, и как вам это поможет? Вспоминается поговорка — когда тысяча человек умирает по плану, то это нормально, когда внезапно умирает сто человек — то это трагедия. В данном случае план без понимания ситуации не гарантирует, что сроки будут выполнены.
Ну ок, кто-то умный скажет, давайте писать n тестов, ревьюить код m раз и не уходить из офиса пока не выполним столько-то работ. А причина в жадности заказчика. Ну будете вы следовать плану, и как вам это поможет? Вспоминается поговорка — когда тысяча человек умирает по плану, то это нормально, когда внезапно умирает сто человек — то это трагедия. В данном случае план без понимания ситуации не гарантирует, что сроки будут выполнены.
Но отсутствие плана гарантирует, что все будет пущено на самотек, люди будут чувствовать что от них ничего не зависит, что резко уменьшит работоспособность. Во время предыдущих фейлов никто не задумывался над составлением плана, казалось что эти фейлы случайны и серьезных последствий для команды не влекут. В ситуации же когда представляется последний шанс необходимы особые меры по подготовке, в том числе конкретный план. Да он может не помочь, возможно причины проблем вне компетенции команды, но по крайней мере все будут знать, что сделали максимум возможного и ничего лучше придумать было нельзя.
Планировать необходимо, но также важна и импровизация. Автор книги «Программист-фанатик» утверждает, что в критических ситуациях наиболее важна именно импровизация (но она невозможна без хорошей квалификации). Какие в данной ситуации мне видятся проблемы — 1)заказчик теряет деньги, 2)если программисты лишатся работы то они возможно будут недовольны, 3)если манагер не разрулит ситуацию или не докажет что она неразруливаема при текущих ресурсах то понизится его авторитет. При этом непонятно, какую из этих проблем можно решить и как. Заранее неизвестно, можно ли как-то убрать зависимость между потерей заказчиком денег и сроком релиза, можно ли убедить программиста что увольнение это не плохо а хорошо и т.д. Не узнаешь, пока не попробуешь. Когда известен результат попыток, возможно придётся изменить план на 180 градусов. Может быть для решения проблемы и не нужно биться над тем, чтобы выкладывать релиз в срок. А может быть нужно биться как раз над этим. Как составить хороший план в условиях такой неопределенности? Да, нужно составить первоначальный план, но он может измениться после наступления первого же события. При этом если команде заранее сказать — мешайте чай по часовой стрелке, и будет вам счастье, то после этого сложно будет направить их в другую сторону. Как они отнесутся к тому, когда после ваших заверений что мешание чая по часовой стрелке гарантирует успех, на следующий день вы заявите: «я передумал, уволен ты, ты и ты!».
Вы рассуждаете с точки зрения работника, а не манагера и отвечаете на вопрос — какое развитие событий благоприятно для зоны комфорта работника, чтобы ему было на что валить вину когда сроки выкладки снова запаздают (а так скорее всего и будет). Давайте повнимательнее посмотрим на ваше предложение с точки зрения работника: зарплата та же, не уважают, а заставляют лезть из кожи вон ради плана, с которым работник может быть и не согласен (всем не угодишь). Работник то честно работает, а тут какие-то неприятности потому что его команда видите ли плохо работает (может дело и в нём, но он никогда себе не признается). Будет он эффективнее и более мотивирован из-за наличия плана? Вряд ли. Повышение мотивации работников как средство решения проблемы посредством плана скорее всего не сработает. А если плана нету, может хоть сами что дельное предложат. По крайней мере слова о том, что у вас есть план который поможет решить проблему, когда его у вас его нет — это такая же ложь, что и «никого не уволят». Ну, может быть, уличить вас будет чуть сложнее
Вы рассуждаете с точки зрения работника, а не манагера и отвечаете на вопрос — какое развитие событий благоприятно для зоны комфорта работника, чтобы ему было на что валить вину когда сроки выкладки снова запаздают (а так скорее всего и будет). Давайте повнимательнее посмотрим на ваше предложение с точки зрения работника: зарплата та же, не уважают, а заставляют лезть из кожи вон ради плана, с которым работник может быть и не согласен (всем не угодишь). Работник то честно работает, а тут какие-то неприятности потому что его команда видите ли плохо работает (может дело и в нём, но он никогда себе не признается). Будет он эффективнее и более мотивирован из-за наличия плана? Вряд ли. Повышение мотивации работников как средство решения проблемы посредством плана скорее всего не сработает. А если плана нету, может хоть сами что дельное предложат. По крайней мере слова о том, что у вас есть план который поможет решить проблему, когда его у вас его нет — это такая же ложь, что и «никого не уволят». Ну, может быть, уличить вас будет чуть сложнее
Интересный кейс. Но по моему учтены не все составляющие.
Обычный сферический менеджер слуга 3-х господ (бизнес, команда, авторитет).
Но в данном кейсе два менеджера: PM и технический директор.
Технический директор выбрал стратегию перекоса под бизнес с риском потерять команду, т.е. PM.
Шаг 0:
Выяснить с техническим, почему он выбрал этот путь?
Возможно что именно его шаги по задабриванию заказчика способствовали провалу итераций.
Если технический твердо решил пожертвовать командой, тогда какой смысл идти против течения?
Руководство готово на этот шаг. PM получается пойдет против своего начальника и не факт, что его поймут другие PM.
Да, они сделают работу в срок. Команда останется, но PM c вероятностью 90% лишится работы.
Обычный сферический менеджер слуга 3-х господ (бизнес, команда, авторитет).
Но в данном кейсе два менеджера: PM и технический директор.
Технический директор выбрал стратегию перекоса под бизнес с риском потерять команду, т.е. PM.
Шаг 0:
Выяснить с техническим, почему он выбрал этот путь?
Возможно что именно его шаги по задабриванию заказчика способствовали провалу итераций.
Если технический твердо решил пожертвовать командой, тогда какой смысл идти против течения?
Руководство готово на этот шаг. PM получается пойдет против своего начальника и не факт, что его поймут другие PM.
Да, они сделают работу в срок. Команда останется, но PM c вероятностью 90% лишится работы.
Какое решение пришло мне в голову — 1.У начальства узнаём кого смогут выделить на замену, если кто то решит сбежать посреди итерации. Выбиваем как можно лучших спецов. 2.На собрании объявляем, что в случае срыва сроков половину уволят, и с какой формулировкой в трудовой — неизвестно. Но если кто-то проявит желание уволиться сразу, то договорюсь чтобы уволили по-нормальному, потом мол ничего сделать уже не смогу. 3.Увольняем тех кто пришёл первым (самых немотивированных и нервных), идём к начальству и говорим дескать пара человек уволилась, давайте отменим решение (пока все не разбежались, тем более что показательная кровь пролита) и немного отодвинем срок следующего релиза. 4.Независимо от того отменили или нет решение идём и говорим команде что вроде как начальство смягчилось и возможно репрессий не будет. 5.Пришедших новых (наверное где то троих) сотрудников просим свежим взглядом посмотреть на проект и оценить что не так. Мотивируем плюшками, премиями и рассказами о важности проекта новичков работать по выходным, дабы они воплощали свои идеи и предложения, которые у них возникли. Главное чтобы они не переусердствовали, улучшения ради улучшений — не выход. Возможно иногда мельком консультироваться с каким нибудь опытным архитектором (в компании на 100 человек хоть одна светлая голова должна быть), проверяя пользу от предложений. Старых сотрудников не заставляем работать сверхурочно и не перенапрягаем их — велик риск что они где-нибудь ошибутся, они итак морально истощены.
Если сроки не срываются, всё ок.
Когда сроки срываются, достаём красивую отмазку, что новички ещё не втянулись в проект и просим ещё шанс, давим на то что заказчик сам инициировал увольнение части команды, он дескать умный и должен был предвидеть последствия.
Если команда сообща договаривается увольняться одновременно и все сразу, прёмся к начальству и говорим что вон какая дружная и сыгранная Команда, нельзя таких людей разбивать, давайте отменим решение.
Интересно было бы узнать, какие недостатки у этого решения?
Если сроки не срываются, всё ок.
Когда сроки срываются, достаём красивую отмазку, что новички ещё не втянулись в проект и просим ещё шанс, давим на то что заказчик сам инициировал увольнение части команды, он дескать умный и должен был предвидеть последствия.
Если команда сообща договаривается увольняться одновременно и все сразу, прёмся к начальству и говорим что вон какая дружная и сыгранная Команда, нельзя таких людей разбивать, давайте отменим решение.
Интересно было бы узнать, какие недостатки у этого решения?
Недостаток в том, что не понятна причина.
А причина, например, в том, что Ген. директор компании рассчитывает на еще один проект от заказчика, но его планы не сбываются. Тех. директор рискует своим местом и вызывает на ковёр менеджера. Т.е. чтобы решилась проблема, нужно получить новый проект от заказчика.
Вариант 1: PM с командой уложились в итерацию. Заказчик стал доволен и заключил новый контракт. Как вы думаете чья заслуга в привлечении нового контракта перед Ген. директором будет выше технического или PM?
+ Т.е. в лучшем случае вы не заработаете очки в лице Ген. директора и тех. директора.
— потеряли несколько человек в команде
— допустили переход команды из стадии производства в стадию формирования, и хорошо если миновали стадию конфликтов
Вариант 2: РМ провалил итерацию. Что бы вы сделали на месте технического?
А причина, например, в том, что Ген. директор компании рассчитывает на еще один проект от заказчика, но его планы не сбываются. Тех. директор рискует своим местом и вызывает на ковёр менеджера. Т.е. чтобы решилась проблема, нужно получить новый проект от заказчика.
Вариант 1: PM с командой уложились в итерацию. Заказчик стал доволен и заключил новый контракт. Как вы думаете чья заслуга в привлечении нового контракта перед Ген. директором будет выше технического или PM?
+ Т.е. в лучшем случае вы не заработаете очки в лице Ген. директора и тех. директора.
— потеряли несколько человек в команде
— допустили переход команды из стадии производства в стадию формирования, и хорошо если миновали стадию конфликтов
Вариант 2: РМ провалил итерацию. Что бы вы сделали на месте технического?
Потеряли несколько человек в команде
А чем это плохо? Напомню, что ушли самые не лояльные. В команде не было звёзд. Их бы всё равно уволить пришлось, иначе бы сложилось впечатление что компания не держит слова. На вариант, что «повезёт» и не придётся, надежды мало. Почему тогда уж вы не рассматриваете шанс, что «повезёт», и никто не уволится, но приложит усилия чтобы вытащить проект? Лучше пусть хоть сами уволятся, так хоть имидж компании не сильно пострадает в глазах работников.
допустили переход команды из стадии производства в стадию формирования
А чем это плохо? Команда то всё равно не справлялась. И команда не «кристализованная», раз ультиматум «уйдём все» не предъявили. Да и решение «уволить половину» не было принято именно манагером, он в данном случае просто взял под контроль этот процесс.
Потеряли несколько человек в команде
Плохо в том, что технический не требовал кого-то срочно увольнять.
Т.е. в его глазах вы или сплоховали или нужно обставить этот шаг, что я мол разобрался в причинах наших неудач.
Но в глазах команды этот шаг может выглядеть как выбор жертвы и нужно предпринять шаги чтобы не ушли действительно ценные сотрудники.
допустили переход команды из стадии производства в стадию формирования
Пока она будет формироваться, неизбежен провал в производительности. А это дополнительные риски.
в глазах команды этот шаг может выглядеть как выбор жертвы
Манагер информирует команду о решении начальства. Кроме того, предлагает свою помощь — если кто хочет уволиться сейчас то надавлю на нужных людей и прослежу чтобы трудовую не замарали, а потом такой возможности может и не быть. В глазах команды манагера не за что упрекнуть.
в его глазах вы или сплоховали или нужно обставить этот шаг
Можно сказать: «Я не мог скрывать от команды положение вещей. Мы с тобой это обговорили когда я выбивал кадры. Неужели ты не предвидел ОЧЕВИДНЫЕ последствия СВОЕГО решения?»
не ушли действительно ценные сотрудники
По условию кейса в команде одни середняки.
Пока она будет формироваться, неизбежен провал в производительности. А это дополнительные риски.
Согласен, это риск. Но когда человек ищет новую работу, он неэффективен, может оставить после себя кучу багов, которые потом сложно будет исправить. Это гораздо больший риск. Имхо, лучше чтобы те кто хочет уйти заявили об этом как можно раньше. Когда провоцируем их на это, имеем возможность оценить, кто хочет уйти больше. Просто попросить людей сообщить о их намерениях — значит надеяться на удачу. Если человек не видит с вами общего будущего, то нет и сильных причин быть с вами полностью откровенными.
Я писал немного о другом.
В моей практике бывали случаи когда нужно было кого-то уволить по сокращению. Естественно команда никогда меня не упрекала и понимала что это не моя идея. Но за двумя уволенными уходили ещё два, которые просто решили перестраховаться. В принципе их всё устраивало в нашей компании, но у них исчезала уверенность что в компании всё и дальше будет хорошо.
Так и здесь, программист может думать: «Срок провалили — это плохо. Но почему сразу не уволили? Наверное нам что-то не договаривают. Обновлю я пожалуй резюме».
В моей практике бывали случаи когда нужно было кого-то уволить по сокращению. Естественно команда никогда меня не упрекала и понимала что это не моя идея. Но за двумя уволенными уходили ещё два, которые просто решили перестраховаться. В принципе их всё устраивало в нашей компании, но у них исчезала уверенность что в компании всё и дальше будет хорошо.
Так и здесь, программист может думать: «Срок провалили — это плохо. Но почему сразу не уволили? Наверное нам что-то не договаривают. Обновлю я пожалуй резюме».
Увольняем тех кто пришёл первым (самых немотивированных и нервных)
Не катит. Если уволится один — за ним пойдут все. Задача — любой ценой сохранить всю команду. Проходил через это :(
Для затравки анекдот в тему:
В результате опроса «На что вы готовы в условиях кризиса чтобы сохранить место?», 80 % согласились на уменьшение зарплаты, 19 % согласились переспать с боссом, 1 % согласились переспать с собакой босса, и ни одна сволочь не согласилась работать лучше.
Мне кажется, что когда собираются менеждеры более 1 человека, то возникает эффект диссинергии. Я понимаю, что данный кэйс, это сферический конь в вакууме, но давайте рассмотрим реакцию такого же сферического mid то sr. разработчика…
У человека семья, дети, кредиты, прочие расходы, и тут ему заявляют, что его доходу что-то угрожает. Правильная реакция — убрать угрозу как в краткосрочном, так и в долгосрочном плане. Соответственно, в краткосрочном плане перечитываем Трудовой Кодекс, в долгосрочном плане — обновляем резюме и приступаем к активному поиску работы.
Вобще-то в никуда не уходят в здравом уме при наличии указанных «расходов», поэтому ничего не говорим и продолжаем искать новое место. Свои реальные мысли «что вы по этому поводу» данный сферический разработчик не озвучивает, ибо никакого профита ему от этого не будет.
Ага, два раза подряд в сроки не укладывались, а тут на пустом месте получится даже лучше с меньшем количеством народа. Менеджеры — такие менеджеры! Срочно перечитываем ТК снова, и ищем работу более активно.
Как результат, с большой долей вероятности будет третий фэйл подряд.
В результате опроса «На что вы готовы в условиях кризиса чтобы сохранить место?», 80 % согласились на уменьшение зарплаты, 19 % согласились переспать с боссом, 1 % согласились переспать с собакой босса, и ни одна сволочь не согласилась работать лучше.
Мне кажется, что когда собираются менеждеры более 1 человека, то возникает эффект диссинергии. Я понимаю, что данный кэйс, это сферический конь в вакууме, но давайте рассмотрим реакцию такого же сферического mid то sr. разработчика…
Шаг №1. На общем собрании с командой описать ситуацию. И сообщить, что если итерацию не сдадим. то уволят всех.
У человека семья, дети, кредиты, прочие расходы, и тут ему заявляют, что его доходу что-то угрожает. Правильная реакция — убрать угрозу как в краткосрочном, так и в долгосрочном плане. Соответственно, в краткосрочном плане перечитываем Трудовой Кодекс, в долгосрочном плане — обновляем резюме и приступаем к активному поиску работы.
Шаг №2.… Если вы для себя решите уйти до конца итерации — большая просьба в течение ближайших 2-3 дней сообщите ...
Вобще-то в никуда не уходят в здравом уме при наличии указанных «расходов», поэтому ничего не говорим и продолжаем искать новое место. Свои реальные мысли «что вы по этому поводу» данный сферический разработчик не озвучивает, ибо никакого профита ему от этого не будет.
Шаг №3,… чтобы минимизировать риск нашего непопадания в сроки, я предлагаю целиться на 5 дней раньше
Ага, два раза подряд в сроки не укладывались, а тут на пустом месте получится даже лучше с меньшем количеством народа. Менеджеры — такие менеджеры! Срочно перечитываем ТК снова, и ищем работу более активно.
Как результат, с большой долей вероятности будет третий фэйл подряд.
Это понятно. :) А с точки зрения руководителя проекта что делать, когда до такой ситуации уже дошло?
Краткий ответ: ничего.
Развернутый ответ: В результате управления данным проектом был достигнут 40% fail rate, с большим негативным влиянием на бизнес заказчика. Данная активность подчеркивает некомпетентность менеджера (и только его), и шаги, предпринятые данным индивидом в «стрессовой» для команды ситуации, приведут к очередной неудаче.
На мой взгляд, в рамках кейса, удовлетворительного решения найдено не будет.
Шаги необходимые предпринять на уровне руководства компании:
— уволить руководителя проекта;
— договориться с заказчиком о переходном периоде за счет компании подрядчика, в результате которого, новым вменяемым руководителем проекта будет создан и реализован план уменьшения до нуля негативного влияния разработки на бизнес заказчика.
Развернутый ответ: В результате управления данным проектом был достигнут 40% fail rate, с большим негативным влиянием на бизнес заказчика. Данная активность подчеркивает некомпетентность менеджера (и только его), и шаги, предпринятые данным индивидом в «стрессовой» для команды ситуации, приведут к очередной неудаче.
На мой взгляд, в рамках кейса, удовлетворительного решения найдено не будет.
Шаги необходимые предпринять на уровне руководства компании:
— уволить руководителя проекта;
— договориться с заказчиком о переходном периоде за счет компании подрядчика, в результате которого, новым вменяемым руководителем проекта будет создан и реализован план уменьшения до нуля негативного влияния разработки на бизнес заказчика.
изменения в составе реализуемых требований и недооценка сроков на реализацию изменений
А как такой вариант?
Менеджер прогнулся под требования заказчика и получился фэйл. CTO устраивает этот менеджер, но решил дополнительно его промотивировать а заодно и всю команду (забыл что когда-то читал Де Марко :))
Заказчик опять меняет требования и тут уже 100% либо фэйл, либо отказать заказчику. Заказчик на прямом контакте с CEO.
Менеджеру сразу уволиться или героически работать всей командой по выходным?
Менеджер прогнулся под требования заказчика и получился фэйл.
Заказчик опять меняет требования и тут уже 100% либо фэйл, либо отказать заказчику.
Если нужен разовый «подвиг», необходимо промотивировать персонал, и не грамотами-медалями, а полновесными денежными единицами. Если же надрываться исполнителям входит в систему, то это показатель некомпетентности управленца.
Управление требованиями это достаточно понятный и простой процесс. И объяснить заказчику что нельзя где-то добавить, не убавив в другом месте может любой вменяемый человек. Так что, указанные 2 случая прекрасно ложаться в концепцию 40% fail rate — фэйл только управления.
А вы, друзья, как ни садитесь,
Всё в музыканты не годитесь.
1. Если вина 90-100% менеджера, то взять вину на себя и договориться с техническим, что команда будет не в курсе угрозы увольнения. Ну или скрыть это от команды.
2. Если технический хочет крови, то договориться что он её получит уже сейчас и дальше продолжать спокойно работать.
2. Если технический хочет крови, то договориться что он её получит уже сейчас и дальше продолжать спокойно работать.
Тут есть по меньшей мере два косяка, подлежащих исправлению.
1. Нет плана отката (на случай неполадок).
2. Нет полноценного тестового контура на территории заказчика. В идеале — кроликов, работающих с бета-версией системы на свой страх и риск (с возможностью быстро выйти из такого тестирования при первой ошибке).
Ну и не сказано, чем вариант «новая версия отличается только номером версии» не устраивает заказчика. Новых глюков-то при этом не будет!
Говорить об угрозе уволить половину надо, но не как о чем-то реальном, т.к. это увольнение вполне реально предотвратить путем перераспределения ресурсов между разработкой и тестированием. А также путем внедрения практик деплоя, допускающих быстрый откат. Думаю, месяца на рефакторинг деплоя хватит, а заказчик поймет, почему не сделано больше ничего.
1. Нет плана отката (на случай неполадок).
2. Нет полноценного тестового контура на территории заказчика. В идеале — кроликов, работающих с бета-версией системы на свой страх и риск (с возможностью быстро выйти из такого тестирования при первой ошибке).
Ну и не сказано, чем вариант «новая версия отличается только номером версии» не устраивает заказчика. Новых глюков-то при этом не будет!
Говорить об угрозе уволить половину надо, но не как о чем-то реальном, т.к. это увольнение вполне реально предотвратить путем перераспределения ресурсов между разработкой и тестированием. А также путем внедрения практик деплоя, допускающих быстрый откат. Думаю, месяца на рефакторинг деплоя хватит, а заказчик поймет, почему не сделано больше ничего.
Я думаю менеджер должен спросить себя «А зачем мне это нужно?». Зачем рвать жопу, пытаться выдавить результат которого нет, из затурканной команды, которая сейчас будет разбегаться с тонущего корабля своего проекта.
Очевидно, что если никто из вышестоящего начальства не озаботился поиском конструктивного решения в стиле «придумайте как сделать так чтобы все было хорошо», вместо «давайте накажем всех причастных», то и дальше он будет действовать в такой канве. Ну и зачем менеджер и разработчики будут выбирать работать на глупого тирана, вместо того чтобы найти себе место на котором к ним будут относится как к людям.
Очевидно, что если никто из вышестоящего начальства не озаботился поиском конструктивного решения в стиле «придумайте как сделать так чтобы все было хорошо», вместо «давайте накажем всех причастных», то и дальше он будет действовать в такой канве. Ну и зачем менеджер и разработчики будут выбирать работать на глупого тирана, вместо того чтобы найти себе место на котором к ним будут относится как к людям.
Оплатил подписку на кейс клуб 4 часа назад. Пришло письмо от 2co.com об оплате, а письма от Стратоплана со ссылками, логинами и паролями не получал. Письмо будет позже, или это какой-то баг?
Вы описали экзистенциальную проблему и ищете способ её решения в плоскости социальных взаимодействий. Однако, экзистенциальные проблемы решаются не через социальные отношения, а через осознание себя и своего пути. Руководителю проекта следует задаться вопросами «Кто я и что вообще здесь делаю? Профессионал ли я? К чему я стремлюсь? Куда я веду команду? Во что я верю?» (для сравнения, в вашем варианте руководитель проекта задаётся вопросом «как мне решить ситуацию с наименьшими потерями _для себя_?»).
Подобные экзистенциальные кейсы (с внешним давлением) — это изменение характера в итоге и неизбежные потери в процессе. С этими потерями нужно просто смириться, каждый в команде что-то потеряет, нужно просто идти к конечной цели, выкладываться по полной. Вопрос только в том, какова она — конечная цель для каждого. Кому важнее быть профессионалом, кому — заработать денег, кому — уйти от ответственности, кому — проявить характер. Каждый в команде должен сам для себя найти ответ на этот вопрос, который поставит перед ним тимлид. Но прежде чем ставить этот вопрос перед командой тимлид должен решить его сам. А дальше как в этом видео youtu.be/UjQQVJWzlLI
После этого у команды есть шанс отрастить яйца и выйти на новый уровень слаженности и результатов. Например, они могут подойти к техдиру и сказать:
— Вы сами должны понимать, что запугивание — в долгосрочной перспективе демотивирующий фактор. Своей угрозой Вы фактически положили начало конца кадровому изобилию в компании, ибо никто теперь не сможет работать без оглядки. Если мы не сдавали проект в срок, а после ваших угроз сдадим — то это будет воспринято коллективом и начальством как зелёный свет угрозам. Если мы прогнёмся сейчас — что помешает вам угрожать увольнением в будущем? А жить и работать в страхе невозможно, и люди начнут уходить, начиная с лучших. Поэтому, чтобы избежать такого сценария, почему бы Вам не внести компенсаторный мотивирующий фактор, например, в виде бонуса за сданный в срок проект? В самом деле, если этот проект так важен для Вас, что мы должны работать в авральном режиме — то этот авральный режим нужно компенсировать. У нас жёны, дети. Мы могли бы форсировать проект, выходя на работу в субботу-воскресенье, но что мы за это получим? Вы пытаетесь переложить на нас Ваши риски — так риски предполагают компенсацию. Как насчёт +50% к з/п? Нет? Ну что ж, в нынешних условиях сдать проект в срок нет возможности, по итогам Вы уволите пол-команды, это точно не улучшит результативность по проекту, через какое-то время он закроется, и в итоге уволят уже Вас.
Итого, последовательность шагов для тимлида:
1. Решить для себя, кто он, и что делает на текущей должности и в текущей команде,
2. Озвучить проблему коллективу и спросить «почему мы фейлим сроки? мы профи или кто? вы понимаете, что мы дошли до края, до ребра вопроса, так сказать? мы здесь нужны для решения конкретной задачи, а сделать мы её не можем. это вопрос даже не наличия работы, это вопрос профессиональной гордости.»
3. Когда команда перебурлит и мнения начнут склоняться к «мы профессионалы и готовы это доказать, в первую очередь самим себе» — пойти к техдиру, объяснить механизм демотивации-мотивации и выбить компенсаторный мотивирующий фактор в виде увеличения зп для всей команды.
4. После этого идти к команде и озвучивать им: «Зарплату нам подняли, теперь заживём. Но если не сдадим проект в очередной срок — уволят всех. И меня. Потому что мы либо решаем задачу, либо не нужны.»
И тогда будет шанс уложиться в срок. Потому что главное во всей истории — укладываться в срок.
Подобные экзистенциальные кейсы (с внешним давлением) — это изменение характера в итоге и неизбежные потери в процессе. С этими потерями нужно просто смириться, каждый в команде что-то потеряет, нужно просто идти к конечной цели, выкладываться по полной. Вопрос только в том, какова она — конечная цель для каждого. Кому важнее быть профессионалом, кому — заработать денег, кому — уйти от ответственности, кому — проявить характер. Каждый в команде должен сам для себя найти ответ на этот вопрос, который поставит перед ним тимлид. Но прежде чем ставить этот вопрос перед командой тимлид должен решить его сам. А дальше как в этом видео youtu.be/UjQQVJWzlLI
После этого у команды есть шанс отрастить яйца и выйти на новый уровень слаженности и результатов. Например, они могут подойти к техдиру и сказать:
— Вы сами должны понимать, что запугивание — в долгосрочной перспективе демотивирующий фактор. Своей угрозой Вы фактически положили начало конца кадровому изобилию в компании, ибо никто теперь не сможет работать без оглядки. Если мы не сдавали проект в срок, а после ваших угроз сдадим — то это будет воспринято коллективом и начальством как зелёный свет угрозам. Если мы прогнёмся сейчас — что помешает вам угрожать увольнением в будущем? А жить и работать в страхе невозможно, и люди начнут уходить, начиная с лучших. Поэтому, чтобы избежать такого сценария, почему бы Вам не внести компенсаторный мотивирующий фактор, например, в виде бонуса за сданный в срок проект? В самом деле, если этот проект так важен для Вас, что мы должны работать в авральном режиме — то этот авральный режим нужно компенсировать. У нас жёны, дети. Мы могли бы форсировать проект, выходя на работу в субботу-воскресенье, но что мы за это получим? Вы пытаетесь переложить на нас Ваши риски — так риски предполагают компенсацию. Как насчёт +50% к з/п? Нет? Ну что ж, в нынешних условиях сдать проект в срок нет возможности, по итогам Вы уволите пол-команды, это точно не улучшит результативность по проекту, через какое-то время он закроется, и в итоге уволят уже Вас.
Итого, последовательность шагов для тимлида:
1. Решить для себя, кто он, и что делает на текущей должности и в текущей команде,
2. Озвучить проблему коллективу и спросить «почему мы фейлим сроки? мы профи или кто? вы понимаете, что мы дошли до края, до ребра вопроса, так сказать? мы здесь нужны для решения конкретной задачи, а сделать мы её не можем. это вопрос даже не наличия работы, это вопрос профессиональной гордости.»
3. Когда команда перебурлит и мнения начнут склоняться к «мы профессионалы и готовы это доказать, в первую очередь самим себе» — пойти к техдиру, объяснить механизм демотивации-мотивации и выбить компенсаторный мотивирующий фактор в виде увеличения зп для всей команды.
4. После этого идти к команде и озвучивать им: «Зарплату нам подняли, теперь заживём. Но если не сдадим проект в очередной срок — уволят всех. И меня. Потому что мы либо решаем задачу, либо не нужны.»
И тогда будет шанс уложиться в срок. Потому что главное во всей истории — укладываться в срок.
Красиво, но не жизненно. Или мне редко встречались команды готовые встать и идти к техдиру. Скорее всего каждый будет решать проблему сам за себя. И если менеджер бросится грудью на амбразуру, то не факт что вся команда последует за ним. И всех жёны и дети. И кушать ещё никто не отменял.
Потому я и говорю, что вопрос экзистенциальный. Каждый сам должен решить, на что он готов ради того, что для него важно — тогда у него появятся силы за это бороться. А задача тимлида в этой ситуации — объяснить команде, что самое правильное — победить задачу, говоря примерно следующее: «Что бы вы, ребята, ни делали, вы — профессионалы, и ваш путь в жизни и на рынке — быть профессионалом, и если вы хотите лучшего будущего — направьте ваши усилия на оттачивание профессиональных навыков. Вы можете сменить место работы, но кому нужны сотрудники, бегущие от задач? Либо мы все вместе решаем эту задачу, либо это начало конца моей карьеры. И ваших тоже.»
+50% очень смело и неожиданно. Но если спокойно разобраться, то с т.з. техдира это как выглядит: мы команда, оценили спринт и утвердили сроки. Но если мы в них уложимся, в свои же сроки, то давайте нам премию.
Странная ситуация при регулярной доставке, лучше какие-то задачи завершить, а какие-то перенести на следующую итерацию, чем торопиться и косячить.
Часть 1 — что и кому говорить.
Команде, да, говорить, и говорить на общем собрании. Но не озвучивать, что собираются разогнать именно пол команды, сказать, что команда будет распущена, а вот с переводом на другие проекты или с увольнением сейчас сказать сложно, но пока намерения выглядят серьезными.
Такой подход и покажет серьезность ситуации, и даст понимание, что все сейчас зависит от команды.
Если озвучить, что есть решение ополовинить команду, то начнутся перетягивания одеяла и подковерная возня, желательно, как можно дольше избегать этого.
Так же нужно показать команде свою заинтересованность в сохранении команды.
Часть 2 — так ли все безсистемно?
Если сбои ранее были безсистемные, то причина, скорее всего, в самой системе, т.е. в том, как построен процесс. Поэтому нужно искать в себе, а также попросить всех участников предыдущих сбоев еще раз вспомнить все обстоятельства приведшие к ним.
Также слегка повысить степень контроля промежуточных результатов, озвучив это людям, как свою попытку выяснить причину сбоев.
Также стоит еще раз поговорить с заказчиком, выяснив есть ли общие и частные претензии к работе команды, возможно всплывут те вещи, которые косвенно или явно вызывают сбои.
Команде, да, говорить, и говорить на общем собрании. Но не озвучивать, что собираются разогнать именно пол команды, сказать, что команда будет распущена, а вот с переводом на другие проекты или с увольнением сейчас сказать сложно, но пока намерения выглядят серьезными.
Такой подход и покажет серьезность ситуации, и даст понимание, что все сейчас зависит от команды.
Если озвучить, что есть решение ополовинить команду, то начнутся перетягивания одеяла и подковерная возня, желательно, как можно дольше избегать этого.
Так же нужно показать команде свою заинтересованность в сохранении команды.
Часть 2 — так ли все безсистемно?
Если сбои ранее были безсистемные, то причина, скорее всего, в самой системе, т.е. в том, как построен процесс. Поэтому нужно искать в себе, а также попросить всех участников предыдущих сбоев еще раз вспомнить все обстоятельства приведшие к ним.
Также слегка повысить степень контроля промежуточных результатов, озвучив это людям, как свою попытку выяснить причину сбоев.
Также стоит еще раз поговорить с заказчиком, выяснив есть ли общие и частные претензии к работе команды, возможно всплывут те вещи, которые косвенно или явно вызывают сбои.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[кейс] Итерация вовремя или пол-команды?