Большой проект: документация

23.03.15

Управление ИТ - Стандарты и документация

Оставим за рамками нашей темы поиск потенциального клиента. Мы его нашли. Вот он - Большой клиент. Чего мы хотим? Хотим заработать. И чтобы этот Большой клиент был у нас не один. А к нам большинство таких клиентов пришли по рекомендации, а для рекомендаций положительных нужно, чтобы Большой клиент был очень доволен сотрудничеством с нами. Но и мы хотели бы быть довольны работой с ним. Вот о том, какими документами мы этого добиваемся, я и попытаюсь рассказать. *** Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3

Попробуем представить проект в виде собрания документов. Любой процесс, процедура, правило находят отражение в документах. Пакет проектных документов меняется от проекта к проекту. Что-то отбрасывается или вводятся новые документы. Но уже не так быстро, как говорится - не быстрее самой жизни. Пакет проектных документов, технология Большого проекта возникли не с появлением такового. Отдельные документы и элементы технологии применялись и совершенствовались на проектах меньшего масштаба. Мы просто были уверены, что когда-нибудь он у нас появится, и хотели быть готовы к нему. Первый Большой проект появился и благодаря тому, что мы продемонстрировали потенциальному клиенту уже имеющиеся у нас наработки, технологические и документационные.

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

Результатом каждого этапа (подэтапа) проекта является подписанный Документ или (как правило) группа Документов. Основной документ – это Договор. Мы обычно включаем в Договор несколько Приложений:

 

Приложение 1 - Спецификация работ

Здесь расписаны основные блоки проекта по видам работ с указанием стоимости + программы и лицензии

 

Приложение 2 - График сдачи работ

Здесь отображается, какой этап или подэтап, когда планируется сдать

 

Приложение 3 – График оплат

Все оплаты и предоплаты с привязкой к Спецификации

 

Приложение 4 – Условия и Порядок работ

Очень серьезный документ. В нем перечислены все этапы (подэтапы) проекта и что является результатом работ по каждому этапу (подэтапу). А также процедуры: процедура сдачи работ, процедура проверки, срок и результат проверки сданных работ, процедура переноса сроков, топокарта проекта

 

Приложение 5 – Список проектной документации

Полный список всех документов, которые будут использованы в данном проекте

 

Приложение 6 - Перечень необходимых ресурсов

Перечень видов ресурсов, выделяемых обеими Сторонами для проекта

 

Приложение 7 – Функциональные и Технические требования к Системе

Официальные требования Заказчика к Системе

Почти все Приложения, может быть, кроме №5 (и, может быть №3), можно применить на менее масштабных проектах.

Последовательность действий (или порядок работ по проекту)
и результаты этапов работ

  

Этап 0: Подготовка к проекту

Результат Этапа:

W22;                Подписанный Список Ответственных, Компетентных и Операционных Лиц (СОКОЛ);

Конечно, список общий, объединенный, т.е. в нем представители обеих Сторон. Ответственные лица обеспечивают организационно-административную поддержку проекта. Это сотрудники, отвечающие за какую-либо область. Например: организационные вопросы проектных работ, делопроизводство проектных работ, ИТ-поддержку проектных работ, юридические вопросы предметной части проектных работ и т.п.

Компетентные лица являются специалистами в предметных областях, включенных в рамки проекта. Почему такое деление? Иногда Ответственное лицо не является специалистом в данной области – это просто администратор (менеджер). Мы сталкивались с ситуациями, когда Ответственное лицо, должное подписать какие-то проектные документы, отказывается это делать по причине некомпетентности. «Я не буду это подписывать – я в этом не разбираюсь». Так появились Компетентные лица, каждый в свой области, которые могут сказать Ответственному лицу: «Да, это так» или «Нет, это неправильно».

Операционные лица проекта – все, кто в ходе проекта привлекается ответственными и компетентными лицами для реализации задач проекта.

В СОКОЛе стараемся прописать резервирование ответственных и компетентных сотрудников с обеих Сторон. Это означает, что там записывается, например, ответственное лицо за юридические вопросы предметной части проектных работ с Первой стороны – г-н Х, а в случае его отсутствия г-н Y.

Фактически СОКОЛ – это и есть ОРГ – Объединенная Рабочая Группа. Собственно, проект и делается силами ОРГ.

Руководитель ОРГ – это сотрудник нашей компании. По-другому никак! А если клиент не соглашается? Ему надо объяснить, уговорить и т.п. А если все равно не соглашается? Тогда надо уходить. Наш опыт показывает, что ничем хорошим такой проект не закончится.

