Глава 38. Как долго рассчитывать стоимость доработки

В моей компании есть отделы продаж и отдел производства. Между ними, бывает, случаются противоречия. Отделы продаж, хорошо понимая, в какой конкурентной среде мы находимся, оценивают запросы на доработку исходя из рыночных условий и потенциальной ценности доработки для клиента. Отдел производства оценивает доработку исходя из предположения о трудоемкости ее выполнения.

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

Отдел продаж:

– Как 40 часов? Да мы сами – бывшие программисты, больше, чем на 16 часов эта доработка не тянет! Клиент побродит по рынку и найдет тех, кто сделает за 8!

Отдел производства:

– 40. Это мы сильно поджались, знали, что вам не понравится. А, вообще, там работы на все 80. Рисков много. Клиенты сейчас пошли капризные, да еще, наверняка, что-то забыли. Нам потом переделывать «за бесплатно».

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

В паспорт вошли следующие разделы и виды работ:

1. Постановка задачи, разработка технического задания (ТЗ).

1.1. Выявление списка заинтересованных сотрудников (пользова­телей) заказчика:

– для согласования технического задания (ТЗ);

– для согласования технического проекта (решения) (ТП);

– для приемки работ и согласования заказа на доработку (заказ).

1.2. Интервью с каждым пользователем (ТЗ).

1.3. Оформление требований пользователей к доработке в виде технического задания.

1.4. Презентация технического задания на общем совещании пользователей ТЗ (при возможности) или отдельно каждому, разъяснение содержания, ответы на вопросы.

1.5. Доработка и согласование технического задания с каждым заинтересованным пользователем (ТЗ).

1.6. Предварительная оценка трудоемкости (подготовка предвари­тельного паспорта доработки).

2. Разработка технического проекта (технического решения) (ТП).

2.1. Проектирование информационной модели доработки (какие объекты и реквизиты будут созданы заново, изменены, удалены).

2.2. Проектирование функциональной модели доработки (какие функции будут разработаны, изменены, удалены).

2.3. Описание алгоритмов для новых и изменяемых функций.

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

2.5. Проектирование новых и изменяемых интерфейсов, перечень удаляемых интерфейсов.

2.6. Проектирование новых и изменяемых печатных форм, перечень удаляемых печатных форм.

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

2.8. Доработка и согласование технического проекта с уполномо­ченными специалистами заказчика (ТП).

2.9. Окончательная оценка трудоемкости (подготовка окончатель­ного паспорта доработки).

3. Доработка программного обеспечения.

3.1. Технические работы – создание (копированием) отдельной информационной базы данных (при необходимости), получение доступа в хранилище и прочие подготовительные работы.

3.2. Создание структуры новых и изменяемых объектов метаданных – справочников, документов, обработок, бизнес-процессов и пр., их табличных частей, реквизитов, удаление ненужных метаданных.

3.3. Разработка новых и изменяемых форм меню, экранных форм объектов метаданных, удаление ненужных форм.

3.4. Разработка кода для общих модулей конфигурации, модулей объектов метаданных.

3.5. Разработка новых и изменяемых печатных форм, удаление ненужных печатных форм.

3.6. Разработка новых и изменяемых форм отчетов, описание алгоритмов получения отчетов, удаление ненужных отчетов.

3.7. Разработка подсказок (help-ов) для новых и изменяемых объектов метаданных.

3.8. Разработка и (или) настройка ролей и прав доступа.

4. Подготовка тестового примера.

4.1. Подготовка описания тестового примера (какие исходные данные будут введены в программу, какие данные в результате будут получены, описание порядка действий пользователя для получения результатов).

4.2. Ручное (в Excel) вычисление необходимого эталонного резуль­тата на основе исходных данных.

5. Тестирование доработки.

5.1. Ввод исходных данных тестового примера в программу.

5.2. Выполнение действий в порядке, описанном в тестовом примере, получение результатов, сравнение результатов с эталон­ным результатом из тестового примера.

5.3. Отладка программы в объеме, необходимом для получения эталонных результатов.

6. Разработка инструкции по использованию доработки.

6.1. Разработка краткой технологической инструкции (описание последовательности действий пользователя).

6.2. Разработка подробной пользовательской инструкции по поряд­ку ввода данных и получению результатов со скриншотами на основе данных тестового примера.

7. Первичная сдача доработки пользователям.

7.1. Демонстрация доработки пользователям (заказ), ответы на вопросы, фиксация замечаний.

. Доработка по результатам первичной сдачи.

8.1. Доработка и согласование технического задания (при необхо­димости).

8.2. Доработка и согласование технического проекта (при необхо­димости).

8.3. Доработка и согласование паспорта доработки (если трудо­емкость изменилась более, чем на 10 %).

8.4. Доработка конфигурации.

8.5. Доработка тестового примера (при необходимости).

8.6. Доработка инструкции (при необходимости).

9. Окончательная сдача доработки пользователям.

9.1. Демонстрация доработки пользователям, демонстрация устра­нения замечаний по списку замечаний.

9.2. Передача результатов работы (технического задания, техни­ческого проекта, описания тестового примера, доработанной конфигурации, инструкций).

9.3. Перенос данных в рабочую конфигурацию (при необходимости), включает в себя работы по созданию архива до переноса доработок, демонстрацию результатов.

10. Помещение доработки в тиражируемое решение (при необхо­димости).

10.1. Работы по помещению доработки в тиражируемое типовое решение – постановка задачи архитектором типового решения по необходимой модификации доработки под требования типового решения (работа архитектора).

10.2. Модификация доработки под архитектурные требования (без потери потребительских свойств):

– Тестирование типового решения с помощью комплексных авто­тестов для исключения сбоев в очередном релизе;

– Первичная сдача работы архитектору типового решения;

– Помещение доработки в хранилище типового решения;

– Повторная сдача доработки архитектору после помещения в хранилище (обязательно) (работа программиста).

10.3. Первичная и вторичная приемка доработки архитектором типового решения (работа архитектора).

11. Подписание заказа.

11.1. Подписание заказа, подтверждение приемки работ с уполно­мо­ченными сотрудниками (заказ).

Как общаться с заказчиком, используя такой паспорт?

Тут есть три варианта.

1. Отправить полный паспорт, если заказчик имеет свою службу ИТ и требует детальной сметы.

2. Отправить укрупненный паспорт, в котором 11 строк с трудоемкостью разделов, но нет расшифровки отдельных разделов. Давать такую расшифровку – только если заказчик потребует. Такой паспорт может упростить понимание состава работ неподготовленному заказчику.

3. Не давать оценку сразу, а отправить заказчику чек-лист с составом работ. Пусть отметит те виды работ, которые, как он считает, должны быть выполнены. В этом случае заказчик будет готов к дальнейшей оценке, а также может потребовать аналогичную расшифровку работ у конкурентов.

Отправить