Согласен. EDS - отличный пример, по дороге выяснится кое-что непривычное местным работникам.

Ну и сразу дублирую свою реакцию на него из параллельной ветки:

Обсудим?

Надо сказать, что общепринятое определение аутсорсинга значительно отличается от Вашего:

Только и всего

Принимается, я, конечно, говорил о конкретном программистском аутсорсинге. Поправил.

Отличается, кстати, незначительно.

Чаще правда, чем нет. Алгоритмы, планирование, проектирование -- какая-никакая наука. Кодирование в соответствии с ТЗ -- ремесло.

Теоретически - да. Но, практически полностью. Это я как старый ИТшник заявляю.

Мне даже представить трудно того, кому нужно предавать на аутсорсинг нечто, что может стать инновацией. Тут есть некоторая наша особость - повторное использование кода. Именно из него на аутсорсинг передается только одноразовый код, что невозможно использовать в других проектах (откуда инновация?). А другой стороне нафига нужно? Лучше компонент самому продавать.

Хотя - дураки встречаются. Но тогда откуда возникнут инновации?.
Не - не бывает.

ИМХО, EDS -- подозрительная компания. Значительная часть их выручки -- это поступления от 10-летнего контракта с ДжиЭм, который вроде бы заканчивается в этом году. Фактически их благополучие зависит от нескольких крупных клиентов: уйдут клиенты -- и все их показатели рухнут.

Или я где-то ошибаюсь?

Технопарк - как девелоперский пороект им на прямую не поможет, и помогать не сможет. Пусть думают. Иногда это полезно!

Я не говорил, что я вижу ТОЛЬКО такой. И не говорил, что другого НЕ существует. Так что напрасно старались, по крайней мере в мой адрес. String пусть сам решает, зря или не зря.

Вообще, КПД обращений ко мне у Вас очень низкий -- пишете очень много, но бОльшую чась -- напрасно. Вы сперва начните хотя бы точно читать то, что пишу я.

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

ЗЫ. Еще раз - из всей цепочки программирования - системный анализ, проектирование, кодирование, последнее - просто ремесло. Инновации начинаются в первых двух. Что, собственно, и пытался довести до вашего разума aspopov.

Дык программирование вообще не наука, это инженерия. А вот насчет инноваций Вы не вполне правы, могут иметь место быть. И пример бывают.
К тому же, сила конкретного примера EDS вовсе не в аутсорсе кодирования, их конкуретное преимущество - поддержа сложных информ систем и бизнес-процессов. На том уровне, который для России сегодня примерно как полет на Луну для Италии - вроде можно, вроде рядом, вроде понятно, а никак никогда.

Еще раз - мы говорим о разных вещах. Я говорил и говорю о наукоемком программировании, т.е. о создании ПО, требующего существенных вложений в лежащий в его основе математический аппарат. Обсуждение любого другого программирования в контексте строительства Технопарка неуместно. Мы ведь исходим из следующей предпосылки (цитата из интервью с директором Технопарка по развитию и связям с общественностью Алексеем Алексеевым):

А в наукоемком программировании Coding (а также забытые Вами с aspopov'ым Testing и Maintenance) - это как раз те этапы, где требуются инновации. Будете спорить?

Программирование (процесс создания программного обеспечения для вычислительных машин, систем и сетей) - может быть не только (1) инженерией, но и
2) поставленным на поток производством,
3) математикой,
4) искусством,
5) перформансом,
6) управлением проектами.
Чаще всего - все это вместе взятое.

Dimitri, Вы с завидным упорством пытаетесь игнорировать потребности покупателя и вынудить его купить то, что вам кажется занимательным делать. В каких-то рамках это даже возможно, но всегда только на время. Ключевое место Стринга в начале, а не в конце. Если системный анализ и проектирование пройдены, остальные этапы - конвейер. По большому счету, без разницы, кто его сделает. Пока русские программеры обладают таким соотношением цена-качество, пусть и они тоже. Будут стоить больше - ключ у хозяина или аутсорсера более ранней стадии, передадут подряд легко. Вы переоцениваете значение цирка с алгоритмами и кодами.

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

Согласен, программирование - ремесло. Если хотите науку, то это информатика + дискретная математика + ...

