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