Knig Fu: 116 страниц об управлении требованиями (вам потребуется прочитать еще меньше)
Привет! В постновогодний обзор литературы для аналитиков мы решили включить одну из самых ёмких и доступных книг по управлению требованиями - книгу Ильи Корнипаева. Ее можно часто встретить в подборках материалов для аналитиков.
В статье отвечаем на вопросы, кому и зачем ее стоит читать в 2024, а также публикуем небольшое саммари по книге :)
Вопрос: что это за книга?
Полное название книги: “Требования для программного обеспечения: рекомендации по сбору и документированию” автор Илья Корнипаев. Автор имеет 15+ лет проектного опыта, а также разрабатывает и проводит авторские курсы по управлению требованиями.
Эта книга достаточно хорошо известна в кругах аналитиков, многие компании используют ее для обучения своих сотрудников.
В книге автор раскрывает, что из себя представляет управление требованиями, начиная с того, какие требования бывают, и заканчивая их согласованием с командой.
Я нарисовала небольшую майнд-карту по содержимому книги, которую можно использовать, чтобы понять, стоит ли читать, а также шпаргалку по работе с требованиями на ваших проектах:
Вопрос: кому и зачем читать?
Если собрать все отзывы на книгу в один комментарий, то это было бы “норм для джунов”. Действительно, книга точно была бы полезна начинающим аналитикам в том, чтобы больше узнать про работу с требованиями и устроиться на первую работу.
Объем книги небольшой, поэтому вы прочитаете ее быстро, поймете ценность работы аналитиков, узнаете, из чего состоит процесс управления требованиями, и сможете подискутировать по вопросу: “А какой способ сбора требований вы бы выбрали в такой ситуации?” (мы такое спрашиваем).
Я же порекомендовала бы прочитать/перечитать ее не только джунам, но и аналитикам, которые работают в небольших компаниях без выстроенных методологий, чтобы как минимум структурировать свои знания, а как максимум внедрить общепринятые технологии в своих компаниях, внедрить единый формат описания требований.
Ну и конечно, книга может оказаться полезной наставникам и тим-лидам и использоваться как рекомендуемая литература при обучении ваших новичков.
Если же вы опытный аналитик, да еще и прочитали классику “Путь аналитика” и аналогичные, то для вас новой информации почти не будет.
Вопрос: тебе понравилась книга?
Моя оценка: 5/5, и вот 5 причин на это:
1. Книга хорошо структурирована и представляет собой полноценное руководство в стиле “бери и делай”.
2. Автор не просто делится методологией, а рассказывает о деталях, к которым приходишь только на личном опыте, например, как правильно сесть на интервью или как говорить о трудностях:
Еще одно важное свойство бумаги может вам пригодиться если речь пойдет о проблемах. О проблемах всегда говорить неприятно, и если вы говорите о проблемах человеку в лицо, он подсознательно начинает думать, что вы рассматриваете его как источник возникновения этих проблем. Когда между вами лежит листок бумаги, вы можете, обсуждая проблемы, рисовать или писать что-то на этом листке, глядя, соответственно, на него, таким образом перенося проблемы на этот листок. Тогда проблема, будучи записанной или схематично зарисованной на листке бумаги, будет находиться перед вами на столе, и вы с вашим собеседником как сторонние наблюдатели можете ее спокойно вместе обсудить. Я называю такой прием «громоотвод».
3. Мне всегда импонируют люди, которые являются фанатами своего дела. В книге транслируется отношение автора к работе аналитика, а именно эту информацию редко встречаешь в профессиональной литературе:
Другой важный фактор при общении между людьми - это уважение. Я искренне убежден в том, что понимание людей невозможно без уважения к ним. Уважение складывается из нескольких составляющих: это и знание бизнеса заказчика, это и понимание его культуры и традиций, это и, несомненно, бережное отношение к чужому времени.
4. На своих первых проектах я часто задавалась вопросами: “как понять глубину проработки требований”, “как определить всех заинтересованных сторон”, “что делать, если они сами не знают, как должно быть” и тд. На все эти вопросы нет универсального готового ответа, но автор делится своими вариантами решения таких вопросов и указывает, на что можно ориентироваться, чтобы понять, правильное решение ли ты принимаешь.
Критерий достижения оптимальной проработки требований тут можно сформулировать так: людей, которые должны работать с этим документом, не пугает его объем, и в то же время они находят в документе все необходимые детали для того, чтобы сделать свою работу: представители заказчика - для согласования документа, разработчики - для разработки системы, тестировщики - для разработки и выполнения тестов. Поэтому имеет смысл как можно раньше обсуждать требования с заказчиками, разработчиками и тестировщиками, чтобы понять, какая глубина проработки требований для них комфортна.
5. Книга читается очень легко и содержит интересные примеры из опыта индустрии и практики автора:
В свое время в среде программистов ходила шутка: «Рано или поздно интерфейс любой программы, которую мы делаем, становится похож на Visual Studio». Человек, проектируя систему, хочет сделать ее удобнее для пользователя, а если реального пользователя рядом нет, то он начинает ее делать удобной для себя. Поскольку программист привык работать в среде разработки и считает ее удобной, то и интерфейс любой программы, которую он разрабатывает, без должного контроля со стороны может очень скоро стать похожим на интерфейс среды разработки.
Ну и моя любимая цитата из книги:
Для того чтобы добиться успеха, необходимо прилагать усилия. Работа аналитика - это всегда творческий труд.
Достаточно сложно представить себе ситуацию, когда работа аналитика превратилась в рутину, не требующую от него включения в работу головы, поэтому на каждом проекте, на каждой задаче аналитик должен прилагать усилия для того, чтобы помочь своей команде добиться хорошего результата. На мой взгляд, простая фиксация того, что требует заказчик, в формальном документе просто недопустима. Если вы не готовы постоянно прилагать усилия, работа аналитика не для вас.
Вопрос: где найти?
Печатается по запросу. Заказать экземпляр можно на маркет-плейсах, недавно видела на Озон. В электронном виде не встречала.
Вопрос: что еще почитать на эту тему?
Список литературы из самой книги:
- Alexander I. F., Stevens R., and Alexander I. Writing Better Requirements. Massachusetts: Addison Wesley Longman, Inc., 2002.
- Hull E., Jackson K., Dick J. Requirements Engineering - 2nd ed. London: Springer, 2005. Перевод на русский язык - Элизабет Халл, Кен Джексон, Джереми Дик. Разработка и управление требованиями. Второе издание (сетевая публикация).
- Leffingwell D., Widrig D. Managing software requirements: a use case approach - 2nd ed. Boston: Addison Wesley, 2003. Перевод на русский язык первого издания книги - Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. 2002 г., Вильямс.
- Cockburn A. Agile Software Development: Addison-Wesley Professional, 2001. Перевод на русский язык - Алистер Коберн. Быстрая разработка программного обеспечения. 2002 г., Лори.
- Юрий Булуй. Классификация требований к программному обеспечению и ее представление в стандартах и методологиях. Доклад на конференции SEC-R 2006 (сетевая публикация).
- Maiden N. Using Creativity Techniques in Requirements Processes: A Step-by-Step Process. Выступление на конференции Software People 2011.
- Кент Бек. Экстремальное программирование. Библиотека программиста. - СПб: Питер, 2002.
А еще много полезного в нашем телеграм-канале Кунг Фу аналитика :)