Разбирали намедни с системным архитектором очередной запрос от пользователя. С одной стороны, требования понятны, пользователь ясно изложил пожелания, оценил эффект от реализации пожелания, всё по правилам и инструкциям. Но вот какая незадача. Прорабатываешь варианты реализации, и уже на подкорке головного мозга понимаешь что местами в заявке написано что-то неадекватное, что придётся делать кучу проверок разного рода, что придётся писать очень строгие правила ролевых ограничений. И всё по одной причине: подсознательно считаешь что пользователь — это некая мифическая неадекватная личность, способная на непредсказуемые действия. И уж ни в коем случае не стоит надеяться на то, что пользователь будет делать так, как заложен алгоритм работы, а попытается с помощью бухгалтерской системы запускать ядерные боеголовки. И меня очень сильно заинтересовал вопрос о том, откуда же такое отношение появилось и можно ли что-то с этим сделать? Мои размышления на эту тему ниже.
За свою профессиональную деятельность я повидал много различных разновидностей нелюбви к пользователям. Со стороны разработчиков, бизнес-аналитиков, руководителей проектов и вообще «айтишников» всех сфер деятельности.
Чаще всего это формулируется следующим образом:
- «Они вообще сами понимают что им надо?» — бизнес-аналитики
- «Они ж обязательно <сделают нежелательную операцию>» — бизнес-аналитики, системные архитекторы
- «Ну зачем они опять <сделали ту же ошибку>» — специалисты поддержки
- «Они обязательно <накосячат> а мы потом виноваты» — менеджеры проекта, системные архитекторы
И вот на этих всех положениях и строятся системы автоматизации. Множество проверок, ролевые ограничения и прямой отказ от выполнения некоторых пожеланий. И вот мой взгляд на то, откуда рождается такое противоречие.
- Не налаженный процесс сбора требований. О том, как важно собирать требования правильно я уже писал. До тех пор, пока требования не будут собираться, документироваться и утверждаться программисты будут вопить о том что пользователи неадекватны и не понимают что они хотят, а пользователь не будет получать то, что просил. И это, надо сказать, одна из самых основных проблем разработки ПО. Из всех своих мест работы, процесс управления требованиями я не встречал ни разу, с пользователями общались программисты (которые, понятное дело, не могут говорить «на языке бизнеса» и понимать потребности пользователя), а руководство компании — интегратора не видело никакой необходимости добавлять в проектную команду аналитиков, которые смогли бы стать посредниками между заказчиками и разработчиками. Внедрив у себя сейчас полный процесс сбора, описания и согласования требований по методологии Вигерса я убедился в том, насколько проще стало работать разработчикам и впервые за более чем 10 лет практики начал получать письма с искренними благодарностями от авторов запросов, потому что всё выполнялось именно так, как они хотели.
- Отсутствие инструкций и подсказок. Вот это что-что, а пользовательская инструкция, выданная вместе с релизом — это вещь пореже розового единорога. Опять-таки, оглядываясь на свой профессиональный опыт в качестве разработчика, тим-лида и руководителя отдела, не могу вспомнить ни одного случая организации процесса создания пользовательской документации. Даже простейший Release Notes обычно не готовился, потому что всегда была огромная очередь задач и отвлекаться на то, чтобы снабдить систему простейшей справкой или инструкцией — непозволительная роскошь. А откуда очередь задач? Правильно, см. п. 1 моего списка.
Вот, в общем-то и всё. «Так просто?» — спросит придирчивый читать. Да, именно так! Оговорюсь, что в крупных компаниях с большими командами разработки мне, к сожалению, до текущего места работы поработать не удалось, и все эти истины постигались на личном горьком опыте внедрения одной распространённой платформы из жёлтой коробочки (об этом кстати есть ещё интересные наблюдения). Когда программисты, ругая пользователей, писали ночами код. Когда внедренцы, при помощи магии и чьей-то матери доказывали пользователям, что вот это вот решение — это именно то, что они хотели, ведь «вот, смотрите, у меня на бумажке написано». И каждый раз, получая новый запрос на доработку, приходилось придумывать что хочет пользователь, и пытаться оградить его от всех граблей, на которые этот самый мифический пользователь может наступить.
Буду рад, если кто-то всё-таки прочитает эту запись и поделится своим опытом.
Добавить комментарий