Симпозиум тимлидов в офисе Первый БИТ и как наладить процесс технологического ревью
Tags: отзыв, управление разработкой
На днях посетил, собранный по горячим следам "Teamlead Meetup" от Binary District, симпозиум тимлидов.
Мест было немного, плюс добралось только половина человек, так что удалось пообщаться вольно и душевно.
В ответ на один из моих вопросов, рассказали про "Технологический комитет" (или технический...), как
средство и процесс контроля используемых технологий, фреймворков и прочего в разработке.
Начну с того, что мы имеем у себя в компании в данный момент.
Мы сейчас работаем над отладкой "архитектурного ревью". Роадмап из должостной:
- Подготовка списка вариантов решения
- Выбор и утверждение предварительного решения, с СТО или СЕО
- Прописывание в wika максимально подробно как реализовать, утвердить с СТО
- Нагрузочное тестирование предварительного решения, утвердить с СТО
- Окончательно решение и продакшн, утвердить с СТО
Получается, что мы выделяем на планирование архитектуры (нового проекта, либо значительную модификацию существующих)
определенное время, оформляем это в виде обязательного процесса и делегируем роль архитектора разработчику который
будет по ней потом вести разработку. При этом мы вводим контроль архитектурных решений с целью помочь, провалидировать
и проконтроллировать стек технологий и решений.
Плюс, делегирование роли архитектора (в противовес - закрепить эту роль за CTO) позволит расставить такие роли:
- разработчик - исполнитель, ответственный за решение, его задача сделать архитектуру, наша - не мешать ему в этом
- менеджер (продуктолог/тимлид/скрам-мастер) - контролирует сроки решения (опрос на скраме), может поменять задачу разработчику и это не повлияет на других людей (CTO, архитекторов, итд)
- CTO - помощь по запросу, участие в совещаниях по утверждению архитектуры
Принципы, которых мы придерживаемся при разработке и ревью архитектуры:
- Skill -1. Просто крутому разработчику сделать сложную систему, сложно потом нанять команду таких же крутых разработчиков для ее поддержки. Подробнее правило 3.1 в аксиомах
- Упор на простые и широко популярные технологии, даже если они хуже (но решают задачу и есть возможность развития). Должна окупиться цена поддержки этой технологии
- Архитектура рассписывается до схемы таблиц БД, структуры каталогов и назначения файлов итд. Проще в реализации, проще в контроле. Сложности в фиксации этих вещей могут указывать на недостаточную проработку решения
- При этом, в дальнейшем архитектура может меняться и скорее всего изменится
- При создании MVP (и возможно даже после релиза) полная реализация архитектуры не важна, но важно ее не нарушать
- Ориентир не код и технологии, а продукт и польза клиенту
Итого
Плюсы:
- Ввели проработку архитектуры как обязательный процесс, т.к. считаем что трата времени на архитектуру окупается
Минусы:
- Смешали контроль технологий и разработку архитектуры
- Фиксация принятия решения на 1-2 людях, из чего следует опасность необъективности и отсталости
- Возможно, требуется доп. мотивация разработчиков для лоббирования новых технологий
Планы:
- Прокачка и делегирование контроля с CTO на технолога разработки
- Отладка схемы, поиск узких мест
А что за технологический коммитет?
На симпозиуме Виталий Шароватов поведал (а я половину забыл, своего додумал, так что вы тексту дальше не верьте, а лучше спросите его напрямую :) ),
что можно составить группу людей из опытных разработчиков, которые будут отвечать за апрув за применение тех или иных технологий.
Этот кейс мне понравился, как хороший способ убрать узкое место в виде CTO, да еще и поднять тех. культуру в компании.
Плюс, полезная вещь, как для работы комитета, так и в 1на1 с разработчиком, который хочет все переписать на новый фреймворк -
это формализованный чеклист, по которому нужно построить "бизнес план" применения технологии, например:
- Оценка зрелости технологии: сколько ей лет, оценка стабильности, сколько еще проект будет жить и развиваться, куда идти за помощью
- Оценка затрат на переобучения персонала: можно ли научить технологии нужное число разработчиков, сколько займет времени, насколько увеличится время "онбординга" в команду, оценка этих знаний у разработчиков на рынке труда
- Оценка стоимости внедрения: сколько займет времени переписать весь проект на новую технологию, сколько стоит ее поддержка
И немного "для себя":
- Повышение лояльности разработчиков
- HR бренд
- итд
Причем, этот чеклист позволит направить энергию амбициозного разработчика в нужное русло, поможет ему научиться думать не только о технологиях, но и о бизнесе.
Планы:
- Выделить апрув технологий из разработки архитектуры, либо сделать это явной его частью
- После утверждения чеклистов протестировать ревью технологии по нему в группе разработчиков, будет ли им интересно
Ссылки: