Comments 15
Хочу добавить, что релиз менеджер как роль (не как выделенный сотрудник) нужна и в ситуации не динамично развивающихся проектов.
Например, если у вас тяжелый в разработке и тестировании софт, мажорный релиз происходит в лучшем случае раз в год. Как следствие, незадолго до релиза начинаются серьезные проблемы с коммуникациями и сбором информации.
- А готов ли release notes и точно ли в него все попало?
- Документалисты ждут список изменений, поэтому релиз нотса нет.
- А кто у нас выкладывает все на публичные сервера, петя же уволился.
- Опять забыли маркетинг предупредить заранее!
- и т.д.
Т.е. времени прошло много, что-то забылось, что-то изменилось. Если с первым справляются чек-листы, то со вторым приходится справляться и без того взмыленному продакту (если он есть). И справляется он в режиме пожаротушения, а не системной работы.
Как правило, для таких тяжелых релизов и сам цикл выпуска в свет продукта занимает приличное время и состоит из множества шагов. Поэтому без менеджера релизов никуда, он будет править чек листы, улучшать процессы, проводить релизные ретроспективы, давать задания девопсам на автоматизацию или профилактику косяков, вовремя снабжать информацией документалистов и маркетологов. В активе - снижение времени на релиз (экономический эффект), снижение стресса, повышение качества.
Из личного опыта, релиз менеджмент реально нужен в больших интеграционных проекта, вроде Интернет банкинга. Прикол в том, что "работающий релиз" - это микс из согласованных поставок разных команд (часто из разных организаций) + куча настроек в разных, иногда довольно таки отдаленных системах + корректно собранные поставки, в которых ничего не пролюбили.
Без понимания связей (а они есть и их никак не обойти), логики взаимодействия, необходмых орг. мероприятий что-то будет не сделано и все пойдет "прахом".
На одном из проектов (была очень сложная политическая обстановка), я как раз занимался вопросом и меня попросил "главный" менеджер пояснить, а что я такого делаю (не вообще, и именно в этой части). Попытка пояснить не увенчалась успехом (ПМ был очень высокого полета), пожтому мне сказали - не надо, дальше я сам. После чего две следующие установки заканчивали глубоко за полночь в пятницу, когда кор тима (та, что была трезвая) мучительно пыталась найти вживую сочетание всего, чтобы система просто ожила :)
----------------------
Но у вас я не совсем понял
Мы просили тимлидов заполнять чек-листы с описанием изменений, связях между сервисами, тогглами и прочее
По идее, вы уже в начале знаете, как паззлик будет собран, иначе смысл ближе к концу опрашивать народ, чтобы узнать что ... да фиг его знает. Ну либо тут неясно написано. Зачем чек-лист - понятно. Но зачем туда тим лидам вписывать описание - не очень понятно. Оно уже должно быть задолго до того как
Нам с коллегой надо было решить проблему установки на тестовые стенды. Ответственные за сервисы вручную проводили отрезку релиз-кандидата и установку, что занимало около 5-6 часов
Этого я вообще не понял, ну да ладно
У меня такое ощущение, что у вас планирование релиза начинается условно где-то в середине, а не в начале. Хотя, как по мне, вы изначально планируете, что будет выходить на прод, и под это уже согласовыыаются контракты/спеки, планируются оргю. работы и постепенно (еслит надо) наполняются инструкции
С большими интеграционными проектами действительно нужно очень много внимания уделять при релизах. Есть опыт, понимаю ту боль, которую описали ?.
В релиз попадают законченные задачи к моменту Х, чек -лист с описанием нужен был так как команд очень много и сразу несколько команд могут дорабатывать один и тот же сервис. На тот момент у нас не было автоматизации, чтобы получить информацию о взаимосвязях и прочем при установки и таким образом, решали этот вопрос.
Собирали воедино кусочки пазлов от разных команд
Поэтому получается, что если планировать наперед (связи, зависимости, моки), то получается не постфактум сбор и "отрезание", а заранее понятный процесс с выписанными обязательствами участников
И понятно, что именно надо контролировать
А вы, как я понял, начинаете собирать паззл в процессе. В этом принципиальная разница
вручную проводили отрезку релиз-кандидата
Чёрт с ними, с "тогглами", но что вы там режете всё время? Что такое "отрезка", "автоотрезка", кто с чем что делает?
Интересная статья, спасибо! Открыл для себя еще одно направление в IT ) Какими базовыми и специальными навыками должен обладать современный релиз-менеджер?
Большое спасибо , рада, что статья понравилась. Для релиз -менеджера важна коммуникабельность и стрессоустойчивость ( шучу).
На самом деле, я бы ответила, что нужно всего понемножку. Базовые знания гита, основы тестирования, тайм менеджмент , какие бывают модели разработки, чтобы на основе их продумывать процессы и тд .
Почему в вашей схеме нигде не указаны системные аналитики, у вас их нет?
Релиз-менеджер — почему он вам нужен