миллион лет назад делал доклад про PDR , и до сих пор считаю, что любая добавляемая сложность в процессы труда должна быть обоснована не хуже, чем добавление сложности в техническую систему.
инженер не добавляет (я надеюсь) условную кафку просто потому что “кафка это ништяк”, но почему-то этот же инженер становится тимлидом или того хуже СТО и спокойно накидывает в процессы труда всё, что где-то ему казалось прикольным.
вослед за ув. тов. Аланом Холубом хочу собрать набор приемлемых “defaults” для процессов труда.
Начну, наверное, с асинхронности.
Мне видится, что синхронный труд — то есть, mob work — стоит рассматривать как дефолтный, и асинхронность — то есть “декомпозиция” задачи для “разбиения” по отдельным разработчикам — добавляться только после обоснования необходимости.
Ровно так же, кажется, в программирование синхронность — default, и добавление любой асинхронщины мы стараемся обосновывать так, чтоб выгоды было больше, чем сопутствующей цены обслуживания увеличенной сложности.
Upd:
в программировании различие между синхронщиной и асинхронщиной всем вроде известно и понятно, а вот в работе буквально сихнронно это “взяли и сделали все вместе”, а асинхронно это “‘декомпозировали’ задачу, ‘раскидали по людям’, а потом начали играть в пинг-понг со статусами и тикетами в джире”
>>Click here to continue<<
