Войти в систему
Войти с помощью соц. сетей:
Документация по проекту внедрения ERP-системы имеет важное значение. Настоятельно рекомендуется вести как рабочие, так и отчетные документы своевременно и с должной детализацией.
Документация является средством коммуникации, управления, позволяет обезопасить обе стороны от возможных конфликтов и судебных разбирательств (либо отстоять в суде свою позицию, если до этого дойдет).
Если формулировки требований, изначально имеющие краткое описание, не переложить в более формально описанные технические задания, которые будут понятны всем участникам и подписаны специалистами заказчика (или хотя бы на уровне электронной переписки утверждены), то все стороны проекта не будут понимать, чего ожидать от реализации этого требования, какие ограничения принимаются, какие алгоритмы закладываются. Остается простор для разных трактовок. А если все оформлено документами и формально описано, то все участники проекта будут «на одной волне».
Это сразу снимет ситуации завышенных ожиданий заказчика и защитит от этого исполнителя, например, уберет реплики пользователей вида: «Ой, а мы думали, что будет все иначе и делаться само по одной кнопке». Точнее, такие ситуации, конечно, возможны первые пару раз, пока специалисты заказчика не осознают степень ответственности работы над проектом, включая задачи по вычитке и утверждению рабочих документов проекта. Конфликт таких ожиданий по уже сделанному функционалу снимается показом утвержденного перед разработкой документа («сделано по ТЗ!») и предложением записать новые требования в журнал изменений для последующего пересмотра границ (сроков и бюджета) проекта, если потребуется. При этом утвержденные технические задания все равно остаются рабочими документами и могут пересматриваться по необходимости, но в управляемом режиме с пониманием ответственности за пересмотр и рисков изменений границ проекта. Сам процесс формального описания ТЗ тоже хорошо помогает в проектировании и понимании задачи и вариантов ее решения, так как кажущееся разработчику «мне все тут понятно» при формализации приводит к множеству вопросов у консультанта и конечного пользователя, и эти вопросы закрываются «на бумаге», а не переделкой кода в процессе тестирования и эксплуатации («ой, а этот сценарий мы совсем не учли»).
Обратная ситуация хорошей проектной документации – это защита интересов заказчика с помощью документации проекта. Зафиксированные в ТЗ моменты должны работать в системе, и если в процессе опытной эксплуатации выявляются недоработки и отступления от ТЗ, то они должны быть устранены исполнителем.
На заметку. Фраза: «Все, что вы скажете, может быть использовано против вас» – очень хорошо работает по отношению к написанному в проектной документации. Причем в обе стороны.
Поэтому не нужно писать в ТЗ какие-то несбыточные и фантастические вещи, нужно явно указывать, как это будет – «автоматически» или «вручную», иначе этого потом будут ожидать и нужно будет все делать или создавать риск конфликтной ситуации: «Ну, мы совсем не это имели в виду».
При использовании гибких agile-методик ведения проектов документация минимизирована согласно манифесту о важности людей и самой работающей системы, но для внедрения проектов ERP такой подход «без документации» имеет ряд минусов.
Применяемая проектная документация описывается по фазам проекта и фиксируется списком и шаблонами в уставе проекта. Это инструментарий для достижения целей проекта и визуальная часть хода проекта и его «бумажных» результатов. Дело в том, что систему и программный код в ней очень сложно представить и оценить неспециалисту, тогда как полноценная проектная документация вызывает доверие к результатам проекта и именно в ней описаны все возможности системы и как с ней работать пользователям.
Нужно помнить, что нет цели гнаться за объемом документации. Объемную документацию сложно готовить, трудоемко поддерживать в актуальном состоянии и, главное, сложно читать и согласовывать. Документация должна содержать необходимую и достаточную информацию для единого понимания всех участников проекта, без лишних, незначимых описаний и отступлений. А такая оптимальная документация и для гибких методик хорошо подойдет и лишней (даже в нарушение agile-манифеста) не будет.
Можно привести крылатое выражение А.П. Чехова: «Краткость – сестра таланта». Вот и проектная документация должна быть в меру краткой, а для этого нужен определенный талант и навык у специалистов, ее делающих. На помощь приходят шаблоны документации и внутренние тренинги, как и что в ней описывать.
У исполнителя должны быть готовые шаблоны на все типы документов и понимание, как и кто формирует эти документы. Возможна ситуация, когда у заказчика есть свои предпочтения по применяемой проектной методологии, тогда требования к документам и их шаблоны предоставляет сам заказчик.
Проектные документы разделяются на рабочие и отчетные:
Так как различных видов документов на разных фазах проекта может быть довольно много, полезно описать, кто что делает. Это полезно не только для документации, конечно, но почти все в проекте документируется в том или ином виде, поэтому рассмотрим такой инструмент в данном разделе книги. Для таких целей хорошо подходит диаграмма RACI:
Диаграмма RACI является удобным инструментом для четкого распределения ролей и сфер ответственности, когда в команде есть внутренние и внешние ресурсы. Часто ее представляют в виде таблицы: список документов и операций – по строкам, а по столбцам – сотрудники или роли в команде, которые в этом задействованы по R, A, C и I действиям. Пример такой таблицы представлен ниже.
| Операция | ФИО_1 РП исполнителя | ФИО_2 РП заказчика | ФИО_3 Консультант | ФИО_4 Ключевой сотрудник |
|---|---|---|---|---|
| Устав проекта | R | A | I | I |
| Тех. задания | C | I | R | A |
| Запрос на изменение | A | C | I | R |
| Руководства пользователей | C | A | R | I |
Далее рассмотрим более подробно фазы проекта и документацию по ним.
Шаблоны самой документации в данной книге не приводятся, их можно взять в технологии корпоративного внедрения 1С:ТКВ из «1С:ПрофКейс».
Войти с помощью соц. сетей: