Мышление письмом по попыткам задействовать лидерство::метод в сторону коллеги::разработчика::роль.
Ситуация характерная для меня “сложно пройти мимо косяка”. Косяк дверной, проём между комнатами разработчиков и девопсов плохо работает. Постоянно кто-то головой ударяется - связанные работы плохо проходят.
У нас бекендерская задача проходит свои состояния “создана”, “взята в работу”. Бывает, что внутри работы над задачей возникает “запрос на работы от команды девопс”::потребность. Что в этот момент надо сделать? Разработчик::роль идёт в трекер задач и на доске девопсов создаёт свою задачу-запрос. Её надо правильно “определить”, привязать к нашему проекту, а не к чужому. Описать нормально свою потребность. И ещё связать эту новую задачу со своей задачей, для которой она нужна. Там связь часто “моя задача” blocked_by “задача на опсов”. Если действительно ничего делать дальше не можешь. Моя задача становится “hold”. Дальше начинается туман войны. Девопсы это отдельная сервисная команда. Она одна обслуживает все продуктовые команды. Т.е. там постоянно на голову сыпется новый поток входящих. Назначать ответственных на работы мы (разработчики) не можем. Точнее можем, но это как будто не рационально. Я же не вижу загрузки коллеги. Значит назначает на работы тимлид девопсов::распределительная шляпа::менеджер. Он выставил ответственного. Когда задача будет взята в работу мы не знаем. Можно как-то её протолкнуть? Можно поставить приоритет повыше. Но желательно при этом не скатываться в “все задачи важные и срочные”.
Яма тут. Я создавала свою задачу на девопсов, зацепилась взглядом за соседскую (но из нашей команды созданную). Иду смотреть, она закрыта. А к ней связанная задача бекендерская всё ещё в hold. Причём готова задача девопса была где-то неделю назад (переведена в состояние review). Как это для меня выглядит? Один (девопс) сделал свой кусок, передвинул статус и забыл про задачу (“дальше не моё дело”). Второй (разработчик) забыл после того, как создал задачу на опса и не следит за статусом его задачи. Почему он не следит? Думает, что ему опс в личку придёт “ваш заказ готов, забирать будете”? Опс не придёт, он не официант, он работник кухни. Отписала комментарий в задаче разработчика “уже не блокируется” пару дней назад. Ничего не поменялось. Вчера разработчик просит в нашем чате у лида себе очередную задачу. Я ему “кажется у тебя завалялась задачка, ждёт тебя”. Наверно это так себе “уговоры” встать в роль. Или хотя бы публично это не надо делать.
Дальше в личке выясняли “кто официант”. Я пояснила почему девопс плохо подходит. Мне подходяшками накинули: скрам-мастера, менеджеры, лид девопсов. Скрам-мастера плохо подходят, они следят за задачами продуктовой команды на доске. Если у тебя пачка задач в hold, каждый раз никто не будет спрашивать, а что с ними. “Менеджеры” это какая-то абстракция, магические сущности, все их знают, никто не видел. Лид опсов тоже не будет ходить к разрабам в другую команду и говорить “вот ваш заказ”. Вроде объяснила.
Оказалось, что у разработчика другие проблемы. Он следит за своими задачами, но когда пожар, не следит. Т.е. он просто упустил момент движения статусов связанной задачи. Претензия к кухне: свою задачу закрыли, никто не проверил, что она работает (сделано то, что просили). Я тут задаю вопрос: а кто это должен проверить? Тестировщик ставится только на задачи разработчиков, у опсов даже статуса такого нет (ready for test). Я понимаю, что статус приёмки у опсов это review (посмотри я сделал). Но тебе его тоже никто на тарелочке не приносит. Я сама слежу, в трекере есть колокольчик с уведомлениями об изменении задач, на которые ты подписан. И задача, которую ты создал на опсов туда точно попадёт. Дальше надо просто надеть на себя шапку тестировщика и пойти проверить. Если не работает, пойти на кухню вернуть плохо приготовленное блюдо. Пытаться накинуть лиду опсов, мол не закрывай задачи просто так, иди спрашивай “что изменилось в реальности” кажется сомнительной идеей. Надо чинить коммуникацию.
Сходила к лиду девопс. Оказывается кухня обслуживает от 15 проектов. В личку с оповещениями точно никто ходить не будет. Выяснилась интересная штука “перевод статуса порождает письмо автору задачи”. Не видела ни разу таких писем. Пообщались про настройку уведомлений в трекере задач.
У меня получается такой алгоритм:
- Разработчик создаёт задачу на девопс
- Прикрепляёт её к своему проекту
- Связывает её со своей задачей
- Проверяет, что он подписан на обновления по задаче (watcher)
- Проверяет свои настройки уведомлений в трекере задач
- Ждёт перевода статуса задачи в review (уведомление надо смотреть либо в колокольчике в трекере, либо в письмах в почте)
- Задача перешла в review, её нужно пойти и проверить разработчику
- Вернуть, если не ок. Если ок, закрыть.
Осталось всего ничего: рассказать команде о тяжёлой жизни сервисных команд (про сотни задач в неделю я не знала) и про алгоритм.
