Комментарии 8
О, ну здравствуйте, дорогие синьористые дезингеры сбермаркета, вы как нельзя кстати.
Вам не икалось сегодня с утра? Почти при каждом входе лезет ваша сраная капча (что на десктопе - фиксированный оператор, что на планшете - мобильный инет, прокси и впн не используются ни там, ни там), которую и на десктопе не всегда с первого раза пройдёшь, что уж говорить про пенсионера, который с планшета пытается заказ в вашей лавке набить в браузере, не может зайти из-за капчи - она на планшете вообще нечитаема, плюётся и ругаясь последними словами оформляет заказ напрямую в ашане, без этой вашей купер-прокладки. Но зато у вас диско, фичи, бэклог, дейли и прочая модная словесность, ага.
Все, кто работает в IT, знают, что в разработке новых фич продукта и поддержке старых выделяются два последовательных процесса:
Discovery — это все действия до начала разработки.
Delivery — все, что касается создания кода.
Я вот работаю в IT и не знаю этого. Ну и да, вопрос, как вы это собираетесь делить в любой сколько-нибудь активной современной разработке, мне не понятно.
Предположу, что вы имеете в виду:
То, что, когда макеты уходят в разработку, работа дизайнера не заканчивается? Не заканчивается - могут вылезти доработки, например. Но это будет относиться в моем понимании к этапу Деливери.
Далее после успешного или неуспешного теста фича может снова вернуться на этап Дискавери, пройти его и пойти в Деливери.
Вот глобально и получается два процесса.
У вас иначе?
Да, у нас иначе. Нет никакого смысла делить работу на дискавери и деливери, если больше половины времени эти процессы (анализа и разработки) идут параллельно.
Поняла, о чем вы – если говорить про команды, в которых процессы идут параллельно (например, в агентствах, где с одной стороны дизайнер рисует макеты, а с другой разработка сразу их кодит), то там действительно процессы нонспом перетекают из одного. в другой. Но в такой ситуации происходит много двойной работы.
Мы стараемся делать так, чтобы после того, как разработчик получил ФТ (функциональные требования), правки в макеты фичи не вносились. Не всегда получается, но очень стараемся.
И, когда, допустим, начинается вторая итерация, то это уже новый файл для дизайнеров, новое диско и новое ФТ для разрабов
Поняла, о чем вы – если говорить про команды, в которых процессы идут параллельно
...то может быть станет понятно, что ваше утверждение про "все в IT знают" избыточно обобщено?
Но в такой ситуации происходит много двойной работы.
Или, наоборот, не происходит лишней. Но это старый спор.
Мы стараемся делать так, чтобы после того, как разработчик получил ФТ (функциональные требования), правки в макеты фичи не вносились.
То есть чистый водопад? Ну... можно, конечно, так работать, и есть люди, которым такого хочется, но жизнь обычно не согласна. Ну, в моем опыте.
Зверь по имени Диско. Как упорядочить процессы дизайн-Discovery и облегчить жизнь команде