Меня зовут Юлия Седова, и я представляю команду технических писателей ГК «Цифра». В рамках масштабной работы по повышению качества документации мы столкнулись с проблемой отсутствия культуры предварительного планирования трудозатрат технического писателя. В этой статье я хочу поделиться нашим решением проблемы.
Предыстория
В нашей компании много продуктов. Текущих ресурсов технических писателей не всегда хватает. Поэтому на некоторых продуктовых и проектных направлениях документы сильно устаревают. Так, например, существуют отдельные продукты, которые сильно зависят от проектной разработки. По ним наблюдалось наиболее существенное устаревание документации. Обновление документации требовало, в первую очередь, более точного и логичного планирования ресурсов, необходимых для проектной разработки.
Почему так получилось?
В рамках нашей компании разработка ведется в двух направлениях: продуктовом и проектном. Планирование продуктовой и проектной разработки осуществляется отдельно. Проектное планирование выполняется в соответствии с набором проектных ролей. Однако данный набор ролей представляется неполным. Так, например, технический писатель не учитывается как роль, но при этом участвует в проектной разработке.
При планировании проектной разработки всю работу над проектными документами возлагают на инженера-проектировщика. По факту же реальные объемы работы инженера-проектировщика зачастую сильно превышают ресурсные возможности. Кроме того, работа над документацией включает огромное количество различных действий, выполнение которых выходит за рамки компетенции инженера-проектировщика: согласование документов, приведение их к стандартам технического языка и стиля и т. п. Соответственно, к данной работе практически на постоянной основе привлекают технических писателей. При этом роль технического писателя не учитывается при планировании проектов, и фактически представляет собой неучтенные расходы, которые ложатся на проект.
Технические писатели официально включены в департамент разработки, то есть структуру продуктовой разработки. При планировании рабочей нагрузки департамента разработки, работа технического писателя на проектах не учитывалась. То есть разработка проектной документации техническим писателем не учитывалась ни в проектной, ни в продуктовой разработке. Данная ситуация привела сразу к нескольким проблемам.
Штат технических писателей не соответствовал существующей нагрузке. Приходилось делать выбор, где использовать технического писателя: на проекте или на продукте.
Так как доход компании, в первую очередь, приносит проект, приоритет отдавали проектам. В течение длительного времени разработка продуктовой документации игнорировалась.
Таким образом, до недавнего времени в компании отсутствовала культура планирования трудозатрат технического писателя. Данная сложность также подкреплялась тем фактом, что планирование разработки документации сопряжено с большой неопределенностью. Так, например, каждый проект включает разный набор и объем документов. Кроме того, не было нормативов разработки документации.
Как мы решили проблему планирования?
Оглядываясь назад, я хотела бы разделить наше продвижение к решению проблемы на этапы.
Первый этап: донесение до проектных команд необходимости планирования трудозатрат технического писателя.
Так как революционным путем изменения не доходили до реализации, пришлось идти эволюционным путем через трансформацию сознания коллег с опорой на извлеченные уроки в проектах. В конечном итоге руководителю команды технических писателей удалось донести до проектных команд важность и нужность включения технических писателей в планирование проектов. Решение было закреплено на уровне руководства.
Второй этап: формирование бэклога задач по разработке документации со стороны продукта.
Путем непростых переговоров с бизнес-аналитиками удалось договориться о создании Kanban-доски для визуализации объема задач, которые «нужно было сделать вчера» и которые предстоит сделать в перспективе. Данный этап является важным психологическим шагом для перехода от игнорирования проблемы к озвучиванию реального объема задач.
Третий этап: разработка калькулятора расчета трудозатрат технического писателя.
Казалось бы, в компании уже существовал общий калькулятор расчета трудозатрат на проектные работы с формулами расчета трудозатрат инженера-проектировщика, то есть трудозатрат на разработку документации. Но опрос, проведенный нами среди работников компании, показал, что проектные команды по-прежнему сталкивались с проблемами планирования (см. Рисунок 1).
Поэтому новый калькулятор трудозатрат технического писателя должен был отвечать ряду требований. Требования и наша реализация каждого из них описаны ниже.
Решение проблемы неопределенности объема работ.
Для расчета трудоемкости задач технического писателя мы использовали методику расчета PERT – Program/ Project Evaluation and Review Technique. Данная методика хорошо справляется с учетом рисков и неопределённости трудоемкости выполнения отдельных работ. Дополнительный плюс методики PERT – возможность интеграции упрощенной версии калькулятора в Jira.
Определение нормативов разработки разных типов документации.
Использование методики PERT подразумевает расчет средней трудоемкости – в нашем случае на разработку одной страницы определенного типа документации – с учетом наиболее оптимистичного, наиболее пессимистичного и наиболее реалистичного значения.
Наш калькулятор включает в себя две таблицы. Первая таблица определяет исходные оценки трудоемкости работ. Таблица представлена на Рисунке 2.
В левой части таблицы мы сгруппировали типы проектной документации, которые передаются техническому писателю, с учетом ожидаемых действий (разработка или оформление). Для каждого типа документа указали среднее количество страниц. Рассчитали по методике PERT количество человеко-часов на:
разработку страницы документа;
вычитку и правки страницы документа.
Для выполнения расчета требовалось определить:
Mi – наиболее вероятное значение, в нашем случае – среднестатистическое время на разработку одной страницы документа по опыту технических писателей с учетом требования ГОСТов;
Oi – наиболее оптимистичное значение, которое предполагает, что ни один из вероятных рисков не реализовался;
Pi – наиболее пессимистичное значение, которое предполагает, что все возможные риски, которые могут привести к задержкам разработки документации, оправдались.
На основе показателей Mi, Oi, Pi мы рассчитали среднюю трудоемкость по каждому типу документа по формуле: Ei = (Pi + 4Mi + Oi)/6.
Далее для учета рисков мы рассчитали среднеквадратичное отклонение по каждому типу документации в соответствии с формулой: CKOi = (Pi - Oi)/6.
Согласно центральной предельной теореме теории вероятностей:
суммарную трудоемкость разработки документации рассчитали по формуле: Е = ∑ Ei.;
среднеквадратичное отклонение для оценки суммарной трудоемкости рассчитали по формуле: СКО = √∑СКОi2.
Для оценки суммарной трудоемкости процесса разработки документации, которую мы не превысим с вероятностью 95%, использовали формулу: E95% = E + 2*СКО. В нашей таблице эта оценка отображена в последних двух столбцах в расчете на человеко-часы и человеко-дни.
Учет индивидуальных особенностей проекта.
Вторая таблица калькулятора – это непосредственный расчет трудозатрат технического писателя на конкретный проект с учетом разных этапов, см. Рисунок 3.
Рассмотрим пример работы с данной таблицей.
Предположим, что у нас два этапа. В этом случае заполняем столбец Количество документов по Этапу 1 и Этапу 2.
Определяем, какие документы передаем техническому писателю на каждом из этапов и вносим соответствующее количество в таблицу. Например, на первом этапе у нас запланировано привлечь технического писателя для написания 9 инструкций, из которых 6 абсолютно уникальны, оставшиеся 3 складываются по разделам из остальных и требуют небольших корректировок. Вносим значение 7. На втором этапе планируем привлечь технического писателя для написания ПМИ. Документ на втором этапе существенно короче, чем на первом, и мы можем использовать вводную часть из первого этапа. Вносим значение 0,3. Значения в таблице автоматически пересчитываются в соответствии с введенными значениями.
Универсальность использования.
Несмотря на то, что таблица готовилась для планирования разработки проектной документации, она довольна универсальна. Таблица также доступна для использования при планировании документирования продуктовой разработки. Например, можно заполнить столбец Количество документов только для одного этапа и в рамках него заполнить только строки Руководство пользователя и Руководство администратора.
При необходимости калькулятор может быть дополнен другими типами документов.
Четвертый этап: интегрировать новый калькулятор в существующие общие калькуляторы. Если интеграция невозможна, то требуется согласовать калькуляторы между собой и добиться реализации принципа непротиворечия. Нам предстоит выполнить данный этап в ближайшее время.
Ожидаемые результаты
Продуктовое направление
При предварительном планировании трудозатрат технического писателя на проекте возникнет возможность планирования разработки продуктовой документации. Мы ожидаем, что это положительно повлияет на качество и имидж продукта за счет:
своевременного появления актуальной информации;
предварительного обнаружения во время подготовки документации возможных незамеченных ошибок в реализации функциональности;
снижения количества обращений в техподдержку.
Проектное направление
По нашим оценкам, использование калькулятора повысит вероятность выполнения работ в срок, улучшит качество проектных документов за счет разделения нагрузки между инженерами-проектировщиками и техническими писателями, приведет к снижению количества претензий от заказчика и соответствующих корректировок.
Кадры
Мы также ожидаем, что распределение когнитивной нагрузки и предсказуемость общей нагрузки положительно повлияют на климат внутри организации.
В будущем мы планируем продолжить работу по улучшению качества документации за счет автоматизации процессов документирования, создания критериев для самостоятельной проверки документа перед выдачей результата инициатору разработки документа. Но это будет уже совсем другая история.
Комментарии (2)
alexsavochkin
02.11.2023 00:52А используете ли вы подход Doc as a Code? Как у вас технологически работа устроена, расскажете?
alexsavochkin
Мне нравится этот подход!
Я, правда, не разделяю оптимизма по поводу того, что 25,35 человекочасов равно 3,17 человекодней.
Во-первых, представляется разумным в целях планирования округлять в большую сторону до целых. Это объясняется тем, что продуктивность в течение дня не одинакова, а сама работа носит квантовый характер: 0,35 часа работы проще и разумнее доработать в этот же день, а не откладывать на следующий (потому что отложенные на завтра 0,35 ч легко превратятся в 1-1,5 ч за счёт утраты потока и контекста).
Во-вторых, нахожу сомнительным равенство 8 чч = 1 чд. По ТК, конечно, оно так и есть; в реальности бывают и переработки, но в реальности же фактической работой заняты 5 или 6 часов, и хорошо если 6. Внутренние заказчики, конечно, тоже не вчера родились, и могут догадываться о поправочном коэффициенте, но я б не надеялся. :)
А вот исходные оценки трудоёмкости работ — пожалуй, утащу к себе в переговоры с заказчиками для оценки стоимости. На страницу по полтора часа разработки и 36 минут редактуры с корректурой — выглядит похоже на реальность. У меня, правда, разработка руководства пользователя объёмом чуть за 20 страниц по грубой оценке снизу заняла 105 часов от начала до сдачи, но это и случай не очень типичный.
Материал очень познавательный, спасибо.