Для кого эта статья: менеджеры, тимлиды, директора, отвечающие за организацию процессов, трансформацию команд и внедрение устойчивых практик управления IT. Если вы ищете понятный способ освежить знания по ITIL 4 и посмотреть, как принципы работают вживую - этот разбор для вас.
Маркетинг при продажах крупным корпорациям это не классические продажи B2B, это целая спецоперация и пропаганда. А еще использование мягкой силы на государственном уровне. Не верите? Тогда читайте непридуманные истории.
Привет, Хабр!
Многие ИТ-компании находится в постоянном поиске баланса между автономией команд и централизацией процессов. Эта дилемма не обошла стороной и нас в Content AI. В силу нескольких причин пришлось отказаться от классической плоской структуры, которая подразумевала минимальное количество уровней управления, в пользу иерархической, где напротив, есть довольно четкое распределение ролей и зон ответственности.
Попросили руководителя нашего отдела разработки — Александра Субботина и его подчиненных, рассказать о причинах смены подхода к распределению ролей в командах и вызовах, с которыми столкнулись в процессе перехода.
Все подробности — под катом.
————
Привет, Хабр!
Если вы ощущаете, что стали частью распределённой системы с бесконечными входящими — поздравляю, вы тимлид. И, скорее всего, вам не весело. Вы не пишете код. Вы не думаете стратегически. Зато вы таскаете ведро с пробоинами по палубе, где вечно течёт.
У большинства тимлидов, особенно в условиях активного роста компании или распределённой разработки, есть общее ощущение перегруженности. Неважно, какая индустрия, стек, удалёнка или офис — ощущение одно: «весь день был занят, но результат размыт».
Заглянуть в будущее, пожалуй, интересно всегда. Но ещё занимательнее — наблюдать, как оно становится настоящим. Вспомним, что говорили про ИИ и Интернет вещей еще лет 20 назад. Технологии всё сильнее развиваются скачкообразно, а не линейно. Мир обсуждает подрывные инновации — самые рисковые и сообразительные их создают. В этой подборке рекомендуем книги про цифровую историю, с которыми получится осмыслить нынешние промышленные революции и актуальные тренды.
Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.
По инструментам всё достаточно просто. На столе у нас GitLab, ему когда-то очень-очень давно помогал Jenkins, немного Vault, чуть-чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена – RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.
В свое время я работал на стороне заказчика — крупной промышленной компании и в том числе моей задачей был выбор подрядчиков на разные ИТ-проекты. Сейчас я тружусь в Linx Cloud и развиваю облака IaaS. Недавно мне понадобилось провести исследование и сравнить предложения облачной инфраструктуры от различных провайдеров, взглянуть глазами клиента на ситуацию, что я с энтузиазмом и сделал. Делюсь с вами итогами и выводами, которые удалось раскопать.
Привет! Это Леша Жиряков, я руководить бэкенд-команды витрины KION и Python-гильдии в МТС. Как раз о Python сегодня и пойдет речь. Обсудим, почему самый популярный ЯП, по версии TIOBE, так востребован в корпоративном секторе: из простого инструмента автоматизации он превратился в полноценную экосистему для создания критически важных продуктов.
Если коротко, причина успеха — в эволюции языка и его экосистемы. Аннотации типов в Python 3.5 сделали доступной статическую проверку кода без потери гибкости динамической типизации. Это решающий фактор для корпоративной разработки, ведь главные требования тут — это надежность и поддерживаемость.
Недавно я уже писал о причинах успеха Python в целом, а сегодня хочу подробно рассмотреть его современные инструменты для предприятий: типизированные структуры данных с dataclasses, высокопроизводительные системы валидации msgspec, pydantic 2 и другие библиотеки. То есть все, что помогло ему стать идеальным выбором для серьезных бизнес-решений. Информации много, так что тему разобью на две части. Погнали!
Всем привет! Я продолжаю небольшую серию нудных статей о базовых знаниях, необходимых для понимания HR-процессов и их экономической составляющей. Сегодня расскажу о концепции роста производительности сотрудника, которая часто используется для расчета точки окупаемости. Правда ли, что, выходя на работу, мы начинаем приносить пользу не сразу? От чего это зависит и что с этим делать компании?
Привет! Меня зовут Кирилл, я студент 3-го курса НИУ МЭИ, направление — «Информатика и вычислительная техника», а также Junior Python Backend-разработчик в Альфа-Банке.
После окончания второго курса я заметил в тематических чатах (например, в чате «Поступашки», где студенты активно обсуждают стажировки), что многие студенты устраиваются на стажировки уже на 2-3 курсах. Часики-то тикают — мой второй курс закончился, теории всё больше, а практики не хватает — была нужна стажировка.
И я начал искать стажировки для backend-разработчиков.
Удивительно, но несмотря на обилие предложений статей от тех, кто «выжил» после стажировок в IT не так уж много. А вопросов много: «Как попасть?», «Что меня там ждёт?», «Как ко мне будут относиться?», «Как устроены процессы в больших компаниях? Можно ли совмещать с учёбой?», «Как теория лекций согласуется с практическими задачами?», «Смогу ли я узнать что-то новое (и научат ли меня?)», «В какую компанию компанию лучше подаваться?»
В итоге стажировку я благополучно прошёл и подготовил статью, где могу рассказать, как попасть на стажировку, чего ожидать от эйчара, какие задачи мне выдавали, помогают ли пет-проекты и, в целом, постараюсь ответить на те вопросы, на которые сам хотел бы знать ответы, когда еще был в поисках.
Дисклеймер. Я пишу для студентов и ребят без опыта работы. Если у вас большой опыт и вы не ищите стажировку в IT — вам, скорее всего, будет не интересно.
«Функциональное программирование», «Immutable значения», «Pure функции».
Тоже слышал эти умные слова?
И ты такой: «Что? Можно просто for написать?»
Спокойно. Сейчас все разложим по полочкам. Даже если ты пишешь var a = 1 и гордишься этим — ты свой. Погнали.
Привет, Хабр! Я Екатерина Разутова, специалист по внутренним коммуникациям и проектам в «ДАР» (ГК «КОРУС Консалтинг»). В этой статье расскажу про наш кейс персонализации подарков, который будет полезен HR-специалистам, руководителям IT-команд и всем, кто хочет укрепить корпоративную культуру компании.
Как продакты выбирают методологию разработки — и почему это вообще важно? Выбор подхода к разработке определяет дальнешие шаги дя разработки роадмепов, верстке бюджетов и выстраиванию процессов в команде. Это решение, от которого напрямую зависят Time to Market, эффективность команды и шанс не потратить бюджет впустую. Разберем основные продуктовые методологии и фреймворки, чтобы создать эффективную систему для принятия сложных решений.
Привет! Меня зовут Александр Фролов, я data scientist отдела машинного обучения в Нетологии. В этой статье я коротко расскажу, откуда взялись LLM, чем они стали сегодня, куда всё идёт и где в этом хаосе найти точку опоры.
Постараюсь обойтись без лишней теории и академического занудства — просто обзор по верхам с точки зрения дата-сайентиста, который строит пайплайны по обработке данных.
Привет! Меня зовут Кристина, я тестировщик в ППК «Роскадастр» и ревьюер курса «Инженер по тестированию» в Яндекс Практикуме. В этой статье я расскажу, как правильно оформлять задачи в Jira — так, чтобы тестировщик сразу понял, что от него требуется, и выполнил работу без лишних уточнений и задержек.
80% компаний используют генеративный ИИ без реальной отдачи. Этот «парадокс Gen AI» разрешают ИИ-агенты: они автоматизируют сложные процессы, повышают оперативность и открывают новые источники дохода.
Узнайте, как перейти от экспериментов к масштабируемому влиянию на бизнес.
ITSM живет с нами уже 30 лет. За это время многое изменилось: технологии, версии ITIL, бюджеты на реализацию. Что осталось неизменным — так это завышенные ожидания, которые часто идут вразрез с реальностью.
Напомню, что ITSM (Information Technology Service Management, Управление ИТ-услугами) — это подход к управлению ИТ-деятельностью, который рассматривает ИТ-ресурсы как услуги, предоставляемые бизнесу для достижения его целей.
Сегодня я хотел обсудить самые распространенные «мифы», которые громогласно и красиво рассказывают со сцен отраслевых мероприятий и на вебинарах признанные специалисты, консультанты, продавцы, эксперты в области ITSM, и то, как потом эти «мифы» разбиваются о скалы суровой реальности.
Миф № 1: Я легко пройду сквозь бюрократию и быстро внедрю сервисный подход! Ведь это же прогресс и инновации, за этим будущее!
Реальность: нет, это будет долго и больно.
Десятки тысяч компаний организуют продажи в системах управления, которые казалось бы для этого не предназначены. Почему? Потому что устали от сложности большинства крупных CRM-систем. Вот как мы делаем свою CRM в системе управления проектами.
Привет, Хабр! Меня зовут Тигран Басеян и я — руководитель MTS Link Доски, CEO geekz.ru, развиваю российскую методологию управления ИТ в организациях РИТМ, преподаватель ВШЭ и автор телеграм-канала Black Product Owner (Чёрный продакт), где рассказываю о продакстве, менеджменте и стартапах. В индустрии уже больше 15 лет. Руководил различными технологическими командами и продуктами, в том числе высоконагруженными.
И раньше я никогда правильно не использовал модель Кано. Это метод, который появился в Японии в 1980-х годах и используется для измерения эмоциональной реакции клиентов на отдельные функции.
Если бы в 2017 году, когда я работал над платформенным продуктом, я применил модель Кано грамотно, проект мог бы обойтись без лишних затрат времени и нервов. Но тогда мне казалось, что Кано — это какая-то скучная теория для учебников по менеджменту.
Спойлер: это не так. Модель Кано — один из самых мощных инструментов для управления ожиданиями пользователей и для приоритизации фич. Главное — уметь ей пользоваться на практике, а не просто пересказывать графики из Википедии.
В этой статье я разложу всё по полочкам: какие бывают категории фич, почему пользователи однажды перестают радоваться вашим «фишкам» и как построить опрос, чтобы Кано действительно заработала в ваших продуктах. Без воды — только факты, кейсы и практические советы.
Тут в глубине комментариев зашла речь о создании видимости работы в ущерб самой работе — когда количество закрытых тасков ценится (менеджерами) выше, чем докопаться до причины бага и устранить ее. Комментарий получился бы большеват, решил вынести в отдельный пост.
Суть.
