Если вам нужна комната для совещаний, забронируйте ее с дополнительными полчаса до и после встречи, чтобы учесть проблемы с подключением / оборудованием, а также открыть обсуждение после демонстрации. Обязательно бронируйте комнату отдельно от фактической встречи, чтобы она была видна только организатору встречи. Используйте это дополнительное время с умом; вы являетесь техническим экспертом организации. У вас не должно быть технических проблем (перед заинтересованными сторонами).
Если это онлайн-собрание, убедитесь, что URL-адрес собрания работает и что нет проблем с подключением. Желательно использовать проверенное решение, к которому люди привыкли. Эксперименты не очень популярны на больших собраниях. Попробуйте смешать это; провести физическую встречу, к которой также можно присоединиться удаленно.
Избегайте отвлекающих факторов
Точно, выключите свой почтовый клиент. Ваш корпоративный мессенджер. Убедитесь, что Slack закрыт. На самом деле выйдите из Скайпа, а не просто спрячьте его в трей. Закройте все 5 запущенных экземпляров Chrome с 20 открытыми вкладками. Закройте все ненужные программы на вашем компьютере. Если у вас есть режим «Не беспокоить», включите его на своем устройстве и телефоне. Еще лучше, если у вас есть специальная машина для демонстрационных целей.
Все эти отвлекающие факторы снижают ценность презентации, и любое прерывание убьет ваш поток. Кроме того, учитывая закон Мерфи, вы можете поспорить, что это будет время, когда в фоновом режиме произойдет какой-то случайный сбой, который сломает демонстрацию. Или кто-то начинает /giphy-войну на слабом канале.
Инструменты разработчика
Нет ничего, что могло бы испортить хорошую демонстрацию, кроме как отображение всех внутренностей вашего кода. Приходится открывать редактор кода, чтобы поэкспериментировать с переменными, чтобы что-то продемонстрировать. Или демонстрация веб-программного обеспечения с открытыми инструментами разработчика F12. По сути, это раскрывает все внутренности прекрасного программного обеспечения, которое должно быть выставлено на обозрение.
Отбросьте жаргон!
По возможности избегайте использования технических терминов. Нам не нужно объяснять, какая версия у фреймворка. Что общая библиотека была обновлена. Что вы начали использовать новую библиотеку. Подробный подход, который вы использовали, и то, как вам нужно было сделать то или иное, чтобы достичь желаемого результата. Почему вы выбрали одну библиотеку вместо другой.
Сосредоточьтесь исключительно на конечном значении изменений, которые вносятся при выполнении любого из вышеупомянутых действий. Если мы сделали рефакторинг/технические улучшения, которые на самом деле не приносят никакой пользы, то даже не упоминайте об этом. Это не важно. Это не то, что мы слышим, когда финансовый директор получает новые отчеты Excel с потрясающими формулами.
Некоторые примеры технического жаргона, который убивает обсуждение, по сравнению с тем, чтобы сосредоточиться на потребностях пользователей, что облегчает и способствует лучшему обсуждению.
Что можно и чего нельзя делать
Нельзя: используйте внутренние кодовые названия продуктов: Maverick, Tomahawk, Banana. Обращайтесь к проектам так, как они есть или что они представляют.
Что нужно делать:система маркетинга, менеджер кампании, бэк-офис отдела продаж и т. д.
Несмотря на то, что заинтересованные стороны/пользователи могут узнать кодовые имена, в этом нет необходимости. Им не нужно еще одно модное слово, чтобы споткнуться. Либо мы учим их вредным привычкам, либо они перестают воспринимать нас всерьез.
Нельзя: мы обновили систему ‹name cms here› до версии 3.42.3.
Что нужно сделать. Нам нужно обновить базовую платформу из-за обновлений безопасности. Это не должно повлиять на вас, но сообщите нам, если у вас возникнут какие-либо проблемы.
Предупреждает заинтересованные стороны о том, что техническое обслуживание выполнено и могут возникнуть проблемы
Не делайте этого. Как вы можете видеть здесь (открывая инструменты разработчика F12), когда я нажимаю кнопку, на эту конечную точку отправляется запрос ajax, и он возвращает успех = true/false.
Выполнить: когда я нажимаю эту кнопку, вы видите счетчик и подтверждение, когда мы размещаем заказ. Если есть какие-то технические трудности, мы показываем этот удобный для человека текст, объясняя ситуацию как можно лучше.
Предлагает простое и ожидаемое поведение, ожидаемое заинтересованными сторонами. Кроме того, команде разработчиков будет проще сосредоточиться на создании замечательных приложений, облегчающих жизнь пользователям.
Нельзя. Мы обновили внутренний справочный проект «черный дрозд» до версии 3, которая содержит подробные темы, которыми мы можем поделиться для наших проектов.
Что нужно сделать. Мы обновили внешний вид наших пользовательских интерфейсов, чтобы они соответствовали нашим универсальным рекомендациям по продуктам. Вы должны чувствовать себя как дома при переключении между нашими продуктами. Это должно значительно упростить чтение контента для наших пользователей. Он также должен быть намного более интуитивным.
Может вызвать обсуждение общего пользовательского интерфейса. Или, может быть, люди могли бы легко распознать ценность и принять это.
Нельзя: мы исправили ошибку, из-за которой возникали условия гонки, когда 4/5 пользователей пытались обновить один и тот же торговый документ.
Что делать. Мы обнаружили проблемы, когда несколько пользователей пытались обновить один и тот же документ, поэтому мы ограничили возможность редактирования одним пользователем за раз.
Может возникнуть дискуссия о том, почему больше пользователей не могут редактировать разные части заказа на продажу одновременно.. у них разные профессии и опыт =› новое изменение, которое лучше соответствует потребностям
Это лишь несколько примеров, но, сосредоточив внимание на диалоге в «Можно» и меньше на «Нельзя», мы значительно повышаем ценность для всех. Всегда будут некоторые проблемы, когда вам действительно нужно немного покопаться в технологии, но это должно быть исключением из правила.
Убедитесь, что там нужные люди
Это необходимо для отличной демонстрации. Нет ничего хуже, чем провести отличную демонстрацию / презентацию с неправильными людьми! Не бойтесь приглашать больше людей, чем необходимо. Если вы это сделаете, то заинтересованные стороны, которых было бы неплохо иметь там, но которые не уверены, могут легче убедиться в важности презентаций. Представьте демонстрацию как важную презентацию для всего бизнеса, чтобы люди почувствовали необходимость присутствовать и участвовать.
Сделав это и предоставив демонстрацию, заинтересованные стороны увидят больше ценности и захотят присутствовать на следующей. Это становится самоисполняющимся пророчеством. Если возможно, запишите его и разошлите всем, чтобы те, кто не смог, могли наверстать упущенное.
Говорите «бизнес»
Используйте те же термины, которые используют заинтересованные стороны и пользователи. Это значительно улучшает общение, показывая, что вы заботитесь об их домене, что, в свою очередь, отразится на программном обеспечении. Это также позволяет больше обсуждать, так как они понимают, что представлено. Это работает в обе стороны и укрепляет доверие, а не усиливает разрыв между «ИТ» и «бизнесом».
Программное обеспечение, которое мы создаем, призвано облегчить их повседневную жизнь, поэтому общее понимание имеет первостепенное значение.
Перейти к сути
Совещания часто являются пустой тратой времени, в основном из-за отсутствия четкой повестки дня или конечной цели. Конечная цель демо / презентаций — продемонстрировать вашу работу, получить ценные отзывы и дать заинтересованным сторонам хорошее представление о том, как идут дела. Это также часто вызывает новые расстановки приоритетов и позволяет им «почувствовать» программное обеспечение.
Помня об этой конечной цели, хорошо подготовьтесь к демонстрации. Убедитесь, что вы не пренебрегаете крайними случаями и не тратите время на обсуждение деталей того, что не имеет значения. Доберитесь до сути, хорошо изложите ее и создайте хорошие отношения с бизнесом.
Не мешайте диалогу
Крайне важно иметь открытую арену для обсуждения, поэтому старайтесь разрешать обсуждение, комментарии и вопросы во время демонстрации. Это приведет к более ценной информации и позволит еще больше задействовать все стороны.
Иногда диалог может перерасти в обвинения или удивление, что фичи были реализованы специфическим образом. Постарайтесь быть скромным и подойти к этому с уважением и пониманием. Иногда мы слишком упрощаем, и демонстрация — лучшее место, где можно собрать заинтересованные стороны для выявления потенциальной проблемы. Это также отличное место для выявления проблем, лежащих в основе бизнес-проблем. Где мы изо всех сил пытаемся точно воссоздать программное обеспечение, потому что правила слишком сложны, что может означать, что к бизнес-проблеме можно подойти совершенно по-другому.
Иногда разработчиков значительно больше, чем заинтересованных лиц. Иногда это не устраивает и создает атмосферу незащищенности для заинтересованных сторон и, таким образом, препятствует диалогу. Если это так, попробуйте, чтобы несколько разработчиков присутствовали и чередовались между командой.
Доведи до блеска!
Это сложный, а также, вероятно, самый важный, поскольку он требует всех остальных. Презентации не должны быть скучными. Покажите, что вы гордитесь тем, чего достигли. Имейте светлый тон и не бойтесь улыбаться. Ничто так не убивает отличный продукт (демонстрацию), как отсутствие энтузиазма в отношении того, что представляется, и адаптации его к аудитории.
Есть еще одно преимущество в привлечении некоторой зрелищности; а именно, что это, вероятно, позволит участникам расслабиться и быть более открытыми для обратной связи. Так что выигрывают все!
Выход за рамки демонстрации
Демонстрации продуктов — отличное место, где собираются заинтересованные стороны и пользователи из разных компаний, чтобы обсудить программное обеспечение, которое затрагивает их повседневную жизнь. Это возможность создать атмосферу доверия и понимания, которая сохраняется еще долгое время после завершения презентации. Потратив время на развитие этой арены, выиграют все участники.
Как вы используете демонстрацию продукта, чтобы лучше сблизить вас и ваших заинтересованных лиц и улучшить ваши продукты?
Мне бы хотелось услышать ваше мнение по этому поводу. Не стесняйтесь оставить комментарий или связаться со мной в Твиттере.
Запись Презентация программного обеспечения пользователям, не являющимся техническими специалистами — 8 способов сделать демонстрацию вашего продукта яркой впервые появилась на странице Программирование с эмпатией.