На больших проектах, где задействовано много людей, мы столкнулись с такой проблемой. Не всегда можно оперативно найти кого-то из сотрудников клиента. Тогда в составе ОРГ появилось Основное контактное лицо (с каждой Стороны). Это что-то вроде секретаря, через которого можно найти любого сотрудника, оперативно передать информацию.

W22;                 Подписанный Общий Рабочий План (ОРП) с разбивкой на этапы и подэтапы;

W22;                 Подписанный График лекций и семинаров «Введение в технологию проекта»

W22;                 Подписанный Журнал посещений лекций и семинаров «Введение в технологию проекта».

Курс занятий нужен для того, чтобы сотрудники клиента знали, что мы делаем сейчас и для чего, какие документы и как применяем (и как их применять им), что будем делать потом и кто за что отвечает. Наш опыт показывает, что в больших проектах затраты на проведение лекций и семинаров окупаются.

СОКОЛ у нас существует почти на всех проектах, вне зависимости от масштаба. Курс лекций - стараемся, если экономика проекта позволяет.

Этап 1: Обследование

Рассматриваются разные аспекты: техника, люди, степень формализации бизнес-процессов и т.п.

 

Результат Этапа:

W22;                 Подписанный Акт о Соответствии и Готовности (АоСиГ);

Документ, констатирующий готовность (или её отсутствие) Заказчика к проекту (техническую, кадровую, организационную и т.д.). Например: Заказчик хочет все свои филиалы объединить в единую сеть. Но не во всех филиалах есть компьютеры. Или мощность серверов недостаточна для планируемой нагрузки. Или Заказчик планирует переходить на МСФО (Международные Стандарты Финансовой Отчетности), но у него нет учетной политики. В Акте фиксируются все подобные моменты.

Зафиксировали. Что с этим делать? А для этого есть еще один документ:

Список мер по проведению реорганизации и график реорганизаций. (СМиГР)

То есть что, когда и в какой последовательности надо сделать, дабы привести предприятие Заказчика в состояние готовности к проекту.

Эти документы мы также используем очень часто. Они прекрасно масштабируются на менее крупные проекты и приносят пользу.

Этап 2: Проектирование

Подэтап 1:

Конструирование Модели Бизнес Деятельности Предприятия (МБДП)

Подэтап 2:

Составление Технического Задания на Прототип (ТЗП) системы учета, контроля, управления, анализа (реализация МБДП в виде Программно-Технического Комплекса (ПТК) путем адаптации типового решения).

Результат Этапа:

W22;                 Подписанная МБДП (Модель бизнес-деятельности предприятия).

W22;                 Подписанное ТЗП (Техническое задание на Прототип Системы).

В большом проекте очень сложно сразу написать ТЗ. У нас не получается. Поэтому пишется ТЗ на Прототип, а потом этот Прототип дорабатывается до Системы.

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

 

МБДП иногда создается и на «средних» проектах. ТЗП или ТЗ – всегда

Этап 3: Реализация

Подэтап 1:

Выполнение ТЗП;

Подэтап 2:

Демонстрация выполненного ТЗП;

 

Результат Этапа:

W22;                 Подписанный Акт о проведении демонстрации Прототипа согласно процедуре проверки на тестовых данных.

Все процедуры детально прописываются в Приложении 4.

Для облегчения сдачи работ в процедуре сдачи прописываются конкретные сроки. Если в установленные сроки не будут предъявлены какие-нибудь претензии (естественно, в письменном виде), то работа считается сданной.

Акт применяем всегда, а процедуры,  в небольших проектах, прописываем по мере возможности

 

Этап 4: Интеграция

Подэтап 0:

Составление Детального Рабочего Плана Этапа (ДРПЭ)

Подэтап 1:

Развертывание системного ландшафта

Подэтап 2:

Загрузка первоначальных данных, остатков и истории

Подэтап 3:

Уточнение ТЗП и доработка до Системы

Подэтап 4:

Внедрение

Результат этапа:

W22;                 Акт о соответствии развернутой Подсистемы Правилам работы по соответствующему Подэтапу;

W22;                 Подписанная Ведомость прохождения тренинга;

W22;                 Акт о соответствии Подсистемы Техническому Заданию, состоящему из ТЗП, и Уточнение Технического Задания на Прототип (далее УТЗП)

W22;                 Акт о соответствии данных, загруженных на начало 2ххх-го года и введенных за период 2ххх-го года Правилам работы по соответствующему Подэтапу;

W22;                 Инструкция пользователя;

W22;                 Описание возможностей;

W22;                 Технический паспорт (требования к условиям эксплуатации);

W22;                 Лицензионное соглашение;

