6911
правок
Изменения
м
Нет описания правки
{{red|Disclaimer: Заметки - с голоса, могут быть неточности и неверные интерпретации}}
[https://www.facebook.com/mtsepkov/posts/pfbid0vDmYXnoPPi6Zq1gqsuf79hQv3XYYh5GS8GjiPcbMJ4b15D55wzgoPNspwasRrvByl Пост на FB в моей ленте] [https://www.facebook.com/groups/1783048761947381/pending_posts/3251452578440318/ Пост в группе Enterprise Agile] [https://www.facebook.com/groups/agilerussia/posts/8416675795073246/ Пост в группе AgileRussia]
=Евгения Меньшикова из ВТБ. Журавль в руке: опыт трансформации процессов производства ПО=
Я тут замечу, что поверхностное рассмотрение - проблема самого формата дискуссии: он вскрывает то, что достаточно очевидно, а не в глубине. Но, с другой стороны, это для экспертов очевидные вещи, для участников может быть интересно. А еще этот формат показывает экспертам, что происходит в общественном сознании, а не на уровне глубокого погружения и это полезно.
= Фарит Хуснояров из VK. Когда все сроки вышли, а результат нужен завтра =
Доклад посмотрел в записи, включил в отчет позднее
История про перестройку в этом году команды, которая делает vk messenger. Проблема в том, что он сильно отстал от других платформ. За прошлый год ни одна из фич не была доведена до релиза. При том, что команда из квалифицированных профи с хорошей мотивацией, люди любят vk и искренне хотят нанести пользу пользователям. Но не получается. И проблема - в организации работы. Кейс, на мой взгляд - характерный для многих инженерных команд, чем и интересен.
На входе команда 40 человек была организована по платформам: web, андроид, iOS, бэк - это часто бывает. Каждая - со своей организацией процесса внутри, ведь "профи лучше знают как организоваться". Коммуникации - слабые. А чтобы поставить фичу, надо чтобы она появилась на всех платформах. Так фичи и не доходили до пользователей.
Еще одна проблема - конфронтация с продуктами, вернее, конструкция, в которой от продуктов требвали доказать команде, что фича будет полезна пользователям. Это - тяжелая вещь, ведь у каждого разработчика свое мнение о продукте. Поэтому сформировать роадмап - не получалось, на момент прихода Фарита в мае годового роадмапа еще не было, и был велик риск, что ситуация прошлого года повторится. Команду это тоже беспокоило, но формирование роадмапа - не ускоряло из-за принципа консенсуса.
Решение по роадмапу - изменение принципов. Приняли решение, что лучше плохой роадмап, чем никакого. Признали ответственность продуктов по оценке фич - он не должен убеждать команду, что фича будет полезна. У команды есть право вето, если она видит, что фича нанесет вред пользователям, они отвернуться. А если этого нет - фича принимается. Да, продукт может ошибиться, и ретроспективно видно, что ошибки были. Но альтернативный путь через тщательное исследование требовал времени, им пытались идти - и роадмап вообще не получался, требовались бесконечные обсуждения и исследования. Ситуацию с планированием облегчило то, что по многим фичам был задел, их прорабатывали и оценивали, просто они не были включены в бэклог. Новый принцип позволил довольно быстро это сделать.
Организационно это было сделано через процедуру квартального планирования, PI planing из SAFe. Фарит раньше работал в РТ Лабс, которая делает госуслуги, там это начали активно применять, чтобы разгрести завал работы, спровоцированный ковидом. Главное что дает процедура - прозрачность планирования, это важно и для руководства и для заказчика, она дает представление что будет сделано и в какие сроки. На конференции был доклад РТ Лабс, где это рассказывали, отзыв у меня в конспекте есть. В целом команда против планирования не возражала, вопросы были в технической осуществимости.
А дальше нужна фокусировка на том, чтобы фичи были сделаны целиком, на всех платформах. Решение тут известное - фичи-тимы или мультиплатформенные команды. Фарит эти две конструкции различает, хотя я не очень понял разницу. У них на первую итерацию было сделано две мультиплатформенных команды, в каждую взяли по 2 разработчика из каждой платформы. При этом платформенные команды - остались, они дорабатывают механизмы ядра, если это нужно для фич, через них проходят новые сотрудники при онбординге. Отмечу, что в целом конструкция сложная, но известная и понятная. О ней, например, [[Блог:Максима Цепкова/2018-02-11: TeamLead Conf - впечатляющий старт#Евгений Россинский из ivi| рассказывал Евгений Россинский из ivi на Teamlead-2018]].
В первую итерацию каждая команда взяла по 1 фиче. Эксперимент признан удачным, сейчас вторая итерация, команд уже 4, они взяли 9 фич. Естественно, был вопрос про организацию работы такой команды - потому что люди пришли из разных команд, в каждой из которой была своя организация. Решили иcпользовать Scrum. Основное возражение - что это долго и требует обучения, но тут подключился ScrumTrek, все сделали быстро.
Еще одна проблема - мощность команды разработки. Когда роадмап сделали, то стало понятно, что нынешней мощностью телеграм нагонят к 2030 году, не раньше. Значит надо что-то делать и быстро. Но культура требовала отбора настоящих профессионалов, были тяжелые собеседования, и больше одного сотрудника в месяц - не приходило. Но и изменить культуру быстро не получалось, люди не были готовы работать с теми, кого не считают "настоящим профи". И тут был workaround - через аутсорсинг. Компании-аутсорсеры предложили лидов, которые прошли собеседование. И те уже под себя набирали команды, а взаимодействие все шло через квалифицированных людей. Таким образом получилось в короткое время добавить 5 команд, 20 человек. Которым отдали все мелочи и исправление багов. Взаимодействие тоже возложено на команды платформ.
В заключении отмечу, что примененные практики для решения проблем в целом известны. Они - не простые, они требуют фокусировки на целях и воли. И основное сообщение доклада - в том, что в этом случае это можно сделать, при чем быстро: подготовительный этап занял всего 2 недели, параллельно делали роадмап и реорганизацию. А еще - что в такие сжатые сроки это можно сделать без разрушения команды, с учетом ее имеющейся культуры. Хотя, наверное, не всякой культуры, здесь сильно помогло то, что команда в целом была мотивирована на развитие продукта, поставку пользователям востребованных и ожидаемых ими фич. Но это не значит, что ради этого люди были бы готовы на любые изменения, культуру учитывали, пример с workaround для масштабирования - лишь один. На этом - все.
{{wl-publish: 2022-11-23 18:33:33 +0300 | MaksTsepkov }}