Пару лет назад, человек из Wrike написал серию статей про красную корпоративную культуру, причём во второй части буквально в 3 абзацах был весь смысл 4 статей. Было написано очень завуалировано и мягко, я же сегодня распишу, по сути, этот абзац в целую статью на примере крупных игроков российского рынка, в которых я поработал, сравню с малым бизнесом, в котором я работал ранее, а также с гос. структурами (спойлер, отличии с последними – минимальное).
Я не буду таким добрым как автор там, и напишу про многие вещи прямо.
Про Agile человек уже писал, а поскольку я последние лет 6 DevOps инженер, я напишу с нашей колокольни. На habr и на youtube полно статей, видео про DevOps чего в них только не рассказывается, и про стоимость задачи, и про релизы и технологии, и про то, как важно запихнуть Kubernetes на пульт от телевизора и кофемолку. Но везде говорят только про нижнюю часть, забывая про голову. Одна из причин этому – красная корпоративная культура, о которой ранее говорил человек в статьях про Agile. Люди боятся увольнений, боятся гнобления, да и вообще говорить, что бояре плохие моветон.
Ну вот мы и подошли от совсем воды и предыстории к интересному. Любая методология работает только в условиях, когда она работает на ВСЕХ уровнях, но вот беда, уровней много и чем выше уровень, тем меньше интереса работать, тем более становиться частью процесса, там принимают великие решения и сроки, придумывают стратегии развития, ну и естественно получают наркотическое опьянение от собственной важности, если верить 3–4 частям тех статей.
Причём начинается это с первых рабочих дней. Когда к человеку, который не будет иметь никакого отношения к людям, притаскивают hr’ы более 500 человек персонала, пришло правда человек 250–350, но никто из них не будет иметь с ним никаких рабочих связей, он будет общаться только с директорами программ, и программ менеджерами – зачем к нему тащили разрабов, тестеров, админов? Потому что его надо развлекать, средняя ставка людей, списавших время на то, чтобы повеселить дядю – 44 бакса в час вместе с налогами. Итого 1 139 600 рублей компании обошлось повеселить и обрадовать топ менеджера пришествием людей.
Помимо этого, есть разные уровни менеджеров, и каждому уровню необходимо принимать волевые решения. Как говорил СТО Dmitry Simonov, основная задача любого директора – принимать волевые решения. У него есть канал для CTO в телеграмме, кому интересно легко его в поиске найдут.
Проблема в том, что принятие волевых решений несёт в себе ответственность, если ты являешься частью процесса, но это не выгодно, ты тратишь время, работаешь, а в это время твои конкуренты приняли уже несколько решений. Какие только решения я не видел…
Установка устаревшей версии Hadoop на 4 сотни серверов чтобы не ждать 3 месяца рефакторинга кода, а после потерять 3 года разработки, потому что у вас нет нужных фич, сменить 2 команды менеджеров, и в итоге винить разрабов что нельзя сделать изменения в золотую запись…
Отключить основную функциональность в колоночной бд, чтобы решить проблемы с нехваткой железа, а потом обвинить девопсов, что всё так плохо.
Причём каждый менеджмент, почему-то считает, что прошлого менеджмента не существовало, и решал почему-то персонал, но мы такого больше не дадим и будем решать сами…. Для этого мы наймём 4 менеджера на 8 инженеров, год они просидят, естественно на з\п большей чем у тех 8 инженеров, они год просидят, а потом выдадут(высрут) решения. В провале которых будут опять же виноваты инженеры. Ведь решения расписали, красиво обосновали, потратили под пол мульта денег на презу, а вот некомпетентные люди снизу всё испортили.
Контроля, дайте нам больше контроля!!! Когда волевые решения приняты, а с результатом плохо, начинается поиск виновных, и попытки управлять хаосом, любые работы начинают проходить через специальных менеджеров, заводятся таски в джиру с полным написанием изменений, параметров, по сути, дублирование гита, а часто и засовывание в джиру файлов с кодом….
Архитектурные решения принимает менеджер Петя, по релизам менеджер Дима, а по текущим делам менеджер Саша, причём зачастую споры с последним могут занимать половину рабочего времени, а после ещё менеджеру Феде надо будет менеджеру Саше мозги вправлять, чтобы не случилось аварии.
Многие заметят и скажут, а причём тут DevOps? Но смотрите, k8s есть, gitlab есть, разрабы есть, тестеры есть, но вот беда, тут не web а тяжёлая аналитика, начав процесс, тут нельзя его прервать, нельзя сделать откат, да и результат зачастую даже первый идёт спустя 30-40 минут, а от первого результата идёт работа последующих сервисов, и при этом это совершенно не монолит, потому что сервисы работают в изолированных контейнерах, с разными участками работы с фс и бд, алгоритмами, и самих контейнеров более 34000.
Тысячи задач в jira за 2 года (на момент когда я уходил 5000 задача появлялась, напомню всего на 8 человек), доски, дейли митинги, еженедельные, каждые 2 недельные с руководителями, и везде идут волевые решения по исправлению «тяжелейшей ситуации» которая возникла по вине ничего не делающего персонала.
Казалось бы, ну говноконтора, иди ищи другую просто, но проблема в том, что и в другой конторе такого размера, выходят такие же проблемы, потому что над вышеописанными менеджерами, сидят ещё менеджеры, которые вообще не в курсе, а что там снизу, им совершенно плевать, что внизу нехватка оборудования, нехватка персонала, нехватка информации, что именно должна решать эта бизнес фича, они выдали волевое решение, указали сроки, и просто требуют реализации, они уже приняли расходы, их мало волнуют проблемы, если они совсем не приводят к краху, и они не попадают в новости, после этого резко появляется бюджет, но всё, вся работа внизу парализована и превращена в цирк, и никакие доски и контроль не спасают.
А когда не дай бог начинает какое-либо направление сливаться с другим, в этот момент менеджмент сверху принимает решения, и внизу мы получаем совершенный абсурд, начинается смена менеджмента, и опять весь прицел на персонал, сроки горят. Потому что сверху решили, ну что там, ну полгода, ну от силы годик, похожие же сервисы, нанятые манегеры сломя голову бегут скорее принимать волевые решения, начинаются костыли, разработка без проработки архитектуры и переезд на стек основного проекта, и в этот момент мы получаем труп проекта, попытки сделать не совместимые для компании с таким бюджетом paas сервисы внутренние, ротация персонала, все забывают про нужды самого проекта, что потом выливается в большие дыры в бюджете, и полностью не поддерживаемое легаси, но поскольку выше стоящий менеджмент живёт отдельно, он не отвечает за результаты внизу, и вся цепочка разработки ломается, и весь смысл с devops и автоматизации тоже уходит вникуда. Процессы вроде есть, но их цель чтобы люди были «при деле», но не в самом результате.
Гонка без результатов, переработки, выводы и перевыводы сервисов, автоматизация которая бы даже не понадобилась, если бы процесс был полным, а главное, которая уже спустя год не актуальная и поросла кучей мусора, который уже практически никто спустя 1-2 года не понимает... Так выглядит Devops+agile/kanban в enterprise.
Сегодня мы рассмотрели про enterprise. В следующий раз я напишу про малый бизнес и стартапы, и почему там тоже в России методологии не работают.
В 4 статье я подведу все итоги, и объясню, почему ситуация между казалось бы разными мирами – практически идентичная.
