Как обучать Заказчика: Часть 1

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

При этом стоит помнить, что есть как минимум 4 направления, в которых вам необходимо обучать Заказчика.

  • Технологии проекта
  • Промежуточные результаты работы
  • Оперативная отчетность
  • Конечный продукт

Чаще всего, мы обучаем наших Заказчиков только последнему «предмету» из вышеперечисленных. Обычно в составе нашей продукции идет какой-то пакет документов, мануалов и хелпов, который отражает то, как работает продукт. А вот боевой опыт (вместе со здравым смыслом) подсказывают, что нужно обучать Заказчика по всем направлениям. Это выгодно и позволит избежать многих неприятностей, когда вашу команду будут ассоциировать с поставщиком некачественных услуг. Обычно Заказчики так думают о командах, которые отдали им «магическую коробочку», которая работала. При этом они даже не объяснили что с ней дальше делать. Думаете только на «баше» встречаются люди, которые копируют ярлыки вместо фильмов и говорят, что на дискету влезло очень много HD фильмов :)?

Причем, когда я привожу пример из быта, то восприятие меняется:

Представьте себе, вы попросили специалистов установить вам домой котел для автономного отопления. Они пришли, за 2 дня все сделали (пусть даже очень хорошо и без скандалов) и ушли, перед уходом включив отопление (зима ведь на улице :)). Вам оставили в качестве «интерфейса» 1 кран, который регулирует температуру батарей дома. Вы были счастливы и всю зиму поддерживали комфортную температуру. Но неожиданно (!) пришла весна. И вам надо бы остановить отопление. Вы выкручиваете ручку на минимум, при этом удивляетесь тому, что батареи все равно теплые. А еще ваш друг сказал, что на лето необходимо сливать всю воду, а то батареи и котел быстро сгниют. Вот только тогда (перед угрозой поломки или перегрева) вы вспоминаете, что не спросили:

  • как эта система работает?
  • как необходимо обслуживать систему?
  • как и куда звонить в случае проблем?

И сразу после этого начинаете вспоминать нехорошими словами людей, которые сделали это. Рассказываете друзьям и соседям, что вас «кинули». И судорожно ищете контактные номера телефонов или хотя бы адрес. После чего они приходят, показывают Вам «как закрутить 2 крана и нажать 1 кнопку» и преспокойно уходят. Ваша проблема решена, но, как говорится в знаменитом одесском анекдоте, «осадочек остался».

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

Стоит заметить, что пример в общем случае касается только того, как пользоваться продуктом. Может быть, в результате вашей настойчивости вы и узнаете что-то из технологий. Но как же сделать так, чтобы все 4 направления обучения были задействованы? И зачем это делать?

Обучение технологиям

Что делать:

  1. В зависимости от технического уровня Заказчика расскажите ему о технологиях на простом языке. Пусть это будет 1-2-10 (сколько нужно часов) но именно на том уровне, на котором он понимает. Когда мне трудно объяснить, я представляю, что рассказываю о технологиях проекта своей маме. И это действует очень хорошо!
  2. Используйте диаграммы, схемы и другие визуальные образы. Это сильно облегчает восприятие информации и снижает вероятность искажения информации из-за наших неидеальных ораторских и менторских способностей. Да и «неродной» английский может препятствовать свободной коммуникации.
  3. Скиньте Заказчику несколько ссылок о технологиях проекта и их применении, при этом учитывая, что его технический уровень может быть не равен вашему. Это, кстати, позволит вам немного сократить время на обсуждение.

Почему обучение Заказчика технологиям может быть вам выгодно:

  • Когда вы рассказываете Заказчику о технологиях, на которых построен продукт, то вы помогаете ему лучше понимать вас в дальнейшем. Слова «транзакция, CSS, скрипт, сервис» станут для него значимыми. Он будет лучше понимать, как решения его бизнес-проблем превращаются в систему. Соответственно, у него больше шансов быстрее найти «отклонение от курса», а значит сделать продукт быстрее и дешевле.
  • Заказчик сможет лучше объяснять свои проблемы службе поддержки. А значит его проблема будет решена быстрее и нужными людьми. Например, если он знает, что такое «сайт не пингуется», то он не будет звонить вам среди ночи с криками «Сережа, <censored>, твой сайт упал!», а напишет такое сообщение хостеру. То есть вы уменьшаете количество потенциальных проблем и негативных отзывов.
  • Знание технологий позволяет Заказчику рекламировать ваши услуги! Да-да, если вы расскажете, насколько уникальным является ваше новое решение для iPhone, то он, вероятно, расскажет об этом друзьям и партнерам (конечно же он похвастается, он в это приложение вложил сумму эквивалентную стоимости нового Porsсhe). А это потенциальные клиенты для вас!

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

Продолжение следует…

