Домклик

Всем привет! Меня зовут Мария, в компании ДомКлик я отвечаю за организацию обработки персональных данных, и сегодня речь пойдёт о процессе сбора согласий на обработку в соответствии с требованиями законодательства.

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

В соответствии с Федеральным законом от 27.07.2006 152-ФЗ О персональных данных субъект этих самых данных должен самостоятельно принять решение об их предоставлении и согласии на их обработку. Согласие на обработку персональных данных должно быть конкретным, информированным, сознательным и не может навязываться субъекту персональных данных со стороны оператора. Согласие должно быть дано субъектом или его представителем в письменной форме, либо в форме электронного документа, подписанного электронной подписью. И оператор обязан предоставить доказательства получения такого согласия.

Для чего и с какой целью?

ДомКлик, как и многие другие компании, столкнулся с рядом проблем, связанных с тем, что:

1. Не было единого подхода к сбору согласий на обработку персональных данных, в том числе:
   
   • отсутствовала централизованная система, регламентирующая процесс сбора (каждый сервис собирал согласия как хотел и хранил артефакты сбора как мог);
   • применялись разные способы подтверждений (в одной подсистеме сайта ДомКлик использовался чекбокс, в другой кнопка подтверждения);
   • использовались разнообразны виды и формы согласий.
2. Были сложности с определением принадлежности полученного согласия конкретному пользователю ДомКлик (субъекту персональных данных).
3. Поиск доказательств факта получения согласий трудоёмкий процесс, который не всегда был результативным.

В результате не в полной мере выполнялись требования законодательства по обработке и защите персональных данных.

Ради централизованного учета в ДомКлик решили создать единый сервис, позволяющий контролировать процесс сбора/регистрации/хранения/отзыва согласий на обработку персональных данных.

Что удалось сделать и как это работает?

В рамках разработки сервиса Согласий перед командой ДомКлик стояли основные задачи:

• реализовать единый подход к сбору, регистрации, хранению и процессу отзыва согласий;
• разработать универсальный виджет для версий согласий и разных сценариев их сбора;
• разработать средство администрирования (админку), с удобным интерфейсом!
• минимизировать правовые риски, связанные с обработкой и защитой персональных данных.

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

Что мы сделали:

• реализовали и регламентировали единый подход и контроль согласий;
• оптимизировали поиск доказательств факта получения согласия, чтобы сократить длительность и трудозатраты;
• параметризировали согласия, то есть теперь можно узнать, кто дал согласие, какой использовался сценарий сбора, когда и в каких целях было получено согласие, а ещё сроки/статус/тип/версию согласия и т.д.;
• обеспечили выполнение требований ФЗ-152, тем самым снизили правовые и репутационные риски.

Дополнительно сервис может регистрировать следующие данные:

• сведения о согласии (наименование, тип, версия, краткое описание процесса, в котором оно используется и т.п.);
• статус согласия (принято/отклонено/в ожидании чуда);
• признак отзыва согласия (дата, время, основание);
• дату подтверждения согласия для автоматического уведомления о сроке его окончания (реализована автоматическая проверка срока действия согласия);
• срок действия согласия;
• способ подтверждения согласия.

Также мы реализовали сбор согласий в форме электронного документа, подписанного электронной подписью.





На этапе сбора мы предусмотрели несколько сценариев:

• ввод полученного кода из SMS-сообщения или голосового сообщения в специальном поле на сайте ДомКлик (если клиент напрямую взаимодействует с сайтом).
• отправка полученного кода из SMS в ответном SMS (если запрос инициирован третьим лицом, например, сотрудником ДомКлик).
• гибридный сценарий позволяет подтверждать согласие как ответным SMS, так и через ввод кода по уникальный ссылке из SMS (обычно используется в случаях, когда клиент не находится на сайте ДомКлик, а инициатором выступает третье лицо).

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

Кроме того, в сервисе предусмотрена поддержка в актуальном состоянии форм согласий (ранее все согласия были в формате .pdf и не имели версионности). Для этого применяется формат .html, а версионность документов позволяет DPO оперативно корректировать формы согласий (например, в связи с изменениями в законодательстве или в бизнес-процессе). При этом не нарушается клиентский путь.

Также при сборе согласий мы проверяем, давал ли пользователь уже такое согласие или нет. Если давал и в той же редакции, то повторно не надо соглашаться, нельзя дважды подтвердить одно и то же согласие.

В серверной части сервиса Согласий использован Kotlin, а фронтендная часть написана на React.

Новый сервис принял уже более 8 000 000 согласий от пользователей ДомКлик.

Какие планы на будущее?

Для пользователей:

• Добавим в личный кабинет на сайте ДомКлик информационный блок о согласиях, которые дали пользователи (со статусом, датой, версией).
• Добавим в личный кабинет возможность отозвать согласие.

Для сервисов ДомКлик:

• Начнём применять сервис Согласий в иных целях и для других документов (например, для согласий на получение рекламно-информационных материалов о продуктах, товарах и услугах ДомКлик, и т.д.).
• Будем использовать в тексте согласий динамические параметры (например, наименование третьего лица, чьи персональные данные были переданы).
• Автоматизируем и упростим процесс отзыва согласий на обработку персональных данных.

Всем привет. Меня зовут Стас, в компании Домклик я курирую разработку сервисов бек-офиса для ипотечного кредитования Сбербанка.

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

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

Тема стала достаточно хайповой, и я решил прикинуть, как именно принципы зеленого могут быть отражены в WEB-разработке.

Основные принципы написания зеленого кода

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

1) Упрощение и оптимизация алгоритмов

Как уже было сказано выше, выполнение кода должно приводить к минимальному потреблению энергии. Оптимизированный код будет выполняться быстрее и, соответственно, потребует меньше затрат на его обработку и охлаждение оборудования.

Давайте попробуем посчитать разницу в энергозатратах на исполнение конкретной операции в коде классической сортировке списка. Я специально буду утрировать ситуацию в приведенном примере, чтобы контрастнее показать разницу.

Возьмём сортировку методом пузырька. Наверное, это один из самых неоптимальных способов. Очень нам подходит. Рассчитаем сортировку списка и посмотрим, как она отразилась на энергозатратах MacBook. Для начала смоделируем массив данных и саму логику сортировки пузырьком:

from random import randintdef bubble(array):    for i in range(productNumber-1):        for j in range(productNumber-i-1):            if array[j] > array[j+1]:                buff = array[j]                array[j] = array[j+1]                array[j+1] = buffproductNumber = 60000products = []for i in range(productNumber):    products.append(randint(1, 1000))bubble(products)print(products)

Для замера влияния исполнения кода на энергозатраты я использовал систему мониторинга iStat Menus 6 (http://personeltest.ru/aways/bjango.com/mac/istatmenus/). Подключил MacBook к сети, закрыл все сторонние приложения, выждал определенное время для зарядки батареи, и запустил сортировку:

График энергопотребления при выполнении сортировки пузырьком:



Виден ярко выраженный скачок потребления мощности длительностью в 305 секунд. Он вызван исполнением нашего неоптимального запроса. Дополнительно потраченная энергия за 5 минут (305 секунд):

P = (W2 W1) 305 = (17,29 [мощность при выполнении скрипта] 2,9 [мощность в состоянии покоя]) 305 = 14,39 305 = 4389 Дж = 0,0012 кВт*ч .

Теперь допустим, что этот код случайно попал на промышленный продуктовый сервер (примем как допущение, что дополнительные энергозатраты на сервере будут такими же, как на моем MacBook, и зависимость прямо пропорциональная) и стал выполняться с частотой 1 раз в 10 секунд. Тогда в год мы получим дополнительные энергозатраты:

365 дней 24 часа 3600 с/10 0,0012 кВт*ч = 3 784,32 кВт*ч.

Предположим, что ЦОД, в котором размещается сервер, получает энергоснабжение от котельной, в качестве топлива в которой используется березовая древесина. При сгорании 1 м³ березовой древесины выделяется 1900 кВт*ч/м³ энергии. Разумеется, КПД котельной не 100 %, и если принять его за 75 %, то получим:

(3 784,32 / 1900) / 0,75 = 2,66 м3.

Если принять дерево за правильный цилиндр, объем которого равен

V = Pi R2 H

где R радиус ствола дерева, примем его за 0,12 метра (среднее значение),
H высота ствола дерева, примем ее за 3 метра (среднее значение).

то получаем:

V = 3,14 0,0144 3 = 0,14 м3

Значит, в одном кубометре древесины будет 1 / 0,14 = 7,14 бревна.

Для обеспечения энергией работы нашего скрипта нам понадобится в год 2,66 м3 7,14 = 19 берез.

Для сравнения я выполнил ту же сортировку с использованием стандартного способа сортировки в Python (.sort()).

График энергопотребления при выполнении стандартной сортировки в Python:



Применяя ту же логику расчета (длительность пика была 10 сек), получаем:

P = (W2 W1) 10 сек = (3,51 [мощность при выполнении скрипта] 2,9 [мощность в состоянии покоя]) 10 сек = 6,1 Дж = 0,0000016 кВт*ч

В год получим (при условии выполнения операции 1 раз в 10 секунд)

365 дней 24 часа 3600 с/10 0,0000016 кВт*ч = 5,05 кВт*ч

Или же:

5,05 / 1900 / 0,75 7,14 = 0,025 бревна березы.

Конечно, в этом примере много допущений, да и сортировку пузырьком делают достаточно редко. Но полученные числа показались мне интересными

2) Использовать событийную модель (event driven model) работы приложения там, где только можно

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

