В этой статье — 7 типовых рабочих процессов, без которых не обходится ни одна команда. Показываю, как за 10 минут собрать под них канбан-доски, которые реально повысят эффективность работы.
Привет! На связи снова Саша Симоненко, операционный директор Xilant. Сегодня разбираем конкретные методики написания безопасных требований: INVEST, SMART, What-If и misuse cases. Чтобы быть в контексте, зачем они нужны и какую проблему решают, рекомендую начать с первой части трилогии — о том, как неточные формулировки становятся уязвимостями и где в SDLC теряется безопасность.
Привет Хабр! Рано или поздно на горизонте появляется одна из важных метрик в разработке — time to market или TTM, которая напрямую может влиять на все процессы внутри компании. Хочу поделиться примером, как мы снижали TTM в команде и почему это было, с одной стороны, непросто, а с другой стороны — интересно.
Привет! Меня зовут Константин Архипов, и я работаю в МТС скрам-мастером. Это довольно креативная должность, связанная с практикой применения гибких методологий: если работать хорошо, то все идет гладко, и моя работа как будто и не видна. При этом она критически важна для того, чтобы каждый в команде чувствовал себя комфортно и мог спокойно делать свое дело. Я совмещаю ее с еще одной ролью — агента изменений. Обо всем этом сегодня и расскажу!
Узнали, почему Lamoda — одно из самых недооценённых мест для разработчиков и как компания ломает их карьерные предубеждения.
Этот текст для компаний, занимающихся аутсорсом и аутстаффингом. Продвигая статический анализ кода в целом и инструмент PVS-Studio в частности, мы отдельно не выделяем компании этой направленности. Сейчас, в связи с вступлением в силу 1 марта 2026 года приказа №117, всё немного по-другому.
Всем знакома ситуации, когда на планёрке команда решает, какие задачи взять в следующий спринт, и с одной стороны — есть запрос на новую фичу, а с другой стороны — нужно обновить зависимости, пока это не стало проблемой. Но в этом и состоит сложность: если работает, то зачем трогать? Возможно, вы уже знаете, в какой момент технический долг приведёт к поломке, но ваши аргументы игнорируются. Дискуссия превращается в громкий спор, где побеждает не самый веский аргумент, а самый настойчивый голос. В итоге принимается решение, которое оставляет вас с чувством, что к вашей экспертизе не прислушались.
Эта статья — для тех, кто хочет изменить формат обсуждений, чтобы узнать обо всех рисках решения и пожеланиях команды. При этом не увеличив, а сократив время совещаний. Мы разберемся, как за минуту понять реальный уровень согласия в команде и выявить невысказанные сомнения, прежде чем риски реализуются. И как создать такое пространство для обсуждения, где даже самый сдержанный инженер сможет донести свои аргументы, обогатив общую картину. Речь пойдет о практических инструментах для улучшения качества коммуникации.
В этом рейтинге обновлены: Gemini 3, GPT 5.1, GLM 4.6, Kimmi K2.
Некоторые условия эксперимента:
Мы продолжаем нашу серию статей, посвящённых фундаментальным концепциям разработки. Сегодня мы поговорим о проверенных практиках, которые помогают разработчикам избегать распространённых ошибок и работать эффективнее. Мы разберём принципы SOLID, а также парадигмы YAGNI, DRY и KISS, которые особенно актуальны в объектно-ориентированном программировании.
Привет! Меня зовут Мария Аркуша, я продакт-менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте.
Есть такое мнение, что ретроспективы — пустая трата времени и бесполезное передвигание карточек. Сегодня я попробую доказать вам, что это мнение в корне неверно и из ретроспектив можно (и нужно!) извлекать огромную пользу. Припас для вас несколько не попавших под NDA кейсов и приемов, которые мы сами применяем в командах разработки. Поехали!
Привет, Хабр. Я старший android-разработчик и скрам-мастер. За годы работы я видел десятки команд, которые относились к ретро как к обязаловке, и столько же тех, которые превратили их в мощный инструмент развития. Разница между ними была не в размере команды или сложности проектов, а в понимании одного простого принципа.
Рефакторинг исторического кода с переходом на сервисную архитектуру напоминает игру в дженгу — надо аккуратно перестроить существующий проект и не сломать его. Но если вы меняете архитектуру с учётом жёстких требований PCI DSS в финтех-проекте, то одновременно с игрой в дженгу вам нужно балансировать на шаре и решать сложные уравнения. В этом мы убедились на собственном опыте.
Меня зовут Анатолий Яшкир. Я руководитель разработки финтеха ВКонтакте. В этой статье расскажу о специфике финтеха и нашем кейсе рефакторинга исторического кода с переходом на сервисную архитектуру.
План задач вроде расписали, поручения распределили по приоритетам — а через неделю дедлайны уже плывут, команда выгорела, а половина задач ушла на следующую неделю. Кажется, что все под контролем, но то задачи недооценили, то коммуникации встали, то внезапно сменились приоритеты.
Почему так происходит, что такое спринты и как они помогают команде двигаться быстрее, а не сгорать по пути? Разбираемся вместе с редакцией Kaiten.
Примерно год назад журналисты спросили меня
— Валерий, а как вы объясните нынешнюю стагнацию на рынке труда в айти?
Кажется, это было связано с этим обзором, но точно не помню. Признаться, я тогда не нашелся, что ответить. Но эфир был прямой, бесконечно затягивать не получалось и я ляпнул
— Возможно, это связано со все большим проникновением технологий искусственного интеллекта в индустрию...
Мой ответ не нравился мне уже тогда, а сейчас я понимаю, где был неправ.
Работа над онбордингом помогла нашей команде вырастить активацию в 2,5 раза.
Процесс работы занял больше полугода, а некоторые действия были совершенно бессмысленными. Делюсь своими выводами по итогам работы, чтобы сэкономить время другим командам, занимающимся этой областью продукта.
Рассказываю, когда онбординг делать не нужно, как подойти к этому процессу, какие инструменты использоавть.
Какие практики бывают в разработке и эксплуатации, и как их внедрять? И как масштабировать практики и оценивать их с помощью метрик? Какие сложности можно встретить на пути?
Привет, Хабр! Меня зовут Евгений Харченко. Моя роль в Райффайзен Банке — руководитель отдела по развитию практик в разработке и эксплуатации. А еще уже пять лет я — Senior Community Lead DevOps, хотя начинал с роли инженера тех. поддержки ServiceDesk. Еще я — член программного комитета DevOpsConf.
В этой статье по мотивам моего доклада для конференции Highload++ будет много примеров, историй и ретроспективы того, как мы в компании развивали технические практики и инженерную культуру.
2026 год на пороге. Искусственный интеллект уже не модное словосочетание, а коллега. Copilot подсказывает код в IDE, а ChatGPT помогает с архитектурой. Но наши подходы к найму техспециалистов всё ещё застряли между допросами и бесконечными этапами, которые отнимают время, но не показывают реальных навыков.
Меня зовут Григорий, я разработчик. За последние несколько лет я прошел десятки собеседований с обеих сторон: и как кандидат, и как интервьюер.
Эта статья — не истина в последней инстанции. Это скорее диалог. Предлагаю порассуждать, каким должно быть техническое собеседование в 2025 году с учётом соврeменных реалий.
Привет! Как и обещал, вторая часть доклада про то, как проводить быстрый аудит разработки без изучения кода (первая тут). Так как весь аудит по своей сути — это качественно поговорить и позадавать нужные вопросы, чтобы потом сделать выводы, то поговорить стоит и про более низкоуровневые вещи, такие как трекер задач, количество багов, метрики, используемые командой, и процесс разработки. В привычном по предыдущей статье формату «Хорошо / Плохо».
Метрики
Количество клиентских багов
Помните фильмы, где главный герой лежит в больнице, подключенный к кардиомонитору, и там на экранчике бежит график сердцебиений? Когда график вытягивается в прямую линию, значит, всё грустно и главный герой умер.
Так вот, с клиентскими багами такая же история. Это пульс продукта. Если в метриках их ноль — то это самое страшное. Это значит, что продукт или вообще не используется, или что клиенты никогда не запускали его.
Нет, конечно, есть исключения, когда какой-то продукт присутствует в компании чисто для галочки. Такое может попадаться в сфере информационной безопасности — например, клиент с точки зрения закона обязан купить какое-то ПО, но никто не будет проверять, используется этот софт на самом деле или нет. Скажем, купила компания антивирус, чтобы соответствовать требованиям регулятора, и просто положила его на полку — aka «бумажная безопасность». При таком подходе вообще без разницы, что там делает разработка — можно ее хоть уволить всю. Захочется ли вам работать в такой компании — это уже отдельный вопрос.
Итак, отсутствие багов — это плохо. Хорошо — это когда они есть, причем динамика изменений может быть любой, главное, чтобы это имело под собой какое-то логическое объяснение.
Есть три вида писем, которые могут испортить блаженную субботу: уведомление безопасности, предупреждение об отключении электричества и, очевидно, повторное напоминание о том, что вы задолжали облачному провайдеру один цент — да, именно $0,01. Услугами DigitalOcean я пользуюсь с 2013 года, хотя для личных задач я этот сервис использую редко, просто авторизуюсь несколько раз в неделю для обеспечения поддержки моих клиентов на этой платформе.
Методы Монте-Карло и швейцарского сыра, статистика в оценке сроков, замена Jira, вредные советы планирования, управление техдолгом, типология руководителей, борьба с микроменджментом, правильный онбординг и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
