#продуктовая_разработка — Public Fediverse posts

# Capacitor: от веба к мобильным приложениям. Часть 6. Встраиваем Capacitor в native-приложение

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

https://habr.com/ru/articles/1099904/

#javascript #android #гибридные_приложения #мобильные_приложения #ios #typescript #продуктовая_разработка #capacitor

«Вопрос к дизайну))» – или как я получил опыт работы в ВК без трудоустройства

TL;DR. Полтора месяца я делал тестовое задание для ВК Подарков. Больше трети моих вопросов продакту вернулись с ответом «Вопрос к дизайну))». Пока я рисовал свою версию фичи, похожая появилась в самом приложении. После трех итераций и двух раундов правок мне отказали. Логика без вопросов, не дотянул визуал. Ниже вся история и мой вывод – тестовые пора хоронить и переходить на вайтборд.

https://habr.com/ru/articles/1093822/

#продукт #найм #тестовое_задание #продуктовая_разработка #продуктовый_дизайн #тестовое

Когда кончаются 5-часовые лимиты, я иду на обед. Когда недельные, обьявляется выходной?

Я один делаю Кубыш , приложение для личных финансов на iPhone, а код пишет ИИ-агент. У которого два лимита: на 5 часовые и на недельные. За несколько месяцев выяснилось, что они неплохо заменяют тимлида и кадровиков. Получается:

https://habr.com/ru/articles/1092312/

#продуктивность #ии #swift #ios #продуктовая_разработка #codex #llm #claude #солоразработка #ииагенты

Откуда пришли установки iOS-приложения без SDK атрибуции: спецстраницы App Store вместо UTM

Я делаю Кубыш, приложение для учета расходов и накоплений на iPhone: оно считает, сколько можно тратить в день до зарплаты и когда накопишь на цель. Пишу о нем на Дзене , vc.ru , в LinkedIn и соцсетях - подписывайтесь пожалуйста. После каждой публикации хотелось понять одно: что из этого приводит людей в App Store. На сайте эту задачу решает UTM-метка. В App Store так не получится: параметры ссылки до приложения не доходят. SDK атрибуции для маленького приложения избыточен: еще одна зависимость и передача данных третьей стороне. Поэтому я посчитал источники стандартными средствами Apple. Ниже как это настроить и на чем я обжегся.

https://habr.com/ru/articles/1091374/

#App_Store #App_Store_Connect #атрибуция #custom_product_pages #индиразработка #ИИ #LLM #iOS #Swift #продуктовая_разработка

20 лет спустя, или как я все-таки выпустил свое странное социальное приложение

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

https://habr.com/ru/articles/1078028/

#карта_эмоций #геолокация #мобильная_разработка #солоразработка #стартап #социальная_сеть #продуктовая_разработка #личный_опыт #релиз_приложения #релиз

Почему разработка постоянно выходит за сроки и как исправить это с помощью Shape Up

Команды часто пытаются ускорить разработку через новые оценки, больше контроля и подробные планы, но задачи всё равно растут, сроки сдвигаются, а бэклог превращается в список невыполненных обещаний. Shape Up предлагает другой взгляд на планирование: вместо оценки объёма вводится «аппетит» — ограниченный бюджет времени, под который команда адаптирует решение. Разберём, как работает этот подход, из каких этапов состоит цикл и почему правило «проект закрывают через шесть недель» помогает принимать более жёсткие решения. Читать разбор

https://habr.com/ru/companies/otus/articles/1081850/

#Shape_Up #управление_разработкой #продуктовая_разработка #гибкие_методологии #Agile #планирование_проектов #управление_задачами #приоритизация #командная_работа #процессы_разработки

Скорость разработки кода перестала быть дефицитом. Дефицитом стали денежные идеи

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

https://habr.com/ru/articles/1084374/

#ииагенты #ииразработка #продуктовая_разработка #идеи_для_стартапов #сезон_код_будущего

Как перенести навайбкоженный проект в Figma через Claude Code и получить дизайн‑систему

