Про эффективные коллективы в IT ч.2

Начало тут.

Итак, мы выяснили, что эффективный коллектив — это не сумма эффективных одиночек.

А эффективный коллектив - это какой? Ну, например, устойчивый, или "антихрупкий", если по Талебу. Пусть это будет первое свойство эффективного коллектива.

А в чём устойчивость выражается? Например, в стойкости к различным проблемкам и форс-мажорам. Кто-то попал под трамвай/уволился/умер. Ну ладно, в отпуск ушёл. Или в декрет. Коллектив способен адаптироваться к этой потере?

У вас бывало, что какой-нибудь Петя ушёл в отпуск, а без него никто ничего не знает? Нет, речь не про принятие каких-то решений, за которые потом с Пети спросят. Допустим, ничего "решать" не надо: надо знать, что и как надо делать, кому написать, что спросить, и т.д. — и это надо сейчас, а не когда он вернётся.

В случае с Петей скорее всего случилось излишнее сосредоточение экспертизы, На проф.сленге это ещё называется "низкий bus-factor". Штош, придётся кому-то подключаться, разбираться. В плохих случаях придётся вызванивать, напрягать отдыхающего (уже нет) Петю. Ещё ладно, если он просто в отпуске.

Лирическое отступление: а если Петя это директор/вождь/президент/царь? И он ушёл не в отпуск, а на тот свет (или ему помогли)? Именно поэтому коллективы вождистского типа часто плохо заканчивают. Самая жесть, когда при этом нет цели/стратегии/идеологии, т.е. какой-то системы координат и ценностей. "Что вождь сказал — то и цель". Ну и нет системы, которая может самовоспроизводиться.

Для достижения большей устойчивости есть всякие, порой очень частные меры. Но есть и общие практики, которые на это направлены — в IT, не в IT, здесь будем про IT писать.

1. Документация разных видов — начнём с банального. Актуальная и доступная. Всё непонятное в документации должно стать понятным — не для того, кто её написал, а того, кто её будет читать. У нас цель, чтобы именно остальные смогли разобраться, и Пете будет легче отдыхаться в своём отпуске.

2. Код-ревью. Ну это база, конечно. Хотя первоначальная задача у код-ревью была в валидации выпускаемого материала, но через этот процесс достигается и обмен знаниями о проекте — то что нам надо.

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

А ещё можно сделать комбо из пунктов 1 и 3. Задачу на написание документации дать чуваку, который не в теме. Хочешь разобраться в вопросе -- напиши доку. Помимо повышения устойчивости коллектива мы зачастую получаем ещё и проф.рост и развитие этого чувака. Знаю по себе, это бывает очень эффективно и весело (но только не сначала — сначала скорее всего будет грустно).

Продолжение следует.

Больше мыслей на эту тему, и не только, есть в моём телеграм-канале. Это не тематический ресурс: он не про работу, не про бизнес, он про всё, о чём я думаю. Спасибо за внимание!