JК
Журнал Компьютерра - 14 от 11 апреля 2006 года :: Компьютерра
Страница: 187 из 191Другое дело, что процессом изменений надо грамотно и четко управлять.
А касательно применения подписи в качестве инструмента давления на заказчика ситуация абсолютно аналогична аудиозаписям.
Пример из практики
При разработке сложной автоматизированной системы заказчик пожелал изменить функциональность одной из подсистем, чем сообщил разработчикам по электронной почте. Разработчики, тоже по e-mail, задали уточняющие вопросы. Завязалась переписка. В конце концов, все вопросы были улажены, заказчик еще раз прислал письмо, с более четкой постановкой задачи. Началась работа.
Спустя некоторое время, во время опытной эксплуатации системы, заказчик заявил, что функционал, о котором говорилось выше, «не соответствует заявленному». Начали разбираться. Выяснили, что то, что хочет заказчик, соответствует тому, что написано в документе требований. Тогда стали вспоминать, на основании чего реализовали не так. Подняли переписку. Нашли то самое письмо с финальной постановкой задачи. Продемонстрировали заказчику. В ответ получили формулировку: «У нас есть подписанный документ, а рабочая переписка документом не является. Поэтому вы не должны были на ее основании проводить разработку». Вот так. Некоторое время спустя выяснилась причина такого поведения. Дело в том, что не до конца отлаженные бизнес-процессы заказчика постоянно изменялись. На момент постановки задачи было одно видение, потом эта позиция была пересмотрена, так родилось злополучное письмо.
А касательно применения подписи в качестве инструмента давления на заказчика ситуация абсолютно аналогична аудиозаписям.
Пример из практики
При разработке сложной автоматизированной системы заказчик пожелал изменить функциональность одной из подсистем, чем сообщил разработчикам по электронной почте. Разработчики, тоже по e-mail, задали уточняющие вопросы. Завязалась переписка. В конце концов, все вопросы были улажены, заказчик еще раз прислал письмо, с более четкой постановкой задачи. Началась работа.
Спустя некоторое время, во время опытной эксплуатации системы, заказчик заявил, что функционал, о котором говорилось выше, «не соответствует заявленному». Начали разбираться. Выяснили, что то, что хочет заказчик, соответствует тому, что написано в документе требований. Тогда стали вспоминать, на основании чего реализовали не так. Подняли переписку. Нашли то самое письмо с финальной постановкой задачи. Продемонстрировали заказчику. В ответ получили формулировку: «У нас есть подписанный документ, а рабочая переписка документом не является. Поэтому вы не должны были на ее основании проводить разработку». Вот так. Некоторое время спустя выяснилась причина такого поведения. Дело в том, что не до конца отлаженные бизнес-процессы заказчика постоянно изменялись. На момент постановки задачи было одно видение, потом эта позиция была пересмотрена, так родилось злополучное письмо.