Назад

# Симпозиум тимлидов в офисе Первый БИТ и как наладить процесс технологического ревью 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>