Там же прямо написано “опсы” – а девопсы как раз появились как противопоставление опсам. Так что даже если это описка, то это типа “описался, вместо слова для лекарства выдал слово для токсина болезни”. Это означает, что природа опсов и девопсов не очень понимается, почему они такие и так называются.
You build it, you run it и беседы с клиентами только когда фирма маленькая) А так никто тебе никогда не доверит выкатку (даже если там правда на одну кнопку надо нажать). Куча вариантов:
- катит на прод тимлид (права только у него на эту кнопку);
- катит девопс::должность по просьбе ответственного за сервис разработчика, разработчик сидит рядом;
- наняты отдельные люди - релиз менеджер::должность, катят они по просьбе от “бизнеса” (бизнес аналитик просит выкатить, согласует с продукт овнером).
Билд тоже разделён. Потому что devops::методология появилась, но докатилась она до нас в довольно странном виде. У ops (админов) часть dev не отросла (они не пишут приложения), а у dev (разработчиков) ops часть тоже не до конца отросла (в контейнеры свои аппы мы заворачиваем и как-то понимать, как оно крутится в kubernetes надо бы, но helm чарты для разворачивания через кубер пишут опсы, а не разрабы). Но да опсы разворачивают платформу для разработки, инфраструктуру для runtime.
Про идею выкинуть совсем manual QA не буду пока писать.
Это ставится как отдельная проблема: как сделать так, чтобы фирма большая работала как фирма маленькая. Скажем, 3 триллиона капитализации у NVIDIA – они себя считают “маленьким стартапом” по сравнению с Intel, и это даже в разговорах проявляется (я с ними беседовал на уровне вице-президентов, и они искренне верят, что они маленькие и поэтому должны действовать как маленькие, “стартап”).
И там ещё интересный момент, что NVIDIA поддерживает много людей, занимающихся приложениями: тем, что делают, по идее, их клиенты. Вот прямо идея о том, что разаботчики через все эти длинные цепочки должны как-то добегать до реального использования.
Там у вас “бизнес-аналитик” ещё помянут. Ага, “аналитик”. Фишка в том, чтобы хоть кто-то там стал не аналитиком, а деятелем. “Кому-то доверить” – это означает, что по процессу будет казаться, что всё надёжно, кнопка – чистая формальность. Это означает, что тестирование надо перестраивать, там обоснование функциональных возможностей, архитектурных хотелок, хотелок безопасности просто автоматом должно происходить, плюс автомат на роллбэк. Это чисто технологические фишки, и ими занимаются как раз инженеры платформы, чтобы оно было. Но вот сами тесты дают, конечно, ответственные за тесты. А потом? А потом всё от клиентов без посредников прилетает к разработчикам фич (а ещё прилетает от архитекторов и от безопасников, а сейчас начинает время от времени прилетать и от методологов – ибо разработчики иногда не SoTA метод работы автоматизируют, а первый попавшийся, “новичковые ошибки” клиентов и свои кодируют).
Это всё в литературе по курсу “Системная инженерия”, следующий семестр.
При этом основной вопрос к нашим студентам: вылезают ли они из чисто аналитической (моя хата с краю) или инженерной (ну ладно, вот тут можно подправить, добавить параметр) работы в организационное развитие, то есть неформально без получения полномочий идут к коллегам и кусочек коленвала выправляют. Конечно, идут не с требованием отдать им главную кнопку! Но делают так, чтобы от соседей прилетало меньше. Обычно это задействование курса методологии (чтобы было меньше ошибок – чеклисты, хорошо помогают от преждевременной смерти проектов), а затем “Системный менеджмент” ибо по факту это оргразвитие, только без получения полномочий. А полномочия дают потом, убедившись в результатах – и в том, что всё это делается “организатором снизу” сознательно на базе знаний, а не по наитию, случайно.
Фишка тут и в том, что по линии технического роста довольно быстро упираешься в необходимость что-то организовывать, ибо растёт масштаб проекта. Ну, или у тебя олимпиадное программирование: суперсложный кусок кода (но это сейчас AI будет писать, людей таких уже не надо вообще).
2 лайка
а еще проблема, что у devOps бы надо отрастить часть business, но про это мало кто говорит
1 лайк
Чинить то, что не сломано? Хм…
Интерфейс-то не сломан. Он неудобен лично вам.
А разработчики как подумали (смоделировали), так и сделали.
Их (и тех, кто ставил им задачу на разработку), видимо, всё устраивает.
“Работает, не трогай”, ага)
Лично нам всем. Но я всё-таки не про дефолтный ui таск трекера, а про передачу информации между командами.
“Всё по ТЗ, не работает” это вообще моё любимое.
Всем-всем?
Давайте уточним, что мы сейчас обсуждаем?
(1) Aisystan ШСМ или (2) ваш корпоративный таск-трекер?
Я - первый вариант. И ваше сообщение, на которое я отвечал, был про Aisystant.
При чём здесь ваше “я всё-таки не про дефолтный ui таск трекера, а про передачу информации между командами” ??
Интерфейс - определён: у всех есть учётки в трекере, всем прилетают уведомления.
“Можно подвести осла к джире, но нельзя заставить осла проверить входящие!”
вот это было про aisystant? Это было про таск-трекер. Я вам в ответ привела пример, другого интерфейса - aisystant. Где всё хорошо, но людям почему-то неудобно. И выбора между “учить людей” или “переделывать интерфейс”, можно ещё “забить”.
На данный момент интерфейсы ПО меня мало интересуют. Меня интересует “передача информации между командами”::интерфейс. У нас девопсы с одной стороны интерфейса, разработчики - с другой. Между ними должен идти поток информации о статусе готовности инфраструктурной задачи. Этот поток информации реализуется “корпоративным такс-трекером”::конструктив.
Там выше про это несколько сообщений. И размышлений что с этим интерфейсом не так. И как его “можно наладить”: 1) формально через документы (инструкции и спрос про исполнение этих инструкций), 2) неформально через объяснения, уговоры и показ как пользоваться, чтобы было поудобнее. Я сейчас к неформальному пути склоняюсь.