Изменения и как их преподнести команде

[undex73]

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

[R_Nas]

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

[EvilMan]

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

[g1otov]

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

[R_Nas]

Этот артефакт у нас в переработке:

1) Мы думаем над его оптимизацией. Сократить до обязательных пунктов.

2) Провести повторный диалог с командой разработки

3) Не забыть мониторинг на этот раз :)