В 2018-м году переиздали книгу «Разработка требований к программному обеспечению». Коллеги прислали мне ссылку на издание. Авторы добавили приёмы для работы в agile-проектах, определение роли аналитика и рекомендации по автоматизации. В Сети ходят крайне противоречивые отзывы. Заказал книгу и разобрался в вопросе.
Книга станет ценным ресурсом как для новичков, которые получат полное представление о работе аналитика, так и для опытных специалистов, которые смогут освежить свои знания и вспомнить о нюансах работы.
В ней детально рассмотрены все этапы создания спецификаций, а в приложении Б представлено пособие, построенное по принципу «проблема – решение». Само оглавление книги выполняет роль подсказки.
Практически в каждой главе представлены подробные чек-листы. Например, шаблон спецификации включает 8 пунктов, 24 подпункта и два приложения, что делает данное руководство действительно исчерпывающим.
Книга отличается четкой структурой, что делает поиск информации максимально удобным. Девятистраничное оглавление позволяет быстро найти нужный этап проекта и получить необходимые пояснения. В каждой главе есть ссылки на другие разделы, где более подробно рассматриваются определенные вопросы.
В конце руководства представлен словарь терминов, благодаря которому не стоит бояться встретить непонятные слова, такие как «UML», «водопадный жизненный цикл проекта» или «CRUD-матрица».
Для удобства также можно найти PDF-версии предыдущих изданий, где можно воспользоваться функцией поиска по документу, чтобы найти нужные данные.
Аналитики играют важную роль в проекте, взаимодействуя с каждым участником: заказчиками, дизайнерами, разработчиками, тестировщиками, сотрудниками продаж, специалистами поддержки и пользователями продукта. Всем им необходимо понимать, как техническое задание соотносится с их работой.
Например, начинающий сотрудник может задать вопрос: «Где в техническом задании написано, что при нажатии на этот элемент ничего не должно происходить?» (реальный случай). Чтение соответствующей документации поможет ему самостоятельно найти ответы на подобные вопросы и обоснованно комментировать документ.
Поначалу читать руководство может быть сложно, но после 700-ой страницы становится легче :) У каждого понятия в скобках приводится его оригинальное название на английском языке. Это удобно, так как переводчик не всегда точен, и можно проверить значение в англоязычной Википедии. В конце книги есть словарь терминов с пояснениями. Правда, там не все понятия, которые встречаются в руководстве. Чтобы дополнить список, пришлось вручную добавить 50 новых фраз и указать номера страниц.
Авторы злоупотребляют длинными предложениями и лишней информацией. Из-за этого смысл уловить сложнее.
Иногда неожиданно встречаются философские категории времени и пространства.
Нередки лишние повторы.
Пояснение, что данные также называют информацией, на мой взгляд, лишнее.
Похожий смысловой шум попадается почти на каждой странице. Приходится абстрагироваться от него.
В процессе чтения я обнаружил более 160 ошибок, которые легко исправить, зная школьную программу русского языка. В тексте встречаются пропущенные слова, неправильное употребление окончаний ("-тся" вместо "-ться"), дублирование предложений в одном абзаце, банальные опечатки, пропущенные запятые и путаница в написании похожих по звучанию слов.
Первая ошибка встречается, как только открываешь книгу. Крис Вигерс якобы посвящает книгу себе. В английском оригинале ей посвящает книгу Карл – они супруги.
В этой фразе не до конца понятно, что хотят сказать авторы:
Похожие неточности оставляют противоречивое впечатление от книги.
По ходу изложения авторы неоднократно упоминают продукты Microsoft (книгу выпускала Microsoft Press). Но когда надо назвать системы управления требованиями (СУТ), авторы о них умалчивают. Связано ли это с тем, что у Microsoft нет полноценной СУТ, я не знаю, но упомянуть о них было бы полезно.
Например, в приложении «В» авторы приводят пример документации требований. Они пишут, что клиенты должны иметь возможность изменять подписки, но не сказано про создание подписок. Можно ли изменить то, что ещё не создано? Пропущен начальный этап.
Остальные этапы прописаны в приложении довольно детально. На их фоне пропущенные звенья вызывают вопросы.
Перед прочтением размышлял, а что люди из другой страны могут нам посоветовать. У них своя специфика. Выяснилось, что проблемы одинаковые и способы их решения примерно те же.
Один знакомый тим-лид часто говорил мне: «Я не читаю ТЗ, а сразу пишу код». Что при таком подходе получается в итоге? Реализация не согласовывается с заказчиками, не прорабатываются дополнительные варианты, упускаются из виду связи с другими элементами, увеличивается риск ошибки и её цена. Если пользователь обнаруживает ошибку после релиза, то её цена возрастает в разы. Это бьёт по кошельку и престижу компании.
Бизнес-требования (business requirements) описывают, почему организации нужен системный подход. Если посмотреть на средние российские компании, то многое зависит не от системности, а от воли конкретных руководителей. Если они уходят и уводят команду с собой, проекты теряют важные компетенции.
Так поступать недальновидно, потому что в случае редизайна приходится править ТЗ. Это лишняя работа. Лучше описывать в ТЗ функции и схемы, а дизайнерам оставлять выбор, как реализовать требования. Например, обозначить «Удалить» не как кнопку, а как элемент, потому что его можно представить в виде кнопки, иконки, ссылки, смахивания или пункта меню.
Видел, как в одной компании аналитикам поручили обязанности менеджера проекта: отслеживать реализацию требований, выявлять причины задержек, координировать действия разных отделов. В итоге страдала сама аналитическая работа. Не было понимания, что аналитик отвечает за требования, а менеджер – за проект.
Вспоминаю, как знакомый руководитель хотел, чтобы сотрудники, работающие с ТЗ, знали их все наизусть. Это невозможно. В компании несколько десятков ТЗ, и их количество постоянно растет. Даже если ты сам составил ТЗ месяц назад, ты все равно его забудешь, так как потом погружаешься в работу над 2-3 новыми. Что уж говорить о непосредственных исполнителях! Проблема решается не за счет памяти, а за счет внедрения систем управления требованиями (СУТ). Они поддерживают выявление, управление, отслеживание и вывод требований. Однако за них нужно платить, и работодатели предпочитают работать по старинке.
Post Scriptum
Я обратился к издателям русского варианта книги с предложением исправить обнаруженные ошибки. К сожалению, мой запрос остался без ответа. Похоже, издательство не считает ошибки критичными, что очень печально, учитывая высокое качество оригинальной книги.
Книга оставляет противоречивое впечатление из-за своей небрежности. Содержание на высоком уровне, а форма оставляет желать лучшего. Это может отпугнуть. Однако, если специалист стремится стать успешным аналитиком, ему придётся приложить усилия и понять, что хотели сказать авторы. Это нелегко, но потраченное время того стоит, и вы будете уважать себя больше за проделанную работу.
Плюсы
Расписано всё
Книга станет ценным ресурсом как для новичков, которые получат полное представление о работе аналитика, так и для опытных специалистов, которые смогут освежить свои знания и вспомнить о нюансах работы.
В ней детально рассмотрены все этапы создания спецификаций, а в приложении Б представлено пособие, построенное по принципу «проблема – решение». Само оглавление книги выполняет роль подсказки.
Практически в каждой главе представлены подробные чек-листы. Например, шаблон спецификации включает 8 пунктов, 24 подпункта и два приложения, что делает данное руководство действительно исчерпывающим.
Легко найти информацию
Книга отличается четкой структурой, что делает поиск информации максимально удобным. Девятистраничное оглавление позволяет быстро найти нужный этап проекта и получить необходимые пояснения. В каждой главе есть ссылки на другие разделы, где более подробно рассматриваются определенные вопросы.
В конце руководства представлен словарь терминов, благодаря которому не стоит бояться встретить непонятные слова, такие как «UML», «водопадный жизненный цикл проекта» или «CRUD-матрица».
Для удобства также можно найти PDF-версии предыдущих изданий, где можно воспользоваться функцией поиска по документу, чтобы найти нужные данные.
Для всех, кто в ИТ
Аналитики играют важную роль в проекте, взаимодействуя с каждым участником: заказчиками, дизайнерами, разработчиками, тестировщиками, сотрудниками продаж, специалистами поддержки и пользователями продукта. Всем им необходимо понимать, как техническое задание соотносится с их работой.
Например, начинающий сотрудник может задать вопрос: «Где в техническом задании написано, что при нажатии на этот элемент ничего не должно происходить?» (реальный случай). Чтение соответствующей документации поможет ему самостоятельно найти ответы на подобные вопросы и обоснованно комментировать документ.
Пояснения терминов
Поначалу читать руководство может быть сложно, но после 700-ой страницы становится легче :) У каждого понятия в скобках приводится его оригинальное название на английском языке. Это удобно, так как переводчик не всегда точен, и можно проверить значение в англоязычной Википедии. В конце книги есть словарь терминов с пояснениями. Правда, там не все понятия, которые встречаются в руководстве. Чтобы дополнить список, пришлось вручную добавить 50 новых фраз и указать номера страниц.
Минусы
Многословие
Авторы злоупотребляют длинными предложениями и лишней информацией. Из-за этого смысл уловить сложнее.
«Средства управления требованиями помогают отслеживать требования, давая возможность определять связи между различными типами требований, между требованиями в различных подсистемах и между отдельными требованиями и связанными системными компонентами (например, дизайном, модулями кода, тестами и пользовательской документацией)».
Иногда неожиданно встречаются философские категории времени и пространства.
«… методы общения могут обеспечить эффективную синхронизацию во времени и пространстве внутри команды».
Нередки лишние повторы.
«Диаграмма состояний для состояния заказов блюд».
Пояснение, что данные также называют информацией, на мой взгляд, лишнее.
«Стивен Уитхолл (Stephen Withall, 2007) описывает много схем для точного документирования данных (которые также называют информацией)».
Похожий смысловой шум попадается почти на каждой странице. Приходится абстрагироваться от него.
Грамматические ошибки
В процессе чтения я обнаружил более 160 ошибок, которые легко исправить, зная школьную программу русского языка. В тексте встречаются пропущенные слова, неправильное употребление окончаний ("-тся" вместо "-ться"), дублирование предложений в одном абзаце, банальные опечатки, пропущенные запятые и путаница в написании похожих по звучанию слов.
Первая ошибка встречается, как только открываешь книгу. Крис Вигерс якобы посвящает книгу себе. В английском оригинале ей посвящает книгу Карл – они супруги.
В этой фразе не до конца понятно, что хотят сказать авторы:
«Перепроектировать систему для более качественной обработки изменчивых бизнес-правил, которые был сложны проект поддержке».
Похожие неточности оставляют противоречивое впечатление от книги.
Product placement
По ходу изложения авторы неоднократно упоминают продукты Microsoft (книгу выпускала Microsoft Press). Но когда надо назвать системы управления требованиями (СУТ), авторы о них умалчивают. Связано ли это с тем, что у Microsoft нет полноценной СУТ, я не знаю, но упомянуть о них было бы полезно.
Недосказанность
Например, в приложении «В» авторы приводят пример документации требований. Они пишут, что клиенты должны иметь возможность изменять подписки, но не сказано про создание подписок. Можно ли изменить то, что ещё не создано? Пропущен начальный этап.
Остальные этапы прописаны в приложении довольно детально. На их фоне пропущенные звенья вызывают вопросы.
Что актуально для России?
Перед прочтением размышлял, а что люди из другой страны могут нам посоветовать. У них своя специфика. Выяснилось, что проблемы одинаковые и способы их решения примерно те же.
Нет культуры уважения к требованиям
Один знакомый тим-лид часто говорил мне: «Я не читаю ТЗ, а сразу пишу код». Что при таком подходе получается в итоге? Реализация не согласовывается с заказчиками, не прорабатываются дополнительные варианты, упускаются из виду связи с другими элементами, увеличивается риск ошибки и её цена. Если пользователь обнаруживает ошибку после релиза, то её цена возрастает в разы. Это бьёт по кошельку и престижу компании.
Не формализуются бизнес-требования
Бизнес-требования (business requirements) описывают, почему организации нужен системный подход. Если посмотреть на средние российские компании, то многое зависит не от системности, а от воли конкретных руководителей. Если они уходят и уводят команду с собой, проекты теряют важные компетенции.
«Привязываются» к дизайну
Так поступать недальновидно, потому что в случае редизайна приходится править ТЗ. Это лишняя работа. Лучше описывать в ТЗ функции и схемы, а дизайнерам оставлять выбор, как реализовать требования. Например, обозначить «Удалить» не как кнопку, а как элемент, потому что его можно представить в виде кнопки, иконки, ссылки, смахивания или пункта меню.
Нет понимания специфики работы аналитика
Видел, как в одной компании аналитикам поручили обязанности менеджера проекта: отслеживать реализацию требований, выявлять причины задержек, координировать действия разных отделов. В итоге страдала сама аналитическая работа. Не было понимания, что аналитик отвечает за требования, а менеджер – за проект.
Не используется инструментарий
Вспоминаю, как знакомый руководитель хотел, чтобы сотрудники, работающие с ТЗ, знали их все наизусть. Это невозможно. В компании несколько десятков ТЗ, и их количество постоянно растет. Даже если ты сам составил ТЗ месяц назад, ты все равно его забудешь, так как потом погружаешься в работу над 2-3 новыми. Что уж говорить о непосредственных исполнителях! Проблема решается не за счет памяти, а за счет внедрения систем управления требованиями (СУТ). Они поддерживают выявление, управление, отслеживание и вывод требований. Однако за них нужно платить, и работодатели предпочитают работать по старинке.
Post Scriptum
Я обратился к издателям русского варианта книги с предложением исправить обнаруженные ошибки. К сожалению, мой запрос остался без ответа. Похоже, издательство не считает ошибки критичными, что очень печально, учитывая высокое качество оригинальной книги.
Заключение
Книга оставляет противоречивое впечатление из-за своей небрежности. Содержание на высоком уровне, а форма оставляет желать лучшего. Это может отпугнуть. Однако, если специалист стремится стать успешным аналитиком, ему придётся приложить усилия и понять, что хотели сказать авторы. Это нелегко, но потраченное время того стоит, и вы будете уважать себя больше за проделанную работу.
