Документация по ГОСТ – не только ТЗ

Если вы давно и успешно работаете с предприятиями по 44-ФЗ и 223-ФЗ и знаете, как писать документацию по ГОСТам – в докладе не будет для вас ничего нового.

Но если вы только недавно начали работать с такими компаниями, испытываете проблемы при подготовке документации и не знаете, как ее правильно структурировать – тогда этот доклад вам поможет.

 

 

Давайте сначала познакомимся. Меня зовут Наталья Лосева, я работаю в сфере внедрения 1С уже 15 лет. Из них последние лет 8 – это только проектная деятельность.

Я выросла от девочки, разносящей ИТС, до архитектора на крупных проектах внедрения.

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

У меня много сертификатов, в том числе сертификаты преподавателя.

В общем, я могу сказать, что знаю, о чем говорю. И проекты по ГОСТам я тоже делала.

 

 

Когда я готовила доклад, мне пришла в голову мысль, что проект по ГОСТ – это ужин в мишленовском ресторане, иными словами, «высокая кухня».

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

При этом каждый шеф-повар все равно вносит что-то свое. От регламентов можно отступать, и ГОСТы – это не железный каркас, который залили бетоном. Если их почитать, они довольно-таки гибкие. С ними можно работать и использовать их так, как нужно вам, а не так, как они написаны.

Я надеюсь, что такой стиль изложения поможет немного оживить мой доклад, потому что при слове «ГОСТ» у некоторых автоматически включается сонный рефлекс.

 

Кулинарная книга и меню

 

Итак, представим: у вас высококлассный французский ресторан. Вы заключили тендер по госконтракту, и нужно приготовить документацию по ГОСТу.

Как будем готовить?

• Во-первых, по нашей главной кулинарной книге – ГОСТ Р 59795 «Требования к содержанию документов». Очень классная штука. Вообще замечательная вещь. Просто супер. Будем не раз к нему обращаться. Читайте, знайте, как «Отче наш».

• «Словарик различных терминов и определений» – терминология важна, чтобы мы с заказчиком однозначно понимали друг друга. Мы можем, конечно, обратиться к Шекспиру, вспомнить, что роза пахнет розой и так далее. Но если мы будем использовать неопределенную терминологию, мы далеко не поплывем. Для этого тоже есть стандарт – ГОСТ Р 59853. По факту им пользуются не часто, но его обычно прописывают в документации.

• Меню на наш ужин-проект – что и в каком порядке будем подавать. Для этого нам потребуются два основополагающих ГОСТа:

  • ГОСТ Р 59793 «Стадии создания автоматизированных систем»

  • и ГОСТ 34.201 «Виды, комплектность и обозначения документов».

Эти два ГОСТа лучше рассматривать в паре, потому что они идут перекрестными ссылками – на каждую стадию есть свой комплект документов.

Если все это свести в одну таблицу, получится примерно так, как на слайде.

• В первой колонке у нас стадии создания автоматизированных систем из ГОСТ Р 59793 – все эти стадии мы проходим во время проекта.

• Во второй колонке указано, какие документы на каждой стадии мы разрабатываем.

• А в третьей – в каком ГОСТе можно найти рецепт.

Во вложении к докладу можно скачать эту табличку в Excel-формате.

 

Этап «Формирование требований к АС» – аперитив

 

 

Начинаем проект.

Аперитив – формирование требований к автоматизированной системе. У нас этот этап обычно называется «Обследование».

Согласно ГОСТ Р 59793 «Стадии создания автоматизированных систем», на стадии обследования есть три подэтапа:

• Обследование объекта и обоснование необходимости создания автоматизированной системы.

• Формирование требований пользователя к автоматизированной системе.

• Оформление отчета о выполненной работе.

 

 

Стадия «Обследование объекта». На слайде – выдержки из ГОСТ Р 59793. Перед тем, как окунуться в проект и начать что-то делать, я предлагаю остановиться и заглянуть в документацию, чтобы понять: что мы вообще должны делать на этом этапе? Как мы должны прийти к тому результату, который заказчик или мы ожидаем по этапу?

• Первым пунктом здесь идет оценка целесообразности создания автоматизированной системы. Но я мало где видела, чтобы на проектах 1С оценивали – нужна нам система в принципе или нет? Потому что часто бывает, что и не нужна.

