rubsterНабрел на одной из тем форума вот на такую схему организации взаимодействия подразделений по разработке ПО
/topic/358492&pg=5#3424564
Вопрос оказался достаточно актуальным
Однако, вопрос интересен в контексте внедрения одной из ERP систем (модификации)
Должен заметить, что ощущается неслаженность работы. ТЗ выдается в разработку, разработка выдает продукт, далее модификация ТЗ, далее опять возврат... Короче говоря очень маленький процент случаев когда запрос клиента проходит прямой путь без возвратов от самого запроса до выдачи готового продукта клиенту. Приведенная схема достаточно интересна. Как указано в сообщении "обсосано сто раз". Однако, лично я не часто наталкивался на информацию подобного рода. Хотелось бы изъявить возможно не только мое желание сбора информации по этой теме и сосредоточение ее в этой теме. Будет это будет полезно не только мне.

постараюсь не сильно размазывать мысль по древу....укажу лишь минусы представленного чертёжика...
на данном чертёжике видно, что нет ОБРАТНЫХ связей до клиента. и пока крутилось внутри конвеера (программеры-тестировщики-новый функционал) получили вместо "ужа", 100 метров "колючей проволоки". Которая в свою очередь заказчику нафик не нужна...
или по другому...при такой архитектуре организации работы - слишком велики риски...


удачи Вам
(круглый)

ФлеймерСхема слишком линейная. Заказчик должен быть вовлечен во все этапы разработки, а не ограничиваться точечным контактом с аналитиком.

+1

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

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

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

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

на мой взгляд плавная "прорисовка" решения возможно только с нахождением тех участков логики, которые не будут меняться в дальнейшем процессе (ну или почти не будут.). т.е. более статичные весчи чем цвет и вкус заказчика... на мой взгляд технология отвечающая таким требованиям - Объектно Ориентированный Анализ и Проектирование. Именно она может способствовать фиксации сущностей от итерации к итерации...
например...
если заказчик ведёт речь о шиномонтаже, то явно на сцену выходят такие сущности как колёса, машины, обода, резина, грузики, нипеля и т.д. и т.п...

Т.е. что бы заказчик не придумал новое - всё равно найденные ранее сущности не исчезнуть. Они могут наполниться другими глаголами и свойствами - но исчезнуть вряд ли. Т.е. они (можно сказать) для задачи - статичны. А там где статика - там простота решения и элегантность кода...

это только методология... а ещё есть управление людьми. есть взаимодействие подразделений. есть автоматизация документооборота...много чаво влияет на "конвейер разработки".


с уважением
(круглый)