Сначала прочитал "парное" с ударением на второй слог))

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

Но подход, естественно интересный. С точки зрения экстремальных видов спорта.

обычно хотя бы одна опция присутствует)

можно провести опрос в формате "хотели бы вы...")

Надо больше народу собрать! Поставить экран большой, за клавиатуру посадить разработчика и петрофизика, а мышку отдать геологу и сейсмику. И пусть друг другу советуют ))

Поговорка "два геолога - три мнения" говорит в пользу отказа от "парного" моделирования, потому что с третьим мнением не согласится в итоге ни один из двух геологов. Хотя связка "один геолог + один разработчег" неизвестно сколько мнений могут породить.

А коллаборацию можно устроить и с более современными HID -устройствами, добавить туда перо для рисования седиментологу, ну и еще распознавание речи всем, чтоб сразу концепция протоколировалась :)

У меня эта же мысль в голове крутится.

• В контектсе "управлениями знаний" - в процессе такого парного моделирования (бок о бок) идет самый эффективный обмен знаниями если пара состоит из опытных специалистов. А также самое эффективное обычение в "полевых" условиях, если пара состоит из опытного и начинающего специалиста.
• Меньше ошибок, (одна голова хорошо а две лучше).
• При обсуждении проблем, всегда на порядок появлется больше идей как их решить
• По аналогии с программирование повышается "code sharing" - когда с моделью знаком не один а как минимум 2 специалистов, которые если что могут  занинить друг друга.
• Читаемость моделей тоже повышается - когда делаешь модель совместно с кем-то, но и объекты называешь так чтобы было понятно не только тебе.

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

PS. Написал и прочитал ссылку в википедии - все преимущества которые называюся для программирования, думаю что все подходит и к совместному моделирования.

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

И зарплату по полам. Тогда может начальство пойдет на такой шаг.

Работал по почти такой схеме.

Плюсы - реально работа движется быстрее, меньше отвлекаешься на вкотнтакте, петролеуминженерс и т.д.

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

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

Ну а ресурсы... в какой то момент все-таки наступает час другого проекта и работа опять развлетвляется. Лично у меня так было пару раз. Начинали вместе а через пару недель коллегу перекидывали на другой проект ибо жирно что бы двое работали в дубле. 

Потом сложно объяснить начальству кто что делал, где чья часть и тд.

В компаниях где один геолог и один гидродинамик это схема практически невозможна, потому что на плечи каждого ложится помоимо текущего проекта еще и "мелочи" предыдущих\следующих (карты выгрузить, контуры нанести, сделать красивые картинки или быстро прикинуть объемы).

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

helgibh пишет:

Наблюдал часть этой схемы недавно, только люди не менялись. И как я понял, даже в такой схеме толк есть - очень опытный человек смотрел на все немного "сверху", второй работал над деталями. ...

В этом случае "опытный специалист" как правило присваивает себе результаты работы "стажёра".

Было дело, еще в студенческие годы, когда я работал программистом, работали в паре с товарищем, не на постоянной основе, а при написании, критических участков, или скажем когда надо было быстро написать какую-нибудь софтину. Действительно, получалось быстрее. В нефтянке, как мне кажется, по выше упомянутой схеме, тоже можно иногда применять, "гуру и стажер".

volvlad пишет:

Было дело, еще в студенческие годы, когда я работал программистом, работали в паре с товарищем, не на постоянной основе, а при написании, критических участков, или скажем когда надо было быстро написать какую-нибудь софтину. Действительно, получалось быстрее. В нефтянке, как мне кажется, по выше упомянутой схеме, тоже можно иногда применять, "гуру и стажер".

ну в нефтянке наверное так и выходит. Старший периодически курирует работу младшего. Выглядит это что младший делает что-то неделю, в пятницу приходит старщий с "ну что там у тебя давай посмотрим". Смотрит, вставляет пистоны, исправляет, дает ЦУ на следующую неделю и возвращается обратно к своему мегапроекту.

Мне больще нравится вариант работать в дубле со спецом такого же уровня (либо чуть выше). Реально это работа вдвоем, эффективна и интересна. Жаль что часто бывает слишком жирно двух спецов держать на одном проекте...

Не обязательно же их постоянно держать на одном проекте, могут работать каждый над своим. Если надо что-то обдумать и быстро сделать, собрались, порботали полдня, день вместе и разбежались дальше по своим проектам... Кстати, идея, еще одного варианта, они оба дулают свои схожие, можно даже не слишком схожие, проекты. И прекрасно если даты начала проектов примерно одинаковые, этапы выполнения и сроки примерно одинаковые, тогда такие сессии парной работы позволят ускорить выполнение критичных частей, отстающий будет подтягиваться за более быстрым
Хмм... надо над этим поразмыслить на досуге)

да согласен идея интересная)))

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

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

Связка гуру-стажер почти всегда приводит к кнопконажимательству. Зеленый модельщик, начинает понимать что для чего нужно только на 2-3 год моделирования, когда все основные кнопки уже усвоены хорошо. Как правило, в этот момент его отпочковывают от гуру и пускают в свободное плавание (хотя конечно к гуру он продолжает бегать периодически). Согласен, что если так работать долгое время то мотивации это ни гуру ни стажеру не добавляет. Те опять же ИМХО спецы должны быть примерно одного уровня, со знанием конретного региона и умением быстро находить нужные данные в БД компании или у конретных коллег.

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