Начнем с того, что наукоемкие разработки всегда начинаются с создания прототипа. Прототип может создать только тот, кто обладает ноу-хау.
Но предположим, что прототип создал сам заказчик и передал проект разработки продукта на аутсорсинг (хотя это и выглядит странно в контексте обсуждения технопарка, разберем этот пример - он поможет понять многое). Специфика наукоемкого программирования такова, что основная сложность в нем приходится на этап, называемый Convergence, заключающийся в том, что надо настроить алгоритмы для успешной работы с реальными промышленными сценариями их использования. Вот здесь и начинаются инновации - ведь такая настройка зачастую ведет к тому, что начальную алгоритмическую базу приходится полностью пересматривать! Разработчики штудируют горы статей, проводят собственные исследования, в перерывах от работы пишут и защищают диссертации на их основе. Вот что такое наукоемкое программирование.
А Вы пишете:

Зачем пытаться рассуждать о вещах, с которыми Вы совершенно не знакомы?

Методологические признаки науки:
1. Объективность.
2. Верифицируемость.
3. Фальсифицируемость.

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

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

Все это принадлежит к прикладной математике. Чистая наука не должна зависеть ни от процессора, ни от платформы, ни от языка, ни от искусства программера. Она должна постулироваться, теоретизироваться и доказываться исходя из доказанных теорем и утверждений.

Dimitri, я устал объяснять Вам очевидные вещи. То, о чем Вы сейчас говорите - уровень студента второго курса, эту хрень Ваш покорный слуга уже тогда знал. Вы проявляете то, то разумно назвать чем-то вроде синдрома клерка: человек делает свою узкую работу, видит в ней пути улучшения и искренне убежден в том, что путь к процветанию и счастью лежит именно в этом месте, в улучшении порядка складывания папок.
Вы текст свой перечитайте и подумайте. Не вспоминайте, не ассоциируйте, а подумайте. Даже в Вашем тексте ключевое место - "реальные ... сценарии". Это означает, что либо вам надо врубиться в реальные процессы и так моргать глазками, чтобы клиент поверил, что вас можно туда допустить, либо клиент уже этот анализ и проектирование проделал. Перестаньте, наконец, произносить заклинания и поймите - это Вы здесь мало про всё это знаете. Потому что самой важной части никогда не видели, процессы эти никогда изучать не пытались. А раз так, прекратите гнуть пальцы и смените режим на задавание вопросов - пока что Вы умудряетесь пропускать простейшие и самоочевидные вещи (из-за синдрома чукчи-писателя) и с апломбом рассуждать на уровне студента младших курсов. Попробуйте читать то, что Вам и другим пишут. При правильном подходе это может дать Вам навыки участия в конструктивной дискуссии и помочь избавиться от мерзкой манеры местных наукеров говорить, ничего не слушая (почему они и живут нищими - в долгосрочных терминах все заслуженно и все справедливо).

ЗЫ Кстати, если бы Вы действительно понимали в предмете, Вы должны были бы на автомате указать, о каком именно прототипе идет речь. Данное неразличение - следствие уровня микросреды, в которой Вы работаете. Так, профессиональная мелочь.

Пардон, я потерял нить спора с Вами. Все началось с Вашего утверждения "наукоемкие исследования - ... не наука". Каким образом его подтверждает Ваш последний пост?

gutterboy, отвечать на это хамство выше моих сил, но буду один раз с вами (позвольте с этого места именовать вас с маленькой буквы - в знак моего к вам неуважения) терпелив. В каком месте вы нашли в моем тексте какую-то агитацию за процветание и счастье? Единственное, что меня возмутило в этой ветке кроме вашего хамства - это безграмотное высказывае пользователя aspopov (подхваченное пользователем String) о том, что Coding - не место инновациям. В наукоемком программировании это верно с точностью до наоборот. Если вы не считаете что наукоемкое программирование станет ИТ-специализацией технопарка, сформулируйте четко и ясно свои претензии на этот счет, и мы их обсудим.

Вы не совершенно поняли фразы "реальные промышленные сценарии". Слово "реальные" в ней использовано для услиления слова "промышленные", а вовсе не то, о чем вы подумали, занявшись проецированием.

