Как стать автором
Обновить

Рецепт дня: готовим сообщество профессионалов, не выходя из своего отдела

Время на прочтение10 мин
Количество просмотров2.5K
Всего голосов 16: ↑16 и ↓0+16
Комментарии9

Комментарии 9

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

Про обучение. Судя по тексту, обмен опытом у вас происходит в основном через митапы (не суть важно, удаленные или очные). Но это же огромное дублирование усилий — невозможно попасть на прошедший митап второй раз, невозможно попасть на митап, на котором меня не было. Можно проводить запись митапов, но видеоинформацию очень дорого анализировать, искать по ней, копипастить и т.п. Почему вы не систематизируете информацию на внутренней вики или в ином текстовом виде? Были какие-то организационные проблемы, почему так не сделано?

По поводу организации производства. Да, у нас есть core и infra-тимы, которые решают сугубо технические задачи. Но их от общей массы всех команд примерно 5%. Остальные команды — это feature teams. Мы работаем в эджайл-фреймворке LeSS. Именно по этой причине и пришлось создавать сообщество, т.к. каждый отдельный QA инкапсулирован в свою команду. Разные команды работают в разных доменах требований, а процессы нужно было настроить одинаковые для всех.
По поводу обучения. Действительно, митапы — это затратно. Я предложила их проводить больше с целью понять истинные потребности сообщества. Не всегда через опросники можно получить честную картину интересов людей, а на митапе можно увидеть тренд популярных вопросов. Плюс, на тот момент мне хотелось всевозможными способами добавить живого общения. В действительности же у нас есть база знаний, мы стараемся ее поддерживать и реорганизовывать по мере необходимости. Но и митапы всё еще проводим, чтобы голосом что-то обсудить. Как правило, они бывают не чаще раза в месяц и самые полезные мы тоже сохраняем в базу.

Сколько денег заработали/сэкономили/потратили на это?

Сколько заработали в рублях, не скажу, но регресс сократили с 4 дней до 1. ТТМ короче стал, стали релизить раз в 2 недели, а не как получится. В общем, посчитать экономию нетрудно, если взять количество инженеров, умножить на среднюю з/п по рынку и на 3 высвободившихся дня их работы.
Также сэкономили на этом через год, когда надо было еще 2 раза отмасштабироваться, прицепив к себе соседнюю команду с ненастроенными процессами и выделив в продукте еще один домен. Это вообще нам ничего не стоило. Ни дня простоя производства не было. В этом году нужно снова отмасштабироваться: сильно надеюсь, что и в этот раз решим все процессные проблемы через сообщество.
А что касается затрат, тут скажу так. Это очень долгосрочная инвестиция. Та ситуация, которую описывает статья, была уже в далеком 2019 году. Тогда на запуск этого комьюнити реально пришлось потратиться: на физический сбор всей команды и несколько командировок. Получается, что инвестировали весь 2019 год. Командировки, конечно, очень дорогое удовольствие. Однако они показали пользу только в фазе запуска. Экспертиза быстро расшарилась, и в них пропала острая необходимость, а потом и пандемия подоспела. Окупилась эта затея примерно в середине 2020. Плюс, за эти 2 года в другие команды перевелось порядка 8 человек, потому что такое количество людей было уже не нужно. Профит очевидный. Вопрос больше в том, насколько вы готовы потратиться на запуске.

Итого. Сухие факты, чистые потери.
  • Вы не стали зарабатывать больше денег. Да вы сократили ТТМ, но это не принесло вам увеличение дохода.
  • Вы не сократили накладные расходы. Вы делаете регрес быстрее, но вы уменьшили команду. Да вы высвободили 3 дня работы, но не превратили это в деньги.


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

Я пока не вижу окупаемости…

Вам в плюс, вы смогли наладить крос взаимодействие, но это можно сделать все дешевле.

Возможно, вы правы.
Мне сложно обозначить какие-либо показатели в деньгах по той причине, что доступа к этой информации у меня нет. Безусловно, в компании есть менеджмент, который умеет получать и анализировать такие цифры. И когда после приведения длительности ТТМ к желаемому виду он ко мне с запросами на изменение больше не пришел, я сделала выводы о том, что, по крайней мере, проблем релизный цикл больше не приносит. Раньше приносил, т.к. запросы на изменение процесса были регулярно.
Сконвертировался ли этот ТТМ в чистые деньги, можно сказать, только имея на руках все цифры продукта. Это ведь зависит от многих факторов. В частности, от успешности самих фич, запускаемых бизнесом.
Мы не совсем уменьшили команду. Эти же люди плавно перетекли в тестирование нашего же бэкенда. Тишейпились-тишейптлись и в итоге остались там, потому что там сформировалась большая потребность. Не пришлось нанимать и тратиться на онбординг. За счет того, что эти же люди высвободили время от регресса, они как минимум, сделали больший импакт в разработку автотестов.

а вы не хотите поделиться рецептом «как сделать всё дешевле» на следующей конференции?
Sergey-Titkov, а вы не хотите присоединиться и продемонстрировать свой подход? И так ли важна окупаемость на каждом этапе? Ведь инвестиции в развитие вовсе не должны мгновенно доводить до окупаемости? И уж тем более в явном виде
Зарегистрируйтесь на Хабре, чтобы оставить комментарий