Менеджмент

Agile-методологии, основанные на манифесте 2001 года, стали краеугольным камнем современной разработки программного обеспечения (ПО) благодаря своей гибкости, ориентации на клиента и способности адаптироваться к изменениям. В России, где IT-сектор демонстрирует устойчивый рост Agile остается доминирующей парадигмой. Однако экономические вызовы, включая санкции, импортозамещение и нестабильность (инфляция 6,2% в апреле 2025), а также технологические сдвиги, такие как интеграция искусственного интеллекта (AI) и DevOps, порождают вопросы о будущем Agile. Действительно ли принципы Agile теряют популярность в российской разработке ПО? Если да, то что приходит на замену?

Российский IT-сектор уникален: он сочетает стремительный рост (CAGR 12% в разработке ПО) с ограничениями. Это стимулирует переход к локальным аналогам и гибридным методологиям. В то же время глобальные тренды, такие как автоматизация через AI и рост DevOps влияют на локальную практику. В этом контексте важно понять, сохраняет ли Agile свою актуальность или уступает место новым подходам, и как российские компании адаптируются к этим изменениям.

Иван с силой скомкал распечатанный макет нового интерфейса. Бумага хрустнула, как лед под ногой. Он швырнул искалеченный лист на полированный стол, где уже громоздилась целая стопка таких же — испещренных его правками, сделанными красной ручкой, словно ранами. Ни одна из них не привела к прорыву.

За окном переговорной сгущались сумерки, а в пустом офисе царила гулкая тишина, нарушаемая лишь гулом его ноутбука. Тишина, которая делала отчаяние почти физически ощутимым. Он остался один после очередного еженедельного совещания, которое, как и десятки до него, превратилось в театр одного актера.

Всем привет! Меня зовут Александр Пряхин, я технический руководитель в Авито Подработке. В этой статье я рассмоатриваю подходы к измерению качества стабильной работы системы, а не только её отказов. Я постараюсь описать, что такое бюджет качества и почему его стоит считать; как SLA, SLO и SLI помогают наводить порядок и принимать решения; и главное – почему техническое качество напрямую становится зоной ответственности тимлида и как через метрики команда может начать говорить с бизнесом на одном языке.

CRM создаёт иллюзию контроля: карточки есть, статусы двигаются, отчёты красивые. Но если менеджер забудет сделать звонок или назначить встречу — клиент уходит к конкурентам. Мы решили проверить, можно ли что-то с этим сделать.

Настало время для третьей и финальной части "запрещенки": фраз, которые хочется сказать, чтобы защититься от злых заказчиков, начальников и их необоснованных претензий, и которые никогда не помогают, а делают коммуникацию только хуже. В каждой части я беру несколько таких фраз, разбираю, как они НЕ работают, почему, и что лучше говорить вместо них.

В прошлых статьях я прошелся по фразам:

Часть один: «Этого нет в ТЗ!» и «Этого нет в моей должностной!»
Часть два: «Мы проговаривали!» и «У меня нет ресурсов!»

И сегодня я пройду по оставшимся. Там будут и совсем гиблые и вполне приемлемые, которые просто надо использовать осторожно.

Вы открываете приложение «на минутку», через полчаса понимаете — залипли. Это не магия и не слабая сила воли, это хорошая работа интерфейсов. Они устроены так, чтобы держать внимание и не отпускать.

В прошлой статье я показывал, как главная страница решает судьбу продукта. Теперь — о приёмах, которые работают после неё. Они незаметны, но именно они удерживают нас внутри экрана.

Период 2020–2021 годов характеризовался двумя на первый взгляд разнонаправленными, но синхронными процессами. С одной стороны, Федеральная резервная система США инициировала беспрецедентную по масштабам программу количественного смягчения (QE), что привело к экспоненциальному росту денежной массы и притоку ликвидности на финансовые рынки. С другой стороны, Народный банк Китая и другие регуляторы КНР последовательно ужесточали политику в отношении криптовалют, кульминацией чего стал полный запрет на майнинг и транзакции в 2021 году.

В момент, когда нужно было готовить релиз, мой мозг отказался работать. Я мог час крутить задачи в трекере, сорок минут решать, на какие письма ответить. Даже перед автоматом с едой я стоял по пять минут и уходил голодным.

