Нет техдокументации — нет доработок

В последнее время волею судеб я часто читаю статьи об интерьерном дизайне и ремонте. И не удивительно (проектная работа во всех отраслях одинакова), что я нахожу множество параллелей в заявленных в них проблемах с моей работой. Помню, совсем недавно читала гневную статью дизайнера про клиентов, которые мало того, что «не заказывают разработку проектов коммуникаций (электрики, сантехники, слаботочки), но и не ведут фотоотчет по прокладке этих самых коммуникаций». Далее шел крик души дизайнера:

«Даже гвоздь под картину не забить — все как по минному полю! То о силовой кабель шиндарахнешься, то интернета клиента лишишь.»

50% моих клиентов на сопровождении — это то самое «минное поле»! Если прошло качественное внедрение и разработка, то вряд ли потребуется регулярное обслуживание и так хорошо налаженной системы, и тем менее вероятно, что Вы захотите поменять подрядчика при подключении нового функционала, если предыдущий подрядчик качественно наладил вам текущий функционал.

И тем более странно, что именно с такими клиентами приходится проводить очень много разъяснительных бесед о необходимости создания технической документации, прежде чем хоть что-то внедрять и дорабатывать: Отчета о предпроектном обследовании, Отчета о техническом аудите, Концептуальной модели учета и КАЧЕСТВЕННОГО ТЕХНИЧЕСКОГО ЗАДАНИЯ.

У меня сейчас есть постоянный клиент, которому я все-таки (через пол года после первичной встречи) доказала в начале работы, что мои запланированные работы по созданию этой документации — это не попытка выкачать из клиента денег и заменить часы программиста дорогостоящими человеко-часами бизнес-аналитика, а необходимая проектная дисциплина.

Казалось бы — фух, теперь все будет правильно и гладко!

НО…

Каждый раз, при внедрении элементарного функционала, я сталкиваюсь с вопросом: «Это не работает на базе заказчика, потому что:

а) КАК-ТО И ЗАЧЕМ-ТО был изменен этот типовой функционал, и то, что у меня отрабатывает на Демо-базе типовой конфигурации никогда без доработок не отработает на базе заказчика?

б) Релиз устарел на 2 года, а у меня в копилке последнего опыта гораздо более современные релизы. И хоть функционал нужен здесь и сейчас, необходимо дождаться, пока пройдет трудоемкая работа программиста, который пытается при обновлении релиза сохранить работоспособность того (имеются в виду доработки типового функционала), что никто не знает КАК и ЗАЧЕМ работает, и не менее трудоемкая работа тестера?

в) Я вконец отупела при проверке этого функционала на 4-х базах (Демо-базе поставки типовой конфигурации, рабочей базе заказчика, тестовой базе заказчика, обновленной до нового релиза тестовой базе заказчика) и не вижу глупой пользовательской ошибки?»

Вот и бегаю я с примитивным гвоздем вдоль стенки заказчика несколько часов оплачиваемого им времени.

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

Ваш адрес email не будет опубликован.