Спектр состояний (оптимизация по энергопотреблению):



Подробнее об этом можно прочитать тут.

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

Правильно было бы транслировать соответствующее событие в очередь, и считывать факт его возникновения всем заинтересованным сервисам.

Спектр состояний (оптимизация по энергопотреблению):


Другой пример взаимодействие фронтенд- и бекенд-компонентов приложения. Если фронту надо поменять свое состояние в зависимости от данных в базе, иногда на бекенд периодически шлют запросы, создавая ненужную дополнительную нагрузку. Хотя можно проинформировать фронт об изменении состояния необходимых данных через сокетсервер.

Хотя с сокетами тоже можно ошибиться, вот пример плохого кода:

while(true){        // Read data        result = recv(serverSocket, buffer, bufferLen, 0);        // Handle data          if(result != 0)        {                HandleData(buffer);        }        // Sleep and repeat        Sleep(1000);}

Видно, что даже если данные в сокет не поступили, всё равно каждые 1000 секунд код будет выполняться, тратя драгоценную энергию.

То же самое можно написать чуть по-другому, и энергии будет тратиться меньше:

WSANETWORKEVENTS NetworkEvents;WSAEVENT wsaSocketEvent;wsaSocketEvent = WSACreateEvent();WSAEventSelect(serverSocket, wsaSocketEvent, FD_READ|FD_CLOSE);while(true){    // Wait until data will be available in     the socket    WaitForSingleObject(wsaSocketEve    nt, INFINITE);    // Read data    result = recv(serverSocket, buffer,     bufferLen, 0);    // Handle data     if(result != 0)    {        HandleData(buffer);    }} 

3) UI/UX: Интерфейс пользователя не должен показывать лишние данные

Если данные всё же используются, но редко, то лучше их не отображать по умолчанию, а показывать только по кнопке Показать детальную информацию.

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

Пример плохого интерфейса:



На странице отображается огромный список задач (разбитый на страницы), однако пользователь всё равно будет искать определенного клиента (по определенной логике у него в голове) в поисковой строке сверху. Зачем тратить ресурсы на получение списка задач?

Тот же самый сценарий, реализованный по-другому:

Пример зеленого интерфейса:



Логика выбора клиента перенесена в систему, по умолчанию не запрашивается лишних данных по привычке. Этому варианту, помимо экологов, и кибербезопасность будет люто аплодировать.

4) Рефакторинг

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

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

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

К примеру, регулярно рефакторя один из наших сервисов (в рамках технической квоты рабочего времени), мы обнаружили вот такое:

Пример рефакторинга:



crm_deal_id идентификатор ипотечной сделки в старой системе. Сейчас он уже не нужен, но в коде осталась проверка на его получение и вызов дополнительной функции delete_deal_chat_telephony, которая выполняет еще кучу действий.

Всё это можно убрать без потери функциональности.

5) Использовать низкоуровневые языки программирования для высоконагруженных приложений

Очевидно, что в большинстве случаев приложения, написанные на низкоуровневых языках, более энергоэффективны. Нагруженный сервис на Python (если он выполняет простую операцию) имеет смысл переписать на C/C+. Будет быстрее и зеленее.

Правда, часто у нас нет нужных знаний для написания логики на таких языках.

6) Группировать I/O-операции

Системы хранения, как и процессоры, также имеют различные состояния энергопотребления.
В режиме сна потребляется гораздо меньше энергии, чем в рабочем прогретом состоянии. Особенно это характерно для систем хранения/жестких дисков.

Если в работе приложения можно группировать данные, записываемые на диск, и обращаться к диску не постоянно, а в определенные периоды времени, то это будет энергоэффективнее, поскольку в период простоя операционная система отправит диск в спячку.

7) Использование менее энергоемких систем хранения для логов

Хорошей практикой будет использовать горячее и холодное хранение. Например, логи за последнюю неделю имеет смысл хранить в индексированном виде горячего приготовления, поскольку вероятность обращения к ним будет достаточно высока. Логи за более длительный период можно хранить в более дешевых и менее энергозатратных системах хранения.

А как в промышленном масштабе?

