Статьи

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

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

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

Как это выглядит практически:

1. С заказчиком определите главные цели проекта. Выясните, чего он хочет добиться этим проектом и определите критерии достижения цели.

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

3. Проанализируйте путь достижения главной цели – из него появляются дочерние цели.

4. Определите (с заказчиком или уже без него) в общих чертах путь достижения каждой дочерней цели.

5. Проанализируйте …

Повторяйте самостоятельно выделение целей и анализ путей их достижения до тех пор, пока цель перестает отвечать на вопрос «чего мы хотим добиться» и начинает отвечать на вопрос «как добиться». Иными словами – вы приходите к финальным сценариям поведения/кейсам/стори – называйте как хотите. Главное, чтобы ваш сценарий позволил ответить на вопросы «кто?», «когда?», «где?», «как?», «для чего?», «что получает?». Если сценарий отвечает на эти вопросы, то он готов к переводу в предметную область разработки – на язык фреймоворка и тестового окружения.

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

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

Какие вы получаете выгоды от такого подхода управления требованиями и дальнейшего проектирования:

1. Резкое сокращение объема работы для заказчика и увеличение объема творческой и высокооплачиваемой работы для себя.

2. Переходя от вопросов «чего надо сделать?» к «чего вы хотите добиться?» вы резко сокращаете влияние субъективного мнения о решении проблемы как вашего, так и заказчика – тот самый риск подмены постановки задачи решением.

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

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

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

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

7. Если команда владеет целями, связанными с реальной бизнес-моделью и приоритетами этих целей – проще бороться с прокрастинацией и смещением фокуса с целей на заклепочничество в команде.

8. У вас есть черновик функциональной карты проекта, связанный с бизнес-целями как пруф вашего понимания бизнес-модели и способности решать бизнес-задачи. Хороший продажник вам так на этой теме денег накосит – мама не горюй Такое и инвестору не стыдно показать, и архитектор потом спасибо скажет.

Такие вот практики продуктовой разработки по управлению риском подмены постановки задачи решением

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжаю серию статей «Старт проекта». Первая статья здесь – Старт проекта. Как это делать?

А в этой статье поговорим о дисциплине управления конфигурациями как таковой и о ее важности.

Сразу начну с кейса из реальной жизни:

• Заказчик прислал проект на оценку в виде нескольких документов, пусть это будут спецификации: «Spec 1 v1_1» и «Spec 2 v1_2»
• Сделали оценку работ, причем в разделе «References» указали что оценки сделаны на основе этих спецификаций
• Заказчик согласился на оценку, подписали контракт, собрали команду, начали проект
• В середине проекта выяснилось, что обещанные сроки выдержать не получается
• Поначалу «подозрение» пало на некачественный оценку работ
• Но в конечном итоге выяснилось что: А) – заказчик в начале работ «подсунул» другие спецификации (названия те же, но версии и содержание отличаются); Б) – никто не сверился, отличаются ли изначальные и новые спецификации.

А теперь еще несколько типичных проблем:

• Устраненные дефекты появляются снова
• Отсутствуют зафиксированные версии спецификаций, продукта
• Заказчику отдали старую или неполную версию продукта или его частей
• Откуда-то появился новый функционал
• Не совпадают спецификации, продукт и тестовая документация

Отсюда возникает вопрос – как этого не допустить, и как это сделать осмысленно, и без чрезмерных усилий? Как ясно из названия, такие проблемы призвана решить дисциплина Управления Конфигурациями.

Немного истории. Дисциплина, как и многие другие здравые мысли пришла от военных. Кстати еще о военных, есть статья «История проектного инструментария, нач. ХХв.» – рекомендую. Так вот, как говорит Википедия, дисциплина формализовалась в 1950-х в американских воздушных силах для контроля над компонентами сложных систем. И сейчас применяется во многих отраслях, в том числе и космической. Если говорить о более близких к ИТ вещах, то она постепенно стала компонентом CMMI, ISO 9000, ISO 10007, ITIL, PRINCE2 и т.д.

