В дополнение к описанным выше навыкам и личным качествам, аналитику требований требуются обширные знания, большая часть которых приобретается с опытом. Попробуйте понять современные способы создания требований и научитесь применять их на каждом этапе разработки ПО. Эффективный аналитик владеет широким спектром средств и знает когда их стоит использовать, а когда — нет.
Аналитик контролирует требования и управляет проектом на протяжении всего цикла его разработки. Аналитик, знающий тонкости управления проектом и рисками, а также понимающий методы обеспечения качества продукции, не допустит провала проекта из-за проблем, возникающих на этапе формулирования требований. В области коммерческой разработки ПО аналитику полезно знать концепции управления продуктом и основы позиционирования и разработки корпоративного ПО.
Становление аналитика
Знание предметной области — ценное качество для эффективного аналитика. Аналитику, разбирающемуся в бизнесе, легче общаться с клиентами и понимать их, ему удается выявить невысказанные предположения и неявные требования. Он может предложить варианты совершенствования бизнес-процессов, а также ценную функциональность, о которой пользователи даже не думали.
Великих аналитиков взращивают, а не обучают. Для работы аналитиком требуется множество личностных черт, а не знаний каких-либо технологий. Стандартного обучающего курса или описания обязанностей такого специалиста не существует. В аналитики приходят из разных профессий, и, скорее всего, у всех новичков есть пробелы в знаниях и навыках. Тому, кто собирается заниматься этим делом, следует определить, какие именно из обсуждаемых в этой главе требований относятся к нему, и постараться активно восполнить пробел, чтобы первоклассно выполнить работу. Патриция Фердинанди (Patricia Ferdinandi) (2002) описывает требования к профессиональному уровню начинающего, опытного и ведущего аналитика требований в разных областях: практический опыт, разработка, управление проектами, средства и способы, качество и личностные характеристики. Аналитику-новичку пригодятся советы и наставления опытных коллег, выраженные, скажем, в форме обучения. Давайте посмотрим, как люди с разным профессиональным опытом становятся аналитиками.
Бывший пользователь
Во многих корпоративных отделах информационных технологий есть сотрудники, пришедшие в бизнес-аналитики из обычных пользователей. Они отлично понимают особенности бизнеса и рабочей среды и легко завоевывают доверие бывших коллег. Они знают язык пользователей, а также существующие системы и бизнес-процессы.
К сожалению, бывшие пользователи зачастую имеют весьма поверхностные знания о разработке ПО и взаимодействии с техническими специалистами. Если они не знакомы с методами моделирования анализа, то по привычке выражают всю информацию в текстовой форме. Пользователям, ставшим аналитиками требований, следует побольше выяснить о технической стороне разработки ПО, чтобы представлять информацию в наиболее подходящей для разных аудиторий форме. Некоторые бывшие пользователи считают, что они лучше, чем те, кто работает с ПО теперь, понимают, что на самом деле необходимо, и поэтому не обращаются к этим сотрудниками или неуважительно от носятся к информации, предоставленной теми, кто будет работать с новой системой. Недавние пользователи могут запутаться в текущих особенностях работы, да так, что не увидят возможности усовершенствовать бизнес-процессы посредством новой информационной сие темы. Еще одна опасность: бывший пользователь может запросто думать о требованиях только с точки зрения пользовательского интерфейса. Концентрация внимания на вариантах решения с самого начала создает ненужные ограничения архитектуры и зачастую не позволяет устранить реальную проблему.
| От специалиста по медицинской технике к аналитику требований У старшего менеджера отдела медицинских устройств в большой компании возникла проблема. «Два года назад я принял на работу в свой отдел трех специалистов по медицинскому оборудованию, чтобы те представляли потребности наших клиентов. Они проделали огромную работу, но уже не владеют особенностями современных медицинских технологий и поэтому не могут точно сказать, что же сегодня нужно клиентам. Какую работу мы можем предложить этим специалистам теперь?» Бывшие специалисты по медицинскому оборудованию, работающие под началом этого менеджера могут стать кандидатами в аналитики требований. И хотя они не знают о новинках медицинской техники, они смогут общаться на одном языке с другими специалистами в этой области. За два года они усвоили принципы работы отдела. Возможно, им потребуется пройти обучение способам документации требований, тем не менее они накопили ценный опыт, который позволит им эффективно выполнять работу аналитиков. |
Бывший разработчик
Менеджеры проекта, которым не хватает профессионального аналитика требований, зачастую ожидают, что его функции будет выполнять разработчик. К сожалению, навыки и личные качества, необходимые разработчику, отличаются от тех, что необходимы аналитику. Шаблонный «компьютерщик» — не самый социально приятный из людей. Мало кто из разработчиков терпелив с пользователями, считая их необходимым злом, с которым нужно разобраться как можно быстрее, чтобы скорее вернуться к реальной работе — программированию. Конечно многие разработчики осознают важность процесса создания требований и высказывают желание работать аналитиками, когда потребуется. Те, кому нравится общаться с пользователями — хорошие кандидаты для специализации в области анализа требований.
Разработчику, ставшему аналитиком, вероятно, придется более подробно ознакомиться с предметной областью бизнеса. Однако разработчики легко переходят на техническое мышление и жаргон, концентрируясь вместо потребностей пользователей на программном продукте, который надо создать. Им будет полезно дополнительное обучение в области межличностных коммуникаций, которыми искусно владеют лучшие аналитики — умение эффективно слушать, вести переговоры и создавать комфортные условия общения.
Профильный специалист
Ralph Young (2001) рекомендует, чтобы аналитик требований был экспертом в предметной области или профильным специалистом, а не обычным пользователем: «Спецификация требований к ПО может определить, насколько разумны требования, как они расширяют существующую систему, как следует проектировать предполагаемую архитектуру и какое влияние они окажут на пользователей». Некоторые организации-разработчики ПО нанимают опытных пользователей их продуктов, обладающих большим опытом в предметной области, в качестве аналитиков или представителей пользователей.
Аналитик требований, будучи экспертом в предметной области, зачастую определяет требования к системе, которые соответствуют его личным предпочтениям, а не обоснованным потребностям различных классов пользователей. Иногда профильные специалисты увлекаются созданием универсальной, всеобъемлющей системы, когда на самом деле большую часть потребностей пользователей удовлетворит менее сложное решение. Зачастую лучше, чтобы аналитик требований из команды разработчиков взаимодействовал с профильным специалистом, который кроме того выбран в качестве ключевого представителя пользователей (сторонника продукта). Подробнее о роли сторонников продукта в разработке проекта — в главе 6.