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

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

В статье мы разберемся с системой развития продукта на основе пользовательской обратной связи. Поговорим обо всем пути — от сбора отзывов по разным каналам до анализа и реализации.

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

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

Мы знаем, как это бывает: проект на Java 8 живёт уже десятый год, релизить страшно, тестов мало, миграция пугает, а система критичная. И вот бизнес хочет «ускорить и не трогать».

Всемогущий календарь, обзоры ИСУП, гибрид Гантта и канбана, эффективный баг-трекинг, вредная многозадачность, обзоры новых книг для лидов и ПМ и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

В «Сдобе» мы часто говорим про исследования, но редко затрагиваем тему, которая напрямую влияет на успех пользовательского опыта в программном продукте — качество этого продукта. Что это вообще такое, как касается не продактов и почему без заботы о нем сложно развивать сервисы?

Меня зовут Аня Серова – продакт в Контуре и экс UX-исследователь. В докладе на конференции ProdConf я делилась, как мы в Контуре подошли к теме качества программного продукта. В статье раскрою идеи из доклада с фокусом на пользу для всех ролей в продукте.

Продолжаю разбирать произведения классической литературы по Agile. В первой статье говорил о «Мёртвых душах» и «Преступлении и наказании», где герои использовали принципы Agile и им удавалось достигать результата. А в этой статье разбор неудачного кейса из «Евгения Онегина».

Привет, Хабр! Меня зовут Павел Новиков. Я руковожу группой разработки мобильных редакторов приложения МойОфис Документы. Мы реализуем его на Kotlin и Swift, и всё это – на базе кроссплатформенного C++17-ядра.

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

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

Казалось бы, чего может быть сложного: спроектировали, разработали, протестировали программную информационную систему и все, осталось только ее запустить в продуктивный режим эксплуатации, что обычно неоднократно репетируется. Но так ли это просто? Ответ положительный, если внедряется ERP-система на подразделении с небольшим числом конечных пользователей, уровень владения компьютером у сотрудников плюс-минус нормальный, все участники проекта сосредоточены в одной локации и, наконец, число специфичных требований к системе небольшое. Сейчас мы рассмотрели типовой проект внедрения корпоративной системы (далее – КИС).

Однако, бывают и более масштабные проекты, требующие более тщательного анализа и выбора вариантов запуска ERP-решения. Например, компания имеет распределенную географию работы, число конечных пользователей велико, часть из которых и компьютером то не пользовались, плюс ожидается, что КИС будет сильно кастомизирована под потребности заказчика. Здесь не получится взять и сразу запустить новое ИТ-решение на всех локациях и для всех пользователей. Хотя, нет, получится, но риск того, что все закончится провалом, достаточно велик. Как быть в этом случае? Необходима более разумная и согласованная со всеми стратегия запуска ERP-системы. Подобную стратегию называют по-разному: где-то концепция имплементации, в других источниках – стратегия развертывания, мы же будем называть ее стратегией внедрения.

Рассмотрим в текущей статье особенности стратегии внедрения ERP-систем, разработка которой обеспечит более взвешенный, осмысленный и, самое главное, менее рискованный ход запуска информационной системы на крупномасштабном предприятии. Для этого мы последовательно коснемся следующих вопросов: пилотные проекты, параллельные и последовательные запуски ИТ-решений, три базовых подхода ко внедрению и обработке неопределенностей.

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

Сколько нужно времени, чтобы команда сработалась? Мы проводим ретроспективы, 1-1, призываем внешних фасилитаторов, проговариваем планы и решения, но чего-то не хватает. Всё это попытки рационализировать — объяснить, как нам друг с другом работается. Но есть же и чувства, а их сформулировать сложнее.

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

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

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

Как использовать метрику потока Throughput и реалистично прогнозировать на основе симуляции Монте-Карло. Разберем динамику Throughput (пропускной способности) за значимые периоды времени, насколько она вариативна, посмотрим на кластеризацию по типам работы).

Разбираем метрику через обслуживание в пабе в пятничный вечер в сравнении с АйТи-командой (с паттернами и примерами). Тема довольно актуальная, так как сейчас в США и Европе расцвет прогнозирования на основе именно метрик потока и появляется много плагинов с Монте-Карло (но не все из них доступны в РФ).

Всем привет! Меня зовут Александр Антипин и я руковожу небольшой студией разработки. Мы разрабатываем мобильные игры и IT-решения для компаний. В этой статье я расскажу про IT Park в Узбекистане — место, которое сейчас активно обсуждают в айтишных чатах. Если вы думаете, что это просто хайп, то я попробую вас переубедить. За пару дней в Ташкенте я успел зарегистрировать компанию, открыть счёт, получить карты и даже съездить в Самарканд, чтобы проникнуться духом города с 2500-летней историей. Но обо всём по порядку: зачем вообще туда ехать, почему именно Узбекистан, какие бонусы даёт IT Park и как там живётся?

Полгода назад я испытал культурный шок. Всю карьеру — я QA Automation Engineer — пилил фичи в аутсорсе: стабильно, предсказуемо, местами даже комфортно. Но на январских каникулах впервые за долгое время задумался: мне скоро 30, я уверенный сеньор — а будто бы стою на месте.

Я просто включил «open to work» на LinkedIn — и неожиданно получил оффер в продукт. Пошёл на собеседование «чисто посмотреть» и остался.

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

Для тех, кто "чуть постарше" термин "индусский кодинг" (оно же "индусский код", "спагетти код") знаком не понаслышке. Штука как "мемная", так и настолько же вызывающая гнев/подгорание/ругань (выбрать по вкусу) при встрече в исходниках.

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

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

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

Не находите, что это все очень напоминает "что-то" происходящее вокруг вас, буквально сейчас? Вам уже говорили, что вайбкодер и ии-агент заменят вам программиста, и смогут "сэкономить много-много-денежек"?

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

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

"Что будет, если взять Канбан, смешать его с Гантом и весь этот соус вылить на релизную политику? Давайте разбирать на практике!"

25 августа в Торгово-промышленной палате РФ прошёл круглый стол на тему «Персонализированное здоровье будущего», в рамках которого был подписан Меморандум о сотрудничестве между ОП ЕАЭС и Российским новым университетом. Мероприятие организовано в рамках национального проекта «Продолжительная и активная жизнь», модераторами выступили председатель комитета Общественной палаты стран Евразийского экономического союза по Здравоохранению Карина Георгиевна Назарова и руководитель компании «Титул Тех» Ольга Юрьевна Симашкина.

В ИТ есть три роли, которые часто путают: Project Manager (PM), Product Manager (PdM) и Program Manager (PgM). Звучат они похоже, но задачи и фокус у каждой разные. Встречаясь с каждой из них в своей карьере, каждый раз возникало ощущение "дежавю". Оказалось "Вы не понимаете, это другое!" - разница есть. Понимание этой разницы помогает компаниям эффективнее выстраивать процессы, а специалистам правильно строить карьеру и лучше ориентироваться в сообществе.