bas4all (bas4all) wrote,
bas4all
bas4all

Categories:

Как бороться с Изменениями Требований?!

В последнее время часто в разговорах всплывает вопрос про Изменение Требований - что делать как с этим бороться и кто виноват?!

Ну во первых я считаю что с эти не надо бороться, этим надо уметь управлять! А для того, чтобы понять как это - управлять, нужно понять почему происходят изменения вроде в хорошо проработанных и сто раз согласованных со всеми по кругу Требованиях. А вот почему:

  1. Заказчик не все рассказал, Аналитик не все вынул из заказчика или что-то понял не так. Потом, переложив на бумагу, Аналитик пропустил пару существенных моментов, а Заказчик подумал, что это и так всем ясно, ведь крыжить и округлять - это два естественных понятия для всех. А все еще усугубляется после того, как написанное Аналитиком поток сознания Требование прочитал Разработчик, и понял еще по третьему, а вопрос забыл, постеснялся или поленился задать. Потом реализовал Разработчик, как понял, и получили, что? Правильно, НЕ ТО, что хотел Заказчик. И нужно делать - что? Правильно, доработку. Кто виноват? Да все трое, в большей степени Аналитик кончено, п.ч. не до конца раскрутил выявил Требования у Заказчика и не изложил их в соответствии с Вигеросом для Разработчика. Или Аналитик вообще забыл про существенного человека от Заказчика и не учел его потребности и интересы.
  2. Заказчик изменил свое мнение или приоритеты. Например, Заказчик побывал на аникризисном семинаре, где ему сказали как улучшить тот или иной участок производства. Кто тут виноват - Заказчик и Аналитик. Заказчик п.ч. дундук не эффективный управляющий, а Аналитик, п.ч. не пытался выявить реальные проблемы, которые поможет решить ИС, а начал клепать ТЗ со слов Заказчика. Что делать? Правильно, прорабатывать лучше Концепцию, в которой указывать решаемые Проблемы и Цели автоматизации.
  3. Политические отношения в стане врага Заказчика. Например, единственный человек, который знает текущее ПО, противится его изменению и улучшению, т.к. он станет бесполезным. Кто виноват - МП (менеджер проекта) и топ менеджмент этого человека, т.к. не замотивировал его на данную работу. Что делать? Искать окольные пути, добывать информацию по крупицам, мотивировать таких людей, искать с ними общий язык.
  4. Произошли изменения в законодательстве или на рынке. Кто виноват? До по сути никто, кроме дорого и горячо любимого нашего не нашего Правительства. Что делать? Да ничего, кроме как не шерстить Законодательства и не быть в курсе будущих изменений, если они критичны для ИС.
  5. Наше разработанное ПО начали эксплуатировать и Заказчик понял, что теперь можно что-то еще улучшить. Кто виноват - хорошие МП, Аналитики, Разработчики, Тестировщики и т.д., т.к. наконец-то поставили ПО в промышленную эксплуатацию. Шутка конечно :) Что делать? Радоваться, значит у вас что-то получилось и Вы сможете сделать ще лучше.
В общем, риск изменения Требований можно уменьшить и даже существенно, но нельзя избежать совсем изменений требований. Да и в принципе, если у вас нет изменений, то Заказчик не вовлечен в процесс разработки и ваше ПО никому не нужно. Поэтому изменений не нужно бояться, ими нужно просто грамотно управлять. А как?

Как снизить риск изменения Требований:
  1. Обучайте Аналитиков, повышая их качество работы, и улучшайте процесс разработки ПО
  2. Создайте План Управления Требованиями.
  3. Более тщательно выявляйте Требования, применяя различные техники, подходящие в данный момент.
  4. Более тщательно анализируйте поступающую информацию, используя разные методики.
  5. Выявляйте всех ЗЛ (заинтересованных лиц) в проекте, их Проблемы, которые будете решать с помощью ПО, и Цели автоматизации. А Вы знаете что такое Цель? Почитайте на страничке boatmana про Целеполагание.
  6. А вообще стоит ли браться за автоматизацию?? Посчитайте невозврат от инвестиций (ROI) и опишите чем Ваше ПО будет лучше 1000 уже написанных программ с нужной Вам функциональностью.
  7. Более качественно пишите Требования, как завещали великие К. Маркс, Ф. Энгельс и В. Ленин К. Вигерс, А. Коберн и Д. Леффингуэлл.
  8. Более тщательно проверяйте Требования как со стороны Заказчика, так и со стороны Команды Разработки (Архитектор, Разработчик, Тестировщик)
