rubsterНабрел на одной из тем форума вот на такую схему организации взаимодействия подразделений по разработке ПО
rubsterГоспода, поактивнее!
Думаю эта проблема актуальна для многих компаний
Был в отпуске.
2 rubster Если у Вас есть вопросы конкретно ко мне то готов ответить на вопросы.
Собственно по указанной мною схеме реализовывал не однократно разработку-сопровождение ПО.
По развернувшейся дискуссии не понял в чем Ваш вопрос заключается.

kolobok0на данном чертёжике видно, что нет ОБРАТНЫХ связей до клиента(круглый)
абсолютно верно. Не являюсь автором данной схемы. Указанная схема публиковалась в открытых источниках как рекомендательная. Естественно полную схему разработки ПО как мы её создавали опубликована не может быть по коммерческим соображениям.

rubsterвопрос собственно в следующем: какая схема жизнеспособна? :) в приведенной мной схеме, что бы подправили?
....
хотелось бы таки посмотреть на Вашу реализацию ...
Не хочу показаться ведущим знатоком в области конвейеров по разработке ПО
Но по сути дважды приходилось формировать такие конвейры. Первый раз для собственных нужд компании, второй именно для компании занимающейся разработкой и продажей ПО.
У нас идиологически подход был таков
1. если аналитики, тестировщики и кодеры подчиняются одному руководителю, то он может оказывать на них давление для ускорения процесса разработки и передачи клиенту. ПМСМ это негативный фактор, отсюда, разделения на группы с подчинённостью руководителю именно по своему направлению. Согласно схемы разделение на отдел Главного конструктора(аналитики), Кодировщиков, Тестировщиков. Т.о. мы исключенили давление общего руководителя, который по определению не может быть спецом сразу в 3-х областях.
2.теперь обратите внимание отдел Главного конструктора, он разделен на 2-е части с общим руководством. Поясню, у нас сложилось разделение на системных аналитиков(СА) и бизнес аналитиков(БА). БА у нас занимались именно подготовкой ТЗ как документальное описание процессов и т.п., СА занимались моделированием ТЗ на IBM Rational (концептуальная модель и т.п.)
3.Далее весьма близко к схеме, т.е. на Вашей схеме "программист", а у нас был кодер, DB девелопер, линковщик и т.п. Не может быть человеком профи по всем областям, отсюда узкая специализация. Опять же разграничение на зоны ответственности.
По Вашей схеме могу заметить отсутствие двунаправленности в стрелках. У нас движение всегда было в обе стороны для ускорения исправления ошибок.
Описанная Вами схема упрощённая, как мне кажется такова д.б. для собственной разработки, а не продажи. Замечу, чем более она будет детализированна и будет разграниченна ответственность групп главного конструктора, кодеров, тестировщиков и т.д., тем более она будет прозрачна для ИТ и что главнее для вашего руководства и заказчиков.
До полных моих схем тяжеловато добраться. В Мурманске всех кого я там знал разбежались по всему миру. То что делал в Твери практически идентично схеме которая Вас заинтересовала, кроме того, что ядерная группа входила в группу программистов и стрелки у нас были двунаправленны между Группами. По договорам+продажам ни чего сказать не могу, т.к. этим занимались менеджеры. В остальном схема именно была такова.

rubsterвопрос собственно в следующем: какая схема жизнеспособна?
Есть флотская поговорка, какой капитан так и судно поплывет
Это я к тому что надо начинать с руководящих кадров. Либо обучайте своих, либо ищите спеца с таким опытом.