Пару лет назад, человек из 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 статье я подведу все итоги, и объясню, почему ситуация между казалось бы разными мирами – практически идентичная.
Комментарии (85)
caballero
09.01.2022 20:20+26оно нигде не работает. просто модные тренды. в айти периодически возникает нечто претендующее на "серебряную пулю" с чем все какое то время носятся как с писаной торбой - devops, agile,Nosql, Goland,микросервисы,"продуктовость" и так далее. пули естественно не получается и "нечто" занимают ту скромную нишу где оно худо бедно раотает
Guzergus
09.01.2022 21:11+15devops
На моей практике вполне себе работает, если говорить о таких вещах как IaC, CI/CD.agile
Тоже работает. Не идеально, но есть проекты, где такие подходы разумнее, чем традиционный waterfall.Nosql
Работают, разве что следует умерить ожидания и сразу понимать, что скорость и другие качества таких баз достигаются не магией, а жертвами в других областях.микросервисы
Тоже работают, но, опять таки, требуют рационального и прагматичного подхода i.e. distributed monolith в десятки раз хуже обычного.
Короче говоря, не совсем понял, что вы понимаете под «оно нигде не работает». Некий оттенок хайпа и трендов — да, это я замечал и в целом согласен, но не считаю это inherent проблемой описанных подходов. Более того, удачное их применение выигрывает по сравнению с альтернативами.
tetelevm
10.01.2022 13:04+3Работает-то всё из этого, просто в каждом из этих вещей есть "..., если применять с мозгами там, где оно требуется". А проблема всех новшеств в айти - слишком много хайпа и подачи, будто именно это новое решение есть панацея всей разработки.
Guzergus
10.01.2022 13:09А проблема всех новшеств в айти — слишком много хайпа и подачи, будто именно это новое решение есть панацея всей разработки
Не назвал бы это проблемой новшеств. Если быть точным — это не проблема технологий, а проблема скорее культуры.
Paskin
09.01.2022 21:57+8Лет много назад мы с товарищем собирали митапы архитекторов - благо компания, где я тогда работал, с удовольствием предоставляла под это помещение и плюшки с кофе. На один из них пришел мужик в возрасте, сел недалеко от сцены и смеялся практически всю первую часть дискуссии. В перерыве я его нашел и спросил о причине веселья. Тот ответил что те же самые проблемы, над которыми бьются лучшие умы IT - в телекоме решили еще в 70х. Например - зачем нужна "очередь запросов", если запросы гораздо логичнее класть в стек. Признаться, у меня не нашлось хорошего ответа.
По поводу Аджайла и прочего NOSQL - это работает только там, где не делают из него религию.
sergeyns
09.01.2022 22:54+3зачем нужна "очередь запросов", если запросы гораздо логичнее класть в стек
А вот тут возникают вопросы что он подразумевает под "стеком", где он хранится и что будет если выключат электричество.. Опять же, если под "очередью" подразумевается некая структура на сервере приложений - это одно, если в самой БД сделана некая "табличка" - это другое, а если у вас есть какой-нибудь менеджер очередей типа IBM MQ поверх которого работает брокер сообщений, который рулит запросами от кучи клиентов - то это совсем третье...
Paskin
10.01.2022 00:36+2Речь шла об архитектуре - вам приходят запросы, вы их где-то сохраняете и по мере сил обрабатываете. Почему в принципе следующий запрос на обработку должен браться из "хвоста" очереди, а не из ее "головы", как все обычно делают? А как именно очередь имплементирована - здесь значения не имеет, есть какой-то интерфейс и все.
aftertherainbow
10.01.2022 07:10+5Так многое зависит от задачи, я тоже не понял, чем этот мужик так вас зацепил. Очередь часто используется потому, что в событийных архитектурах важно обрабатывать события в порядке поступления.
Условно говоря, если вы отправляете два смс подряд, то хотелось бы, чтобы то, что вы отправили раньше, раньше и пришло.
Paskin
10.01.2022 08:38+4SMSC совсем не гарантирует передачу SMS в оригинальной последовательности - и если, например, какое-то длинное OTA сообщение делится на части - правильная их "сборка" обратно это проблема телефона (в формате, разумеется, есть поля "номера части" и "всего частей").
TCP-пакеты в разветвленной IP сети тоже приходят (если приходят) "как попало"...
Насчет мужика - это называется Design for Failure (хотя тогда еще таких слов не знали). На пиках нагрузки вы можете не успевать обрабатывать все запросы до того у клиента закончится таймаут и он пошлет тот же запрос еще раз (нажмет "refresh" в браузере). Очень возможна ситуация, когда вы 100% заняты обработкой запросов, ответов на которые уже никто не ждет - а клиенты шлют все новые и новые, не получая ответа. Поэтому, лучше брать запросы из "хвоста" очереди - тогда получившие ответ перестанут вас "DDoS-ить".
По поводу "событийных архитектур" - обработка в порядке поступления это далеко не самая лучшая идея. Если бы, например, банковские и платежные системы так работали - все бы было довольно печально.aftertherainbow
10.01.2022 09:21+1Мы с вами на разных уровнях абстракции. Я имел ввиду что-то ближе к современным месенджерам вроде WhatsApp'а, где сообщения показываются в порядке получения.
Если ваш сервер не успевает обрабатывать запросы, то стек это явно не решение проблемы. Вы точно также будете не успевать обрабатывать сообщения из стека. Проблема с сообщениями, на которые никто уже не ждёт ответа решается временем жизни таких сообщений.
Вы поправьте меня, но ваш тезис выглядит со стороны как 'везде, где используются очереди, можно использовать стек, и стек гораздо лучше'.
Paskin
10.01.2022 09:39+3Сообщения "показываются" != "приходят". Ничто не мешает включить время в формат сообщений и расставлять их в нужном порядке на клиенте (я более чем уверен, что так и делается).
У траффика есть пики и провалы - резервировать мощность выше пиков может быть очень дорого.
Borz
10.01.2022 10:48+1Ничто не мешает включить время в формат сообщений и расставлять их в нужном порядке на клиенте
То есть, пришло мне десяток сообщений с временной меткой около "09:50", я их прочитал и даже ответить успел, а тут до меня только дошло (по разным причинам) сообщение с меткой "09:49" и встало выше того десятка как непрочитанное.
ArsenAbakarov
10.01.2022 11:45+1Я офигел, но именно так делал скайп год назад в веб версии (сайчас не знаю). В общении с коллегами я был идиотом и только скринами смог показать в чем было дело.
Paskin
10.01.2022 12:00Это именно так и работает для разных чатов (для одного - не замечал). Если у вас есть, например, часы куда приходят оповещения - можете сильно удивиться...
SergeyMax
10.01.2022 10:58Сообщения "показываются" != "приходят". Ничто не мешает включить время в формат сообщений и расставлять их в нужном порядке на клиенте (я более чем уверен, что так и делается).
Ну то есть без какого-то осмысленного технического обоснования заменили очередь на стек, а теперь всем остальным нужно лепить костыли, чтобы это заработало. Отличный план.
Paskin
10.01.2022 12:02+1Это не "костыли" - это изначально так задумано и работает. Потому что поддержание консистентности в сильно распределенной системе - очень дорого и часто просто не нужно, а то и мешает.
ApeCoder
10.01.2022 07:13+1Чтобы порядок сохранялся? Если там запрос на создание документа, потом на его модификацию, например, если очередь то они так и обработабтся, а если стек, то надо сначала модифицировать потом создать. А как?
Paskin
10.01.2022 08:51+1Смотрите шире - в масштабах всей системы, а не отдельной сессии. Допустим, случился пик нагрузки - и запросы стали задерживаться какое-то время в очереди (если нагрузка мала - то алгоритм работы с очередью не имеет значения, она будет пуста). Ваш клиент пошлет "запрос на создание документа", у него истечет таймаут и что он сделает - пошлет еще один.
В результате - вы у себя видите что все ОК и запросы обрабатываются в максимально возможном количестве - а с точки зрения клиентов, сервис "в дауне".
Поэтому, даже если это не совсем честно по отношению к "ветеранам очереди" - лучше сразу удовлетворить самых "свежих" клиентов и постепенно "разгрести" оставшихся.Dmitriy_Volkov
10.01.2022 10:27+3Если смотреть шире, то и для очереди и для стека есть места, где они оптимальны. Спор по сути о том, что лучше вилка или ложка
ApeCoder
10.01.2022 11:49+5Изначальный посыл - вы едите вилкой хехе, а мы давно едим ложкой. Вот, возьмем, например, суп.
Метарассуждение:
Обычно, когда все делают X, потом приходит дедок и говорит "Вы дураки и не лечитесь, а надо делать Y" вариантов несколько:Дедок самый умный, а весь остальной мир - тупые. Это самый маловероятный вариант. Даже Эйнштейн не отменил Ньютона - релятивистскую поправку при сложении скоростей почти никто не использует
Дедок занимается какой-то узкой нишей и него оправдано Y. Понять, что у других по другому, он не осиливает. Иногда эта узкая ниша потихоньку разрастается и теснит другие (ну или быстро), но обычно для X всегда остается место
Дедок - Кулибин, он придумал Y и он захвачен идеей. Смотрите! Это Я! Я! приудумал! Обычно он не удосуживается изучением существующих способов сделать то же самое и закрывает глаза на какие-то аспекты реальности (а то получится, что идея не такая уж иновая и уже кем-то опробована, но не подошла).
Paskin
10.01.2022 12:11+3Изначальный посыл - ребенок, только что научившийся орудовать ложкой и страшно гордый собой - не подозревает что бывают еще вилки и ножи десятка видов, а еще суп можно пить из чашки.
Paskin
10.01.2022 12:05+1и для очереди и для стека есть места, где они оптимальны
Разумеется. Пример был о том, что "оптимальность" может быть довольно неочевидной, и ее уже нашли много лет назад.
BobArctor
10.01.2022 12:09+3До телекомов эти же проблемы решали в эпоху индустриализации, но с реальными товарами, железом, станками и углём, а не с абстрактными цифроывми данными.
KGeist
09.01.2022 22:20>Goland
А что не так с этой замечательной IDE от JetBrains?
tendium
10.01.2022 00:09Она не умеет дебагать сервисы в K8s так, как это можно делать в VSCode с помощью Bridge to Kubernetes. Приходится извращаться — запускать VSCode, там создавать туннель из кластера в локальное окружение, потом переходить в Goland и там уже дебагать. Обидно, что в бесплатной IDE можно комфортнее работать, чем в платной.
VitalySh
10.01.2022 02:37В Goland можно настроить запуск произвольной команды перед стартом дебага, а именно запуск kubectl port forward, да и всё. Если не нравится cli, попробуйте Lens. Через него очень удобно прокидывать порты, не залезая в консоль.
А ещё есть telepresence, или если эти варианты не угодили.
tendium
10.01.2022 10:48port forward не подходит — мне нужно не в k8s дебагать сервис, а запускать его локально и перенаправлять трафик из кластера на мой localhost.
Дебагать в кластере с помощью dlv я пробовал, работает, но пересборка и деплой нового бинарника занимают непозволительно долгое время. Кроме того требуются манипуляции с настройками деплоя, т.к. по умолчанию инстансов пода в кластере может быть несколько, и никогда не знаешь, куда прилетит коннект (я уж не говорю о том, что для удаленного деплоя мне нужно наши деплой скрипты патчить).
Телепрезенс мог бы быть альтернативой, но он у меня не завёлся. Во-первых, трафик перенаправлялся на локальный инстанс только непродолжительное время, а потом переставал. Во-вторых, сам телепрезенс периодически не мог определить, что он установлен в кластере, и даже не мог удалить сам себя. В общем, штука крайне ненадежная оказалась. Кроме того, его манипуляции с кластером гораздо сложнее, чем то, что делает Bridge to Kubernetes.
Но так или иначе, использовать ли VSCode + Bridge или Telepresence — не так важно, важно, что Goland не поддерживает фичу даже с плагинами, чтобы не нужно было запускать стороннее приложение. И, похоже, что это даже не стоит в приоритетах разработчика. У разработчиков бриджа есть в Roadmap поддержка Intellij, но когда это случится — неизвестно. В худшем случае никогда ;)
pupsegadm
11.01.2022 20:56+1Устал отговаривать бездумно впихивать все подряд в докер.
"Нет! Контейнеры - это модно!" отвечают мне.
ky0
09.01.2022 20:22+24«Почему в России DevOps и Agile не работают, а статьи перед публикацией не вычитываются?»
passing1by Автор
09.01.2022 20:26-3Скорее я человек с 2 по русскому, которому ставили 3, чтобы не парится))))
ky0
09.01.2022 20:29+35Ну, смотрите.
Статья — это результат оформившегося желания рассказать о чём-то миру. Так уж исторически сложилось, что текстовый формат, в отличие от аудиовизуального (подкасты, видеоролики), подразумевает структурированность и соответствие нормам языка, на котором написан текст — в противном случае его просто-напросто неприятно читать, примерно как и слушать бесконечные «эмммм», «вот», «как бы» и другие слова-паразиты.
Не то чтобы я вас в чём-то обвинял (сам не без греха), просто в моём мире «свидетелей рунета первой волны» — это демонстрация неуважения к читателям.
SergeyMax
09.01.2022 20:33+10Скорее я человек с 2 по русскому, которому ставили 3, чтобы не парится))))
Ну хоть здесь не менеджеры виноваты)
Shaz
09.01.2022 20:36+22Как не виноваты? "Искусственно завысили показатели, для предоставления верхам красивой отчётности". А страдает теперь Хабр.
burz_ex
11.01.2022 22:59+1Но ведь преподаватель суть исполнитель, т.е. в данном контексте скорее инженер, чем менеджер.
Так что, внезапно, виноваты не менеджеры)
vkni
09.01.2022 23:00+1Скорее по литературе. В след. раз, пожалуйста, напишите где-нибудь план статьи - сразу лучше будет, на порядок.
barloc
09.01.2022 21:21+6Начал читать, понимаю что похоже на хрыча. И надо же, это хрыч.
Заголовок к статье отношения не имеет, а этот плач уже выбился за пределы телеграм чатов и достиг хабра.
mSnus
09.01.2022 21:48+131) это проблема не только DevOps / Agile, это общая проблема бизнеса. Кратко: с менеджерами всё плохо.
Хороших менеджеров, которые умеют разруливать организационные проблемы -- очень мало, ещё меньше, чем хороших программистов. И у программистов хотя бы есть какое-то решение по уровням jun / mid / sr, а у менеджеров нет. Поэтому хорошие с средними и начинающими сидят на одних должностях и зарплатах, пока не уйдут на другие должности.
Плюс в России лет 20 подряд всеми вузами страны выпускали толпы совершенно бестолковых менеджеров, которые не умели вообще ничего - на уровне ПТУшников. Это ещё сильнее усугубляет общую проблему.
В общем, за всё время работы из тысячи менеджеров, что я видел, хорошими реально были 2-3. Остальные вообще не думали, потому что не умели. И созданные ими проблемы расхлёбывали специалисты всех уровней.
2) В России есть особая культура целования задницы клиента. Я слышал, что она развита и в некоторых других странах, от Франции до Японии, но сам не сталкивался, поэтому мне сложно сравнивать. А в России если денежный клиент капризничает - вся фирма должна лечь под него и облизывать, пока тот не успокоится.
Потому что менеджер, прослойка между клиентом и исполнителем, прогибается во все удобные позы, лишь бы не сказать клиенту "нет". И вслед за ним эти движения повторяет вся фирма. Если клиент внутренний, например, мелкий босс, то всё точно так же -- дурное настроение босса или его дебильные решения расхлёбывают все, потому что никогда промежуточные звенья не будут ему перечить. Все трясутся за свои рабочие места, премии, кабинеты и общую благосклонность.
А боссы, часто очень неглупые люди, привыкают к тому, что у них не просто компания, а "5-звёздочное обслуживание", и прощают менеджерам из постоянные косяки. Зато ими так приятно руководить! Сотни раз сталкивался с такими ситуациями, и всего несколько раз слышал, чтобы кто-то набирался смелости возражать Главному. Даже если это контора из 30 человек, и босс - большая лягушка в мелкой лужице..
vkni
09.01.2022 23:02+2Я слышал, что она развита и в некоторых других странах, от Франции до Японии
"Не только лишь всех", да. Понимаете, людям тяжело слать начальника с гениальными идеями на 3 буквы, если от него напрямую зависит зарплата. С этим пытаются бороться, типа зарплату назначает начальник начальника, как относительно независимый человек. Но результат всё равно ещё тот.
StupidMouse
10.01.2022 08:36+2А в России если денежный клиент капризничает - вся фирма должна лечь под него и облизывать, пока тот не успокоится.
Было такое, длилось пока клиент не покинул рынок в результате банкротства. Облизывание дошло до того, что некоторые фичи пилились в тесном сотрудничестве с исполнителями клиента, без должного документирования и т.д., из рук в руки так сказать. Долгие годы после банкротства этого клиента ещё всплывали вопросы о существовании фич в проекте, смысл которых никто не мог объяснить толком. Очень забавно выглядит контора не способная ответить уже новым клиентам, на вопросы о функционале в своем же продукте, на которые те случайно наткнулись.
p0st
10.01.2022 09:40+3Дополню от лица менеджера историей из жизни - разместил своё резюме в соц. сетях, пришли бывшие коллеги из одной крупной еком компании, где я работал 3 года назад с плачем Ярославны, что всё плохо и проспали все полимеры. При этом коллеги, ведущие разрабы, архитекторы и консультанты. Возвращайся мальчик с нами, будешь нашим королём! (с).
Удивился, меня никогда не хантили архитекторы и разработчики, ладно интересно, чего там сейчас и как. Выслал резюме, сказал сколько хочу сейчас денег и предупредил, что сомневаюсь, что они столько предложат, т.к. 3 года назад ушёл потому что компания перестала быть в рынке по зарплатам.
Через 2 дня позвонил лид менеджеров и уже не из ИТ. Как и предполагалось, предложили в 2.5 раза ниже рынка, на проекты и продукты, которые находятся в перманентном огне и говне (за год на одном из них сменилось 8 менеджеров).
Весело посмеялся, пожелал удачи и хорошего настроения и для понимания, рассказал, как на такой же продукт нанимал человека на ЗП в 2 раза больше с функционалом в 2 раза меньше, но реальной экспертизой.
panzerfaust
09.01.2022 22:08+2Дискутируя с заголовком, а не с содержанием, замечу, что и девопс и гибкие методологии разработки работают - но только если к ним прийти эволюционным путем. Нельзя просто взять за шиворот команду, работающую по лекалам прошлого века, и закинуть ее в светлое будущее. Так же как нельзя цивилизацию из феодализма зашвырнуть в коммунизм, где все в кайф.
Имел честь работать в стартапе, сформированный людьми, бежавшими от сберджайл-трансформации. Все практики у нас прекрасно работали.
tvr
09.01.2022 22:57+1Напомнило систему построения федеральных сетей торговли электроникой в конце девяностых — начале нулевых. Один в один.
aazazello
10.01.2022 08:37+2Это один из способов борьбы с недоверием. В 90-е доверие вообще было как мишень для приколов в самом мягком случае.
С обеих сторон очевидно. Менеджеры не доверяют, потому что сами осознать предлагаемые решения неспособны, а команды (тут скорее о лидах речь) не слишком напрягаются в попытках свои решения объяснить, показать не просто отдельный случай, а хотя бы инженерный план достижения цели . Команды не доверяют, потому что могут прийти и сказать "сворачивайте ваши Иксперименты и развитие и делайте кондово и бегом".
А тут еще разработка, которая помимо производства софта еще и конструирование содержит и элементы НИОКР. И получается, что на цикл ОКР-конструирование-производство менеджеры 2-3 слоев и команды натягивают гибкие процессы. Сложность растет быстрее компетенций и тех и других. Пока проект небольшой, разбираются. В энтерпрайзе под это дело уже весь управленческий состав до тим-лидов включительно нужно очень серьезно готовить. Одних цели формулировать и управлять их изменениями не "а сегодня начинам жить по новому", других выстраивать процессы, третьих создавать и изменять решения достижения этих целей. Взаимное доверие только за счет взаимной уверенности в профессионализме может появиться. И один "случайно залетевший в систему" менеджер его легко может порушить. А это частый случай, вот и тянутся все к модели нулевого доверия.
K27habr
09.01.2022 23:22Согласен с автором статьи. Но, мне повезло у нас технический директор может сам написать любому рядовому сотруднику, при необходимости. В этом плане, это очень здорово! :)
pyrk2142
09.01.2022 23:30+6ИМХО, очень наивно считать, что менеджмент глуп, некомпетентен или способен понять важность чего-то. Средний руководитель прекрасно понимает цели DevOps, DevSecOps, Agile, Scrum, CI/CD и кучи других вещей. И часто гораздо лучше знает, зачем это нужно или не нужно в компании. Но при этом он прекрасно понимает, что из этого принесете ему пользу или не принесет.
Зачем внедрять DevOps, если ты собираешься через полгода уходить из компании? Лучше пусть собирают руками, зато релизы предсказуемые (а так они станут предсказуемыми через год, а тогда уже менеджера тут не будет).
Заменил Agile на какую-то странную систему, когда сначала формулируется набор задач на два месяца, а потом каждую неделю готовятся отчеты по тому, что сделано? И не важно, что через год это все развалится, зато сейчас есть хорошие отчеты и графики. Если ты уходишь через полгода, то план абсолютно рабочий.
Сваливать все на сотрудников абсолютно логично, менеджер не идиот, чтобы брать вину на себя. Много ли разработчиков не в маркетинговых статьях (вида "я совершил ошибку, мы потеряли 1000 миллиадров, но меня не уволили, смотрите, как важно учиться") выходили и говорили "Да я забил на работу, из-за меня упали сервисы, утекли данные людей, кого-то угнетают"? Не очень много. А почему менеджер должен так делать?
Тупых менеджеров крайне мало, даже если они так выглядят. И попытки рассказать им, зачему нужен DevOps, обречены на провал, так как менеджеры это уже знают прекрасно, он им просто не выгоден. Поэтому основная задача - это показать менеджементу, почему какая-то инновация полезна именно им. Или почему ее отсутствие приведет к проблемам именно у менеджмента, которые простым увольнением не убрать.
Shaz
10.01.2022 00:23+7А DevOps'ам этот самый девопс (точнее кубер и сиай) нужны примерно для тех же целей - внедрил, вроде что-то работает, пока разбираются - меняешь работу. Видимо для win-win нужно просто договорится с менеджером.
Jammarra
11.01.2022 18:12+2Вы так говорите как будто внедрить и уволится это плохо. Я вот за год примерно сделал внедрил. И что дальше делать окровенно не знаю. Пайпы работают, команды их используют, техподдержкой может кто угодно заниматься. Каких то глобальных задач больше нет.
А сидеть имитировать бурную деятельность оно не очень интересно. Как и мелочевкой заниматься. Зато если уйдешь HR начнут "ко ко ко а что это так мало отработал"У меня вообще всегда в целом привести все в порядок занимает 1-2 года. Потом скучная и унылая текучка начинается и сидение на хабре 60% рабочего дня. Если не больше.
На прошлой работе так же было. была задача адекватный мониторинг сделать, отказоусточивость обеспечить и т.д. Сделал. Потом блин вообще по 30-40 минут максимум из 8 часов занимался чем то. Остальное время плевал в потолок.
Shaz
11.01.2022 18:54Это может быть и плохо, а может и не плохо. Не нужно пытаться давать этому какую-то окраску. Иначе придётся погрязнуть в разборе огромного количества частных случаев.
passing1by Автор
10.01.2022 12:15а про глупость и не сказано, сказано, что всех интересует только имитация деятельности, надо принять как можно больше решений, ведь их эффект будет только среди челяди, а верхи и дальше будут жить спокойно
KoteMilote
10.01.2022 01:10+1Если одним абзацем для Лиги Лени:
Не работает там, где менеджмент на всех уровнях в этом не заинтересован/не понимает.
uyrij
10.01.2022 01:34https://youtu.be/_Z_VnOaIYAc Х.Х и в продакшн! Немного с другой стороны про аджайл и скрамп
FlashHaos
10.01.2022 09:24+2Бессвязный кому души. Не знаю, как у автора с девопсом - но с русским точно плохо. Обидели инженера в кровавом энтерпрайзе? Не дали поставить любимую версию хадупа? Заставили на директора посмотреть? Вот сволочи.
Наверное, в той компании действительно был плохой менеджмент. Он вообще часто плохой. Но с плохим менеджментом через задницу работает не только девопс, а вообще все толковые методики работают через задницу.
Но свою обиду на одну компанию выдавать за экспертную оценку индустрии - не надо. Даже если в индустрии действительно такая ситуация, это некорректно и нечестно. Если хотите пожаловаться - пишите с названием организации. И на профильный сайт жалоб на работодателя, Хабр вроде бы не жалобная книга.
LuchS-lynx
10.01.2022 10:43+9Я технарь, но не IT, а строитель. За годы работы понял следующее:
В структуре управления то что говорят и то что делают это две разные вещи. Потому что управляющий или тот кто может влиять преследует свои глобальные/местечковые цели и интересы. Внедрение новой структуры управления это перераспределение ответственности, бюджета и прав. Собственно этот конфликт интересов и обеспечивает неработу всего такого.
-
Из экономики известно чем глубже уровень разделения труда, чем дальше цепочка от идеи до модели, проданной потребителю - тем выше риски, которые распределяются внутри этой цепочки. Применительно к структуре управления, условно раньше ты мог придти зеленым рабочим на завод/предприятие, пройдти по горизонтальным лестницам и затем, в случае удачной карьеры, ты понимал как и что работае, тебе не нужно десятки согласований или их будет требоваться на порядок меньше.
Сегодня управленец это такой же винтик как и инженер, но с правом решать. Стараясь минимизировать риски в деятельность втягивается уйма народа, что бы размыть ответственность.
У молодого поколения управленцев и менеджеров (условно возраст до 40-45лет) есть огромный соблазн и желание управлять по статистическим данным (в т.ч. из-за влияния проблем в п.2.) Для этого увеличивается отчетность и кол-во показателей. Иногда это работает, но чаще нет. Но это же созвучно сути бюрократического аппарата любой фирмы/гос-ва. Т.е. нужны технологии и инструкции, по которым будут работать люди. Увеличение отчетности приводит к побочке: если раньше специалист хоть что-то на своем уровне решал сам, за счет рабочего времени или даже нерабочего, в рамках своих компетенций, то теперь специалист это больше или меньше оператор данных, которые он собирает, структурирует и передает дальше. Решают другие! А управленческие специалисты, как правило, теперь не имеют знаний и опыта в рамках компетенций технических специалистов, в результате они либо не понимают части проблем, либо даже их не видят. Усугубляется это еще и трудовой миграцией между отраслями, когда условный выпускник педа/эконома идет на стройку, а технарь в бухгалтерию... Тут кто как устроился и кому как повезло или "повезло"
-
Человеческий фактор.
Больше всех в колхозе работала лошадь. Но председателем она так и не стала.
Тех кто вывозит технические процессы с управленческой точки зрения повышать глупо, т.к. на их место придут другие, кто перестанут вывозить. А вот тех кто решает управленческие проблемы могут и повысить. Второй вопрос в том как отпиарить решение проблемы, т.к. люди существа эмоциональные и могут заморачиваться с одной стороны над тем что и яйца выединого не стоит, а с другой не считать проблему проблемой. В итоге субъективизм чистой воды на всех этажах управленческой вертикали + связанные личным интересами и союзами группировки и отдельные люди. Ищи кому выгодно. Если руководитель тебя хвалит за решение задач это может так же означать, что наверх он докладывает что сделал это сам или именно его идея или воля в нужный момент оказалась решающей. Даже если это руководитель из другого отдела.
ApeCoder
10.01.2022 11:51+1Если не секрет, как вас занесло в обсуждение девопсов?
LuchS-lynx
10.01.2022 13:15+6В детстве мечтал стать программистом, осилил Spectrum Basic, QBasic 4.5, Borland Pascal 7.0. Сейчас пишу формы под себя с применением VBA. Пишу и комментирую для себя интересное на Хабрахабре. На стройке работал мастером, мастером в эксплуатации котелен, сейчас я сметчик, но руководство переодически бросает аварийно латать дыры с документацией ПТО по объектам время от времени, приходится ситуативно руководить. Поэтому все что связано с управлением/руководством интересно.
chernish2
10.01.2022 21:05+1Так у Вас все данные чтобы в программисты пойти. Не пробовали?
LuchS-lynx
11.01.2022 09:11Не пробовал, потому что с одной стороны меня программистом никто не ждет, мне скоро 40лет, стабильно платят з/п чуть выше рынка, в своей сфере есть опыт и даже широкая известность в узких кругах. =) С другой стороны з/п не дотягивает даже до джунов в МСК.
Планирую как хобби что-то освоить навроде C с чем-нибудь, что бы делать модули под Excel и библиотеки закрытые для документооборота, но это хобби, впрочем в этом году со вводом обязательного электронного документаоборота в строительстве все это может пойдти по одному известному пути - дорогой добра, т.к. не смотря на удобства у меня нет денег и времени конкурировать с программерами на з/п и софтом от компаний - лидеров рынка типа 1С, Арос, Алтиус и т.п. в части специализированного софта.
ky0
10.01.2022 12:53+1Тех кто вывозит технические процессы с управленческой точки зрения повышать глупо, т.к. на их место придут другие, кто перестанут вывозить. А вот тех кто решает управленческие проблемы могут и повысить.
Когда «неповышение» сопровождается регулярным и достаточным увеличением зарплаты и прочими ништяками — при условии, что появляются интересные задачки, лично мне, как технарю, большего и желать не нужно, гори оно синим пламенем, это повышение.
Куда мне, как сисадмину, «повышаться» по вертикали? В руководителя отдела эксплуатации? Пробовали, знаем — почти везде это уход от работы головой и руками в сторону работы ртом.LuchS-lynx
10.01.2022 13:24Куда мне, как сисадмину, «повышаться» по вертикали? В руководителя отдела эксплуатации? Пробовали, знаем — почти везде это уход от работы головой и руками в сторону работы ртом.
Я не оспариваю Ваш выбор, вполне может быть что лично для Вас так оно и лучше. Но когда руководители люди без бэкгрануда технического или хотя бы не прошедшие по горизонтали по нескольким смежным рабочим/техническим должностям, что бы знать как оно устроено изнутри, то получаем такие вот вещи как в этой статье, потому что или не хватает опыта/кругозора, или знаний что бы корректно оценить и просчитать последствия, подменяя такие знания внешним/внутренним аудитом. Бюрократия не только полезна, но и вредна.
ky0
10.01.2022 14:07+2Я с вами совершенно согласен, что хороший менеджер обычно произрастает изнутри соответствующего направления, а не приходит извне, пытаясь (или не пытаясь, хе-хе) понять, что там унутре происходит. Но для этого у человека должна быть соответствующая склонность — а далеко не всякий технарь для этого пригоден. Я именно из таких — готов водить руками только в режиме «играющего тренера», иначе начинаю стрессовать.
doctorvvv
10.01.2022 12:12Везде так. Довелось мне как то быть начальником, и даже пару раз большим. Постоянно требуют оптимизацию ресурсов, ВСЕХ. Пережил и "бережливое производство" и даже внедрение Тойоты %) Приходит новый админдир или эфективный менеджер и начинаеться, то бишь каждый полгода-год перетрахивание всего. А по факту страдает производство, теряються довольно ценные и редкие кадры. Но в странах постсовка везде так. Тойота хороша, но.... Для Японии, у нас же руководство считает что этот подход онли для рабочих и прочей челяди)
Всем добра, особенно на работе!
johnfound
10.01.2022 12:17+2Уже написали, что это не только в России не работает.
Я только хотел напомнить о великолепном сайте и манифесте Programming, Motherfucker, который создан далеко не в России.
А автору я бы рекомендовал думать о тенденциях и причинах, а не о место действия. Когда agile не работает, это не потому что в России, а потому что agile. Кстати, когда agile работает (а он иногда и работает) это тоже не из за России/Нероссии а из за других причин.
dgstudio
10.01.2022 13:46Типичный плач Ярославны от человека с внешним локусом контроля. Автор, работай над своим окружением. Воспитывай своих менеджеров, а если не воспитываются — ищи других. Если ты хороший спец — тебе будут рады в любой конторе на рынке, а если нет — то иди работай над собой сначала.
lazy-fox
10.01.2022 18:51-3Agile - интересен для проектов с неизвестным сроком и стоимостью, waterfall - наоборот.
Когда строим серийную многоэтажку в спальном районе или обслуживаем конвейер тойоты.шушары - применяем водопад, потому что известны ресурсы, сметы, снипы, ставки, нормы... Все это ясно отражается на диаграмме Ганта и стендах бережливых производств.
Напротив, разрабатывая стартап Uber, применяем гибкий подход, так как точное планирование может потребовать ресурсов больших чем сама разработка (например времени за которое конкуренты сделают проект быстрее и снимут первую пену).
Задача управленца состоит в декомпозиции проекта на ряд ясных задач, возникающих так же и в процессе работы опираясь на бэклог, а не только начальные и случайные хотелки верхов.
Идея создания MVP, как реально минимально-работающей системы, позволяет оценить эффективность проекта с последующим наращиванием функционала и масштабированием.
DevOps позволяет реализовать итерационное и непрерывное управление такой разработкой.
Вопрос культуры применения agile и devops будет стоять до тех пор, пока не появится мотивация низов брать задачи. А это подразумевает сдельную оплату труда и отсутствие социальных гарантий.
lazy-fox
11.01.2022 14:53-4Минусуют так понимаю те программисты и эффективные манагеры, что пригрелись на окладе в 100500 и приспособились удовлетворять вышестоящий уровень по принципу "к пуговицам претензии есть?".
Экономика ожидаемо уперлась в кризис перепроизводства и комфортные условия труда ведут к империализму и последующему краху. Для того что бы этого избежать была разработана гибкая методология, особенно актуальная стартапам и инновациям, в противовес жесткому планированию.
Глобальная сеть позволила работать над продуктом совместно и инструментарий DevOps позволяет управлять этим процессом точно и непрерывно.
Другое дело что пихать модные тенденции под любым соусом, регулируя процесс по прежнему кнутом и пряником - неэффективно. И важно понимать что стартап или инновация - это риск. Так почему команда не принимает его и просит оклад и СП?
msamoylov
10.01.2022 23:13Проблема такая есть не только в Российских компаниях, но и в международных, а ещё есть российские и международные компании, где описанных проблем нет. Частный опыт не может быть аргументом для описания общей тенденции.
glebiuskv
11.01.2022 15:06Ну не знаю. Работал и в конторах, где работал DevOps и в конторах, где работал Agile, и, хотите верьте, хотите-нет, там, где работало и то и другое. Кстати, в большинстве случаев, сначала по шапке получало высокое начальство, и только потом, уже от него, раздача спускается на уровень разработчиков и девопсов. С уменьшеной силой и то если руководство не вылетало после получения по шапке.
Опять же приведённые ошибки менеджмента, (даже если забыть, что все мы люди и ошибаемся, и таких же ошибок со стороны разработчиков я могу привести не меньше) эти ошибки нельзя оценить без контекста, без информации на стоимость разработки. Та же старая версия хадупа заместо рефакторинга могла сэкономить/заработать фирме достаточно, чтоб не считать ошибкой(хотя скорей всего это и не так), например, в условиях, когда этих 3х месяцев просто нет.
Вобщем, резюмируя, не работает там, где на это всем начхать.
Try_better
11.01.2022 23:34Статья в духе "Все папуасы, а я Д'арьаньян". Если ты видишь дичь, зачем делаешь? А если ты своими руками делаешь дичь, то какие к другим вопросы то? Или у вас там надсмотрщики с плетками? Или мож паспорт не отдают?
Отчего сам не рулишь, если знаешь, как нужно?
Unbeliver
11.01.2022 23:34+1По моему опыту Devops вполне себе работает, главная проблема, что нормальных девопсов не найдёшь днем с огнём. 90% так называемых девопсов обычные сис админы, которые хотят много денег за ту же работу.
Agile тоже работает при нормальном менеджменте, что и правда встречается крайне редко. Среднестатистический менеджер, к сожалению, может только ставить сроки (часто нереальные) и подгонять все, что движется и не движется.
Jammarra
12.01.2022 00:46Ну с таким подходом как у вас работать точно не будет. К сожалению многие не знают что devops это методология а не специальность и пытаются нанять человека. Который просто за десятерых работать должен по их мнению
Unbeliver
12.01.2022 07:38А кого же мне пытаться нанять? Я не могу нанять методологию. Я как раз и имею ввиду то, что люди пишут в резюме, что они специалисты по Devops, а по сути даже не знают, что это. За десятерых никого работать не заставляем. У меня кросс функциональные команды примерно человек по 8, в каждой по 1 девопсу.
Jammarra
12.01.2022 08:47Почему вы изначально решили что вам надо кого то нанимать?)
меняйте процессы а не людей.
Unbeliver
12.01.2022 08:58Странный совет. Я должен менять процессы на несколько тысяч человек, чтобы что? Не нанимать девопса?
Jammarra
12.01.2022 09:51Очень правельный вопрос. Только вы его не мне задавайте, а себе.
Ну а если мне то извените без вводной информации которой с комментариев в хабре явно недостаточно и анализа текущих процессов и проблем ответить не смогу.К слову агрессия которая в этом вопросе сквозит и приводит к тому что в большистве случаев весь девопс в компаниях и заканчивается на найме человека с модной лычкой который пишет пайпы.
Unbeliver
12.01.2022 10:04Да нет у меня никакой агрессии. И уж явно не я виноват в том, что девопс где-то там заканчивается. У меня проблема прямо противоположная. Хотим вот мы развить девопс культуру в организации, ищем людей, которые с методологией знакомы. Что в этом плохого? А по факту получается именно так, как вы говорите. Т.е. люди по сути работают сис админами на всем готовом, с девопсом не знакомы и знакомиться не хотят. Но в резюме пишут, что они девопс-инженеры (видимо такие агрессивные как я лычки им повесили в погоне за модой) и просят 400К. И таких кандидатов 90%.
Jammarra
12.01.2022 17:44А вот тут вопрос психологии. Любое давление из вне будет вызывать отторжение. Ну придет какой то чел со стороны. Скажет тестировать это круто. Зафигачит кволите гейты на сборку без тестов. Разрабы скажут «А не офигел ли ты» И уволятся дружно.
Изменение должно идти из самой органзации и комманд. Просто людей как то заинтересовать надо что бы сами хотели менять процессы. Нужно понимать что люди по свой природе обычно всегда хотят сделать хорошо. Нет такого что прям «Мы делаем хрень потому что хотим сделать херню» Обычно любой работник стремится сделать что то клевое. И нужно только дать направление. В этом плане например митапы где будут делится практиками и сводный день на исследовательскую работу, свободный от рутины может дать даже большей результат чем любой девопс.
Поэтому и говорю организацию нужно плавно менять.
Unbeliver
12.01.2022 17:51Я перестал понимать, о чем вы и что за кровавый девопс описываете) Никто никого не заставляет, девопс-инженеры такие же члены команды, как и разработчики, тестировщики и т.д., которые вместе развивают продукт.
Boltyanskiy
12.01.2022 03:07+36 баллов по 5-ти бальной системе. Именно это я и увидел, когда перешёл из маленькой конторки, которая делала продукт, но который работает, в большую Компанию, которая уже который год бредит-грезит выпуском второго поколения продукта, который был выпущен этой Компанией, когда она была ещё маленькой конторкой. И, что обидно, что кругозор менеджеров, уже чем у скаковой лошади. Даже из этой статьи, любой менеджер вынесет вывод, что дело в некомпеиентности менеджеров. И будут нанимать ещё более дорогих менеджеров. Как будто от этого новонанятые будут более компетентны. Вот готов поспорить, что ни один из менеджером не сможет сделать очевидный правильный вывод из этой статьи. Не способны они на очевидные правильные выводы.
Valle
Хороший пример двунаправленной blame culture.