Разбор кейса 'CYA наоборот'

Спасибо за решения, камрады,

для меня было очень интересно их читать и анализировать.

Предлагаю вашему вниманию разбор кейса ‘CYA наоборот’, в котором я попробую из всех предложенных решений выделить сухой остаток

Почему же так могло получиться

ТимЛид

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

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

3. Девелоперское прошлое наложило нетленный отпечаток 'думай только за девелопмент' и не дает возможности думать обо всей команде. Часто встречающаяся ситуация, когда ТимЛиды назначаются (по другому и не скажешь) на роль Скрам мастера, а прошивка на понимание этой роли не ставится. Существует так же ситуация, когда и роль ТимЛида навязали, а не очень то и хотелось. Данная ситуация тоже лечится – говорить надо с человеком, узнать хочет ли он быть ТимЛидом и/или СкрамМастером, если да, то попробовать отправить его на какие-то тренинги, семинары, конференции, которые раскрывают тему 'а как же им быть' ну и, в общем, воспитывать его как Лида и/или СкрамМастера. В ситуации, когда это лидство ему и даром не нужно, отпустить и пусть лучше будет хороший программист, чем плохой менеджер самого среднего звена.

Тестинг Тим или почему не ‘зарепортили баг’

1. Стресс. Если команда перед релизом находится в состоянии стресса, причем и ТимЛид и ТестТим, то это в первую очередь флаг для PM-а, говорящий о том, что что-то идет не так, и надо выяснить, что же с нашим процессом, и не превратился ли SCRUM в SCRAP. Решается по средствам эффективных коммуникаций и мониторинга достижения поинтов, которые были подняты на ретроспективах, как improvement points; так же в достаточном/разумном контроле соблюдения процессных моментов, и, возможно, аудита процесса на предмет выбрасывания из него мусора или добавления недостающих элементов.

2. Не желание подствлять ТимЛида перед заказчиком очень хорошее начинание, но всегда есть но: замалчиванием в момент принятия решения - можно одного не подставить, но, при этом, косвенно подставить других, как правильно заметил один из респондентов: подставить себя и PM-а. Так же очень хорошая и, более того, правильная мысль – мягко поправить человека по средствам вопросов типа: ‘Насколько я понимаю, это время только на разработку…’, ‘А не забыли ли вы про нас, с нашей стороны это займет …’ и т.д.

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

3. "А что я могу сделать?" или забили

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

• устали стучаться в закрытую дверь (как указанно ранее);
• долговременное неполучение ответов, а только отговорки;
• постоянное несоблюдение критериев приемки/выпуска, решение о выпуске принимается, не смотря на рекомендации ТестТима

Все эти ситуации говорят об одном – Скрам превратился в Скрамно.

Как выйти из подобной ситуации

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

Уменьшить скоуп но выйти вовремя

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

Увеличить время но сохранить скоуп

Опять же, для этого нужна определенная лояльность заказчика и достаточное обоснование причин задержки, плюс ко всему - это должны быть 'важные и не срочные’ задачи. Работает, можно применять, но вышеописанные факторы должны быть соблюдены.

Овертайм

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

Выделение большего количества ресурсов

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

Пожертвовать качеством в пользу времени

Вариант приемлемый в случае, когда мы не релизим фичи, которые не затрагивает основной функционал системы. Они могут быть: либо не UI-ными (разного рода логирования, сборы статистики); либо предназначаться для работы роботов (Гугл-бот, Яху-бот); и, в общем, быть далеко от main-path’ов по которым ходит пользователь. При применении такого подхода обязательно запланировать патч/хот-фикс как можно быстрее после релиза, а, в некоторых ситуациях, ставя само приложение на костыли, чтоб хоть как-то сколько-то проработало, в параллели заниматься разработкой хорошего и достойного решения. И, как отписал один из респондентов, применить – один релиз для витрины, а еще один, чтоб заработало.

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

Как предупредить появление такой ситуации в будущем

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

Ретроспективы и lesson learned

Тут все тихо, ясно и понятно – выносим на ретру, на который выписываем improvements points, назначаем ответственных за мониторинг выполнения (в данном случае PM) и потом отслеживаем как ситуация разрулилась. Решение классическое и будет работать. НО если взять в расчет возможные причины возникновения, которые были рассмотрены ранее, то, до исполнения этой активности в рамках ретроспективы, хорошо бы бегло просмотреть 2 следующих метода.

Личные разговоры

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

Аудит процесса

Процесс разработки, так как он есть и все думают, что именно по нему мы и работает, может в реальности быть не насколько применен и не на столько работать, как на бумаге. Ситуация, когда после демо РМ узнает от ТестТима, а не от SCRUM мастера, что у нас есть проблемы и вы не вкладываемся в сроки, является флагом того, что с коммуникациями что-то не так. Когда что-то не так нужно, сначала выяснить что и постараться решить по средствам стандартных методов (ретроспектив и improvement points).

Суровая реальность

Для решения этой задачи был принят комбинированный подход – reduce quality + небольшая отсрочка релиза + небольшие овертаймы со стороны девелопмент тима. Основная проблема - это не недостаток времени на тестирование, а неготовое решение для разработки. По сему, пришлось поставить на костыли, чтоб потом залатать хот-фиксом.

Во избежание проявления такой ситуации в будущем, применен вариант с ретроспективой и lesson learned. В случае повторного появления, будут применяться более жесткие меры.

Надеюсь было интересно. Жду коментов.

Спишемся