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

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, так и в «пользовательской» продуктовой обвязке).

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

— И это после всего, что я вам рассказал? — я, конечно, уже слышал подобные заявления от потенциальных клиентов, но каждый раз удивлялся.
— Ну да. Зачем нам эти прототипы и функциональные спецификации? Я уже несколько проектов запустил со своей командой и точно могу сказать: никто документацию не читает.
— А как же вы ставите задачу на разработку?
— Пишу небольшую вводную — и всё. В основном, на словах объясняю. Я же каждый день с разрабами общаюсь. Да и сам немного программист. Мы же с вами оба понимаем, что этап проектирования — это просто способ для вас заработать дополнительных денег.

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

— Ну что ж, понимаю. Тогда давайте попробую вам рассказать одну небольшую историю…

Обычно я пишу про статический анализ, баги и оформление кода. Однако сейчас меня притянуло к тематике РБПО (разработка безопасного программного обеспечения). Это связано с тем, что статический анализ является одним из основополагающих процессов безопасной разработки.

Всё началось с цикла публикаций про ГОСТ Р 56939-2024 в моём Telegram-канале "Бестиарий программирования". Мой внимательный читатель Виталий Пиков из УЦ МАСКОМ, увидев это, пришёл и сказал: "А давай больше!" Он предложил запустить целый цикл совместных вебинаров, где последовательно разобрать все 25 процессов, описываемых в ГОСТ Р 56939-2024. И идея мне понравилась.

Привет! Меня зовут Вадим, я техлид команды разработки платформы кеширования в Газпромбанке. Хочу рассказать о том, как внедрили, использовали и улучшали Trunk Based Development, совершили все возможные ошибки, но в итоге получили то, что хотели — быструю и надежную разработку. Cycle time у нас теперь около одного дня, по одному сервису больше 30 деплоев в месяц, и команда больше не боится пятничных релизов.

Если коротко про TBD — это подход к разработке с одной интеграционной веткой (trunk), куда все делают мердж-реквесты несколько раз в день. Никаких долгоживущих feature-веток, никакого git-flow с develop.

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

Что общего у руководителей, которые говорят:

– На рынке слишком много кандидатов-фродеров, которые вписывают фейковый опыт в резюме, обманывают меня на интервью и в итоге на синьорских позициях в моей команде работают джуны?

– Мне досталась слабая команда, я ни на кого не могу положиться и целыми днями тону в рутине, а сам не расту?

– Меня постоянно подводят смежники, факапят каждый инициированный мной проект?

– У нас в компании слишком размытые цели, я не понимаю, чего хотят от меня и моей команды?

Нет, не невезение.

Общее у них – непринятие ответственности и недостаточная зрелость.

Привет! Меня зовут Гульдар Ахунзянова, и я тестировщик в Яндекс Смене. В статье хочу рассказать о теме, которая может показаться банальной: как превратить рабочий хаос в управляемый порядок. Но за этой банальностью скрывается важная мысль: если вы тестировщик, у вас есть реальный инструмент, чтобы сделать жизнь (и свою, и команды) проще, понятнее и предсказуемее. И этот инструмент — процессы.

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

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

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

Компании уделяют много внимания внешнему виду сайта и его юзабилити. Это действительно важно, но в погоне за красотой нельзя упускать главное: сайт должен быть производительным и устойчивым к высоким нагрузкам. Подготовили для вас гайд, с которым получится обезопасить сайт от перегрузок в высокий сезон — на основе нашего опыта работы с Ариель.

Почему даже сильные разработчики делают на авось?

Команда вроде опытная, но в проде — баги, архитектура — костыль на костыле, а фичи заливаются «на нервах»?

Всем привет! С вами Леша Жиряков, и сегодня я затрону тему планирования и Agile.  Недавно кластер/трайб/холдинг, в котором я работаю, проходил трансформацию методов работы, все началось с идеи: а давайте сделаем продукт более открытым. С одной стороны, бизнес требует предсказуемости и возможности строить долгосрочные стратегии, с другой — рыночная турбулентность и подводные камни в IT диктуют необходимость быстрой адаптации к меняющимся условиям. 

Это противоречие особенно остро проявляется при столкновении традиционного многолетнего планирования с гибкими Agile-методологиями, призывающими «реагировать на изменения важнее, чем следовать плану».  Открытость, гибкость, скорость, эффективность, надежность — вот критерии успешного продукта.  Но, развивая надежность, сложно оставаться гибким, повышая эффективность, рискуешь потерять в скорости, а стремление к открытости может снижать безопасность.

Классическое долгосрочное планирование на год и более даёт стратегическую перспективу, но часто оторвано от реальности быстро меняющегося рынка и технологий. Двухнедельные спринты позволяют гибко адаптироваться к изменениям, но затрудняют видение большой картины и координацию масштабных инициатив. Где же золотая середина?

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

В 1985 году учёный Питер Нур будто зрил в будущее, написав свою работу под названием «Programming as Theory Building», которая сегодня стала весьма актуальной. Мы всё чаще видим, как начинающие разработчики бездумно принимают сгенерированный ИИ код, который толком не понимают, а кодовые базы разрастаются лишёнными теоретических основ реализациями. В свете всего этого чётко вырисовывается основная идея Нура: «программа – это не её исходный код».