• Дальше мы собираем информацию о качестве функционирования тех процессов и систем, которые есть в компании сейчас.

• Собираем данные об объекте автоматизации и так далее.

 

 

Формирование требований. На слайде – выдержка из ГОСТ Р 59793 о том, как оформить требования. При этом способов сбора требований существуют десятки – это тема отдельной конференции.

 

 

Интересен пункт 1.3 – результирующая документация по этапу обследования. Согласно ГОСТ Р 59793, на этом этапе мы должны оформить:

• отчет о выполненных работах;

• и заявку на разработку технического задания на создание АС или другого заменяющего ее документа с аналогичным содержанием.

Заявка на разработку пишется в произвольной форме, а вот отчет – это штука интересная.

 

 

Если мы заглянем в нашу основную кулинарную книгу – ГОСТ Р 59795 «Требования к содержанию документов» – там в приложении А мы увидим:

• Полную структуру документа «Отчет о выполненной работе» по результатам обследования – с пояснениями по каждому разделу.

• При этом, внезапно, в ГОСТ Р 59795 говорится, что «Отчет о выполненной работе» должен быть подготовлен по ГОСТ 7.32.
  А ГОСТ 7.32 – это действительно страшная вещь. Когда вы его откроете, вы сразу вспомните себя в те времена, когда получали высшее образование и писали дипломный проект. Например, у меня заместитель завкафедры сидел с линейкой и отмерял отступ от края листочка до рамочки и потом от рамочки до текста. Весь ГОСТ 7.32 примерно об этом – там написано, что у отчета о научно-исследовательской работе должен быть титульный лист, содержание, список литературы и так далее. Но там нет структуры разделов, указанных в ГОСТ Р 59795, и как это свести с тем, что от нас требуется при составлении отчета об обследовании – не понятно.

Когда мы делали такой проект впервые, у нас, конечно, мозг взорвался. Но потом уже стало легче.

 

 

Рубрика «Хозяйке на заметку». Подытожим по первому этапу – какие фишки из ГОСТ Р 59795 можно использовать в своей домашней кухне, даже если вы не делаете проекты по ГОСТам:

• В ГОСТ Р 59795 приведен очень хороший, последовательный, четкий, структурированный перечень работ по этапу «Формирование требований к АС». Красота. Берите и делайте.

• Там дана структура разделов для результирующих документов – сделайте себе готовые шаблоны.

• Лайфхак: при формировании «Отчета по НИР» вы можете вынести всю его содержательную часть в приложение. Делаете титульный лист, содержание, список литературы и страничку с резюме на один абзац о том, что перечень работ приведен в приложении А. И дальше приложение А на 260 листов (или сколько там у вас получилось) с отчетом о НИР, который соответствует ГОСТу 59795.

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

 

Этап «Разработка концепции АС» – закуска

 

 

Закуска. Следующий этап – разрабатываем концепцию АС.

Кто бы мог подумать, что в ГОСТах может быть описана разработка концептуального дизайна? Тем не менее в ГОСТ Р 59793 она описана. После того как мы на этапе обследования собрали весь этот вал требований, зафиксировали их и формализовали в отчете, дальше, согласно ГОСТам, мы начинаем погружаться глубже:

• Проводим дополнительное изучение.

• Проводим научно-исследовательские работы.

• Разрабатываем варианты концепции АС,

• Оцениваем риски проекта,

• И опять формируем «Отчет о НИР».

 

 

Этапы «Изучение объекта автоматизации» и «Проведение необходимых научно-исследовательских работ» – для 1С это по факту моделирование и составление КФП (карты функционального покрытия). В ГОСТах такой штуки нет, но тоже можно оформить.

 

 

На этапе «Разработка вариантов концепции АС»:

• Мы подбираем программный продукт, потому что далеко не всегда мы заходим в проект и сразу понимаем, что здесь мы поставим ERP, а здесь – УХ. Иногда нам нужно разобраться, подойдет ли заказчику какая-то отраслевка, и что нам нужно будет в ней доработать.

• Оцениваем преимущества и недостатки каждого варианта.

• Сопоставляем требования пользователей и характеристики предлагаемой АС – формируем ту самую карту функционального покрытия (КФП).

