...или причём здесь телешоу "Пойми меня" из 90-х.
Интересуетесь бизнес-анализом в ИТ? Приглашаю Вас ознакомиться с моей книгой "Профессия "бизнес-аналитик". Краткое пособие для начинающих" , которая вышла в издательстве "Олимп-Бизнес": https://taplink.cc/vdm_mrnv .
Упрощённый жизненный цикл разработки программного обеспечения состоит из 5 этапов:
- Обследование;
- Разработка;
- Тестирование;
- Опытная эксплуатация и внедрение;
- Сопровождение.
На каждом этапе предполагается работа различных ИТ-специалистов: руководителя проекта, аналитиков, разработчиков и тестировщиков. А значит каждый этап стоит бизнес-заказчику определённых денег. Естественно, что Заказчик заинтересован в том, чтобы работа шла строго по плану, без ошибок, а в идеале и с опережением сроков.
Увы, людям свойственно ошибаться и ИТ-проект, реализованный без единой ошибки - это нечто из области фантастики. Тем не менее, цена ошибок, допущенных в рамках ИТ-проектов, может сильно различаться. Сегодня мы поговорим о том, почему ошибки аналитиков могут обходиться заказчику особенно дорого и что с этим делать.
Ошибки в требованиях
По итогам этапа обследования аналитик готовит структурированный документ, в котором сформулированы требования к будущему ИТ-решению. Требования эти нацелены на то, чтобы максимально удовлетворить потребности заказчика в решении стоящей перед ним проблемы. Как правило проблема связана с бизнес-процессами Заказчика: длительностью выполнения отдельных работ, высокими затратами, техническими и законодательными рисками и т.д.
На основе требований разработчик приступает к созданию ИТ-решения, которое призвано частично либо полностью устранить имеющиеся у Заказчика проблемы. Для разработчика требования - ключевой документ с точки зрения понимания потребностей Заказчика.
Допустим, в ходе разработки программист неверно реализовал логику расчёта финансовых показателей в системе. В идеале, такую ошибку должен выявить инженер по тестированию. Тестовые сценарии подготавливаются на основе тех же требований аналитика. В ходе тестирования инженер выявит расхождение между написанным в требованиях и тем, что реализовано на практике. В этом случае разработчик исправит баг и продолжит работу над системой. Да, на устранение ошибки понадобится дополнительное время и деньги, но влияние ошибки на сроки и бюджет проекта будут не столь велики.
Совсем другое дело, если сами требования изначально сформулированы неверно ввиду недопонимания между Заказчиком и аналитиком. Очевидно, что такие ошибки выявляются гораздо позже, чем на стадии разработки и тестирования. В самом деле: и разработчик и тестировщик реализовали функциональную возможность в ИТ-решении в строгом соответствии с требованиями. Какие к ним могут быть вопросы? За корректность требований отвечает аналитик.
Ошибку в требованиях могут обнаружить лишь на этапе опытной эксплуатации, в которой примут участие представителя Заказчика. Вот тут-то и может выясниться, что "это совсем не то, что мы хотели". Что это означает с точки зрения жизненного цикла разработки? Это означает, что все этапы придётся проходить с самого начала: проводить дополнительное обследование, вносить изменения в требования, переделывать код и повторно его тестировать. А мы помним, что каждый этап - это время и деньги. Поэтому аналитические ошибки имеют куда большие последствия для сроков и бюджета проекта, чем любые другие.
Важно понимать, почему такие ошибки в принципе могут возникнуть и что с этим делать?
Причины возникновения ошибок в требованиях
Начнём с причин возникновения ошибок на этапе обследования. Ключевая причина - проблема в коммуникациях между аналитиком и Заказчиком.
Авторы "Настольной книги аналитика" Сергей и Валерий Ковалёвы отмечают, что при прохождении информации более чем через 2 звена устная информация искажается более чем на 50%. Этот принцип был наглядно показан в телешоу "Пойми меня", выходившем в начале 1990-х годов. По сути, это была телеверсия популярной игры "Испорченный телефон", в которой демонстрируется непроизвольное искажение информации, проходящей через большое количество людей.
Французский писатель и философ Бернар Вербер в своей книге "Энциклопедия относительного и абсолютного знания" наглядно показывает, сколь много вариантов недопонимания может случиться между людьми.
Между
тем, что я думаю,
тем, что я хочу сказать,
тем, что я, как мне кажется, говорю,
тем, что я говорю,
и тем, что вы хотите услышать,
и тем, что как вам кажется, вы слышите,
тем, что вы хотите понять
тем, что вы понимаете,
стоит десять вариантов возникновения
непонимания.
Но всё-таки давайте попробуем...
И действительно, поставьте себя на место Заказчика. У вас есть собственное представление о текущей проблеме в вашем процессе и вариантах её решения. И мнение это необязательно правильное. Но поскольку Заказчик - Вы, то ваше понимание ситуации станет определяющим для команды разработки.
По тем или иным причинам вы можете сказать аналитику далеко не всё, что думаете о проблеме. Это может быть связано с корпоративной культурой компании, политическими нюансами, конфиденциальностью отдельных видов работ и т.д. В конце концов вы можете быть изначально настроены против проекта и участвовать в нём под давлением руководства. В таком случае вы вряд ли встретите аналитика с распростёртыми объятиями.
Но всё же Вы сообщаете аналитику некую информацию о своей предметной области. Хорошо, если ваш рассказ последователен, структурирован, учитывает детали и особенности предметной области. Ну а если нет? Человеку свойственно думать, что другие знают о его работе почти столько же, сколько и он сам. Поэтому профильный специалист часто не останавливается в своём рассказе на "очевидных" моментах. Вот только эти моменты могут быть совершенно неочевидны для людей с другим жизненным и профессиональным опытом.
Теперь взглянем на процесс коммуникации с точки зрения аналитика. Это тоже человек со своим жизненным и профессиональным опытом. У аналитиков своя "профессиональная деформация" - они мыслят схемами бизнес-процессов и структурированными документами вроде бизнес-требований или технических заданий.
Ваш рассказ аналитик неизбежно начнёт воспринимать в рамках требуемой документации: схем, требований, таблиц и т.д. Хорошо, если аналитик достаточно опытен и не поддаётся соблазну додумать или подогнать рассказ Заказчика под нужный формат. Важно, чтобы аналитик подмечал и цеплялся за все логические нестыковки и "белые пятна" в рассказе Заказчика, а не стремился как можно скорее упаковать полученную информацию в документ. Тем не менее, все мы люди и аналитик может бессознательно додумать ответ на незаданный им вопрос и отразить его в требованиях. В реальности же ответ Заказчика может оказаться совершенно иным. Увы, такое недопонимание часто выясняется лишь на этапе опытной эксплуатации.
Нельзя сбрасывать со счетов и разницу компетенций между Заказчиком и аналитиком в рамках предметной области. Очевидно, что Заказчик намного более погружен в детали конкретного процесса, нежели аналитик. Поэтому рассказ Заказчика может изобиловать десятками специфических терминов и аббревиатур. Аналитику может казаться, что он всё понял, но самом деле нет.
Видите, сколь многое в ходе коммуникации может пойти не так? А если один из представителей Заказчика настроен против проекта? Вероятность возникновения дорогостоящих ошибок в требованиях в таких случаях крайне велика.
Что же делать?
В англоязычном ИТ-сообществе распространена аббревиатура CYA. Расшифровка слегка неблагозвучная, но в целом правильная: "Cover your ass" (прикрывай свой зад).
Для аналитика это значит, что все материалы обследования до передачи в разработку должны быть официально согласованы Заказчиком. Как минимум в виде ответных писем в электронной почте. Помня, сколь много в процессе коммуникации может пойти не так, сторонам важно постоянно "сверять часы". Цель согласования документов в том, чтобы спросить у Заказчика: "Я понял Ваш рассказ так. Я предполагаю, что он приводит к появлению следующих требований. Правильно ли я Вас понял? Этого ли Вы хотите от будущего ИТ-решения?".
Иногда Заказчик может уклоняться от прямых ответов или вовсе игнорировать процесс согласования. Проявите настойчивость. При необходимости эскалируйте вопрос на руководителя проекта.
Начало работ по несогласованным требованиям может дорого обойтись обеим сторонам проекта. Если на этапе опытной эксплуатации Заказчик начнёт говорить о том, что "Всё не так и всё не то", но у Вас на руках есть согласованные им же требования - это серьёзный аргумент. Наличие согласованных требований позволит Вам быстро урегулировать спорную ситуацию. Если Заказчик согласовал требования не читая - это проблема. Но проблема общая, а не только Ваша. И обвинить аналитика в срыве сроков и бюджета проекта не получится. В конце концов документация для этого и нужна - убедиться до начала работ , что стороны понимают друг друга, решают одну и ту же проблему и сходятся в подходах к её решению. По этой же причине официальная переписка в электронной почте предпочтительнее телефонных звонков и мессенджеров. Это дисциплинирует участников проекта и стимулирует нести ответственность за принятые решения.