Мы сначала спрограммировали, а потом подумали…

Короче, вполне себе такие приличные джуны, опора и надежда ИТ-отрасли. Одна беда — они рассматривают задачу исключительно как техническую, разработческую, не вникая и не умея вникать в то, какие же процессы за нею стоят, какие потребности, да и что, в конце-то концов, надо получить при ее решении. Стоооооп, скажете вы. Это ж функционал бизнес/продуктового аналитика, а не разраба. И вот тут-то и лежит корень проблемы.

С того периода (это примерно с 2000-х), когда начали разделять деятельность разработчика системы и бизнес-аналитика, и «затачивать» разработчиков ПО, и даже его архитекторов, исключительно на техническую реализацию, и стала набирать мощь проблема программерской слепоты — когда за техническим решением не видят пользователя и его нужд. Зачем? Есть же бизнес-аналитик, есть специалист по User Experience (Ux), они пусть и думают. А мы будем разрабатывать.

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

Пример номер раз. Внедрили новый вид сквозной авторизации по типу ЕСИА, чтобы под единым логином/паролем можно было получить доступ ко всем корпоративным сервисам. Круто? Полезно? Несомненно. Но теперь, чтобы пользователю зайти в любой сервис требуется 4 (!!!) клика мышкой и экрана авторизации. Вдобавок есть и альтернативный способ авторизации (старый), который сбивает с толку. В итоге — вал запросов пользователей с однотипной фразой: «Не могу зайти в сервис». Потому что сначала спрограммировали, потом подумали.

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

Пример номер три. В предложенном разработчиками решении для корпоративного сервиса нарушено несколько требований Закона о персональных данных. При попытке объяснить разработчикам, что так нельзя, они апеллируют к тому, что сделали все по стандартам Google. Окей, Гугл, а к кому придет прокуратура, когда это будет обнаружено? К Гуглу и его стандартам или к заказчику?

Пример номер четыре. В достаточно несложном как по процессу, так и по логике модуле для сервиса, при наличии полного технического задания, включая диаграмму BPMN, разработчики не приступили к реализации до тех пор, пока бизнес-аналитик не прошелся по ТЗ и не разъяснил им все еще раз. Они даже не читали техзадание. Зачем? Если есть бизнес-аналитик, который должен разбираться. Это затянуло сроки разработки на пару месяцев и ввело ненужное промежуточное звено в коммуникацию заказчика и разработчиков, что неизбежно привело к неточностям.

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

Я противный препод, признаю. Я заставляю их обосновывать выбор того или иного алгоритма не тем, что «так удобнее считать», или «это будет красивый алгоритм», или потому, что «это самый популярный пакет»… И даже «потому, что на Хабре это хвалили» тоже не работает. И даже то, что «ну вы же давали эту архитектуру в примере» совсем не подходит.

Нет, я заставляю оперировать понятиям скорости, удобства (причем удобство мы еще считаем), ресурсоемкости, а также задаю бесконечные вопросы: «зачем?» и «что получит пользователь?» — пока не выйдем на ответ, понятный без знания технических терминов. Но не могу не признать, это работает только, пока студент учится на бакалавриате. Когда ко мне попадают студенты в магистратуре, задавать подобные вопросы уже почти бесполезно. Паттерн сформирован, и разделение на умных и красивых — ой, простите! — на бизнес-аналитиков и разработчиков уже в их головах сделан.

Значит ли это, что я против профессии бизнес/продуктвого аналитика и считаю ее вредным и ненужным звеном в разработке? Нет, нет и еще раз нет. Я сама работала и бизнес-, и продуктовым аналитиком еще тогда, когда у этой профессии не было такого названия. Да и сейчас частенько выступаю в данной роли. И разумеется, я понимаю функционал и важность этой роли в разработке. Более того, в автоматизации сложных производственных процессов, в финтехе, роль бизнес-аналитика не менее, а бывает, и более важна, чем роль разработчика. Неправильно запроектированные и реализованные процессы могут ооочень дорого обойтись, даже (и особенно) при безупречной технической реализации. Я против того, чтобы бизнес- и продуктовые аналитики привлекались для разработки любого, даже самого простого сервиса. В таких сервисах не требуется специфических знаний, чтобы понять и расписать процесс, нет тайных знаний, недоступных человеку с логикой и интеллектом (а ведь все разработчики должны обладать такими качествами, правда?), зато очень важна ориентация на пользователя — как профессионального, так и конечного. И именно здесь важна прямая коммуникация разработчиков с функциональными заказчиками. Именно так формируется «насмотренность» процессов, их понимание, ориентация на пользователя, а не на технические решения. Я многократно убеждалась, что погружение разработчиков в процессы замедляет процесс только на короткое время на начальном этапе, зато в ходе разработки, доработки и выпуска в прод она, наоборот, позволяет выбирать оптимальные решения и быстро их реализовывать, ускоряя процесс, иногда в разы.

Происходит ориентация на пользователя (пресловутый Ux) и процессы, а не на технические решения. А для того чтобы это происходило как можно более безболезненно и эффективно, я считаю необходимым включать в каждый курс ИТ-специальностей (неважно — в бакалавриате, магистратуре или на курсах) модуль по анализу бизнес-процессов и продуктовому анализу. Это должно быть таким же «золотым стандартом», для каждого курса, как «алгоритмы и структуры данных» или «организация процесса разработки». Ну а полученные знания должны сразу же применяться на хакатонах, в разработке пользовательских сервисов. Должна создаваться культура коммуникации между разработчиками и заказчиками. Только тогда первые перестанут быть в глазах вторых странными людьми, говорящими странные слова, а вторые в глазах первых — непонятными нервными человеками с непонятными хотелками. И только тогда процесс разработки станет действительно нацеленным как на решение задач, так и на интересы пользователя.