Правила проведения предварительных созвонов-знакомств с докладчиком
Страница актуальна на декабрь 2025. Проверила @Mariam Kereyeva
Для того, чтобы созвон с докладчиком был максимально эффективным, мы выработали простые правила.
Договоритесь с докладчиком о времени созвона самостоятельно или с помощью Программного менеджера, добавьте событие в календарь.
Прогон надо обязательно записать! Спикеру будет полезно посмотреть запись, ПК может вернуться к ней, если будет необходимость во втором мнении.
В процессе беседы надо записать как своё впечатление, так и рекомендации (или даже задачи), которые вы даёте докладчику - см. О чём спрашивать докладчика во время предварительного прогона.
Впечатление о докладчике надо добавить в карточку доклада в Системе работы с докладчиками в режиме "Только для членов ПК".
Рекомендации для докладчика и ссылку на запись тоже надо опубликовать, но уже в режиме для всех. Тогда и докладчик будет их видеть, и вы или другой член ПК сможет проконтролировать выполнение рекомендаций.
Например, отзывы для ПК могут быть такими.
Примеры отзывов "Для ПК"
Для ПК: Доклад по контенту довольно слабый. Основные мысли: нужна хорошая документация, нужно тестировать, нужно замерять производительность. Я пытаюсь склонить докладчика к следующему: рассказать не просто, что именно хочется иметь, но и откуда это взять. Инструменты для автогенерации тестов и рыбы кода по доке, инструменты, облегчающие версионирование, всё, что они у себя стали использовать.
Для ПК: Доклад мне показался достаточно целостным после внесенных правок. Посоветовала дополнить еще деталями (в том числе из списка ниже), но и сейчас уже неплохо и информативно с практической точки зрения.
Примеры рекомендаций для докладчика
По результатам созвона.
Запись разговора: [ссылка]
Комментарий:
Хорошо, когда мы фокусируемся даже не на инструментах, а на задачах. Мне кажется, легче всего воспринимается доклад, если мы вначале демонстрируем людям задачу (или симптомы проблемы), и показываем, как её решать. Тогда нам последовательно нужно всё больше информации, и тут естественно всплывают инструменты, которые нам эту информацию дают.
После того, как инструмент уже введён в рассказ через одну-две фичи, можно поговорить и о том, что ещё с ним можно делать. Вообще легче слушать, когда вы говорите не о том, что в инструменте есть, а о том, какие задачи с его помощью можно решить (а что в нём есть, получается само собой в процессе рассказа о задаче).
Задачу по ходу дела можно усложнять, и когда нам требуется сделать что-то такое, чего текущий инструмент не даёт, уместно показывать, что это есть в следующем инструменте.
Ещё рекомендация: скриншоты интерфейсов не должны быть первым, что видит зритель, поскольку в новом интерфейсе разбираться трудно. Я очень настоятельно рекомендую сначала словами, схемами или как-то ещё на концептуальном уровне рассказать людям, что мы хотим получить, а уже потом, если очень надо, показывать интерфейс инструмента и подсвечивать, где находится то, о чём мы в данный момент говорим.