Саша пишет про процессы, как всегда очень круто, имхо

Про творческий беспорядок в процессах

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

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

1. Максимум делегирования

Тимлид, как и любой другой член команды, которого в команде всего одна штука - это самый первый кандидат на бутылочное горлышко и single point of failure. Поэтому его ключевая задача - всю работу скидывать с себя на кого-то другого. Этакий вариант поговорки "работа-работа, перейди на Федота". Load balancer от мира команд.

2. Замкнутые ответственности

Доведенное до максимума делегирование подразумевает, в том числе, делегирование и уже традиционно лидерских задач. А именно - самостоятельная расстановка приоритетов по задачам и самостоятельный контроль прода во всех смыслах. В идеале: в продуктовом и инфраструктурном смыслах тоже.

3. Минимум координационного взаимодействия

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

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

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

4. Минимум процессов

Я в своей жизни насмотрелся на процессы ради процессов: дейлики, ретро, планирования. Обязательно списывайтесь, обязательно двигайте таску по трекеру, обязательно через ветку, через 2 ревью, 0 замечаний в сонаре, 80% покрытия, написать вики. Все обязательно. Человеко-дни работы команды сгорают каждую неделю на очень логичную и зачастую очень малополезную туфту.

Поэтому процессы у нас всегда строились так: если ничего не болит, то и процесса не надо. Если что-то болит, давайте найдём подходящий инструмент. Не достаёт коммуникации - давайте введем регулярные синки. Не хватает ревью кому-то - сажаем ему в пару человека. Ну и так далее. Чем меньше процесса, чем меньше людей в нём людей, тем лучше.

5. Доверие

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

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

6. Самоорганизация

Я в банке часто слышал вопрос-упрёк от нашего аналитика: "Я не понимаю границы своей ответственности, что конкретно от меня ожидают?!"

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

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

Результат

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

Про подводные камни

Ну и, как обещал, давайте разберём очевидные вопросы, которые у вас 100% возникли.

1. Максимум делегирования

Первый очевидный вопрос: если лид все делегировал, какова роль лидера в такой команде?

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

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

2. Замкнутые ответственности

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

3. Минимум координационного взаимодействия

Режим одиночки имеет 3 основных ограничения и, соответственно, возражения:

- Bus factor. Человек ушёл в отпуск - продукт стоит. Человек уволился - продукт сильно просел. Решается просто - всегда должен быть запасной человек, который либо работает вместе на продукте, либо когда-то на нём работал.

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

- Некоторые продукты заколебешься делать в одного - нужна куда большая пропускная способность. Порой это даже десятки и сотни человек, да? Да, но можно ли разделить их работу на небольшие независящие друг от друга подпродукты, которые могут делать 1-2 человека? Почти всегда - да.

4. Минимум процессов

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

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

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

5. Доверие.

Как довериться человеку, которого только нанял? Может, он балду пинает. К тому же, если ты его только что нанял, то он точно ещё долго будет въезжать, прежде чем станет действительно самостоятельным.

Ответ: нельзя довериться. Доверие нужно заслужить. Просто для этого надо не так много: дать ментора и чуть-чуть времени на вход. Уже довольно скоро будет видно, можно ли доверять или нет.

Что делать, если нельзя? В идеале - поговорить честно и разойтись по-хорошему. В реальности часто: оставить вечным подопечным на второстепенных ролях у кого-то, кто тащит.

6. Самоорганизация.

Как можно работать в процессах, где у тебя нет чётко сформированной ответственности? Ведь, тебя, получается, могут спросить вообще за все, что угодно?

Привет!

Я жив и даже что-то делаю по ЭП и ErgocodeAi, но пока окончательно распихать всю толпу своих любых детей по садам и няням не выходит, поэтому на канал и блог времени ещё нет.

Поэтому вот вам мемасик на злобу дня:)

Prompt
by Christoph Niemann

Хорошей тебе недели!

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

Во многом мы с автором сходимся, но расходимся в условиях (у него есть та самая сложная бизнес-логика, которой у меня нет) и предпочтениях (он нашёл своё счастье в ООП и богатой доменной модели, в отличие от меня).

Блин. Я дочитал. И тотально разочаровался. Автор просто придумал JPA/Hibernate/NHibernate на ручной тяге поверх EntityFramework и передачу списка вообще всех репозов в методы сущностей/агрегатов/бизнес-логики. По сути, книга о том, как сделать производительность большого императивного кома грязи сносной, если ты хочешь остаться в ОО, но не знаешь про хибер. Не рекомендую к прочтению.

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

Собственно отрывок из черновика статьи Модель неизменяемых реляционных данных с чуть более подробным описанием идеи:

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

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

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

PS>

Вот и пиши после этого книги, чтобы аноны в интернетах их обсирали 🤦‍♂️🤣

Не, ну кстати, справедливости ради, есть у автора одна любопытная идея.

Чтобы защитить инварианты сущности, автор предлагает делать конструктор приватным, я для создания экземпляров делать внутренний интерфейс, у которого есть протектед метод, который делегирует вызов в конструктор:

public class Client
{
    public interface IRepository : IBaseRepository<Client>
    {
        protected static Client Restore(
            Guid id, string name, string address, Conditions condition)
            => new(id, name, address, condition);
    }

    private Client(
        Guid id, string name, string address, Conditions condition)
    {
        // ...
    }
}

В оригинальном виде, правда, это половинчатое решение - этот интерфейс может реализовать кто угодно и создать сущность без проверки инвариантов. И в шарпе (по словам гопатыча), нет возможности это как-то залечить. Зато в Котлине есть.

interface можно сделать sealed и тогда его реализовать можно будет только в той же директории.
Правда в котлине нельзя сделать протектед метод в интерфейсе, но можно сделать sealed класс.

В итоге получается такая конструкция:

// в файле my_app.clients.Client.kt

class Client private constructor(
    val id: UUID,
    val name: String,
) {
    sealed class Repository {
        protected fun restore(id: UUID, name: String) =
            Client(id, name)
    }
}

// в файле my_app.clients.ClientRepository.kt

class ClientRepository : Client.Repository() {
    fun restoreFromDb(id: UUID, name: String) =
        restore(id, name)
}

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

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

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

#kotlin@ergonomic_code