Качество, реально дешево
Это позволит сравнивать файлы, полученные в результате нескольких испытаний программы с последовательно изменёнными параметрами. Также можно заставить программу вести протокол внутренних несогласованностей, который будет полезен при диагностике трудно воспроизводимых сбоев в работе программы.
Детализация требований
Ещё одна проблема, которую придётся решить, — насколько подробно нужно формулировать требования. Разумеется, в данном случае задача в том, чтобы определение было как можно полнее: чем подробнее описано требование, тем легче следить за ходом его реализации. Чем больше аспектов определено заранее, тем больше параллелизма в работе разработчиков и групп, отвечающих за тестирование, обучение пользователей и выпуск программного продукта, так как тогда им проще понять, какой продукт создаётся. Однако часто подробно документировать требования очень трудно и даже невозможно, так как приходится работать в незнакомых областях (так чаще всего и бывает при работе над программными проектами). Как правило, чтобы понять, что именно пытаются создать участники проекта, приходится изрядно поэкспериментировать и испробовать много новых идей. Бывает и так, что поставленная цель оказывается вовсе недостижима. Ниже я опишу способ, позволяющий согласовать потребности в эксперименте и в документировании требований к проекту.
Недостаточно подробное определение обычно является следствием недостаточного понимания. Если недостающие сведения относятся к маркетингу или другим вопросам бизнеса, то разработчики мало чем помогут — это работа менеджера проекта и менеджера по маркетингу. Однако при нехватке сведений о реализуемых функциях, например, когда неясно, как работает та или иная функция, откуда берётся информация или чего хочет пользователь, можно создать прототип пользовательского интерфейса, иллюстрирующий внешний вид этих функций. Если недостающая информация касается технических возможностей, скажем, может ли программный продукт выполнять те или иные действия, можно провести анализ технической осуществимости, а затем создать прототип. Вот как свести воедино информацию из реального мира, экспериментальную работу и творческий процесс в процесс формулирования требований, прежде чем перейти к планированию (рис. 8-1).
Главная идея в том, чтобы заранее выяснить места возможного риска и до начала работы над проектом разработать решения потенциальных проблем. Анализ осуществимости и прототипы пользовательского интерфейса помогут понять суть проблемы, оценить потребности и снизить общий риск. Эти методики обеспечивают процесс формулирования требований обратной связью с внешним миром и позволяют составлять более детальные планы.
Рис. 8-1. Связь между требованиями, практичностью и созданием прототипа.
О базовых методиках анализа технического риска и создания прототипов пользовательского интерфейса, а также их использование для формулирования оптимальных требований см. главы 9 и 10.
Анализ требований
Когда требования сформулированы, но ещё не утверждены, разумно проанализировать их в целом и каждое по отдельности. Требования к новой программе нужно отбирать очень тщательно. Многие просто берут список требований, не анализируя его с точки зрения коммерческой привлекательности и не удаляя всё, что не вписывается в центральную идею проекта. В итоге получаются программы с плохо организованной функциональностью, не соответствующей назначению программы. Оценке требований и поиску направления, в котором движется разработка вашей программы, должно уделять большое внимание.
«Фрагментация» требований
Отойти от намеченного пути при формулировании требований легко. Так бывает, когда упрямый индивид или целая группа уводит «фокус» требований совсем в другую сторону, чем было задумано. Возможно, было легче формулировать требования для тех функций, определить которые было проще всего. Может оказаться и так, что требования сопряжены с чрезмерным для таких программ риском. Как бы ни было, обязательно должны присутствовать объективный взгляд на требования и оценка их влияния на ход проекта.
Категории требований
Ниже описаны четыре категории требований.
• «Опережающие» и «догоняющие» требования
Первые позволяют продукту обогнать конкурентов по рынку. Они могут описывать просто новое представление данных или возможность поддержки новой платформы. Им не обязательно быть революционными — достаточно, что они дают преимущество в конкуренции на момент выхода программы на рынок. Вторые подтягивают функциональность программы до уровня конкурентов. Они призваны сохранить конкурентоспособность и связаны с решением проблем сбыта и технической поддержки.
Разделение требований на категории «опережающих» и «догоняющих» позволяет проанализировать конкурентоспособность вашей программы. Например, если выяснилось, что в программе реализовано слишком мало опережающих требований или их вообще нет, можно реализовать дополнительные опережающие требования. Стратегия разработки программ в NuMega всегда включает ряд особенностей, которые делают программу уникальной на рынке и позволяют ей стать или остаться, так сказать, «чемпионом породы».
• Перспективные и ретроспективные требования
Последние направлены на решение проблем, связанных с прошлыми выпусками ПО. Например, для решения проблем с производительностью и удобством использования в последнем выпуске в общем случае служат ретроспективные требования. Так как эти требования — не что иное, как реакция на существующий продукт в существующем окружении, их реализация позволяет улучшить продукт, но не предвосхитить будущие потребности.
Перспективные требования позволяют заранее побеспокоиться о будущих потребностях заказчика. Они основаны на уверенности в том, что заказчик обязательно изменит свои потребности и желания, даже если сам он ещё об этом не знает. Часто перспективные требования базируются на крупномасштабных изменениях в деловой практике (например, на повсеместном внедрении размещения заказов через Web), технологиях (появление платформ, поддерживающих беспроводную связь) или рынка (слияние двух конкурировавших фирм). Перспективные требования труднее всего сформулировать, но, если удастся верно предугадать нужды потребителя и не ошибиться с выбором рынка и функций ПО, результатом будет значительное преимущество перед конкурентами.
Подборка ретроспективных и перспективных требований должна соответствовать потребностям, которые призван удовлетворить продукт, особенностям рынка и задачам выпуска. Скажем, можно быстро (за полгода) подготовить выпуск, в котором будет реализован ряд ретроспективных требований, а также включить в него несколько перспективных требований, чтобы не упустить какую-то интересную возможность.
Перспективные требования вовсе не обязательно являются копией опережающих. Перспективные требования именно предвосхищают потребности, в то время как опережающее требование может быть основано на текущих потребностях клиента, оставленных без внимания конкурентами. Так, введение поддержки диаграмм и графиков и нового одноэтапного процесса ввода данных можно считать опережающими, но никак не перспективными. С другой стороны, поддержку карманных компьютеров можно одновременно рассматривать, как опережающее и как перспективное требование, которое приносит двойную выгоду.
Наглядное представление требований
Чтобы понять сформулированные требования в общем, можно использовать таблицу для анализа требований, расписав их по ячейкам таблицы. Эта таблица имеет вид квадрата. поделённого на четыре равные части. Ниже по одной оси находятся догоняющие и опережающие требования, а по другой — перспективные и ретроспективные требования (рис. 8-2).
Рис. 8-2. Набор требований, представленный в виде таблицы из четырёх ячеек.
Далее приводится описание содержимого каждой ячейки таблицы. Расписав собственные требования по ячейкам такой таблицы, вы поймёте, в каком направлении пойдёт работа.
Ячейка 1. Вы предвидите будущие потребности потребителей и будете первым производителем, предоставившим соответствующее решение. Эти потребности пока ещё не до конца поняты и не полностью установлены. Вы первопроходец в этой области, поэтому уровень риска довольно высок. Из-за множества «неизвестных» нельзя заранее предоставить подробное определение требований. Основное внимание должно быть уделено созданию и последовательному улучшению прототипа ПО. Потребуется очень быстро пересматривать структуру ПО в процессе разработки, привлечь для тестирования реальных пользователей и обновить требования до начала этапа планирования.
Ячейка 2. Ряд возможностей ПО, созданного конкурентами, предвосхищают нужды потребителей, поэтому хотелось бы наверстать упущенное. Следует изучить предложения конкурентов, понять, что они сделали правильно, а что — нет, и извлечь урок из допущенных ими ошибок. Риск, связанный с требованиями из этой ячейки, меньше в сравнении с риском в ячейке 1, так как уже существуют программные продукты, способные стать материалом для изучения и извлечения уроков. Однако следует ожидать быстрого изменения рынка и потребностей клиентов, поэтому, прежде чем перейти к формализации требований и созданию плана проекта, придётся затратить много усилий на моделирование технических характеристик и анализ удобства использования.
Ячейка 3. Наверное, реализация требований из этой ячейки доставит меньше всего хлопот, так как нужно предоставить уникальный в отраслевом масштабе набор возможностей без риска ошибиться в прогнозе тенденций рынка. Поскольку вы работаете с хорошо известным и заслуживающим доверия заказчиком, риск при разработке ПО такого типа обычно связан с верной реализацией функций и своевременным завершением разработки, а не с применением инновационных технологий.
Ячейка 4. Тактика заключается в расширении функциональности продукта, который уже поставляют конкуренты. Риск в случае такого ПО должен быть относительно невелик, так как вы работаете в основном с хорошо известными функциями и технологиями на устоявшемся рынке. Поскольку риск столь мал, на тестирование удобства использования и последовательное улучшение прототипа уйдёт меньше времени, чем в других случаях.
Помните: задача — обеспечение желаемого коммерческого эффекта при реализации сформулированных вами требований. Хотя вполне можно создать набор требований, распределяющийся по ячейкам таблицы практически поровну, в общем случае это нежелательно, поскольку так можно легко отойти от намеченной цели. Намного лучше сосредоточить большинство требований в одной из ячеек, а остальные требования разместить ещё в одной-двух ячейках.
Определение приоритетов
Определив и проанализировав требования, вы вплотную приблизились к обладанию полным набором функциональности. Но, прежде чем идти дальше, нужно задать приоритеты требований. Это поможет заранее оценить важность каждого требования и понять, как они связаны с другими требованиями.
Почему это так важно
Расстановка приоритетов определяет планирование и распределение задач. Вообще при планировании стараются наметить окончание реализации наиболее критичных требований на максимально ранние сроки. Если сначала сконцентрировать усилия команды на воплощении самых важных требований, можно снизить неопределённый риск, неизбежно присутствующий в любом плане. После завершения реализации критичных функций новая программа уже будет жизнеспособной. Если на этом этапе придётся сжимать сроки или вносить непредвиденные изменения, то вы окажетесь в выигрышном положении и сможете быстро завершить работу над новым выпуском программы, так как её основные функции будут уже готовы.
Коллектив должен заранее прийти к соглашению об уровне приоритета каждого из требований. Лучше, чтобы в момент принятия трудных решений (если такой момент настанет) об исключении той или иной функции вами не владели эмоции и напряжённость ситуации, что может сказаться на принятии решения. Не должно быть никаких сомнений в том, какие функции обязательны, а какие — нет. Приоритетные функции данного выпуска должны быть ясны каждому участнику проекта.
Как это делается
Каждому требованию должен быть назначен тот или иной приоритет. Детализация приоритетов может быть любой, в зависимости от потребностей. Уровни приоритета можно определить следующим образом:
• Необходимые
Обязательно должны быть воплощены в программе, без этого её нельзя выпускать на рынок. Необходимые функции должны быть реализованы и испытаны как можно раньше; этому нужно уделить максимум внимания и все ресурсы.
• Желательные
Присутствие этих требований крайне желательно. При достаточном обосновании от их реализации можно отказаться, но это не уменьшает важности их наличия в программе. Реализация и испытания желательных требований начинается сразу после обязательных.
• Возможные
Эти требования также желательны, но реализуются в последнюю очередь и являются первыми кандидатурами на удаление, если вдруг возникнут проблемы со сроками.
Утверждение требований
Многие ошибочно считают, что сформулировав требования, они готовы к распределению заданий и планированию проекта. Это не так. Нужно выполнить ещё два важных действия: провести техническую экспертизу основных факторов риска, связанных с технологиями, и создать прототип пользовательского интерфейса вашей программы. См. об этом главы 9 и 10.
Представим на минуту, что прототип пользовательского интерфейса уже готов и технологическая экспертиза закончена. Готовы ли вы поставить свою подпись на списке требований? Ещё нет. Нельзя утверждать требования, пока не составлен план работы. Может оказаться, что на исполнение плана должно уйти слишком много времени, и придётся отказаться от реализации части требований.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Детализация требований
Ещё одна проблема, которую придётся решить, — насколько подробно нужно формулировать требования. Разумеется, в данном случае задача в том, чтобы определение было как можно полнее: чем подробнее описано требование, тем легче следить за ходом его реализации. Чем больше аспектов определено заранее, тем больше параллелизма в работе разработчиков и групп, отвечающих за тестирование, обучение пользователей и выпуск программного продукта, так как тогда им проще понять, какой продукт создаётся. Однако часто подробно документировать требования очень трудно и даже невозможно, так как приходится работать в незнакомых областях (так чаще всего и бывает при работе над программными проектами). Как правило, чтобы понять, что именно пытаются создать участники проекта, приходится изрядно поэкспериментировать и испробовать много новых идей. Бывает и так, что поставленная цель оказывается вовсе недостижима. Ниже я опишу способ, позволяющий согласовать потребности в эксперименте и в документировании требований к проекту.
Недостаточно подробное определение обычно является следствием недостаточного понимания. Если недостающие сведения относятся к маркетингу или другим вопросам бизнеса, то разработчики мало чем помогут — это работа менеджера проекта и менеджера по маркетингу. Однако при нехватке сведений о реализуемых функциях, например, когда неясно, как работает та или иная функция, откуда берётся информация или чего хочет пользователь, можно создать прототип пользовательского интерфейса, иллюстрирующий внешний вид этих функций. Если недостающая информация касается технических возможностей, скажем, может ли программный продукт выполнять те или иные действия, можно провести анализ технической осуществимости, а затем создать прототип. Вот как свести воедино информацию из реального мира, экспериментальную работу и творческий процесс в процесс формулирования требований, прежде чем перейти к планированию (рис. 8-1).
Главная идея в том, чтобы заранее выяснить места возможного риска и до начала работы над проектом разработать решения потенциальных проблем. Анализ осуществимости и прототипы пользовательского интерфейса помогут понять суть проблемы, оценить потребности и снизить общий риск. Эти методики обеспечивают процесс формулирования требований обратной связью с внешним миром и позволяют составлять более детальные планы.
Рис. 8-1. Связь между требованиями, практичностью и созданием прототипа.
О базовых методиках анализа технического риска и создания прототипов пользовательского интерфейса, а также их использование для формулирования оптимальных требований см. главы 9 и 10.
Анализ требований
Когда требования сформулированы, но ещё не утверждены, разумно проанализировать их в целом и каждое по отдельности. Требования к новой программе нужно отбирать очень тщательно. Многие просто берут список требований, не анализируя его с точки зрения коммерческой привлекательности и не удаляя всё, что не вписывается в центральную идею проекта. В итоге получаются программы с плохо организованной функциональностью, не соответствующей назначению программы. Оценке требований и поиску направления, в котором движется разработка вашей программы, должно уделять большое внимание.
«Фрагментация» требований
Отойти от намеченного пути при формулировании требований легко. Так бывает, когда упрямый индивид или целая группа уводит «фокус» требований совсем в другую сторону, чем было задумано. Возможно, было легче формулировать требования для тех функций, определить которые было проще всего. Может оказаться и так, что требования сопряжены с чрезмерным для таких программ риском. Как бы ни было, обязательно должны присутствовать объективный взгляд на требования и оценка их влияния на ход проекта.
Категории требований
Ниже описаны четыре категории требований.
• «Опережающие» и «догоняющие» требования
Первые позволяют продукту обогнать конкурентов по рынку. Они могут описывать просто новое представление данных или возможность поддержки новой платформы. Им не обязательно быть революционными — достаточно, что они дают преимущество в конкуренции на момент выхода программы на рынок. Вторые подтягивают функциональность программы до уровня конкурентов. Они призваны сохранить конкурентоспособность и связаны с решением проблем сбыта и технической поддержки.
Разделение требований на категории «опережающих» и «догоняющих» позволяет проанализировать конкурентоспособность вашей программы. Например, если выяснилось, что в программе реализовано слишком мало опережающих требований или их вообще нет, можно реализовать дополнительные опережающие требования. Стратегия разработки программ в NuMega всегда включает ряд особенностей, которые делают программу уникальной на рынке и позволяют ей стать или остаться, так сказать, «чемпионом породы».
• Перспективные и ретроспективные требования
Последние направлены на решение проблем, связанных с прошлыми выпусками ПО. Например, для решения проблем с производительностью и удобством использования в последнем выпуске в общем случае служат ретроспективные требования. Так как эти требования — не что иное, как реакция на существующий продукт в существующем окружении, их реализация позволяет улучшить продукт, но не предвосхитить будущие потребности.
Перспективные требования позволяют заранее побеспокоиться о будущих потребностях заказчика. Они основаны на уверенности в том, что заказчик обязательно изменит свои потребности и желания, даже если сам он ещё об этом не знает. Часто перспективные требования базируются на крупномасштабных изменениях в деловой практике (например, на повсеместном внедрении размещения заказов через Web), технологиях (появление платформ, поддерживающих беспроводную связь) или рынка (слияние двух конкурировавших фирм). Перспективные требования труднее всего сформулировать, но, если удастся верно предугадать нужды потребителя и не ошибиться с выбором рынка и функций ПО, результатом будет значительное преимущество перед конкурентами.
Подборка ретроспективных и перспективных требований должна соответствовать потребностям, которые призван удовлетворить продукт, особенностям рынка и задачам выпуска. Скажем, можно быстро (за полгода) подготовить выпуск, в котором будет реализован ряд ретроспективных требований, а также включить в него несколько перспективных требований, чтобы не упустить какую-то интересную возможность.
Перспективные требования вовсе не обязательно являются копией опережающих. Перспективные требования именно предвосхищают потребности, в то время как опережающее требование может быть основано на текущих потребностях клиента, оставленных без внимания конкурентами. Так, введение поддержки диаграмм и графиков и нового одноэтапного процесса ввода данных можно считать опережающими, но никак не перспективными. С другой стороны, поддержку карманных компьютеров можно одновременно рассматривать, как опережающее и как перспективное требование, которое приносит двойную выгоду.
Наглядное представление требований
Чтобы понять сформулированные требования в общем, можно использовать таблицу для анализа требований, расписав их по ячейкам таблицы. Эта таблица имеет вид квадрата. поделённого на четыре равные части. Ниже по одной оси находятся догоняющие и опережающие требования, а по другой — перспективные и ретроспективные требования (рис. 8-2).
Рис. 8-2. Набор требований, представленный в виде таблицы из четырёх ячеек.
Далее приводится описание содержимого каждой ячейки таблицы. Расписав собственные требования по ячейкам такой таблицы, вы поймёте, в каком направлении пойдёт работа.
Ячейка 1. Вы предвидите будущие потребности потребителей и будете первым производителем, предоставившим соответствующее решение. Эти потребности пока ещё не до конца поняты и не полностью установлены. Вы первопроходец в этой области, поэтому уровень риска довольно высок. Из-за множества «неизвестных» нельзя заранее предоставить подробное определение требований. Основное внимание должно быть уделено созданию и последовательному улучшению прототипа ПО. Потребуется очень быстро пересматривать структуру ПО в процессе разработки, привлечь для тестирования реальных пользователей и обновить требования до начала этапа планирования.
Ячейка 2. Ряд возможностей ПО, созданного конкурентами, предвосхищают нужды потребителей, поэтому хотелось бы наверстать упущенное. Следует изучить предложения конкурентов, понять, что они сделали правильно, а что — нет, и извлечь урок из допущенных ими ошибок. Риск, связанный с требованиями из этой ячейки, меньше в сравнении с риском в ячейке 1, так как уже существуют программные продукты, способные стать материалом для изучения и извлечения уроков. Однако следует ожидать быстрого изменения рынка и потребностей клиентов, поэтому, прежде чем перейти к формализации требований и созданию плана проекта, придётся затратить много усилий на моделирование технических характеристик и анализ удобства использования.
Ячейка 3. Наверное, реализация требований из этой ячейки доставит меньше всего хлопот, так как нужно предоставить уникальный в отраслевом масштабе набор возможностей без риска ошибиться в прогнозе тенденций рынка. Поскольку вы работаете с хорошо известным и заслуживающим доверия заказчиком, риск при разработке ПО такого типа обычно связан с верной реализацией функций и своевременным завершением разработки, а не с применением инновационных технологий.
Ячейка 4. Тактика заключается в расширении функциональности продукта, который уже поставляют конкуренты. Риск в случае такого ПО должен быть относительно невелик, так как вы работаете в основном с хорошо известными функциями и технологиями на устоявшемся рынке. Поскольку риск столь мал, на тестирование удобства использования и последовательное улучшение прототипа уйдёт меньше времени, чем в других случаях.
Помните: задача — обеспечение желаемого коммерческого эффекта при реализации сформулированных вами требований. Хотя вполне можно создать набор требований, распределяющийся по ячейкам таблицы практически поровну, в общем случае это нежелательно, поскольку так можно легко отойти от намеченной цели. Намного лучше сосредоточить большинство требований в одной из ячеек, а остальные требования разместить ещё в одной-двух ячейках.
Определение приоритетов
Определив и проанализировав требования, вы вплотную приблизились к обладанию полным набором функциональности. Но, прежде чем идти дальше, нужно задать приоритеты требований. Это поможет заранее оценить важность каждого требования и понять, как они связаны с другими требованиями.
Почему это так важно
Расстановка приоритетов определяет планирование и распределение задач. Вообще при планировании стараются наметить окончание реализации наиболее критичных требований на максимально ранние сроки. Если сначала сконцентрировать усилия команды на воплощении самых важных требований, можно снизить неопределённый риск, неизбежно присутствующий в любом плане. После завершения реализации критичных функций новая программа уже будет жизнеспособной. Если на этом этапе придётся сжимать сроки или вносить непредвиденные изменения, то вы окажетесь в выигрышном положении и сможете быстро завершить работу над новым выпуском программы, так как её основные функции будут уже готовы.
Коллектив должен заранее прийти к соглашению об уровне приоритета каждого из требований. Лучше, чтобы в момент принятия трудных решений (если такой момент настанет) об исключении той или иной функции вами не владели эмоции и напряжённость ситуации, что может сказаться на принятии решения. Не должно быть никаких сомнений в том, какие функции обязательны, а какие — нет. Приоритетные функции данного выпуска должны быть ясны каждому участнику проекта.
Как это делается
Каждому требованию должен быть назначен тот или иной приоритет. Детализация приоритетов может быть любой, в зависимости от потребностей. Уровни приоритета можно определить следующим образом:
• Необходимые
Обязательно должны быть воплощены в программе, без этого её нельзя выпускать на рынок. Необходимые функции должны быть реализованы и испытаны как можно раньше; этому нужно уделить максимум внимания и все ресурсы.
• Желательные
Присутствие этих требований крайне желательно. При достаточном обосновании от их реализации можно отказаться, но это не уменьшает важности их наличия в программе. Реализация и испытания желательных требований начинается сразу после обязательных.
• Возможные
Эти требования также желательны, но реализуются в последнюю очередь и являются первыми кандидатурами на удаление, если вдруг возникнут проблемы со сроками.
Утверждение требований
Многие ошибочно считают, что сформулировав требования, они готовы к распределению заданий и планированию проекта. Это не так. Нужно выполнить ещё два важных действия: провести техническую экспертизу основных факторов риска, связанных с технологиями, и создать прототип пользовательского интерфейса вашей программы. См. об этом главы 9 и 10.
Представим на минуту, что прототип пользовательского интерфейса уже готов и технологическая экспертиза закончена. Готовы ли вы поставить свою подпись на списке требований? Ещё нет. Нельзя утверждать требования, пока не составлен план работы. Может оказаться, что на исполнение плана должно уйти слишком много времени, и придётся отказаться от реализации части требований.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36