• Определяем порядок оценки качества и условий приемки.

• И ГОСТ нам в очередной раз напоминает, что нужно заранее оценить эффект от использования АС: для чего мы ее внедряем? Какой эффект мы должны получить? Какие цели мы должны достичь?

 

 

Интересно, что в ГОСТе для разработки концепции системы выделен отдельный этап «Оценка рисков проекта».

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

Но кто-нибудь из вас пишет устав проекта? И если пишете, подписываете ли вы устав проекта до начала работ по проекту с заказчиком? А в проектах по ГОСТу вы заказчика вообще не заставите подписать устав проекта – вы его не заставите подписать ничего, кроме того, что есть в ГОСТе.

При этом оценка рисков проекта в ГОСТе есть. И это хорошо – это ваша соломка.

 

 

Дальше мы опять формируем отчет о выполненной работе, а его писать мы уже умеем – это тот же самый «Отчет о НИР».

 

 

Что вы можете взять для себя с этапа «Разработка концепции АС», если вы не работаете по ГОСТ:

• Для этого этапа в ГОСТ Р 59793 сформулированы неплохие рекомендации по выбору ПП. Прочитайте их внимательнее и пропустите через себя – это поможет организовать вашу работу по данному этапу.

• Этот этап нужен, чтобы еще раз продумать, что вы делаете, и куда вы движетесь.

• Если проект не по ГОСТу, мы эти работы обычно делаем в рамках первого этапа – сливаем в один этап обследование и моделирование.

 

Этап «Техническое задание» – рыбное блюдо

 

 

Техническое задание. Рыбное блюдо.

Согласно нашей кухне, мы пишем ТЗ по ГОСТу 34.602. Кстати, в 2020 году он обновился, он сейчас вообще очень крутой. Замечательный ГОСТ. Когда я писала ТЗ по 34-му ГОСТ в 2016-м году, там еще не было структуры документа – все нефункциональные требования мне приходилось придумывать.

 

 

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

Но я хочу еще раз зафиксировать. Справа на слайде – выдержка из ГОСТ.

ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы.

ТЗ – это не документ для разработчика. Здесь мы фиксируем требования. Разработчик не пишет ничего по ТЗ – в мире ГОСТов и в принципе в нашем мире.

Фактически, ТЗ – это документ, который идет вместе с договором. Он определяет, что мы по договору будем делать. А вот как мы это будем делать – это мы опишем уже дальше, на этапах «Эскизный проект» и «Технический проект».

 

Этап «Эскизный проект» – сырное блюдо

 

 

Эскизный проект. Я решила, что это сырное блюдо во французской кухне – оно не всегда есть. И стадия «Эскизный проект» не всегда есть, ее наличие зависит от проекта. Это такой этап для истинных гурманов.

Здесь мы разрабатываем предварительное проектное решение. В переводе на язык 1С, мы рисуем MVP.

Этот этап предусмотрен, но там прямо в ГОСТе написано, что допускается этот этап объединять со следующим.

 

Этап «Технический проект» – главное блюдо

 

 

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

На первой стадии этого этапа мы пишем то, что все называют «ТЗ разработчику». Но я слово ТЗ по отношению к разработчикам никогда не употребляю, я считаю, что правильнее называть этот документ «Проектным решением», «Постановкой» или «Функциональным дизайном».

На этом этапе мы опускаемся на уровень метаданных, объектов конфигурации. И пишем эти проектные решения. Здесь мы описываем, как это все будет реализовано, проектируем то, что мы будем кодить.

 

 

Казалось бы, мы пишем технический проект для себя, и делаем это как хотим. Но это не так – полный перечень видов документов, которые разрабатываются на этой стадии, приведен в ГОСТ 34.201. Там есть примечание, что конкретные документы, разрабатываемые на этой стадии, определяются в ТЗ.

Вспоминаем, что в ТЗ у нас есть очень важный раздел – «Требования к документации». Если вы не пропишите в ТЗ конкретные документы на этой и последующей стадии, вы в документации потом утонете – на следующих слайдах я это подробнее покажу.

 

 

Здесь на слайде – выдержка из ГОСТ 34.201, причем это только часть положенной на этой стадии документации.