Знакомая ситуация: продукт написан за выходные, гипотеза подтвердилась, кто‑то уже платит. Приходит дизайнер и просит файл. Файла нет. Есть интерфейс, который существует только в виде кода. Кнопка там называется.btn‑primary,.btn‑add и.button‑save — три класса, одна кнопка, паддинги отличаются на пиксель. Серый цвет записан тремя способами, и один из них, судя по всему, опечатка. Отдать это дизайнеру нельзя. Нарисовать заново — значит выбросить полгода работы и начать спорить про радиусы. Мне стало интересно, что тут реально может AI. Не «сделай красиво», а честный замер: я собрал маленькое демо, намеренно заложил в него шестнадцать несогласованностей, записал их в отдельный файл и спрятал. Потом запустил на этом коде свежую сессию Claude Code, которая файла с ответами не видела. В статье — что из этого вышло, с цифрами и с местами, где всё сломалось.

https://habr.com/ru/articles/1074204/

#claude_code #figma #интерфейсы #продуктовая_разработка #ииагенты

Хочешь сделать лотерею — думай «как лотерея», или Почему пять месяцев Discovery без требований — это правильно

Или как один лотерейный билет превратился в несколько сотен требований, десятки интеграций и пять месяцев Discovery. Когда мне предложили заняться разработкой с нуля цифрового сервиса Альфа‑Мании, я была уверена, что понимаю задачу. Что может быть проще? Клиент открывает мобильное приложение банка, выбирает лотерейный билет, оплачивает его, ждет розыгрыш и, если цифры в лотерейном билете совпали — получает выигрыш. На первый взгляд всё выглядело как вполне стандартный цифровой продукт: несколько экранов мобильного приложения, интеграция с партнером, немного аналитики, немного CRM‑коммуникаций и привычная продуктовая работа. Я никогда так не ошибалась. Через несколько месяцев я уже обсуждала особенности прогрессивной шкалы НДФЛ, разбиралась в требованиях к онлайн‑кассам, участвовала в проработке процессов идентификации победителей и спорила с коллегами о трактовке отдельных пунктов законодательства о лотереях. При этом ТЗ всё ещё не было. Наверное, это первый проект в моей карьере, где мы сознательно не писали бизнес‑требования почти пять месяцев. Но не потому что не успевали или не хватало ресурсов, и уж точно не потому что не умели писать BRD. Просто довольно быстро стало понятно, что писать требования к тому, чего ты сам пока не понимаешь — самый быстрый способ построить неправильный продукт. Поэтому вместо того, чтобы открывать шаблон BRD, мы начали исследования. Именно тогда я поняла, что самые сложные продукты начинаются не тогда, когда команда не знает решения, а тогда, когда она практически ничего не знает про предметную область. Об этом я и расскажу. Эта статья про discovery. Про исследования, важность которых часто недооценивается.

https://habr.com/ru/companies/alfa/articles/1069320/

#Discovery #управление_продуктом #продуктовая_разработка #CJM #Customer_Journey_Map #бизнестребования #финтех #клиентский_опыт #АльфаМания

Почему я перестал верить, что хороший продукт можно придумать заранее

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

https://habr.com/ru/articles/1067556/

#продуктовая_разработка #MVP #пользовательское_поведение #UX #продуктовые_гипотезы #user_research #product_discovery #WorkHub

COUNT(DISTINCT food), борщ и немного Менделеева

Я хотел добавить в пищевой дневник одно число: сколько разных растений человек съел за неделю. Четыре строки Kotlin — пока не выяснилось, что непонятно главное: что именно считать разным? Помидор и черри — один продукт или два? Сырой и запечённый шпинат? Три грамма петрушки в борще? Разбираю, как простой COUNT(DISTINCT food) превратился в три инструмента: недельный счётчик, карту пробелов из 14 направлений и рейтинг продуктов по 24 показателям. Внутри — исследования пищевого разнообразия, проверка устойчивости расчёта и три борща одинаковой массы, которые система видит совершенно по-разному.

https://habr.com/ru/articles/1066892/

#пищевое_разнообразие #питание #нутриенты #healthtech #визуализация_данных #продуктовая_разработка #пищевой_дневник #микронутриенты #мобильное_приложение #пищевые_метафоры

Как плохой UX в B2B-продукте приводит к потере денег

Раньше часто сталкивался с мнением, что дизайн в B2B вообще не нужен. Мол, Figma можно исключить из процессов и всё делать в коде. Одна проблема: рынки развиваются, сервисы эволюционируют и людям стал доступен качественный дизайн во многих сферах. Поэтому B2C-опыт стал активно влиять на B2B.

https://habr.com/ru/articles/1064446/

#дизайн #b2b #b2bсервисы #crm #дашборды #управление_проектами #продуктовая_разработка

Сейчас будет горячо: нагрев iOS-устройств как продуктовая метрика

В какой-то момент разработки приложение становится достаточно зрелым, а команда достаточно большой. Или наоборот. Тогда кто-то решает, что пора собирать метрики: Crash Rate , Hitch Rate , время холодного запуска, потребление памяти, сетевые ошибки. Организуются красивые дашборды, пишутся аккуратные отчеты, ставятся четкие квартальные цели. Все довольны. Пока не придет технический директор и не спросит: Интересный вопрос

https://habr.com/ru/articles/1062824/

#swift #thermal_state #нагрев #мобильные_приложения #аналитика_мобильных_приложений #пользовательский_опыт #ios #продуктовая_разработка

Продуктовый разработчик 2026: кто это, откуда берётся и что с ним делает ИИ

Долгое время — да и до сих пор в большей части индустрии — в разработке цифровых продуктов существовал привычный порядок вещей: бизнес или продакт придумывает идею, передает ее аналитику, тот — архитектору, и только потом задача доходит до разработчиков и QA. Каждый делает свою часть работы, передавая друг другу артефакты. Но есть компании, которые освоили концепцию продуктового разработчика. Такой человек сфокусирован не только на закрытии задач по ТЗ, а еще стремится донести дополнительную пользу и глубоко погрузиться в бизнес. Где-то говорят про T-shaped специалиста, где-то уже — про M-shaped. Мы решили разобраться в этой роли с точки зрения более-менее прикладного контекста через опыт людей, в чьих командах такие специалисты либо уже есть, либо внедряются.

https://habr.com/ru/articles/1062608/

#продуктовая_разработка #продуктовый_разработчик #управление_разработкой #управление_командой #разработка_продукта #продуктовый_подход #продуктовый_менеджмент

Построение нормальной системы эскалаций

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

https://habr.com/ru/companies/otus/articles/1058188/

#эскалация #принятие_решений #управление_конфликтами #распределение_ответственности #межкомандное_взаимодействие #управление_рисками #полномочия_команд #RAPID #DRI #продуктовая_разработка

Как я год строила SaaS и только потом поняла, что разработка — не самая сложная часть

Это статья о том, почему написать SaaS оказалось проще, чем превратить его в продукт. После университета я начала искать первую работу разработчиком. Вакансии для начинающих почему‑то не выглядели вакансиями для начинающих. Я читала требования, понимала, что многого не умею, нервничала всё сильнее, а потом решила сделать собственный проект — конструктор магазинов. Уже звучит как начало чего‑то плохого. Идея была такой: владелец отправляет токен своего Telegram‑бота, мой сервис подключает к нему команды и витрину. Покупатели открывают его бот‑магазин внутри Telegram, собирают корзину, оформляют заказ. Владелец управляет всем через отдельный Mini App.

https://habr.com/ru/articles/1059336/

#SaaS #Telegram_Mini_Apps #Telegramботы #FastAPI #PostgreSQL #мультитенантность #ecommerce #продуктовая_разработка

PRD для AI-фичи в 2026 году: что класть в спецификацию помимо привычных user stories

Первая AI-фича часто ломается задолго до релиза — ещё на этапе, когда команда пытается описать, что именно она собирается делать. Привычного PRD с user stories и acceptance criteria уже недостаточно: поведение LLM зависит от промпта, модели, данных для оценки и множества граничных случаев. В статье разбираем, какие разделы стоит добавить в спецификацию AI-продукта, чтобы команда понимала, как измерять качество, контролировать риски и принимать решения после запуска. Разобрать подход

https://habr.com/ru/companies/otus/articles/1054610/

#ai #продуктовая_разработка #управление_продуктом #PRD #промптинжиниринг #оценка_качества_моделей #разработка_продуктов #AIфичи

Как я построил сервис аренды квартир без риелторов, довел его до прибыли и почему всё равно закрыл

Когда я переехал из Санкт-Петербурга в Москву, то, как и тысячи людей, первым делом столкнулся с вполне обычной задачей, найти съемную квартиру. После нескольких просмотров подходящий вариант наконец нашелся. Мы подписали договор, и оставалось только передать деньги. Помимо первого месяца аренды и залога нужно было заплатить комиссию агенту, сумму, равную еще одному месяцу проживания. Именно в тот момент у меня возник простой вопрос: Почему вообще арендатор должен платить посреднику, если владелец квартиры и будущий жилец вполне способны найти друг друга самостоятельно? Разумеется, подобная мысль приходила в голову не только мне. Поэтому следующим вопросом был уже продуктовый: Если проблема настолько очевидна, почему ее до сих пор никто не решил? Эта идея не превратилась в проект за один вечер. Несколько недель я просто наблюдал за рынком, анализировал существующие сервисы и пытался понять, где именно возникает ценность посредника и можно ли часть этой ценности заменить цифровым продуктом. Со временем первоначальная эмоция превратилась в гипотезу. Если создать удобную площадку, на которой владельцы квартир смогут публиковать объявления напрямую, а арендаторы быстро находить такие предложения без комиссии агентствам, то, возможно, спрос на такой сервис окажется достаточно высоким. На тот момент это была всего лишь гипотеза. У меня не было инвесторов, команды или готового бизнес-плана. Был только вопрос, на который хотелось получить честный ответ: Нужен ли вообще людям такой продукт? Именно с поиска ответа на этот вопрос началась история сервиса «Сдаре».

https://habr.com/ru/articles/1057140/

#стартапы #продукт #продукт_менеджмент #продуктовый_дизайн #продуктовая_разработка #продуктовая_аналитика #продуктовое_мышление #продуктовая_стратегия #продуктовый_маркетинг #продуктовая_команда

Как мы превратили 700 студентов‑гуманитариев в продуктовые команды и получили 51 MVP за 8 недель

За два месяца более 700 студентов‑гуманитариев создали 51 цифровой продукт и 19 проектов по Data Science. При этом самой сложной задачей для них оказалось не освоение технологий искусственного интеллекта, а понимание пользователя и формулирование продуктовой гипотезы. Чем дешевле становится разработка благодаря AI, тем выше становится ценность специалистов, которые умеют видеть человеческие проблемы, работать с мотивацией, поведением и пользовательским опытом. Возможно, именно поэтому следующая волна AI‑продуктов будет рождаться не только в инженерных командах, но и в аудиториях психологических и педагогических факультетов.

https://habr.com/ru/articles/1049666/

#продукт #продуктивность #продуктовый_дизайн #продуктовая_разработка #продукт_менеджмент #zerocoding #ai #обучение #обучение_программированию #образование

Иннерсорсинг в Островке: как мы перестали ждать чужой бэклог и ускорили delivery на несколько кварталов

Знакомая ситуация: вашей команде нужна фича в чужом сервисе, вы ставите задачу — и ждёте. Неделю, месяц, квартал. Потому что у того сервиса свои приоритеты и свой ограниченный ресурс. А ваш продукт стоит. В Островке мы столкнулись с этим в масштабе: сразу несколько продуктов зависели от одного большого внутреннего сервиса, который физически не мог обработать все запросы. Решением стал иннерсорсинг — подход, при котором команда сама пишет нужный ей код в чужом репозитории . За два года в одной из наших команд через иннерсорсинг прошли 22 проекта разного объёма. Часть задач, которые раньше могли ждать несколько кварталов в чужом бэклоге, теперь удаётся доводить до релиза за один квартал. Взаимодействие с принимающим сервисом стало предсказуемее: появились понятные правила, зоны ответственности и точки синхронизации. Под катом рассказываем, как у нас устроен иннерсорсинг: какие правила мы зафиксировали, где столкнулись с проблемами и что стоит предусмотреть перед запуском такого процесса. Статья может быть полезна тимлидам, чьи команды зависят от других сервисов; разработчикам, которым предстоит иннерсорсить; и руководителям, которые ищут способ ускорить кросс-командное взаимодействие без дополнительного найма.

https://habr.com/ru/companies/ostrovok/articles/1049140/

#иннерсорсинг #innersource #delivery #code_review #ownership #продуктовая_разработка #техдолг

Почему мы так уверенно решаем не те задачи

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

https://habr.com/ru/articles/1048890/

#системное_мышление #системный_анализ #бизнесанализ #управление_продуктом #принятие_решений #процессы #ТРИЗ #продуктовая_разработка

IT-ретейнер для ресторанной сети: как за 7 месяцев запустить 6 цифровых продуктов

Ресторанная сеть из 10 заведений обратилась с первичным запросом на доработку Telegram Mini App. В процессе стало понятно, что задача шире: компании нужен не отдельный подрядчик под приложение, а внешний продуктово-технический контур, который сможет развивать несколько цифровых продуктов, поддерживать инфраструктуру, закрывать интеграции и сопровождать эксплуатацию. За 7 месяцев работы были запущены 6 продуктов:

https://habr.com/ru/articles/1041256/

#itразработка #продуктовая_разработка #telegram_mini_app #ai_automation #rag #управление_itкомандой #цифровая_трансформация #devops #интеграция_систем #itинфраструктура

Telegram Mini App для ресторанов: бронирования, IIKO, CRM, Grafana и Telegram API в одной системе

Ресторанный холдинг с 10 ресторанами использовал первую версию Telegram Mini App как интерфейс, через который гости могли ознакомиться с заведениями сети. На следующем этапе потребовалось усилить IT-направление: увеличить скорость разработки, стабилизировать систему, расширить функциональность и связать приложение с операционными процессами ресторанов. В результате Telegram Mini App вырос в полноценный цифровой контур, который объединяет бронирования, мероприятия, меню, банкеты, сертификаты, кулинарию, коммуникацию с гостями, аналитику, админ-панель и интеграции с внешними системами. На текущем этапе система стабильно держит 11 000 MAU, включает более 200 функций, работает с Remarked, IIKO, RocketData, CRM, Telegram API и внутренними API заказчика. В процессе эксплуатации также была отражена атака на серверы заказчика.

https://habr.com/ru/articles/1040020/

#telegram_mini_app #telegram_api #iiko #crm #grafana #автоматизация #backend_development #интеграция_api_опросов #продуктовая_разработка #ai

Спектр. Контекст создания, трудности, боли и победы

20 апреля мы официально сообщили на широкую аудиторию, что ведём разработку собственного аналога Figma и Pixso — Спектр, а также открыли приём заявок на закрытое бета-тестирование. И сейчас отличное время, чтобы поделиться с сообществом историей разработки продукта, взлётами и падениями, трудностями и победами. Узнать внутрянку

https://habr.com/ru/articles/1031322/

#дизайн #продукт #продуктовая_разработка #продуктовый_дизайн #продукт_менеджмент #ретроспектива #внутренняя_кухня #спектр #pixso #figma

SaaS умирает? Я сравнил 8 публикаций Q1 2026 с тем, что вижу внутри Kaiten

Последние месяцы я вижу одну и ту же мысль: SaaS умирает, AI-агенты забирают работу из интерфейсов, а компании перестают платить за пользовательские лицензии. На первый взгляд кажется, что так и есть. Если агент может сам прочитать CRM, создать задачу, разобрать заявку, сходить в API и принести руководителю готовый статус, зачем держать десятки людей в системе? Пусть машина сама делает работу, а человек только проверяет. Но когда смотришь на это изнутри SaaS-продукта, картина выглядит по-другому. Я работаю в Kaiten — мы делаем платформу для задач, проектов, документов, заявок и процессов. То есть находимся ровно в той модели, которую сейчас принято хоронить. Последний год показал, что хоронить рано. Но и делать вид, что ничего не меняется, уже странно.

https://habr.com/ru/companies/kaiten/articles/1040650/

#SaaS #AIагенты #LLM #корпоративный_софт #автоматизация #управление_проектами #рабочие_процессы #продуктовая_разработка #B2B_SaaS #AI_в_бизнесе

Слабоумие и отвага: как я за выходные сделала прототип ИИ-помощника для UX-дизайнера

Привет, Хабр! Меня зовут Екатерина Ионова и я руковожу проектами и продуктами экосистемы «Лукоморье» . Когда-то программировала на Java и C#, но последние шесть лет занималась управлением — продуктами, командами, сроками, бюджетами и всем тем, что обычно находится вокруг кода, а не внутри него. Недавно наша команда участвовала во внутреннем продуктовом хакатоне-акселераторе. За три месяца нужно было пройти путь от идеи и анализа рынка до финансовой модели и первого прототипа. У нас была идея нейроассистента для UX-проектировщика, сильная методология, дизайнеры, исследователь, продуктовая логика и не было разработчика. Поэтому прототип пришлось собирать самим. Сначала в Lovable, потом в Cursor. В этой статье расскажу, как мы собрали рабочий ИИ-прототип за выходные, какие грабли поймали, что пришлось «накостылить» и почему даже работающий прототип всё ещё нельзя путать с продуктом. Это кейс о vibe coding в боевых условиях: когда надо быстро проверить гипотезу, а идеальной команды, инфраструктуры и времени у тебя нет.

https://habr.com/ru/companies/lukit_ru/articles/1037968/

#vibecoding #лукоморье #хакатон #хакатоны #вайбкодинг #вайбкодинг #вайбпрограммирование #продукт #продуктовая_разработка #продуктовая_аналитика

AI-native компания: почему пора перестать делать продукты

На первый взгляд AI-native звучит как очередной красивый ярлык для компаний, где всем выдали ChatGPT, Claude Code, Cursor и пару внутренних ботов. Но если смотреть не на инструменты, а на то, как реально работает компания, картина становится интереснее. Оказывается, значительная часть нашей работы — это не создание продукта и даже не принятие решений. Это перенос контекста. Клиент что-то сказал. Аналитик понял и оформил. РП пересказал. Разработчик уточнил. QA нашёл неоднозначность. Архитектор вспомнил, что три года назад похожее решение уже ломалось. Новичок спросил, где это описано. Все снова собрались на встречу, потому что в Jira непонятно, в Confluence устарело, а “без Пети никто этот модуль не понимает”. Снаружи это выглядит как привычная разработка продукта. Внутри — как огромный информационный конвейер, где клиентские сигналы превращаются в требования, требования — в дизайн, дизайн — в код, код — в тесты, релизы, эксплуатацию и новую обратную связь. И чем больше проект, тем дороже становится не сам код, а движение смысла через людей, документы, задачи, переписки и решения. И что с этим делать?

https://habr.com/ru/articles/1035898/

#aiагенты #бизнеспроцессы #проекты #продуктовая_разработка #менеджмент

Я попросил ИИ выбрать нишу для стартапа. Готовой кнопки почти нет

Эксперимент с zero-human компанией: GitHub-агенты, SaaS-валидаторы, поиск боли и почему готовой кнопки выбора ниши пока почти нет Некоторые из вас знают, что я решил провести эксперимент: построить zero-human компанию. Не в смысле "я вообще никогда не буду трогать бизнес руками". Это сказки для лендингов. Идея другая: найти нишу, где максимум операционки можно отдать агентам. Исследования, продукт, код, QA, онбординг, поддержка, отчёты, часть продаж. Человек остаётся там, где надо принять решение, а не переносить данные из одной таблицы в другую. И тут возник первый занимательный вопрос. Если компания строится на ИИ, кто должен выбрать нишу? Ну да. Тоже ИИ. Я пошёл смотреть, что уже есть. Не "спросил ChatGPT придумать 10 идей", а открыл реальные инструменты: GitHub-репы, агентные фреймворки, SaaS-валидаторы, инструменты поиска боли в Reddit, майнеры отзывов из приложений, всякие красивые штуки в духе "ИИ-кофаундер". Хотел понять простую вещь: можно ли сегодня нажать кнопку и получить нишу, которой хотя бы не стыдно заняться. Спойлер: почти нет. Но стало понятно, из каких деталей такая машина собирается.

https://habr.com/ru/articles/1034846/

#искусственный_интеллект #aiагенты #стартап #поиск_ниш_и_продуктов_через_ai #saas #open_source #github #продуктовая_разработка #zero_human_company #предпринимательство

Запуск ИИ‑продукта с нуля: от гипотезы до первых результатов

AI-прототип сегодня можно собрать за вечер, но между рабочим демо и продуктом, которым реально пользуются и за который готовы платить, обычно лежит неприятная зона: слабая гипотеза, грязные данные, лишний стек, непонятные метрики и отсутствие внедрения. В статье разбираем, как подойти к запуску AI/ML-продукта без иллюзии «сейчас прикрутим LLM и всё взлетит»: от проверки боли и выбора use case до MVP, первых метрик и типичных ошибок, которые хоронят проекты ещё до выхода в прод. Разобрать запуск

https://habr.com/ru/companies/otus/articles/1029756/

#ai #стартап #AIпродукт #ИИпродукт #запуск_продукта #продуктовая_разработка #LLM

15 команд, 1 продукт, 14 проектов в Jira. Что не так?

Пока команда одна — всё логично: бэклог, доска, понятный поток. Но когда команд становится пятнадцать и все работают над одним продуктом — Jira начинает вести себя странно. Product Owner открывает утро с обхода четырёх проектов, задачи дублируются, а зависимости живут в комментариях. Разбираемся, почему это не про «плохую Jira», а про конфликт моделей.

https://habr.com/ru/companies/simpleone/articles/1031342/

#Jira #масштабирование #scrum #safe #less #продуктовая_разработка #бэклог #управление_зависимостями #многокомандная_разработка #product_management