HomosumМожет кто сталкивался инфой, которая рассказывает о структуре компании, которая разрабатывает ПО.
Ув. Homosum Расскажите поподробнее что за проблема. Сами предприятия по разработке ПО очень разные и соответственно структуры внутри этих компаний разные. Даже внутри Майкрософта и Гугла каждый департамент сам по себе.

Naroto думало что начать Вам следовало бы с внимательного изучения практики этих серъёзных компаний - наиболее успешно внедрены принципы построения ПО у Мелкомягких. Посмотрите внимательно вот сюда найдите книжечку на русском языке Naroto точно знало что такая книжечка есть. Автор Майкл Тернер

В общем случае должны быть освещены следующие софт дисциплины:

.

Если уж совсем детально требуется - пожалуйста определите какое именно ПО ваша команда пишет (ERP/CRM, End-user software, web-development, video games etc)

Narotoнаиболее успешно внедрены принципы построения ПО у Мелкомягких.
Naroto забыло что wiki и на русском языке есть... "Склеротик ©"

HomosumРазрабатываем ПО самого разного направления и ERP и енд юзер и веб (практически все, кроме игр и системных программ).

Ну вот Naroto немножечко сообразило что к чему. Давайте, ув Homosum, рассмотрим с очень высока (10 000 фт) вашу возможную структуру. Итак - разработка ПО - опыт ~ ограничен. То есть своего продукта нет. Если всё так как вы описали - Ваша компания занимается оказанием консультационных услуг в сфере программного обеспечения. Работает под стороннего заказчика . Naroto угадало? А Значит самое главное внимание должно быть уделено именно сервису. У Вас должны быть как минимум пол состава этого Отдела Разработки ПО - профессиональные маркетологи, понимающие и умеющие работать с заказчиком. Должности им можно раздать любые - программный менеджер, продуктивный менеджер, проектный менеджер - называйте как хотите - но их задача удовлеторять все прихоти заказчика. И Всё документировать. Вот именно здесь вам и понадобится опыт работы с MSF. Никакой связи с инфраструктурными (хардверными) отделами компании по логике вещей быть не должно. Продукт продуктом - Сервис Сервисом. Можете использовать рекоменуемые ими системы, но и они - чаще всего уступают серъёзным существующим хостингам виртуально-облачным на серъёзных проектах. Расценивайте свой отдел Разработки ПО как отдельную обособленную часть бизнеса. Дело в том что и методы и расценки и результат работы абсолютно чужды продажам продукта (инфраструктуры) и продажам сервиса (консультантов). Naroto бы советовало полностью разделить бизнес. В Программно-Сервисном отделе Введите матрично-командную систему. На один проджект в офисе - 1 функциональный менеджер (два три проекта под контролем), 1 проджект менеджер (Координатор проекта), 1 архитектор (на основе выбранной платформы), 1-2 DBA (выбранная платформа), количество Девелоперов и QA должно быть приблизительно одинаковым. QA не в подчинении архитектора - обычно в подчинении Заказчика и его представителя. И очень много внедренцев у клиента. Среди них обязательно очень сильный бизнес аналист (Представитель Заказчика).

Как рекомендация - должен быть полностью свой бюджет и свои "традиции". Выбирайте аджайл для маленьких проектов и ватерфол для больших. Но и в том и другом случае - клиент {представитель заказчика} должен участвовать во всех аспектах подготовки разработки и внедрения проекта. Naroto думает что если бы заказчиком Отдела разработки ПО был бы отдел реализации хардвер - было бы всё по-другому. Но Вы этого не указали, или Naroto ошибло?

У Naroto в компании ситуация другая - Программное Обеспечение пишется специально для нужд основного бизнеса - а основной бизнес как раз и есть продажа Инфратруктурных систем холодного хранения / обработки органического материала. Ну представьте себе рефриджираторы которые перевозят бананы, бананы очень скоропортящийся груз - температурная составляющая при транспортировке - наиважнейший показатель. Холодильные Транспортные системы и Хранилища - и есть ПРОДУКТ компании. Отдел Разработки ПО - в общем случае готовит системы настройки и хранения данных для таких систем. Очень специфичный продукт {Программное Обеспечение}. На полках его нет, потребителями являются потребители рефриджираторов. Например компания NASA купила хранилище - заливалище холодного азота. Программа которую мы выпускаем нацелена специально на NASA и холодильник в котором хранится этот самый азот. Она коллекционирует данные обо всех этапах содержания и всех (в том числе и аварийных) режимах транспортировки. То есть хотя заказчик сторонний - NASA - без знаний и особенностей холодильников выпускаемых хардверной частью компании программы бесполезны. И никому не нужны. Ну и не напишет под заказ никто другой без особенностей Интерфейса с Нашими холодильными установками. То есть хардверная и софтверная составляющие ВСЕГО КОМПЛЕКСНОГО ПРОДУКТА очень сильно взаимосвязаны. Как Naroto мыслит - это не ваш случай. не так ли?

Ещё одна особенность работы - выбор платформы. Например Naroto со своим ПО для хранения данных не может диктовать условия для внедрения у заказчика. Что заказчик скажет - хочу базу данных на DB-2 супермашины - пожалуйста, Oracle - всенепременно, MS SQL Server - как стандарт. То есть функционально продукт один и тот же - реализация и воплощения разные.

В Случае с Консультационными услугами - тоже есть смысл содержать специалистов двух трёх платформ Ну как пример Java + Oracle; .NET + MS SQL Server; LAMPs ну и на крайний случай DB-2 + Visual COBOL... Или стать внедренцем {Value Added Reseller} какой нить общеизвестной системы типа Oracle Manufacturing, SAP, Axapta, 1C ну и так далее. Но это чисто технические вопросы, Вас какак Naroto себе поняло интересуют больше бизнес-кадровые-организационные проблемы. Или опять ошибло?

Просто спрошу и всёУважаемые, а если немного сместить акценты?

Ув. Просто спрошу и всё .... Ну Вы канешна уверены что везде "там где-то" всё идеально. Да посмотрите на всех включая Гугликсов и Мелкомягких. Поначалу везде был своего рода бардак. Или - скажем так - хаотический рост разброд и шатание. Мелкомягкие пришли к MSF спустя 15 лет существования компании. Структура Формальных отношений в любой компании появляется с годами и опытом. А поначалу - до формального "матёрывания" все компании одинаковы - все выглядят как стартапы. Есть пару-тройка лидеров с опытом и знаниями, есть куча "студентов" среди которых появляются звёзды и очень быстро. А вобщем бизнес развивается своим чередом - и только по достижению каких то успехов образуются своего рода порядки. И совершенно неважно какой по-началу структура была, все хотят сделать "правильно" а как правильно - или "бест практика" - читайте Майка Тернера - там написано КАК должно быть а не то что есть. Вы бы лучче рассказали как у вас с ЭТИМ дела - а мы вот посидим и помозгуем. Всё равно ведь ничего менять не будем, Naroto так думало... Или Naroto ошибло?

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

Точно так же как это было сделано сто пиццот лет назад успешной Мериканской компанией Oracle, Microsoft, Google и так далее... For example: "Без царя в голове", "как попало" , "хаотически", "на авось".... и так далее и тому подобное...

Замечательное повествование о том как Российские (и не только) компании взлетали изложено вот тут . Ув. Garya. Naroto бы заметило что Всёжтки в MBA есть много положительного. Naroto понравило сравнение автора с полётом и пилотами. Особенно в отношении к управлению предприятием {Читаем внимательно-пилотированием самолёта}. Сначала нужны "толкачи" - холерики, Потом "педанты"-флегматики, а вот в конце - работник похоронного бюро :) .

Так вот если рассматривать эту теорию применительно к Компании по разработке ПО - А у Naroto накопилось много интересных знакомых такого рода во всём мире - то наступает - обязательно наступает момент когда книжечки про MSF и про SCRUM и про методологию со стандартами ну просто нельзя будет не читать. Потому как полёт будет прерван и набарнная высота очень скоро станет дном .... Так что смотрите...