Выше мы рассмотрели основные приемы работы с кодом для обеспечения его энергоэффективности. Но даже соблюдение большинства этих правил даст весьма скромную экономию, которую сложно будет визуализировать. Конечно, если в проде не сортировать списки методом пузырька

Гораздо больший эффект даст целенаправленная разработка функциональности по внедрению электронного документооборота.

Одним из направлений деятельности команд Домклик является оптимизация и упрощение процесса получения ипотеки. И в этом ипотечном процессе на финальной стадии готовится достаточно много документов на бумаге. Причем в нескольких экземплярах. Один экземпляр для продавца, один для покупателя, один для архива банка.

Мне приятно осознавать, что Домклик тратит много усилий для изничтожения этой порочной практики и перевода всего документооборота в электронный формат. В этом году значительная часть ипотечных сделок была уже полностью оцифрована (печаталась только одна бумага: заявление на выпуск УКЭП, усиленной криптографической электронной подписи). Все остальные документы подписывались уже этим УКЭП и бумага на них не тратилось.

Благодаря этой инициативе было сэкономлено уже более 67 491 108 листов бумаги. В березках это примерно 23 000 деревьев!

Берегите природу!

Ссылки для интересующихся:

1. Green IT available data and guidelines for reducing energy consumption in IT Systems / Ardito L.; Morisio M In: SUSTAINABLE COMPUTING. ISSN 2210-5379. STAMPA
2. Understanding Green Software Development: A conceptual Framework /Luca Ardito, Giuseppe Procaccianti, Marco Torchiano, Antonio Vetro
3. Green SW Engineering:Ideas for including Energy Efficiency into your Softwar Projects/Gerald Kaefer

Всем привет, меня зовут Семён и я руковожу разработкой витрины объектов недвижимости в ДомКлик. В прошлой части этой серии статей мы поговорили про самую трудоёмкую область работы тимлида работу с людьми. Сегодня я расскажу про не менее важную тему для любого тимлида технологии. Насколько крут должен быть тимлид технически? Должен ли он писать код? Отвечает ли тимлид за техническое состояние своего хозяйства? Кого заинтересовал, прошу под кат.

Об уровне владения технологиями

Должен ли тимлид быть самым-крутым-нинзя-рокстар разработчиком? Вопрос дискуссионный. Зависит от компании: где-то тимлид сам проектирует архитектуру, принимает все ключевые решения по реализации функциональности, проводит code review, отвечает за релизы; а где-то эта роль подразумевает управление людьми, и в команде есть техлид, закрывающий основные технические вопросы.

Для себя я отвечаю на этот вопрос следующим образом: тимлид должен иметь опыт разработки, но не обязан быть самым лучшим разработчиком в команде. Более того, тимлид обязан сплотить вокруг себя разработчиков гораздо круче, чем он сам.

Окей, мы разобрались с тем, что у тимлида должен быть опыт разработки. Каким уровнем знаний он или она должны обладать? На мой взгляд, уровень владения техническими вопросами должен быть достаточным, чтобы:

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

Должен ли тимлид постоянно писать код?

На мой взгляд ни в коем случае. Иначе это не тимлид, а высокооплачиваемый разработчик. Но если тимлид не пишет код, то зачем все эти знания? Как говорит Егор Толстой: тимлид это снежинка, и наша диаграмма из предыдущей статьи тому подтверждение:

Я отнёс к блоку технологий в обязанностях тимлида четыре области:

• инженерная культура;
• Agile-процессы;
• SLA;
• постоянное улучшение качества.

Что я понимаю под инженерной культурой?

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

К первой категории я отношу конкретные техники, методики и инструменты, использование которых тимлид регулирует, продвигает и контролирует:

• архитектурные стандарты;
• типовые решения;
• правила оформления кода (stylе guides);
• стандарты code-review;
• автомацизация рутинных операций;
• практики сообщества;
• работа с техдолгом;
• документация.

Ко второй части относятся неосязаемые понятия, которые также зависят от тимлида:

• внутренний стандарт качества команды;
• ответственность за принятие решений;
• научный подход;
• нетерпимость к плохим решениям;
• открытость к экспериментам;
• ориентация на результат.

Agile-процессы

Почему я пишу Agile? Почему не рассматриваю другие подходы к разработке? Потому что, на мой взгляд, ничего лучше, чем Extreme Programming и принципы Agile Manifesto ещё не придумали. Как еще нам действовать в условиях неопределённости, в которых работает большинство из нас?