Обратите внимание, здесь появляется неожиданный нюанс – упоминание программных документов и ГОСТ 19.101.

• ГОСТы 34 серии – это ГОСТы на автоматизированные системы.

• ГОСТы 19 серии – это ГОСТы на программы.

Автоматизированные системы могут быть не только программными, но наша с вами 1С – это программа. Соответственно, в ГОСТ 34.201 у нас перечислены типы документов, которые нужно оформить на этапе проектирования.

Программные документы – т.е. виды документов на программные средства, используемые при создании АС и ее частей – должны быть написаны по ГОСТ 19.101.

Если вы прописали использование ГОСТ 19.101 в ТЗ, но не прописали перечень документов, будьте готовы к тому, что по ГОСТ 19.101 вам нужно будет подготовить вот такой список документов.

 

 

В первый раз, когда я еще молодая и зеленая попала в проект по ГОСТ, мы писали кучу документов, потому что результатом для проекта по ГОСТам является проектная документация. Есть ЕСКД – единая система конструкторской документации. А есть ЕСПД – единая система проектной документации. Заказчику, который работает по ГОСТам, вы сдаете бумагу, а не систему. К этому надо быть готовым.

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

Во вложении к докладу можно скачать эту табличку в Excel-формате – она объединена с предыдущей таблицей, оформлена в файле отдельным листом.

 

 

Давайте еще раз подытожим.

• Предыдущие две стадии – эскизный проект и технический проект – можно объединить в одну.

• Эскизный проект вообще можно выкинуть – я редко его в проектах по ГОСТам видела.

• Можно даже следующую стадию к ним приплюсовать – это будет называться техно-рабочий проект. На него мы дальше посмотрим.

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

 

Создание рабочей документации – десерт

 

 

Десерт. Что тут сказать? На десерт обычно места в животе не хватает, кажется, что его уже и не хочется. Но готовить его все равно надо.

Как мы его обычно готовим? Тяп-ляп, и печеньки испекли? Нет, так нельзя. Десерты в ГОСТе такие же сложные, такие же разнообразные, как и французские. Там документации еще больше, чем по предыдущему этапу – различные мероприятия, инструкции, сценарии, методика тестирования, и т.д. и т.п. В ГОСТ 34.201 «Виды, комплектность и обозначения документов» можно найти полный перечень.

 

 

Для понимания – он такой, как на слайде.

Если вы не договоритесь в ТЗ о тех документах, которые будете формировать на этом этапе, заказчик будет от вас требовать «Схему соединения внешних проводок». Хотя я считаю, что в проектах по 1С практически все это можно выкинуть.

 

 

По моему мнению, в качестве рабочей документации нужно иметь только три документа:

• Руководство пользователя;

• Технологическая инструкция;

• Программа и методика испытаний.

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

 

 

Например, для документа «Программа и методика испытаний» в нашей кулинарной книге «Требования к содержанию документов» ГОСТ Р 59795 есть отдельный пункт 5.13, который описывает, какие разделы должен содержать документ и что должно быть описано в каждом разделе. По ПМИ там информации на три страницы – выдерните их себе и сделайте из них шаблон.

Документ «Программа и методика испытаний» нужен для того, чтобы сдавать заказчику то, что вы все напроектировали на предыдущих этапах. Это еще можно назвать сценарий тестирования. Чтобы, когда вы начинаете показывать тест-кейсы по разработанной вами функциональности, никакая Мария Ивановна или даже Василий Петрович, который платит деньги, не сказали вам: «А что, если мы сделаем так?» Никаких «если». У вас есть «Программа и методика испытаний», есть зафиксированный список шагов – все, сдаемся так.

Каждая проверка, которую вы описываете в документе «Программа и методика испытаний», должна показывать, какое требование из ТЗ вы закрываете. И это очень круто, очень логично. Документации по сценариям тестирования лучше, чем то, что написано в этом ГОСТе, я не видела. Если вы по этой табличке пойдете, ничего не забудете – это и формально, и технически очень удобно.

 

 

Хозяйке на заметку:

• В проектах по 1С мы обычно стадию подготовки рабочей документации не выделяем отдельно, она у нас, как правило, объединяется с техническим проектированием. Кстати, если у вас проект по ГОСТу, у вас должна быть отдельная штатная единица – технический писатель, который будет все это писать. Иначе вы просто не вывезете.

