Важность понимания предметной области

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

Вспоминая прошлый опыт

Когда разрабатывал продукт для РЖД — перечитал всё про поезда и станции. Это сформировало очень хорошее понимание проблемной области и позволило общаться с заинтересованными сторонами на равных. Колесные пары? Окей, давайте обсудим.

Когда разрабатывал систему онлайн обучения для университетов — прошел несколько курсов в подобных системах, много общался с преподавателями, постоянно общался с сокурсниками и сам провел онлайн курс. Позволило прочувствовать удобства и неудобства на себе, приоритеты устанавливались как по волшебству, архитектура органически развивалась вслед за каждым новым выпуском продукта. У этой системы было интересное ограничение — в качестве протокола для общения фронта с бэком использовался IRC 🙂

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

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

И так каждый раз.

К чему это всё?

Разработка продуктов и систем — это не просто взять текст ТЗ и перевести с бумаги в код. Если бы это было так, то куда проще научить того, кто пишет ТЗ программировать. Разработка — это понимание проблемы, осознание её, это новый, огромный домен. Это инвестиция в себя и капитализация знаний. Разработчик в прямом смысле строит в виртуальном мире проекцию реального, а без понимания устройства реальности это сделать очень и очень сложно.

Реальный и виртуальный мир отличаются в своем устройстве. В реальном связи строятся нередко сами собой, спонтанно, структура зачастую понятна (или ее по крайней мере можно обозреть), о многих причинах и следствиях мы не задумываемся, они просто есть. Мы можем увидеть картину в целом (с точностью до субъективной оценки), особенно для привычных вещей. Мы и привыкли видеть и получать законченный результат.

Взять покупку квартиры. Мы знаем, что получим в итоге, в нашей ментальной модели есть устоявшиеся паттерны как квартирой пользоваться: двери, розетки, окна, лифт. Мы прекрасно знаем, как интегрироваться с магазинами черед биты в кошельке. Как деплоится на работу. Если мы хотим доставку — отправляем событие на покупку и получаем пиццу.

И взять совершенно новый виртуальный продукт. Паттернов поведения еще нет, решает он проблему или нет — непонятно. Вообще, далеко не факт, что люди смогут перевести паттерн поведения из реального мира в виртуальный органически. Всегда есть сопротивление и доля страха. Ага, а мы еще и технически такого никогда не делали 🙂 Отсюда берется инкрементально-итеративная разработка.

Берем самый минимальный набор ключевой функциональности и реализуем самым простым, каким только возможно образом. Показываем или выводим на клиентов — это отдельное решение, но важно то, что мы начинаем лучше понимать и предметную область и техническую часть сразу же, как только получили работающий продукт. Это фантастическое ощущение осознания 🙂 И обладая новым знанием уже можем принять более осознанное решение о стратегии развития. Может, вообще откажемся от дальнейшей разработки, может сделаем крутой вираж и полностью изменим продукт, а может и продолжим развивать по изначальной стратегии. Тут важно то, что не только продукт должен нести ценность; информация, которую мы получаем — это тоже ценность.

Из этого два следствия

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

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

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

PS: начать можно с простых вопросов:

• Какую проблему мы хотим решить?
• Кто пользователи/заказчики?
• Как выглядит процесс от начала и до конца в реальном мире?
• Какие риски и ограничения существуют?
• Есть ли зависимости?
• Какую ценность несет наше решение?