УправТреб.рф - все для управления требованиями

В большинстве старых проектов требования либо не задокументированы вовсе, либо их точность оставляет желать лучшего. В таких случаях разработчикам приходится заниматься обратной инженерией, чтобы понять, как всё работает. Этот процесс мы называем «археологией проекта» 🧐 👉 Чтобы обратная инженерия была эффективной, необходимо документировать результаты исследований в форме описания требований. Это позволит команде разработчиков безопасно доработать или заменить продукт, не потеряв критически важную функциональность. Однако многие разработчики считают, что документирование требований занимает слишком много времени. Из-за этого возникает условный рефлекс — пренебрегать обновлением документации. Но стоит задуматься о том, сколько времени и сил потребуется специалисту, чтобы восстановить утерянную информацию 😒 При доработке или замене системы важно постоянно улучшать документацию. Это позволит избежать потери критически важной информации и облегчит обслуживание системы в будущем 💯 Важно помнить, что при реализации доработок практически всегда требуется разработка новых требований. Поэтому необходимо добавлять эти требования в хранилище существующих, если таковое имеется. А при замене старой системы можно задокументировать требования к новой и поддерживать их в актуальном состоянии на протяжении всего проекта 😉

При разработке проектов по доработке или замене, обязательно надо учитывать, что у пользователей уже сформированы определённые ожидания от продукта посредством его прошлой версии. 👉 И соответственно, у заинтересованных лиц всегда должны быть ключевые показатели эффективности (KPI), которые они хотят сохранить в новом проекте. Необходимо расставить приоритеты коэффициентов KPI, которые важнее всего поддерживать. Важно выявить бизнес-процессы, связанные с самыми важными KPI, и требования, обеспечивающие реализацию этих бизнес-процессов 👌 Таким образом, модель KPI помогает заинтересованным лицам увидеть, что, несмотря на изменения, бизнес-результаты должны быть, как минимум, не хуже 😉

В продолжение вчерашнему посту мы решили привести конкретные примеры анализа расхождений, чтобы вы ориентировались, как его можно применить на практике 👌 👉 В существующем продукте есть функция «Добавить товар в корзину», но нет функции «Оформить заказ». Это значит, что существующий продукт не соответствует требованию «Возможность оформления заказа». Или, например, в существующем продукте есть функция «Поиск товара», но она работает медленно и не всегда корректно. Это значит, что продукт не удовлетворяет требованию «Быстрый и точный поиск товара». То есть, можно сделать следующий вывод - анализ расхождений позволяет выявить слабые места существующего продукта и определить, какие изменения нужно внести, чтобы улучшить её работу 😌

При разработке проекта замены первым, что в принципе и логично, возникает вопрос - а что, собственно, нужно изменить? И как раз тут на помощь приходит анализ расхождений 🧐 👉 Анализ расхождений (gap analysis) — это сравнение функциональности между существующим и желаемым новым продуктом. Он позволяет понять, какие изменения нужно внести в систему, чтобы она соответствовала новым требованиям и бизнес-целям. Как провести анализ расхождений: 1️⃣ Определите пользовательские требования к существующему продукту. 2️⃣ Определите, каким новым требованиям должен соответствовать новый продукт. 3️⃣ Сравните существующие и новые требования. 4️⃣ Определите, какие требования не выполняются в существующем продукте. 5️⃣ Расставьте приоритеты существующих и новых требований. 6️⃣ Определите приоритеты устранения расхождений с использованием бизнес-целей или других методов определения приоритетов. В общем и целом, можно сказать, что анализ расхождений помогает понять, почему текущий продукт не соответствует бизнес-целям, и определить, какие изменения нужно внести. Это важный этап в процессе разработки и модернизации систем 😌

Проекты доработки и замены зачастую получаются особенно успешными. Ведь они позволяют добавить новые возможности в существующий продукт и при этом перенести существующую функциональность. Однако при работе над такими проектами важно избегать добавления ненужных функций. Тут важно не переусердствовать, как говорится 🤪 ❓ Как избежать добавления ненужных функций? 1️⃣ Отслеживайте связи требований с бизнес-целями. Это поможет понять, какие функции действительно нужны клиентам и бизнесу. 2️⃣ Определяйте приоритеты запросов на доработку. Это позволит сосредоточиться на наиболее важных функциях и избежать распыления ресурсов. 3️⃣ Внимательно следите за проектами замены. Основная задача таких проектов — перенести существующую функциональность. Добавление новых функций должно быть обосновано бизнес-целями. 4️⃣ Ищите существующую функциональность, которую можно удалить. Это поможет избежать дублирования функций и упростит систему. 5️⃣ Обновляйте систему в соответствии с новыми бизнес-потребностями. Это позволит компании оставаться конкурентоспособной и удовлетворять меняющиеся потребности клиентов. 6️⃣ Не допускайте аргументацию типа «это есть сейчас, поэтому оно должно быть в новом продукте». Такой подход может привести к добавлению ненужных функций и увеличению сложности системы. Следуя этим рекомендациям, вы сможете создать эффективную и удобную систему, которая будет соответствовать потребностям пользователей и бизнеса 😉