Собственно определение – Управление конфигурацией (Configuration Management, CM) – это управление наборами рабочих продуктов, их версиями, статусами и взаимосвязями.

Ключевые задачи могут немного отличаться в разных источниках, но если выделить основное, то это:

• Определение элементов конфигурации
• Учет состояний и версий
• Отслеживание запросов на изменение
• Верификация конфигураций

Причем, о первых трех в списке нужно по возможности договориться на старте проекта, лучше до подписания контракта. Давайте рассмотрим первую задачу – «Определение элементов конфигурации». На протяжении проекта производится множество разных артефактов (Work Products) – спецификации, отчеты, код, результаты инспекции кода, документация пользователя, тест кейсы, скрипты, протоколы совещаний и т.д. Некоторые из них являются Элементами Конфигурации (Configuration Items), а некоторые нет. Если по простому, то Элементы Конфигурации – это наиболее важные артефакты, это могут быть: результаты поставки заказчику; артефакты, от которых зависят другие артефакты и т.п. Например, спецификация – однозначно Элемент Конфигурации, т.к. на ее основании разрабатывается продукт, тестовая документация, делается приемка продукта и т.п. А вот отчет – вряд ли.

Соответственно к Элементам Конфигурации должен применяться структурированный контроль – со второй по четвертую ключевые задачи в списке.

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

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

Серия статей «Старт проекта» выходит в поддержку тренинга «Успешный старт проекта», в котором темы статей рассматриваются подробнее и с практическими заданиями.

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

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

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

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

Это не работает. Это просто приведет к тому, что у нас будет 100% покрытие зелеными тестами, например, но свободный поиск руками покажет, что фича негодна. С такими всплесками нужно бороться. Например – ни одна практика не внедряется без экономического обоснования с точки зрения целей проекта, а не процесса. Потому что под процесс всегда можно оправдать А вы попробуйте честно доказать друг-другу, например, что TDD вам нужна в первую очередь как инструмент уточнения требований, а уж потом – как средство повысить качество кода. Очень много интересного узнаете о том, как вы управляете требованиями и почему у вас они часто меняются.

Ценность agile практик, кстати, как раз в том и заключается (в том числе), чтобы убрать культы, но человек слаб, поэтому он часто возводит уже agile в культ.

Третья ошибка – смещение фокуса ролей. Крамольная мысль №1 – не нужен в команде «главный выделенный архитектор», отвечающий за стратегию и фреймворк решений. Так много внимания уделяется архитектуре приложения во всех её проявлениях – архитектура, дизайне, детальный дизайн. А ведь это инструмент, не более. Потому что проектирование – это не создание технического фреймворка, это процесс решения вполне себе экономических, социальных, психологических и прочих проблем. Мы привыкли рассматривать разработку как процесс создания артефакта – работающего кода. А решаемые проблемы (заказчика и разработчика) – они не ложатся в этот фреймворк, в его структуру и иерархию – он просто выступает одним из решений.

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

Крамольная мысль №3 – наличие выделенного архитектора во много крат повышает влияние риска «любимого ребенка» и вместо реальной помощи при адаптации архитектуры под изменения требований бизнеса – начинается игра не в те ворота. Как часто вам главные архитекторы тормозили процесс изменений и рассказывали, что это сложно, невозможно и очень трудно тестировать? И ведь под благим предлогом – нам нельзя дестабилизровать проект и т.д. и т.п.

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

Иными словами, архитекторы – это опытные разработчики, которых подпирает бизнес-аналитик, не позволяя увлечься сферическим конем в вакууме, постоянно напоминая о реальных критериях качества, а не о чистоте архитектурных решений, паттернах и иерархии классов. При этом, завершив этап архитектуры, эти разработчики начинают получать обратную связь о качестве этой архитектуры путем использования – самы хороший вид обратной связи. Кстати, самая навороченная из Agile методик – Feature-Driven Development, как раз и оперирует группами архитекторов (Chief Developers).

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