Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Совершенное программное обеспечение невозможно создать без изучения накопленного опыта. Опыт — главный учитель, но медленный и нередко болезненный. Но зачем же нам повторять ошибки? Книга «Жемчужины разработки» поможет совершенствоваться быстрее и избежать многих проблем, обучаясь на опыте других людей, которые уже поднялись по кривой обучения. Карл Вигерс сформулировал 60 кратких практических уроков, которые подойдут для любых проектов, независимо от роли, отрасли, технологии или методологии. Идеи и конкретные рекомендации охватывают шесть важнейших элементов успеха: требования, дизайн, управление проектами, культуру и командную работу, качество и совершенствование процессов. Для каждого из направлений Вигерс предлагает «первые шаги», позволяющие осмыслить собственный опыт, уроки с основными идеями, реальными примерами и действенными решениями и «следующие шаги» для внедрения опыта в вашем проекте, команде или организации. Эти знания нельзя получить в университете!
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 449
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик Л. Киселева
Карл Вигерс
Жемчужины разработки. Чему мы научились за 50 лет создания ПО. — СПб.: Питер, 2024.
ISBN 978-5-4461-1986-8
© ООО Издательство "Питер", 2024
Оглавление
Как всегда, посвящается Крис
Отзывы о книге
«Это сборник уроков, которые Карл усвоил за свою долгую жизнь и, могу честно сказать, выдающуюся карьеру. Это ретроспектива всего хорошего (и кое-чего плохого), что встретилось ему по пути. Однако это не воспоминание а-ля “в мое время было так”, а ценные советы, которые могут принести пользу любому, кто, пусть даже косвенно, связан с разработкой программного обеспечения. Данная книга удивительна. Это не просто список жемчужин мудрости. В каждом уроке Карл тщательно аргументирует и объясняет, почему то или иное важно для вас, и, что особенно ценно, показывает, как реализовать теорию на практике».
Джеймс Робертсон (James Robertson), автор книги Mastering the Requirements Process
«Было бы здорово получать жизненный опыт в самом начале карьеры, когда он особенно необходим, не расплачиваясь за неизбежные ошибки, возникающие в ходе обретения собственного опыта. Более полувека Карл Вигерс (Karl Wiegers) проработал консультантом в сфере разработки и управления программным обеспечением, и его часто приглашали исправить неудачи других людей. В своей книге “Жемчужины разработки” Карл описывает наиболее распространенные и вопиющие ошибки, с которыми он сталкивался. Любому разработчику полезно знать, где таятся самые серьезные проблемы и какие ошибки люди продолжают повторять снова и снова.
Карл не просто специалист по чрезвычайным ситуациям — он хорошо разбирается в передовых методах бизнес-анализа, разработки программного обеспечения и управления проектами. Благодаря его опыту и знаниям вы получите краткую, но важную информацию о том, как оправиться от неудач и, что особенно важно, избежать их.
Сорок шесть лет назад мне посчастливилось наткнуться на классическую книгу Фреда Брукса (Fred Brooks) The Mythical Man-Month1, раскрывшую мне глаза на мою начинающуюся карьеру. Книга Карла во многом подобна ей, но имеет более широкий охват и более актуальна для современного мира. Мой собственный полувековой опыт подтверждает, что он точно угадал с уроками, которые были выбраны для “Жемчужин разработки”».
Мейлир Пейдж-Джонс (Meilir Page-Jones), старший бизнес-аналитик, Wayland Systems Inc.
«Карл написал еще одну замечательную книгу, полную всесторонних советов разработчикам программного обеспечения. Его уроки будут актуальны для профессионалов и учащихся, молодых и старых, начинающих и умудренных опытом. Я занимаюсь разработкой программного обеспечения уже много лет, но эта книга вовремя напомнила мне, что еще можно улучшить в моей команде. Теперь я жду не дождусь, когда все мои коллеги прочитают эту книгу.
“Жемчужины разработки” основана на реальном опыте развития множества проектов и анализе достигнутого, подкрепляющем уроки. Как и во всех книгах Карла, эти уроки получаются простыми и увлекательными. Они наполнены интересными историями и забавными комментариями. Вы можете прочитать книгу от начала до конца или просто углубиться в конкретные разделы, относящиеся к областям, которые вы хотите улучшить сегодня. Увлекательное повествование плюс практические советы — вы не ошибетесь, если выберете эту книгу!»
Джой Битти (Joy Beatty), вице-президент Seilevel
«Книга Карла “Жемчужины разработки” преследует сложную цель — обозначить и объяснить многие особенности, которые вы вряд ли откроете для себя в процессе обучения и которые многие специалисты познают на горьком опыте. Все эти идеи имеют решающее значение для разработки отличного программного обеспечения.
Книга построена так, что вам придется подключить весь свой опыт и определить, как можно изменить свое поведение, и это прекрасно. В ней вы найдете 60 уроков, посвященных экосистеме разработки программного обеспечения. Подробный анализ, уже проведенный автором, поможет вам сэкономить время, повысить эффективность совместной работы и иначе взглянуть на распространенные заблуждения, а также даст возможность создавать более совершенные системы. Книга написана простым и доступным языком, и к тому же материал подкреплен большим количеством ссылок на других экспертов, которые в своей практической работе открыли для себя те же идеи.
Эти уроки — настоящие жемчужины: ценные крупицы мудрости, которые помогут вам разрабатывать совершенное программное обеспечение независимо от вашей роли. Подумайте о том, чтобы приобрести два экземпляра: один для себя и один для коллег — оставьте его там, где другие участники команды смогут взять его и обнаружить собственные жемчужины».
Джим Броссо (Jim Brosseau), Clarrus
«Это отличная книга для всех, кто занимается разработкой программного обеспечения. Один из потрясающих (и необычных) плюсов книги — ее организация в виде отдельных уроков. Они легко запоминаются при чтении и быстро приходят на ум, когда в них возникает потребность. Такое случилось со мной недавно, когда я обсуждал со старшим руководителем требования к компетенциям в проектах, использующих методы гибкой разработки, и сразу же вспомнил об уроке 8 “Главное требование к разработке — налаженное и эффективное общение”.
Из личного опыта могу подтвердить ценность таких уроков, как № 22 “Проблемы многих систем скрываются в интерфейсах”, поскольку сильно обжегся, не уделив интерфейсам должного внимания. Любой, кто занимается разработкой программного обеспечения, в конечном счете накапливает подобный опыт, который в будущем подсказывает, что надо и чего не надо делать. Эта книга поможет вам обрести его безболезненно. Как говорит Карл в уроке 7, “запись знаний обходится дешевле, чем повторное их обретение”. Эти слова не только являются хорошим советом для практиков, но и четко объясняют, почему вам следует купить данную книгу».
Говард Подесва (Howard Podeswa), автор The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery
1Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. — СПб.: Питер, 2021.
Предисловие
Получив степень доктора в области органической химии, Карл Вигерс устроился научным сотрудником в компанию Kodak в Рочестере, штат Нью-Йорк. Перед собеседованием он думал, что понимает особенности будущей работы, и полагал, что будет проводить исследования, связанные с фотопленкой, процессами проявления фотографий и всем подобным.
Когда Карл в первый раз пришел на работу в Kodak, его провели через световой шлюз в лабораторию. Этот шлюз похож на воздушный шлюз на подводной лодке, за исключением того, что предотвращает проникновение света в комнату, которая должна оставаться полностью темной. Карлу потребовалось несколько минут, чтобы глаза привыкли к слабому освещению. Никто его не предупредил, что исследования предстоит проводить в фотолаборатории.
Карл быстро осознал, что не хотел бы тратить годы на работу в прямом смысле в темноте и поэтому вскоре перешел на должность разработчика программного обеспечения, затем администратора ПО и, наконец, руководителя процесса разработки и совершенствования ПО. Позднее он основал собственную компанию Process Impact.
С помощью этой книги Карл пытается вывести других разработчиков ПО из темноты на свет. Как и в других его книгах, здесь больше практики, чем теории. Карл концентрируется на областях, в которых непосредственно имеет опыт работы: особенно это касается требований, совершенствования процессов, качества, культуры и командной работы.
Карл не объясняет, почему для своей книги он выбрал название «Жемчужины разработки». Жемчужина начинает расти, когда в раковину устрицы попадает раздражитель, например песчинка. Защищая себя, устрица начинает выделять перламутр. Процесс длится многие годы, но в итоге песчинка-раздражитель превращается в ценную жемчужину.
Карл — один из самых вдумчивых людей, которых я знаю. Он тщательно анализировал проблемы, с которыми сталкивался в процессе разработки программного обеспечения, и собрал в этой книге 60 самых ценных советов.
Стив Макконнелл (Steve McConnell), Construx Software и автор Code Complete2
2Макконнелл С. Совершенный код. — СПб.: Питер, 2005.
Благодарности
За пятьдесят с лишним лет я научился разрабатывать программное обеспечение, управлять проектами и совершенствовать процессы. Я прочитал бесчисленное количество книг и статей, посетил множество курсов профессиональной подготовки и прослушал немало докладов на конференциях. Я благодарен моим учителям, которые помогли мне пройти путь от обретения полезных знаний до совершенно нового понимания той или иной части нашей дисциплины. Особенно я хочу отметить Стива Боденхаймера (Steve Bodenheimer) и доктора Джойса Стаца (Dr. Joyce Statz). Сколько имен учителей останется в вашей памяти спустя десятилетия?
Огромное количество литературы по разработке программного обеспечения является практически неисчерпаемым источником просветления. Вот авторы, чьи работы я нашел особенно яркими: Майк Кон (Mike Cohn), Ларри Константин (Larry Constantine), Алан Дэвис (Alan Davis), Том ДеМарко (Tom DeMarco), Том Гилб (Tom Gilb), Роберт Гласс (Robert Glass), Эллен Готтесдинер (Ellen Gottesdiener), Каперс Джонс (Capers Jones), Норм Керт (Norm Kerth), Тим Листер (Tim Lister), Стив Макконнелл, Роксана Миллер (Roxanne Miller), Джеймс Робертсон, Сюзанна Робертсон (Suzanne Robertson), Джоанна Ротман (Johanna Rothman) и Эд Юрдон (Ed Yourdon). Если вы не читали их книги и статьи, то обязательно прочитайте. Мне выпала редкая удача за свою карьеру подружиться со многими мудрыми авторами и консультантами.
Мне посчастливилось работать с несколькими талантливыми инженерами-программистами. Наблюдая за работой других, можно многому научиться и пополнить свою копилку опыта. Будучи главным консультантом в моей компании Process Impact, я предоставил свои услуги примерно 150 компаниям и госорганам. Я благодарен всем клиентам и слушателям моих учебных курсов, которые поделились со мной своими историями успеха и неудач. Эти истории помогли мне узнать, какие методы работают или нет в тех или иных ситуациях. Все, что я узнал из этих многочисленных источников, я постарался изложить в виде уроков в данной книге.
При подготовке книги я имел возможность получить бесценные отзывы Джима Броссо, Тани Чарбери (Tanya Charbury), Майка Кона, Дэвида Хикерсона (David Hickerson), Тони Хиггинса (Tony Higgins), Норма Керта, Рэмзи Миллера (Ramsay Miller), Говарда Подесвы, Холли Ли Сефтона (Holly Lee Sefton) и особенно Мейлира Пейджа-Джонса, Кена Пью (Ken Pugh) и Кэти Рейнольдс (Kathy Reynolds). Я искренне благодарен им за терпение и ответы на мои вопросы, а также за их опыт, которым они щедро поделились со мной. И спасибо всем, кто прислал мне содержательные отзывы, подкрепившие мои личные наблюдения.
Я признателен Джой Битти, Джиму Броссо, Майку Кону (Mike Cohn), Гари К. Эвансу (Gary K. Evans), Лонни Фрэнксу (Lonnie Franks), Дэвиду Хикерсону (David Hickerson), Кэти Иберле (Kathy Iberle), Норму Керту, Дэррилу Логсдону (Darryl Logsdon), Жаннин Макконнелл (Jeannine McConnell), Марко Негри (Marco Negri), Мейлиру Пейджу-Джонсу, Нилу Поттеру (Neil Potter), Кену Пью, Джине Шмидт (Gina Schmidt), Джеймсу Шилдсу (James Shields), Джону Зигристу (John Siegrist), Дженейлу Стивену (Jeneil Stephen), Тому Томасовичу (Tom Tomasovic) и Себастьяну Ватцингеру (Sebastian Watzinger) за ценный вклад в рецензирование рукописи. Обзоры комментариев, которые выполнили Таня Чарбери (Tanya Charbury), Кэти Рейнольдс (Kathy Reynolds), Мод Шлих (Maud Schlich) и Холли Ли Сефтон (Holly Lee Sefton), были особенно ценными. Спасибо также Гари К. Эвансу за разрешение изменить удачный рисунок со схемой организации интерфейсов.
Я благодарен Хэзи Гумберт (Haze Humbert), Менке Мехта (Menka Mehta), а также всему редакционному и производственному отделу издательства Pearson за прекрасную работу над моей рукописью.
Как всегда, я в особом долгу перед своей женой Крис за то, что она была терпелива, пока я занимался еще одной книгой.
Об авторе
С 1997 года Карл Вигерс (Karl Wiegers) занимает пост главного консультанта в Process Impact, консалтинговой и обучающей компании в сфере разработки программного обеспечения, находящейся в Хэппи-Вэлли, штат Орегон. До этого Карл 18 лет работал в Kodak, где занимал должности ученого-исследователя фотографического дела, разработчика программного обеспечения, администратора программного обеспечения и, наконец, руководителя процесса разработки и совершенствования программного обеспечения. Карл получил степень доктора органической химии в Университете штата Иллинойс.
Карл — автор 12 книг, в том числе The Thoughtless Design of Everyday Things, Software Requirements3, More About Software Requirements, Practical Project Initiation, Peer Reviews in Software, Successful Business Analysis Consulting, и детективного романа под названием The Reconstruction. Он написал множество статей по разработке программного обеспечения, менеджменту, проектированию, консалтингу, химии и военной истории. Несколько книг Карла были отмечены наградами, одна из последних — премия Общества технических коммуникаций за книгу Software Requirements, написанную в соавторстве с Джой Битти. Карл работал в редакции журнала IEEE Software и писал статьи для журнала Software Development.
Когда он не сидит за компьютером, то любит дегустировать вина, работать волонтером в публичной библиотеке, играть на гитаре, сочинять и записывать песни, читать книги о военной истории и путешествиях. Вы можете связаться с ним через www.processimpact.com или www.karlwiegers.com.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу: [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
3Вигерс К.И. Разработка требований к программному обеспечению.
Глава 1. Обучение на собственном опыте
Я не знаю никого, кто мог бы, положа руку на сердце, сказать: «Сегодня я пишу программное обеспечение лучше, чем когда-либо». Всем, кто не может этого сказать, было бы полезно обучиться более эффективным методам работы. Моя книга дает возможность ускорить прохождение этого квеста.
Обретение опыта — это форма обучения, которая лучше всего способствует закреплению знаний и умений. Но она же и самая болезненная. В попытках попробовать новые подходы мы часто терпим неудачу. Мы должны преодолевать трудности и прикладывать усилия, чтобы освоить новые методы и понять, когда и как их использовать.
К счастью, есть другой путь. Кривую обучения можно сделать более пологой, опираясь на уроки, советы и приемы людей, которые уже получили знания и опыт. В книге собраны полезные идеи в области разработки ПО и управления проектами. Эти жемчужины мудрости я обрел на личном опыте и наблюдал в работе других. Ваш собственный опыт и уроки могут быть другими, и вы можете соглашаться не со всем, о чем я рассказываю. Это нормально — опыт каждого уникален. Тем не менее все описанное было весьма ценным для меня и пригодилось в моей карьере программиста.
Моя точка зрения
Позвольте начать с короткого рассказа о моем прошлом, чтобы объяснить, как я усвоил эти уроки. Свой первый курс по программированию я прослушал в 1970-м в колледже. В основе курса лежал, конечно же, язык FORTRAN. Следующим летом я приступил к выполнению своего первого задания. Нужно было автоматизировать некоторые операции в отделе бухгалтерии в моем колледже, причем сделать это я должен был в одиночку. У меня за плечами было уже два курса по программированию, так что я чувствовал себя полноценным инженером-программистом. Я на удивление легко справился с заданием, если учесть мой небольшой опыт. Несмотря на еще два года учебы, все остальное, что я узнал о программировании, я почерпнул сам из сторонних источников и от своих коллег. В прошлом такое неофициальное начало карьеры не было чем-то необычным, поскольку разработка программного обеспечения привлекала многих людей из разных слоев общества, которые не всегда имели формальное образование в области информатики.
С самого начала я много работал c программным обеспечением: разрабатывал требования, архитектуру и дизайн пользовательского интерфейса, писал код, тестировал его, занимался управлением проектами и писал документацию, наконец, пытался совершенствовать качество и процесс разработки. Попутно я защитил докторскую диссертацию по органической химии. Уже тогда треть моей диссертации состояла из программного обеспечения, которое анализировало экспериментальные данные и моделировало химические реакции.
В начале карьеры в компании Eastman Kodak, превратившейся в огромную и успешную корпорацию, я использовал компьютеры, чтобы заниматься проектированием и анализом экспериментов. Вскоре я перешел на должность программиста и занялся созданием приложений для исследовательских лабораторий Kodak, а затем несколько лет руководил небольшой группой разработчиков. Я обнаружил, что моя научная подготовка позволяет мне использовать более систематический подход к разработке программного обеспечения.
В 1983 году я написал первую статью о программном обеспечении. С тех пор из-под моего пера вышло много статей и восемь книг на темы, связанные с программированием. Как независимый консультант и преподаватель, начиная с 1997 года я оказал услуги почти 150 компаниям и государственным учреждениям их многих сфер. Эта деятельность позволила мне увидеть, какие методы эффективно работают в программных проектах, а какие — нет.
Ко многим своим идеям, связанным с разработкой программного обеспечения и управлением проектами, я пришел на личном опыте. Одни из них были полезными, другие — ошибочными. Некоторые идеи я почерпнул из опыта моих клиентов, в основном из проектов, потерпевших крах. Никто не вызывает консультанта, когда все идет хорошо. Я написал эту книгу, чтобы вам не приходилось медленно и мучительно проходить все те же уроки на личном опыте. Один опытный инженер-программист, прочитавший этот список уроков, сказал: «С каждым из этих уроков связан шрам (или несколько), полученный при его усвоении».
О книге
Эта книга содержит 60 уроков, связанных с разработкой и управлением программным обеспечением. Уроки разбиты на шесть групп, каждая из которых описывается в отдельной главе.
• Глава 2. Требования.
• Глава 3. Проектирование.
• Глава 4. Управление проектами.
• Глава 5. Культура и командная работа.
• Глава 6. Качество.
• Глава 7. Совершенствование процессов.
Глава 8 содержит заключительный общий урок, о котором следует помнить всегда. Для удобства все 60 уроков перечислены в приложении.
Я не пытался составить исчерпывающие списки уроков в названных областях. В каждой накоплено так много знаний, что никто не сможет представить более или менее полный список. Кроме того, я не рассматриваю другие важные и наиболее очевидные аспекты разработки ПО: программирование, тестирование и управление конфигурацией. Обсуждение этих процессов вы найдете в трудах других авторов, например, в таких книгах, как:
• Programming Pearls4 Джона Бентли (Jon Bentley) (Bentley, 2000);
• Lessons Learned in Software Testing Джема Канера (Cem Kaner), Джеймса Баха (James Bach) и Брета Петтикорда (Bret Pettichord) (Kaner, Bach, Pettichord, 2002);
• Code Complete Стива Макконнелла (McConnell, 2004);
• Software Engineering at Google5 Титуса Уинтерса (Titus Winters), Тома Мэншрека (Tom Manshreck) и Хайрама Райта (Hyrum Wright) (Winters, Manshreck, Wright, 2020).
Темы и уроки в этой книге в значительной степени независимы, поэтому вы можете знакомиться с ними в любой последовательности. Каждая глава начинается с краткого обзора соответствующей области разработки программного обеспечения. Затем несколько врезок под названием «Первые шаги» предлагают вам поразмышлять о предыдущем опыте работы, прежде чем погрузиться в уроки главы. Эти врезки предлагают задуматься о проблемах, с которыми сталкиваются команды в данной области, влиянии этих проблем и возможных глубинных причинах.
Каждый урок начинается с краткого изложения основной мысли, далее следует обсуждение и приводятся рекомендации, которые команды могут применять в своей практике. Читая каждую главу, думайте о том, как описанные приемы можно использовать в вашей ситуации.
Значок с изображением книги указывает на реальную историю из личного опыта или опыта моих клиентов или коллег. Все истории реальны, хотя имена участников изменены, чтобы сохранить конфиденциальность.
Ключ указывает на основные моменты в описании каждого урока.
Врезка «Следующие шаги» в конце каждой главы подскажет вам, как применить полученные сведения в вашем проекте, команде или организации. Независимо от вида проекта, над которым вы работаете, его жизненного цикла или создаваемого продукта, ищите идею, которую несет каждый урок, и думайте, как вы можете адаптировать ее, чтобы помочь проекту стать более успешным.
Попробуйте проработать материал всех врезок вместе с коллегами. В начале всех обучающих курсов, которые я вел, участники объединялись в небольшие группы и обсуждали задачи, стоявшие перед их командами («Первые шаги»). В конце те же группы изучали варианты решения этих задач, проводили мозговой штурм, посвященный тому, как решить их с помощью материалов курса («Следующие шаги»). Мои студенты увидели, что в эти дискуссионные группы полезно включать представителей разных заинтересованных сторон, так как они высказывали свою точку зрения на функционал проекта и его продвижение. Благодаря всестороннему обсуждению можно достичь глубокого понимания текущей деятельности и творчески подойти к выбору решений.
Я надеюсь, что многие из моих уроков найдут отклик и мотивируют вас попробовать что-то новое в своих проектах. Однако вы вряд ли сможете изменить все сразу. Разные люди, команды и организации воспринимают новый опыт с разной скоростью. Заключительная глава «Что дальше?» поможет вам наметить путь, как реализовать уроки на практике. В ней предлагается установить приоритеты изменений, которые вы хотели бы внести, и разработать план действий, который поможет перейти из точки, в которой вы находитесь сегодня, в точку, куда хотели бы попасть.
Примечание о терминологии
В этой книге я использую термины «система», «продукт», «решение» и «приложение» более или менее взаимозаменяемо. В каждом случае я имею в виду просто конечный результат вашего проекта, поэтому, пожалуйста, не ищите особого смысла в этих терминах. Независимо от того, работаете ли вы с корпоративной или государственной информацией, сайтами, коммерческими программными продуктами или аппаратными устройствами со встроенным ПО, уроки и соответствующие практики найдут свое применение.
Ваши возможности
Если вы действительно не относитесь к той редкой категории практиков, которые уже создают программное обеспечение лучше, чем кто-либо другой, то у вас всегда найдется что улучшить. Мы все — и отдельные разработчики, и группы, и организации — должны постоянно расширять свои возможности. Мы все хотим иметь как можно меньше шрамов.
Младший разработчик по имени Захари Минотт (Zachary Minott, 2020) поделился своей методикой, которая помогла ему превзойти более опытных разработчиков. Минотт описал этический подход, согласно которому он признает отсутствие у себя тех или иных знаний и обязуется изучать и применять новые знания на практике. Он сказал: «Если у меня и есть какая-то сверхспособность, то это способность быстро учиться и сразу же применять новые знания в своей работе». Минотт открыл важнейший механизм, позволяющий ему постоянно совершенствоваться в своей сфере.
Нам всем нужно постоянно совершенствоваться, мы все хотим иметь как можно меньше шрамов.
Возможно, вы решите пройти курс обучения, чтобы освоить новый навык или усовершенствовать привычные методы работы. Пока вы учитесь, невыполненная работа продолжает накапливаться. Из-за спешки велик соблазн проигнорировать новые знания и продолжать работать по старинке. Вы можете чувствовать себя вполне комфортно, поскольку текущих знаний и умений пока достаточно. Но это не путь к совершенствованию.
В каждом проекте я выделил две области, в которых нужно совершенствоваться. Я тратил какую-то часть времени, чтобы изучить новые темы и попытаться применить новые знания. Удача не всегда сопутствовала мне, но мой подход позволил постепенно накопить навыки, сослужившие мне хорошую службу.
Я призываю вас поступить так же. Не просто читайте книгу — делайте следующий шаг. Решите, как вы и ваши коллеги сможете применять описанные здесь методы и что, по вашему мнению, они дадут вам. Составьте список практик, о которых хотели бы узнать больше, а затем применяйте их. Так постепенно вы достигнете прогресса.
4Бентли Дж. Жемчужины программирования. 2-е изд. — СПб.: Питер, 2002.
5Винтерс Т., Маншрек Т., Хайрам Р. Делай как в Google. Разработка программного обеспечения. — СПб.: Питер, 2021.
Глава 2. Требования
Введение
У каждого проекта есть свои задачи — цели или результаты, на достижение которых направлена работа. Каждый проект также имеет требования, определяющие, что необходимо для удовлетворения запросов бизнеса или вывода продукта на рынок. В большинстве проектов с самого начала в требованиях не хватает многих деталей. Эти детали начинают обретать все более ясные черты по мере того, как клиенты осваивают программный продукт и присылают команде разработчиков свои замечания и предложения. Требования могут быть точно задокументированы или существовать только в головах заинтересованных сторон. В любом случае при отсутствии четкого понимания требований весьма маловероятно, что команде удастся достичь поставленных целей.
В конечном итоге команда (или, по крайней мере, большинство ее членов) выявит все требования заказчика. И чем раньше это произойдет — хотя бы до того, как команда решит, что разработка завершена, — тем проще и дешевле будет их воплотить.
Множество типов требований
Изучать требования гораздо сложнее, чем просто спросить пользователей, чего они хотят. (См. урок 11 «Люди не просто так собирают требования».) Первая сложность заключается в том, что все по-разному представляют, что такое требование. В литературе по программному обеспечению можно найти множество определений. Вот одно из них (Wiegers, Beatty, 2013):
Требование — это заявление о потребности или цели клиента либо об условиях или возможностях, которыми должен обладать продукт, чтобы удовлетворить такую потребность или цель. Свойство, которым должен обладать продукт, чтобы представлять ценность для клиента.
Термин «требования» охватывает множество категорий; некоторые из них определены в табл. 2.1 (Wiegers, Beatty, 2013; IIBA, 2015). У программистов нет единого мнения о том, как называть каждую категорию. Но название не так важно, как признание необходимости исследовать, записывать и передавать эти разнообразные категории требований людям, которые будут работать над проектом (см. табл. 2.1).
Таблица 2.1. Несколько категорий информации о требованиях
Категория требований
Краткое определение
Бизнес
Бизнес-цели или задачи, для достижения или решения которых был запущен проект. Могут быть записаны в документе о ви́дении и масштабе, уставе проекта или экономическом обосновании
Пользовательские
Описание действий, задач или целей, которые пользователи должны иметь возможность выполнять или достигать с помощью продукта. Обычно представлены в виде вариантов применения или пользовательских историй. Иногда под пользовательскими требованиями понимаются требования заинтересованных сторон, охватывающие более широкий круг запросов, выходящих за рамки использования продукта
К решению
Описание возможностей и качеств решения, отвечающего требованиям заинтересованных сторон
Функциональные
Описание поведения, которое продукт должен демонстрировать при определенных условиях. Основная часть требований к решению — функциональные требования. Разработчики пишут код, удовлетворяющий функциональным требованиям, которые соответствуют конкретным запросам пользователя
Нефункциональные
Детали требований к решениям, которые обычно относятся к качеству и эксплуатационным характеристикам продукта, также называемым атрибутами качества
К внешнему интерфейсу
Описание связей продукта с внешним миром, включая пользователей, другие программные системы, аппаратные устройства и механизмы взаимодействий
К переходу
Описание условий, которым должен соответствовать продукт, или действий, которые необходимо выполнить, чтобы обеспечить успешную миграцию из текущего состояния в обновленное
Проще говоря, бизнес-требования описывают, почему организация берется за проект. Пользовательские требования описывают, что пользователи смогут делать с помощью продукта. Функциональные требования сообщают разработчикам, что они должны создать. Согласование бизнес-, пользовательских и функциональных требований — важный компонент успешного планирования.
Основу составляет набор требований к продукту или решению, которые описывают возможности продукта, функциональное поведение и характеристики. В проектах часто есть дополнительные требования к переходу, описывающие, что еще должно быть сделано в рамках проекта, помимо создания самого продукта (IIBA, 2015). Примерами таких требований к переходу могут служить: создание и передача учебных материалов; создание документации для сертификации продукта; создание вспомогательной документации; перенос данных и другие действия, необходимые для того, чтобы помочь пользователям перейти от текущего состояния к обновленному.
Подобласти разработки требований
Обширную область разработки требований можно разделить на подобласти разработки и управления требованиями. Они охватывают пять основных видов деятельности, перечисленных в табл. 2.2 (Wiegers, Beatty, 2013). Команды разработчиков программного обеспечения не всегда строго последовательно выполняют различные действия по разработке требований, а делают это, то забегая вперед, то возвращаясь назад.
Таблица 2.2. Подобласти разработки требований
Подобласть
Деятельность
Описание
Разработка требований
Выявление
Действия по выявлению и изучению запросов клиентов и определению требований к решению, удовлетворяющему эти запросы
Анализ
Действия для достижения четкого и полного понимания требований, их уточнения до соответствующего уровня детализации, определения приоритетов и выявления взаимосвязей между ними
Детализация
Действия, направленные на формулирование знаний о требованиях, их хранение и передачу заинтересованным сторонам
Проверка
Действия, помогающие подтвердить, что решение, удовлетворяющее указанным требованиям, также будет удовлетворять запросы клиентов
Управление требованиями
Действия, направленные на отслеживание состояния требований во время разработки, обеспечение реакции на их изменение и отслеживание требований для последующих продуктов
Самое главное в процессе разработки требований к программному обеспечению — убедиться, что команда понимает и решает реальную задачу, которая может отличаться от задачи, первоначально озвученной заказчиком. Клиенты часто высказывают свои идеи вместо потребностей. Эти идеи не всегда отражают реальную задачу и могут приводить к реализации решения, не соответствующего действительности.
В отличие от большей части работы по созданию программного продукта, работа с требованиями связана не столько с программированием, сколько с общением между людьми. Требования к разработке сложны, поэтому не следует ожидать, что каждый член команды будет владеть ими в полной мере. Для работы с требованиями многие организации формируют штат людей, обладающих высокой квалификацией: подготовленных и опытных бизнес-аналитиков, продакт-менеджеров или (в проектах, использующих подходы Agile-разработки) владельцев продуктов. Сегодня для обозначения людей, которые аккумулируют итоговые требования в программных проектах, все чаще используется термин «бизнес-аналитик» и почти не употребляются другие термины, такие как «инженер по требованиям», «аналитик требований», «системный аналитик» и просто «аналитик». Если различие между ролями несущественно, то для обозначения тех, кто занимается формированием требований, я буду использовать термин «бизнес-аналитик» независимо от должностей или других обязанностей этих людей.
В отличие от большей части работы по созданию программного продукта, работа с требованиями связана не столько с программированием, сколько с общением между людьми.
Роль бизнес-аналитика
В последние годы важность бизнес-анализа в проекте была признана благодаря созданию профессиональных организаций, таких как Международный институт бизнес-анализа (International Institute of Business Analysis, IIBA; www.iiba.org). Эти организации разработали своды знаний и программы сертификации (IIBA, 2015). Даже если в команде нет отдельной должности бизнес-аналитика, его роль играют другие члены команды, работающие с заинтересованными сторонами, стремясь понять требования и определить решения.
Квалифицированные бизнес-аналитики выявляют реальные потребности заинтересованных сторон и пишут документацию для дизайнеров, разработчиков, тестировщиков и других специалистов. Специально назначенный бизнес-аналитик может оценить требования в широком бизнес-контексте, так как имеет представление о них на уровне системы или предприятия. Когда клиенты сообщают о своих потребностях непосредственно разработчикам, обе стороны имеют лишь ограниченное представление о системе со своих точек зрения. Бизнес-аналитик же предлагает представление более высокого уровня.
Различные организации поручают своим бизнес-аналитикам выполнять разные функции в проектах. Обычно бизнес-аналитики руководят деятельностью по разработке требований и управлению проектом. Они организуют обсуждения с представителями пользователей и с помощью различных методик стараются выявить все требования. Получая информацию от компетентных заинтересованных сторон, бизнес-аналитики структурируют ее, записывают и распространяют.
Требования — это фундамент
Требования служат основой для проектов. Не существует единственного «правильного» способа обработки требований. Для проектов разработки программного обеспечения можно выбрать нужное из множества жизненных циклов и моделей разработки, которые подразумевают различные способы представления требований. Но при этом важно, чтобы все разработчики обладали одной и той же информацией для создания правильного программного обеспечения независимо от подхода к разработке, принятого в команде. (См. урок 6 «Agile-требования не отличаются от других».)
Не все команды пишут конкретные технические задания. Тем не менее они аккумулируют всю информацию о разного рода требованиях и хранят ее в некоем документе, который можно назвать спецификацией требований.
Некоторые мои клиенты спрашивали меня: «Как компании, которые действительно хорошо собирают и формулируют требования, делают это?» На что я всегда отвечал: «Не знаю, они мне не звонят». Трудно узнать, что делают организации, освоившие процесс разработки требований, если они не делятся своим опытом через публикации или презентации. У меня также было несколько клиентов, которые говорили мне: «Вы здесь, потому что мы столкнулись с непреодолимыми трудностями». Чаще всего главной причиной этих трудностей были недоработки в требованиях.
Все команды должны серьезно относиться к требованиям, принимать и адаптировать выбранные методы разработки требований, учитывая характер своего проекта и командную культуру. Команды разработчиков программного обеспечения, которые пренебрегают требованиями, увеличивают риск провала проекта. Примерно с 1985 года я много размышлял о том, как помочь командам разработчиков ПО и систем разобраться с требованиями. В этой главе описываются 16 ценных уроков, которые я усвоил за это время.
Первые шаги: требования
Прежде чем вы перейдете к изучению уроков, связанных с требованиями, предлагаю вам потратить несколько минут на следующие действия. По мере чтения подумайте, в какой степени каждый из этих пунктов применим к вашей организации или команде.
1. Перечислите методы работы с требованиями, в которых особенно преуспела ваша организация. Задокументирована ли информация об этих методах? Доступна ли она другим членам команды, чтобы они могли ознакомиться с этими методами и применять их на практике?
2. Определите любые проблемы (болевые точки), которые можно отнести к недостаткам, мешающим командам разобраться с требованиями по проекту.
3. Опишите, как каждая проблема влияет на вашу способность успешно завершать проекты. Как они мешают достижению успеха в бизнесе и разработчикам, и их клиентам? Проблемы могут привести к материальным и нематериальным затратам из-за незапланированных доработок, задержек, поддержки и сопровождения продукта, негативных отзывов и неудовлетворенности клиентов.
4. Для каждой проблемы, выявленной на шаге 2, определите основные причины, провоцирующие или усугубляющие ее. Одни первопричины могут скрываться внутри команды или организации; другие спровоцированы внешними условиями и неподконтрольны вам. Проблемы, последствия и первопричины могут сливаться, поэтому постарайтесь разделить их и увидеть, как они связаны. Вы можете найти несколько основных причин, способствующих появлению одной и той же проблемы, или несколько проблем, обусловленных одной общей причиной.
5. Читая эту главу, отметьте любые практики, которые могут быть полезны вашей команде.
Урок 1. Если вы неверно определили требования, то неважно, насколько хорошо вы выполните остальную часть работы
Бизнес-аналитик одного из моих клиентов рассказал о неудаче, постигшей проект. Их IT-отдел взялся за создание новой информационной системы для своей компании. Команда разработчиков считала, что прекрасно понимает требования системы и без дополнительных отзывов пользователей. Участники команды не были высокомерными, просто оказались чересчур уверенными в себе. Однако, когда разработчики представили готовую систему, реакция пользователей была такой: «А если серьезно, где наше приложение?» Они категорически забраковали систему.
Разработчики были шокированы; они думали, что работают на совесть и создали правильный продукт. Однако отказ от взаимодействия с пользователями, которое помогает убедиться в правильном понимании требований, был серьезным упущением.
Когда вы с гордостью представляете миру свое новое детище, то едва ли хотите услышать: «Ваше детище уродливо». В описанном случае произошло именно это. Итак, что же сделала компания? Разработчики переделали систему, на этот раз внимательно прислушиваясь к пользователям. (См. урок 45 «У организаций никогда нет времени, чтобы правильно создать программное обеспечение, но они находят ресурсы, чтобы исправить его позже».) Это был дорогой урок о важности участия клиента в составлении требований.
Независимо от того, создаете вы новый продукт или улучшаете существующий, требования — это фундамент для всей последующей работы над проектом. Проектирование, конструирование, тестирование, документирование, обучение и миграция из одной системы или операционной среды в другую зависят от наличия правильных требований. Многочисленные исследования показали, что эффективная разработка и своевременное информирование о требованиях являются решающими факторами успеха любого проекта. И наоборот, неадекватное ви́дение проекта, неполные и неточные требования, а также меняющиеся требования и цели проекта — частые причины неудачи (PMI, 2017). Правильное определение требований помогает гарантировать, что решение будет соответствовать ви́дению продукта и бизнес-стратегии организации (Stretton, 2018). Не сформулировав правильно требования, вы потерпите неудачу.
При отсутствии качественной проработки требований заинтересованные стороны могут удивиться тому, что предлагает команда разработчиков. Такие программные сюрпризы часто оказываются неприятными.
Правильные требования, но когда?
Я не говорю, что нужно иметь полный набор требований перед началом реализации. Это нереально для любых продуктов, кроме самых маленьких и стабильных. Всегда будут появляться новые идеи, изменения и исправления, которые вы должны учитывать в своих планах развития. Но для любой части системы, которую вы создаете, будь то отдельная фаза разработки, конкретный релиз или полный продукт, вам необходимо иметь как можно более полные и правильные требования. В противном случае планируйте доработку после окончания реализации. В проектах, практикующих Agile-разработку, предусмотрен дополнительный этап проверки требований. Чем дальше первоначальные требования от того, что действительно нужно клиентам, тем больше доработок понадобится.
Некоторые утверждают, что невозможно сразу правильно выявить все требования, что клиенты всегда предлагают добавить что-то еще — и поэтому среда постоянно развивается. Возможно, они правы, но я скажу так: «В таком случае вы никогда не сможете закончить проект». Учитывая, что всегда можно что-то добавить, вы никогда не сможете идеально выполнить требования. Но оговоренный объем разработки требует, чтобы вы сделали все правильно, иначе успеха вам не видать.
Дело обстоит немного иначе, если вы создаете инновационный продукт. Если никто и никогда не делал ничего подобного, то у вас вряд ли все получится с первой попытки. Ваша первая попытка — это, по сути, этап проверки гипотез и определения требований экспериментальным путем. Однако в конечном счете ваши эксперименты приведут к тому, что вы разберетесь в возможностях и характеристиках нового продукта — его требованиях.
Правильные требования, но как?
Ничто не заменит постоянного взаимодействия с клиентами, при котором можно определить набор точных, четких и своевременных требований. (См. урок 12 «Выявление требований должно помочь разработчикам услышать голос клиента».) Нельзя просто провести встречу в самом начале, а затем сказать клиентам: «Мы позвоним вам, когда закончим». В идеале команда должна быть на связи с представителями клиентов на протяжении всего времени разработки проекта. У разработчиков будет много вопросов и моментов, требующих уточнения. Участники команды должны будут прописать общие требования на ранних этапах и постепенно уточнять их в дальнейшем. Команде нужна надежная частая обратная связь с пользователями и другими заинтересованными сторонами, чтобы подтвердить правильность понимания требований и предлагаемых решений.
Не всегда получается уговорить клиентов на такое тесное взаимодействие. В конце концов, у них есть своя работа; руководители могут воспротивиться тому, чтобы некоторые из их лучших сотрудников тратили много времени на проект. «Вы можете посетить одну-две встречи, — скажет руководитель, — но я не хочу, чтобы эти программисты постоянно отрывали вас от дела своими вопросами».
Один из способов убедить клиента в необходимости постоянного взаимодействия — привести примеры проблем, с которыми столкнулась организация из-за недостаточного участия клиентов в разработке продукта. Еще лучше рассказать об опыте, когда взаимодействие с клиентами окупилось. Другой метод убеждения — предложить четкий план взаимодействий для уточнения требований, а не оставлять этот вопрос полностью открытым. Подобный план может предусматривать ряд неформальных обсуждений, встреч, обзоров требований и утверждения эскизов, прототипов и последовательности релизов.
Клиенты с большей вероятностью будут в восторге от проекта и c готовностью согласятся внести свой вклад, если увидят ощутимый прогресс, например в виде периодического выпуска новых версий работающего программного обеспечения. Они также воодушевятся, если увидят, что их вклад действительно влияет на продвижение проекта. Иногда бывает трудно убедить заказчиков принять обновленную программную систему. Представители заказчиков, работавшие с командой разработчиков, знающие суть нововведений и понимающие их необходимость, могут помочь облегчить переход.
Я работал с несколькими представителями клиентов, которые оказали огромное влияние на успех проекта. Помимо информации о требованиях, некоторые из них также предоставили эскизы пользовательского интерфейса и тесты, помогающие убедиться в правильной реализации разных частей программного обеспечения. Трудно переоценить вклад таких преданных клиентов, помогающих команде разработчиков точно определить требования и выработать правильное решение.
При отсутствии качественной проработки требований заинтересованные стороны могут удивиться тому, что предлагает команда разработчиков. Такие программные сюрпризы часто оказываются неприятными. Я хочу, чтобы, увидев продукт, мои клиенты реагировали так: «Ого! Карл, получилось лучше, чем я мог себе представить. Спасибо!»
Урок 2. Основной результат разработки требований — общее ви́дение и понимание
Материальным результатом разработки требований является документ в некой хранимой форме. Обычно это письменный документ, часто называемый спецификацией требований к программному обеспечению, бизнес- или рыночными требованиями. Как вариант, требования можно оформить в виде каталожных карточек, стикеров на доске, диаграмм, приемочных тестов или их комбинаций.
Однако наиболее важными результатами разработки требований являются общее понимание и согласие заинтересованных сторон в отношении решения, которое будет создано командой проекта. Добившись этого понимания, можно проверить, соответствуют ли предлагаемый объем и бюджет проекта необходимым возможностям и характеристикам решения.
Управление ожиданиями — важная часть управления проектами. Разработка требований направлена на формирование общих ожиданий (общего ви́дения) у представителей заинтересованных сторон. Спецификации требований содержат информацию об особенностях соглашения. Благодаря общему ви́дению согласовывается вся деятельность, связанная с проектом (Davis, 2005):
• работа, которую финансирует спонсор проекта;
• решение, которое, как ожидают клиенты, позволит им достичь бизнес-целей;
• программное обеспечение, которое проверяют тестировщики;
• продукт, который отделы маркетинга и продаж предлагают миру;
• планы и списки задач, создаваемые руководителями и командами разработчиков проекта.
Часто трудно определить, одинаково ли понимают несколько человек нечто столь сложное, как проект по разработке программного обеспечения. Я бывал на встречах, где участники достигали определенного согласия, а позже выяснялось, что некоторые детали соглашения (и, следовательно, результат) они понимают по-разному. Эти различия могут привести к тому, что участники будут стремиться к противоположным целям.
Заявление о ви́дении определяет общую стратегическую цель, к достижению которой должны стремиться все участники проекта.
Заявление о ви́дении помогает достичь общего понимания и непротиворечивых ожиданий. Я использовал следующий шаблон заявления, чтобы помочь заинтересованным сторонам сформулировать свои мысли (Wiegers, Beatty, 2013; Moore, 2014):
Для
[целевые клиенты]
Которые
[изложение бизнес-потребностей или возможностей]
Предполагается создать
[название продукта или проекта]
Являющийся
[тип продукта или проекта]
Позволяющий
[основные возможности продукта; основные преимущества, которые он обеспечит; веская причина покупки продукта или реализации проекта]
В отличие от
[текущей реальности или альтернативных продуктов]
Наш продукт
[краткое изложение основных преимуществ этого продукта по сравнению с текущей реальностью или товарами конкурентов]
В качестве простого примера ниже приводится заявление о ви́дении, которое я написал для сайта, созданного мной в целях поддержки книги. Несмотря на то что этот крошечный проект я целиком хранил в своей памяти, написание заявления о ви́дении в самом начале помогло внести ясность в то, чего я надеялся достичь с помощью сайта.
Для читателей, которые интересуются книгой «Жемчуг из песчинок», предполагается создать сайт PearlsFromSand.com, позволяющий посетителям получить информацию о книге и ее авторе, приобрести копии в различных форматах и создать сообщество людей, заинтересованных в обмене своим жизненным опытом. В отличие от сайтов, которые просто описывают и рекламируют книгу, наш продукт — PearlsFromSand.com — позволит посетителям делиться своим жизненным опытом, а также читать и комментировать сообщения друг друга.
Если у вашего проекта нет заявления о ви́дении, то никогда не поздно его написать. На своих учебных занятиях при обсуждении требований к программному обеспечению я прошу студентов написать заявление о ви́дении своего текущего проекта с использованием этого шаблона. Меня всегда впечатляют краткие описания, которые студенты создают всего за пять минут. Из их заявлений о ви́дении я могу быстро понять, с какой целью создаются проекты.
Когда занятия посещают несколько человек из одной команды, бывает так, что их заявления о ви́дении существенно различаются. Я часто прошу, чтобы представители разных заинтересованных сторон, имеющие разные точки зрения, писали заявления о ви́дении по отдельности. В дальнейшем, сравнив эти заявления, можно увидеть, пришли ли заинтересованные стороны к общему пониманию того, куда движется проект. Наличие расхождений подсказывает, что члены команды должны еще поработать над согласованием своих ожиданий.
У моей подруги-консультанта был точно такой же опыт работы с клиентским проектом. Она сказала: «Я попросила представителей четырех основных заинтересованных сторон изложить на бумаге собственное ви́дение, пока мы все были в одной комнате. В результате получились очень разные и кое в чем несовместимые заявления. О таких вещах лучше узнавать заранее».
Заявление о ви́дении определяет общую стратегическую цель, к достижению которой должны стремиться все участники проекта. Если в ходе работы над проектом ви́дение изменится, то заказчик должен сообщить об этих изменениях всем, кого они касаются, чтобы у людей по-прежнему было единое понимание требований. Заявление о ви́дении не заменяет спецификации требований, но задает отправную точку, позволяющую гарантировать, что требования, озвученные команде, соответствуют этому ви́дению и, следовательно, успех будет достигнут.
Урок 3. Интересы всех сторон нигде не пересекаются так явственно, как в требованиях
Консультант и писатель Тим Листер (Tim Lister) трактует успех проекта как «удовлетворение набора всех требований и соблюдение всех ограничений, определяющих ожидания ключевых заинтересованных сторон». Эта формулировка подразумевает, что команда разработчиков проекта должна определить заинтересованные стороны и порядок взаимодействия с ними, чтобы понять эти требования и ограничения.
Заинтересованная сторона — это любое лицо или группа людей, активно участвующих в проекте, затрагиваемых им или способных влиять на его продвижение. Связи между заинтересованными сторонами и проектом могут быть разными. Одним заинтересованным сторонам просто навязывают результат разработки проекта; другие тщательно прорабатывают требования. И среди них всегда будет тот, кто сможет изменить направление проекта или даже остановить его.
Заинтересованная сторона — это любое лицо или группа людей, активно участвующих в проекте, затрагиваемых им или способных влиять на его продвижение.
Заинтересованные стороны могут быть внутренними по отношению к команде проекта или организации, занимающейся разработкой, либо внешними. На рис. 2.1 перечислены типичные заинтересованные стороны, мнение которых необходимо учитывать при разработке большинства программных проектов. В зависимости от категории продукта могут быть и другие заинтересованные стороны: корпоративная информационная система, коммерческое программное приложение, государственная система или материальный продукт, содержащий встроенное ПО.
Рис. 2.1. Заинтересованные стороны, определяющие требования к проекту, которым он должен удовлетворять, и ограничения, которые он должен соблюдать
Анализ заинтересованных сторон
Команда проекта должна заранее определить потенциальные группы заинтересованных сторон. Не удивляйтесь, если список получится пугающе длинным. Потребуется приложить некоторые усилия, чтобы определить ваши заинтересованные стороны. Однако это намного лучше, чем игнорировать критически настроенное сообщество и вносить коррективы на поздних стадиях проекта.
Конечные пользователи и клиенты, приобретающие продукты, которыми будут пользоваться другие, выступают основными источниками требований. Заказчик, который выбирает продукт или платит за него, не всегда использует его и может иметь неправильное представление о том, что нужно пользователям для выполнения их работы. Многие продукты имеют широкий круг конечных пользователей. Чтобы упростить исследование требований, разделите своих пользователей на группы с разными наборами потребностей (Wiegers, Beatty, 2013). Пользователи могут быть даже не людьми, а аппаратными устройствами или другими программными системами, взаимодействующими с вашими продуктами. Вам нужно будет определить людей, которые могут предоставить требования от имени этих компонентов.
Обычно мы представляем себе прямых пользователей, которые будут непосредственно взаимодействовать с продуктом, но у вас могут быть и непрямые пользователи. Они могут предоставлять данные, поступающие в информационную систему, или получать выходные данные системы, даже притом что сами не будут генерировать выходные данные. Однажды я участвовал в создании корпоративной системы, объединявшей данные из десятков проектов и составлявшей ежемесячные отчеты, которые затем рассылались многим руководителям. Эти руководители были непрямыми пользователями — они не работали с самой системой. Тем не менее, будучи получателями системных отчетов, они были основными заинтересованными сторонами.
Один мой коллега лаконично описал непрямого пользователя: «Ваш клиент и после удаления из списка остается вашим клиентом». Чтобы идентифицировать непрямых пользователей, нужно подняться на один или два уровня выше непосредственного контекста приложения и посмотреть, какие группы людей и какие другие системы должны быть представлены. Необходимо также определить классы нежелательных пользователей, которые не должны иметь возможности пользоваться системой. Например, хакеры не являются заинтересованными сторонами (они не будут определять требования или ограничения), но вам нужно предвидеть и пресекать их злые намерения.
Попробуйте ответить на следующие вопросы о каждой выявленной вами группе заинтересованных сторон.
Кто они? Опишите каждую группу, чтобы все участники проекта понимали, кто это. Описания заинтересованных сторон могут повторно использоваться в нескольких проектах организации.
Насколько они заинтересованы? Подумайте о том, как сильно результат проекта повлияет на группу и насколько велико их желание участвовать в проекте. Вам нужно узнать об ожиданиях, интересах, опасениях и ограничениях каждой группы заинтересованных сторон.
Какое влияние на проект они имеют? Определите, какие решения каждая заинтересованная сторона может и не может принимать. Какие группы обладают наибольшим влиянием на проект? Каковы их взгляды и приоритеты? Вы должны уделить особое внимание группам, которые проявляют наибольший интерес к проекту и оказывают наибольшее влияние на него (Lucidchart, 2021).
С кем лучше всего говорить? Определите подходящих представителей в каждом сообществе, с которыми нужно работать. Они должны быть авторитетными источниками информации.
Где они? Сбор информации — итеративный процесс, требующий множества встреч. Проще всего получить информацию от группы заинтересованных сторон, если у вас есть прямой доступ к отдельным ее представителям. В противном случае продумайте механизмы и протоколы удаленного взаимодействия.
Что мне нужно от них? Определите информацию, решения и данные, которые понадобится получить от каждой группы. Это поможет вам выбрать наилучшие способы получения информации в нужное время. Для каждой группы пользователей вы должны понять их требования (что продукт должен позволять им делать) и их ожидания в отношении качества. Некоторые группы заинтересованных сторон будут накладывать ограничения, которые должна соблюдать команда проекта. Ограничения делятся на несколько категорий, среди которых:
• финансовые, временные и ресурсные ограничения;
• применимые политики, нормы и стандарты (бизнес-правила);
• совместимость с другими продуктами, системами или интерфейсами;
• юридические или договорные ограничения;
• требования к сертификации;
• ограничения возможностей продукта (то есть какие функции не должны включаться в продукт).
Что им нужно от меня? Одни заинтересованные стороны нужно проинформировать о существенных проблемах, которые могут их затронуть, поэтому вам необходимо знать, какая информация о проекте актуальна для каждой группы. Другим может понадобиться пересмотреть требования, чтобы убедиться, что они не противоречат существующим правилам и ограничениям. Взаимодействуйте с заинтересованными сторонами, чтобы понять, чего они ожидают от вас, и сообщайте им о своих ожиданиях. Успех сотрудничества во многом зависит от создания и поддержания взаимного доверия с помощью эффективного общения.
Как и когда мне с ними взаимодействовать? Как только вы очертите круг заинтересованных сторон, подумайте о том, какими способами лучше всего обмениваться с ними необходимой вам всем информацией. Если у вас нет прямого доступа к реальным представителям определенной группы пользователей, то подумайте о возможности создания персон, воображаемых людей, которые будут замещать реальных (Cooper et al., 2014).
Какие заинтересованные стороны наиболее важны при разрешении конфликтов? При разрешении противоречивых требований и принятии важных решений оцените, какой результат больше всего соответствует бизнес-целям проекта. Одни группы пользователей могут быть предпочтительнее других; удовлетворение их потребностей способствует успеху в бизнесе в большей степени, чем удовлетворение требований других групп пользователей. Проанализируйте влияние и интересы заинтересованных сторон, чтобы выявить эти приоритеты, не ждите, пока назреет первый конфликт.
Кто звонит?
Важно сразу определить лиц, принимающих решения. В некоторых случаях таким лицом может быть один человек, например спонсор проекта или владелец продукта. Взаимодействие с ним наиболее эффективно при условии, что у него есть вся нужная информация, чтобы принять соответствующее решение, и он сможет быстро сделать это при необходимости. Однако чаще вам придется определять правильные группы людей для принятия решений из разных областей. На принятие групповых решений потребуется больше времени, зато они лучше отражают все интересы, соответствующие целям проекта.
Лица, ответственные за принятие решений, касающихся нескольких заинтересованных сторон, должны основывать свои решения на бизнес-целях проекта. Цели, заявление о ви́дении, ограничения проекта и другие бизнес-требования обычно оформляются в виде документа о ви́дении и масштабе проекта или в виде устава проекта (Wiegers, 2007; Wiegers, Beatty, 2013). В проекте, не имеющем четких бизнес-требований, мало оснований для принятия и аргументирования важных решений.
Мы все на одной стороне
Не всегда получается поразить все заинтересованные стороны результатами проекта. Напряженность между сторонами может расти, если люди преследуют противоположные цели, стараясь защитить свои интересы. Выстраивание отношений в духе сотрудничества с ключевыми заинтересованными сторонами имеет большое значение для достижения успеха проекта. Поскольку в будущем вам, возможно, придется работать с теми же людьми, стоит с самого начала строить общение на основе взаимоуважения.
Урок 4. В требованиях в первую очередь важны особенности использования, а затем — функциональность
Один из наших внутренних корпоративных пользователей попросил мою команду добавить новую возможность в приложение, которое использовала его группа. Он настаивал, что эта возможность необходима, поэтому мы удовлетворили его просьбу. Однако, насколько нам известно, никто так и не воспользовался добавленным функционалом. В следующий раз я бы скептически отнесся к просьбе данного клиента.
В индустрии программного обеспечения существует убеждение, согласно которому (в зависимости от источника, который вы читаете) от 50 до 80 % возможностей ПО используются редко или не используются никогда (The Standish Group, 2014). У меня нет точных цифр, но я могу смело заявить, что значительная доля функционала поставляемого программного обеспечения не представляет большой ценности для конечных пользователей. Используют ли ваши сотрудники возможности каждого приложения в полной мере? Мои — нет. Я написал множество книг и статей, пользуясь Microsoft Word, но в Word есть куча возможностей, которыми я никогда не пользовался и не буду. То же верно и для других приложений, которыми я пользуюсь. К сожалению, индустрия ПО прилагает значительные усилия для реализации возможностей, которые практически не используются.
Зачем нужна лишняя функциональность?
Если разработчики стремятся удовлетворить требования к возможностям продукта, растет риск появления невостребованных функций. Если заказчик хочет, чтобы функции можно было постоянно расширять, их количество будет увеличиваться. Ориентированность на богатство функциональных возможностей может привести к выпуску продукта, который, казалось бы, имеет нужные функции, но не позволяет пользователям решать их задачи.
Я рекомендую обсуждать не только возможности самого продукта, но и то, что пользователи будут с ним делать. Мы должны смещать акцент с функциональности на особенности использования, с решения на потребность. Это быстрее поможет бизнес-аналитику и команде разработчиков понять контекст и цели пользователя. Имея такую информацию, бизнес-аналитик сумеет точнее определить, какими возможностями должно обладать решение, для кого оно, как и когда будет использоваться.
Сочетая оба подхода, то есть учитывая и технические возможности, и особенности использования, можно определить функциональные требования, которые будут озвучены разработчикам. Однако фокус на особенностях использования позволит гарантировать, что в продукт будут добавлены те функции, которые действительно необходимы пользователям для выполнения их задач. Это снижает риск создания избыточной функциональности, которая вроде и кажется хорошей идеей, но на деле не помогает пользователям достичь конкретных целей. Ориентируясь на особенности использования, мы повышаем удобство работы с продуктом, поскольку разработчики могут взвешенно подходить к реализации каждого элемента функциональности с учетом задач или целей пользователя (Constantine, Lockwood, 1999).
Я рекомендую смещать обсуждение требований с самого продукта на то, что пользователи будут с ним делать.
Ставим особенности использования на первое место
Когда при определении требований мы ориентируемся на особенности использования, немного меняется суть вопросов, которые бизнес-аналитик может задавать во время сбора информации. Вместо «Что вы хотите?» или «Что, по вашему мнению, должна делать система?» бизнес-аналитик может спросить: «Как предполагается использовать систему?» В процессе обсуждения определяются задачи, которые пользователи должны решать с помощью системы.
Обсуждение вариантов использования — хороший способ понять эти задачи (Kulak, Guiney, 2004). Редкие пользователи запускают приложение ради определенной функции; подавляющее большинство пользуются им, чтобы достичь конкретной цели. Каждый раз, когда я запускаю свое приложение финансового учета, я преследую одну или несколько целей, например хочу сверить состояние счета кредитной карты, перевести средства на личный банковский счет, оплатить что-либо или открыть депозит. Каждая из этих целей — вариант, или случай, использования. Я открываю приложение, имея определенное намерение, и выполняю последовательность шагов, вызывая функции, необходимые для решения задачи. Если все идет хорошо, то я успешно решаю свою задачу и закрываю приложение — желаемый результат достигнут.
Есть несколько причин, объясняющих привлекательность вариантов использования. Прежде всего, они помогают представителям пользователей задуматься о своих потребностях. Пользователям сложно правильно сформулировать перечень функций, которые должны быть реализованы в продукте, но они с легкостью расскажут о сценариях использования из своей повседневной жизни. Эти сценарии помогают структурировать и организовать описания связанных функций. В шаблон варианта использования можно включить дополнительное описание, настолько подробное, насколько сочтет нужным ваша команда (Wiegers, Beatty, 2013). Связанная функциональность включает описание наиболее типичной последовательности взаимодействий или действий по умолчанию для задачи (обычный сценарий) и любые варианты этой типичной последовательности (альтернативные сценарии). По этим описаниям бизнес-аналитик или разработчики смогут определить, какие функции должно предоставить приложение, чтобы пользователи могли решать поставленные задачи. В надлежащем описании варианта использования также учтено, какие ошибки могут возникнуть и как система должна их обрабатывать (нештатные ситуации).
Анализ, ориентированный на особенности использования, помогает расставить приоритеты. К функциональным требованиям с наивысшим приоритетом относятся те, которые позволяют пользователям решать самые важные задачи. Одни варианты использования будут более важными и востребованными, чем другие, поэтому должны быть реализованы в первую очередь. В пределах одного варианта использования наивысший приоритет имеет нормальный сценарий вместе с возможными нештатными ситуациями. Альтернативные сценарии имеют более низкие приоритеты, и часто их допускается реализовать позже или даже не реализовать никогда. Изучение особенностей применения поможет вам определить, какие варианты использования встречаются чаще и должны иметь наивысший приоритет. (Подробнее об особенностях применения см. урок 15 «Когда принимаете решение о добавлении функций, избегайте расстановки приоритетов по децибелам».)
Поставив себя на место пользователя, вы сможете продуктивнее взаимодействовать с ним и получить более полное представление об ограничениях реализации, которое труднее получить в случае подхода, ориентированного на функциональность продукта. Если пользователи с помощью продукта не смогут решать свои задачи или он им не понравится, то добавление дополнительных функций не повысит их лояльность.