В проектах доработки или замены существующей системы все говорят, как важно уделить ОСОБОЕ ВНИМАНИЕ работе с требованиями. А в чём это внимание должно, собственно, заключаться? 🧐 Сейчас мы ответим на этот вопрос для вас и представим ценные приёмы, которые помогут эффективно разработать требования в проектах доработки: 👉 Создание дерева функций — позволяет наглядно представить изменения в проекте и выявить функции, которые будут добавлены или удалены. 👉 Определение классов пользователей — помогает оценить, на кого повлияют изменения, и выявить новые группы пользователей. 👉 Определение бизнес-процессов — даёт понимание того, как текущий проект вплетен в повседневную деятельность организации и как изменения повлияют на эти процессы. 👉 Документирование бизнес-правил — фиксирует правила, которые уже присутствуют в системе, и выявляет новые, которые необходимо учесть. 👉 Определение приоритетов функциональности — помогает определить наиболее важные функции для нового проекта. 👉 Определение атрибутов качества — обеспечивает соответствие нового проекта ожиданиям по качеству. 👉 Создание таблиц отчётов — конвертирует существующие отчёты, которые по-прежнему нужны, и определяет новые отчёты, которых нет в старом проекте. Перечисленные приёмы помогут вам обеспечить эффективное управление изменениями и минимизировать риски при разработке нового проекта 😉

При работе с существующими системами разработчики сталкиваются с рядом трудностей, которые необходимо учитывать при планировании проектов доработки или замены. Чтобы предостеречь вас от распространённых ошибок, давайте сегодня их обсудим 😉 1️⃣ Первое, что может вызвать затруднения - это снижение производительности. Внесённые изменения могут привести к снижению производительности системы, что негативно скажется на удобстве использования. 2️⃣ Также проблемой может стать недостаточная документация. Существующая документация может быть неполной или неактуальной, что затруднит понимание текущего состояния продукта и его дальнейшее развитие. 3️⃣ Неприятие изменений пользователями. Пользователи, привыкшие к текущей системе, могут негативно отнестись к изменениям, даже если они направлены на улучшение работы. 4️⃣ Пропуск важной функциональности. Из-за недостаточного понимания системы или невнимательности можно пропустить важные функции, которые необходимы пользователям. 5️⃣ Запросы на ненужную функциональность. Заинтересованные лица могут запрашивать новые функции, которые не соответствуют бизнес-целям проекта. 6️⃣ Сложности при замене систем. При замене систем необходимо тщательно проверять требования и переносить только необходимую функциональность, чтобы избежать лишних затрат и сложностей при интеграции. 7️⃣ Изменение бизнес-процессов. Полная замена системы может потребовать изменения бизнес-процессов и организационной структуры, что может вызвать сопротивление со стороны сотрудников. В общем, важно тщательно планировать проекты доработки и замены систем, заранее учитывая если не все, то хотя бы основные возможные трудности и разрабатывая стратегии для их преодоления 👌

При разработке проекта важно чётко формулировать требования к продукту. Однако иногда возникают ситуации, когда документация оказывается неполной или отсутствует вовсе 😒 Приведём пример из практики: Бизнес-аналитик столкнулась с проблемой недостающей спецификации при работе над пятой версией важного продукта. В спецификации требований было указано, что новая система должна делать то же, что и предыдущая, с добавлением новых функций и исправлением ошибок 👌 Чтобы понять, что именно делает текущая версия, аналитик обратилась к спецификации четвёртой версии. Там было указано, что четвёртая версия должна делать то же, что и третья, с добавлением новых функций и исправлением ошибок 🤔 Аналитик подняла все предыдущие документы, но так и не нашла исходную спецификацию требований. В каждой спецификации перечислялись отличия новой версии от предыдущей, но нигде не было описания первоначальной системы 🚫 👉 Если вы оказались в подобной ситуации, важно задокументировать требования для следующей версии более подробно, чтобы все заинтересованные лица — настоящие и будущие — смогли разобраться в том, что же всё-таки система делает!

