2019-03-13 Lidconf And Tech Commision.md

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

Tags: отзыв, управление разработкой

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

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

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

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


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

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

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

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

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

Итого

Плюсы:

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

Минусы:

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

Планы:

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

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

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

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

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

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

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

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

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

Планы:

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

Ссылки:

Обсуждение

adminadmin, 18.04.2019 10:09

полезно

Ваш комментарий. Вики-синтаксис разрешён: