Никакой пользы в этой заметке, но однако забавно какой путь в признании проделал слак за эти годы

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

Конечно, слаку непросто выдерживать давление со стороны "халявного" MS Teams (включен в пакет МС услуг все равно)

К вопросу о возвращении в офисы - в этой карикатуре есть большая доля правды.

Если когда-то в офисе наступало время созвона и народ бежал дружно в один конференц рум, то потом даже в офисе народ при приближении созвона также дружно бежал уже в РАЗНЫЕ комнаты. Потому что так удобнее, не нужен гемор с подключением общего микрофона и т.п.

В региональных офисах ИТ гигантов два человека за соседними столами часто работали в разных проектах и командах и обсуждать им друг с другом было нечего.

В офисах вместо больших конференц комнат понадобились много маленьких, на одного человека, чтобы он мог говорить, не мешая остальным.

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

Наверное уже все слышали, про шумное исследование, что 10% инженеров в компаниях (смотрели на выборку в 50 тыс человек) не делают практически ничего.

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

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

А так-то хотя мериться сотнями строк код это дурная практика, но посмотреть на объем созданного кода и подумать про отдельных выдающихся личностей полезно. Для этого даже AI был не нужен. С кем-то приходилось и прощаться после пары разговоров, но это 1%, а не 10%.

https://www.404media.co/are-overemployed-ghost-engineers-making-six-figures-to-do-nothing

Пока все репостят скандал с провели опрос по удовлетворенности и уволили всех неудовлетворенных, попробуем быть на шаг впереди и прочтем, что автор первого поста описывает это как PR ход. Завирусилось знатно, надо признать.

Невозможно, конечно, точно сказать было ли это реально PR ходом или оперативно переиграли.

https://www.snopes.com/fact-check/yes-madam-fired-employees-stress/

Помните смешной текст про то, что все животные делятся на
- принадлежащих Императору;
- набальзамированных;
- прирученных;
- молочных поросят;
...
?
Это Х.Л.Борхес так пошутил, а для нас иллюстрация плохо структурированных категорий.

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

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

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

Чтобы такого было поменьше, лучше делать хорошие категории по принципу MECE, mutually exclusive and collectively exhaustive. То есть одновременно взаимно неперекрывающиеся и совместно полные. То есть мы каждому предмету можем присвоить категорию и ровно одну. Можно конечно сделать подкатегории следующего уровня. Как в биологии - виды/рода/классы/... но на каждом уровне тот же самый принцип.

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

Конечно, есть способы и инструменты передавать сложную информацию - можем рисовать графы, и как между ними перетекают объекты. Люди, которые в этом варятся постоянно даже придумают какие-то собственные метрики и концепции, чтобы с этим жить. Но все-таки простая воронка для приведенного примера проще хитрых графов, все будет понятно в ситуации "должны были позвонить -> планово позвонили", 7 из 9, все понятно.

Наверное, надо в другой раз полнее развернуть про паразитную когнитивную нагрузку

Смотрел, что недавно в confluence выкатили функции встроенных баз данных - очень прикольная штука, но оказалось, что к ним еще не был готов бекап/рестор, что для более-менее крупной организации, конечно стопор для активного использования. Это заставило задуматься еще раз про в каких местах правильно срезать углы, если надо выкатить продукт пораньше.

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

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