Мне нужно было срочно придумать, как перезагрузить голову.

Добрый день, уважаемое сообщество Хабра! Я тимлид, и сегодня хочу поделиться с вами опытом поиска работы в 2025 году. Это первый раз в жизни, когда я искал новую должность, уже будучи лидом. В последнее время тема поиска работы всесторонне рассматривается с точки зрения разработчиков. Но как новые предложения ищут лиды?

Предлагаю вам вместе со мной посмотреть на ключевые особенности рынка вакансий лидов в России. Моё мини‑исследование не претендует на объективность: только одно (ладно, два) резюме и только один всем известный сайт поиска работы. Однако можно понять некоторые общие закономерности и обсудить то, как видят нас, лидов, наши потенциальные работодатели. Ну и поделиться друг с другом своими историями в комментариях.

Если вы лид, либо смотрите в эту сторону, а также если вы HR, приглашаю вас дальше.

Привет, Хабр!

Многие команды однажды замечают, что оценочные сессии превращаются в рутину, а прогресс всё не торопится улучшаться. Парадоксально, но именно так родилось движение #NoEstimates — отказ от традиционных оценок времени и переключение на метрики, основанные на реальных данных. Вместо гаданий «сколько времени займёт фича» мы смотрим на поток работы и используем его показатели для планирования.

Концепция #NoEstimates во многом объяснена в публикациях старожилов Agile. Оценки всегда неточны, обычно очень сильно. Единственный случай, когда оценка может сработать — это когда вы строите то же самое снова. Во всём остальном мире — где постоянно что‑то меняется — тратить время на приблизительные расчёты бессмысленно. Гораздо важнее смотреть на реальные показатели команды: скорость выполнения задач, время их прохождения и т. п. Холуб дальше замечает, что планировать «строгие» сроки — это пережиток водопадной модели, а Scrum‑фреймворк даже не требует от команды жёсткого commit«а на объем работ: в Scrum говорят о прогнозах (forecast), а не о фиксированных обязательствах.

Я знал одну компанию, которая занималась продажами В2В и В2С. У них было интересное правило: раз в неделю менеджер имел право послать одного клиента на три буквы, высказать ему матом всё, что захочется, нагрубить в своём стиле и бросить трубку. Директор компании считал это невероятной инновацией и проявлением демократичного стиля управления. Мне эта традиция не нравилась: во-первых, всегда можно расстаться по-человечески, а во-вторых, 7 менеджеров, 50 рабочих недель в год, это 350 посланных клиентов с очень высоким уровнем негатива. Даже если «право» реализуют в 10% случаев, это 35 потенциальных носителей отрицательных отзывов (и это минимальный из рисков). 

Но что интересно: во многих компаниях нет таких эпатажных руководителей, но это не отменяет того, что продажники и клиентские менеджеры ненавидят клиентов, игнорируют их, а иногда и просто сливают. Да, клиенты бывают непростыми и некоторые реально заставляют поседеть и охрипнуть, но…стоит ли переживать? Возможно, важно выстроить диалог.

Привет, Хабр!

Использование OSS‑компонентов — стандарт современной разработки. Под OSS‑компонентами мы понимаем ПО с открытым исходным кодом. Это могут быть приложения, библиотеки, набор файлов, или даже просто фрагмент кода.

Но при использовании OSS есть нюанс — лицензии. Одни библиотеки можно брать без оглядки, другие требуют платежей, а третьи — строгого соблюдения условий. И если в бэкенде зачастую все относительно статично (версии меняются редко, компонентов немного), то веб — отдельная история. Тут компоненты множатся с космической скоростью, версии обновляются каждую неделю, и следить за всем этим вручную просто нереально.

В этой статье расскажем о том, как мы формируем реестр OSS‑компонентов и какие инструменты помогают нам быстрее проверять лицензии и формировать единый список компонентов.

Потерянные версии документов, поиски актуальных планов и отчетов, несоответствие статус проекта и реального состояния... Такое знакомо многим и менеджерам проектов, и спонсорам, и командам (которые считают, что проще написать заново). Дело не в плохих людях, а в отсутствии системы, которая учитывает статусы и этапы проектов.

Так как придумывать контент оказалось задачей не простой, а придумывать СТОЯЩИЙ контент почти невыполнимой, а писать тем не менее что-то хочется, то я немного снижу планку своего перфекциониста.