• Как я уже говорила, большинство видов документов стадии «Создание рабочей документации» для 1С неактуальны.

• Но документ ПМИ – для меня прямо любовь, в самое сердечко.

 

Этап «Ввод в действие» – дижестив

 

 

Предпоследний этап – ввод в действие. ГОСТы здесь выкладывают там только организационно-распорядительную документацию – акты и протоколы. Но по факту мы здесь делаем очень много чего: мы здесь переносим остатки; загружаем справочники; настраиваем роли, права пользователя. Много всего. Но это все можно подкладывать протоколами.

 

 

И еще одна очень хорошая штука – описание приложения Б из ГОСТ Р 59795, нашей основной кулинарной книги. Его пункт 5 посвящен оформлению актов. Для меня это библия.

 

 

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

Даже если на проекте не надо писать документацию по ГОСТу, я все равно иду по этому описанию как по чек-листу и проверяю – есть ли у меня это в документе? А вот это я предусмотрела?

И я иногда документы с этой точки зрения переделываю перед тем, как отправить РП на подпись.

 

Этап «Сопровождение АС» – кофе

 

 

И последний этап – сопровождение.

Слава Богу, здесь уже регламентов нет. Тут уже пишите как хотите – можно выдохнуть и попить кофе.

 

ГОСТы – не ограничение, а полезный инструмент

 

 

Я надеюсь, что вы после моего доклада как-то вдохновитесь, откроете вот эти ГОСТы и не заснете там сразу же на третьем предложении, а попробуете посмотреть внутрь их.

• В ГОСТах очень четкие, понятные шаги, что нужно делать. Я часто встречаю запросы: «А есть ли у вас пример документа? Есть ли у вас такой-то шаблон?» Да, пожалуйста, он есть – не надо изобретать велосипед.

• При этом вы не обязаны делать на 100% все, что там написано. ГОСТы вполне гибкие и допускают отклонения в ту или иную сторону.

• Вы не обязаны на 100% следовать ГОСТам, но вы можете много что оттуда взять. Главное, понять, что ГОСТы – это для вас не ограничение, это для вас полезный инструмент. Используйте их.

 

Вопросы и ответы

 

У нас внутренняя разработка – нет никаких госзаказов или внешних заказчиков, которые бы выставляли требования готовить документацию по ГОСТ. Я общие рекомендации услышала, что на ГОСТы стоит ориентироваться, но насколько надо упахиваться, оформляя документацию по ГОСТ при работе с внутренним заказчиком?

Внутренняя разработка – это инхаус-команда. Вы сдаете свои разработки заказчикам, ключевым пользователям? Вы как-то показываете это?

Да, сдаем, проводим демо.

А потом вы делаете еще 150 бантиков?

Может, да, может, нет.

Когда требования пользователей изначально размыты, многие задачи решаются бесконечно: «А мне здесь надо по-другому и сбоку бантик. А здесь не выводится то. А здесь – это».

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

Так вы сдадите задачу за один-два раза, и у вас не будет этого пула вечноживущих задач. Потому что эти задачи, переходящие из месяца в месяц – это боль руководителей внутренней службы поддержки.

Если у вас эти бантики возникают постоянно, я бы обратила внимание на формулировку и фиксацию требований. У вас явно что-то не то с постановкой, с выявлением и описанием требований. Получается, что вы тут не дорабатываете.

Вопрос в том, насколько подробно нужно писать ПМИ? Мы должны по каждому полю писать, что должен быть такой-то справочник, в нем должен быть какой-то перечень реквизитов?

Если вы добавляете в отчет одну колонку и пишете, что в нее выводится, то ПМИ или сценарий тестирования будет несложный, листика на два.

Вы прописываете:

• при таком-то условии там выводится колонка; а при таком – она не выводится;

• при таком условии – в этом примере будут такие данные, а при другом условии – другие данные.

Просто пользователь может сказать: «А у меня есть еще такой пример», но если эта ситуация не была заявлена в требованиях, она не обрабатывается.

Как и при работе с документацией, мы как аналитики должны быть гибкими. Мы должны и по опыту, и эмпирически оценивать: где нам лучше упереться в документацию, вложить в нее побольше времени; а где – это не нужно. Наверное, это показатель более опытного аналитика.

