Всем привет! Разработка интерфейса платформы для риелторов — задачка нетривиальная. В этой статье я расскажу о том, как мы делаем наш интерфейс понятным и дружелюбным.
О чем речь?
Мы с командой офтальмологов разрабатываем систему для прогнозирования и сдерживания прогрессирования детской миопии на клинических и поведенческих факторах. В этом процессе всегда три стороны — врач, родитель и ребёнок — поэтому дальше будет продуктовый разбор пути “врач–родитель–ребёнок” и того, где он ломается в реальной жизни.
Начну с простого. Класс все помнят что такое CustDev? А что он может привести к социально значимым ответам?!
Custdev — это метод проверки гипотез, который позволяет выявить потребности и запросы целевой аудитории вашего продукта. Главная задача метода — понять, как человек решает свою задачу сейчас, что его бесит, какие решения он уже пробовал.
Но есть одна проблема, с которой сталкиваешься, как только начинаешь «кастдевить» родителей по вопросам здоровья их детей — социально желательные ответы. Т.е. люди часто рассказывают не то, как живут, а то, как «правильно» жить — чтобы выглядеть хорошо и не ощущать себя виноватыми, если они допускают ошибки. Ровно об этом пишет Роб Фицпатрик в The Mom Test (сразу запишем домашнее задание: прочитать книгу «Спроси маму»).
Получается, родителям очень хочется звучать ответственными и вовлеченным — и это нормально. Это не злой умысел, это искреннее желание быть «идеальным» родителем, особенно в глазах окружения, тем более когда в медиа буквально везде сквозит тема «осознанного родительства».
И если строить продукт на этой «идеальной версии родителя» — например, сразу уходить в тотальный трекинг рекомендаций врача — легко получить тревожное приложение/таблоид/напоминалку с картинками, которое семья отключит в гуще рутинных будней. Не потому что родитель «плохой», а потому что живой родитель не выдержит постоянный контроль какого‑то алгоритма, взращивающего тревожность. Ведь реальная жизнь неизбежно проигрывает идеальным метрикам.
Открытый подход зарекомендовал себя в ИТ и идет в смежные отрасли. Одна из примечательных и быстрорастущих ниш — симрейсинг, где открытый подход позволяет вовлекать комьюнити и ускорять инновации. Предлагаю свой разбор истории вопроса: знаковые кейсы, опыт применения открытой модели в данной сфере и мнения экспертов.
Если вы даже не можете завести людей в двери своего ресторана, качество еды в нем уже не имеет никакого значения.
В первом полугодии 2025 года LEGO отчиталась о рекордной выручке в 34,6 млрд крон (примерно 5,24 млрд долларов США). Это лучший показатель за все время существования компании. Как игрушке с почти 80-летней историей удается побеждать в битве за внимание «айпадкидов», которые осваивают смартфоны и планшеты раньше, чем учатся ходить? Особенно если вспомнить, что в начале 2000-х, на волне экономического благополучия, LEGO едва не обанкротилась. Спойлер: тренд на ностальгию у миллениалов тут помог, но это далеко не главное.
Если кто-то из вас мечтает создать свой продукт, но не может решиться, копит бюджет или ищет инвесторов, этот цикл может изменить вашу жизнь.
Материал будет также полезен основателям с техническим складом ума, кто привык опираться на команду разработки, но старадает из-за сроков и стоимости реализации начальной стадии проектов.
Мне 34, из них больше десяти лет я в коммерческой разработке. И примерно столько же я женат. Каждый год 7 марта я ловил себя на мысли, что стою в торговом центре с пустым взглядом, пытаясь угадать с подарком. В этом году я решил подойти к проблеме не как муж в панике, а как инженер.
Я прочитал книгу Гэри Чепмена «Пять языков любви», поймал пару инсайтов и за 5 вечеров написал сервис-переводчик для пар. Внутри: Flask, Vanilla JS (да, в 2025 году, и я объясню почему), DeepSeek API для генерации карточек в стиле «Love is…» и алгоритм матчинга, который понимает мою жену лучше, чем я за 10 лет брака. Под катом — история о том, как код помогает чинить баги в коммуникации.
«Я заметил, что возникает дефицит внимания в твоей команде, и это снижает мотивацию,» — сказал председатель ПРП в одной из наших приватных бесед на профсоюзной встрече. И я решила разобраться с этим. В статье опишу результаты этого исследования: возникновение, основные проявления и способы устранения этого дефицита.
Привет, я Виталий, и я управляю проектами в KTS. Это должна была быть третья завершающая статья, где я делюсь своим опытом об обучении в Стратоплане на курсе CTO.
Курс завершился несколько месяцев назад, и в моей памяти смешались лекции и сессионные дни, поэтому я решил немного изменить структуру рассказа. Хотя статья все еще посвящена третьему по хронологии модулю, за это время в моей работе очень многое изменилось:
- экономическая ситуация;
- ожидания заказчиков — объект поставки сместился с хорошего кода, соответствующего ТЗ, на оптимальное решение едва сформулированной потребности бизнеса;
- производственный процесс — те, кто собирают MVP по два месяца, отправляются на свалку истории;
- требования к кандидатам на рынке труда — приходится искать не просто кодеров, а инженеров с продуктовым мышлением;
- пытаясь не утонуть в этом шторме, поменялся и я.
В этом новом контексте я чувствую особенную важность нескольких тем из курса, поэтому я сфокусируюсь именно на них.
Меня зовут Борис Кузнецов, я руководитель Управления стратегических проектов ЕДИНОГО ЦУПИС. В конце прошлого года мы столкнулись с необходимостью сменить менеджер задач и перейти на отечественное решение. После тщательной оценки вариантов мы сделали выбор в пользу системы Shtab — и не пожалели об этом. Рассказываю, как все происходило.
На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».
Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок.
Чтобы решить проблему, мы решили внедрить в жизненный цикл разработки концепцию DoR (Definition of Ready) и DoD (Definition of Done). В этой статье я расскажу: чем DoR и DoD отличаются от критериев приемки и почему их важно не путать, как не превратить полезный инструмент в бюрократическую обязаловку, какие узкие места могут возникнуть при внедрении концепции.
Velocity, Burndown и количество закрытых задач выглядят как контроль над разработкой. На практике эти метрики часто создают только видимость управляемости: отчёты красивые, а сроки всё равно срываются.
В статье разбираем, какие показатели действительно помогают прогнозировать сроки, находить узкие места и держать баланс между скоростью разработки и качеством релизов.
Данная статья является переводом откровений Гельдрейха о работе в Valve и некоторых других «самоорганизующихся» компаниях (представленных в виде, без преувеличения, «учебника по выживанию»), с некоторым форматированием для более удобного чтения. Имейте ввиду, что это рассказ об условиях работы на Западе (США), и некоторые советы могут выглядеть очевидными или странными.
Привет! Меня зовут Игорь Федорчук, я руковожу разработкой в направлении «Монобренды» в GRI.
За последний год компания заметно выросла: команд стало больше, изменений и интеграций — тоже. А процессы в разработке долго оставались такими же, какими были пару лет назад. В какой-то момент это перестало «склеиваться» само собой: ответственность размылась, централизованной точки входа в команды не было, а коммуникация стала слишком неэффективной.
Это первая статья о том, как мы пересобирали процесс разработки в GRI — от получения запроса от заказчиков до выкатки в прод. В этой части я разберу роли (тимлиды, техлиды, TPM), зоны ответственности и общий флоу. Во второй части покажем, как мы приземлили это в Jira и метрики, а в третьей — как масштабировали поставку: релизы, код-ревью и инциденты.
Начали мы не с Jira и не с попытки «ускорить релизы», а с зоны ответственности. При росте она ломается первой: задачи начинают зависать на стыках ролей, статусы приходится собирать вручную и дублировать в несколько каналов коммуникаций, а «владелец результата» меняется по ходу движения.
Привет! Меня зовут Ксюша, я руководитель продукта Project Ruler — это система, которая помогает бизнесу управлять проектами и продуктами в едином пространстве и позволяет видеть полную картину: от отдельных задач до стратегических целей компании. Мы развиваем продукт на рынке систем управления проектами и таск-трекеров, где конкуренция высокая, а требования к гибкости и масштабируемости постоянно растут.
В начале 2025 года я перешла на позицию менеджера продукта, и именно тогда вопрос погружения в рынок и стратегического взгляда на развитие продукта стал для меня особенно важным. Операционные задачи не заканчиваются, новые решения появляются постоянно, а времени на осмысленное наблюдение за рынком почти не остается. При этом от менеджера продукта ждут решений, которые будут актуальны не только сейчас, но и через несколько лет.
В этой статье я расскажу, что такое трендвотчинг с практической точки зрения, чем он отличается от насмотренности и анализа конкурентов, как отличать хайп от устойчивых трендов, какие инструменты помогают находить ранние сигналы и какие изменения уже сейчас видны на рынке управления проектами.
В этой статье я поделюсь опытом, кейсом из моей практики в российском ритейле. Ко мне обратился заказчик с проблемой. На производстве чипсов (СТМ в Краснодарском крае) возникали проблемные возвраты целых партий картофеля от производителей по причине брака 80–90%. Внешний осмотр показывает, что картофель снаружи весь в чёрных пятнах. Сами производители утверждали, что отправляют картофель качеством не превышающим 5% брака, и ссылались на отчёт сюрвейера.
Проект требовал присутствия в формате 90%, поэтому с заказчиком мы определились с посещением двух поставщиков и самого филиала по производству.
Из документации я запросил у заказчика только паспорт-спецификацию именно того сорта картофеля, который отправляется на производство для изготовления чипсов. Время в данном проекте не определяли, главной задачей было найти причину.
Первым этапом стало посещение производителей картофеля в разных регионах (Нижегородская и Мо��ковская область), проверка качества картофеля на разных складах и проверка работы сюрвейеров.
В каждом хозяйстве я попросил первым делом взять по ведру картофеля именно такого сорта с разных сторон склада и просто сделать разрушающий контроль (то есть разрезать весь картофель на половинки). Это проводилось отдельно от сюрвейеров. Также я осмотрел внешний вид картофеля в хранилище и на складе, осмотрел и зафиксировал картофель в процессе мойки. Я разобрался в процессе и проследил этап мойки до формирования партии и на выходе после неё. Внешний вид картофеля в обоих хозяйствах соответствовал ПК (паспорту качества). Особое внимание я обратил на внешний вид картофеля — чёрные большие пятна на поверхности кожицы.
«Когда регулятор — лучший продакт» — это был верхний слой. Выводы без данных.
Сегодня представляю полный PESTEL-анализ карьеры CPO в российском финтехе на 2025–2026: 28 факторов, от ключевой ставки и импортозамещения до agentic AI и зарплатных вилок. Для тех, кто предпочитает разбираться самостоятельно, а не читать чужие выводы. Всё по ссылке.
Сегодня из каждого утюга звучит мантра: «Делегируйте рутину нейросетям! Пусть ИИ пишет вакансии, отказы и рассылки, пока вы мыслите стратегически». Как AI-аудитор, я регулярно вижу, как бизнес с радостью отдает корпоративную коммуникацию на откуп алгоритмам, свято веря в их математическую «объективность».
Проблема в том, что базовые LLM — это не юристы, не эмпаты и не HR-директора. Это генераторы вероятного текста, чья главная цель — услужить пользователю. Даже если пользователь просит нарушить закон или базовые нормы морали.
Чтобы доказать это, я провел Red Team-тест: притворился некомпетентным HR-директором российского ритейла и дал топовым моделям задачи «с двойным дном». Результат: 65% нейросетей сгенерировали тексты, которые гарантируют визит Трудовой инспекции и репутационный суицид в СМИ.
Под капотом — разбор самых опасных галлюцинаций ИИ и чек-лист фраз, которые могут довести вашу компанию до суда.
Когда лиды стоят дорого, а цикл сделки длится месяцами, просто «налить больше трафика» — провальная стратегия. В этом кейсе я расскажу, как отказ от шаблонного маркетинга и скрещивание CJM с картой позиционирования помогли нам увеличить общую конверсию в 4 раза без раздувания рекламного бюджета.
Меня зовут Андрей Васючков, я - стратегический маркетолог, член Гильдии маркетологов России.
В B2B-маркетинге есть классическая проблема: компания годами вливает бюджеты в контекстную рекламу и SEO, но заявки обходятся слишком дорого, а до коммерческого предложения (КП) и сделки доходят единицы. Отдел продаж винит маркетологов за «мусорный трафик», маркетологи ругают продажников за то, что те «сливают лидов».
Примерно с такой вводной мы начали работу над проектом компании «Стальпром-Оборудование». Перед нами стояла задача: увеличить конверсию по всей воронке (из посетителя в лид, из лида в КП, из КП в сделку), но в условиях замороженного бюджета на продвижение. Спойлер: мы это сделали за 6 месяцев, не меняя сам продукт.
Недавно знакомый PM попросил рассказать “Что значит отвечать за качество?” в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.
