Хотите узнать, как создать убедительный документ о концепции и границах, который точно привлечет внимание заинтересованных лиц? В этой статье мы рассмотрим ключевые шаги по разработке бизнес-контекста, а в частности профилей заинтересованных лиц, чтобы вы могли создать документ, который не оставит равнодушными всех читателей документа.
Лозунг “Нужно срочно приступать писать код” свойственен рядовому программисту. Это конечно же понятно с вершины понимания и взглядов программистов, которые в большинстве своём являются интровертами и стремление писать сразу код обусловлено нежеланием общаться с людьми или по крайне мере сократить общение до минимума.
Но каждый раз, когда вы думаете о том, что пора начинать писать код, вспоминайте о строителях многоэтажных домов. Они ведь также, умеют выполнять необходимые (профессиональные) операции по строительству, как и вы по программированию. Но если строителю сказать на словах “мне нужен вот такой-то дом” и от щедрот даже написать пару тезисов в техническом задании на бумаге. Как считаете, будет ли этот дом устраивать его конечных пользователей, т.е. жильцов?
А давайте переформулируем вопрос: как считаете, в процессе такого строительства будет делаться упор на удобство быта в будущих квартирах или же больше на удобство для самих строителей?
Конечно же строители без должной документации будут делать так, как им удобно и в результате сдадут дом, который будет никому не нужен. А строители при этому будут негодовать со словами на устах “как же так, мы здесь применили такие инновационные и сложные подходы, а вам еще не нравится? Потому, что вы ничего не понимаете”. Узнаете себя, когда показываете свое супер-пупер приложение заказчику? 🙂
Не переживайте, я тоже был таким упертым программистом-интравертом, который просто хотел писать код и чтобы его никто не трогал. Как же я понял, что пора выбираться из зоны комфорта, которая отдаляет от меня заказчиков? Речь конечно же пойдет о понимании актуальности создания профилей заинтересованных лиц. Рассказать? Конечно же я расскажу 🙂
Когда я был молод и считал себя великим бизнесменом-теоретиком то, как и все неуспешные люди читал книги авторов, которые построили свои успешные компании. И вот однажды я наткнулся на книгу, где создатель компании Menlo Innovations по разработке ПО рассказывал о своём опыте и применяемых техниках при разработке в их компании.
Мне автор книги открыл глаза на понимание никчёмности страусиного подхода (когда прячешь голову от других в песке), который я применял все эти годы. Произошло это в той главе, где рассказывалось о введенных должностях в их организации, а в частности “антропологи высоких технологий”.
Они создали целую команду, которая проводила исследования на предмет поиска возможного поведения их потенциальных пользователей в разрабатываемом ими приложении. Уделялось внимание таким тонкостям, как возрастная группа, куда человек любит ходить, что предпочитает смотреть и т.д. В результате из этих данных собирался усредненный портрет пользователя и под него создавался пользовательский интерфейс построенные на его опыте.
Это невероятно - воскликнул я тогда в своём сознании и попробовал применить это на практике. Тогда я столкнулся с тем, что я ничего не знаю о пользователях, для которых разрабатываю ПО. Речь не о знакомстве лично, а об их портрете. Я создавал приложение для заказчика, а не для пользователя, в этом и крылась основная проблема неудачных интеграций и непониманий в лице рядовых пользователей.
В данной статье я не буду рассказывать, как стать антропологом высоких технологий, но покажу важность применения такого навыка при разработке требований. В частности нас сегодня интересует следующий раздел документа о концепции и границах “Бизнес-контекст”, в котором мы посвятим внимание первому подразделу “Профили заинтересованных лиц”. Если вы сразу попали на эту статью и не читали остальные из цикла разработки требований, то обязательно начните с первой.
Профили заинтересованных лиц
Со временем вы начнете понимать, что в каждом новом проекте нужно при разработке требований более плотно работать с конечными пользователями и избегать ограничений заказчика.
Обычно заказчик является владельцем фирмы или руководителем, т.е. тем, кто будет в итоге подписывать документы на выплаты по реализованному вами проекту. Они редко работают с информационной подсистемой, которая будет использоваться в организации, т.к. их задача руководить, а не стоять у станка (это образно).
Поэтому в их представлении нужно быстро заключить сделку и приступать к разработке, чтобы не тратить лишнее время и деньги. Исходя из этих соображений они все меньше стараются подпускать вас к своим сотрудникам, которые являются конечными пользователями, чтобы не тратить время в пустую (по их мнению).
Этот щит обязательно вам нужно пробить и объяснить, что разработка требований может быть успешной лишь тогда, когда вы понимаете с какими болями сталкиваются их сотрудники. Тогда и продуктивность работников возрастет, т.к. произойдет актуальная оптимизация и им не придется делать бессмысленные операции, что принесет косвенный экономический эффект.
Обычно любая форма упоминания денег влечет за собой успех в переговорах с такой группой лиц. 🙂
Пообщавшись с пользователями вы должны категоризировать их по группам заинтересованных лиц, описать признаки по каждой категории и описать характеристику признаков.
Оформлять в документе это необходимо в форме таблицы. Описание признаков состоит из трех составляющих:
- Основная ценность или преимущество, которое принесет разрабатываемый продукт для этой категории;
- Вероятное отношение к продукту этой категории пользователей;
- Самые важные функции и характеристики для этой группы;
- Все известные ограничения, которые должны быть соблюдены для данной группы.
Касательно последнего пункта, здесь имеются ввиду ограничения, которые описывались в предыдущем разделе “Ограничения и исключения”. Мы рассматривали его в прошлой статье.
Давайте начнем с того, что в первую очередь вы объясняете читателям документа “что это и для чего оно нужно”.
Теперь посмотрим, как должна выглядеть шапка таблицы.
В рамах нашего проекта мы имеем всего две категории пользователей, это руководитель и сотрудники. Предлагаю заполнить в первую очередь категорию сотрудников.
Прошу обратить внимание на второй признак “Вероятность отношения к продукту” - это единственный пункт, в котором необходимо характеристику заполнять по структуре. В частности есть три характера для каждого признака:
- Положительное отношение;
- Отрицательное отношение;
- Нейтральное отношение.
Принцип заполнения заключается в том, что нужно описывать эти три пункта. Но как видите, не для всех категорий пользователей подходит каждый пункт. Например, для категории сотрудников не используется пункт положительно.
Описываемый проект достаточно мал, поэтому здесь всего две категории лиц, которые взаимодействуют с подсистемой. Однако имея такую таблицу в документе о концепции и границах, вы подстраховывайте себя от ошибок при разработке, которые могут не охватить того или иного события и доставить ряд негативных эмоций для конечных пользователей.
Самое страшное, это когда ваша разработанная программа, над которой вы работали долгое время не улучшает старого способа ведения дел, а настоящий ад выражается в том, что она делает еще хуже. Поэтому понимание болей конечных пользователей оберегает вас от совершения непоправимых ошибок при разработке.
Если ты хочешь получать жизненно важную информацию для разработчика, то обязательно подписывайся на канал. А если тебе понравилась статья, то ставь лайк, я буду признателен.
Спасибо за прочтение!
