Как cделать хорошо пока не знаю что?

Сколько раз вы такое слышали?

В начале проекта:
- Нужно сначала всё продумать, учесть все нюансы и предусмотреть все возможности, а потом делать, а то получится как в прошлый раз! 

При завершении проекта:
- Ну вот, почему сразу не сказали все требования, теперь половину придется переделывать!

Но почему-то раз за разом попытки "сделать, наконец-то, все правильно" оказываются неудачными. Проблемы и причины - разные, результат - один. А если попробовать принять как данность, что мы не можем заранее все предусмотреть, и выстроить стратегию разработки программных продуктов соответствующим образом?
Давайте попробуем!

Шаг первый - концепция продукта.

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

Шаг второй - планируем путь.

После безудержного полёта фантазии - самое время спуститься на землю и составить план действий для достижения светлого будущего.
Распространенная ошибка заключается в создании плана реализации придуманного идеального продукта. Фантазия у всех богатая, идеи - самые лучшие, продукт будет просто замечательный. Сделать его, естественно, хочется сразу хорошо и полностью, а это требует немало времени и денег. Встреча продукта с объективной реальностью происходит нескоро, и часто оказывается, что придуманный продукт не очень в неё вписывается. Вот тут-то мы и слышим присказки, упомянутые в начале.
Ошибка кроется в подмене цели. Очень легко забывается, что идеальный продукт существует в придуманном мире. А ведь наша цель - это не сделать продукт, а оказаться с его помощью в новой реальности.
Окружающая нас действительность довольно консервативна, она не любит резких движений. Только плавное изменение в правильном направлении приводит нужному результату. Поэтому планировать нужно не создание идеального продукта, а постепенное изменение мира в нужную сторону. Только какое же направление изменений правильное? Ответ на этот вопрос подскажет интуиция, опыт и … эксперименты.
Для начала предположим, что мы выбрали правильную конечную точку и составим путь из промежуточных небольших изменений. Это и будет наш план. По мере движения по этому пути важно отслеживать фактические изменения (получать обратную связь от заказчика, "слушать рынок" и т.д.) и соответственно корректировать своё видение будущего. Иногда, понимая что мир сопротивляется и совсем не хочет прогибаться в запланированную нами сторону, приходится делать довольно резкие повороты. Специалисты называют это умным словом pivot.

Шаг третий. Создаем продукт.

Добрались до самого вкусного. Теперь мы последовательно развиваем продукт, выпускаем версии, каждая из которых делает мир вокруг себя немножко иным, не таким как был до этого. Реальность меньше сопротивляется, когда малые изменения происходят почти непрерывно. Отсюда первое правило, тактическое - выпускать версии с полезными свойствами как можно чаще. Для разработчиков это означает, что не стоит без явной необходимости ввязываться в долгосрочные и глобальные работы. Решения должны быть максимально простыми, быстро реализуемыми. Здесь кроется опасность, многие воспринимают это правило как индульгенцию для непродуманных и поверхностных поделок и костылей, в результате после быстрого старта темпы разработки резко снижаются. Избежать этого помогает второе правило, стратегическое: каждый шаг должен в идеале - приближать, а как минимум - не отдалять нас от идеального продукта, который мы придумали на первом шаге (ещё помните про него?). Для разработчиков это означает, что (в соответствии с первым правилом) не стоит сразу тратить время на реализацию всех возможностей, которые могут понадобиться в будущем, но (в соответствии со вторым правилом) ни в коем случае не забывать о них, учитывать при планировании архитектуры и не блокировать возможность реализации в следующих версиях. Такой подход помогает избежать неуправляемого накопления технического долга.

Вместо заключения

Вот так, шаг за шагом, версия за версией и доберемся до светлого будущего. Не забывайте периодически корректировать свои представления о текущей цели, чтобы не потеряться в пути. Будет ли наш продукт и новый мир таким, как мы его придумали на первом шаге? Всё может случиться, но мне кажется, что вряд ли. В процессе пути меняется мир, меняемся мы, меняется наше видение цели. Мир большой, всегда найдется что-то ещё, что тоже стоит изменить к лучшему ;-).