Опять же никогда в жизни не отвечал на такое неприкрытое хамство, но сейчас попробую. Мой самоуверенный собеседник, позвольте сообщить вам, что наукоемким программированием я занимаюсь последние 15 лет (вы еще тогда под стол пешком ходили, судя по категоричности ваших сегодняшних суждений, которая вкупе с незнанием предмета однозначно выдает ваш юный возраст). Я веду речь о коммерческом программировании - за которое платят приличные деньги. Не два бакса в час, как АА говорил в своем интервью, а около 50. И я отлично знаю изнутри все процессы, связанные с созданием накоемкого ПО, ибо провел в совокупности больше двух лет в офисах одной зарубежной софтверной компании (с годовым доходом на уровне $1B), выполняя для них заказные работы. За это время я изучил все процессы от и до. И смею о них рассуждать далеко не на уровне студента младших курсов. В отличие от тех, кто даже пороха не нюхал.

Пытаюсь читать. Вот терпеливо прочитал и прокомментировал ваш пост, полный уничижительных характеристик собеседника (т.е. меня). Самое интересное, что информации в этом посте - круглый ноль. Общаться мне с вами - не о чем. Если String'у и aspopov'у я еще могу что-то доказать, то как можно говорить о вкусе устриц с тем, кто их никогда не пробовал?

Модераторам: удаление этого поста (как это было с моим предыдущим постом) без какого либо информирования меня о факте удаления и о его причинах станет для меня однозначным сигналом навсегда покинуть этот форум.

Прочитал.

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

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

Почему? Я лелею надежду, что эту информацию прочитают представители нашего местного ИТ-бизнеса, тот же Dimitri, к примеру. Это поможет им выработать наиболее эффективную стратегию на будущее в рамках того же Технопарка. И т. д.

Знаю, что ряд моментов, обсуждённых на форуме, были учтены организаторами (это из прессы видно).

Я все же надеюсь что обсуждение поможет многим представителям местного бизнеса и молодежи, особенно, продвинуться в направлении более осознанного построения бизнеса.
Поговорим о "тоскливых программерах"
Условно бизнес можно разделить на несколько классов:
1. Продуктовая модель;
2. Аутсорсинг на моноклиента;
3. Чистый аутсорсинг или Ит-консалтинг.
1. С первым бизнесом все понятно, кроме того,что развитие такого бизнеса это маркетинг, в первую очередь. Здесь есть проблемы которые практически для нашего бизнеса пока не разрешимы.
2. Работа на моноклиента (огромный сегмент существующих в АГ бизнесов) это скрытая форма внутреннего R&D. Здесь не нужно никого обманывать - нужно постораться войти внутрь компании (поглощение) происходит снижение рисков и выстраиваются нормальные отношения. В существующей схеме заказчик минимизируетсвои риски за наш счет.
3. Самое интресное - можно ли зарабатывать деньги на классическом консалтинге и аутсорсинге.
Здесь несколько моментов - прежде всего собственное позиционирование на рынке. Начну с банальностей. Но нет ничег более эффективного, чем осознание банальностей и следования самым элементраным вещам.
Аутсорсинг или ИТ - консалтинг можноотнести к сервисам или "оказания профессиональных услуг юридическим лицам" в этом Ит ничем не отличается от клининга (уборка помещений), юридических, финансовых услуг и т.д.
У данного бизнеса (услуги) есть общие правила и законы.
Правило первое - основой экономики таких бизнесов является внутренняя оценка через потраченные человеко часы. Даже если проект оценивается через фиксированную цену, менеджмент должен оценивать через человеко часы.
Бизнесы позиционируются исходя из эффективной стоимости человеко часа на проекте и через показатель "плеча" разница между стоимостью и ценой человека часа. Д. Майстер предлагает четко разделять три вида сервисов - проектов, при этом их не смешивать.
Мозги
МОЗГИ - Новые решения новых проблем
В проектах первого типа («Мозги») проблема клиента находится на переднем крае профессионального или технического знания либо является очень сложной. Ключевые элементы такого рода профессиональных услуг — это творчество и инновации: новые подходы, концепции или способы.
Проекты типа «Мозги» обычно требуют привлечения самых квалифицированных и самых высокооплачиваемых специалистов. Очень немногое делается по шаблону: каждый проект — единственный в своем роде.
СЕДИНА Best practice
Проекты второго типа («Седина»), хотя и могут содержать высокоиндивидуализированный «продукт», требуют инноваций и творчества в меньшей степени, чем проекты типа «Мозги». Общая природа проблемы известна, и действия для ее решения могут быть аналогичны тем, которые уже были проведены на других проектах. Клиенты с проблемами типа «Седина» ищут фирмы с опытом в решении именно определенного типа проблем. В свою очередь фирмы продают свои знания, опыт, мнение. По сути, они говорят: «Наймите нас, потому что мы давно этим занимаемся. У нас есть практика решения таких задач».
ПРОЦЕДУРЫ
Третий тип проектов («Процедуры») обычно направлен на решение хорошо известных проблем. Хотя и сохраняется некоторая потребность в индивидуализации, шаги для решения проблемы могут быть практически запрограммированы. У клиента могут быть навыки и ресурсы для самостоятельного выполнения работы, но он все-таки обращается к фирме, так как фирма может выполнить работу более профессионально и эффективно, к тому же она подходит к проблеме со стороны, а возможности собственного персонала клиента ограничены и могут быть с большим успехом направлены на решение других задач. По сути, фирма продает свои процедуры, свою эффективность и постоянную готовность к решению типовых проблем, т.е. она говорит: «Наймите нас, потому что мы знаем, как это сделать, и сделаем это эффективно».
Для проектов типа «Процедуры» диапазон возможных результатов на некоторых этапах может быть настолько хорошо известен, что их можно чуть ли не «запрограммировать».

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