Oct 28th, 2010
  1. akhlystov
    Nov 2nd, 2010 at 13:15 | #1

    А как объяснить заказчику зачем ему тратить время на изучение технологий? Ему же это не надо?

    • Nov 2nd, 2010 at 13:54 | #2

      to akhlystov on

      А как объяснить заказчику зачем ему тратить время на изучение технологий? Ему же это не надо?

      В общем случае, конечно, вы не должны его заставлять. Искусство как раз состоит в том, чтобы сделать это ЕГО (заказчика) желанием. Для этого нужно перечислить несколько преимуществ, которые он получит в результате изучения технологий. Опять же мы говорим об изучении на базовом уровне, а не на уровне профи.

      Возвращаясь к преимуществам. Мне кажется, что вы были не очень внимательны в прочтении. Как минимум две из трех указанных выше выгод принесут пользу Заказчику:
      1. Он будет лучше понимать, как решения его бизнес-проблем превращаются в систему. Соответственно, у него больше шансов быстрее найти «отклонение от курса», а значит сделать продукт быстрее и дешевле.
      2. Заказчик сможет лучше объяснять свои проблемы службе поддержки.
      ++++
      3. Он сможет лучше рассказать своим пользователям, как это все работает.
      4. Он будет все время держать вас “тонусе”, если вы ошибетесь попытаясь “overestimate” данный проект (вот не знаю, будет ли этот довод в вашу пользу, но ему он точно понравиться).
      5. Если дело касается железа (серверов, устройств), то знание технологий поможет Заказчику сделать более оптимальный выбор.
      6….

      Кстати, по поводу пункта 5. Я знаю одного Заказчика, который вкинул 200К денег в то, чтобы заказать сервера, которые в итоге “не совсем подошли”. В общем, он мог бы сэкономить где-то 80К. Хороший стимул для того, чтобы поучиться? :)

      • akhlystov
        Nov 2nd, 2010 at 19:52 | #3

        Да я читал конечно статью, я извиняюсь имел ввиду что не совсем их воспринимаю.

        Давая базу по технологиям в течении небольшого времени по-моему сложно надеятся что она может быть использована грамотно.

        Я понимаю Сергей, что у вас есть успешный опыт такого рода действий.

        Но мне сложно представить что имея дело именно с бизнесс-заказчиком, можно получить такие полезности. Оперировать ему ИТшными терминами без подготовки после небольших презентаций всё равно сложно. Если речь о техническом персонале то всё логично.

  2. Roman
    Nov 2nd, 2010 at 16:00 | #4

    Приведенный пример мало иллюстрирует тезис статьи “вам необходимо обучать Заказчика. -Технологии проекта”

    Цитата:

    как эта система работает?
    как необходимо обслуживать систему?
    как и куда звонить в случае проблем?

    Эти вопросы решаются грамотной инструкцией по эксплуатации (юзер/оперейшн мануалом) и тренингом операторов при поставке продукта.

  3. Roman
    Nov 2nd, 2010 at 16:09 | #5

    Сергей Бережной: Я знаю одного Заказчика, который вкинул 200К денег в то, чтобы заказать сервера, которые в итоге “не совсем подошли”. В общем, он мог бы сэкономить где-то 80К. Хороший стимул для того, чтобы поучиться?

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

  4. Roman
    Nov 2nd, 2010 at 16:20 | #6

    Сергей Бережной :2. Заказчик сможет лучше объяснять свои проблемы службе поддержки.

    Промышленные системы, а, соответственно, эксплуатационные документы к ним, и так достаточно объёмисты…

    Чтобы пользователь системы и саппорт говорили на одном языке – глоссарий системы и юзер-мануал им в помощь вкупе с тренингом и аттестацией по этому материалу.

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

  5. Roman
    Nov 2nd, 2010 at 16:25 | #7

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

    При условии, что со стороны Заказчика есть специалисты, готовые понять то, что им рассказывают.

    • Nov 2nd, 2010 at 17:06 | #8
      Roman :

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

      А вот эти пункты также можно записать как “плюсы” того, что Заказчик владеет технологиями. Спасибо за хороший пример!

      • Roman
        Nov 2nd, 2010 at 17:37 | #9

        Пожалуйста!

        С миру по нитке насобираем Вам материал на целую книгу :)

        “Плюсы”-то ладно, не забывайте про “минусы”…

  6. Nov 2nd, 2010 at 16:58 | #10

    Roman , большое спасибо за большое колличество коментов. Видно, что тема не оставила вас равнодушным :)

    Часто ссылаетесь на мануалы и юзер-гайды. Это конечно тоже обучение Заказчика, но это уже 4 пункт – Обучение конечному продукту (который еще не опубликован). Терпение, и мы доберемся и до юзер-мануалов.

    Про 200К пример был в том, что он вложился не только в железо, но и софт, который был очень недешев. А так как Заказчик не понимал технологий, то и впарили ему все что могли “полный фарш”, который оказался излишним.

  7. Roman
    Nov 2nd, 2010 at 17:28 | #11

    Да уж, оказался я неравнодушен к Вашему “троллингу” :)

    Сергей: “Про 200К пример был в том, что он вложился не только в железо, но и софт, который был очень недешев. А так как Заказчик не понимал технологий, то и впарили ему все что могли “полный фарш”, который оказался излишним.”

    То есть Вы считаете, что те представители Заказчика, которые не смогли понять Ваши системные требования (а они были написаны адекватно, правда ведь?), поняли бы хотя бы архитектуру Вашего продукта?

    Пример:
    Предположим, на тренинге по внутренним технологиям системы будет озвучено: “Наша система использует собственные алгоритмы шифрования в базе данных”.
    Как это поможет среднестатистическому Заказчику понять, что ему не нужен MS SQL Server 2008, а достаточно 2005-го?

    В чём цимес _нужности_ тренингов Заказчика внутренностям проекта? В данной заметке и, тем более, примере с котлом, это не заметно.

    (И это мы ещё не начинали говорить про негативные аспекты подобных тренингов, а они есть, шишки уже нАбиты…)

Leave a comment