Парное моделирование

Последнее сообщение
AlNikS 878 13
Сен 12

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

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

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

fedos 86 10
Сен 12 #1

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

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

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

AlNikS 878 13
Сен 12 #2

А что, у нас все специалисты нервные некоммуникабельные неадекватные психопаты с манией величия? :)

fedos 86 10
Сен 12 #3

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

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

AlNikS 878 13
Сен 12 #4

Ну давайте опрос :) Функционала в блоге такого нет, так что велкам, пишите комменты.

EmptyEye13 102 14
Сен 12 #5

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

Гоша 1197 15
Сен 12 #6

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

Гоша 1197 15
Сен 12 #7

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

AlNikS 878 13
Сен 12 #8

Не, ну можно всех специалистов собрать, шнур в затылок и подключить к Матрице сразу, и пусть как кластер работают :)))

Давайте как-то ближе к делу :)

Antalik 1683 15
Сен 12 #9

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

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

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

 

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

AlNikS 878 13
Сен 12 #10

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

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

helgibh 64 9
Окт 12 #11

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

Kolos 208 13
Ноя 12 #12

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

AlNikS 878 13
Ноя 12 #13

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

Celebrity 1678 14
Ноя 12 #14

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

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

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

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

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

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

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

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

karakurt2 94 12
Ноя 12 #15

helgibh пишет:

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

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

AlNikS 878 13
Ноя 12 #16

karakurt2 пишет:

helgibh пишет:

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

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

Не стоит наболевшее выдавать за правило :)

volvlad 2245 15
Ноя 12 #17

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

Celebrity 1678 14
Ноя 12 #18

volvlad пишет:

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

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

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

volvlad 2245 15
Ноя 12 #19

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

Celebrity 1678 14
Ноя 12 #20

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

karakurt2 94 12
Ноя 12 #21

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

Celebrity 1678 14
Ноя 12 #22

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

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

I_am_Moonlight 97 7
Фев 16 #23

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

Go to top