Почему налаживание процессов проблема тимлида? Я уверен, что невозможно выпускать стабильный продукт вовремя без налаженных процессов в разработке. Как мы передаём задачи от продукта в разработку? Как проверяем гипотезы? Как уменьшаем риски вкладывания наших усилий не туда? Как релизим? Как даём быструю обратную связь заказчику? Если на эти вопросы не будет чётких ответов, на каждом этапе разработки будут потери времени и усилий на их прояснение. Поэтому, процессы должны сидеть в подкорке мозга каждого члена команды, включая бизнес, дизайн, разработку. И работа тимлида как раз состоит в том, чтобы эти процессы наладить и закрепить. Для этого хорошо подойдёт cookbook свод правил, который стоит обсудить со всеми членами команды и выложить на Confluence/вики/базу знаний команды, показывать новым членам команды при введении в работу, и постоянно совершенствовать его.

SLA

Ещё одна особенность позиции тимлида ответственность за доступность и бесперебойную работу сервисов, которыми владеет команда. Руководство не очень любит разбираться, где конкретно проблема. Даже если, к примеру, проблема у подрядчика в дата-центре, но проявляется она у тебя на продукте, поднимут первым тебя. Нужно быть готовым, что тебе позвонят ночью с тем, что не работает поиск, или включат в чат на выходных, где генеральный директор пытается понять, почему у него не грузятся фото в приложении. Это случится обязательно, рано или поздно. И тимлид должен быть готов к этому.

Для того, чтобы быть готовым к инцидентам и уменьшить уровень стресса, когда они происходят, нужно, как минимум, иметь:

• мониторинг сервисов;
• архитектурную схему;
• настроенный доступ к критическим системам;
• налаженные отношения со смежниками.

Мониторинг сервисов

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

Архитектурная схема

Когда я говорю архитектурная схема, я не имею в виду чертёж размером со стену, распечатанный на листах А1 (доводилось видеть и такое). Я, скорее, подразумеваю, что тимлид должен знать все компоненты (микросервисы) в своём владении, бизнес-логику, по которой эти компоненты обмениваются данными, типовые сценарии использования сервиса. Также тимлиду нужно знать путь запроса до приложения со всеми балансировщиками, API-гейтвеями, waf-ами, IPS-ками, ингрессами и прочими проксями это позволит быстро диагностировать проблему и найти ответственных.

Настроенный доступ

Даже при хорошо налаженной схеме дежурства может случиться так, что дежурный недоступен (сел телефон, отключили интернет, крепко спит и т.д.). И в таком случае всё равно реагировать придётся тимлиду. Поэтому важно иметь настроенный доступ во все критические системы, которые могут пригодиться при диагностировании и решении проблемы. Для меня это реплики баз данных, поды Kubernetes/kubectl, ELK, CI/CD, UI RabbitMQ, и конечно VPN, чтобы добраться до всего этого.

Отношения со смежниками

Не секрет, что в современном мире команда разработки не делает продукт в вакууме: всегда, как минимум, есть команда DevOps/эксплуатации, подрядчики с дата-центрами, служба безопасности со своими прокси, DBA с базами, провайдеры связи, DNS, CDN и бесконечное число внешних интеграций. При сбое любого из этих узлов может возникнуть ощущение, что ваш продукт не работает. В этом случае координировать усилия по устранению проблемы придётся тимлиду. Очень важно при этом быть на короткой ноге со смежными командами/подрядчиками: как минимум, нужно иметь все контакты (почтового адреса недостаточно, нужен номер телефона или аккаунт мессенджера). Но лучше, когда у вас со смежниками есть общий чат, в котором в любое время можно организовать взаимодействие. Помогает также заранее провести учения по имитации недоступности систем (мы писали об этом тут), итогом которых станет протокол реагирования на инциденты.

Постоянное улучшение качества

Не секрет, что в погоне за time-to-market мы часто принимаем быстрые решения и встраиваем костыли в наш код (конечно же, с намерением вернуться и всё отрефакторить, когда будет время!).

Как только такое быстрое решение поселилось в вашей кодовой базе, оно становится проблемой тимлида, потому что влияет на поддерживаемость и расширяемость сервиса. Задача тимлида сделать так, чтобы все подобные задачи на рефакторинг регулярно попадали в бэклог команды. Иными словами, тимлид должен организовать в команде работу с техническим долгом. В нашей компании принято выделять 20 % спринта на работу с техдолгом, причём эта квота не включает в себя баги и написание тестов такие задачи мы относим к продуктовым.

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

Заключение

В этой статье мы рассмотрели, каким должен быть технический уровень тимлида (должен быть опыт разработки). Также, я рассказал, как тимлид может организовать работу с инженерной культурой, процессами, SLA и качеством. В следующей части мы рассмотрим, пожалуй, самую противоречивую часть работы тимлида работу с бизнесом, так что, как всегда, stay tuned!