Привет!

Продолжаем публиковать текстовые версии докладов с QIWI Server Party 6.0, в этом посте — Александр Прокопьев и Developer Experience. Про инструменты, их качество и развитие инструментов разработчиков в QIWI.

Если предпочитаете формат видео — держите.

А вот и текст.

У меня есть любимая притча. Мужик пилит дерево. Другой к нему подходит и спрашивает: 

— Как дела? Давно пилишь?
— Три дня уже.
— Что-то долго. Может, тебе стоит пилу заточить?
— Не, некогда точить, нужно дерево пилить. 

И в IT такое бывает часто. Работаешь над какой-нибудь рутинной задачей и думаешь, что вот наверняка есть какой-то инструмент, который может автоматизировать эту работу. Но сроки горят, и мы говорим себе: «Не в этот раз». И оставляем на потом. А когда работа завершается, мы быстро забываем про эту боль. 

Я, например, до сих пор использую старый SQL Developer для работы с базой данных, хотя все коллеги давно перешли на DataGrip. И они периодически подталкивают меня, а мне все лень. Кто-то пользуется Git-ом и никак не соберется с силами, чтобы изучить его поглубже, добавить в свой багаж более глубокие команды. А кто-то использует IDE и не изучает горячие клавиши или плагины, которые могут помочь в работе.

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

Именно для того, чтобы полностью исключить или существенно минимизировать вероятность возникновения нежелательных ситуаций, служит программный продукт SOLIDWORKS PDM.

Эпопея с автодокументацией началась у нас неспроста: 300 разработчиков, 500 репозиториев и 400 сервисов — все живет на 600 хостах и использует 600 баз данных. Изменения происходят настолько часто, что ручной поиск данных в наших масштабах — та еще морока. При этом раньше никакого общего хранилища с актуальной информацией о владельцах проектов, о конфигурациях хостов и связанных с проектами сервисах не было. Расскажу, как мы вконец устали от квестов, перешли на сторону автодоки и почему выбрали в помощь Insight.

Меня зовут Юля, я руковожу командой SRE. Помимо стабильности сервисов, моя команда занимается поддержкой инструмента, который нам позволяет за этими сервисами следить. Это отдельное приложение, генерирующее документацию по всей нашей инфраструктуре.

В 2018 году, когда я только пришла в компанию в роли девопса, мне дали для погружения в процессы простую задачу: допилить скрипт локального разворачивания проектов, чтобы он корректно работал под macOS. То есть скрипт уже был, он успешно работал для Linux-окружения. Его нужно было просто адаптировать, подправить пару регулярок, настроить сеть, дописать инструкцию — совсем не сложно. Я довольно быстро сделала правку в самом инструменте, и казалось, что нет никаких проблем. Но дальше 15-минутная на первый взгляд задача растянулась на 3 месяца.

В сегодняшнем выпуске по мотивам конференции ЮMoneyDay три доклада от менеджеров проектов.

В первом разбираем, зачем мы запустили игру ЮVillage. С какими вызовами столкнулись при разработке, и за счёт чего получилось круто. Во втором — как за два года мы научились по-новому ставить задачи, вести дела на удалёнке, адаптировать новичков и вообще не забывать, что мы есть друг у друга. Из третьего доклада узнаете, как планировать при большом количестве команд, продуктов, проектов.

Скорее заглядывайте под кат.

Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, DevOps технический менеджер. Сейчас работаю в Quantori.

Я не буду описывать самоорганизующиеся команды, а расскажу про алгоритм их создания. Это мой личный опыт — я так работаю с командами (их было 30+). Он перекликается с Management 3.0, моделью Херши-Бланшар, LeSS, Sсrum и даже SAFe, а также со многими другими софтовыми областями. И в нем есть конкретика на уровне действий.

Для ленивых: я исследую окружение, проектирую дизайн культуры, объясняю правила и делегирую задачи команде. Я не поддерживаю внедрение самоорганизации через фреймворк. Видео моего выступления об этом на конференции TeamLead Conf 2021 можно посмотреть здесь.

С 2020 года мы выстраиваем платформенный подход к разработке продуктов. Мы сформировали набор технологий, которые должны распространиться на все наши команды, чтобы в масштабе всей компании мы могли централизованно управлять качеством разработки. Хотим поделиться впечатлениями от того, как эти технологии проходят испытание практикой в наших новых проектах.

Для начала коротко о том, какие технологии легли в основу платформу. Про многие из них мы подробно рассказывали в отдельных статьях.