И пока вокруг все разговаривают про гендерное неравенство в разных областях и сферах работ, я бы хотела поисследовать, что делать со сложными проектами, которые идут сразу не туда, куда хочется и не так, как нужно.

В целом, редкие проекты строго двигаются к своим запланированным и четко сформулированным целям, а какой-то хаос в предстоящих итерациях стоит закладывать сразу, смело отводя на него внушительную долю запланированного времени. А еще здорово, когда выстроены процессы ОТ и ДО, но как мы все знаем, суровая реальность далека от идеала. Поэтому аки фокусник тебе так или иначе придется выполнять разные роли и задачи из разных областей рабочих обязанностей. Потому что, если ты архитектор или инженер, то какие-то мелкие договоренности о встречах, адресах или настройках легче проводить самостоятельно и глупо дергать РП (если вообще таковой на проекте имеется) для каждой фиксации мелочи, а с другой стороны где-то надо искать грань, когда количество времени на организаторскую работу превышает мыслимые и немыслимые пределы и вместо архитектурной или инженерной работы (на какую ты собственно и договаривался словами через рот) ты занимаешься какой-то сплошной тратой времени, когда вот эти мелкие задачи занимают настолько много времени, что становятся скорее рутиной, нежели неприятным, но быстрым обязательством, которое ускорит достижение цели, сократит человекочасы, потраченные на проект и в целом поможет сделать все хорошее, против всего плохого.

Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я — Д«Артаньян, а все остальные — редиски.

OpenAI впервые раскрыла реальную статистику использования ChatGPT: 73% запросов не связаны с работой

Компания OpenAI опубликовала первое масштабное исследование поведения пользователей ChatGPT, проанализировав 1,5 миллиона реальных диалогов за период с мая 2024 по июнь 2025 года. Результаты оказались неожиданными и развенчали многие мифы об использовании ИИ.

Ключевые выводы:

700 млн пользователей в неделю - каждый десятый взрослый житель планеты

73% запросов личные, только 27% связаны с работой (год назад было 50/50)

Женщины обогнали мужчин - 52% vs 48% пользователей

Программирование - всего 4,2% от всех запросов (а не основное применение, как многие думали)

Три главные категории: практические советы (29%), поиск информации (24%), создание текстов (24%)

Неожиданные факты:
→ В развивающихся странах ChatGPT растет в 4 раза быстрее, чем в богатых
→ 10% всех обращений - это обучение и репетиторство
→ Больше половины "письменных" задач - редактирование существующих текстов, а не создание нового контента

Исследование показало, что ChatGPT превратился из нишевого инструмента для программистов в массовый помощник для повседневных задач - от рецептов до домашних заданий.

Однажды я записался на ProductCamp, придумал игру, которая была бы моим вкладом в команду «развлечений», не нашел свободных слотов, не поехал, но идею той игры полюбил и начал развивать.

Эта статья посвящена описанию вариации Spaghetti Challenge (далее Спагетти Челленджа) — игры для вечеринок, корпоративов, тимбилдингов, мастер‑классов по управлению, инженерному мышлению и кооперации.

Описанная версия игры добавляет в классический Спагетти Челлендж новую роль: Продуктологов. Участники в этой роли тренируются преподносить свои идеи и продавать их Строителям, и сразу смотреть: решают ли их продукты проблемы, и какую пользу они приносят.

Говорите по‑русски: не «OPEN» а «ОТКРЫТО». Ваш код — следующий? Всем коммитить по‑русски!

порассуждаем о будущем

Мы решили встроить ИИ в систему управления проектами и посмотреть, что из этого выйдет. Спойлер: получилось лучше, чем мы ожидали.

Сегодня речь пойдёт о том, как превратить приблизительные оценки сроков выполнения задач в надёжные прогнозы, и о том, как рассказывать об этих прогнозах другим.

Оценка сроков выполнения задач — это важное дело. Но, в то же время, подобные оценки доставляют массу неприятных эмоций множеству инженеров и программистов. Оценки сроков являются источником напряжения, которое возникает между командами разработчиков и всеми теми, кто так или иначе с ними взаимодействует. Это — менеджеры, другие отделы компаний, клиенты.

Всё дело в том, что почти все до сих пор неправильно рассказывают другим об этих оценках.