да, все верно. сделать можно быстро, если понимаешь проблематику, и если у тебя есть все технические относительно легальные позможности разработать, а потом и опубликовать на стенде компании :)
почему это пользователей не будет в прототипе? вообще не согласна. Пользователь может посмотреть и покликать все, что угодно - хоть презентацию, хоть кликабельную первую версию. Но от этого кликабельная первая версия не станет MVP. MVP - это то, что уже приносит прямую ценность бизнесу, то есть пользователи могут выполнять конкретные задачи, работать с данными (а если мы говорим об энтерпрайзе, то данные должны быть защищены). Не пробовать что-то в MVP надо, а работать в нем. Все что не MVP - это прототип. Если хотите, можно назвать это MVE (Minimum Viable Experiment), не проблема, но это все еще не приносит прямой ценности бизнесу и пользователям. Тестирование гипотез не приносит прямой ценности бизнесу, поэтому инструмент для тестирования - это стадия до MVP. Хотя это, несомненно, важный и обязательный процесс.
MVP - это когда можно спокойно пользоваться минимальным набором функций. То, о чем Вы говорите - по самому процессу вопросов нет, но смысл в том, что это не MVP, а прототип. С помощью прототипа проверяют гипотезы, а не с помощью MVP. С помощью нейронок быстро можно навайбкодить прототип, и причем функциональный прототип - это супер и огромный прорыв.
Это как красная тряпка для быка. «Ну мы же agile”, говорят мне, когда систематически затягивают сроки. Это не гибкость, это триггер проблемы, и надо копать или в коллективную безответственность, или в неадекватное планирование, или искать другие причины. И устранять их, а не оправдывать набрасыванием популярных подходов
Приятно найти совпадение во взглядах 😊. У меня есть пример из области геологии. Раньше запасы месторождений, а точнее, залежей, рисовали руками, а считали планиметром. Условно говоря, при помощи линейки. Но это было совсем давно, сейчас так никто не делает, так как все алгоритмы заложены в разные программные обеспечения. Я не спорю, это гораздо удобнее - нажал кнопку, выбрал тип построения, и карта сама нарисовалась, запасы посчитались. Но вчерашние студенты зачастую не понимают первопричины, основы физики, математики и геологи. И на вопрос: почему залежь отрисована определенным образом говорят «ну я не знаю, так программа построила». Другие из них, задавая граничные значения, выбирают от 0 до 100 или 50, если повезёт, в то время как в природе диапазон от 4 до 35.
Вот и получается ситуация, когда прогресс нас догнал, процессы автоматизированы, а какой от этого толк, если мы этим пользуемся как обезьяны.
И я не говорю, что надо знать все на свете и зазубрить все формулы. Но надо понимать базу
у нас, кстати, есть отдельные подразделения RnD, но и они ограничены конкретным набором технологий, библиотек и тд. И, конечно, далеко не все продукты и функциональности можно воссоздать имеющимися средствами. И, как Вы правильно заметили тоже, никто не отменяет согласований, тестирование и пр. даже для обособленных подразделений. Написать MVP и внедрить MVP (ну или даже просто развернуть по всем правилам) - требует совершенно разных усилий
да, если LLM можно использовать в контуре компании, а на производствах часто нельзя из-за чувствительных данных. А разворачивать LLM на своих серверах - очень дорого, не все на это идут. Тем более сейчас в кризисные времена на такие нецелевые "хотелки" с отложенным эффектом огромный бюджет никто не выделит. Вот и получается, что ИИ - классная штука и должна помогать, но не в интерпрайсе
конечно, замечаю. В этом посте я рассмотрела конкретный кейс, когда инфраструктура под быстрые публикации не настроена, что я встречала достаточно часто. Если использовать отдельный контур, сроки кратно сократятся, но все равно останется минимальный набор шагов - непосредственно разработка, публикация на тесте, тестирование, согласование переноса (с учетом доступа пользователей к данным), перенос на прод / предпрод. И в таких случаях у нас получалось отдать функционал за 2 месяца. Если поделитесь примерами, как этот процесс более эффективно настроен в крупных организациях, буду очень благодарна.
я обязательно прочитаю! Да, согласна, что при использовании платформ многие шаги можно перепрыгнуть, и сделать MVP быстрее. Из самого простого аналога, с которым работала - мы делали так дашборды на клике или power BI. Но даже в этом случае публикацию на тесте, затем на проде, и, как следствие, все согласования - никто не отменял. И в итоге минимальный срок от старта до публикации на проде был чуть меньше 2 месяцев, что тоже неплохо
😹😹😹 встречала всяких) все очень сильно зависит от масштаба и уместности. Иногда менеджеры вообще не нужны, так как только портят работающий процесс лишними дейликами и статусами. Но если мы говорим о комплексном проекте с большой командой из разных подразделений - без дополнительного управления не справиться.
смысл как раз в том, что можно достаточно четко разделить эти две роли, если правильно договориться о понятиях "продукт" и "проект". Но на практике даже в пределах одного проекта они сливались
специалиста из Вашего примера я бы отнесла больше к экспертам, чем к менеджерам. Так как пока он погружался в самые глубокие нюансы процессов и осваивал новые инструменты, он вряд ли выполнял задачи менеджера. И потому что конкретно его будет ценнее всегда держать в одном направлении деятельности, в то время, как управленцы могут менять проекты.
Но! мне очень нравится, когда менеджеры вырастают из производственных процессов. И, если говорить про опыт, мне кажется, для менеджера гораздо ценнее иметь техническое/математическое образование и опыт и логическое мышление по сравнению с управленческим образованием.
Поэтому получается, что специалист должен рассказывать дилетанту популярно о том, что делает. При этом, спец понимает, что тот, кому он рассказывает может ему существенно нагадить.
Специалист не должен это рассказывать на постоянной основе. Ни в коем случае. Я говорила про проблемные ситуации, когда имеет смысл привлечь к решению менеджера.
Менеджеры ведь тоже часто ошибаются, например, ставят невыполнимые задачи в короткий срок. И такие обсуждения могут менеджеру понять почему надо быть менее оптимистичным в планах, а так же как обоснованно рассказать об изменении сроков вышестоящему руководству.
к сожалению, выгорание зависит не только от внешних рабочих обстоятельств, но и от возраста/опыта. Я честно скучаю по тем временам, когда каждая сложная задача или очередная оптимизация казалась интересной на старте карьеры. Как себя сейчас развеселить и замотивировать на работе - пока не поняла. Но вижу, что подавляющее большинство коллег и друзей за 35+ сталкивается с одинаковыми мыслями и выгоранием.
Мне кажется, посыл в статье правильный - даже в рабочей рутине найти для себя "красивое". Да, работа это просто работа, за которую платят деньги. Но лучше, когда тебе платят за то, что тебе нравится, чем за то, что тебе не нравится.
у меня были разные руководители: и те, кому надо было доказывать каждое действие и раз в квартал обосновывать необходимость развития наших давно внедренных цифровых решений (то есть буквально обосновывать деятельность отдела), и те, кто доверял моей работе, но при моем или его желании я погружала в проблемы и оперативку по проектам.
Мне, конечно, ближе второй вариант. Такой подход использую и для своих проектов и команд.
Судя по количеству минусов, я не совсем понятно доношу мысль :) Я точно не за микроменеджмент и контроль каждого разработчика.
да, все верно. сделать можно быстро, если понимаешь проблематику, и если у тебя есть все технические относительно легальные позможности разработать, а потом и опубликовать на стенде компании :)
почему это пользователей не будет в прототипе? вообще не согласна. Пользователь может посмотреть и покликать все, что угодно - хоть презентацию, хоть кликабельную первую версию. Но от этого кликабельная первая версия не станет MVP. MVP - это то, что уже приносит прямую ценность бизнесу, то есть пользователи могут выполнять конкретные задачи, работать с данными (а если мы говорим об энтерпрайзе, то данные должны быть защищены). Не пробовать что-то в MVP надо, а работать в нем. Все что не MVP - это прототип. Если хотите, можно назвать это MVE (Minimum Viable Experiment), не проблема, но это все еще не приносит прямой ценности бизнесу и пользователям. Тестирование гипотез не приносит прямой ценности бизнесу, поэтому инструмент для тестирования - это стадия до MVP. Хотя это, несомненно, важный и обязательный процесс.
MVP - это когда можно спокойно пользоваться минимальным набором функций. То, о чем Вы говорите - по самому процессу вопросов нет, но смысл в том, что это не MVP, а прототип. С помощью прототипа проверяют гипотезы, а не с помощью MVP. С помощью нейронок быстро можно навайбкодить прототип, и причем функциональный прототип - это супер и огромный прорыв.
100%
Да, скорость проверки гипотез сильно сокращается. Но на этом практически все(( хотя и это тоже круто и даже полезно
О том и речь. Называть это mvp наверно
Это как красная тряпка для быка. «Ну мы же agile”, говорят мне, когда систематически затягивают сроки. Это не гибкость, это триггер проблемы, и надо копать или в коллективную безответственность, или в неадекватное планирование, или искать другие причины. И устранять их, а не оправдывать набрасыванием популярных подходов
Именно так. Я очень рада, что нашла единомышленников 😊
Приятно найти совпадение во взглядах 😊. У меня есть пример из области геологии. Раньше запасы месторождений, а точнее, залежей, рисовали руками, а считали планиметром. Условно говоря, при помощи линейки. Но это было совсем давно, сейчас так никто не делает, так как все алгоритмы заложены в разные программные обеспечения. Я не спорю, это гораздо удобнее - нажал кнопку, выбрал тип построения, и карта сама нарисовалась, запасы посчитались. Но вчерашние студенты зачастую не понимают первопричины, основы физики, математики и геологи. И на вопрос: почему залежь отрисована определенным образом говорят «ну я не знаю, так программа построила». Другие из них, задавая граничные значения, выбирают от 0 до 100 или 50, если повезёт, в то время как в природе диапазон от 4 до 35.
Вот и получается ситуация, когда прогресс нас догнал, процессы автоматизированы, а какой от этого толк, если мы этим пользуемся как обезьяны.
И я не говорю, что надо знать все на свете и зазубрить все формулы. Но надо понимать базу
у нас, кстати, есть отдельные подразделения RnD, но и они ограничены конкретным набором технологий, библиотек и тд. И, конечно, далеко не все продукты и функциональности можно воссоздать имеющимися средствами. И, как Вы правильно заметили тоже, никто не отменяет согласований, тестирование и пр. даже для обособленных подразделений. Написать MVP и внедрить MVP (ну или даже просто развернуть по всем правилам) - требует совершенно разных усилий
да, если LLM можно использовать в контуре компании, а на производствах часто нельзя из-за чувствительных данных. А разворачивать LLM на своих серверах - очень дорого, не все на это идут. Тем более сейчас в кризисные времена на такие нецелевые "хотелки" с отложенным эффектом огромный бюджет никто не выделит. Вот и получается, что ИИ - классная штука и должна помогать, но не в интерпрайсе
конечно, замечаю. В этом посте я рассмотрела конкретный кейс, когда инфраструктура под быстрые публикации не настроена, что я встречала достаточно часто. Если использовать отдельный контур, сроки кратно сократятся, но все равно останется минимальный набор шагов - непосредственно разработка, публикация на тесте, тестирование, согласование переноса (с учетом доступа пользователей к данным), перенос на прод / предпрод. И в таких случаях у нас получалось отдать функционал за 2 месяца. Если поделитесь примерами, как этот процесс более эффективно настроен в крупных организациях, буду очень благодарна.
я обязательно прочитаю! Да, согласна, что при использовании платформ многие шаги можно перепрыгнуть, и сделать MVP быстрее. Из самого простого аналога, с которым работала - мы делали так дашборды на клике или power BI. Но даже в этом случае публикацию на тесте, затем на проде, и, как следствие, все согласования - никто не отменял. И в итоге минимальный срок от старта до публикации на проде был чуть меньше 2 месяцев, что тоже неплохо
😹😹😹 встречала всяких) все очень сильно зависит от масштаба и уместности. Иногда менеджеры вообще не нужны, так как только портят работающий процесс лишними дейликами и статусами. Но если мы говорим о комплексном проекте с большой командой из разных подразделений - без дополнительного управления не справиться.
смысл как раз в том, что можно достаточно четко разделить эти две роли, если правильно договориться о понятиях "продукт" и "проект". Но на практике даже в пределах одного проекта они сливались
И Вам спасибо за дискуссию. Я бы хотела поставить лайк, но эта публикация настолько не понравилась всем, что я осталась без возможности оценивания :).
Да, это действительно два разных подхода. Я сама выросла в менеджера из геофизика и геолога. В этом подходе было много плюсов, но и минусы были.
На практике встречала менеджеров из обеих групп. И одни, и вторые встречались как хорошие, так и плохие.
для меня продакт-менеджер это не надзиратель за проектом и командой. Это полноправный участник проекта
специалиста из Вашего примера я бы отнесла больше к экспертам, чем к менеджерам. Так как пока он погружался в самые глубокие нюансы процессов и осваивал новые инструменты, он вряд ли выполнял задачи менеджера. И потому что конкретно его будет ценнее всегда держать в одном направлении деятельности, в то время, как управленцы могут менять проекты.
Но! мне очень нравится, когда менеджеры вырастают из производственных процессов. И, если говорить про опыт, мне кажется, для менеджера гораздо ценнее иметь техническое/математическое образование и опыт и логическое мышление по сравнению с управленческим образованием.
Специалист не должен это рассказывать на постоянной основе. Ни в коем случае. Я говорила про проблемные ситуации, когда имеет смысл привлечь к решению менеджера.
Менеджеры ведь тоже часто ошибаются, например, ставят невыполнимые задачи в короткий срок. И такие обсуждения могут менеджеру понять почему надо быть менее оптимистичным в планах, а так же как обоснованно рассказать об изменении сроков вышестоящему руководству.
к сожалению, выгорание зависит не только от внешних рабочих обстоятельств, но и от возраста/опыта. Я честно скучаю по тем временам, когда каждая сложная задача или очередная оптимизация казалась интересной на старте карьеры. Как себя сейчас развеселить и замотивировать на работе - пока не поняла. Но вижу, что подавляющее большинство коллег и друзей за 35+ сталкивается с одинаковыми мыслями и выгоранием.
Мне кажется, посыл в статье правильный - даже в рабочей рутине найти для себя "красивое". Да, работа это просто работа, за которую платят деньги. Но лучше, когда тебе платят за то, что тебе нравится, чем за то, что тебе не нравится.
это отличные примеры как делать не надо))
у меня были разные руководители: и те, кому надо было доказывать каждое действие и раз в квартал обосновывать необходимость развития наших давно внедренных цифровых решений (то есть буквально обосновывать деятельность отдела), и те, кто доверял моей работе, но при моем или его желании я погружала в проблемы и оперативку по проектам.
Мне, конечно, ближе второй вариант. Такой подход использую и для своих проектов и команд.
Судя по количеству минусов, я не совсем понятно доношу мысль :) Я точно не за микроменеджмент и контроль каждого разработчика.