Глупость полнейшая.
Программирование - это наука.

Предложение пойти на 4й круг (три или 4 уже было). Так что, глупость здесь Вы ляпнули, причем детсадовскую (вопрос закрыт еще в начале 80-х, задержка на 20 лет - т.е., навсегда).

Может, модеры сумеют подтолкнуть админов и достать прошлую дискуссию про инженерию и науку? можно было бы сделать из неё дайджест и положить для отсылок в библиотеку, а то у народа стремление говорить явно отстает от даже поверхностного знания.

Кем закрыт?

Интересная подача про Майстера, никак не могу собраться в кучку и сделать "этот самый текст" ответ-реакция. Так что, пока лапидарно, тезисами.
1)Не стоит забывать, что модели Майстера основаны на его ключевом опыте работы в лоерских конторах, но не все из этого опыта изоморфно переносится.
2)Модель мозги-седина-процедура - всего лишь новый парафраз упрощенного жизненного цикла прорыв-опыт-производство (конвейер). Конечно, и сам жизненный цикл несколько сложнее, и, как давно известно, в разных сферах работают разные модели и стадии развития. Майстер, как я понимаю, носом почуял новую волну темпа, как в свое время Сенге (а еще раньше Таунсенд), и сделал попытку облечь парадигму в новый образ. Меж тем, именно у него есть другая несложная модель, матрица стандартизации процессов/контакта с клиентом, она же важности/уникальности предложения. Такое впечатление, что этот инструмент сейчас будет полезнее (и рычаг, конечно), а жизненные циклы итак неплохо известны. Как выяснилось из моей дискуссии с одним-местным, наши распальцованные наукеры-программеры, которые провели по пару лет в иностранских конторах и не смогли удержаться (вечная проблема социализации...), пока что не научились даже различать исследовательские и демонстрационные прототипы, так что тут надо азбуку учить, а переводить парадигму будущего в образы немного рано (это еще одна интересная тема-фича, про образы и парадигмы).

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

Сорри всем за неперевариваемую краткость, но как-то не получается, а парни в теме сообразят. Остальные - задавайте вопросы.

В дисциплине и теме. Вы не в теме.

А есть ли IBM, который надо спасать?

Хороший вопрос. Я бы намек сделал на акцент в другом месте - без вливания в менеджмент опыта и навыков других росс бизнесов игра не получится. Внутри айти нет запаса, нет вызова и энергии. А сотрудники без менеджмента и владельцев-инвесторов значат почти ничего. Вызовы глобальны и вполне серьезны, если из пропустить, получится мелкий аутсорсинг второго ряда (но и тут не все просто). Считайте, что я только что подарил-предложил стратегию. Вот только мы оба знаем, что я.
Я бы сказал, что тот самый трюк ББ главным имел осознание невозможности выйти своими внутренними ресурсами и умение увидеть решение в других бизнесах. Результат известен. На самом деле, это не было первым примером, знаменитая история про Амекс и Авис - тоже самое, хотя там расстояние было поменьше. Это не перечеркивает другие модели, Мелкософт доказал успешность совмещения лидерства и производства, но там более тонкая и эффективная модель с персоналом, которую можно было содержать за счет сливок с передовых решений, а потом уже цикл оборота заработал.

