Сегодня столкнулся (в очередной раз) с ситуацией, когда менеджер самого среднего звена, очень неплохой девелопер в прошлом и, как показывает практика, в будущем, выдав желаемое за действительное, очень крепко "подставил" всю команду.
Вот он, кейс на разбор. "CYA наоборот"
>> разбор кейса "CYA наоборт"
Давайте попробуем подумать над ним вместе; разобрать предлагаю с двух точек - понять мотивацию человека, совершившего подобный поступок, и придумать, как из этой ситуации выйти.
Игроки:
TL - dev team lead, по совместительству Scrum Master
PM - PM
QT - QA team
DT - dev team
DBA - data base admin
C - customer
Диалог1:
говорят C, DT, PM, TL, QT (демо спринта)
PM:
- Уважаемый TL, как Вы оцениваете готовность функционала к code freeze, который должен состояться 5 часов назад?
TL:
- Ну нам тут понты остались, в принципе, за пару дней справимся и выйдем в пре-релиз.
у QT расширяются глаза, в голове мысль: "Ну ничего себе, его же на тестирование еще и не ставили даже!"
С:
- Ну, хорошо. Ребята, скажите, насколько это повлияет на релиз, который должен состояться через неделю?
TL:
- Ну, по идее, мы должны успеть вовремя, возможна задержка в пару дней
QT думает: "Или мы что-то не понимаем, или одно из двух, но не подставлять же своих"
C:
- Окей. Я пару дней готов подождать, не проблема
Диалог2:
говорят PM, TL, QT
PM:
- Ну что, TL, завтра вы уже закончите и девелопмент и тестирование?
TL:
- Неет, тогда на демо я давал эстимейт только на девелопмент, а что?
PM:
- Ну а что с тестированием, сколько времени нужно, ты же SCRUM master?
TL:
- Даже не догадываюсь
QT:
- На тестирование нужно 5 человеко-дней и то при раскладе, что фикс, предложенный TL, будет сделан, как он говорит, завтра, то, если мы кинем все ресурсы, возможно и закончим через 2,5 дня после постановки на тестирование; и это только первый прогон тестов, после которого нужен будет баг фикс, потом снова перетестирование и пре-аксептанс всего релиза - итого 7-8 дней работы; и это только в случае, если наши метрики окажутся неверными, а в пессимистическом варианте релиз задержится на две с половиной недели.
PM:
- TL, а почему ты этого мне не сказал? Почему ты сказал что все хорошо?
TL:
- Ну, у меня же спросили сколько займет времени это доделать, я и сказал 2 дня.
PM:
- А тестирование?
TL:
- А я не подумал.
QT:
- Что там было думать - мы ж тебе на Стендапах это говорили?
TL:
- Ну, у меня же спросили сколько займет времени это доделать, а не протестировать.
……
Дальше начали играть в игры "давайте считать так, чтоб хоть как-то выпустить релиз", и к кейсу последующий диалог имеет весьма посредственное отношение.
Давайте попробуем подразобрать. Если нужны какие-то уточнения - пишите, добавлю.
>> разбор кейса "CYA наоборт"
РАЗРУЛИТЬ:
ReplyDeleteЗдесь многое зависит от адекватности и лояльности клиента. Если клиент с нами по одну стонону барикад, то надо перезвонить и сказать что тут факапчик вышел. Предложить несколько вариантов:
1. Обрезать скоп и выложить релиз во-время
2. Оставить скоп и двигать релиз.
Ну и быть готовым к тому, что клиент скажет что за нафиг и тогда команда рискует поработать овертайм за не понятно еще чей счет.
ПРЕДУПРЕДИТЬ:
На ретро пишите в lessons learned, что вышло так-то, на будующее ответственный (я так понимаю это скрам мастер в вашем случае) проверяет эстимейты от каждого на каждом стэндапе.
Скорее всего после такого Скрам Мастер будет впредь дважды перепроверять все эстимейты от всех членов команды, особненно, если команда таки будет овертаймить.
Кто виноват, понятно: все. Один наступил на известные грабли "ну что вы, мы же профессионалы, тут чуть-чуть". QT больше похоже "А что я могу сделать?" (хотя не понятно и я не настаиваю). А PM вообще не ясно.
ReplyDeleteЕсть только один непонятный момент. Если ситуация только вот раз проявилась, то все просто друг на друга понадеялись и недопоняли одновременно. Надо просто помнить. А вот если это уже не первый, или далеко не первый раз. То все или "молодцы" и не учатся или забили. Если второе, то капитан подсказывает, что у вас ПроблемЫ
Лечим симптомы.
Согласен с предыдущим коментарием. В такой ситуации так близко к релизу: либо не выкатываем, что не проверили, либо двигаем релиз, либо жестокого овертаймим. Вам виднее что выгоднее
Лечим болезнь.
Ощущение что такое не первый раз и ретроспектива тут уже не поможет. Только личные разговоры с ПМом и ТЛом. Ну и почаще в такого рода ситуациях кричать погромче, но вовремя, т.е. СРАЗУ, а не "Я же вам говорил". На демке заказчику можно мягко уточнять с учетом проверки или нет дается эстимейт и сразу решать на месте. А если такое озвучивается на дейли митингах, то прямо на нем или сразу после и разруливать.
А если разовая ситуация, то lessons learned именно то, что нужно
Артём, спасибо за интересный, жизненный кейс. Стратегически согласен с предыдущими комментами. От себя хочется добавить по двум пунктам.
ReplyDeleteДИАЛОГ (первый):
Похоже, что TL во время таких переговоров испытывает определённый стресс, раз забывает о 70% работы. :) Тем более, что он действительно потом признал это, а не пытался отмазаться. Поэтому, подставлять его, конечно же, не стоит, а нужно помочь. И сделать это было бы естественно со стороны QT, судя по описанному кейсу. TL был в прострации, что происходило в разуме PM'а кейс умалчивает, зато чётко написано что тестерам СРАЗУ ЖЕ пришла в голову правильная мысль - поэтому надо было ТУТ ЖЕ её и сказать, ну только, разумеется, подобрав правильную мягкую форму.
На первый взгляд вы не сыграли против TL, но вы сыграли против себя и PM'а. :( Dev lead'у в горячке релиза простительно на 1 час забыть о тестах, а PM'у и, тем более, QT - нет! И вы сыграли против клиента, т.к. на основании ваших эстимейтов он уже может пойти и что-то кому-то пообещать там у себя. И ещё - на западе нормально относятся к тому, что "нам надо посовещаться и посчитать". А если вы продолжите партизанскую тактику "жёсткого и молчаливого овертайма", то риск таки не уложиться в срок возрастает - и тогда все сядут в лужу.
Все мы знаем, что стоимость поправки бага тем меньше, чем раньше он обнаружен. В данном случае в первом диалоге был баг, тестеры его обнаружили, оставалось дело за малым - баг репорт. ;)
QT: "Так, ну эстимейт по разработке понятен, а по тестированию - надо посчитать... Навскидку от 7-8 дней до 2.5 недель."
QT: "TL, а ты про нас не забыл? :)"
QT: "Ребята, оставьте и нам что-нибудь! :))"
Если нет таких артистических талантов, то можно просто написать в личку TL'у и/или PM'у. Если TL не идиот - он вам только спасибо скажет. А по хорошему - PM должен был выяснить все эстимейты до начала митинга, чтоб не устраивать reality show перед клиентом. На мой взгляд, тут недоработка PM'а и QT. У TL всё понятно - стресс, не подумал, кается - и что с ним делать: бить или давать больше глюкозы - отдельная тема. Другое дело если он упорствует, чтобы выгородить себя - тогда бить. :))
РАЗРУЛИТЬ - аддон к 1 комменту (опять же - если это применимо к данному кейсу и, конечно же - если заказчик готов платить):
3. Reduce quality. Затестить основное и зарелизить. И пока заказчик будет мылить глаза своим заказчикам несколькими happy-path'ами - дотестить и дофиксить (возможно подкидывать патчи каджый день). Т.е. такой двойной релиз, из которых первый в срок и для витрины, а второй - латентный. :)
4. Add resources. Альтернатива "жёсткому овертайму" - если вдруг в соседней команде возможно взять ещё ручных тестеров на время. Заказчику что так, что так - платить, но наши ребята меньше устанут. ;)
Ребятам, которые не подставляют своих товарищей - мой удалённый респект! И всё же репортить баги любого рода лучше сразу и по существу, но мягко и тактично (мы ж добрые и любим своих). Успехов!
Коллеги, спасибо большое за ваши варианты, саммаризируем через денек-два в посте по разбору данного кейса.
ReplyDeleteВ общем и целом, я согласна с предыдущими ораторами :)
ReplyDeleteСамая первая ошибка была допущена, что в ТимЛида, исходя из его девелоперского прошлого, на подсознательном уровне не была вдолблена мысль о том, что после девелопмента должно идти тестирование, и именно после проведения тестирования, должно приниматься решение о выпуске продукта.
Во-вторых, как по мне, ошибка была допущена и на встрече с клиентом.
Я бы мягко поправила ТимЛида: "%Name, очевидно имел в виду время на написание кода, плюс, нам ещё понадобится некоторое время на тестирование - примерно, ещё неделя." И обостовать сказанное - т.к., если мы хотим выпустить продукт надлежащего качества, то надо согласовать фичи, которые мы хотим выпускать и сроки. Чем-то надо пожертвовать.
Однако, раз уж момент на митинге прощёлкали, дабы не выводить команды на убой (т.е., бешеный овертайм), я бы предложила продумать, чем мы можем пожертвовать (фичи против времени), чтобы релизнуться в срок.
Можно написать клиенту о том, что релиз, всё же, лучше было бы перенести. (вспоминаем золотое правило, что, чем раньше мы донесём проблему до клиента, тем быстрее мы её решим).
У меня, просто, на нескольких проектах, как у тест лида, было право ветирования релиза.
Или, если решим выпускать релиз, после минимального прогона тестов, написать known issues, которые должны войти в release notes, с их workaround'ом и обещаниями пофиксить в ближайшем патче (это в случае, если выход продукта критичен по времени.
Из случившейся ситуации всем нужно вынести урок, устроив "разбор полётов" с упором на то, что было сделано не так, и как этого избежать в будущем (без поиска козлов отпущения и принятия обиды слишком близко к сердцу - это, пожалуй, самое главное!)
lessons learned - PM взять за правило накануне демо просматривать тикеты, которые будут демиться, на предмет количества прилинкованных к ним багов, находящихся в статусе re(open), дабы иметь некоторое представление о картине происходящего и об эстимейтах, выдаваемых TL.
ReplyDelete