(ты это построил, ты это и эксплуатируй!). В курсе «Системная инженерия» дано достаточно литературы по DevOps, где обсуждается этот принцип. Как раз DevOps (в менеджменте администраторы) были отделены для того, чтобы разработчики (в менеджменте организаторы) могли и проектировать, и воплощать организацию и далее быть её эксплуатационными операторами. Главное тут в том, что убирается вечная война между создателями системы и её операторами: одна и та же роль (можно обсуждать, как она дальше делится между оргзвеньями) и проектирует, и создаёт, и проводит эксплуатацию системы, а DevOps обеспечивают для этого «внутреннюю инфраструктуру разработки, internal development platform».
Роли, должности, организационные статусы
Главное, что нужно помнить, когда разбираетесь с устройством какой-то организации – не надо честно верить всем произносимым разными людьми словам, всем табличкам на дверях. Помним высказывание Козьмы Пруткова: «Если на клетке слона прочтешь надпись: „буйвол“, – не верь глазам своим». Люди вроде бы называются «на слух» понятно и можно вроде ожидать от них выполнения каких-то понятных из их названия работ, но это не так:
• Работа может выполняться не человеком-начальником, а его подчинённым («я это выполню» может означать «мой сотрудник Петя это сделает»), поэтому разговаривать о деталях дела надо не с начальником, а с подчинённым. С начальником надо договариваться о координационных актах (поручения, обещания, информирование о моменте выполнения обещания, подтверждение приёмки работы как выполнения вашего обещания её сделать, и т.д.). Мы называем «начальником» человека с ролевым аспектом распоряжения трудом и ресурсами.
• Должности часто называются по ведущей роли, но это не обязательно. Есть штатное расписание, и там будет какой-нибудь «специалист второй категории» как должность (организационное место), на этой должности может находиться человек с самым разным мастерством, выполняющий самые разные роли. И даже начальник, который распоряжается его трудом, у него может оказаться не тот, который записан в штатном расписании. Это «схема»: штатное расписание нужно только для того, чтобы «официально» выписывать человеку зарплату, а реальное положение дел закреплено устными договорённостями.
• Ведущая роль обозвана неправильно. Когда вам представляют какого-нибудь «аналитика», то это может быть или и впрямь аналитик (который ничего не решает сам, а только «понимает», о чём пишет аналитические отчёты), но может быть и вполне инженер (который решает всё сам, ибо это входит в признаваемые остальными членами команды полномочия). А как же он может принимать решения на такой должности? Очень просто: он «серый кардинал», его полномочия нигде не прописаны, но он имеет большое влияние. В его вроде как «пониманиях» будут «рекомендации», представляющие собой инженерные решения. Вокруг таких «аналитиков» постоянные конфузы, это «скользкая должность»: кто-то обращает внимание на должность и общается не как с полномочным инженером, а как с аналитиком, который не полномочен ничего решать (а он полномочен, но неформально), а кто-то обращается как с полномочным, но неожиданно в критический момент такой «аналитик» говорит, что он всего-навсего аналитик, и пусть кто-то другой из начальства принимает решение, а он тут просто «дал рекомендации». Инженеры принимают решения, а не дают рекомендации по этим решениям. И несут ответственность за решения. Ответственность аналитиков обычно даже не обсуждается. Поэтому