Четкого плана работ в такой ситуации не будет никогда - вернее, он будет столь часто перекраиваться и нарушаться, что смысла в нем нет.

В целом, у Вас как-то свалены в кучу разные вещи: план работ, ТЗ, инструменты анализа и проектирования, общая технология......

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

Оптимальной для такой ситуации я полагаю следующую схему: полноценно документируется общая архитектура модуля, то, что можно назвать решением стратегической задачи. Детали документируются непосредственно в программном коде "на ходу", и исправляются вместе с внесением изменений в модули; исправления стратегических документов при этом как правило не требуется.

NikolayKно что-бы слова имели вес надо обосновать.
Лучшее обоснование для слов - практика. Особенно для человека, мало знакомого с "кухней".

В этой связи я довольно часто вспоминаю один эпизод, который у меня был несколько лет назад. Тогда состоялся примерно следующий диалог (формулировки, разумеется, не дословные имя "Ваня" сугубо условное):

Начальник: Саш, вот надо сегодня это сделать
Я: Никак. На это нужно дня четыре
Начальник: Да ладно тебе, вот Ваня бы сделал
Я (пожимая плечами): Ну пусть Ваня и сделает

(через пару дней)

Начальник: Саш, ты говорил, что дня за четыре сделаешь? А то Ваня сделал, но.....

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

NikolayKВ этом-то и состоит вопрос кто какой технологией пользуется.
В первую очередь нужно определить требования, которые бизнес к вам выдвигает. Я бы предположил примерно следующее:

- время исправления критических ошибок и недоработок порядка часов, в худшем случае дней

- реализация поставленных задач в порядке их срочности и важности с регулярным выпуском новых версий (недельная или месячная периодичность, лучше недельная)

- планомерное покрытие новых областей (если система недавно начата и еще не охватила деятельность предприятия)

- возможность внезапного возникновения приоритетных задач

- наличие некоторого количества несложных хотелок, которые следовало бы сделать быстро по политическим соображениям (пожелания руководства итп)

В такой ситуации безусловное "ждем ТЗ, потом планируем, потом рисуем..." просто не пройдет по времени. С другой стороны, "сразу бросаться кодировать" - породит страшного и бесполезного монстра.

Примера замечательной работы в такой ситуации я не видел и не организовывал. По незамечательному примеру, в котором участвовал (с сильным перекосом в "сначала запрограммируем, потом подумаем"), и по прочим виденным я бы сказал так:

1. Обязательная документация по задачам должна быть минимальной; такой, чтобы программист мог не особо напрягаясь проработать ее по ходу решения задачи. Скажем - ER-диаграммы плюс документирование решения в программном коде.

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

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

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

Что именно есть "идеологически правильная цепочка" - решайте по месту, тут уже вам виднее. Главное - гибкость; главное - чтобы большие и серьезные задачи были правильно спроектированы, но в то же время их можно было "за полчаса" доработать по мелочи и это не требовало бы внесения изменений в кучу документов.

Хм. С технической точки зрения на "как" ответов предостаточно - и технологии, и инструменты есть.

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

Мне так кажется, что при команде в двенадцать человек вполне можно выделить бюджет на квалифицированного тестировщика; его присутствие окупится экономией времени программистов, которые сейчас лениво и неумело тестируют свои программы (и говоря честно - один тестировщик утонет в объеме работы, который ему подбросят двенадцать разработчиков. Что же до "одного консультанта, который в том числе и тестирует" - тут и речи быть не может о сколько-нибудь адекватном покрытии, если конечно программисты не проводят весь день за квейком).

Что же до "пользователи звонят и сообщают" - безусловно, какое-то количество ошибок всегда будет прорываться, но при нормальном тестировании можно добиться достойных показателей. Но тут есть еще один момент, которого я опять же пока нигде не видел внедренным, но который считаю важным (может быть, постепенно раскачаю на текущей работе) - мне представляется важным анализировать проблемы. Не просто исправлять, но тратить время на то, чтобы выделять классы регулярно возникающих проблем и искать, что переделать в технологии так, чтобы эти проблемы ушли; где та дырка, которая их порождает.

NikolayKДля анализа проблемы надо накопить статистику
Безусловно. Но это интеллектуальная работа, не по формальным признакам.

NikolayKЯ попросил что-бы мне написали програмулину(может велосипед конечно, но что-то похожего не встречал)в которую заносятся проблемы по программным модулям,
Это называется bug tracker , существует в уйме вариаций, платных и бесплатных.

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

dvvvУ меня хорошее качество тестирования наблюдалось при соотношении числа программистов к числу тестировщиков 2,5:1.
Имхо оптимальное соотношение зависит от слишком многих факторов. 12:0,5 - это, конечно, не дело, но затруднюсь советовать "сколько именно надо".

dvvvОбычно пользователей трудно заставить пользоваться багтреккером
Имхо вопрос не столько в "трудно заставить", сколько в "хорошо все равно не напишут - не умеют".

Проба сил№На самом деле скорее АВТОРИТЕТ человека который это заявляет...
А откуда этот авторитет появляется, если предположить, что начальник - не идиот? Именно от "сказал и сделал".

Проба сил№Иначе начальник может и приказать как в армии...
Может. Примерно как в той ситуации, что я цитировал выше.

Проба сил№Всегда важно иметь разделение на поддержку и развитие.
Спорно; весьма спорно.