Processes

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

Хорошее ревью:

Статья описывает настройку процессов таким образом, чтобы по минимуму отвлекать разработчиков. Для этого назначается дежурный, который отдувается за всех. Например, у вас есть команда поддержки, которая постоянно дергает разработчиков, когда не может справиться самостоятельно. Можно назначить дежурного — именно этого человека и будут дергать, а он…

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

Сколько раз мы брали задачу в работу, а в середине ее разработки выясняли, что некоторая часть требований не описана, а API, с которым будем интегрироваться в процессе, еще не готов?

В прошлом посте мы разобрали ловушку оптимизма, в которую попадают при попытке оценки нового проекта. Главная причина — Planning Fallacy: когда наш мозг из раза в раз моделирует идеальный сценарий и игнорирует прошлые провалы.

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

Разработка часто страдает от болезни «почти готово». Это состояние, когда код написан, но функциональность еще не выпущена в продакшен, потому что «еще не дописали тесты», «забыли дополнительное условие» или «дизайнер еще не смотрел».

Итак, мы установили, что даже команды, которые состоят из суперзвезд, могут легко провалить все мыслимые и не мыслимые строки.

Довольно часто возникают такие ситуации:

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

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

У мозга есть встроенный лимит: мы можем одновременно держать во внимании примерно 7 объектов. Понимая это ограничение, можно проще писать код, строить архитектуру, управлять командой — и даже планировать день.