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

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

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

Что такое описание предметной области? В умных книжках дается много определений, но мне больше нравится следующее:

предметная область проекта – это совокупность всех ролей, объектов и их состояний, возможных действий, возможностей и ограничений, связанных сценариями использования

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

Итак, какими основными рисками позволяет управлять описание предметной области:

0. Риск потери понимания бизнес-модели

Штука, которая страшна для любого проекта, независимо от его величины и сложности. Как только разработчик теряет понимание/ощущение/осязание первоисточника решения, т.е. бизнес-модели использования программного продукта и в проектировании оперирует не терминами предметной области проекта (бизнес-терминами, иными словами), а только классами, методами и интерфейсами – все, приехали. Начинается »клейка танчиков» и «заклепочничество» в чистом виде. Лучше иметь ответы на вопросы «зачем мы это делаем» в максимально простой, компактной и понятной форме. Кто-то может сказать, что он замечательно и без всяких моделей предметной области переводит user-story/use cases/scenarios в программный код. Отлично, а вы спросите его о том, как ответить на вопрос о том, как определить сложность тестирования или определить степень влияния фич друг на друга?

1. Риск потери ценности системы знаний

В любой системе знаний, кроме накопления, систематизации, транзитивности и пр. – есть ещё такая вещь, как обмен знаниями. Чем меньше объем и чем на более высоком абстрактном уровне находится вводная для проекта – тем проще вводить новичка, да и старикам навигацию это упрощает. Такая модель, представленная, как правило, в виде «кружочки + стрелочки + поясняющие надписи» – это очень полезная для команды вещь. Намного полезнее, чем диаграмма классов во всю стену, которая висит в большей степени «для понтов» и «меряний» :)

2. Риск определения момента, когда заказчика можно отпустить

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

3. Риск потери управления техническим долгом

Очень часто бизнес требует сразу писать legacy код :) Все часто сталкивались в своей практике со случаями, когда бизнесмен принимает решение quick win vs. long way в пользу быстрой поставки решения, которое с точки зрения разработчиков не более чем технический долг чуть более, чем полностью. Даже если этот технический долг измерим, осязаем и вполне себе в будущем начинает возвращаться, то без абстрактной модели будет очень трудно. В этом часто и состоит конфликт между бизнес-стороной проекта и его разработчиками: бизнесмен ожидает, что уж после не самого дешевого «продакшен-прототипа» с наработанным опытом и пониманием реализованной бизнес-модели возврат технического долга произойдет быстро. А получается, что уже через полгода требуется функциональный реверс-анализ проекта :)

4. Риск качества перевода с языка бизнеса на язык кода

Имеется ввиду перевод требований и сценариев в рабочий код. Модель предметной области в данном случае – отличная точка входа для управления рисками перевода идеи в реализацию. Хотите – используйте её как трамплин для погружения в DSL и DDD, хотите – просто как артефакт, задающий на высоком абстрактном уровне структуру, иерархию, потоки данных и действий, разделяющий зоны воздействия ролей для удешевления верификации, разработки, планирования и т.д.

5. Риск определения достаточности регрессии функциональных тестов

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

6. Риск смены решения

Разговоры про эволюцию кода и гибкие архитектуры – вещь классная. Но в бизнесе, как на войне – пушистый зверь может подкрасться незаметно. Например – сменятся аппаратные требования. В разгар кризиса и при развитии Atom платформы они менялись в сторону уменьшения :) Вот и представьте, что вы отрезали от вашей связки «требования – сценарии – реализация» слой реализации. Что при этом произойдет? Правильно – кроме проектирования решения, опять реверс-анализ ввиду непрозрачности связей в сценариях.

7. Риск удорожания внесения изменений

С помощью абстрактной модели изменения в проекте легче продавать, анализировать, реализовывать, оценивать тестирования, вводить на задачу новых людей, страховаться от «замыливания» восприятия и многого другого. Очевидные, казалось бы вещи, но если бы все системно работали над снижением себестоимости реализации процесса – вряд ли было бы столько проектов, у которых деньги кончились или из-за невоспроизводимости качества или просто «вдруг», не так ли? Все-таки один из ключевых рисков разработки – потерю понимания потребностей заказчика никто не отменял.

8. Риск удорожания стратегического планирования

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

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

Самое трудное в абстрактном моделировании, как с любой документацией – его продажа процесса и артефакта заказчику и/или руководству компании. Рекомендую эту продажу делать от перечисленных выше рисков – очень помогает :)

Более детально о рисках проектирования и о управлении ими, мы поговорим с вами на мастер-классе «Практики эффективного, но экономного проектирования».

Продолжение следует.