Комментарии 32
Есть некое лукавство "Если сравнить с первым вариантом, то наш клиент сильно обгонит своих конкурентов" - он не может обгонять т.к. сидит и ждёт пока вы создадите что-то похожее на плохой автомобиль.
Т.е. точка 1 на шкале III равна точкам 3 на шкалах I и II
Т.о. пользователь на шкале I может играться с колесом, видеть что строится шасси, пользователь на шкале II уже отмахал пару сотен км на самокате - велике - мопеде, а пользователь на шкале III сидит и слушает менеджера как он будет обгонять всех на свете, пока инженеры собирают фактически готовый автомобиль
Это вы исходите из предположения, что в первом варианте мы заранее точно знаем, что именно хотим построить, и именно это у нас в итоге и получается. Но в случае разработки так почти никогда не получается — заказчику сложно заранее сказать, что в точности ему нужно. Вот когда он увидит что-то похожее — тогда скажет — то, или не то.
Отчасти да, но это же только метафора. Как я писал, не каждый клиент встанет на самокат и захочет крутить крутить педали велосипеда. Если вынашиваю такого клиента, то это удача. Он правда может обогнать других.
Мне кажется, чтобы снять вопросы по этой теме надо вначале описания методик указать, что все продукты на ранних стадиях для клиентов типа innovator и early adopter. Никто не будет на 100% пересаживаться на этот продукт, или полностью завязывать свои бизнес процессы. То есть условный клиент ездил на лошади, а мы ему даем самокат. На этот самокат он посадит свою фокус-группу. А на автомобиль перейдет полностью по итогам опытной эксплуатации и доведения продукта.
Суть в том, что мы даем обещание выдать бизнес-результат к определенному сроку и за фиксированный бюджет, но договариваемся, что объем работы будет "плавающий".
FFF классный. Бюджет фиксирован, время фиксировано и мы просто сдаем в аренду свою команду, которая умеет делать качественно, но когда сделаем MVP не говорим. Кажется это вообще не про создание MVP в его базовом понимании, потому что он нужен ровно для того, чтобы протестировать какую-нибудь гипотезу, и если она не сработает -- то выбросить код без сожаления.
Обратите внимание, что в MVP по второму варианту мы полностью выкидываем работающую систему, и делаем вместо неё совсем другую. То есть, это скорее иллюстрация пивота, а не MVP. Далеко не все заказчики и разработчики к такому готовы.
Почти так, но иллюстрация подразумевает, что наработки переходят от стадии к стадии и переиспользуются. В реальном мире, конечно, это маловероятно, но в IT такое частенько происходит. Если смотреть на схему, как на работу в физическом мире, то было бы точнее назвать, как вы сказали — каждая следующая стадия это пивот
Кажется на странице какая-то "верстко-бомба" - если долистать до видео в тиктоке, то под ним неконтролируемо растет пустое пространство, скролл уменьшается, мышкой и пальцем не удается обогнать, только кнопкой page down. Воспроизвелось дважды.
[на второй картинке] Основной минус в том, что на самокате неудобно ехать в дальние поездки, он медленный, он небезопасен, он не закрыт от дождя, т.е. он слишком
далек от того, что действительно хочет клиент в итоге. Поэтому у нас
есть шанс на этом этапе клиента потерять.
А по-моему на второй картинке основной минус в том, что вы последовательно создаёте 4 разных продукта просто в рамках "создания VMP". Так ещё и вряд ли приобретаете компетенции по ходу дела (вряд ли умение делать велосипеды поможет вам при изготовлении автомобиля).
Уровень неопределенности бывает совершенно разный. Есть стартап, который нащупал идею, которую никто никогда не думал и не делал в мире, и, с другой стороны шкалы, сложившаяся компания с прописанными бизнес-процессами, которым надо автоматизировать их.
Во втором случае фига там строить велосипед или изобретать колесо? Любой опытный ПМ врубится в задачу за неделю, сняв требования со стейкхолдеров и за вторую неделю набросает кликабельный прототип. После этого можно пилить, 90% не изменится.
В первом случае (стартап) это поиск в мутном болоте непонятно чего, там может быть и колесо сначала, и велосипед. Если в мире не было еще изобретено "колесо" возможно нам нужен первый вариант, чтобы сначала изобрести его, а потом по любому придется собрать тележку без двигателя или самокат и только дальше автомобиль.
Все три варианта применимы в разных ситуациях в разработке ПО.
Да, разные варианты для разных "состояний" проекта. Если в уже существующей системе надо добавить "кнопку", то нет смысла идти издалека. Надо просто добавить кнопку. С другой стороны, даже в устоявшемся бизнесе и в давно существующих системах надо сделать нечто, чего в них раньше не было. Тогда подходы с "самокатами" отлично применимы. Я бы за основу брал Cynefin framework, чтобы понимать, как лучше двигаться к решению.
Когда я попытался объяснить своему генеральному, что задуманный им большой и сложный проект нужно пилить по MVP-схеме и расписал ее на примере автомобиля, генеральный подумал и ответил: "Хорошо, давай сделаем как ты предлагаешь, только в понятие "минимальный" добавим коробку-автомат, холодильник-бар и массаж в сиденьях".
ведь, метафоры не годятся для убеждений, а только для объяснений... К тому же, метафора про MVP очень неточная. У авто, самоката, байка принципиально разные сценарии использования, они закрывают разны потребности. Это как ставить в один ряд гречку и мороженое — мороженое едят не для того, чтобы насытиться.
Я согласен, что для убеждения надо использовать механизмы "продажи" идеи. А вот для синхронизации подхода к разработке уже подойдут эти картинки
Я использую Cynefin Framework, причем не только на работе. Этот фреймворк объясняет много причин фейлов тех проектов, где с его помощью ничего не анализировали. Например, он объясняет эффект Даннинга-Крюгера, карго-культы, разницу в обучении на своих и чужих ошибках, микроменеджмент. А еще он демонстрирует самую (на мой взгляд) жестокую ошибку софтверной инженерии: смешение анализа и синтеза (исследований и разработки).
Круто! Всё понял, кроме последнего. Можете, пожалуйста, расписать подробнее вот эту часть?
> самую (на мой взгляд) жестокую ошибку софтверной инженерии: смешение анализа и синтеза (исследований и разработки)
Инженерия описывается доменом Complicated. Это домен, где у нас есть вся необходимая информация, мы знаем некие хорошие практики, которые гарантировано могут решить задачу при наличии неограниченного времени и ресурсов. Единственное, чего у нас нет -- это понимания, какую из практик предпочесть, чтобы уложиться в имеющиеся ресурсы и выполнить требования. Грубо говоря, мы можем закрыться от внешнего мира в гараже (в библиотеке, на рабочем месте с интернетом), произвести анализ имеющихся данных, а потом начать создавать продукт.
Домен Complex отличается от предыдущего существенным пробелом в знании внешнего мира. Мы уже не можем закрыться в гараже и вынуждены отправиться добывать недостающую информацию, причем методом проб и ошибок. Это тот домен, где происходят исследования: вначале формулируется гипотеза, затем она либо опровергается, либо принимается.
Если взять реальную инженерную разработку (например, постройку моста), то можно заметить, что проектирование не начинается без знания точного места, где его нужно строить, без точных данных о рельефе местности и розе ветров. Тут четко разграничены Complex и Complicated части, и это дает некие гарантии качества постройки.
Теперь перейдем к "software engineering". Я взял это выражение в кавычки потому что в современном мире это стало какой-то "морской свинкой": не всегда про software и редко про engineering. У нас есть комок грязного легаси кода, про который уже никто не уверен, как оно работает. Вместо того, чтобы вначале разобраться, как оно вообще должно работать, мы бросаемся в пекло и наваливаем еще больше грязи. Энтропия возрастает, и мы все больше заняты багфиксом (который принадлежит домену Complex), и все меньше заняты проектированием фич (Complicated). Я даже придумал замещающий термин, "software surgery", поскольку такая деятельность больше напоминает работу хирурга в реанимации, когда присутствует существенная доля неопределенности, и мы вынуждены "вести разведку боем". Только у хирурга нет копии пациента, чтобы произвести повторную операцию с учетом допущенных ошибок; у программистов же есть возможность вначале уточнить проблему сделав прототип, а потом перейти к созданию продукта с учетом новых знаний о проблеме. Только прототип стоит выкинуть, чего современные программисты не делают, отправляя сырую грязь сразу в продакшн.
А есть ещё контр-метафора, за авторством Карла фон Клаузевица "Нельзя перепрыгнуть канаву наполовину". Не совсем, конечно, про IT, но тоже актуально
Про "FFF" как-то не очень понятно. Мы зафиксировали стоимость и срок. Допустим 10000 руб к следующей пятнице. И вот наш инженер стал работать. 1 вариант: за 2 часа он достиг результата, таким образом оплата его труда составила 5000 руб/час. 2ой вариант. Он трудится, не успевает к пятнице, берёт ещё помощника, трудятся вдвоём. Допустим успели и потратили совместного труда 100 часов. Получается их оплата труда оказалась 100 руб/час? А вы уверены, что это действительно та оплата труда, на которую рассчитывал работник?
Если вы закончили за 2 часа, то и получили оплату за два часа. В этом плане все делят риски поровну. Либо, за оставшееся время, вы можете еще что-то сделать, что не входило в первоначальный план.
Если он не успевает, то он как можно раньше должен об этом узнать, обсудить какую часть работы можно упростить, чтобы успеть.
Всевдо-MVP из второй картинки ещё не позволяет проверить гипотезу «автомобиль им решит вопрос поездки» на прототипе-самокате
прекрасные метафоры! Я всегда радуюсь умению объяснять сложные вещи простыми словами
Из обсуждения стало понятно, что по мнению топ маркетологов ( га), 1. Клиент не чего не смыслит в задаче которую поставил... 2. Маркетолог ОБЯЗАН вбухать кучу денег в прототип, чтоб иметь хоть минимальный шанс что-то обьяснить клиенту. И просто ТАК НУЖНО. 3. После выполнения ( оно же foll ) пункта 2, возвращаемся к пункту 1...
Ето если что не критика а наблюдение за статьями тех, кто называет себя маркетологами...
А в доказательство не критики, вот выход: просто нанять чувака, который таки умеет обьяснять клиентам свои/чужие мысли, если они имеют хоть какой-то сенс. Как он это сделает, через качественный роад меп/ софт скиллы/ умение организовывать команды и бюджеты, не суть уже важно... И пусть он держит в "Титановых перчатках всех маркетологов, и т д...
Метафоры подходов к созданию IT-продуктов