Анна Федорова - Откровения модераторши

Теперь выделяем кандидатов в требования. Находим описания похожих функций и детализируем их до такого состояния, когда становится понятно, что является общим случаем, что – частным. Если не хватает описаний каких-то частных случаев, уточняем их у клиента. Последовательно проходим все сценарии развития событий. Устраняем дубликаты.

Готовые болванки начинаем обтачивать напильником. Добиваемся непротиворечивости формулировок и ситуации, когда каждое требование упоминается в ТЗ только один раз.

Когда все лишнее отпилили, можно заняться дизайном . Я строю ТЗ следующим образом: сначала очень сжатое описание всех функций, а потом по разделу на каждую группу родственных функций, где они описываются детально. Важно найти базовый принцип, на основании которого устанавливается родство. Скажем, если некая система печатает отчеты в файлы MS Excel, получает данные из системы 1С и отправляет смс-сообщения, то все три функции будут являться частными случаями обмена с внешними системами. Объединяет их как минимум необходимость шлюза и согласованности форматов между обменивающимися системами. Аналогично все требования к отображаемым меню и экранным формам объединяются в раздел, где описываются требования к дизайну.

Я употребляю это слово в значении «человек, зарабатывающий на жизнь определенным занятием» (в котором он и будет профессионалом). Есть также значение «опытный и квалифицированный специалист». Признавая его право на существование, я тем не менее почти им не пользуюсь. Есть еще слово «любитель», которым обозначают человека, занимающегося чем-то, что не дает ему средств к существованию. При этом не обязательно не дает вообще ни копейки – просто доход от этого занятия настолько мал, что не позволяет содержать себя, и чаще всего у этого человека есть другие источники дохода. Объясняю все это для того, чтобы было ясно, о чем пойдет речь в дальнейшем. Да, по моему мнению, будь вы хоть четырежды гением и с пяти лет кодить с закрытыми глазами – если написание кода вас не кормит, значит, вы в нем только любитель.

Я часто учу других тому, как общаться с заказчиками, а сегодня мне захотелось присоединиться к заказчикам и рассказать им о том, как можно общаться с аналитиками, чтобы быстрее и радостнее достичь взаимопонимания.

Терпение – ваша самая сильная черта. Представьте себе, что вы общаетесь с детьми. В определенном возрасте дети задают много вопросов, в том числе о том, что для вас очевидно. Порой из-за этого вы не знаете, как им объяснить ту или иную вещь. Грамотный аналитик будет вести себя примерно так же. Делается этого не потому, что аналитик сам не может ответить на эти вопросы, а потому, что крайне важно получить именно ваш взгляд на проблему, понять, что для вас имеет значение. Для другого заказчика будет иметь значение что-то другое, для разработчика – третье, и так далее. Чем более полное представление будет у аналитика, тем лучше конечный продукт будет соответствовать вашим потребностям (порой даже тем, о которых вы не догадывались). То есть – нужно готовиться к тому, чтобы отвечать на разные вопросы, иногда банальные, иногда не один раз. И обратно – если аналитик почти не задает вопросов, тут определенно что-то не так.

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

Согласование терминологии . В любой отрасли есть своя профессиональная терминология (речь в данном случае идет не о жаргоне – см. выше). Хорошая практика – в начале беседы определить основные понятия, которыми вы будете оперировать. То есть, объяснить, что под ними подразумевается именно в вашем бизнесе или сфере деятельности. В дальнейшем, когда вы будете использовать эти понятия, аналитику сразу станет ясно, о чем идет речь. Это необходимо по той причине, что в разных отраслях одними и теми же словами могут называть разные вещи, вплоть до использования внутренней терминологии в масштабах одного предприятия. Заказчик не всегда сталкивается с этим, так как работает только в своей сфере, но у аналитика, имеющего дело со многими заказчиками из разных отраслей, часто возникают вопросы в области терминологии.

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

В процессе работы над следующим семинаром пришла к мысли, что лично мне было бы проще провести, скажем, три курса по UML, чем один – по анализу требований. Инструменты преподавать вообще очень легко, будь то ПО или стандарт моделирования. Именно потому, что простор для импровизации минимальный – все уже кем-то описано, разложено по полочкам, – отыгрываешь, как пьесу по нотам. И аудитория лучше воспринимает такие вещи – тот же UML уже примелькался, в возможность его практического применения уже поверили, но пока еще не все поняли, что без правильного подхода он бесполезен. А подход как раз лежит в другой области.

Той, которую преподать труднее.

Исторически сложилось так, что с методами структурного анализа и проектирования я в практической деятельности не сталкивалась. Для общего образования, конечно, изучала. Наверное, есть случаи, когда эти методы оптимальны. Но для меня оптимальным, или лучше сказать – естественным, – является объектный подход. Далеко не сразу это стало очевидно.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.