У каждого может быть свое мнение. Мне было интересно прочитать ваше. Меня даже впечатлило, насколько длинным и многоуровневым получился ваш комментарий.
Я как раз и говорю, что процесс описания требований становится важнее, а не исчезает. Просто меняется его природа, не User Stories для команды разработки, а структурированная документация для AI. Это не противоречие, это и есть суть сдвига.
Wibegile — отличный термин, забираю! Но если серьезно, то я как раз и не говорю, что вайбкодинг заменяет все. Это инструмент для фазы исследования и гипотез. А дальше структурированные требования, документация, системный подход. Просто теперь к моменту «настоящей» разработки у тебя уже есть работающая модель, а не текстовое описание. Это меняет разговор с командой и с заказчиком довольно радикально.
Модель оплаты Time & Materials — это основной стандарт работы для крупных аутсорсинговых компаний и системных интеграторов. Но даже когда работа ведется по фикс-прайсу, он рассчитывается на основании оценки в часах.
Как раз проекты с историей проще всего адаптировать под ответы ИИ, потому что есть на чем обучить модель. Да и в проектах с иторией редко нужны радикальные изменения.
Согласен с вами. Мне бы хотелось ошибиться и чтобы дизайнеры были настолько же нужны, как и раньше, но похоже все меняется. Скорее всего и дизайнеры поменяются.
На мой взгляд, команды как раз чаще склонны упрощать идеи. Не хотят рисковать и не хотят усложнять себе жизнь. Но, в конечном счете, и смелые идеи не должны становиться самоцелью.
У фреймворка нет цели фокусировать вас на сложных и рискованных задачах. Он только помогает понять, где идея находится на шкале SAFE-BOLD. А дальше уже ваш стратегический выбор: попробовать найти более инновационное решение, или наоборот поискать более очевидное.
А как делить ресурсы между простыми задачами и инновационными – это уже вопрос управленческой работы.
Хороший вопрос! BOLD-идеи — это смелые, амбициозные шаги, которые могут радикально изменить игру: открыть новые возможности, выделить вас среди конкурентов и принести долгосрочный рост. Они заметны, вдохновляют и дают конкурентное преимущество в среде, где сотни голодных игроков борются за внимание. SAFE-идеи — это безопасные, постепенные улучшения, которые хороши, если ресурсы ограничены, риски недопустимы или отрасль консервативна (например, естественные монополии или госкомпании). Но часто SAFE выбирают просто из страха "как бы чего не вышло" (у Даниэля Канемана в Теории перспектив это описано, как склонность к избеганию потерь), что в долгосрочной перспективе может стать проигрышной стратегией для коммерческой компании. BOLD требует смелости и расчета, но именно такие идеи двигают прогресс и выделяют лидеров.
У вас интересный подход, но мне кажется, что его применимость в реальных условиях ограничена. Вы используете синтетические данные, предполагая отсутствие внешних искажений. Например, вы делаете предпосылку, что «увеличение комплектности сопровождалось снижением списаний», что может быть далеко от реальности.Возможно, стоит проверить гипотезу на реальных данных, даже если они будут «шумными». Также было бы интересно узнать, как вы предлагаете учитывать в модели такие факторы, как сезонность или изменения в поведении клиентов.
А/Б тесты внешне просты, но это не означает, что результата легко добиться. Меньше 15% тестов в зрелых командах приводят к значительным результатам. Искажение распределения трафика по вариантам на 0,2% уже искажает результат тестирования. Даже при наличии выигрышного результата у вас есть почти 26% вероятности, что результат неверен. И как говорил генеральный директор Airbnb Брайан Чески: «А/Б-тестирование — это отказ от ответственности перед пользователями.» Полная его цитата звучит так: «А/Б-тестирование — это отказ от ответственности перед пользователями. Если вы собираетесь проводить A/B-тестирование, оно должно быть основано на гипотезах. Если это сработает, вы должны быть в состоянии сказать, почему, а не только что».
Ваше заключение: "...мы правильно сформулировали гипотезу, выбрали оптимальное соотношение процента прироста и длительности эксперимента, а также определили наиболее подходящее распределение аудитории " — кажется мне скорее попыткой выдать желаемое за действительное, нежели выводом основанным на реальных фактах. Вся статья больше похожа на попытку разобраться в самом подходе к проведению эксперимента. А содержание проводимого эксперимента, вообще, очень сомнительным. Возможно, руководство недостаточно критично отнеслось к вашей работе и этому материалу, только этим я могу себе объяснить появление и первого и второго.
Спасибо за статью. У меня есть несколько замечаний, может вы их сможете прокомментировать. Непонятно всё-таки, почему была выбрана визуализация данных на карте, а не на дашбордах. Ведь для управленческих решений структурированные дашборды удобнее: на них можно показать динамику во времени, вывести прогнозные значения из аналитических моделей, да и просто места больше. И даже если выбрали карту, кажется, что профессиональнее было бы использовать не карту общего назначения, а схему железнодорожной сети. Так было бы меньше визуального шума, и можно было бы обеспечить большую плотность элементов.
У каждого может быть свое мнение. Мне было интересно прочитать ваше. Меня даже впечатлило, насколько длинным и многоуровневым получился ваш комментарий.
Я как раз и говорю, что процесс описания требований становится важнее, а не исчезает. Просто меняется его природа, не User Stories для команды разработки, а структурированная документация для AI. Это не противоречие, это и есть суть сдвига.
Wibegile — отличный термин, забираю! Но если серьезно, то я как раз и не говорю, что вайбкодинг заменяет все. Это инструмент для фазы исследования и гипотез. А дальше структурированные требования, документация, системный подход. Просто теперь к моменту «настоящей» разработки у тебя уже есть работающая модель, а не текстовое описание. Это меняет разговор с командой и с заказчиком довольно радикально.
Модель оплаты Time & Materials — это основной стандарт работы для крупных аутсорсинговых компаний и системных интеграторов. Но даже когда работа ведется по фикс-прайсу, он рассчитывается на основании оценки в часах.
так толковых ну процентов 40, а остальным то значит конкурент.
Как раз проекты с историей проще всего адаптировать под ответы ИИ, потому что есть на чем обучить модель. Да и в проектах с иторией редко нужны радикальные изменения.
Скоро, вот Anima AI уже вполне сносно переносит дизайн в верстку.
Любопытно, с какой легкостью вы описываете будущее незнакомых вам людей.
Ну для кого-то это была важная часть жизни. Но, видимо, упадок дизайна тоже является частью жизни.
Согласен с вами. Мне бы хотелось ошибиться и чтобы дизайнеры были настолько же нужны, как и раньше, но похоже все меняется. Скорее всего и дизайнеры поменяются.
Как раз это и обеспечивает бьстрое получение дизайна. Результат не блястящий, но уже неплохой и этого оказывается достаточно.
Это не график для сравнения, а тренды.
На мой взгляд, команды как раз чаще склонны упрощать идеи. Не хотят рисковать и не хотят усложнять себе жизнь. Но, в конечном счете, и смелые идеи не должны становиться самоцелью.
У фреймворка нет цели фокусировать вас на сложных и рискованных задачах. Он только помогает понять, где идея находится на шкале SAFE-BOLD. А дальше уже ваш стратегический выбор: попробовать найти более инновационное решение, или наоборот поискать более очевидное.
А как делить ресурсы между простыми задачами и инновационными – это уже вопрос управленческой работы.
Хороший вопрос! BOLD-идеи — это смелые, амбициозные шаги, которые могут радикально изменить игру: открыть новые возможности, выделить вас среди конкурентов и принести долгосрочный рост. Они заметны, вдохновляют и дают конкурентное преимущество в среде, где сотни голодных игроков борются за внимание. SAFE-идеи — это безопасные, постепенные улучшения, которые хороши, если ресурсы ограничены, риски недопустимы или отрасль консервативна (например, естественные монополии или госкомпании). Но часто SAFE выбирают просто из страха "как бы чего не вышло" (у Даниэля Канемана в Теории перспектив это описано, как склонность к избеганию потерь), что в долгосрочной перспективе может стать проигрышной стратегией для коммерческой компании. BOLD требует смелости и расчета, но именно такие идеи двигают прогресс и выделяют лидеров.
Попытка навешивать ярлыки на всех подряд - это очень манипулятивная техника. Вы сейчас весь корпус авторов Researchgate назвали шарлатанами.
У вас интересный подход, но мне кажется, что его применимость в реальных условиях ограничена. Вы используете синтетические данные, предполагая отсутствие внешних искажений. Например, вы делаете предпосылку, что «увеличение комплектности сопровождалось снижением списаний», что может быть далеко от реальности.Возможно, стоит проверить гипотезу на реальных данных, даже если они будут «шумными». Также было бы интересно узнать, как вы предлагаете учитывать в модели такие факторы, как сезонность или изменения в поведении клиентов.
А/Б тесты внешне просты, но это не означает, что результата легко добиться. Меньше 15% тестов в зрелых командах приводят к значительным результатам. Искажение распределения трафика по вариантам на 0,2% уже искажает результат тестирования. Даже при наличии выигрышного результата у вас есть почти 26% вероятности, что результат неверен. И как говорил генеральный директор Airbnb Брайан Чески: «А/Б-тестирование — это отказ от ответственности перед пользователями.»
Полная его цитата звучит так: «А/Б-тестирование — это отказ от ответственности перед пользователями. Если вы собираетесь проводить A/B-тестирование, оно должно быть основано на гипотезах. Если это сработает, вы должны быть в состоянии сказать, почему, а не только что».
Ваше заключение: "...мы правильно сформулировали гипотезу, выбрали оптимальное соотношение процента прироста и длительности эксперимента, а также определили наиболее подходящее распределение аудитории " — кажется мне скорее попыткой выдать желаемое за действительное, нежели выводом основанным на реальных фактах. Вся статья больше похожа на попытку разобраться в самом подходе к проведению эксперимента. А содержание проводимого эксперимента, вообще, очень сомнительным. Возможно, руководство недостаточно критично отнеслось к вашей работе и этому материалу, только этим я могу себе объяснить появление и первого и второго.
Спасибо за статью. У меня есть несколько замечаний, может вы их сможете прокомментировать.
Непонятно всё-таки, почему была выбрана визуализация данных на карте, а не на дашбордах. Ведь для управленческих решений структурированные дашборды удобнее: на них можно показать динамику во времени, вывести прогнозные значения из аналитических моделей, да и просто места больше.
И даже если выбрали карту, кажется, что профессиональнее было бы использовать не карту общего назначения, а схему железнодорожной сети. Так было бы меньше визуального шума, и можно было бы обеспечить большую плотность элементов.
Сделайт тогда статью и с ProtoPie, чтобы было понятнее, как вы используете его для прототипов и в каких случаях.