Добрый день, коллеги ... несмотря на то что уже ночь на дворе.

Часто слышу от руководителей проектов и линейных руководителей в достаточно больших организациях о том, что из-за особенностей разрботки ПО собственными силами для нужд организации невозможно улучшать процессы и т.п. ... Меня это всегда несколько удивляет. В принципе я сам работал как в софтверной компании, которая делает ПО на заказ или как фрилансер с командой коллег ... и как тот самый in-house разработчик. Принципиальных отличий, кроме условной защищенности контрактом у подрядной организации мне не приходит на ум.
Интересно, можно ли софрмулировть 10 принципиальных отличий in-house разработки от компании-разработчика софта на заказ?

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

Единственное отличие внутренней разработки от разработки на заказ - это то, что с компании-разработчика зачастую требуют всякие там документы по стандарту (ГОСТ, СРС и т.д.), да и модно нынче сказать в качестве рекламы, что мы используем РУП и ЮМЛ, поэтому хошь не хошь, а приходится им постигать новые методологии и стандарты. А для внутреннего разработчика зачем что-то новое внедрять и так все работали сто лет и так проработают, если нет инициативных людей, которые видят кучу ошибок в организации процесса разработки.

Кстати, а компания-разработчик, которая делает один большой коробочный продукт - это как считать??

Кстати, а компания-разработчик, которая делает один большой коробочный продукт - это как считать??

А это ещё одна категория, отдельная. COTS-продукты, массовые сервисы, игры, встраиваемое ПО. Вот только Юрий вроде достаточно чётко вопрос поставил, без них.

Спасибо за ответы.
Тут вот еще какие моменты ...

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

Для внутреннего отдела деятельность
а. трудно измерима по результатам (значит, улучшение затруднено)

Но ведь метрики/KPI можно снимать и с внутренних процессов ... и измерять их и соответственно улучшать эти показатели?

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

Для производителей ПО на заказ ситуация к сожалению значительно хуже, чем кажется со стороны.
1. Результат определяется полученными финансами соотвественно:
 а. Для Fixed Price Чем меньше сделаешь, тем эффективнее будешь.  Кроме того сразу открывается простор подсаживанию заказчика на крючок, "процентовочкам", "боданию" за каждую новую фичу и т.д.
 б. Для T&M принципиально не интересно иметь производительность выше того порога при котором заказчик уйдет. (Именно по этому многие крупные компании делают ставку не на профессионалов а обучающихся студентов)
2. Конкуренция Пока конкуренция условна. Получение большинства проектов связано с величиной надутости щек и эффективностью Accaunt Manager. Ждемс :-)
3. Прибыль см п.1.

С этой точки зрения ситуация должна быть  лучше в продуктовых компаниях (Основной бизнес + Заинтересованность в результате) ... Но там свои тараканы.

после поста cless и Boatman складывается ужасное будущее для развития разработки ПО везде ....

Можно было бы провести семинар и на эту тему тоже ...

после поста cless и Boatman складывается ужасное будущее для развития разработки ПО везде ....

Согласен что мой пост несколько циничен, но ничего о будущем в нем не было сказано.

Вопрос времени, профессиональной этики и конкуренции :-)

Если каждый профессионал при выборе места работы будет учитывать этичность принципов которыми руководствуется компания, то отрасль "всплывет" :-)

Слава богу в ИТ сейчас проблем с вакансиями просто не существует 

проффесиональной
проффесионал

от слова профессия, профессор, профессиональный, профессионал, профессорский ну и так далее

Если каждый проффесионал при выборе места работы будет учитывать этичность принципов которыми руководствуется компания, то отрасль "всплывет" :-)

Слава богу в ИТ сейчас проблем с вакансиями просто не существует 

Найти бы эти "этичные" компании и вакансии, а так всякой шушуры полно - я с тобой согласен.

Хочу подвести небольшой итог:
Потенциал развития в сторону улучшения процессов разработки больше у софтвеерных компаний по нескольким причинам:
- внешняя конкуренция
- большее кол-во сотрудников ИТ именно в разработке ПО в софтвеерных компаниях, следовательно бОльшая веротность найти единомышленников
- более широкой охват технологиями и разными областями
- более профессиональный подход в области подбора персонала (хотя это спорно)

И для Юрия.
Я подозреваю, что вопрос не праздный: он вызван стандартными возражениями потенциальных клиентов, когда им предлагают внедрение упорядоченных процессов разработки. Мое общее мнение по этому поводу: эксплуатационщикам (коими в большей части являются in-house) нужно не то же, что и производителям.

Вопрос вызван в большей части именно продажей процессов SE и именно в условиях, когда компания разрабатывает внутри себя программные продукты. И соотношение доработки/новое ПО около 60/40 %. Со временем, и с течением зрелости процессов компании и ее менеджмента это соотношение может изменяться в сторону увеличения доли доработок существующих систем и внедрения "коробок" или кастомизированных решений. В этом случае будет рулить ITSM, особенно если заказы по разработке на аутсорсинге. И P&PM тоже будет востребован.
Для эксплуатации бесполезно предлагать процессы SE .. им пойдет очень даже ITIL/ITSM.

от слова профессия, профессор, профессиональный, профессионал, профессорский ну и так далее

Спасибо :-)

Спасибо :-)

Не начем, просто один раз описка, два уже закономерность :-)
Да, кстати, посмотрел перевод в ОпенУП базовых принципов, мое мнение таково: перед публикацией нужно стараться внимательно проверить текст на выявление ошибок, описок, правил синтаксиса и пунктуации. Ну следует уважать себя и читателя. Когда в тексте много ошибок, описок и т.п. создается впечатление не серьезного отношения к печатаемому. Кроме-того, думаю не имеет смысла оставлять англоязычные фразы целиком. В конце концов, исходный вариант же остается, и никто не мешает читателю обратится к первоисточнику.

Извините за оффтопик, но уж больно гладко сообщение клеится