Некоторые подсказки для более эффективного обмена информацией через электронную доску?

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

Как я могу стать более эффективным при выполнении этого? Я ищу подсказки относительно стандартных символов и коннекторов, чтобы использовать, некоторые стандартные способы организовать и категоризировать информацию (например, плавать маршруты), и т.д.

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

20
задан 2 revs 23 February 2010 в 18:45
поделиться

11 ответов

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

  • Используйте минимальный набор символов : прямоугольники, стрелки, круги и линии помогут вам далеко. Предпочитайте простые вещи более продвинутым техникам моделирования - все понимают прямоугольники и стрелки.
  • Думайте вслух, рисуя , чтобы помочь аудитории понять, что вы рисуете.
  • Общайтесь со своей аудиторией. Белая доска - это не одностороннее общение. Если вы не уверены, дошло ли до вас сообщение или рисунок, просто спросите.
  • Когда аудитория достаточно мала, поставьте людей ближе к доске , а сделайте легкодоступными ручки, чтобы люди могли рисовать вместе с вами . Это позволяет улучшить визуальное общение и еще более эффективно провести сеанс «белой доски».
  • Найдите достаточно времени, чтобы писать и рисовать «аккуратно», но предпочитайте стабильную скорость общения идеальному письму от руки . Это трудный компромисс, требующий некоторой практики, и практика, сохраняя понятность вашего письма и рисования, увеличит вашу скорость письма и рисования.
23
ответ дан 29 November 2019 в 22:47
поделиться

Помедленнее.

Нет ничего плохого в том, чтобы писать аккуратно.

12
ответ дан 29 November 2019 в 22:47
поделиться

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

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

11
ответ дан 29 November 2019 в 22:47
поделиться

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

9
ответ дан 29 November 2019 в 22:47
поделиться

Я часто пишу в Post It Notes, потому что вы можете легко перемещать их при обсуждении отношений между объектами. Кроме того, разные цвета Post Its могут передавать смысл.

Ниже приведен пример:

альтернативный текст http://www.matterco.com/wp-content/themes/matter/images/art057.jpg

2
ответ дан 29 November 2019 в 22:47
поделиться
  • Попытка вместить слишком много в {{1} } одна диаграмма может запутать.
    • Попытайтесь визуализировать детализацию идей, где вы можете рисовать и соединять более крупные модули. Может быть, сделайте снимок этой диаграммы, чтобы сохранить свою идею на доске и получить обратную связь.
    • Сосредоточьтесь на меньших модулях и примените детализацию, если применимо.

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

Надеюсь, это поможет.

ура

2
ответ дан 29 November 2019 в 22:47
поделиться

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

0
ответ дан 29 November 2019 в 22:47
поделиться

Вы знакомы с диаграммами ER? Если вы моделируете базу данных, диаграммы ER довольно универсальны для большинства людей.

1
ответ дан 29 November 2019 в 22:47
поделиться

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

1
ответ дан 29 November 2019 в 22:47
поделиться

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

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

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

Прочтите несколько блок-схем и создайте одну для сложного потока, над которым вы работаете. Они чертовски круты в анализе того, что происходит, и в передаче чего-либо, кроме тривиального вызова / возврата одного метода. Я не знал об этом примерно 1/3 своей карьеры и был просто ошеломлен, когда в первый раз кто-то выбросил один на доску (это было после того, как я все узнал, но, конечно, каждый год я узнаю больше, а затем решаю Я НАКОНЕЦ все знаю).

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

Изменить:

Эта страница представляет собой хорошее введение в диаграммы последовательностей с множеством отличных примеров.

1
ответ дан 29 November 2019 в 22:47
поделиться

Диаграммы архитектуры «должны» быть в UML.

Однако.

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

Однако существуют некоторые стереотипы классификаторов, которые очень и очень помогают, позволяя сводной диаграмме «высокого уровня» охватить ряд оснований.

«Стереотипы классов объектов» (см. http://doc.sumy.ua/prog/umld/AD970806.PDF ) для классов Control, Boundary и Entity на вес золота. Добавление этих стереотипов в диаграмму классов - полезный, быстрый и формальный способ определить, как класс (или пакет) вписывается в целое.

0
ответ дан 29 November 2019 в 22:47
поделиться
Другие вопросы по тегам:

Похожие вопросы: