SOLID'ный тимлид

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

Общий формат взаимодействия с командами напоминает полиморфизм: заказчику не нужен совершенно новый порядок постановки задачи для каждого API, веб-продукта или мобильного приложения. Аналогия применяется и к ролям. Требования вакансии задают абстракцию разработчика в контексте найма; после выхода на работу важны обязанности и качество результата, а не одинаковые личные привычки при написании кода.

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

Принцип открытости и закрытости связывается с матрицами компетенций: уровни различаются выполняемой работой, технической сложностью и неопределённостью. Подстановка Лисков проявляет неоднозначность названий должностей. Архитектор, выросший из разработки, и архитектор из системного анализа могут обладать разными навыками; одинаковая должность не делает их взаимозаменяемыми. Различение software- и solution-архитектуры помогает уточнить ожидаемые обязанности и не подменять их красивым названием.

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

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