W22;                 Гарантийный талон;

Акты о соответствии практически на любом проекте. Остальные документы – на Больших проектах.

С хронологией закончили. Есть еще значимые для обеспечения проекта документы.

 

 

 

 

Ежедневно мы пользуемся таким важным и нужным документом, как Дневник контактов (ДК),

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

ДК позволяет выявить еще только формирующуюся проблему на начальном этапе. Причем документ не только позволяет обезопасить Исполнителя – ДК помогает и Заказчику. Если сотрудники Исполнителя чего-то не делают, делают не так или не вовремя – Заказчик фиксирует это в ДК. Вся текущая ситуация по проекту становится абсолютно прозрачной для обеих сторон.

В рамках курса «Введение в технологию проекта» сотрудники Заказчика знакомятся и берут на вооружение этот документ. В случае спорных моментов любая из Сторон может поднять свои копии ДК и предъявить как аргумент: позвольте, у нас все записано, да еще и с вашей подписью.

 

Такие ежедневные документы, как Задание Исполнителю (ЗИ) и Отчет по Заданию Исполнителя (ОЗИ), являются внутренними документами, т.е. без подписи Заказчика. Содержание понятно из названия. Инструмент контроля непосредственных исполнителей со стороны руководителя ОРГ.

Эти документы (ДК, ЗИ, ОЗИ) используются нами всегда, вне зависимости от масштабов проекта.

Ведомость отклонений (ВО) – Документ, в котором фиксируются все отклонения от запланированного: на какой срок перенесено (заменено, отменено), какая причина, итог.

ВО используется в большинстве и более мелких проектов. В рамках курса «Введение в технологию проекта» сотрудники Заказчика знакомятся и берут на вооружение этот документ. В случае спорных моментов любая из Сторон может поднять свои копии ДК и предъявить как аргумент: позвольте, у нас все записано, да еще и с вашей подписью.

 

На большом проекте есть еще такой орган, как Объединенная Наблюдательная Комиссия (ОНК). Руководитель ОНК назначается со стороны Заказчика. В составе равное количество представителей каждой из Сторон. Со стороны Исполнителя в ОНК, как правило, входит руководство компании. Это орган, контролирующий проект. ОНК принимает решения по вопросам, выходящим за рамки компетенции ОРГ (замена сотрудников, перенос сроков этапа (подэтапа), утверждение отклонений от проекта и т.д.). И еще – именно ОНК оценивает успешность выполнения этапов (подэтапов) и всего проекта в целом.

ОНК получает отчетность от ответственных лиц и проектную документацию - Дневник Контактов (ДК) и Ведомость Отклонений (ВО). На основании данных документов ОНК готовит единый отчет руководству обеих Сторон.

Ответственные лица ОРГ предоставляют краткий ежемесячный отчет в ОНК.

Выделенные члены ОНК ведут следующие документы:

- журнал записей проблем и принятых решений

- журнал оценок этапов работ

- сборник копий отчетов для руководств обеих сторон

- сборник отчетов ответственных лиц ОРГ.

Назначенные члены ОНК готовят проект решений по текущим вопросам ОРГ, ежемесячной отчетности и оценки успешности этапов.

Руководитель ОНК утверждает подготовленные проекты решений по текущим вопросам ОРГ, ежемесячной отчетности и оценки успешности этапов.

ОНК – это атрибут исключительно Больших проектов.

 Подводя итоги, хочется отметить, что регламентируется и документируется все, что может повлиять на проект. Помимо указанных документов регламентируются процедуры: Процедура сдачи работ, Процедура, срок и результат проверки сданных работ, Процедура замены СОКОЛ, Процедура переноса сроков. А курс лекций и семинаров: «Введение в технологию проекта» призван не просто ознакомить сотрудников Заказчика с проектными технологиями, а разъяснить, как будет проходить наш проект, по каким правилам и с применением каких документов. Как этими документами пользоваться, в том числе и с выгодой для Заказчика. 

*************

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Стандарты и документация Разработчик Бесплатно (free)

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

23.10.2026    361    0    jack_nsk    0    

1

Стандарты и документация Разработчик Аналитик Россия Бесплатно (free)

Статья посвящена практическому опыту адаптации стандартов разработки фирмы «1С» для работы с ИИ-инструментами. Показано, почему обычного пересказа стандартов недостаточно для надёжной генерации и ревью кода: при сокращении теряются условия применения, исключения, обязательность требований и контекст. Авторы описывают переход к формализованным карточкам правил, содержащим источник, условия, исключения, способ проверки, тяжесть нарушения, возможности автоматического контроля и дату сверки со стандартом. Материал будет полезен руководителям проектов 1С, архитекторам и разработчикам, которые внедряют ИИ в разработку и контроль качества. На реальных тестах показано, как структурированное представление стандартов снижает число пропущенных дефектов, ложных замечаний и потенциально опасных исправлений.

