Я принёс тебе аналитику

Наши действия или намерения – это проекция нашего сознания. Есть какой-то внешний стимул, есть субъективная интерпретация этого стимула. Стоит ли говорить, что интерпретация может быть неверной?! На подобные мысли меня навел предыдущий пост и недавние события на текущем проекте.

Эта проблема известна всем, кто работает по принципу, когда между пользователем, бизнесом и разработчиком стоит некоторый посредник. Это может быть представитель заказчика, бизнес-аналитик, системный аналитик, архитектор или автор задачи. Вся эта цепочка посредников часто образует “глухой телефон”, результат работы которого как цунами обрушивается на непосредственного исполнителя.

Императив не работает так, как вы хотите! Императив – это ваша субъективная проекция исходной мысли, не более. Не случайно приверженцы гибких методологий очень любят такой инструмент, как User Story, ведь он несет в себе изначальный посыл и предполагает наличие обратной связи. Имея цепочку посредников-аналитиков-архитекторов между пользователем и разработчиком, обязательно включайте в описание сведения о том, для чего это делается, почему это делается, что на самом деле от нас ждут, укажите важные требования и ограничения. И только после этого, если считаете, что это действительно несет ценность, опишите ваш способ решения – как вы предлагаете это сделать. При этом под словом “как” я больше имею в виду что-то близкое к Use Cases или пошаговому формату без перегрузки деталями, которые непременно устареют.

Что это даёт?

Сколько раз мне приносили многостраничные документы, изначальный посыл которых становился понятен только после прочтения последнего предложения; и только после того, как я прочитал это на раза 2-3. Пожалуйста, никогда не делайте так! Пусть в самом начале повествования будет побуждающий мотив, а затем ваша версия решения. Видя цель, читатель вовлекается постепенно, его мыслительный процесс практически сразу запускает “обратную связь”, критическое мышление, которое будет работать от первой до последней страницы. В результате он придёт к вам с правильными вопросами и, возможно, укажет на ошибки или недочёты, и их можно будет устранить на ранних этапах.

Свежий пример того, как не нужно делать.

Всей командой разбирались со странным поведением приложения. Если быть конкретным, то приложение должно было отображать дату последнего вызова скорой помощи. Однако после первого вызова скорой эта дата не отображалась. По коду всё выглядело как ошибка разработчика. Тестов, естественно, не было; а в системной аналитике был только императив – пошаговый алгоритм, больше напоминающий псевдокод. К счастью, к концу дня мы смогли найти документ с бизнес-постановкой, в которой скромно затесалась фраза: “Вызов скорой помощи является для пользователя сигнальной информацией, начиная со второго”. Эта простая и короткая фраза могла бы сэкономить кучу времени и сил. Трудно было её добавить в постановку задачи или в комментарий к коду, написать тест для этого кейса? Не думаю.

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

Только так вы добьётесь эффективности в работе и получите желаемый результат.

---

После выхода статьи были подняты интересные вопросы. Ответы получились хорошим дополнением, поэтому включаю их в текст статьи.

Вопрос: Часто встречаю непонимание своей профессии [системный аналитик]. Многие называют [нас] ненужной прослойкой.

Ответ:

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

Вопрос: По поводу декларативного и императивного. Некоторые вещи не описать декларативно.

Ответ:

Согласен, всегда есть исключения. Поэтому сказал, что декларация вполне может дополняться конкретикой (императивом). Например, императив пошагово на две страницы показывает, как нужно делать ETL (Extract-Transform-Load), но перед этим желательно понимать, а зачем всё это происходит. Ведь когда ты в теме, добавить пару предложений о том, какой цели мы хотим добиться, совсем не проблема. Например: “Пользователям нужно каждый день формировать отчет X. Текущий вариант хранения не позволяет формировать отчет X быстро, поэтому он формируется по ночам раз в неделю. В связи с этим нужно создать проекцию данных, используя нижеследующий алгоритм”. Вот таких банальных объяснений подчас не хватает. Особенно если системная аналитика (аналогично - архитектура) спускается от заказчика “сверху” и пишется неизвестными людьми.

Вопрос: Дублировать [бизнес-требования в системных постановках] не желательно. Тут также как в коде - в одном месте поменял, а в другом забыл.

Ответ:

Тут зависит от используемой системы, организации процесса и самодисциплины. Если артефакты меняются разными людьми и в разное время, то могут быть проблемы. Например, обновили документ с бизнес-требованиями, а системная аналитика еще в процессе. Если гиперссылки в документах wiki-системы как-то учитывают версионирование, то хорошо; если нет, может возникнуть непонимание. Однако момент с “дублированием” я, возможно, раскрыл не очень точно. Суть - дать в несколько предложений простым и понятным языком контекст и мотивацию последующих выкладок. Естественно, я не имел ввиду полное дублирование бизнес-постановки. Иначе говоря, хочется, чтобы автор текста немного позаботился о будущем читателе.

Вопрос: Ошибаются все.

Ответ:

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

Вопрос: Просто чем раньше по жизненному циклу создания ПО случается баг тем он дороже.

Ответ:

Наверное, ты хотел сказать, что неточности в понимании предметной области оказывают лавинообразное влияние на всё последующее: архитектуру, реализацию и сопровождение. Именно поэтому я и говорю о необходимости вовлекать читателя (исполнителя) на самых ранних этапах; чтобы возникала эта “петля обратной связи”. Чтобы читатель невольно выступал в роли рецензента с самого начала. Этот нехитрый прием, как мне кажется, позволяет сместить ошибку влево (shift-left). Естественно, есть и те, кто любит делать по написанному, как под копирку и без всякого критического мышления. Я знал таких людей лично, но для меня это чуждо; могу найти лишь оправдания для подобного поведения (не хотят брать ответственность, ходят на работу за деньгами). Я все-таки за то, чтобы каждый включал голову чуть больше, чем требуется формально, тогда возникает нужная синергия и получается хороший результат.

Вопрос: Поэтому на ошибки аналитика часто реагируют очень остро, а на ошибки разработчик более понимающе.

Ответ:

Бывает по-разному. На одном месте работы главными негодяями всегда были разработчики. :)