Вопрос из зала: постоянные изменения требований

Нам пишут о наболевшем:

Уже довольно давно идёт проект разработки информационной системы. Руководство не может справиться с заказчиками: на любом этапе разработки продукта могут появиться (и появляются) новые требования или измениться уже утвержденные.

Это разрушает порядок в разработке, порождает множество ошибок, заставляет переделывать работу по нескольку раз, что в свою очередь, увеличивает сроки и отнимает ресурсы. Как быть?

Коллеги, поделитесь опытом и удачными примерами подходов, которые помогли выстроить взаимотношения.

6747-strip

PRINCE2 Управление ИТ-проектами на основе PRINCE2

Трёхдневный аккредитованный учебный курс с интерактивным кейсом.
 

Узнайте больше!

Комментарии и мнения

  1. Денис Денисов

    Давайте задумаемся, что значит "справляться с заказчиками". Вариантов, на мой взгляд, два. Первый — "загнать" заказчиков в знакомую и понятную текущую систему. Второй — пересмотреть свой подход к принципам организации разработки в организации, построив новую или "улучшенную" систему. Как мне кажется, автор вопроса тяготеет к первому варианту разрешения конфликтной ситуации, вопрос в средствах убеждения.

    Однако, мир в очередной раз (и давно уже) изменился. Статичная (каскадная, «waterfall) разработка отходит на второй план, гибкая («agile») выходит на первый. Бизнесу нужна скорость вывода новых решений на рынок, поэтому соответствующие требования транслируются и на ИТ. ИТ же продолжают по старинке, как привыкли: «с чувством, с толком, с расстановкой». Но ведь важна не разработка ради "правильной" разработки, а так выстроенная деятельность по разработке, что отвечала бы изменчивым и частым требованиям.

    Вероятно, среди бизнес-подразделений в организации начали появляться заказчики нового типа: "старых" устраивает «водопад», а "новым" «скорость» подавай. А ИТ пока что «односкоростные», заточенные под первых. Вторых это, естественно, не устраивает. Нужно отвечать потребностям и тех, и других, становиться "многоскоростными". Моё предложение — посмотреть в сторону методологий гибкой разработки, а затем оценить, что найдёт применение в конкретной организации.

        1. Алексей Юсов

          Олег,

          Не работал в таких компаниях сам лично, но рискну предположить, что с учётом динамики нашего законодательства (если IDM должен решать задачи в том числе и этих соответствий, к примеру), это будет не 3 года, а просто "вечный кайф" для интегратора-внедренца )).

          А уж что-то "бизнесовое" — три года при сегодняшней свистопляске динамике экономики — это просто несерьёзно.

          PS Жаль, что на ближайший ваш Agile-курс у нас не получилось — по времени нестыковочка вышла :(.

  2. Николай Рямзин

    «Как бы нам научиться «вытряхивать» из представителей Заказчика полную и качественную информацию на стадии сбора требований. Чтобы собрать все их требования, затем утвердить и «заморозить» (т.е. запретить изменения списка требований до самого конца проекта)». После очередного провала мы порой возвращаемся к обсуждению этой проблемы: «У нас просто порядка не хватает». Многие пытались навести порядок, утверждали жесткие регламенты, но полностью решить проблему НИ У КОГО не получилось.

     Решение было найдено в рамках новой философии разработки software, которая появилась конце 80-х годов – начале 90-х годов прошлого века. Новый подход получил название Agile. Он предложил неожиданное решение данной проблемы, постулировав: собрать с самого начала все требования к новой программной системе и заморозить их НЕВОЗМОЖНО. И, кстати, НЕ НУЖНО! Философия Agile (и ее конкретные методики, такие как, например, Scrum) признает право Заказчика до самого конца разработки вносить новые требования и изменять старые. При этом попутно, Agile предлагает новые действенные подходы для решения таких традиционных задач, как – снижение основных рисков, мотивация разработчиков, формирование командного духа и коллективного владения кодом и, наконец, увеличение бизнес ценности продукта.

  3. Сергей

    Бизнес меняется — меняются и требования. Не нужно никого никуда загонять, нужно успевать реализовывать требования, чтобы они приносили отдачу здесь и сейчас. 

    А если квартал писать ТЗ, потом месяц его согласовывать, то через полгода от возникновения идеи уже задача может потерять актуальность и появятся новые требования, а мы тут только напрограммировали новый функционал...

  4. Дмитрий Исайченко

    Поскольку про Agile здесь уже отписались, добавлю немного с другой стороны. Помимо изменения подходов к организации труда, надо также оценить соответствие условиям решения задачи самой среды разработки. Какой подход ни используйте, а если Вы собираетесь с нуля написать ERP-систему на C, быстро не получится. И регулярные релизы на ранней стадии разработки заказчика тоже вряд ли осчастливят — он даже их содержание не сможет оценить.

    При работе с крупными системами Agile особенно хорош в режиме доработок (не создания с нуля) и при работе с RAD-платформами, позволяющими существенно сократить время на собственно кодинг. Вот тогда, действительно, вполне возможно жить в режиме относительно частых (2-4 недели) и небольших релизов, что обеспечивает и соответствие скорости мысли заказчика, и небольшое количество ошибок, помноженное на простоту их локализации.

    Все же в триаде people, processes, products про products тоже забывать нельзя. ИМХО.

  5. Андрей Яковлев

    Немного абстрактного. От Заказчика вообще-то глобально нужно одно — цель. Если она есть, то как еще достичь — технические детали. Это как в эволюционном планировании.  Допустим, нам надо получить сплав с заданными характеристиками, которые зависят от добавок. Проводить большое число плавок в промышленных масштабах слишком затратно. Варьировать состав надо так, чтобы избежать  брака, но — самое главное — на каждом этапе получать информацию, ведущую к оптимуму. Разница между химической технологией и автоматизацией или разработкой ПО в том, что в первом случае a  priori известно, что оценить влияние всех факторов заведомо невозможно, во втором, что все можно учесть сразу. Отсюда и разница в подходах — в первом случае после каждого шага делается коррекция. Долго, однако, доходили до того, что errare humanum est. Я просто к тому, что работы Бокса и Уилкинсона относятся к 1955 году. Потом кто-нибудь знает ИТ-проекты с участием психологов и социологов?

    1. Дмитрий Исайченко

      Потом кто-нибудь знает ИТ-проекты с участием психологов и социологов?

      Конечно. По крайней мере, психологическая помощь заказчику — штатная обязанность консультанта и дополнительная функция бизнес-аналитика 🙂

      1. Андрей Яковлев

        Я немного не о том. "Водопад" 100% сработает, если, PMом назначить Бендера (да-да, "Убить всех человеков"). Психолог для оценки рисков проекта от человеческого фактора. Звучит дико, но мне кажется разумным. В планировании эксперимента, например, "а туда ли мы идем" обосновывается статистическими методами.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20