Попса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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