Аргументация технических решений

В черновом варианте эта статья называлась «Что делать, если начальство продавливает административно свои технические решения?». Этот вопрос я слышу столько, сколько работаю в IT — практически всю жизнь. Лет пять назад я отвечал на него на выступлении, посвященном принятию решений в условиях неопределенности и вот, когда он вчера прозвучал в очередной раз, решил опубликовать ответ здесь, но ответ выглядел не полным и в итоге он стал введением к теме об аргументации технических решений в целом.

Что делать, если начальство продавливает административно свои технические решения?

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

Если мы крепко задумались и поняли, что все-таки решение нам костью в горле — попробуйте разобраться, зачем им это надо и попытаться интегрировать точки зрения.

Какими могут быть причины? Лишь несколько примеров:

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

Что можно сделать?

Есть несколько возможных путей:

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

Если есть чем дополнить, пишите, добавлю в статью:


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

Аргументация технических решений

Важный пререквизит для сильной аргументации и проработки решения в целом — понимание процессов компании. Например, это могут быть:

  • кто/что/когда делает
  • требования, политики, стандарты, требования
  • требования регуляторов, финансы, безопасность, закупки

Список не исчерпывающий и зависит от масштаба технического решения. Для крупных изменений он, скорее всего, будет шире.

Разумеется, технические решения не появляются в вакууме, хоть часто кажется, что именно так и происходит, и для решения понадобится оформить бизнес-кейс, состоящий таких частей, как:

  • Бизнес-проблемамитка. Акцент именно на проблеме, а не решении, ведь если проблема не стоит того, чтобы быть решенной, то никакое решение не стоит того, чтобы быть примененным
  • Критерии успешности решения (иногда полезно определить «критерии провала», показывающие, что решение не сработало и пора от него отказаться)
  • Анализ ROI (возврат на инвестиции)
возврат на инвестиции

Конечно, важно явно обозначить ценность решения:

  • Решение должно
    • зарабатывать деньги и/или
    • сокращаться расходы и/или
    • решать задачи по соответствию требований регуляторов
  • Результаты должны быть связаны с конкретными высокоуровневыми бизнес-целями
  • Должно быть отражено как ценность изменяется со временем

Дальше нужно показать какие существуют альтернативы и как они оценивались, при этом:

  • Опирайтесь на четкие бизнес-ориентированные критерии оценки
  • Покажите как вы выбирали и оценивали альтернативы
  • Двигайтесь от общего к частному
  • Используйте максимально простые и понятные формулировки
Всегда существует более одной альтернативы

В дополнение можно поискать примеры применения подобных решений в схожих ситуациях или релевантные кейс-стади. Если возможно, то в идеале подготовьте и предоставьте Proof of Concept.

Пример итогового результата решения, таким образом, может выглядеть следующим образом:

  • Краткие выводы и рекомендации
  • Бизнес потребность/проблема
  • Возврат на инвестиции
  • Рассмотренные альтернативы
  • Выводы
  • Итоговые рекомендации

Самое интересное

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

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

А если требуется помощь в проработке, оценке или рациональном обосновании архитектурного решения, всегда готов помочь, пишите.

Share

Добавить комментарий