А что Вы?

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

Юмор професс. Что я предложил, колышек.

Верно думали, не вопрос. Однако, есть тонкость. Тонкость "культурного интерфейса". Решается двумя методами - переподготовкой или наймом. Но сложность в переподготовкой в её глубине и периоде. Такие фишки проходили на стадии фронтира сер 90-х, когда иностранские конторы могли себе позволить период ввиду отсутствия даже теоретической альтернативы и стадии рынка. Сейчас они помимо роста темпа столкнулись с явной недостаточностью массы кадров и разрывом завышенной самооценки. Последний накладывается на вытекающую из культуры отношений защиту территории. Вечно этот разрыв жить не будет, первые же серьезные контракты его выявят. Конечно, первыми получат свое местный эйчар (вообще не готовый ни к чему, их подбирают стратегически неверным способом, что отражает слабость высшего менеджмента) и средне-верхний менеджмент (второй эшелон, операционисты). И вот тут будет обычная дилемма - кто-то успеет адаптироваться и научиться, а с остальными будет вопрос темпа. Вопрос: чем заполнить разрыв темпа? ответ: "герстнер". В других бизнесах темп и умение отвечать на вызовы на порядок лучше айти и около-науки, и это тоже невозможно не замечать.
Ваш ход, пишу в темпе думания.

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

А вообще логично предположить и сценарий с поглощениями (торможение в телекоме, доминирование государства в ТЭК и т. д.) -- люди с деньгами могут просто перейти из своих отраслей в ИТ и около-науку вместе со своими командами и инвестициями.

Это, похоже Вы не в теме.
Создавать и поддерживать сложные програмные системы, это вам не банными принадлежностями торговать.

bugfix, сделайте по случаю праздника исключение и прочитайте нить - точнее, соответствующий её фрагмент. Хинт: читать надо все тексты и свои тоже.

Про лоеров согласен, хотя и на другие услуги переносится достаточно полноценно. Тут вопрос в экономической моделе. То на чем появляется плечо. На управлении процессом или на новом решении.

К модели м-с-п я бы еще добавил, что она не абсолютна. То что на одних рынках, географических или иных является Процедурой на других - Супермозги.
Построение прогностической модели развития и стратегии компании на 3 года с оценкой рисков для "пацанов" с Уолл-стрит - процедура с налетом "седины" в Москве - Седина, в Новосибирске - супер-мозги, В Искитиме - вы это о чем?
В середине 90-х у наших рекламистов нарисовать оригинал-макет в Corel Draw 5 было супер мозгами, теперь стало процедурой. И так везде. Так что я бы привязывался к ценовым показателям, которые в сравнении с рынком все расставляют на свои места.

Понятно. Я не буду спорить по сути сформулированных вами (имхо, никак не следующие из слов АА) ИТ-ограничениях технопарку. С моей колокольни, переписывание матвыражений в программный код, пусть сложных - это детская проблема. Требует всего лишь аккуратности. Речь идет о прикладной метаматематике и все! -- программирование просто рядом валялось, не более.

Причем, даже в ремесле кодирования встречаются задачки посложней, чем эта. Например, один мой знакомый пишет ОС для сотовых 4 поколения. Там есть зубодробильная математика, но как раз это сделали многие. Но ОС сделать толком не могут, как раз, из-за специфических требований к реал-тайму. Вот это действительная ИТ проблема.

Я не хочу вдаваться в терминологический спор (например, валялось ли программирование рядом с computer science?), но т.к. на выходе мы имеем программный продукт (код), то и процесс его создания все-таки программирование (в данном случае - кодирование). Согласен, что инновации здесь сосредоточены именно в изобретении нового (или оптимизации существующего) алгоритма, а собственно процесс его кодирования инноваций не требует. Так ведь и построение диаграмм классов UML тоже процесс технический.