В основном, все эти ГОСТы – это классический «каскад», они не про Agile. При этом мы же не можем жить в каких-то ограниченных рамках. У нас должна быть гибкость мышления, в том числе и при подготовке документации. Если у нас документация делается ради документации, она не нужна. Мы должны делать документацию для тех случаев, когда она реально поможет – и нам, и пользователю.

Насколько вообще документация помогает при сдаче работ? Случай из жизни: все сделал по ТЗ практически идеально. Начинаем сдавать: нам здесь не так надо, там не так. Я поднимаю ТЗ, говорю: «Товарищи, вот же ТЗ – оно всеми утверждено, кем можно. Как написано, так и сделано». Как вообще бороться с такими случаями? Как документация поможет в таких случаях?

Завести себе хорошего РП, в первую очередь.

Когда заказчик приходит и говорит: «Здесь должно быть не так», ты поднимаешь документацию. И в этот момент очень важно, как были сформулированы требования. Потому что, если требования были сформулированы неоднозначно, то идешь наверх и дальше там РП разбирается. Если требования были однозначны, задача возвращается на доработку.

Нередко бывает такое, что заказчик подтверждает это требование, но оно уже не несет никакой бизнес-ценности и все равно требует доработки. Классическая ситуация: «Мы думали, что ТЗ – это точка зрения, а у нас их несколько». Да, это провал, но это все равно будет новое требование, новая реализация. Да, бывает у нас такое. Мы не боги, мы не умеем читать мысли, не можем зафиксировать все.

Но вообще документация на проекте очень помогает. Например, текущий проект, на котором я работаю, очень хорошо задокументирован. Там все проектные решения очень хорошо описаны. Я вошла в проект уже на стадии сопровождения – там уже вторая очередь развития. Мне эта документация сэкономила огромное количество времени на освоение новой функциональности. При том, что функциональность этой компании – очень специфическая, редкая и нетиповая. Таких компаний в России вообще не больше десяти. Грубо говоря, я открываю документ, и через два часа у меня уже есть ответ на вопрос пользователя, хотя я с этой предметной областью вообще не работала. Вот так помогает документация.

Мы не работаем по ГОСТу – у нас внутренняя автоматизация. У нас быстро меняются процессы, потоки данных – компания живая, быстро растет, развивается. Но когда мы делаем какую-то доработку и выпускаем инструкцию для пользователей, они ее не читают, потому что им некогда. Как делать полезную документацию для пользователей, чтобы они ей пользовались, чтобы наша работа, которую мы делаем в отделе, не была бесполезной, чтобы мы не тратили свои ресурсы на такую документацию?

Тут нет универсального рецепта. Пользователи не читают документацию, они не смотрят видео. Если вы проведете им обучение – периодически такое бывает – они через неделю уже все забудут.

Компании, построенные по западному образцу, с этим работают системно – у них есть отдельный отдел обучения, есть внутренний информационный портал, прямо в учетную систему встраивается удобная справка.

Это как работа с детьми. Мы можем разжевать им кашку и положить в рот, но что делать, если они ее не глотают? Если пользователи не обращаются к документации в принципе, тут скорее момент оргвопросов – видимо, это должно идти со стороны руководства.

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

А когда все 99 человек из 100 привыкли не обращать внимание на документацию – вы их не заставите. К этому сначала надо методично приучать, возможно, даже силком. Но спустя несколько лет вы, может быть, получите хороший результат. Универсального рецепта я не нашла.

Этот доклад можно было назвать «Как правильно прикрыть филейную часть ГОСТом». Но я прошу вас поработать адвокатом дьявола – расскажите, как со стороны заказчика противодействовать всему этому?

А зачем этому противодействовать?

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

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

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

Заплатите денег, и вам все сделают. Если не можете изначально правильно сформировать бюджет, используйте рамочную модель работы. Или используйте модель аутстаффинга – просто нанимайте людей, которые потом будут вам выставлять счет по факту потраченных затрат. И никаких проблем с рюшечками не будет.

Если вы не можете сразу войти в фикс и понять, что вам нужно, просто используйте модель поэтапной работы.

 

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT 2023.