Следуя 7ми описанным принципам выше, можно подумать, что я заставляю Читателя погрузиться на вечно в Требования и вылезти наружу только через пол года или год с идеальным ТЗ. Во все нет! Во-первых, идеального ТЗ никогда не получится, все равно Требования поменяются прежде чем Вы допишите 300от страничный бестселлер. Во-вторых, Я предлагаю вести разработку Итерационно. Сначала проработать хорошо Концепцию и понять весь масштаб бедствия крупно, а потом, приоритизировав крупные функциональные (пользовательские) требования, выбирать наиболее востребованные Бизнесом, их прорабатывать\детализировать и пускать в разработку и тестирование. Потом браться за следующий пул требований и так далее. Тем самым Вы уменьшаете время на разработку ТЗ и пускаете это время на реальную доработку ПО, а не на мифические буквы. Ведь мерилом всего является только работающее ПО, а не красивое ТЗ.

Собственно все это мы уже и так делаем, а Требования изменяются, что делать с изменениями? А вот что:
  1. Опишите процесс поступления и работы над изменениями, чтобы всем было ясно что, как и когда делаем.
  2. Принимайте все изменения через один канал и сохраняйте все запросы в одном реестре
  3. Приоритизируйте запросы на изменения. Если требования попадают в единый реестр, то их можно приоритизировать и делать наиболее важные, НЕ забывая об остальных. В этом случае легче разговаривать с Заказчиком и говорить ему, что мы ничего не забываем, а делаем сейчас наиболее важные, потом займемся и остальными. А остальные со временем могут сами отмереть или станут не такие важные как при звонке
  4. Анализируйте запросы на изменения. Поймите что нужно будет изменить, сколько это займет времени и средств. Это позволяет глубже проанализировать проблему, а не сразу реализовывать ее. Бывали случаи, что нужно внести изменения в отчет, а этот отчет использовался только для формирования другого, так не лучше убрать вообще первичный отчет и сразу формировать второй?!
  5. Не хватайтесь сразу за реализацию, а накопите изменения и делайте их скопом для одного куска, т.к. делать, так дешевле
  6. Разговаривайте с Заказчиком об разделении рисков между Разработчиком и Заказчиком, желательно заранее. Например 50% на 50% при появлении новых требований и возможно убедите Заказчика заплатить за фичи (features) не входящие в скоуп.
  7. Проводите Анализ ошибок, кто виноват - Аналитик, что не выявил требования или Пользователь, который хочет совершенно новую фичу. Может пересмотреть квалификацию Аналитика?!
  8. Проводите анализ частоты Изменений.Если одно и тоже требования часто меняется, то есть смысл задуматься - а в чем проблема, Аналитик дурак или у Заказчика бардак (не устоялся БП), а как известно автоматизация бардака - это автоматизированный бардак. Может отложить это требование?!
  9. Изменяйте первичные требования, а не пишите каждый раз новое ТЗ, получая кучу маленьких ТЗ на доработку, становится не понятно что же в конечном должна делать ИС.
  10. Оповещайте всех участников проекта об изменении.

И наверное последний вопрос, который хотелось здесь осветить - зачем мы проводим анализ Изменений, если они и так неизбежны и их придется делать, т.к. иначе не сдать ПО. А вот зачем:
  1. Чтобы понять самим сколько это займет времени и денег, чтобы спланировать работы
  2. Чтобы понять, какие куски ИС нам придется изменять и не порушит ли все это нашу Систему
  3. Чтобы делать наиболее востребованный Бизнесом функционал, который требует минимальных затрат. Ведь 80% результата дает всего 20% затрат.
  4. Чтобы были аргументы для убеждения Заказчика об увеличении сроков\бюджета или разделении рисков 50 на 50 или предложения альтернативного мене затратного варианта.
  5. Чтобы отличить - что действительно нужно Заказчику, а что является бантиком
  6. Чтобы согласовать мнение внутри команды разработки (Продавцы, МП, Аналитики и т.д.)
Естественно процесс принятия на выполнение того или иногда запроса на изменение очень связан с политическими играми и тут нужно не стесняться привлекать МП, т.к. он обладает большим опытом в уламывании переговорах с Заказчиком.
Tags: Анализ, Управление Требованиями
Subscribe

  • Post a new comment

    Error

    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments