Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
MVP за 2-3 дня - это вполне реально при условии использовании "платформ" (т.е. вычёркиваются процессы поиска команды, заказа серверов, установки, согласования ИБ, настройки DNS, регистрации пользователей и т.д.). Чуть подробнее можно тут прочитать (особенно про невыдуманные истории). А можно и не читать :)
я обязательно прочитаю! Да, согласна, что при использовании платформ многие шаги можно перепрыгнуть, и сделать MVP быстрее. Из самого простого аналога, с которым работала - мы делали так дашборды на клике или power BI. Но даже в этом случае публикацию на тесте, затем на проде, и, как следствие, все согласования - никто не отменял. И в итоге минимальный срок от старта до публикации на проде был чуть меньше 2 месяцев, что тоже неплохо
я возвращаюсь к своей презентации по новому продукту, где нужно объяснить почему MVP за 2 дня в нашем бизнес-процессе – это из области фантастики :)
Ну то есть варианта сделать отдельные процессы для продуктовых MVP (хотя бы впихнув их в RnD подразделение) вы не замечаете принципиально? Понятно, что рукожопный MVP никто не хочет втиснуть в основной продукт, но почему не вынести в отдельный контур и отливать туда трафик произвольно?
не замечаете принципиально?
конечно, замечаю. В этом посте я рассмотрела конкретный кейс, когда инфраструктура под быстрые публикации не настроена, что я встречала достаточно часто. Если использовать отдельный контур, сроки кратно сократятся, но все равно останется минимальный набор шагов - непосредственно разработка, публикация на тесте, тестирование, согласование переноса (с учетом доступа пользователей к данным), перенос на прод / предпрод. И в таких случаях у нас получалось отдать функционал за 2 месяца. Если поделитесь примерами, как этот процесс более эффективно настроен в крупных организациях, буду очень благодарна.
В этом посте я рассмотрела конкретный кейс, когда инфраструктура под быстрые публикации не настроена
Тогда логично идти другими путями RnD, не пытаясь натянуть подход серийной генерации MVP на инфру, очевидно под такой подход не заточенную?
Если поделитесь примерами, как этот процесс более эффективно настроен в крупных организациях
По конкретным примерам еще NDA не истекли, к сожалению. Но смысл простой: соответствие подхода инфре. А уж достигать это соответствие сменой подхода (см выше), или сменой инфры - смотрите по месту. Смена подхода достигается через диалог со стратегами. Развитие инфры - через диалог с CTO, он обычно будет за - для него это бюджеты, ставки...
Что за отдельные MVP в отдельном подразделении RnD? То есть можно за 2 дня. только не будем считать 4 месяца которые потратило подразделение RnD на согласование, исследование и тестирование на стейджинге? Или выкидываем критерии 2 и 3 которые указаны в начале статьи?
у нас, кстати, есть отдельные подразделения RnD, но и они ограничены конкретным набором технологий, библиотек и тд. И, конечно, далеко не все продукты и функциональности можно воссоздать имеющимися средствами. И, как Вы правильно заметили тоже, никто не отменяет согласований, тестирование и пр. даже для обособленных подразделений. Написать MVP и внедрить MVP (ну или даже просто развернуть по всем правилам) - требует совершенно разных усилий
Что за отдельные MVP в отдельном подразделении RnD?
В смысле? Ну вот как раз чтобы не тащить ограничения стеков, инфры, релизных циклов и т.д. с основного продукта - выводим MVP. На отдельную инфру. А с организационной точки зрения - в отдельное подразделение. В больших компаниях обычно выносят куда-то в сторону RnD
только не будем считать 4 месяца которые потратило подразделение RnD на согласование
Подразделения RnD (в здоровых компаниях) обычно отличаются как раз тем, что у них минимум операционных согласований. Т.е. внутри своего отчетного цикла (обычно годового) и выделенных бюджетов как таковых согласований у них может вообще не быть.
исследование
Какое исследование? У вас огромный объем поставленных на поток MVP заменяет классические исследования как раз
тестирование на стейджинге
Зачем? Еще раз: это серийно генерируемые MVP. Их надо катить сразу в отдельный по инфре прод (чтобы дырявыми не цеплять рабочие продукты)
Или выкидываем критерии 2 и 3 которые указаны в начале статьи?
Вот как раз при описанном мной подходе все критерии на месте. На отдельной продовой инфре живут MVP. 5, 10, 20, 100, 1000 или сколько там их генерится в рамках RnD циклов. На них отливается целевой объем трафла в рамках согласованных планов и бюджетов. Эти планы и бюджеты согласуются не отдельно для каждого MVP, а для всего RnD направления
эти три критерия выполнимы легко за два дня c LLM. А вот если к ним добавить еще один:
- достаточно устойчивая и защищенная сборка MVP, чтобы ее не ломанул первый встречный-поперечный с LLM в кармане и она не упала в ответ на первый запрос пользователя
то все становится сложнее. Сделать «какашку в обертке» с LLM легко. А сделать устойчивый и защищенный продукт - это отдельная проблема, и решается она только если за LLM смотреть в оба глаза.
да, если LLM можно использовать в контуре компании, а на производствах часто нельзя из-за чувствительных данных. А разворачивать LLM на своих серверах - очень дорого, не все на это идут. Тем более сейчас в кризисные времена на такие нецелевые "хотелки" с отложенным эффектом огромный бюджет никто не выделит. Вот и получается, что ИИ - классная штука и должна помогать, но не в интерпрайсе
Спасибо за статью. Похожие мысли. Навайбкоженый за два дня прототип на локальной машине - не есть MVP для энтерпрайза. И в энтерпрайзах по моему опыту дай бог только 30% всего времени уходит непосредственно на написание и отладку кода. Соотв эта же цифра и ограничивает максимально возможный эффект от LLM
Нейрослопов немножко: https://share.google/aimode/beykcVQmXDxQSjz3M
MVP за 2-3 дня это плохонький ходовой макет, по готовой идеи, которая прототипируется автором идеи без доступа к реальным данным, по готовому в голове "ощущению" целевого продукта. В реальном мире за это время в компании среднего размера вы даже поверхностные пожелания в общем виде не опишите.
О том и речь. Называть это mvp наверно
Но справедливости ради, такое быстрое проституирование действительно упрощает работу всего цикла от идеи до продукта. Правда тут есть еще одна загвоздка, ИИ прототипы практически невозможно допиливать, т.е. после презентации прототипа по факту, с учетом замечании идет разработка нового прототипа с нуля и скажем на 10 прототипе время на работу с ИИ уже может оказаться больше чем с ограниченным( в качестве автокомплита ) его использовании. Плюс степень переиспользования решений из прототипа в последующем продукте у ИИ прототипа будет фактически нулевой.
За два дня можно навайбкодить прототип для предметного обсуждения с конечными пользователями, проверки каких-то идей. MVP - ядро проекта, с которого начнётся его развитие. Что можно развивать после вайб-кодинга - не понятно.
100%
Что можно развивать после вайб-кодинга - не понятно.
В смысле "что"? Продуктовую идею, которую вы проверили с помощью MVP. А вот как ее развивать - вопрос вовсе отдельный. Возможно путем полного переписывания выстрелившего MVP человеками. Для ретроградов переписывать можно в Notepad++. чтобы уж точно богомерзкие нейронки не пролезли даже автокомплитами
MVP - это когда можно спокойно пользоваться минимальным набором функций. То, о чем Вы говорите - по самому процессу вопросов нет, но смысл в том, что это не MVP, а прототип. С помощью прототипа проверяют гипотезы, а не с помощью MVP. С помощью нейронок быстро можно навайбкодить прототип, и причем функциональный прототип - это супер и огромный прорыв.
Идею можно проверить только пользователями, а их в прототипе нет и не будет. А для презентаций проще картинок наделать.
почему это пользователей не будет в прототипе? вообще не согласна. Пользователь может посмотреть и покликать все, что угодно - хоть презентацию, хоть кликабельную первую версию. Но от этого кликабельная первая версия не станет MVP. MVP - это то, что уже приносит прямую ценность бизнесу, то есть пользователи могут выполнять конкретные задачи, работать с данными (а если мы говорим об энтерпрайзе, то данные должны быть защищены). Не пробовать что-то в MVP надо, а работать в нем. Все что не MVP - это прототип. Если хотите, можно назвать это MVE (Minimum Viable Experiment), не проблема, но это все еще не приносит прямой ценности бизнесу и пользователям. Тестирование гипотез не приносит прямой ценности бизнесу, поэтому инструмент для тестирования - это стадия до MVP. Хотя это, несомненно, важный и обязательный процесс.
Можно сделать MVP в корпорации за 2-3 дня, но для этого потребуются скорее всего лишь собственные силы.
Делал MVP в виде сканера файлов на предмет сторонних библиотек: 100+ строчек кода на Python, которые вызывали нужную библиотеку для сканирования, интерпретировали результаты и отправляли в человекочитаемом виде нужным коллегам. Написание и отладка как раз заняли вечера 2-3 дней. Коллеги показали "большой палец вверх" и дальше запустили полноценный проект с интерфейсом, многопоточностью, поддержкой и разделением пользователей и всем остальным.
Что потребовалось - понимание проблемы, возможность и желание ее решить (помочь), знание Python (в итоге можно было и обычным шеллом обойтись), доступ к свободной виртуалке, доступ к почтовому серверу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я тоже хочу MVP за 2 дня. Но давайте без иллюзий в энтерпрайзе