Попса

популярный светский альманах

Тег: требования

Тактика вопросов для интервью с заказчиком

Интервью по сбору требований

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

Заказчик — необязательно главное лицо в компании, это может быть эксперт в предметной области или кто-то из ключевых пользователей. Заранее договоритесь о том, сколько времени займёт интервью. Я бы не рекомендовал проводить встречи длиннее 45 минут, на более длинных встречах собеседники устают и теряют фокус. Также при назначении встречи прикрепите адженду. Возможно, ответы на некоторые вопросы потребуют от заказчика подготовки.

По-хорошему, кто-то из вашего руководства (как правило, это спонсор проекта) должен заранее провести с вами бриф, рассказав краткую вводную по проекту, но может быть такое, что вы отправитесь на встречу вслепую. В таком случае, нужно задать вопросы:

  • Чем занимается компания?
  • Кто будет пользоваться решением, которые мы хотим разработать?

Далее следуют три вопроса, которые дадут вам 90 % информации о проекте. Это вопросы:

  • Какую бизнес-проблему нужно решить?
  • Как эта проблема решается сейчас?
  • Что не устраивает в текущем решении?

Дальше можно спросить, как они видят систему, которая будет решать проблему. Есть вероятность, что они уже потратили большое количество времени на проработку этой системы и их видение может быть вам полезно.

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

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

Имеет смысл спросить, у кого ещё можно пособирать требования. В идеале это один представитель каждого пользовательского профиля. Например, если системой будут пользоваться менеджеры и продавцы, надо бы опросить одного менеджера и одного продавца.

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

О том, как не превратить сбор требований в соревнование

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

Вот вы здесь говорите, что должна быть голосовая почта. То есть, в приложении должен быть контакт, позвонив на который вы можете прослушать голосовые сообщения, я правильно понимаю? Ну а здесь по всем канонам юзабилити мы будем размещать кнопку управления группами контактов, не так ли? Здорово, что мы с вами понимаем друг друга. Мне однажды доводилось курировать разработку подобного приложения, там был случай…

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

Как не настроить заказчика против себя при сборе требований? Вести диалог так:

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

И только если он сам вас об этом попросит, что-то рекомендовать. В этом случае вы не спорите с заказчиком, кто компетентнее, вы просто пытаетесь поглубже вникнуть в суть задачи, никакого соревнования нет, только продуктив.

Об обсервации

Есть несколько видов знания. Покажу на примере.

  1. Чувак не умел драться, но никогда об этом не задумывался, так как необходимости не было. Это неосознанное незнание.
  2. Чувака гопнули гопники и отжали телефон. И он резко осознал, что не умеет драться. Это осознанное незнание. 
  3. Чувак пошёл к тренеру, который в деталях обучил его, как наносить хук справа. Какое-то время чувак точно помнил, как сжимать кулак, как разворачивать корпус и как поднимать руку. Это осознанное знание.
  4. Чувак довёл хук справа до автоматизма и перестал ходить к тренеру. Навык остался, но он забыл, как это делается в деталях. Это неосознанное знание. 

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

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

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

Проблема роста

Проблема роста

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

Традиционный для отечественных компаний сценарий, ведущий к подобным проблемам:

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

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

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

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

Финиш. В продукте бардак.

Бороться можно. Серебряная пуля называется: «выделяем весь консалтинг в отдельный бюджет». С ранних этапов, как бы ни хотелось окунуться в кодинг с головой, сначала проектируем, затем кодим. Произошли изменения — актуализируем документацию. Для того, чтобы не забыть, встраиваем коррекцию документации в карту контрольных проверок и не считаем функционал готовым, если документация неактуальна. Кроме того, нельзя допускать, чтобы разработчики что-либо делали без формальной задачи в системе постановки и контроля задач. Это требование менее критично, но если его не соблюдать, в дальнейшем будет очень трудно найти концы.