Здравствуйте, GPFault, Вы писали:
СШ>>Это как крупные игрушки создают: один пишет музыку, другой графику, третий движок. И втроём они создадут игрушку за меньшее количество человеко-часов, чем один человек.
GPF>Угу... один программист пишет музыку, другой рисует спрайты. Игра обречена на "успех".
GPF>И как таким чудесным образом мы избежим клонирования? Человек который написал весь код не сможет купить графику и музыку?
в игре главное далеко не код и, арт или музыка.
СШ>>Брукс в играх и в шароваре отдыхает.
GPF>Брукс разбирается в управлении софтверными проектами. Если Вы считаете, что написание крупной игрушки или серъезной шаровары сильно отличается от того, что говорит Брукс, я бы порекомендовал Вам, Слава, пойти поработать на дядю понабраться опыта управления серъезными проектами.
написание игрушки кардинально отличается от написания любой программы, т.к. техническая реализация игры в виде програмного кода это очень малая ее часть.
... << RSDN@Home 1.1.4 stable rev. 510>>
30.08.05 01:03: Ветка выделена из темы Подумалось...
GPF>>Брукс разбирается в управлении софтверными проектами. Если Вы считаете, что написание крупной игрушки или серъезной шаровары сильно отличается от того, что говорит Брукс, я бы порекомендовал Вам, Слава, пойти поработать на дядю понабраться опыта управления серъезными проектами.
Y>написание игрушки кардинально отличается от написания любой программы, т.к. техническая реализация игры в виде програмного кода это очень малая ее часть.
Ой-ой-ой.... обидели профессионального игродела Написание игрушки, как и постройка Боинга, слабо в чем отличаются с точки зрения управления проектом. И там и там есть задачи зависимые, независимые. Везде есть идея, план, реализация. Везде есть контроль качества. Везде есть исполнители и рукамиводители, а также все проблемы связанные с человеческим фактором.
GPF>>>Брукс разбирается в управлении софтверными проектами. Если Вы считаете, что написание крупной игрушки или серъезной шаровары сильно отличается от того, что говорит Брукс, я бы порекомендовал Вам, Слава, пойти поработать на дядю понабраться опыта управления серъезными проектами.
Y>>написание игрушки кардинально отличается от написания любой программы, т.к. техническая реализация игры в виде програмного кода это очень малая ее часть.
GPF>Ой-ой-ой.... обидели профессионального игродела
сарказм здесь неуместен
GPF>Написание игрушки, как и постройка Боинга, слабо в чем отличаются с точки зрения управления проектом. И там и там есть задачи зависимые, независимые. Везде есть идея, план, реализация. Везде есть контроль качества. Везде есть исполнители и рукамиводители, а также все проблемы связанные с человеческим фактором.
в разработке Боинга и написания софта общего больше чем в написании софта и игры. а все потому что разработка игры — это скорее креативный процесс, чем технологический. при продаже программы и Боинга продается польза, которую можно получить при использовании этого товара, а при продаже игры продается фан, и для создания фана нет четких методологий разработки.
GPF>>Ой-ой-ой.... обидели профессионального игродела
Y>сарказм здесь неуместен
Почему? Игроделы это богема софтверного мира?
GPF>>Написание игрушки, как и постройка Боинга, слабо в чем отличаются с точки зрения управления проектом. И там и там есть задачи зависимые, независимые. Везде есть идея, план, реализация. Везде есть контроль качества. Везде есть исполнители и рукамиводители, а также все проблемы связанные с человеческим фактором.
Y>в разработке Боинга и написания софта общего больше чем в написании софта и игры. а все потому что разработка игры — это скорее креативный процесс, чем технологический. при продаже программы и Боинга продается польза, которую можно получить при использовании этого товара, а при продаже игры продается фан,
Ой ли... В этом мире не продается ничего кроме фана. Даже когда ты покупаешь садомазохисткие услуги, ты покупаешь фан. Задача втюхать софт, это задача сделать пользователя довольным, чтобы он ощущал себя всемогущим, иначе если он разочаровывается, то в 70% случаев ты получаешь refund.
Y>и для создания фана нет четких методологий разработки.
Ой ну как я в свое время (работая на дядю) утомился слышать от своих программистов: "Ну это же креативная работа. Мне сегодня не прет, а вот может быть за завтра я напишу недедльную норму". Но тогда я не мог воздействовать на процессы компании. Когда я начал работать самостоятельно, я пару раз тоже слышал от своих дизайнера и контент-врайтера о том какие они креативщики. Вопрос решился достаточно быстро. Резюмируя:
1) Программирование шаровары, по креативности не намного утупает играм.
2) Я тебе бесплатно раскрою секретную методологию разработки фана:
Пускай в твоей комманде будет фан, и твоя комманда начнет рефлецировать его на свою работу. И мого раз отраженный он усилится, и получится супер проект.
А вот о том как мотивировать фан в своей комманде уже рассказали многие. Почитай PeopleWare тот же — классика.
Здравствуйте, GPFault, Вы писали:
GPF>>>Ой-ой-ой.... обидели профессионального игродела
Y>>сарказм здесь неуместен
GPF>Почему? Игроделы это богема софтверного мира?
при чем здесь игроделы. тебе будет приятно, если я буду снисходительно отвечать на твои сообщения? а я ведь тоже могу.
GPF>>>Написание игрушки, как и постройка Боинга, слабо в чем отличаются с точки зрения управления проектом. И там и там есть задачи зависимые, независимые. Везде есть идея, план, реализация. Везде есть контроль качества. Везде есть исполнители и рукамиводители, а также все проблемы связанные с человеческим фактором.
Y>>в разработке Боинга и написания софта общего больше чем в написании софта и игры. а все потому что разработка игры — это скорее креативный процесс, чем технологический. при продаже программы и Боинга продается польза, которую можно получить при использовании этого товара, а при продаже игры продается фан,
GPF>Ой ли... В этом мире не продается ничего кроме фана. Даже когда ты покупаешь садомазохисткие услуги, ты покупаешь фан. Задача втюхать софт, это задача сделать пользователя довольным, чтобы он ощущал себя всемогущим, иначе если он разочаровывается, то в 70% случаев ты получаешь refund.
если ты не понимаешь какая разница между прикладным и развлекательным ПО, нам не о чем говорить.
Y>>и для создания фана нет четких методологий разработки.
GPF>Ой ну как я в свое время (работая на дядю) утомился слышать от своих программистов: "Ну это же креативная работа. Мне сегодня не прет, а вот может быть за завтра я напишу недедльную норму". Но тогда я не мог воздействовать на процессы компании. Когда я начал работать самостоятельно, я пару раз тоже слышал от своих дизайнера и контент-врайтера о том какие они креативщики. Вопрос решился достаточно быстро. Резюмируя:
GPF>1) Программирование шаровары, по креативности не намного утупает играм. GPF>2) Я тебе бесплатно раскрою секретную методологию разработки фана: GPF>Пускай в твоей комманде будет фан, и твоя комманда начнет рефлецировать его на свою работу. И мого раз отраженный он усилится, и получится супер проект. GPF>А вот о том как мотивировать фан в своей комманде уже рассказали многие. Почитай PeopleWare тот же — классика.
сколько ты сделал игр, и сколько из них успешно продаются?
GPF>>>>Ой-ой-ой.... обидели профессионального игродела
Y>>>сарказм здесь неуместен
GPF>>Почему? Игроделы это богема софтверного мира?
Y>при чем здесь игроделы. тебе будет приятно, если я буду снисходительно отвечать на твои сообщения? а я ведь тоже могу.
Вот только не надо двойных стандартов, yxiie. В твоих сообщениях уважения ни на бит нету. Так что go ahead — снисходительствуй....
Y>если ты не понимаешь какая разница между прикладным и развлекательным ПО, нам не о чем говорить.
Аргументы у тебя железные. Ну раз ты не понимаешь, что общего между прикладным и развлекательным ПО, то предлагаю свернуть дискуссию.
GPF>>1) Программирование шаровары, по креативности не намного утупает играм. GPF>>2) Я тебе бесплатно раскрою секретную методологию разработки фана: GPF>>Пускай в твоей комманде будет фан, и твоя комманда начнет рефлецировать его на свою работу. И мого раз отраженный он усилится, и получится супер проект. GPF>>А вот о том как мотивировать фан в своей комманде уже рассказали многие. Почитай PeopleWare тот же — классика.
Y>сколько ты сделал игр, и сколько из них успешно продаются?
Здравствуйте, GPFault, Вы писали:
GPF>>>1) Программирование шаровары, по креативности не намного утупает играм. GPF>>>2) Я тебе бесплатно раскрою секретную методологию разработки фана: GPF>>>Пускай в твоей комманде будет фан, и твоя комманда начнет рефлецировать его на свою работу. И мого раз отраженный он усилится, и получится супер проект. GPF>>>А вот о том как мотивировать фан в своей комманде уже рассказали многие. Почитай PeopleWare тот же — классика.
Y>>сколько ты сделал игр, и сколько из них успешно продаются?
GPF>yxiie, ты жжешь.
ну а что мне сказать человеку, который не делал игр, но твердо уверен, что это чисто технический процесс? мой опыт говорит об обратном.
GPF>Давай письками мерятся?
GPF>>yxiie, ты жжешь.
Y>ну а что мне сказать человеку, который не делал игр, но твердо уверен, что это чисто технический процесс? мой опыт говорит об обратном.
yxiie, ты видел программистов которые не писали игры? я уверен, что у твой опыт в игростроение превосходит мой в разы, но...
фан создает game-designer. Фан создают художники и музыканты.
Я кого-то забыл?
Программист? О, да... я уже вижу:
— Ребята, посмотрите какой смешной A* алгоритм я сделал... они бегают сквозь стены.
Или может быть мэнеджер проекта?
— Ребята, Вы сейчас все усцытесь, но мы сорвали последний дедлайн.
Я никогда не делал игры профессионально, но если начнется такой цирк на работе — проект будет мертв!
GPF>>Давай письками мерятся?
Y>тоже мне интелегент нашелся
Здравствуйте, GPFault, Вы писали:
GPF>>>yxiie, ты жжешь.
Y>>ну а что мне сказать человеку, который не делал игр, но твердо уверен, что это чисто технический процесс? мой опыт говорит об обратном.
GPF>yxiie, ты видел программистов которые не писали игры? я уверен, что у твой опыт в игростроение превосходит мой в разы, но... GPF>фан создает game-designer. Фан создают художники и музыканты.
GPF>Я кого-то забыл?
GPF>Программист? О, да... я уже вижу:
GPF>- Ребята, посмотрите какой смешной A* алгоритм я сделал... они бегают сквозь стены.
GPF>Или может быть мэнеджер проекта?
GPF>- Ребята, Вы сейчас все усцытесь, но мы сорвали последний дедлайн.
GPF>Я никогда не делал игры профессионально, но если начнется такой цирк на работе — проект будет мертв!
не пойму, что ты хочешь сказать? программирование это всего лишь часть разработки игры. если программу можно описать, выделить ф-ции, фичи, спроектировать, сделать по проектной документации и получить именно то что хотели, то в игре такое не получится. в игровой индустрии никогда конечная игра не является такой, какой она описана в первоначальном дизайн документе, и менеджмент игровых проектов тоже очень отличается от менеджмента разработки, как более непредсказуемый процесс. я этой темой в свое время очень интересовался, т.к. думал кандидатскую писать на тему менеджмента игровых проектов, а тут вдруг появляется GPFault, никогда не писавший игры и говорит что это все одно и тоже. если бы разрабатывать игры можно было чисто по софтовых методологиях типа MSF, RUP, etc. то мы бы не наблюдали сплошь и рядом задержки игр и все бы выходило тогда, когда это было озвучено в персс-релизах. правда в том, что софтовые приемы и методологии разработки применяются в игровых проектах довольно ограничено, и все очень непросто, как может показаться не искушенному в этой теме человеку.
Здравствуйте, yxiie, Вы писали:
Y>не пойму, что ты хочешь сказать? программирование это всего лишь часть разработки игры. если программу можно описать, выделить ф-ции, фичи, спроектировать, сделать по проектной документации и получить именно то что хотели, то в игре такое не получится. в игровой индустрии никогда конечная игра не является такой, какой она описана в первоначальном дизайн документе.
Ты не поверишь, но у нас так же.
Проект не игровой
Замороженные с самого начала требования бывают только на лабах во время учебы.
В жизни этого практически никогда не бывает.
В общем давай, заканчивай с героизацией геймдева и спускайся на землю
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, yxiie, Вы писали:
Y>>не пойму, что ты хочешь сказать? программирование это всего лишь часть разработки игры. если программу можно описать, выделить ф-ции, фичи, спроектировать, сделать по проектной документации и получить именно то что хотели, то в игре такое не получится. в игровой индустрии никогда конечная игра не является такой, какой она описана в первоначальном дизайн документе.
B>Ты не поверишь, но у нас так же. B>Проект не игровой B>Замороженные с самого начала требования бывают только на лабах во время учебы. B>В жизни этого практически никогда не бывает. B>В общем давай, заканчивай с героизацией геймдева и спускайся на землю
да я в принципе не героизирую, но тут матерый GPFault начал авторитетно рассказывать что в геймдеве все легко делается по софтовым методологиям, а в Electronic Arts почему-то об этом не знают и поэтому у них авралы — норма . им нужно GPFault-а нанять, чтобы он оптипизировал им производственные процессы
кстати если в традиционном софтваре-девелопменте при серьезно поставленном процессе проектирования и документирования такое возможно (получить именно то что хотели), то в геймдеве это невозможно в принципе для более-менее нетривиальной игры, а самое главное, что никто вообще не может знать как это должо в результате выглядеть. у опытных продюсеров эти творческие потуги сделать то, что должно быть сделано, оказываются зачастую чем-то интересным, у неопытных — зачастую неинтересным
GPF>>Я никогда не делал игры профессионально, но если начнется такой цирк на работе — проект будет мертв!
Y>не пойму, что ты хочешь сказать?
см. нижее
Y>программирование это всего лишь часть разработки игры.
Скажем так, программирование это часть разработки проекта. Не важно игрового или нет.
Y>если программу можно описать, выделить ф-ции, фичи, спроектировать, сделать по проектной документации и получить именно то что хотели, то в игре такое не получится. в игровой индустрии никогда конечная игра не является такой, какой она описана в первоначальном дизайн документе,
Да наверное еще ни один проект не был закончен в том виде, в котором планировался. Опять не вижу игровой специфики.
Y>и менеджмент игровых проектов тоже очень отличается от менеджмента разработки, как более непредсказуемый процесс.
Вот это уже интереснее. А чем он более непредсказуем? (Мне правда интересно)
Y>я этой темой в свое время очень интересовался, т.к. думал кандидатскую писать на тему менеджмента игровых проектов, а тут вдруг появляется GPFault, никогда не писавший игры и говорит что это все одно и тоже. если бы разрабатывать игры можно было чисто по софтовых методологиях типа MSF, RUP, etc. то мы бы не наблюдали сплошь и рядом задержки игр и все бы выходило тогда, когда это было озвучено в персс-релизах.
Ну если бы MSF, RUP или какая другая методология гарантировала сдачу проекта в срок, то мир стал бы светлее и чище...
Y>правда в том, что софтовые приемы и методологии разработки применяются в игровых проектах довольно ограничено, и все очень непросто, как может показаться не искушенному в этой теме человеку.
yxiie, я очень уважаю тебя и твой бизнес. И не хочу навязывать свою точку зрения (тем более, что с тобой это не прокатило бы). Мне правда интересно управление игровыми проектами. Этот тот экспириенс, который я хотел бы, но не успел получить. Поможешь мне набить "Level Up"?
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, yxiie, Вы писали:
Y>>>не пойму, что ты хочешь сказать? программирование это всего лишь часть разработки игры. если программу можно описать, выделить ф-ции, фичи, спроектировать, сделать по проектной документации и получить именно то что хотели, то в игре такое не получится. в игровой индустрии никогда конечная игра не является такой, какой она описана в первоначальном дизайн документе.
B>>Ты не поверишь, но у нас так же. B>>Проект не игровой B>>Замороженные с самого начала требования бывают только на лабах во время учебы. B>>В жизни этого практически никогда не бывает. B>>В общем давай, заканчивай с героизацией геймдева и спускайся на землю
Y>да я в принципе не героизирую, но тут матерый GPFault начал авторитетно рассказывать что в геймдеве все легко делается по софтовым методологиям, а в Electronic Arts почему-то об этом не знают и поэтому у них авралы — норма . им нужно GPFault-а нанять, чтобы он оптипизировал им производственные процессы
Y>кстати если в традиционном софтваре-девелопменте при серьезно поставленном процессе проектирования и документирования такое возможно (получить именно то что хотели), то в геймдеве это невозможно в принципе для более-менее нетривиальной игры, а самое главное, что никто вообще не может знать как это должо в результате выглядеть. у опытных продюсеров эти творческие потуги сделать то, что должно быть сделано, оказываются зачастую чем-то интересным, у неопытных — зачастую неинтересным
Да, конечно же у геймдева есть свои особенности, но не только там.
Непредсказуемость появляется там, где сложно предсказать реакцию юзера на софт.
В геймдеве тоже можно получить именно то, что хотели и что будет на все 100% соответствовать спецификациям.
Но ведь конечная цель то не соответсвие спецификациям (это только один из пунктов общего процесса),
а удовлетворение юзера, который платит денежку.
Предсказать реакцию юзера сложно не только в геймдеве.
Но это не означает, что в геймдеве совсем не применимы общие принципы,
которые помогают навести порядок в хаосе.
Игрушки, к примеру, тестируют? Несомненно...
Баги в bugtrack системах регистрируют? Не вижу причин почему этого не делать при разработке игры...
Код пишут и документируют? Думаю так же как и в других областях.
Диаграмы состояний рисуют? Запросто. Ну и т.д...
В общем мне кажется, что разумно все же выделять то,
что присуще именно геймдеву, а все остальное доверить универсальным методологиям.
Здравствуйте, GPFault, Вы писали:
Y>>и менеджмент игровых проектов тоже очень отличается от менеджмента разработки, как более непредсказуемый процесс.
GPF>Вот это уже интереснее. А чем он более непредсказуем? (Мне правда интересно)
тем во что ты не веришь. вовлечены креативные процессы и должности, очень нестабильная и динамичная ситуация в индустрии (за срок разработки игры может выйти несколько поколений видеокарт), жесткие дедлайны — E3, рождество, и.т.д., все это а также множество других нюансов делают менеджмент таких проектом очень волатильным занятием и требуют совершенно другого — имхо гораздо более вероятносного и психологического подхода.
Y>>я этой темой в свое время очень интересовался, т.к. думал кандидатскую писать на тему менеджмента игровых проектов, а тут вдруг появляется GPFault, никогда не писавший игры и говорит что это все одно и тоже. если бы разрабатывать игры можно было чисто по софтовых методологиях типа MSF, RUP, etc. то мы бы не наблюдали сплошь и рядом задержки игр и все бы выходило тогда, когда это было озвучено в персс-релизах.
GPF>Ну если бы MSF, RUP или какая другая методология гарантировала сдачу проекта в срок, то мир стал бы светлее и чище...
про гарантии как раз никто и не говорит, но эти методологии упрощают разработку софта, в геймдеве все гораздо сложнее.
Y>>правда в том, что софтовые приемы и методологии разработки применяются в игровых проектах довольно ограничено, и все очень непросто, как может показаться не искушенному в этой теме человеку.
GPF>yxiie, я очень уважаю тебя и твой бизнес. И не хочу навязывать свою точку зрения (тем более, что с тобой это не прокатило бы). Мне правда интересно управление игровыми проектами. Этот тот экспириенс, который я хотел бы, но не успел получить. Поможешь мне набить "Level Up"?
каким образом, если ты упорно не хочешь слушать то, о чем я говорю и все отрицаешь?
B>Да, конечно же у геймдева есть свои особенности, но не только там. B>Непредсказуемость появляется там, где сложно предсказать реакцию юзера на софт. B>В геймдеве тоже можно получить именно то, что хотели и что будет на все 100% соответствовать спецификациям. B>Но ведь конечная цель то не соответсвие спецификациям (это только один из пунктов общего процесса), B>а удовлетворение юзера, который платит денежку. B>Предсказать реакцию юзера сложно не только в геймдеве. B>Но это не означает, что в геймдеве совсем не применимы общие принципы, B>которые помогают навести порядок в хаосе. B>Игрушки, к примеру, тестируют? Несомненно... B>Баги в bugtrack системах регистрируют? Не вижу причин почему этого не делать при разработке игры... B>Код пишут и документируют? Думаю так же как и в других областях. B>Диаграмы состояний рисуют? Запросто. Ну и т.д...
применимо конечно, я и не утверждал об обратном, просто не все в полной мере. я же еще в начале писал, что основные особенности — это вовлеченность креативных профессий — художников, дизайнеров в процесс разработки. таким образом игра настолько программа, насколько и, скажем, фильм.
B>В общем мне кажется, что разумно все же выделять то, B>что присуще именно геймдеву, а все остальное доверить универсальным методологиям.
а как ты выделишь это программирование, если оно идет паралельно со всем остальным? полностью отделив программирование мы потеряем гибкость. и я не имею ввиду тестирование или разработку каких-то отдельных элементов типа движка или общих библиотек. я имею ввиду непосредственно разработку самой *игры*
Здравствуйте, yxiie, Вы писали:
Y>применимо конечно, я и не утверждал об обратном, просто не все в полной мере. я же еще в начале писал, что основные особенности — это вовлеченность креативных профессий — художников, дизайнеров в процесс разработки. таким образом игра настолько программа, насколько и, скажем, фильм.
B>>В общем мне кажется, что разумно все же выделять то, B>>что присуще именно геймдеву, а все остальное доверить универсальным методологиям.
Y>а как ты выделишь это программирование, если оно идет паралельно со всем остальным? полностью отделив программирование мы потеряем гибкость. и я не имею ввиду тестирование или разработку каких-то отдельных элементов типа движка или общих библиотек. я имею ввиду непосредственно разработку самой *игры*
Что такое "разработка самой *игры*"?
Там что, нету программирования?
Если так, то что мы тут вообще обсуждаем?
Творческие муки художников на программистком форуме нет особого смысла обсуждать.
Ну а так, в условиях постоянно меняющихся требований при программировании помогают:
— адекватные модели и метамодели;
— дополнительные уровни абстакции;
— специализированные языки, заточенные на решение определенных задач.
— и т.д...
Ну наконец программеры могут предложить специализированный софт,
который помогают креативщикам в процессе разработки.
Да, программер не сможет сильно помочь художнику, когда он, грубо говоря, рисует.
Но подготовиться к тому, чтобы быстро реагировать
на всевозможные изменения — это одна из задач программиста.
Она присутствует практически везде.
Здравствуйте, yxiie, Вы писали:
Y>тем во что ты не веришь. вовлечены креативные процессы и должности, очень нестабильная и динамичная ситуация в индустрии (за срок разработки игры может выйти несколько поколений видеокарт), жесткие дедлайны — E3, рождество, и.т.д., все это а также множество других нюансов делают менеджмент таких проектом очень волатильным занятием и требуют совершенно другого — имхо гораздо более вероятносного и психологического подхода.
Ты у производителей тех же мобилок поинтересуйся как у них с теми же дедлайнами.
Слышал, что если продукт не успевает к рождеству, то его можно уже и не выпускать.
Опоздание на неделю может быть фатальным.
А скажем, сделать крутую мобилку для молодежи — это тот еще риск.
Труба должна выглядить круто (стильно и пр...) и иметь крутые же фичи.
B>Что такое "разработка самой *игры*"? B>Там что, нету программирования? B>Если так, то что мы тут вообще обсуждаем? B>Творческие муки художников на программистком форуме нет особого смысла обсуждать.
я имею ввиду программирование игрового процесса и контента, которое идет паралельно с гейм-дизайном, непрерывным тестированием, наполнением игры контентом.
Здравствуйте, yxiie, Вы писали:
GPF>>Ну если бы MSF, RUP или какая другая методология гарантировала сдачу проекта в срок, то мир стал бы светлее и чище...
Y>про гарантии как раз никто и не говорит, но эти методологии упрощают разработку софта, в геймдеве все гораздо сложнее.
Imho, эти технологии вполне применимы и в игроделании, и в упоминаемом тобою кинопроизводстве, а также во многих других областях человеческой деятельности. Поскольку их предметом является не конкретная методика написания кода, а взаимодействие в команде разработчиков. Кстати, в рамках встреч Kiev.NET UG Денисом Пасечником и Александром Ложечкиным был прочитан ряд интересных лекций по MSF 4.0. Не знаю, когда они будцт продолжены, однако желающие могут получать уведомления о планируемых лекциях на сайте http://kyiv.gotdotnet.ru/ .
. им нужно GPFault-а нанять, чтобы он оптипизировал им производственные процессы 
