Попса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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