Comments 23
Если продакт может сам сделать прототип и убедиться, что он имеет нужные свойства, сделать его в продакшн-качестве разработчику можно будет в 10 раз быстрее.
...но нет. Ровно столько же времени: получить полные требования, спроектировать и реализовать. Возможность продакта самому сделать прототип влияет только на то, как быстро продакт может проверить свою гипотезу.
Я думаю, тут с 2 сторон может быть преимущество.
Первое: проверка гипотезы при занятой другими задачами разработке. Продакт что-то придумал, попробовал, покрутил разные варианты, финальное показал другими командам или клиентам, собрал обратную связь, и все это не отвлекая разработку.
Второе: не совсем понятно, что делать надо, очень большая неопределенность. Нужно увидеть сочетание технологии и интерфейса, чтобы понять, что именно так и надо двигаться дальше, или что не выходит каменный цветок.
Первое: проверка гипотезы при занятой другими задачами разработке
Это то, про что я писал выше. Но это не влияет на скорость "сделать в продакшн-качестве".
Второе: не совсем понятно, что делать надо, очень большая неопределенность.
Это называется "сбор требований".
Нужно увидеть сочетание технологии и интерфейса, чтобы понять, что именно так и надо двигаться дальше
Проблема в том, что в продакшне могут быть совсем другие технологии. И на переделку уйдет больше времени, чем делать с нуля.
Вот с этапом "прототип -> продакшен" пока сделать действительно ничего радикального нельзя, но этап "сбора требований", как описал выше - запросто.
Напомню, что в статье вы написали дословно вот так:
Если продакт может сам сделать прототип и убедиться, что он имеет нужные свойства, сделать его в продакшн-качестве разработчику можно будет в 10 раз быстрее.
То есть именно про этап "прототип - продакшн".
Ок, я исправил текст, чтобы было более понятно. Основная мысль, что когда от продакт-менеджера вместо документа, плохо сформулированного, приходит работающий прототип со всеми нюансами и корнер кейсами, количество вопросов от разработчиков и возможных проблем в финальной версии радикально уменьшается.
Ок, я исправил текст, чтобы было более понятно.
В этот момент я перестаю понимать - вы пишете: "вышло интересное интервью [...] захотелось законспектировать основные мысли". Вы конспектируете свои мысли или то, что в интервью сказано?
Основная мысль, что когда от продакт-менеджера вместо документа, плохо сформулированного, приходит работающий прототип со всеми нюансами и корнер кейсами, количество возможных проблем в финальной версией радикально уменьшается.
Нет. Потому что перенести нюансы и корнер-кейсы из прототипа сложнее, чем из требований. Не говоря о том, что я не верю, что продакт-менеджер (не аналитик) способен на то, чтобы корректно найти и реализовать корнер-кейсы, это просто не его работа.
Я, так уж получилось, больше одного раза был в ситуации, когда мне давали прототип, и его надо было преобразовать в продакшн-версию, и все разы это было дольше и сложнее, чем если бы я работал по требованиям.
Ок, я скорее на свой опыт ориентировался. У нас нет бизнес-аналитиков и основная неопределенность - в том, будет ли удобно пользоваться определенной технологией в определенном интерфейсе. Figma не дает возможность это реализовать, а полновесная реализация - дорого и возможно придется выкинуть.
У нас нет бизнес-аналитиков и основная неопределенность - в том, будет ли удобно пользоваться определенной технологией в определенном интерфейсе
Серьезно? У вас нет неопределенностей "сможет ли система выдержать нагрузку"? "Будет ли это достаточно безопасно"? "Сможем ли мы это поддерживать в будущем"?
Если это так, я завидую уровню технологической зрелости вашей компании.
Хм, ... например, у НАС нет бизнес-аналитика и очень сильная неопределённость: "будет ли удобно пользоваться определённой технологией в определённом интерфейсе". Про поддерживать в будущем - это боль, но так уж получается, что "здесь и сейчас" ещё решать рановато (хотя можно подготовиться). Вопрос про "безопасно" и "нагрузку" вообще не стоит (так как интернета нет и не будет). Приходите к нам, у нас печеньки :)
---
Про прототип согласен и с lair и с akimovpro: вменяемых прототипов не видел и не видел продактов, которые САМИ были готовы что-то накрутить-навертеть. Однако, ЕСЛИ БЫ продакт (или другое лицо, влияющее на конечный результат) сам что-то напрототипировал, то это было бы полезно.
Вопрос в сторону/продолжение темы: [Мало интересовался, но] есть ли простые средства прототипирования, чтобы условный продакт мог бы набросать прототип на основе некоторых скриншотов (так как это всё не веб и гуй там другой)?
и очень сильная неопределённость: "будет ли удобно пользоваться определённой технологией в определённом интерфейсе".
У вас какая-то нестандартная технология? Тогда вопрос, сможет ли Copilot вам помочь с этим.
Вопрос про "безопасно" и "нагрузку" вообще не стоит (так как интернета нет и не будет)
Внезапно, безопасность и производительность - это не только про интернет.
Приходите к нам, у нас печеньки :)
...если у вас нет аналитиков, зачем мне ваши печеньки?
Ну самый простой вариант - это Keynote, потом Figma, потом no-code инструменты разработки всякие.
И она там еще говорила, что Copilot может же и вопросы продакту за разработчиков задавать, в итоге вытягивая из него все нужные данные вместо того, чтобы команде обнаруживать несоответствия уже на этапе демо.
Copilot может же и вопросы продакту за разработчиков задавать
Гм, на основании чего?
Типа жаловаться на его плохо сформулированное ТЗ )
Это не имеет никакого отношения к "продакт может сам сделать прототип".
А главное, ощутимая часть вопросов, задаваемых разработчиками - они возникают как следствие имплементации в конкретные технологии и конкретную ситуацию. Откуда у Copilot этот контекст?
Они прикидывали ситуацию из демо GPT-4 Vision: сфоткал дизайн сайта на салфетке и получил код.
https://www.youtube.com/shorts/i0bGZffYUNs?feature=share
В итоге AI, если не понимает, что конкретно делать-то, сможет задавать вопросы. Конечно, без контекста конкретных технологий, а скорее чтобы снять совсем уж непроработанные вещи.
В итоге AI, если не понимает, что конкретно делать-то, сможет задавать вопросы. Конечно, без контекста конкретных технологий, а скорее чтобы снять совсем уж непроработанные вещи.
То есть задает те вопросы, которые бы задал хороший аналитик, еще не дойдя до разработчика. О чем я и написал выше.
Вот и задал я copilot-у задачу сформулировать проверки/тесты для алгоритма выбора лучшего сигнала из нескольких радиостанций. Ведь прежде чем писать алгоритм, нужно понять, что он должен делать. Вдруг copilot что-то полезное бы предложил?
Ответ copilot-а: ничего не понял и для проверок нужно понять алгоритм.
курица - яйцо - курица?
Книги классные, по крайней мере две из них. Но я не поняла к чему они были в этой теме. Вроде как тема книг далека от AI
Будущее AI в разработке ПО – интервью с CPO GitHub