Несколько советов для более эффективной доски?

Question

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

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

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

Answer 1

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

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

Answer 2

Замедление.

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Последнее, но не менее важное, оно также дает вам хорошее начало для начала, прежде чем переходить к диаграммам ER и другому моделированию.

Answer 6

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

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

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

ура

Answer 7

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

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

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

Answer 8

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

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

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

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

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

Edit:

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

Answer 9

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

Answer 10

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