Правила проведения предварительных созвонов-знакомств с докладчиком
Страница актуальна на 01.02.2022. Алла Аблова
Для того чтобы созвоны с докладчиком были максимально эффективны, мы выработали простые правила.
Договоритесь с докладчиком о времени созвона. Обязательно опубликуйте договорённость в Системе работы с докладчиками (http://conf.ontico.ru ) в карточке доклада, чтобы другие заинтересованные члены ПК могли к вам присоединиться.
Прогоны проводим в zoom (можно запросить готовую ссылку на zoom-встречу у координатора ПК) или в skype (здесь запись придётся делать вручную, инструкция). Прогон надо обязательно записать!
В процессе беседы надо записать как своё впечатление, так и рекомендации (или даже задачи), которые вы даёте докладчику - см. О чём спрашивать докладчика во время предварительного прогона;
Впечатление о докладчике надо сразу же опубликовать в карточке доклада в режиме "Только для членов ПК", тогда ПК сможет использовать ваш созвон при принятии решения о докладе;
Рекомендации для докладчика тоже надо опубликовать, но уже в режиме для всех. Тогда и докладчик будет их видеть, и вы или другой член ПК сможет проконтролировать выполнение рекомендаций.
Например, отзывы для ПК могут быть такими.
Примеры отзывов "Для ПК"
Для ПК: Доклад по контенту правда довольно слабый. Там основные мысли: нужна хорошая документация, нужно тестировать, нужно замерять производительность. Я пытаюсь склонить докладчика к следующему: рассказать не просто, что именно хочется иметь, но и откуда это взять. Инструменты для автогенерации тестов и рыбы кода по доке, инструменты, облегчающие версионирование, всё, что они у себя стали использовать.
Для ПК: Доклад мне показался достаточно целостным после внесенных правок. Посоветовала дополнить еще деталями (в том числе из списка ниже), но и сейчас уже неплохо и информативно с практической точки зрения. Видимо, тыканье оказалось действенным :)
Примеры рекомендаций для докладчика
По результатам созвона.
Запись разговора: https://www.youtube.com/watch?v=AbXkV1bVjjk
Соображения:
Хорошо, когда мы фокусируемся даже не на инструментах, а на задачах. Мне кажется, легче всего воспринимается доклад, если мы вначале демонстрируем людям задачу (или симптомы проблемы), и показываем, как её решать. Тогда нам последовательно нужно всё больше информации, и тут естественно всплывают инструменты, которые нам эту информацию дают.
После того, как инструмент уже введён в рассказ через одну-две фичи, можно поговорить и о том, что ещё с ним можно делать. Вообще легче слушать, когда вы говорите не о том, что в инструменте есть, а о том, какие задачи с его помощью можно решить (а что в нём есть, получается само собой в процессе рассказа о задаче).
Задачу по ходу дела можно усложнять, и когда нам требуется сделать что-то такое, чего текущий инструмент не даёт, уместно показывать, что это есть в следующем инструменте. Так и до WireShark'а дойдём. =)
Ещё рекомендация: скриншоты интерфейсов не должны быть первым, что видит зритель, поскольку в новом интерфейсе разбираться трудно. Я очень настоятельно рекомендую сначала словами, схемами или как-то ещё на концептуальном уровне рассказать людям, что мы хотим получить, а уже потом, если очень надо, показывать интерфейс инструмента и подсвечивать, где находится то, о чём мы в данный момент говорим.