Не бежать впереди паровоза
Лучше столкнуться с реальной проблемой, чем решать несуществующую 👌
Когда проектируешь новую фичу, бывает такое, что замечаешь какую-то потенциальную проблему. То есть это даже не проблема пока что, но руки чешутся предусмотреть всё и пофиксить ещё до того, как она появилась.
Если это не какая-то очевидная штука, если проблема не ломает сценарий, то лучшим решением будет дать проблеме проявиться, а потом уже её решать. Потому что вы не тратите время на несуществующую проблему. Можно конечно провалидировать, закинуть её на тестирование, но ведь мы уже определились, что это не крит, а времени как всегда нет))
Если мы ничего не сделаем, то мы либо столкнемся с проблемой потом, либо нет. Но зато когда столкнемся, то мы точно будем знать, что проблема всё-таки есть и узнаем частотность, а потом уже спокойно возьмем задачку на фикс. При этом мы не потратили время, а пользователи получили ценность быстрее, пусть и с косячками.
Всё предусмотреть невозможно, а вот потратить время на решение несуществующей проблемы — изи
· 22.06
А о какого рода проблемах тут идёт речь? И как вы приоритезируете и валидируете гипотетические проблемы, чтобы понимать, чего точно не допускать, а что фиксить по мере возникновения?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 22.06
Неочевидные потенциальные проблемы, найденные по ходу работы. Часто это просто юиксовые штуки, на которые только дизайнеры обращают внимание, а пользователи пропускают это мимо и их не триггерит никак. Приоритезируем и принимаем решение экспертно, дизайнер инициатор — заносит и подсвечивает эти моменты продакту и разрабам. Что делаем дальше зависит от сложности разработки, сроков поставки основной ценности, критичности и потенциальных рисков.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён