Глава 38 из книги нашего директора Рустэма Валеева "Как долго рассчитывать стоимость доработки"

13 апреля 2022

Продолжаем публиковать отдельные главы из книги нашего директора Рустэма Валеева "Франчайзи на грани нервного срыва".

Автор книги прошел большой и долгий путь в сфере информационных технологий. Ему пришлось поработать и программистом, и консультантом, и руководителем проекта, и начальником абонентского отдела. Он побывал с разных сторон баррикад: и заказчиком, и подрядчиком в проектах внедрения ИТ-систем. За 35 лет автоматизации предприятий наш директор попадал во множество забавных и поучительных ситуаций.

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

Глава 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. Доработка по результатам первичной сдачи.
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. Не давать оценку сразу, а отправить заказчику чек-лист с составом работ. Пусть отметит те виды работ, которые, как он считает, должны быть выполнены. В этом случае заказчик будет готов к дальнейшей оценке, а также может потребовать аналогичную расшифровку работ у конкурентов.

...

Предыдущая публикация из серии доступна по ссылке

Всю книгу вы можете скачать на сайте Литрес:

https://www.litres.ru/rustem-valeev/franchayzi-na-grani-nervnogo-sryva-kak-nebolshoy-firme-partn/





Подписаться на рассылку: Новости Софт-портал




Вернуться к списку