Управление разработкой *

Я — Дмитрий, работаю продакт-менеджером в «Лаборатории Касперского». Это значит, делаю так, чтобы клиенты были довольны продуктом. Получается, мне нужно проанализировать рынок и конкурентов, составить стратегическое видение продукта, собрать запросы от заказчиков, понять их боли и сформировать бизнес-требования. Далее, соответственно, нарезать роадмап, подсветить и развить преимущества продукта, способного эти боли закрыть.

В статье поделюсь опытом, полученным в ходе работы над собственным некст-ген фаерволом «Лаборатории Касперского» — Kaspersky NGFW. Думаю, узнать о пути такого комплексного продукта от идеи до релиза может быть интересно как коллегам по ремеслу, так и ИТ-сообществу в целом. Особенно учитывая, что (как это часто происходит) конечный продукт существенно отличается от изначального концепта.

Привет! Меня зовут Мария Белых, я занимаюсь управлением изменениями более 10 лет.

Последние 5 лет я работаю в SM Lab и в роли методолога продуктового подхода и помогаю ИТ-командам повышать пропускную способность, сокращать время выполнения задач и избавляться от ложной нагрузки. Применяю канбан-метод, фасилитацию и командный коучинг. 

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

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

Это перевод статьи Des Traynor, сооснователя и Chief Strategy Officer в Intercom. Трейнор отвечает за стратегию компании 14 лет с момента её основания и делится опытом, проверенным на практике роста от стартапа до мирового SaaS‑лидера.

Этот текст попал мне в самое сердечко: в моей работе продакт-менеджера одна из самых сложных частей — это постоянно говорить "нет" клиентам и команде и выглядеть плохой в их глазах. Но текст Трейнора напоминает: хорошая стратегия продукта — это не про то, чтобы напихать всего подряд, а про умение держать фокус.

Не так давно в моем календаре появилась встреча под названием «Эффективность дизайнеров». И это выглядело как личное оскорбление. Мы всегда работали по спринтам, закрывали задачи, и вопросов к нашей эффективности ни у кого не возникало. До этого дня.

На встрече мне поставили задачу — разработать систему для подсчета производительности каждого дизайнера. Я была уверена, что это невозможно: разный профиль дизайнеров, разный объем проектов.

В каких таких попугаях я должна считать, насколько эффективно отрисовал дизайнер MES-интерфейс или сгенерировал картинки для сайта?!

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

Но я ошибалась. Это было не концом, а началом истории о том, как самая ненавистная и абсурдная идея превратилась в главный инструмент, который понятен бизнесу. Но при этом защищает, а не угнетает команду.

Привет, Хабр! Представьте: ваше приложение зависло на минуту. Если это интернет-магазин — пользователь просто перезагрузит. А если это система учёта, связанная с логистикой зерна, — остановится вся цепочка поставки, или клиент уйдёт в офлайн к привычным бумажным документам. В этом и есть главная разница между B2B и B2C.

В корпоративном мире каждый сбой бьёт не по одному человеку, а по целым бизнес-процессам. Упала система заказов — встали поставки. Глючит биллинг — компания не может выставить счета. Проблемы с интеграцией — парализована работа с партнёрами.

B2B-системы не работают с толпой — они работают с уникальными процессами каждой компании. У одного клиента простое согласование документа, у другого — 15 подписантов по строгой иерархии. Попробуйте втиснуть это в стандартную B2C-логику — провалитесь. Всё это требует не только высокой надёжности каждой операции, но и умения подстроиться под каждого клиента — предоставить ему кастомизацию.

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

В сентябре 1985 года Джон Бентли опубликовал книгу Programming Pearls — сборник афоризмов об истинах в программной отрасли.

Прошло сорок лет. Наверняка спустя множество революций в нашей отрасли они потеряли актуальность? Эти советы относятся к той же категории, что и «всегда держи при себе пучок сена для лошадей» или «карманный калькулятор не всегда будет под рукой».

Ох, какая наивность! Ничто не ново под луной. Почти все приведённые афоризмы болезненно актуальны.

Архитектура — основа любого IT-продукта. Для ее создания нужно видеть систему целиком, понимать требования бизнеса и учитывать бюджет. Но вот проблема: научиться думать как архитектор непросто. Нужно держать в голове десятки взаимосвязей и находить решения, которые будут жить годами.

Меня зовут Арина Николаева, я занимаюсь развитием архитектурного сообщества в MWS. Вместе с коллегами мы придумали Arch Kata — игру, которая позволяет попробовать свои силы: участники должны решить сложный бизнес-кейс, а наши эксперты оценят проект и объяснят, что в нем хорошо или не очень.

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

🚀 Как перестать бояться релизов и начать жить: практический гайд для тимлидов

Сбор практик для тех, кто хочет сделать доставку кода не болью, а удовольствием

Знакомая ситуация? Ваши релизы похожи на прыжок с парашютом без парашюта? Команда нервничает при каждом деплое, а бизнес теряет деньги из-за медленной доставки фич? Эта статья для вас.

Актуальность статьи: в современном мире скорость доставки фич — это не просто модный тренд, а вопрос выживания на рынке. Компании с быстрой доставкой обгоняют конкурентов по доходам на 20–40%.

