Междисциплинарная Алгоритм строительство с не являющимися разработчиками

Question

Да, я знаю, что название это громоздко ...

Что я имею в виду, чтобы сказать, как вы общаетесь с экспертом предметным, кто нуждается в теории кодированную и испытанную?

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

Как повысить уровень общения и понимания между дисциплинами? И не обязательно просто для погоды, других наук тоже.

Answer 1

Самый короткий ответ - Непрерывное привлечение клиентов.

Все симпатичные диаграммы UML, макеты crayola UI, объяснения к четырем годам и другие методы никогда не дадут полный опыт использования рабочего приложения. Сохранение потребителя в цикле допускает цикл обратной связи как для клиента, так и для клиента. Эта симбиотическая связь имеет наибольшее вероятность создания продукта, который будет им полезен.

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

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

Даже если вы считаете, что ваши коммуникативные/объяснительные навыки являются на высшем уровне, вам все равно придется учитывать ошибку в способе общения.

Answer 2

С большой осторожностью и терпением. Вы не можете принять понимание, поэтому используйте технику, например, прототипирование или изображения для общения.

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

Заказчику не нужно знать свой язык, поэтому не пытайтесь обучать метеоролога CS lingo. Вам нужно выучить его язык. Даже самое тривиальное требование должно быть проверено прототипом. Если они скажут: «Нам нужно увидеть карту США», тогда вам нужно нарисовать карту США и показать их и сказать «Это то, что вы хотите увидеть»? Затем он собирается сказать: «Но я не вижу реку Миссиссипи на этой карте», тогда вы говорите «но вы не просили рек». Затем вернитесь и снова рисуйте карту. и т. д.

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

Answer 3

«Самый короткий ответ - это непрерывное участие клиентов».

Я предлагаю вам сделать это с помощью определенных подходов.

1. Язык, на котором вы можете быстро развиваться. Мой выбор Python, ваш может быть другим. Например, Java - может быть невелика в вашем списке, потому что требуется некоторое время, чтобы запустить работу. С ++ может быть слишком много усилий для быстрого развития.

2. Постройте небольшие вещи быстро. Начните с чего-нибудь - чего угодно - чтобы начать разговор. Сборка, просмотр, расширение.

3. Формализовать результаты с помощью модульных тестов, которые позволяют вам реорганизовать как раньше, так и часто.

Как только у вас есть что-то твердое, вы можете рассмотреть возможность перезаписи на Java или C++ или что-то для повышения производительности.

Answer 4

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

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

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

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

Этот метод работал очень хорошо для меня.

Answer 5

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

Answer 6

Я имел хороший успех с материалом Weiger в: http://www.processimpact.com/reqs_book/reqs_book.shtml

Start, делая видение и сферу применения документа: http://www.processimpact.com/pubs.shtml#requirements

Answer 7

Вы всегда должны спросить себя: «Как бы я это объяснить, что ол «бабушка на рынке?». Когда у вас есть это, вы можете поговорить и объяснить свои методы и процедуры практически всем. Если у них есть дополнительные знания, еще лучше.

Если вы не можете, то, возможно, вы должны спросить себя: «Может быть, проблема не на их стороне». Даже если это на их стороне, нет никакого вреда в попытке понять их точку зрения.

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

Answer 8

Действуйте как программист и используйте подход «с самым низким сцеплением».

Для случая метеоролога я немного знаю поле, а метеорологи и программисты с трудом общаются по фактическому коду. Эти программисты знают достаточно математики, чтобы внедрять любые уравнения, которые хотят метеорологи, а затем метеорологи достаточно выкапывают, чтобы использовать программное обеспечение.

Я мог бы также связать торговец против квантов против программистов случае, что еще хуже ...

Они не обсуждают метеорологию, и они не обсуждают код.

Answer 9

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

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

Есть люди, работающие над этим с обоих концов - пытаясь научить ученых основам ответственной разработки программного обеспечения (например, Software Carpentry) Грега Уилсона и обучению людей, занимающихся разработкой программного обеспечения, о крупномасштабной вычислительной науке (например, Стив Истбрук very interesting blog, из которых this особенно уместен). Почему все так же примитивно, как и на этом фронте, я понятия не имею. Оба имеют ссылки на соответствующих коллег по своим блогам.

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

@vfilby имеет правильную идею - непрерывное участие клиента - но это немного больше. Для этого, чтобы работать, вы собираетесь получить положить в петлю науки - вместо цикла составляет ученого → теории → теста → интерпретации → теории обновления, это будет ученым → теории → вы код → вы и ученый как интерпретировать ваши собственные части → Теория обновления и/или реализация. Ученые домена не будут знать, как вы, как наилучшим образом реализовать то, что они хотят, или как распутать результаты своей модели по результатам вашей реализации модели; с другой стороны, они будут понимать последствия модели намного лучше, чем вы, и как обновить теорию.

Это тяжелый баланс, чтобы получить право. Для того, чтобы он работал, обе стороны должны (а) уважать другую область знаний, (б) изучать немного этой другой области и (в) инвестировать в проект в целом. Эти виды междисциплинарных проектов ломаются чаще, чем они преуспевают, но они жизненно важны. I действительно Желаю, чтобы у меня были легкие, гарантированные к работе советы для вас.