Часто, после запуска проекта становятся очевидны слабые места и ошибки, хочется доработать, докрутить и выпустить новый проект, уже с учётом всех особенностей 🧐 И вот тут как раз появляются они: 👉 Проекты по доработке (enhancement project) предполагают добавление новых функций в существующий продукт. Это может быть устранение дефектов, добавление новых отчётов или модификация функциональности в соответствии с изменившимися бизнес-правилами. 👉 Проекты по замене (реинжиниринг) подразумевают полную замену существующего продукта на новую версию, разработанную с нуля, серийную систему или комбинацию этих решений. Такие проекты часто реализуются для повышения производительности, сокращения затрат, применения современных технологий или выполнения требований регулирующих органов. В обоих типах проектов есть свои особенности работы с требованиями. Важно помнить, что разработчиков, которые изначально создавали систему и знали её досконально, уже может не быть в команде. Поэтому не стоит пренебрегать написанием требований даже при внесении небольших изменений 👌 В ближайшее время мы рассмотрим особенности таких обновлённых проектов и дадим рекомендации по их успешной разработке 😉

Днём мы начали говорить о переходе к гибкой разработке, и сразу хотим вас предупредить - такой переход может быть сложным процессом, особенно если он осуществляется без учёта особенностей компании и проекта 😒 Например, в одной организации попытка внедрения гибкой разработки привела к неудаче... 👉 Руководство решило перевести всю компанию на новый метод работы, однако многие разработчики стали слишком строго следовать принципам гибкой разработки. Они настаивали на использовании только карт с историями и отказывались от любой другой документации. Такой подход не нашёл поддержки у всех заинтересованных сторон. Некоторые приёмы гибкой разработки оказались неприменимы из-за масштабов проектов. В результате новые проекты потерпели неудачу, и руководство решило вернуться к традиционной модели разработки 👌 Однако разработчики поняли, что возврат к старой системе тоже приведёт к проблемам. Они начали применять смешанный подход, используя элементы гибкой разработки. Проекты были разделены на трёхнедельные циклы, а требования приоритизировались 📊 Итог всей этой истории таков - большинство принципов гибкой разработки успешно применялись в компании, но только после того, как разработчики научились адаптировать их под свои нужды 😏

🧐 Если вы бизнес-аналитик и хотите перейти на гибкую разработку, не волнуйтесь: вы по-прежнему можете применять большинство привычных вам приёмов. А чтобы максимально упростить процесс перехода, дадим несколько важных советов: ✅ Определите свою роль в команде. В некоторых проектах гибкой разработки есть выделенный бизнес-аналитик, а в других задачи бизнес-аналитика выполняют другие люди. Поощряйте ориентацию членов команды на проект, а не на свои индивидуальные роли или должности. ✅ Выберите подходящие приёмы. Вспомните, какие приёмы разработки уже хорошо себя зарекомендовали в вашей организации, и продолжайте их применять. Поговорите с людьми, выполняющими другие роли в команде, и определите, как их приёмы работы применить в среде гибкой разработки. ✅ Начните с малого. Реализуйте один небольшой проект в качестве пилотного для обкатки методов гибкой разработки или внедрите несколько приёмов гибкой разработки в свой следующий проект. ✅ Обратитесь за помощью. Если вы новичок в гибкой разработке, пригласите опытного наставника, чтобы помочь вам избежать искушения вернуться к привычным приёмам работы. Ну и конечно, не будьте пуристом от гибкой разработки только из принципа. Гибкая разработка — это не самоцель, а инструмент для достижения целей проекта 😉

Если мы всё таки продолжим говорить о проектах гибкой разработки и раскрывать эту тему всё глубже, то можно заметить - большинство традиционных приёмов работы с требованиями легко адаптируются для проектов гибкой разработки ✔️ Для этого, скорее всего, потребуется изменить лишь время и объём их применения, а также лиц, участвующих в их реализации 🤔 Например, можно адаптировать метод тестирования, сделав его более гибким. Вместо того чтобы проводить тестирование после завершения разработки, можно тестировать каждый рабочий цикл отдельно. Это поможет выявить ошибки на ранних этапах и сэкономить время и ресурсы 😌