HighLoad++ 2017 Зал «Сингапур», 8 ноября, 13:00 Тезисы: http://www.highload.ru/2017/abstracts/2926.html На примере важных задач организации команды разберем, как их можно решить, имея опыт разработчика, но не управленца. Перенесем опыт и знания из пространства разработки программного обеспечения в пространство управления командой и тем самым решим новую задачу проверенным способом. ...

1. Команда
как
высоконагруженная
система
Антон Потапов
Unit Manager
Ingram Micro Cloud

2. План доклада
1) Как управлять командой умея писать софт?
2) Базовые практики, которые не все используют
3) Общий подход

3. Team lead перегружен. Проблема
Только team lead может
1) Найти причину сложного бага
2) Исправить любой срочный баг
3) Сделать дизайн новой функциональности

4. Team lead перегружен. Решение
Load balancing как основа идеи
1) Процесс перераспределения задач
2) Члены команды как дополнительные мощности
«Exception man»
1) Отвечает на все запросы/прерывания ( тесты, баги, новые
фичи,консультации)
2) Обязан выяснить ответ и донести до вопрошающего
3) Full time работа с недельной сменой

5. Team lead перегружен. Результат
1) Ни одной жалобы от внешних людей
2) Спустя 2 месяца каждый знал, что нужно пользователям
3) Женя сделал дизайн рефакторинга, а до этого полгода не мог

6. Команда перегружена. Проблема
1) Большую часть времени занимает исправление багов
2) Регулярный срыв сроков с эскалациями
3) Костыли преобладают при разработке новых фич
4) Растет технический долг (рефакторинг, покрытие тестами)

7. Команда перегружена. Решение
API команды как основа идеи
1) Что команда принимает на вход?
2) Что и как команда выдает на выходе?
SDLC
1) Баг или улучшение (a.k.a. фича)?
2) Что такое блокерный баг?
3) Единый упорядоченный список улучшений

11. Единый список улучшений
1) Есть один упорядоченный список улучшений
2) В бэклоге все улучшения, которые нужны продукту
3) Мы сами добавляем задачи в бэклог
4) Если кто-то пытается пройти мимо API, нужно перенаправить на
путь истинный

12. Команда перегружена. Результат
UI framework
1) Мы стали тратить меньше 25% времени на баги
2) Научились делать все нужные фичи в релизе
B2B eCommerce
1) Нет эскалаций по багам.
2) CI, поддержка плагинов, запуск продуктов

13. Непрозрачный статус. Проблема
1) Регулярные вопросы «когда?», «на сколько готово?»
2) Подготовка занимает больше 30 минут
3) Соседние команды считают, что вы делаете что-то ненужное
4) Нет системы предупреждения «пожаров»

14. Непрозрачный статус. Решение
Health check monitoring, как основа идеи
1) Иметь в понятной форме важные параметры команды
2) Регулярно смотреть командой и показывать окружающим эти
параметры
Dashboard
1) Daily standup с оперативной информацией
2) Weekly/bi-weekly с тактической информацией
3) Monthly со стратегической информацией

15. Непрозрачный статус. Результат
1) «Постояшки», где всем видны текущие задачи
2) Планирование и закрытие итерации со списком ожидаемых
доставленных улучшений

16. Уникальные навыки. Проблема
1) Работа из отпуска или больничного
2) Больничный одного приводит к невозможности зарелизить
улучшения в нескольких компонентах
3) Определенные люди не могут уйти в отпуск одновременно
4) Больничный одного приводит к работе из отпуска другого

17. Уникальные навыки. Решение
High availability, как основа идеи
1) В каждой области должно быть более одного специалиста
2) Легкость создания специалиста в любой области
Способы
1) Намеренно распределять знания
2) Хорошая документация, покрытие тестами, т.д.

18. Уникальные навыки. Результат
Успешно применен
1) В июле и августе команда успешно закрыла итерации
2) Одна из компонент была закончена к релизу силами трех
разработчиков

19. Общий подход
1) Найти ситуацию в реальном мире, которую хочется улучшить
2) Выбрать аналогичную задачу из области разработки
3) Выбрать решение задачи из области разработки
4) Получить идею, как решить задачу в реальном мире
5) Улучшить ситуацию в реальном мире