Идеальное программное решение

Как разрешать технические противоречия с минимальными потерями

У каждого в жизни случались ситуации, которые заводили в тупик. Инженеры в ИТ сталкиваются с ними ежедневно. Как они выбирают лучшие решения с наименьшими потерями и какой методологией руководствуются, читателям RSpectr рассказал руководитель направления разработки и технического развития компании «Эдит ПРО» (группа «Борлас») Никита Зайцев.

САМЫЙ ВАЖНЫЙ ЭТАП

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

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

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

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

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

НА СОВЕТСКОЙ БАЗЕ

Современные методики принятия проектных решений базируются на ТРИЗ (теории решения изобретательских задач), разработанной в 1940-1950-х годах в СССР и получившей второе рождение в 2010-х, в том числе в связи с ростом популярности творческого программирования.

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

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

Любое противоречие решается в пользу ИКР, причем решение должно быть реализуемо с минимальными затратами времени и ресурсов. То есть если перед разработчиком будет стоять дилемма, реализовать подписание документов кнопкой или гиперссылкой, кнопка будет предпочтительным вариантом с точки зрения удобства для пользователей.

Процесс принятия проектного решения по ТРИЗ

Современные инженеры переработали изобретательскую теорию и выделили на ее основе несколько этапов принятия проектного решения.

Этап 1. Целеполагание.

На этом этапе нужно сформулировать задачу, для которой необходимо найти решение. Важно, чтобы она была максимально конкретной и практически решаемой. К примеру, задача «как вести документооборот» слишком объемная. Лучше разделить ее на несколько: «какие шаблоны оформления документов реализовать в системе», «как подписывать документы» и так далее.

Этап 2. Выявление граничных условий.

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

Этап 3. Выявление внешних факторов.

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

Этап 4. Поиск и описание вариантов.

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

Этап 5 (самый важный). Анализ и оценка вариантов.

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

КАК ОЦЕНИТЬ ПРИНЯТОЕ РЕШЕНИЕ

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

• критериев должно быть немного (не более семи, а лучше – пяти);
• каждый критерий должен иметь четкую качественную шкалу.

Что такое качественная шкала? Это порядковая шкала, которая позволяет определить относительную позицию того или иного объекта. У нас обычно это шкала с четырьмя измерениями: «Отлично», «Хорошо», «Удовлетворительно», «Плохо» (критерию можно присвоить весовой коэффициент).

Вот так выглядит мой личный набор критериев:

• трудоемкость всех стадий жизненного цикла до ввода продукта в эксплуатацию;
• рентабельность доработок, от диагностики ошибок и проблем до внесения оперативных изменений;
• энергоемкость: то, что называется «совокупная стоимость владения», + ФОТ, лицензии и т.д.;
• масштабируемость, или возможность дешево преодолеть падение качества при повышении нагрузки;
• отказоустойчивость, то есть вероятность возникновения сбоев при ошибках персонала, пиках нагрузки, долгих uptime;
• отчуждаемость – мера зависимости от чужих неподконтрольных компонентов;
• гибкость – стоимость и сроки внесения качественных изменений при наращивании требований.

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

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

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

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

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