Когда считать процесс разработки ПО завершенным?

Question

[0xA0]

Надеюсь опытные разработчики подскажут ответ на вопрос:
В какой момент необходимо остановить процесс разработки ПО, чтобы остаться довольным результатом, а не думать «тут мог бы лучше сделать, и там тоже...»?

Answer 1

[jj_killer]

Ответ один — когда заканчивается поддержка. Срок поддержки устанавливается на этапе проектирования или сдачи проекта. Он может быть продлен, но не наоборот.

Answer 2

[super]

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

Comments

[0xA0]

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

[super]

Так ведь весь смысл ПО не в том что вы его напишете (что кстати несложно), а в том что вы будете его поддерживать и развивать.

Answer 3

[Вячеслав Плиско]

Здесь два одновременных варианта — никогда и завтра. Проект нужно разбивать на итерации неделе — две в конце каждой он должен иметь рабочую версию. Ну а сами итерации можно планировать до бесконечности, потому что хороший разработчик результатом практически всегда недоволен и хочет больше, лучше, выше сильнее.

Comments

[0xA0]

Вот я и задумался. Возможно ли вообще остаться довольным. Строитель построил здание-доволен, врач вытащил с того света пацинета-доволен.
А нам неужели не познать чувства удовлетворения собственным творением?

Answer 4

[Алексей Сидоров]

Когда не осталось никого, кто бы мог или хотел что-то сделать с кодом.

Answer 5

[Ro_On]

Когда проект сдан заказчику.

Comments

[Сергей Протько]

Угу… а потом период поддержки… багфиксы и импрувы…

Answer 6

[vaevictus]

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

Насчёт когда «остановиться» — если Вы делаете свой продукт, то его стоит выпускать на рынок, когда пользователи смогут им пользоваться без мата (да, тестировать нужно). А дальше — чутко реагировать на баглист.

Answer 7

[wholeman]

Определите требования, которым должен соответствовать проект. Когда они будут достигнуты, проект можно считать завершённым.
Новые идеи (кроме исправления ошибок и серьёзных недоработок) записывайте для будущих версий. Если пытаться сделать всё в текущей версии, Вы рискуете никогда её не выпустить. Особенно опасно, если надо сдавать заказчику.

Answer 8

[Krovosos]

ПО с точки зрения пользователя оценивается так: «с помощью ПО можно выполнить такую-то задачу, да или нет».

У этого «может» два основных аспекта.

1. Полнота функционала
2. Приемлимый уровень ошибок

Допустим. Ставится задача — программа создания текстов для их последующей печати.

Предположим, программисты увлеклись и сделали вставку картинок, вложенных таблиц, а вот печать пока не работает. Программу отдавать пользователям НЕЛЬЗЯ из-за пункта 1.

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

Современный софт решает много задач, но подход — тот же.

Еще помогает отслеживание темпа. Если темп замедлился, то возможно не хватает обратной связи от пользователей, чтобы принимать решения.

Comments

[0xA0]

А если не функционал развивается постоянно, а способ решения меняется на «более оптимальный»?

[Krovosos]

А пользователь в курсе, что его задачи теперь решаются «более оптимально»? Эти изменения внешне проявляются?

[0xA0]

Не всегда проявляются.Главным образом я больше доволен продуктом, а пользователь и не узнает никогда, что же там лучше.

Answer 9

[edogs]

Никогда. Это как с ремонтом. Если про «теорию».
Если про «практику», то ровно в тот момент, когда реализовано ТЗ и пофиксены все известные баги.

Answer 10

[Wott]

Как только он надоедает тому, кто его спонсирует.

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

Answer 11

[Сардар]

«Никогда». При первых итерациях сдается рабочий прототип, как можно быстрей. К 2/3 бюджета проекта обычно прототип уже делает все, что необходимо заказчику. В этот момент лучше всего отбрасывать часть фич, посвящая время тестам и доводке до ума, с энтузиазмом привлекая к этому заказчика, что бы у него не было мыслие «его кидают». Под оставшиеся 1/10 бюджета в конце берут поддержку (не разу не видел, что бы заказчик хотел вывести оставшиеся деньги из бюджета). Все откинутые фичи подробно расписываются и оформляются в v2.0. Если ваша поддержка действительно не лажает, то заказчик будет счастлив и через пол года/год создаст новый бюджет, все повторяется. Вы при этом никогда не переходите через рамки начального бюджета.

Итог: пока есть идеи, никогда.

По опыту, что бы сделать заказчика счастливым, не надо боятся откидывать low-priority фичи. А виденье приоритета появляется после первых релизов/прототипов, а не (как ошибочно думает большинство) на этапе дизайна. Откинутые и новые фичи держат проект в развитии постоянно, хоть и с паузами.