Когда задачи есть, а движения — нет
Команда работает.
Задачи в трекере стоят.
Стендапы идут, код пишется, обсуждения кипят.
А результата всё нет.
Нет чувства прогресса, нет ощущения, что продукт становится ближе к релизу.
Итерации проходят одна за другой — а продукт будто топчется на месте.
Приложения для планирования и управления проектами призваны помочь нам успешно разрабатывать и поддерживать проекты в рамках нашего бизнеса. Сегодня, в эпоху цифровых технологий, когда все больше отраслей уходит в онлайн и все больше людей работают дистанционно, на рынке программного обеспечения для управления проектами царит настоящие изобилие. Но как понять, какие продукты действительно хороши, а от каких лучше держаться подальше?
Привет, Хабр! Меня зовут Денис Романов, и я руковожу подразделением Professional Services, которое сейчас занимается внедрением и поддержкой продуктов «Базис».
Когда я пришел в компанию несколько лет назад, ситуация в PS была непростой: процессы хаотичные, стандартов почти нет, разработчики тратят много времени на внедрение продукта вместо разработки, а уровень знаний о продуктовой линейке у моей команды оставляет желать лучшего.
За первый год мне и моим коллегам удалось решить практически все базовые проблемы. В первой части нашего цикла я поделюсь, как нам удалось привести подразделение в порядок, и что из реализованного сработало лучше всего.
Привет, Хабр! Меня зовут Эля, я исследователь в ecom.tech. В этой статье расскажу, как мы измеряли юзабилити приложения для курьеров‑партнёров, зачем мы это делали — и что из этого получилось.
Все давно привыкли к мысли, что приложения должны быть удобными в первую очередь для клиентов. Но как насчет курьеров‑партнеров Самоката, которые каждый день доставляют продукты? Мы в команде решили разобраться и замерить, насколько удобно приложение для курьеров‑партнёров. Ведь их комфорт и эффективность напрямую влияет на качество продукта в целом.
Статья на основе выпуска подкаста «Лида, где лиды?», где Стас Поломарь основатель платформы SEOWORK и эксперт в аналитике больших данных и SEO рассказывает о революционных изменениях в поисковой выдаче: борьбе Яндекса с маркетплейсами, эволюции динамических мест и новой реальности, где SEO-специалистам и контекстологам придется работать сообща.
Введение: почему AI-трансформация — это не мода, а конкурентное преимущество
В последние годы бизнес всё чаще сталкивается с вызовом: искусственный интеллект перестал быть “технологией будущего” — теперь это рабочий инструмент для роста, автоматизации и удержания позиций на рынке.
Однако во многих компаниях AI внедряется точечно и хаотично: разные команды пилят своих агентов, чат-ботов и интеграции, зачастую не зная о работе друг друга.
Результат — раздутые бюджеты, дублирование решений, высокий технический долг и замедление инноваций.
Почему так происходит, к чему это приводит и как навести порядок?
В этой статье — практический опыт и структурированный подход: как системно трансформировать компанию под AI, сделать бизнес AI-friendly и экономить ресурсы.
Для эффективной организации производства Информационных систем (ИС) требования должны стать каркасом, связывающим все этапы жизненного цикла ИТ‑продукта и передаваться от одной фазы к следующей, обеспечивая непрерывность и согласованность всего проекта. Так при реализации разработчики наделяют продукт функциональностью в соответствии с утвержденными требованиями. А тестировщики на основе спецификации требований разрабатывают план тестирования: к каждому функциональному требованию привязывают сценарии, тест‑кейсы и подтверждают, что готовое решение удовлетворяет требованиям, и так далее по цепочке.
Поэтому, когда спецификации требований разработаны и производство готово к переводу на этап реализации целевого продукта, крайне важно обеспечить надлежащий процесс приема/передачи инициативы команде разработки. Проектировщики не могут просто кинуть требования на стол разработчикам и считать свою часть работы выполненной. Процесс передачи должен быть регламентирован и по возможности соблюдаться.
Процедура передачи может регулироваться, например, управленческими правилами делегирования, а именно:
Привет! Я, Ева, руководитель продуктовой аналитики в М2, отвечаю за внедрение экспериментов и A/B-тестирования в компании. М2 — это онлайн-платформа для решения вопросов с недвижимостью. Сервисами М2 пользуются как частные лица, так и профессиональные участники рынка — риелторы, застройщики, банки. Мы помогаем тысячам людей экономить время, нервы и деньги.
Недавно мы завершили этап внедрения A/B‑платформы. Этот материал для тех, кто думает, как запустить эксперименты с ограниченными ресурсами, сохраняя здравый смысл.
В М2 достаточно компактная команда аналитики: 3 продуктовых и 4 digital-аналитика на 8 продуктовых команд. Эта статья про то, как небольшая компания может внедрить A/B-тесты и получить пользу даже с ограниченными ресурсами. Расскажем, как мы выбрали open source платформу GrowthBook, запустили MVP, обучили команду и выстроили процессы.
Почему пользовательские исследования — не опция, а must-have для продакта
В продуктовой разработке угадывать — дорого. А вот регулярно проверять гипотезы на реальных людях — разумно, эффективно и жизненно необходимо. Пользовательские исследования — не разовая активность, а непрерывный процесс, встроенный в цикл развития любого осознанного продукта.
Глава показывает, как интервью, опросы, юзабилити-тесты, A/B и поведенческая аналитика помогают команде на каждом этапе: от идеи до зрелого MLP. Поймёте, как собирать инсайты, формулировать гипотезы, отсеивать «влюблённые» идеи и запускать MVP без слива ресурсов.
Мы любим говорить: «Нужно делать CustDev». Или: «Нужно считать Юнит-экономику». Или: «Нарисуем CJM — и станет ясно».
Проблема в том, что эти артефакты часто делаются изолированно: JTBD не связывается с User Story, Юнит-экономика существует в вакууме, Use Cases живут отдельно от гипотез, а гипотезы накапливаются и становится непонятно, почему они появились именно в таком порядке.
В результате — знания есть, но целостной картины видения продукта нет.
Я уже ответила себе на этот вопрос, на кого учиться, но спустя 15 лет вернулась к нему как организатор магистратуры и точно вернусь позже как мать двоих детей. Расскажу, как выбирала профессию сама и как собирала обучение под специальность, которой до меня не было.
Вы сможете найти в статье лайфхаки, чтобы пройти собеседование на бесплатное обучение в магистратуре для продактов, и просто почитать про мой опыт: как я из ботаника мехмата добралась до банков и HR Tech.
Когда ключевой вендор ушёл с рынка, а готовые решения перестали справляться, у нас было два пути: искать костыли или написать свою систему. Мы выбрали второе — и за 2 года создали ACRM, которая не просто заменяет SAS, но и даёт новые возможности. Рассказываю, как мы проектировали систему с нуля, на какие грабли наступили и почему теперь не зависим от вендоров.
Меня зовут Иван Курбатов, и я руковожу направлением систем взаимодействия с клиентами в компании «Столото». Наша команда отвечает за разработку и поддержку CRM-систем, которые помогают нам общаться с миллионами клиентов через СМС, email-рассылки и push-уведомления.
Если вы ранее не сталкивались с деятельностью бренда «Столото», отмечу коротко, что это крупнейший распространитель всероссийских государственных лотерей. Организацией таких лотерей занимаются сразу два федеральных ведомства: Минфин и Минспорт, что накладывает на нас серьёзные обязательства. Наши решения должны быть максимально надёжными и бесперебойными, ведь мы отвечаем за доверие пользователей по всей стране.
Хотите узнать, как строится CRM-система с нуля, как она работает в масштабе миллиона клиентов и почему иногда лучше писать своё, чем адаптировать чужое — добро пожаловать под кат!
Если ваш стартап буксует, а продукт не летит дело может быть не в том, что он «ещё сырой». Проблема часто в том, как вы его продаете и кому. Вот мои выделенные топ 7 ошибок, которые вижу снова и снова от SaaS до консалтинга.
Каждую из них можно исправить. Начнём с самой банальной, но самой критичной.
В предпринимательстве часто так: занимаешься всем сразу и мечтаешь делегировать. У меня тот же случай: компания маленькая, и я, как говорится, и швец, и жнец, и на дуде игрец. Недовольство накопилось, и я решил разобраться, как оптимизировать дела, чтобы не затыкать дыры, а развивать бизнес.
Узнать это я решил с помощью простого инструмента. Всю неделю я записывал свои задачи и затраченное на них время. Следил за тем, что записать каждую мелочь и включал секундомер, чтобы считать не на глаз.
Так я увидел, на что реально трачу время. Много думал.
Несколько раз проходил в компаниях такую историю: сделали классный продукт для себя, решили, что он прекрасен и пришла гениальная идея, продавать его внешнему рынку. Успешных примеров у меня пока не было. Как правило, то, что было идеально для внутренних задач, при попытке вывода вовне превращается в совершенно новый проект, который зачастую проще переписать с нуля, чем адаптировать.
Знакомо?
Мне это напомнило мой недавний опыт. Пару недель назад был у родителей, у них на даче есть старая раскладушка. Используется редко, работала плохо, возможно производитель не предполагал, что на ней кто-то будет лежать с весом больше 20 кг. Когда на нее ложишься, практически достаешь до земли, спине неприятно, а еще ножки посередине гнутся.
«Я не боюсь того, кто изучает 10 000 различных способов управления. Я боюсь того, кто изучает один 10 000 раз». Выбрали по одному самому «смертоносному» инструменту планирования и управления, и объяснили почему.
Собрали 10 книг по управлению проектами. Каждая с выводами, которые руководители применяли на практике. Здесь — результаты от внедрения знаний из книг и подводные камни.
Запишите эту дату где‑нибудь между дедлайном релиза и списком багов: 7 июля 2025 года. Именно в этот день опубликован Федеральный закон № 214‑ФЗ, который усилил ответственность за нарушение исключительных прав авторов и владельцев интеллектуальной собственности в России. Срок до старта, казалось бы, комфортный — январь 2026-го. Но если вы когда‑нибудь пытались собрать согласования от трёх департаментов, то знаете: время разлетается, как кофе по клавиатуре. И на проработку и уточнение внутренней стратегии по защите активов не остаётся ничего.
Почему это вообще важно? Для айтишников, владельцев стартапов, компаний на стыке технологий и контента всё это — не просто юридический шум. Теперь даже небольшие недоработки в бумагах или халатное отношение к лицензиям обойдутся сильно дороже: многомиллионные компенсации, суды, заблокированные проекты, увольнения ключевых людей. Да, звучит как очередная страшилка. Но если вы хотите защитить свой продукт, команду и бюджет — пришло время разобраться и настроиться.
Всем привет! Меня зовут Макаров Иван, я руководитель программы Tech for Tech проектов в Magnit Tech. Последние 1,5 года мы реализуем масштабный технологический проект по выносу наиболее критичных информационных систем из единой платформы-монолита на выделенную инфраструктуру. Проект интересен своим масштабом и сложностью, и сегодня я расскажу, как мы справились с высоким уровнем неопределенности, скрытыми зависимостями, требованиями бизнеса и другими трудностями.
Сразу предупрежу: будет практика и честные выводы. И я был бы безгранично рад, если бы перед стартом проекта нашел и прочитал подобную статью.
Привет, Хабр!
На связи команда BIM‑координации в ПИК. Сегодня мы хотим рассказать, зачем вообще нужен отдельный сервис координации BIM‑моделей, как он устроен внутри и какие задачи решает на практике. Поделимся сложностями, с которыми сталкиваемся каждый день, и дадим несколько советов тем, кто хочет запустить похожий сервис.
Зачем нужен отдельный сервис BIM‑координации?
Представьте: утро, начало рабочего дня, от проектировщиков один за другим сыплются запросы: не получается обновить семейства; модель зависает — не можем синхронизироваться; нужно срочно проверить модель на коллизии — сегодня выпуск; плагин печати в PDF «не видит» штриховку; начинаем новый объект — срочно нужно создать модели и тд. Все эти задачи требуют немедленного реагирования и часто конфликтуют по приоритетам. Координатор начинает разбираться с одной, но тут же поступает срочный запрос на решение другой. Это приводит к тому, что в попытках разорваться между задачами, он теряет концентрацию, переключается туда‑сюда и в итоге не успевает качественно решить ни одну из проблем. Все это замедляет работу и повышает уровень стресса в команде.
Мы проанализировали и разделили поступающие задачи на два направления. Часть из них обрабатывает сервис BIM‑поддержки, который оказывает техническую помощь проектировщикам в использовании САПР‑программ, консультирует по работе инструментов и технологии BIM. Другую часть выполняет сервис BIM‑координации адресных объектов, который выступает связующим звеном для всех проектировщиков: помогает в создании моделей, поддерживает актуальность данных, отвечает за техническую координацию и следит за качеством информации.
Наш сервис управляет проектом с точки зрения BIM на всех этапах, минимизирует ошибки в документации, гарантирует соответствие корпоративным стандартам и делает командную работу по‑настоящему эффективной.