25.09.2026    455    0    Rico17    3    

1

Стандарты и документация Аналитик Руководитель проекта Бесплатно (free)

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

24.09.2026    318    0    YA_826532418    0    

3

Стандарты и документация 1С:Документооборот Бесплатно (free)

После нормативной документации, несоответствий, жалоб и аудитов остается еще один большой пласт СМК: записи качества, периодический мониторинг, цели, показатели и анализ со стороны руководства. В статье разбираю, что из этого стоит вести непосредственно в 1С:Документообороте, где достаточно контроля и хранения результата, когда нужен проект, а какие данные лучше оставить в профильных учетных системах.

22.09.2026    283    0    YA_826532418    0    

3

Стандарты и документация 1С:Документооборот Бесплатно (free)

Жалоба клиента может привести к регистрации несоответствия, внутренний аудит — сразу к нескольким проблемам, а корректирующее действие — к новой редакции нормативного документа. Во второй части разбираю, какие механизмы 1С:Документооборота подходят для жалоб и внутренних аудитов, какие связи между объектами нужно предусмотреть и что спросить на обследовании, чтобы СМК не превратилась в набор несвязанных карточек.

22.09.2026    258    0    YA_826532418    0    

3

Стандарты и документация 1С:Предприятие 8 1С:Документооборот Бесплатно (free)

Имея опыт работы и специалистом по системе менеджмента качества, и бизнес-аналитиком, я отметила, что автоматизация СМК редко сводится к созданию нескольких видов документов и маршрутов согласования, потому что нормативная документация, несоответствия и корректирующие действия живут по разным правилам. В статье посчитала важным разобрать не только вопрос того, какие механизмы 1С:Документооборота подходят для этих процедур, но и какие вопросы нужно задать на обследовании, чтобы потом не переделывать структуру документов и маршруты.

21.09.2026    370    0    YA_826532418    0    

4

Стандарты и документация Аналитик Руководитель проекта Бесплатно (free)

ИИ удобно использовать для анализа ТЗ, подготовки протоколов, писем и проверки требований. Но до загрузки рабочего материала его нужно обезличить, а после получения ответа — проверить. Рассказываю, как я разделяю эти две проверки и почему уверенный ответ ИИ еще не означает, что предложенный вариант существует в 1С.

04.09.2026    655    0    YA_826532418    0    

3

Стандарты и документация Бесплатно (free)

Разбираем ISO/IEC 42001:2023 – самостоятельный стандарт по системам менеджмента искусственного интеллекта, построенный на логике ISO/IEC 27001 и расширяющий привычные подходы информационной безопасности на разработку, поставку и использование ИИ-систем. Показываем, как типовая модель оценки рисков дополняется анализом воздействия на бизнес и общество, а приложение А объединяет меры управления рисками в десять групп контролей. Объясняем, чем отличаются требования к разработчикам, поставщикам и пользователям систем искусственного интеллекта и какие риски каждая из сторон должна учитывать на своих этапах жизненного цикла. Материал будет полезен специалистам по информационной безопасности и разработчикам информационных систем, интегрированных с ИИ.

31.07.2026    684    0    roman_nikishov    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. pro-rok 335 24.03.15 15:23 Сейчас в теме
Интересная статья, спасибо автору. Для полноты картины не хватает примеров проектной документации.
Ведение такого объема документов требует от РП большого объема времени, у Вас в проектах работа РП выделяется отдельно?
2. UR1 97 25.03.15 11:51 Сейчас в теме
(1) pro-rok,
Если говорить о большом проекте, то да. Но не все документы ведет РП. Есть делопроизводитель. А многие документы ведутся самыми разными сотрудниками. Например, если кто-то (не РП) проводит встречу с сотрудниками другой стороны, то он и заполняет свою часть Дневника Контактов.
С примерами сложно. Объем очень большой. Вас какой-то конкретный документ интересует?
3. AlexSunS 11.04.15 16:17 Сейчас в теме
Собственно интересуют все документы, на примере какого либо проекта
4. UR1 97 14.04.15 20:15 Сейчас в теме
(3) AlexSunS,
Я уже отвечал: объем очень велик. Кроме того, существует понятие конфиденциальности и наши обязательства перед клиентами.
Мне проще ответить на конкретные вопросы.
Для отправки сообщения требуется регистрация/авторизация