Если вы хоть раз были на стороне бизнеса, наверняка слышали (или говорили):
Сколько можно делать такую простую штуку?; Они что, не понимают, как это важно?
Но тут надо смотреть шире...
Все знают аббревиатуру CI/CD. Continuous Integration and Continuous Delivery - Непрерывная интеграция и Непрерывная поставка. Но едва ли можно найти более неправильно понимаемую нашей индустрией идею, чем непрерывная интеграция. Практика, которая была придумана, чтобы её делали разработчики, почему-то превратилась в объект работы девопсов, хотя к культуре DevOps ну вообще никакого отношения, по идее, иметь не должна.
Так что вот вам статья про то, как так вышло, что сейчас под CI понимают что угодно, кроме того, чем она, на самом деле, является.
Как AI-системы теряют 30% смысла при обработке документации?
Проблема кроется в процессе chunking — разбиении документов на фрагменты. Когда связанная информация оказывается в разных частях, контекст теряется. Разберем механизмы работы RAG-систем и покажем, как писать документацию, которая работает для людей и машин.
Модель Кано, фреймворки, отсутствие ТЗ, отпуска на проекте, много гайдов по инструментам и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Пошаговое руководство по использованию Git, Obsidian, Markdown и любимого IDE для разработки требований и трассируемого в них программного кода.
Привет, Хабр!
Многие ИТ-компании находится в постоянном поиске баланса между автономией команд и централизацией процессов. Эта дилемма не обошла стороной и нас в Content AI. В силу нескольких причин пришлось отказаться от классической плоской структуры, которая подразумевала минимальное количество уровней управления, в пользу иерархической, где напротив, есть довольно четкое распределение ролей и зон ответственности.
Попросили руководителя нашего отдела разработки — Александра Субботина и его подчиненных, рассказать о причинах смены подхода к распределению ролей в командах и вызовах, с которыми столкнулись в процессе перехода.
Все подробности — под катом.
————
Привет, Хабр!
Если вы ощущаете, что стали частью распределённой системы с бесконечными входящими — поздравляю, вы тимлид. И, скорее всего, вам не весело. Вы не пишете код. Вы не думаете стратегически. Зато вы таскаете ведро с пробоинами по палубе, где вечно течёт.
У большинства тимлидов, особенно в условиях активного роста компании или распределённой разработки, есть общее ощущение перегруженности. Неважно, какая индустрия, стек, удалёнка или офис — ощущение одно: «весь день был занят, но результат размыт».
Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.
По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.
80% компаний используют генеративный ИИ без реальной отдачи. Этот «парадокс Gen AI» разрешают ИИ-агенты: они автоматизируют сложные процессы, повышают оперативность и открывают новые источники дохода.
Узнайте, как перейти от экспериментов к масштабируемому влиянию на бизнес.
ITSM живет с нами уже 30 лет. За это время многое изменилось: технологии, версии ITIL, бюджеты на реализацию. Что осталось неизменным — так это завышенные ожидания, которые часто идут вразрез с реальностью.
Напомню, что ITSM (Information Technology Service Management, Управление ИТ-услугами) — это подход к управлению ИТ-деятельностью, который рассматривает ИТ-ресурсы как услуги, предоставляемые бизнесу для достижения его целей.
Сегодня я хотел обсудить самые распространенные «мифы», которые громогласно и красиво рассказывают со сцен отраслевых мероприятий и на вебинарах признанные специалисты, консультанты, продавцы, эксперты в области ITSM, и то, как потом эти «мифы» разбиваются о скалы суровой реальности.
Миф № 1: Я легко пройду сквозь бюрократию и быстро внедрю сервисный подход! Ведь это же прогресс и инновации, за этим будущее!
Реальность: нет, это будет долго и больно.
Привет, Хабр! Меня зовут Тигран Басеян и я — руководитель MTS Link Доски, CEO geekz.ru, развиваю российскую методологию управления ИТ в организациях РИТМ, преподаватель ВШЭ и автор телеграм-канала Black Product Owner (Чёрный продакт), где рассказываю о продакстве, менеджменте и стартапах. В индустрии уже больше 15 лет. Руководил различными технологическими командами и продуктами, в том числе высоконагруженными.
И раньше я никогда правильно не использовал модель Кано. Это метод, который появился в Японии в 1980-х годах и используется для измерения эмоциональной реакции клиентов на отдельные функции.
Если бы в 2017 году, когда я работал над платформенным продуктом, я применил модель Кано грамотно, проект мог бы обойтись без лишних затрат времени и нервов. Но тогда мне казалось, что Кано — это какая-то скучная теория для учебников по менеджменту.
Спойлер: это не так. Модель Кано — один из самых мощных инструментов для управления ожиданиями пользователей и для приоритизации фич. Главное — уметь ей пользоваться на практике, а не просто пересказывать графики из Википедии.
В этой статье я разложу всё по полочкам: какие бывают категории фич, почему пользователи однажды перестают радоваться вашим «фишкам» и как построить опрос, чтобы Кано действительно заработала в ваших продуктах. Без воды — только факты, кейсы и практические советы.
Разработчики делают задания ради галочки, в их глазах больше не горит огонь, а число инновационных идей от девелоперов уменьшилось? Нет, сотрудники не обленились. Им просто не хватает мотивации для эффективной работы. Разбираемся вместе с командой системы управления проектами Kaiten и консультантом по современному менеджменту Neogenda Марией Савельевой, как вернуть мотивацию IT-команде.
Когда говорят про аутстаффинг, в большинстве случаев речь идет о разработке: фронтенд, бэкенд, DevOps, тестирование. Это то, что легко измерить в часах и тасках. Но в работе над цифровым продуктом бывают моменты, когда задача не в том, чтобы «написать код», а в том, чтобы разобраться, что именно нужно писать и зачем. И вот тогда на первый план выходят не программисты.
Привет, Хаброжители!
Издательство «Питер» представляет книгу-гид в мире профессионального роста. Автор Гергели Орош, прошедший путь от джуниора до принципал-разработчика в Uber, делится ценными инсайтами о том, как прокачать карьеру в IT. В этой статье мы немного больше расскажем о книге, которая представляет собой структурированное руководство, основанное на реальном опыте работы в крупных технологических компаниях. Как она называется? Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов.
Привет! Меня зовут Сергей Господчиков, и в IT я, страшно подумать, с 1992 года. Именно тогда я начал работать программистом и писать свой первый код, за который мне платили деньги. Примерно в 2001 году я стал руководить людьми и прошел путь от главного инженера до генерального директора, попутно попробовав себя в ролях CIO, CTO, CEO и даже преподавая проектный менеджмент. И все эти годы я постоянно проводил различные изменения.
Сейчас я работаю с командами разработки в качестве методолога продуктового подхода и практикую Канбан-метод. В этой статье поделюсь с вами своим опытом проведения изменений. А именно — практическими инструментами, которые сам использую почти ежедневно.
Жизнь вокруг нас меняется очень динамично, и не все изменения нам нравятся. Точнее, давайте так — не каждое изменение мы принимаем. Так что эта статья для большинства из нас. Для тех, кто восемь часов в день, как минимум, проводит на своей (конечно же, любимой) работе. Инструменты, которые я опишу, также подходят для планирования и проведения изменений в семейном кругу. Однако в этом случае нужно быть очень аккуратным, чтобы не навредить вашим отношениям. Кстати, я в браке уже 28 лет. Ребята, оно реально работает. Но, как говорится, это уже совсем другая история.
Так вот, про изменения. Задумывались ли вы когда-нибудь почему предложенные вами изменения не вызывают восторг у окружающих и остаются лишь мечтами, несмотря на то, что с вашей точки зрения они очень полезны? Но остальные, к вашему удивлению, почему-то так не думают и не спешат делать то, что вы задумали. Бывало?
Таск-трекер без бизнес-процессов ― деньги на ветер! Самая частая ошибка ― пытаться заводить задачи, не продумав сам процесс. В этом тексте показываем 6 универсальных процессов, которые можно внедрить буквально за 10 минут: от онбординга до работы с подрядчиками.
Привет, Хабр!
Если у вас в команде код-ревью — это унылое ожидание и пассивно-агрессивные комментарии уровня «не по канону», значит, что-то пошло не так. А если ревью не просто тормозит, но ещё и убивает мотивацию — то вы откладываете техдолг не только в коде, но и в культуре.
В 2025 году вопрос полноценной генерации продуктового кода с помощью LLM («вайб-кодинг») становится все более актуальным, но при этом остается и достаточно дискуссионным: насколько такие подходы вообще применимы в реальных проектах, действительно ли они сокращают время и стоимость разработки, и что происходит с тестируемостью и поддержкой такого кода в долгосрочной перспективе?
Сложность этого вопроса не только в качестве самой генерации, но и в том, как интегрировать LLM в инженерные процессы, чтобы получить управляемый, масштабируемый и архитектурно устойчивый код.
Моя мотивация была проста: попробовать выстроить полноценный продуктовый backend для нетривиального телеграм-бота с функциями агента (планированием, напоминаниями, памятью и проактивным поведением, возможностью дальнейшей расширяемости и интеграции сторонних сервисов), при этом — не писать руками ни строчки кода. Чтобы человек участвовал только как архитектор и асессор, а все проектирование и реализация шли через промпты в специализированные IDE-агенты (Cursor, Copilot, Codex, Zed) и LLM (как доступные через API/CLI, так и в «пользовательской» продуктовой обвязке).
Иногда тебе кажется, что ты обычный член команды, такой же винтик системы, как и все. Вы так же общаетесь с командой, у вас есть свои приколы, иногда очень жесткие. Ты так же ходишь с ребятами в бар и на квизы, часто скидываете друг другу мемы. Но однажды ты слышишь:
— Марина так сказала. Как самый важный довод при споре по рабочим вопросам, истина в последней инстанции. И тебя это пугает, потому что ты тоже человек, ты не хочешь, что бы они делали так, как ты сказала, а что бы сами подумали и нашли правильное решение. И тут до тебя наконец‑то доходит что твоем мнение не одно из равных, а самое значимое. И теперь тебе нужно очень внимательно следить за тем, что ты говоришь и насколько хорошо люди тебя поняли.
— И это после всего, что я вам рассказал? — я, конечно, уже слышал подобные заявления от потенциальных клиентов, но каждый раз удивлялся.
— Ну да. Зачем нам эти прототипы и функциональные спецификации? Я уже несколько проектов запустил со своей командой и точно могу сказать: никто документацию не читает.
— А как же вы ставите задачу на разработку?
— Пишу небольшую вводную — и всё. В основном, на словах объясняю. Я же каждый день с разрабами общаюсь. Да и сам немного программист. Мы же с вами оба понимаем, что этап проектирования — это просто способ для вас заработать дополнительных денег.
Внутри меня аж передёрнуло от этой фразы. Но виду я не подал и ненадолго задумался. На самом деле до сих пор не знаю объективного способа проверить, помогает ли проектная документация в разработке. Что не мешает мне искренне в это верить.
— Ну что ж, понимаю. Тогда давайте попробую вам рассказать одну небольшую историю…
