Нашел полезную статью для владельцев продуктов, стартапов, где явно есть проблемы с планированием и внедрением фичей. Да и в целом для тех, кто метит в дизайн менеджмент или имеет отношение к продуктовой команде, где что-то не так и он хочет это изменить

Просто сборник правильных вопросов перед началом исследования и разработки:

— зачем фича нужна пользователям? какие предпосылки для ее внедрения?
— зачем фича нужна бизнесу? какую выгоду он получит от нее?
— как будет выглядеть фича в продукте?
— как мы убедились, что нашли оптимальное решение?
— какие команды затронет реализация фичи?
— как мы измерим успех от внедрения фичи?
— какие риски мы видим?
— сколько времени потребуется на реализацию фичу?

гоу читать
https://gopractice.ru/skills/software-development-lifecycle-for-pms/
#артдирекшн

А есть еще одна методология - Waterfall, не такая гибкая как аджайл, но в некоторых проектах так же применима.

В чем, мать его разница???

📍Agile
В Agile заказчик может при необходимости вносить изменения в план работ
и требования можно корректировать: изменять приоритеты проекта во время реализации или тестировать гипотезы.

● Как это работает?
Каждый спринт начинается с планирования — например, на первом этапе команда будет делать макет будущего приложения. Глобальные задачи — их ещё называют эпики — на этот спринт будут следующие: нарисовать mind map с функциями, затем сделать прототип в Figma, согласовать с клиентом. Задачи на спринт участники команды определяют вместе с проджект-менеджером.

Промежуточным результатом для клиента будет макет будущего приложения. Чтобы команда могла двигаться дальше, клиент комментирует, что нравится, а что хочется улучшить. Эти задачи будут решать в следующем спринте.


📍Waterfall
Этапы разработки в Waterfall похожи на Agile. Основное отличие в том, что они идут последовательно и не взаимосвязаны друг с другом, закончен один — команда переходит к следующему.

Waterfall не предполагает промежуточных изменений. Если даже они появятся, ни на одном из семи этапов их вносить не будут. Команда действует строго по ТЗ, которое согласовали на старте.

● Как это работает?

В начале работы клиент прописывает свои ожидания от дизайна и функциональности. Например, хочется отдельный раздел с акциями, который будет открываться при входе в приложение, личный кабинет, где покупатель сможет отслеживать заказ, и блог — электронный журнал о книжных новинках.

Все требования учитывают в техническом задании, которое клиент согласовывает на старте, и формируют финальную документацию для работы над проектом. После этого оценивают объём работ и сроки.

————————————————————

Каждый проект уникален — разные требования, специфика, состав команды, заказчики, внешние условия, поэтому удобнее совмещать

Китайцы дропнули электрокар SU7, цена которого в фирменных магазинах начинается от ¥500.000 (почти 6.5 млн рублей).

Наверное, единственный китаец, которого бы я сейчас взял. Есть одно но где взять 6,5 лямов??))

Вот такие решения очень пугают)

В данном случае Cybertruck говорит о том, что какие-проблемы с вольтажом в тачке - попробуйте выйти и зайти снова.

Просто от таких нотификейтов ощущение, что авто сейчас взлетит на воздух

Цыгане диджитал переобулись и теперь лечат от сглаза)

У вас плохой дизайн? Заказчик не платит вовремя? Пиксели не ложатся красиво? Дедлайны играют против вас? Коспоненты в фигме слетают сами? Композиция на банерах оставляет желать лучшего? Типографика не клеится? Не получается поженить оба варианта? Слишком душный ПО? Вопросы с исследованием не удается провентилировать? Релиз постоянно откладываются? Заказчик назвал финальный дизайн «черновыми матетами»? Не удается приземлить концепцию? Наигрались со шрифтами, хочется чего-то новенького?

Можете продолжить список)