# Симпозиум тимлидов в офисе Первый БИТ и как наладить процесс технологического ревью
Tags: отзыв, управление разработкой

На днях посетил, собранный по горячим следам "Teamlead Meetup" от Binary District, симпозиум тимлидов.
Мест было немного, плюс добралось только половина человек, так что удалось пообщаться вольно и душевно.
В ответ на один из моих вопросов, рассказали про "Технологический комитет" (или технический...), как
средство и процесс контроля используемых технологий, фреймворков и прочего в разработке.

### Начну с того, что мы имеем у себя в компании в данный момент.

Мы сейчас работаем над отладкой "архитектурного ревью". Роадмап из должостной:

 - Подготовка списка вариантов решения
 - Выбор и утверждение предварительного решения, с СТО или СЕО
 - Прописывание в wika максимально подробно как реализовать, утвердить с СТО
 - Нагрузочное тестирование предварительного решения, утвердить с СТО
 - Окончательно решение и продакшн, утвердить с СТО


Получается, что мы выделяем на планирование архитектуры (нового проекта, либо значительную модификацию существующих)
определенное время, оформляем это в виде обязательного процесса и делегируем роль архитектора разработчику который
будет по ней потом вести разработку. При этом мы вводим контроль архитектурных решений с целью помочь, провалидировать
и проконтроллировать стек технологий и решений.

Плюс, делегирование роли архитектора (в противовес - закрепить эту роль за CTO) позволит расставить такие роли:

 - разработчик - исполнитель, ответственный за решение, его задача сделать архитектуру, наша - не мешать ему в этом
 - менеджер (продуктолог/тимлид/скрам-мастер) - контролирует сроки решения (опрос на скраме), может поменять задачу разработчику и это не повлияет на других людей (CTO, архитекторов, итд)
 - CTO - помощь по запросу, участие в совещаниях по утверждению архитектуры

Принципы, которых мы придерживаемся при разработке и ревью архитектуры:

 - Skill -1. Просто крутому разработчику сделать сложную систему, сложно потом нанять команду таких же крутых разработчиков для ее поддержки. Подробнее [правило 3.1 в аксиомах](http://opencarbon.ru/open_carbon_7:аксиомы)
 - Упор на простые и широко популярные технологии, даже если они хуже (но решают задачу и есть возможность развития). Должна окупиться цена поддержки этой технологии
 - Архитектура рассписывается до схемы таблиц БД, структуры каталогов и назначения файлов итд. Проще в реализации, проще в контроле. Сложности в фиксации этих вещей могут указывать на недостаточную проработку решения
 - При этом, в дальнейшем архитектура может меняться и скорее всего изменится
 - При создании MVP (и возможно даже после релиза) полная реализация архитектуры не важна, но важно ее не нарушать
 - Ориентир не код и технологии, а продукт и польза клиенту


#### Итого

Плюсы:

 - Ввели проработку архитектуры как обязательный процесс, т.к. считаем что трата времени на архитектуру окупается

Минусы:

 - Смешали контроль технологий и разработку архитектуры
 - Фиксация принятия решения на 1-2 людях, из чего следует опасность необъективности и отсталости
 - Возможно, требуется доп. мотивация разработчиков для лоббирования новых технологий

Планы:

 - Прокачка и делегирование контроля с CTO на технолога разработки
 - Отладка схемы, поиск узких мест


### А что за технологический коммитет?

На симпозиуме Виталий Шароватов поведал (а я половину забыл, своего додумал, так что вы тексту дальше не верьте, а лучше спросите его напрямую :) ),
что можно составить группу людей из опытных разработчиков, которые будут отвечать за апрув за применение тех или иных технологий.

Этот кейс мне понравился, как хороший способ убрать узкое место в виде CTO, да еще и поднять тех. культуру в компании.

Плюс, полезная вещь, как для работы комитета, так и в 1на1 с разработчиком, который хочет все переписать на новый фреймворк -
это формализованный чеклист, по которому нужно построить "бизнес план" применения технологии, например:

 - Оценка зрелости технологии: сколько ей лет, оценка стабильности, сколько еще проект будет жить и развиваться, куда идти за помощью
 - Оценка затрат на переобучения персонала: можно ли научить технологии нужное число разработчиков, сколько займет времени, насколько увеличится время "онбординга" в команду, оценка этих знаний у разработчиков на рынке труда
 - Оценка стоимости внедрения: сколько займет времени переписать весь проект на новую технологию, сколько стоит ее поддержка

И немного "для себя":

 - Повышение лояльности разработчиков
 - HR бренд
 - итд

Причем, этот чеклист позволит направить энергию амбициозного разработчика в нужное русло, поможет ему научиться думать не только о технологиях, но и о бизнесе.



Планы:

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

### Ссылки:
 - Форум тимлидов <https://teamlead.discussion.community/>
 - Плейлист с митапа тимлидов <https://www.youtube.com/watch?v=T4T2CMwyGVg&list=PLZzb3aEhs6IjmaTG0YtH-yUCqblATsjet>