Организационный аспект автоматизации

[elglin]

Есть три факта, которые вроде как подтверждены наукой психологией.
1. Оптимальный размер низового подразделения - это малая группа. "Семь плюс-минус два" по учебнику Г.М. Андреевой, или же 5-9 человек.
2. Оптимальное число подчиненности для не нижнего и не верхнего уровня - 3. От 2 до 4 съедобно.
3. Максимальное число контактов, которые может поддерживать человек - около 150. Примерно рота. Зависит от человека, конечно, то есть 130-170, но ориентироваться надо на 150.

Так вот, это даже научно подтверждает, что чем меньше организация, тем быстрее в ней все проворачивается. Те же пресловутые малочисленные стартапы практически лишены организационного трения.
В громадной куче организаций все эти красивые рассуждения неприменимы потому, что нужно много подносчиков патронов, сиречь не особо квалифицированной рабсилы, для которой тем не менее дофига работы. Так вот, нынче все более это заменяется автоматикой, роботами и био-роботами.
А вот в айтишном контексте все интересно. Сейчас пара-тройка человек может спокойно рулить хорошо отстроенным хозяйством конторы, ворочающей реальным баблом. При этом с перерывом на пиццу и поспать. ИТ-отделы уже сдуваются, и еще будут сдуваться.
И, внезапно, группа поддержки из 7-8 человек сеньоров с одним тимлидом несмотря на свои космические (хотя не настолько уж) зарплаты может оказаться дешевле классического сектора поддержки человек на 20 с манагером, проджектом и 3-4 тимлидами - каковой сектор наполовину набит джунами подай-принеси. Реально может оказаться, что нанять условного Гинденбурга за 100500 голды выгоднее, чем обходиться Козловыми.
А это означает, что вскорости из уютных кресел начнут лететь тимлиды с ИТ-манагерами, "не вписавшиеся в рынок". Потому как сокращение ИТ-штатов, размененное на удорожание специалиста, срежет один уровень подчиненности, а это, по опыту, изрядно поднимает эффективность.
Так что даже "уход вверх по карьерной лестнице" уже ничего не гарантирует.

Comments

[beldmit]

Вообще у меня ощущение, что это будет ломаться при турбулентности типа умерших железок...

[scif_yar]

Уже. Уже отделы ИТ реально крцпных лавок - 2-3 человека на текущей операционной деятельности и он-колл интегратор и саппорт вендора. все.
Я так скажу, в моих двух бывших работах, 1500 - 2000 человек, весь "ойти" отдел, включая кусок бизнесового (и не включая одинце) - 2 на виртуализации и СХД, два на винде и бекапе (с пересечением задач), и парочка на "прочем около бизнесе". И пользовательский саппорт 4 человека.
Меньше сдуваться просто некуда, потому что есть отпуска и болезни.
Хотя нет - в старой конторе (интегратор) парни на отдел рулят 3-4 конторами по факту.

[elglin]

Да не особо. В конкретном сценарии умерших железок у тебя есть, как минимум, два варианта:
1) У тебя облако и железок нет вообще - тогда от многих турбулентностей тебя спасет какой-нибудь deploy.sh или deploy.py, который переразвернет хозяйство взамен попадавшего.
2) У тебя дофига железа и проблема умерших железок не твоя, а вендора, чей инженер, с вероятием, днюет и ночует на твоей площадке.
В более общем сценарии... ты знаешь, я видел своими глазами, изнутри, как выглядит падение датацентра по питанию. Львиная доля приложух чихнула, прокашлялась и продолжила работать, во многих случаях вообще без участия оператора.

[beldmit]

С утра я готов это формулировать немного по-другому.

С одной стороны есть объём текущей работы, которая в норме конечна, и на ней есть соблазн резать косты.

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

[elglin]

С форс-мажорами сейчас начинают "бороться" путем концепта максимальной проектной аварии. То есть мы гарантируем вот в таком и таком случае, что мы разберемся быстро, а если долбануло все совсем... ну запроектная авария, извиняйте, ничего не гарантируем.
К примеру: "если в Амазоне упала одна AZ, то мы выдерживаем с некоторой просадкой, если в Амазоне упал регион, то мы за ХХ часов можем передеплоиться в другой, а вот если упал весь Амазон, то мы просто разводим руками и обновляем резюме".
Касательно внезапной смертности и пресловутого bus factor - это, как раз обуславливает некую минимальную численность отдела, ниже которой ни уволиться, ни в отпуск уйти. Но сейчас много где отделы изрядно раздуты, и идея изначального поста в том, что если сдуть их до разумного минимума, то много где это срежет уровень иерархии, что начнет отправлять на рынок труда тимлидов и манагеров.

[scif_yar]

>>У тебя дофига железа и проблема умерших железок не твоя, а вендора, чей инженер, с вероятием, днюет и ночует на твоей площадке
-
Это проблема вообще не твоя и не вендора.
Дежурная смена ЦОД получает извещение по мониторингу, пишет письмо вендору или идет на склад, далее по регламенту, завела работы, выдернула-вставила, проверила.
Схема оповещения и эскалации простроена и пофикшена.
На М9 человек 5 чтоли смены, и кстати по моему именно они и падали тут по питанию.
Или не они, в салатовом чате кажется был разговор.

[beldmit]

А оно точно срежет этот уровень иерархии сверху, а не снизу? Для мелких контор скорее снизу, для средних скорее равномерно.

[elglin]

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

[beldmit]

Это запросто, да.