сеньорчикОткрыть в Telegram
← вся теориятеория к собесу · Стейкхолдеры

Презентация решения

Презентация решения

Два доклада об одном проекте. Первый: «мы сделали ролевую модель, справочник контрагентов и выгрузку в бухгалтерию». Второй: «на ручной сверке мы теряем 1,2 миллиона в год, вот из чего складывается эта сумма, и вот что её убирает». Утверждают второй, хотя проект абсолютно тот же.

Стержень: начинать с проблемы и её цены, подстраивать акценты под аудиторию, честно обращаться с рисками и с собственным незнанием.

// Формулировки: «как построишь доклад руководству?», «не знаешь ответа на вопрос», «как подать риск?»

От проблемы и её цены

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

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

// Порядок изложения меняет решение сильнее, чем содержание. Один и тот же проект, поданный от списка функций и от цены проблемы, получает разные ответы на одном и том же комитете.

Разные аудитории, один смысл

Финансиста интересуют затраты и срок возврата. Руководителя отдела - как изменится работа его людей и не станет ли её больше. Архитектора - влияние на систему и техдолг. Безопасность - какие новые риски вы приносите.

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

// Практический приём: перед докладом выпиши по одной фразе на каждого ключевого участника - что он должен унести с собой. Если для кого-то фраза не пишется, вы не знаете, зачем он в зале, и это тоже полезный вывод.

Прототип вместо текста

Документ с требованиями читают по диагонали и соглашаются - на бумаге всё выглядит разумно. Тот же человек, увидев экран, через двадцать секунд говорит: «а где поле с номером договора?» и «почему сумма без НДС?».

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

// Поэтому на защите решения макет ценнее слайда с формулировками, даже кривой и нарисованный за час. Отдельный бонус: разговор идёт про предмет, а не про формулировки в документе.

Риски, вопросы и незнание

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

Вопрос из зала означает, что человека волнует именно это и до ответа он не услышит ничего. Отвечать коротко и по существу, потом возвращаться в канву. «Об этом будет через три слайда» читается как уклонение, даже когда это правда.

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

Как отвечать: «На защите задали вопрос, ответа на который ты не знаешь»

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

Кандидат объясняет цену выдуманного ответа через доверие ко всему докладу и добавляет случай, когда вопрос блокирует решение.

На чём валятся

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

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

  1. #ana_sh_presentation1 / 5
    Зачем показывать прототип, если требования уже описаны текстом?
    A)Прототип заменяет собой документацию
    B)Прототип быстрее согласовать формально
    C)На макете расхождения видны сразу
    D)Прототип позволяет оценить трудозатраты
    показать ответ и разбор
    +C)На макете расхождения видны сразу

    // разбор: Текст требований читают по диагонали и соглашаются, а увидев экран, немедленно говорят «а где поле с договором?». Несоответствие ожиданиям обнаруживается за минуты и до начала разработки. Это самый дешёвый известный способ проверить понимание.

  2. #ana_sh_presentation2 / 5
    Как правильно подать риск на защите проекта?
    A)Назвать риск вместе с планом реагирования
    B)Не упоминать, чтобы не спугнуть решение
    C)Перечислить все возможные риски подряд
    D)Упомянуть риски в конце одной фразой
    показать ответ и разбор
    +A)Назвать риск вместе с планом реагирования

    // разбор: Умолчание о риске выглядит как некомпетентность, когда он реализуется. Названный риск с оценкой вероятности и понятным планом действий, наоборот, добавляет доверия: видно, что автор думал наперёд. Перечислять стоит существенные, а не весь список подряд.

  3. #ana_sh_presentation3 / 5
    Руководитель прерывает презентацию вопросом из конца доклада. Что делать?
    A)Попросить дослушать до нужного слайда
    B)Ответить сразу и вернуться к структуре
    C)Перейти сразу к финальным выводам
    D)Отложить ответ до конца выступления
    показать ответ и разбор
    +B)Ответить сразу и вернуться к структуре

    // разбор: Вопрос показывает, что человека волнует прямо сейчас, и до ответа он не воспримет остальное. Отвечать надо коротко и по существу, а потом вернуться в канву. Отсылка к будущему слайду читается как уклонение и почти всегда портит контакт.

  4. #ana_sh_presentation4 / 5
    Что делать, если на защите звучит вопрос, ответа на который вы не знаете?
    A)Дать наиболее правдоподобное предположение
    B)Перевести вопрос к другому участнику
    C)Сказать, что уточните, и назвать срок
    D)Уйти от ответа общей формулировкой
    показать ответ и разбор
    +C)Сказать, что уточните, и назвать срок

    // разбор: Придуманный на ходу ответ живёт до первой проверки, а потом обесценивает и остальные ваши утверждения. Честное «не знаю, уточню к завтрашнему дню» стоит дёшево и работает на доверие — при условии, что вы действительно вернётесь с ответом в названный срок.

  5. #ana_sh_presentation5 / 5
    Решение приняли на встрече устно. Что сделает аналитик после неё?
    A)Ничего: решение уже принято всеми
    B)Разошлёт запись решения и его причину
    C)Внесёт изменения в требования молча
    D)Дождётся официального протокола от секретаря
    показать ответ и разбор
    +B)Разошлёт запись решения и его причину

    // разбор: Через месяц участники будут помнить встречу по-разному, а половина заинтересованных на ней не присутствовала. Короткая рассылка с формулировкой решения, причиной и следующими шагами закрывает оба вопроса и даёт возможность возразить сразу, а не на приёмке.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.