Компании как и люди, в своем развитии проходят схожие этапы. Есть этап детства, когда закладываются базовые семейные ценности. В юности мы смотрим на модели ценностей, которые нас окружают, и примеряем их к себе. В зрелости мы уже готовы принимать решения и все они базируются на опыте и понимании как должны происходить трансформации. Тогда мы или костенеем и трансформаций практически нет, или делаем прорыв и выходим на абсолютно новый уровень жизни.
Для IT компаний архитектура — базис, на котором выстраиваются все продукты и подходы. Но, у архитектуры тоже должна быть основа. Интересно, что будет, если мы будем выстраивать её из ценностей? Не тех, которые плакатами развешаны на кухне, а тех, которые живут «в курилке», на которых сформировалась компания и коллектив.
Я — Катя Лысенко — более 15 лет работаю в IT в таких отраслях, как fintech, e-grocery, TIS. В моём опыте — крупные госкорпорации; стартапы, переживающие взрывной рост; компании, которые только вышли в самостоятельное плавание.
В этой статье предлагаю обсудить ценности, а конкретно их прикладную сторону: как они влияют на разработку и бизнес, и почему без общих ценностей в компании могут возникнуть проблемы с архитектурой.
Я поделюсь идеями из своего опыта и кейсами из работы в «Самокате». Расскажу, чем полезны ценности на разных стадиях жизни компании, как они перетекают в практики и как работать с ценностями без нудного морализаторства и «гуманитарного» шаманства.
Процессы и архитектура в стартапах
Мы пройдем путь развития компании и принципов построения архитектуры шаг за шагом. Посмотрим, как на этом пути нам помогают ценности.
Начнём с того, чем все мы когда-то были, а может ещё не раз будем — со стартапа.
Когда вы работаете в стартапе, то прежде всего играете роль выжившего. По статистике, только 6% из всего числа стартапов доходят до стадии стабильного развития и поиска новых направлений роста. Об этом факте команде приходится помнить каждый день.
Ежедневно на вас давит статистика, и под этим гнетом необходимо решать бизнес и технические задачи.
Всегда есть шанс, что стартап разовьётся во что-то большее. Какие задачи выставляет себе в этот момент бизнес? Нужно проверить спрос и узнать потребности клиента, промасштабировать идею, протестировать пилот на практике, упаковать решение для инвесторов.
Всё указанное выше отражается на разработке:
Необходимо обеспечить высокую скорость поставки изменений. Очень высокую: утром и в обед могут быть противоречащие друг другу задачи.
Процессы разработки должны быть не просто гибкими, а гибчайшими, потому что нужно соответствовать вызовам бизнеса.
Часто приходится экономить на важном: на людях, серверах, софте.
Нужно постоянно помнить о выдвигаемых к продукту требованиях и соответствовать заявленному MVP во всём многообразии, включая любые внезапные требования. Например, анимацию иконок.
И знаете, что самое страшное может случиться со стартапом? Процитирую Джеймса Хэтфилда, гитариста и одного из вокалистов группы Metallica: «Кто-то говорил мне недавно — умирать тяжело и страшно. Враньё! Умирать — это легко. Вот что действительно трудно, так это жить».
Вы выиграли Грэмми, никак не меньше — стартап выжил. Но есть все шансы прийти на вручение наград в состоянии «раздрая».
Не факт, что мы обладаем должным уровнем архитектурной гибкости.
Проектирование могло проводиться в сжатые сроки и с главной целью — «соответствовать MVP». Есть шанс, что целые сервисы или куски кода проще выкинуть и написать заново, так как реинжиниринг обойдётся дороже. Выбранный стек и «привычки» команды стартапа могли привести к гипермикросевистности или наномонолитности. И, конечно же, «гонка» сказалась на качестве анализа, включая риск-менеджмент. Про эту часть управления, вероятнее всего, не задумывались, так как главным риском было — не выжить. Кроме этого, команда и бизнес ещё не были сыграны, разработка могла не иметь глубокого погружения в предметную область, а значит архитектура достаточно далека от того, чтобы быть похожей на проекцию бизнеса на код.
Для обеспечения индустриальных стандартов качества может не хватать мощностей.
Облака и дата-центр часто откладываются на этап «светлого будущего». В моём опыте были кейсы, когда весь софт уже многотысячного приложения крутился на компе в кладовке рядом с печеньками и салфетками. DevOps, как методологии, так и на уровне инженерных практик, тоже может не быть, так как до этого должны были появиться админы. Ну и, конечно же, в таких условиях под вопросом стоит нормативно-правовое поле:
нет отдельной политики безопасности под 152-ФЗ;
полное информационное забытие — непростой в реализации процесс;
фискализация конечно же будет, но соответствовать 54-ФЗ в требованиях сроков — проблематично.
Практики идут вразрез с DomainDrivenDesign.
Я «топлю» за DDD — предметно-ориентированное проектирование. Ключевым термином DDD является домен, набор сущностей и действий (операторов) над ними, который однозначно определяет бизнес компании подлежащий автоматизации.
Главной особенностью проектирования в DDD является коллаборативный симбиотический подход к проведению анализа и созданию решений между бизнесом и разработкой. Если разработка и бизнес не настроены друг на друга, а на бизнес и системный анализ выделили слишком мало времени, то легко прийти к состоянию, когда архитектура не соответствует реальным процессам. Обычно в этом случае вина обоюдна: «молодец» и бизнес, и разработка.
В качестве примера поделюсь, как в «Самокате» на уровне кода разработали отдельный процесс публикаций текстовых изменений. Он помогал агрегировать все внесённые контент-менеджерами правки, сохранял их (срезал новую версию) и доставлял изменения пользователям. Чтобы исправить опечатку в слове «мАрковь», приходилось или забить на ошибку на несколько часов, пока не закончат вносить новый пакет изменений, или начать редеплой всех пользовательских витрин приложения по всей России.
Это пример про ошибку проектирования, когда разработка решила, что так будет проще, а бизнес изначально не предполагал, что необходимо будет доставлять продукты дальше, чем в несколько кварталов одного города.
Люди с синдромом «выжившего».
Оказывается, люди, которые росли вместе со стартапом, обладают качествами, которые помогли ему выжить:
Команда привыкла делать быстро. «Fast Input – Fast Output» слишком долго могло быть девизом.
Скорость и желание «побыстрее задеплоить» вызваны отсутствием стабильности. Люди привыкли, что нет стабильности в целях и задачах. Материальная и социальная безопасность завязаны на показатели количества, а не качества. Очень долго бизнес требовал выпускать новые фичи, проверять гипотезы, а про качество приходилось или забыть, или «партизанить» неявно для бизнеса, чтобы не набрать критическое число костылей.
Ну и люди, которых потом назовут «архитекторами», жили в состоянии постоянной дилеммы: отказаться от архитектурных принципов или выделить время на подумать и принять взвешенное решение.
Процессы и архитектура в постстартапный период
В какой-то момент стартап перебирается на новый уровень, и тащит за собой «багаж» предыдущего периода. Только бизнес выставляет уже новые требования:
Требование к масштабированию на уровне всего бизнеса. Важен не только продукт и новые фичи, но и то, как сам бизнес будет развиваться. Мы начинаем говорить о долгосрочном планировании, стратегии. Необходимо сменить процессы и парадигму управления всей компанией.
Быстрый time-to-market остаётся, но это уже не тот TTM. Важно сохранить привычную скорость выпуска, потому что продукт уже начали копировать, а сами фичи поменяли масштаб. Они стали «зонтичными», кросс-командными.
Недостаточно начать думать о рисках. Необходимо научиться нивелировать риски, искать и быстро находить ответы на вызовы рынка.
Пора искать способы выхода на новые рынки. Это уже не про автоматизировать +1 завод, это про поддержку сервиса 24/7 по всей РФ, а может быть в Европе или мире.
Настало время соблюдать нормативно-правовое поле, так как с ростом компании вырос и интерес к бизнесу, как у конкурентов так и у контролирующих органов.
Чтобы отвечать новым требованиям, разработке нужно погружаться в бизнес и строить продуктовый подход. Пришло время, когда нельзя отмахнуться от номинальной «бухгалтерии» или «юристов», а требуется выстроить диалог, слушать и слышать. Ниточки коммуникации должны идти не только от разработки к бизнесу, но и в обратную сторону, и язык должен быть понятен всем.
Здесь на помощь приходит DDD. Это не только домены и контексты, но прежде всего язык, на котором строится коммуникация и возникает архитектура. В основе DDD лежат два сквозных принципа: коммуникация, когда бизнес и разработка вместе проектируют решение, и проекция — отображение бизнеса в коде.
Бизнес начинает меняться от архитектуры, потому что архитектура — это про математическую модель, про то, что не может быть ошибочным, если корректно работает. И код пишется с оглядкой на бизнес, включая появление в коде спецтерминов из производства. И главное — люди перестают использовать подход: «Да что они там себе …».
Пример. В стартапе вы могли позволить себе использовать сущность «user», подразумевая под ней физическое лицо, которое пользуется вашими продуктами. В постстартапном периоде вам придётся договориться с бизнесом и разграничить понятия:
Потенциальный клиент — тот, кто просто пользуется вашим сервисом, но не принимал оферту.
Клиент — тот, кто принял оферту.
Пользователь — принял оферту и принят на обслуживание (это актуально, например, для торговых площадок с товарами 18+, в которых необходимо дополнительно подтвердить возраст или для финансовых продуктов, когда необходимо пройти идентификацию и прочие процедуры).
Стоит учесть, что эти сущности протекут не только на уровень баз или API, но также появятся в BI системах, отчётах. Поэтому проще договориться «на берегу», чем создавать в документации таблицы соответствия: термин в документации = термин в коде.
В этот постстартапный период перед людьми, которые работают в компании, появляются новые вызовы. И самое главное — это новый макет разработчика, который соответствует новым задачам:
Быть вдумчивым.
Ставить архитектурные принципы во главу — стоимость ошибки растёт быстрее, чем бизнес. Так как необходимо держать достаточно высокий time-to-market, то времени на реинжиниринг становится всё меньше.
Быть готовым снижать скорость time-to-market, если стоимость ошибки выше предполагаемого профита.
Понимать, что стабильность не равна стагнации и нужно: «Бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее».
Ценности, которые развивают компанию
Компания всегда на какой-то стадии — стартап, постстартапный период, энтерпрайз. Сотрудник тоже на каком-то уровне развития, например, junior, middle, senior. Можно предположить, что если воспитание и привитые нам в детстве ценности формируют нас, как человека, то почему нельзя пойти по этому пути в формировании компании? Что будет, если на этапе ещё стартапа начать собирать людей с ценностями, которые позволят и стартапу вырасти, и не утонуть в крови энтерпрайза? Это же план!
Дальше поговорим о том, как построить разработку от ценностей: как ценности отражаются на архитектуре и какие практики из них прорастают. Не сразу, каждая в своё время, но наличие у команды единых ценностей даёт вам возможность развиваться эволюционно и применять подходящие практики на разных стадиях развития компании.
Итак, я бы выделила всего лишь пять базовых ценностей:
Честность/открытость.
Безопасность.
Инициативность.
Сопряженность/соучастность.
Соблюдение этических норм.
У каждой ценности своя роль. Мы пойдём по спирали и на каждом витке будем раскручивать ценности и разбираться, как они работают в архитектурных процессах и в компаниях на разных этапах развития.
Честность, открытость и безопасность
Честность и открытость отражают две важные вещи в работе команд: отношение к ошибкам и отказ от подмены понятий. Умеют ли люди в команде признавать ошибки, разрешают ли ошибаться другим, и как они справляются с кейсами, где нужно открыто назвать вещи своими именами?
При этом, честность и открытость не могут существовать без безопасности. Нельзя играть в игру: «найди ошибку, за которую накажут того, кто ее нашёл».
Чувство безопасности в команде порождает практики ретроспективного анализа: человек учится оценивать результаты любой деятельности — от спринта до плана собственного развития. Конечно, чтобы это работало, внутри компании нужно вовлекать и менеджмент, и HRD. На уровне корпоративной культуры у всех должна быть единая цель.
Давайте копнём в ценности глубже и посмотрим, как честность, открытость и безопасность отражаются в архитектурных практиках и процессах.
Безопасность и риск-менеджмент
Я говорю о риск-менеджменте с точки зрения архитектуры, потому что он касается не только процессов. Когда мы проектируем то или иное техническое решение, важно учитывать, как оно отразится в проекте. Внезапно на архитектуру влияют все классы рисков. Строгой нотации я не нашла, а в своей практике обычно пользуюсь этой типизацией:
Нормативно-правовые риски: можно ли пренебречь корректным хранением и передачей персональных данных по 152-ФЗ или сразу предусмотреть возможность удаления аккаунтов, чтобы поддержать информационное забытие?
Ресурсные риски: это не только возможность потерять важного разработчика и не уложиться в сроки, но и вероятность отзыва лицензий после ввода санкций, переезд из облаков или необходимость соблюсти закон Яровой, нехватка запасных частей и инструментов с учётом новых сроков поставки оборудования.
Интеграционные риски: всегда есть шанс, что написанный и согласованный всеми сторонами протокол придётся срочно переписывать, так как в интеграции участвует «железо», протокол которого не может отдавать контрагенту что-то кроме true/false, но он об этом забыл.
Репутационные риски: простой, снижение SLA, особенности технических решений и выбора стека. При чём, выбор стека и решений может сыграть как против вас, так и за вас. Простота поиска кадров в распространённом стеке, популяризация компании на конференциях — и люди захотят к вам идти.
Классические архитектурные риски: как понять, нужно ли сейчас заложить точку гибкости, или она приведет к переусложнению? А вдруг мы наложим ограничения, а через квартал придёт бизнес и заставит всё переписать?
Работа с рисками в идеале должна продолжаться в управленческих практиках на уровне ROAM-борда. И о рисках необходимо говорить с бизнесом также открыто, как о недополученной прибыли.
Я очень люблю Канбан, так как он позволяет эволюционно развивать процессы, и если к обзору рисков в рамках отдельного мероприятия вы ещё не готовы, просто добавьте в технические решения раздел про риски и записывайте туда всё, что важно обсудить на встрече архитектурного комитета. И со временем этот пласт работы станет важен и привычен для бизнеса.
Коммуникационные практики в развитии архитектуры компании
В коммуникациях я бы выделила три основные практики, которые вырастают из честности и безопасности: архитектурные комитеты, ликбезы, «сапёрники». Рассмотрим, как они работают.
Архитектурные комитеты
Архитектурный комитет — это команда, в которую входят наиболее опытные разработчики и архитекторы.
В моей практике были как компании, в которых был институт архитекторов, так и компании, в которых не было. Например, до недавнего времени архитекторы в «Самокате» отсутствовали как класс. Каждая команда была полностью ответственна за технические решения, над которыми работала. Число команд росло, и настало время создать общий архитектурный ландшафт продукта на уровне доменов и сущностей. Это было нужно, чтобы избежать оверинжиниринга, порождения легаси на этапе проектирования и в целом ситуации «лебедь, рак и щука» между юнитами.
В итоге в «Самокате» появились два уровня комитетов: кластерный и корпоративный.
Кластер — это объединение юнит-команд на основе близости доменов и по принципу пересечения на уровне кодовой базы.
Цель кластерных архитектурников — сформировать культуру обсуждения технических решений. Мы хотели выработать единый вокабуляр, научиться объяснять свои решения, спорить, понимать, где друг другу помочь и как разделить ответственность за решения, без подхода «моя хата с краю».
Корпоративный архитектурник — это встречи для корпоративной синхронизации и синхронизации с бизнесом.
Этот вид встреч появился не сразу. С ростом бизнеса мы столкнулись с тем, что на уровне каждой команды стало трудно отслеживать изменения и то, как реализуются продуктовые стратегии. Нам было нужно синхронизироваться, иметь общее видение и делать так, чтобы технические решения соответствовали стратегии компании и общему планированию работы в продукте.
Так, например, в промежутке полутора месяцев на архитектурниках «Самоката» всплыли три технических решения от команд из разных кластеров. Все они начали разработку трёх сервисов «Расписания».
Первый сервис предназначался для расписания медиа-контента, второй — для публикаций о товарах, а третий отвечал за сроки проведения промо-акций. Всё бы ничего, но эти сервисы должны были встретиться в мобильном приложении и единообразно отобразить информацию пользователю. Это усложняло решение, потому что одно приложение — с днями и неделями, второе — с буднями и выходными, третье — по часам. Мапить их друг на друга по набору неведомых правил было нерадостной перспективой. В итоге пришлось два решения убрать, одно дописать.
Чтобы избежать таких ситуаций, архитекторы должны задавать общий вижен, который станет не скрижалью, а отправной точкой для обсуждения. Тем самым можно сохранить ценности и принципы, на которых построена компания.
Ликбезы
Ликбез — коммуникационная практика для обмена знаниями и опытом в работе с кодом или предметной области.
Здесь стейкхолдеры, продакты, разработка — каждый рассказывает про свою зону ответственности в продукте. На эту встречу приходят любые представители компании, и можно задавать любые вопросы.
Ликбез состоит из двух частей:
Архитектурный ликбез — говорим об основных сущностях, схемах компонентов и обмена данными, технических метриках и данных, которые отправляются для BI.
Бизнесовый ликбез — обсуждаем вопросы по стейкхолдерам; автоматизацию бизнес-процессов и как они вписываются в архитектурное решение; какие бизнес-процессы физически задействованы и какие команды вовлечены; процессные метрики — что измеряем, куда поступает, кем обрабатывается, что из этого относится к метрикам, за которыми следит разработка.
Практика ликбезов — потрясающая, так как позволяет всем ответственным за продукт честно рассказать о нём со всех сторон, ответить на вопросы, выявить предложения, которые могут стать продуктовым или техническим бэклогом команды. Также абсолютно бесплатно, на уровне дополнительных затрат, можно сформировать библиотеку знаний, состоящую из: схем, презентаций и видео-записей. Всё это круто работает в онбординге новых сотрудников, когда нужно за короткое время познакомить с продуктом и рассказать, как его разрабатывали.
Сапёрники
Сапёрник (от слова «сапёр») — это встреча для обсуждения легаси и других проблем в коде или продукте.
Мы инициируем такой формат, когда нужно обсудить выявленный кусок легаси или принять решение «разминировать» какой-то известный кусок. Проводится как отдельно, так и в рамках ликбеза.
Все «сапёрники» открытые, и бизнес в них тоже участвует. Через эти встречи мы также тренируем коммуникацию — важно не просто найти проблему, но и обосновать, почему ей стоит заниматься. Плюс, собираем данные для технического бэклога.
Структура «сапёрника»:
Текущие проблемы — то, что «плохо лежит», и надо срочно чинить.
Проблемы уровня «deus vult» — те, что исторически сложились.
Информация о том, что уже заведено в бэклог — как ведётся работа, где найти все задачи технического долга.
Все три практики — архитектурник, ликбез и «сапёрник» — имеют ограничение. Они хороши для постстартапного периода и ещё велики для стартапа. Но реализовать принципы честности, открытости и безопасности в стартапе можно другими способами.
Честность, открытость в стартапе
Обычно в молодой компании всё не так системно — команды на виду, больше синхронизации. Чтобы внедрить ценности честности и открытости, используют такие практики:
Продуктовые брейнштормы — помогают повысить понимание процессов и продукта всеми участниками.
Совместное рисование портрета пользователя — для качественного погружения в продукт и проблемы пользователей, которые стартап хочет закрыть.
Групповые обсуждения автоматизируемых процессов, архитектуры, API — толчок к формированию единого словаря, который будет расти вместе с компанией и помогать бизнесу и разработке понимать друг друга.
При этом надо иметь в виду: всё описанное выше нельзя внедрить в архитектурные процессы и в саму архитектуру, если за честность в компании бьют по рукам.
Безопасность в постстартапной компании
Чтобы построить безопасную среду, важно понимать природу отношения к ошибкам. Нас со школы учили ошибаться как можно меньше. Не так важно, как найдено решение, главное — чтобы оно было правильным. Но при таком подходе в команде не будет симбиоза.
Когда мы выбираем безопасность как ценность, то подразумеваем, что у каждого есть шанс на ошибку. Прийти к этому в технической команде помогают ретроспективы, инцидентный анализ и пост-ревью по проектам.
Ретроспективы — практики менеджмента по окончанию спринта/проекта, по какому-либо периоду внутри команды (квартал или полугодие), ретроспективы для «калибровки» программ развития команд и сотрудников.
Стартапу важно научиться воспринимать команду как единый организм со своими проблемами, идеями и классными фичами. Тогда мы можем целостно смотреть на то, как развиваются наши команды, кластеры и подразделения.
Анализ инцидентов включает PIR/post-mortem анализ и формирование картотеки выявленных уязвимостей. Не важно, кто именно в команде совершил ошибку, важно выносить пиры на общее рассмотрение и открыто разбирать каждый инцидент, сохраняя его историю. И делать так, чтобы новый сотрудник знакомился с библиотекой инцидентов — это дополнит картину того, что происходило с продуктом, как он менялся и как его чинили.
Пост-ревью по проектам. Вопреки привычке, работа над проектом не заканчивается после его запуска. Нужно проанализировать проект и понять, что получилось. И хорошо это разобрать не на уровне команд, которые его выполняли, а на уровне всей компании.
Что даёт ценность безопасности в стартапе
Открытый диалог с бизнесом и инвесторами. Стартап — это не только новый продукт, но и новый код, а иногда и новые технические вызовы, с которыми вы не сталкивались, и даже индустрия может быть незнакома. И это нормально — признавать честно, когда что-то не учтено.
Возможность не потерять из виду процессы и скрытые проблемы. С помощью ретроспектив мы можем остановиться и раз в месяц разумно посмотреть, что сделали и что планируем. Это даёт возможность не ошибиться. В стартапе месяц — это много. За это время пишется столько строк кода, сколько пишет корпорация за 1,5-2 месяца, и в этой гонке очень легко перейти к состоянию бега ради цели, но без понимания процесса.
Возможность менять корпоративную культуру изнутри. Ценности можно создавать буквально руками и системно внедрять в компанию на всех уровнях. Начиная с собеседований проговаривать, что вам важен не результат, а способ мышления. Предупреждать, что вы «не ругаете» за ошибки, что все ошибаются, и главное — быть готовым исправить. Ну и конечно помогать человеку признавать ошибки и оценивать готовность исправления, а не факта ошибки.
Но есть тонкая грань, которую важно не перейти: баланс между умением принимать и прощать ошибки и безалаберным, всепрощающим отношением к блокерам/критам. На мой взгляд, эта грань проходит через ещё одну ценность — ответственность.
Ответственность
Создавая продукты, сложно не ошибаться. Вспомните себя два-три года назад: как оцениваете свои решения на тот момент? Всегда есть, за что зацепиться и где внести правки, поэтому чтобы развивать в командах ответственность, важно создать условия, которые не позволят членам команды уйти в самокопание и самобичевание:
Внедрять практики работы с ошибками.
Подключать команду к устранению ошибок и поиску решений.
Формировать поддерживающую среду и строить совместные процессы с HR-департаментом.
В этом случае, изменяя корпоративную культуру, можно создавать ценность и внедрять в компанию. Например, начать можно с собеседований, проговаривая, что нам важен не результат, а способ мышления человека. Предупреждать, что мы «не ругаем» за ошибки, и считаем, что все ошибаются и имеют право на ошибку. Главное — быть готовым её исправить. И конечно помогать человеку в признании ошибок и оценивать готовность исправления, а не факта ошибки.
И абсолютно не важно, на каком этапе находится компания. Практики одинаковые. Они базируются на эмпатии, уровне доверия и чувстве «братского плеча», которое придёт на помощь в трудной ситуации, а может быть и «отвесит» подзатыльник.
Инициативность и соучастность
Как только в компании появились честность, безопасность и условия для принятия ответственности, за ними следом «бегут» инициативность и соучастность. Конечно, может возникнуть вопрос, почему за ними, а не впереди. Я считаю, что инициатива не должна быть наказуема.
Говоря про инициативность, я имею в виду принципы: «кто первый встал, того и тапки» и отказ от собственнического подхода к коду.
Когда мы запустили архитектурные комитеты в «Самокате», наши решения стали более согласованными и открылась дорога для инициативы. Когда команде понятны цели принятого решения, гораздо легче приживается правило: кто первый наткнулся на проблему, кому она мешает, тот её чинит. Это не значит, что человек остаётся с проблемой один на один. Можно попросить помощь и искать решение уже с поддержкой соседней команды.
При таком подходе удаётся держать высокий темп time-to-market, поддерживать знание кодовой базы среди нескольких команд и достаточно глубоко погружать людей в предметную область. Но чтобы всё описанное свершилось, необходимо внедрение практик и на уровне разработки, и на уровне управления.
Инициативность в практиках разработки
Код-ревью
О качестве кода нужно научиться договариваться не только в команде, но и на уровне компании. Недостаточно подхода: «мы устно проговорили». Договоренности важно фиксировать, учитывая специфику, в том числе инфраструктурного ландшафта каждого из участников. Нужны общие правила.
Код-стайл
Договариваться важно и о стиле кода. Код-стайл значительно ускоряет процесс адаптации новых программистов, минимизирует эффект ментального блокера при изучении нового кода, например, из-за специфического оформления. В идеале состояние, к которому нужно прийти в этом процессе, называется обезличенным кодом.
Архитектурный гайд
Если требования предъявляются к качеству и стилю кода, то предъявляем их и к архитектуре. Формулирование архитектурных принципов может породить в компании невероятно жаркие споры В «Самокате» так и произошло. Итог — свод договоренностей о том, как строится архитектура и при каких условиях эти договоренности могут быть пересмотрены.
Соучастность в практиках менеджмента
За практиками разработки следуют практики менеджмента. Когда код пишут вместе, и нет «своих/чужих» проблем, делать проекты приходится тоже вместе, вне зависимости от границ продуктов.
«Зонтичные проекты»
Если мы договорились помогать и принимать ответственность за принятые решения, то менеджерские практики подтягиваются за практиками разработки. Потому что каждый проект, как зонтик, который накрывает сразу несколько команд.
Сквозные процессы и продуктовый подход
По мере того, как растёт компания, процессы становятся более сквозными. Оставаясь продуктовыми командами и сохраняя принципы продуктового деления, мы продолжаем помогать другим командам, делим ответственность, меняемся знаниями на уровне компании, подкрепляем ретроспективные практики, развиваем команды с учетом ценностей. Это помогает сохранять высокий уровень экспертизы и понимать, что происходит.
Так архитектурные принципы и практики разработки, внедрённые в компании, начинают влиять на процессы управления. И мы возвращаемся к симбиозу бизнеса и разработки, но уже в ситуации, когда бизнес начинает меняться от разработки. Давайте посмотрим, что происходит с нашими ценностями в стартапе.
Инициативность и соучастность в стартапе
На мой взгляд, инициативность и соучастность приносят больше пользы стартапу, чем корпорации.
Быстрые инициативные старты
В корпорации вряд ли можно с нуля раскачать разработку до уровня, когда кому-то по фану написать бота, который приведёт новых пользователей, или потестировать в свободное от основных задач время новую библиотеку. Но в стартапе обычно с этим нет проблем, потому что много фана, желания менять и пробовать всё.
Бесстрашие перед A/B-тестами и результатами
A/B-тесты инициируются любым участником, проектируются командой совместно. Вырабатывается привычка быстрого запуска тестов и легкого отношения к их результатам. Потому что, как правило, первыми пользователями продукта является сама разработка, их семьи и первый круг общения.
Совместный багфикс как практика
Люди учатся вместе чинить то, что сломалось. Без оглядки на то, что кто зацепил. Если внедрить эту практику на старте, ценность инициативности и сопричастности приживётся и дальше — в корпорации, и в энтерпрайзе.
Продолжить мысль помогла бы идея, что всё это недостижимо без уважения. Но, например, в «Самокате» опасаются термина «уважение» за дух абсолютизма, которым от него веет — «уважать старших», «уважать начальство». Можно называть всё своими именами и строить архитектуру на открытом диалоге с бизнесом. Так мы пришли к поддержке норм этики.
Нормы этики в продуктовом подходе
Какие нормы поддерживают в «Самокате»:
Здоровые и честные отношения.
Линейность структуры управления.
Обоснование ценностей — в основе любой задачи.
Снова возвращаемся к симбиозу, на котором строится продуктовый подход и держится возможность использовать DDD. Как бы ни складывались отношения между людьми в команде, важно понимать, что каждый участник несёт ценность продукту, компании и важен именно этим. На таком основании рождается устойчивая архитектура и принципы, которые мы каждый день закладываем на уровне кода.
Техническая стратегия
«Самокат» — в чём-то такая же компания, как другие, но она всегда продвигала свои ценности. Это не значит, что любая практика внедрялась с радостью и без сопротивления. За пять лет компания пришла к необходимости иметь стратегию, и даже две — бизнеса и техническую. И техническая стратегия переплетает три направления:
Корпоративные вызовы, формируемые CTO, в том числе планы по стабилизации сервисов, выявленным уязвимостям (ИБ), масштабированию бизнеса.
Вызовы на уровне лидов практик: Back-end, Front-end, Mobile, QA.
Командные вызовы: выявленные, в том числе на сапёрниках, проблемы и задачи по развитию архитектуры и устранению легаси.
Стратегия формируется на встрече, где представители всех трёх направлений обсуждают каждый свою часть и принимают решения. В рамках этой же встречи могут быть приняты решения, которые приведут к пересмотру общекорпоративной технической стратегии.
Это пример проникновения ценностей на С-level компании, когда от разработки начинают меняться не только вектора развития, но перспектива и видение.
Закладывая в фундамент компании ценности, мы выбираем путь развития всего: продукта, команд, архитектуры. А ниже ценности «Самоката», как они есть.
Выводы
Мы привыкли говорить об архитектуре, как об отдельном аспекте компании, как о чистой математике — паттерны, практики, подходы. Но архитектура — это зеркало бизнеса, процессов, людей и ценностей.
Можно ли строить что-то в отрыве от ценностей — конечно. Можно ли при этом достичь успеха — неоспоримо. Но ценности могут стать универсальным механизмом на всех этапах жизни компании.
Воплощение ценностей будет отличаться для стартапа и для корпорации, но принципы будут едины. И вам никогда не придётся ломать себя и других, вы откроете возможность менять подходы по мере роста и строить архитектуру, закладывая для неё прочный фундамент. Тогда любой переходный период в компании — кратный рост коллектива или выход на новые рынки — будет проще и куда более эволюционным, чем революционным.
Строить компанию и архитектуру на ценностях никогда не поздно, но, конечно, лучше начинать раньше, пока вы ещё стартап.
Пройдите, пожалуйста, небольшой опрос от Онтико! За него вы получите ссылку на видеозаписи докладов с конференции HighLoad++ Foundation 2022. Записей ещё нет в открытом доступе.