Цель исследования — показать, как технические и управленческие практики влияют на ключевые бизнес-метрики и уровень счастья команды. Мы делимся реальным опытом из агротех-разработки.

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

Trunk-Based Development сокращает время доставки на 30%

Feature Toggles делают релизы безопасными

Left-shifting тестирование снижает время восстановления с 15–20 часов до 1 часа

Kanban превращает хаос в прозрачную систему

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

P.S. Если вы всё ещё релизите раз в квартал — эта статья поможет вам пересмотреть свои подходы к разработке. 🎯

Вы, наверное, слышали, что тесты — это хорошо, что тесты надо писать. И, возможно, даже согласны с этим.

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

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

За свой многолетний опыт лидерства мне уже трижды удавалось построить команды с настоящим полностью автоматическим тестированием. Это когда нажал кнопку и через короткое время, увидев зеленые тесты, точно знаешь, что все работает. Без ложной скромности, скажу, что очень‑очень мало кто из лидов любого уровня может таким похвастаться. Нельзя сказать, что мало кто пытался, но путь этот тернист и полон коварных ловушек. Поэтому давайте вместе разбираться, как в них не попасть.

Серия: Чем болен средний бизнес? Статья 6.LLM + ДРАКОН: доступный инструмент процессного управления для МСБ

Предыдущая статья:Чем болен средний бизнес? Статья 5. Нейро-символический ИИ: прорыв в управлении или очередной хайп?

Классические BPM-проекты дороги, сложны и часто проваливаются в МСБ. Вы получаете схемы, которые никто не понимает, и зависимость от консультантов, а хаос остается.

В этой статье мы разбираем прагматичный подход, доступный уже сегодня:

LLM как аналитик: Используем нейросети для быстрого анализа «цифровых следов» процесса (почта, CRM, логи) и выявления узких мест.

ДРАКОН как интерфейс: Превращаем выводы LLM в наглядные и понятные схемы, которые может прочитать любой сотрудник, а не только IT‑специалист.

Человек как архитектор: Показываем, как на основе этих данных принимать управленческие решения и моделировать улучшения.

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

[Искусственный интеллект*] [Управление процессами*] [Визуализация данных*] [МСБ*]

Выродивщийся аджайл, карты Уордли, метод MOSCOW, канбан‑каденции, НФТ, закон Хофштадтера, топ-10 канбан‑досок, запретные слова для ПМов, рынок вакансий, управление кросс‑функциональной командой и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

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

Основная обратная связь для Взрослого — это положительное подкрепление, которое тоже должно отвечать определенным критериям.

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

Положительное подкрепление — это любая форма поощрения сотрудника за эффективное поведение. Так как положительное подкрепление приносит удовольствие сотруднику, он стремится как можно чаще повторять те действия, за которые его поощряли, следовательно положительное подкрепление — это инструмент развития эффективного поведения. При этом важно понимать, что положительное подкрепление имеет такое результативное действие потому, что оно как раз направлено на Мотивационные факторы по Фредерику Герцбергу: Признание, Самостоятельность, Рост и развитие, Достижение и Реализация в Работе. То есть все те факторы, которые относятся к факторам развития эффективности деятельности сотрудников.

Кстати, практически все они относятся к нематериальной мотивации. Эффективный руководитель понимает, что именно нематериальная мотивация его основной инструмент развития своей команды и что варианты такой мотивации безграничны.

Всем привет! Это спецпроект "Три трюка" от ИнженеркиТех, где мы разговариваем с CTO об их пути и подходах к управлению инженерными командами.

Мы любим мифы про CTO: всезнающий технобог, который одним глазом смотрит архитектуру, вторым следит за продакшеном, а параллельно растит команду как дзен-мастер. На деле все одновременно проще и сложнее.

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

Сколько и куда инвестировать в дев-инструменты и платформу, как считать отдачу от оптимизаций (хоть от снижения CPU), и где гонять тесты — на пресабмите или на интеграции? Простых ответов нет. В этой статье я предлагаю целостную модель баланса между затратами разработки и создаваемой ценностью с учётом рисков: успех продукта, продуктивность команды, эффективность ресурсов и стратегические возможности. Дам практичные ориентиры для продактов, инженеров и менеджеров, а также покажу, как инфраструктура и архитектура сдвигают этот баланс и где именно выгодно усиливать автоматизацию и проверки.

Всем привет! На связи команда Центра разработки решений ALM‑стримов «ALM 2.0 Платформа» и «Динамическое моделирование баланса». В этой статье расскажем, как в нашей компании создаётся современная ALM‑система: на основе импортонезависимых решений, с расчётным ядром на Spark/Hadoop и интуитивно‑понятной интерфейсной частью на React/Java/Postgres. Ещё расскажем, как устроены витрины, где живёт логика и как запускаются пользовательские расчеты.

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

В какой‑то момент я понял: так дальше нельзя. Поэтому сделал инструмент, который берёт на себя рутину анализа резюме и превращает хаотичный поток откликов в понятный список реально сильных кандидатов. В статье я рассказываю, как к этому пришёл, что получилось и почему считаю, что автоматизация в HR — это уже не фишка, а необходимость.

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

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

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