Comments 12
Мне нравится этот подход!
Я, правда, не разделяю оптимизма по поводу того, что 25,35 человекочасов равно 3,17 человекодней.
Во-первых, представляется разумным в целях планирования округлять в большую сторону до целых. Это объясняется тем, что продуктивность в течение дня не одинакова, а сама работа носит квантовый характер: 0,35 часа работы проще и разумнее доработать в этот же день, а не откладывать на следующий (потому что отложенные на завтра 0,35 ч легко превратятся в 1-1,5 ч за счёт утраты потока и контекста).
Во-вторых, нахожу сомнительным равенство 8 чч = 1 чд. По ТК, конечно, оно так и есть; в реальности бывают и переработки, но в реальности же фактической работой заняты 5 или 6 часов, и хорошо если 6. Внутренние заказчики, конечно, тоже не вчера родились, и могут догадываться о поправочном коэффициенте, но я б не надеялся. :)
А вот исходные оценки трудоёмкости работ — пожалуй, утащу к себе в переговоры с заказчиками для оценки стоимости. На страницу по полтора часа разработки и 36 минут редактуры с корректурой — выглядит похоже на реальность. У меня, правда, разработка руководства пользователя объёмом чуть за 20 страниц по грубой оценке снизу заняла 105 часов от начала до сдачи, но это и случай не очень типичный.
Материал очень познавательный, спасибо.
Спасибо, что поделились впечатлениями от статьи, а также своим опытом. Да, действительно, не могу не согласиться с наблюдениями относительно продуктивности. Округление в большую сторону видится целесообразным решением, возьмем на заметку.
Я позже опубликую статью о том, как конкретно готовил то руководство, которое 105 часов заняло. Думаю, я бы при других вводных справился бы скорее, но ненамного. Там было много смежных затрат: кроме скриншотов ещё нарисовать картинки, придумать рациональную структуру, подготовить сокращенную версию со своими картинками, и ещё всякого по мелочи.
Будет очень интересно почитать!
Опубликовал: https://habr.com/ru/articles/776410/ Комментарии от коллег особенно приветствуются.
А используете ли вы подход Doc as a Code? Как у вас технологически работа устроена, расскажете?
Добрый день! На данный момент мы только начинаем внедрение Docs-as-Code. Для некоторых продуктов документацию уже готовят на языке разметки (мы используем Markdown) и хранят в GitLab-репозиториях. Документация публикуется на портале документации. Сейчас мы работаем над внедрением данного подхода на тех продуктовых направлениях, где документация пока выпускается в форматах .docx и .pdf.
Здорово.
Я по традиционной технологии работаю почти всю карьеру, и теперь тоже решительно перехожу на маркдаун. По правде говоря, теперь не вижу ни одной причины брать руками текстовый процессор из офисного пакета. У них вообще нет никаких преимуществ перед маркдауном.
Мне ещё понравилось использовать связку из плейнтекста и Adobe InDesign, но это потому что могу.
Добрый день! Присоединяюсь к Юлиному комментарию. Про наш подход docs as code написано вот здесь https://habr.com/ru/companies/zyfra/articles/578486/. А более подробная статья выйдет в ближайшее время, т.к. переход пока не до конца осуществлен, но обязательно поделимся нашими наработками. надеюсь, будет полезно и интересно.
Да, будет очень интересно. Спасибо. Вернусь из отпуска — прокомментирую подробнее.
Прочитал с изумлением. :)
У технического писателя неускоряемой работы всегда очень много — по крайней мере, сколько себя помню, было именно так. Поэтому я лично всячески за то, чтобы свалить на автоматику абсолютно всё, что можно на неё свалить. У меня, правда, смещённая оценка опыта: я всю дорогу писал с оглядкой на ГОСТы, а там (особенно в 2.105 и 8.857) много формальных требований к оформлению, притом довольно контринтуитивных. К тому же в ворде довольно непросто нарулить непротиворечивый набор стилей, особенно если ты первый, кто озаботился этим.
Да, вообще процесс перехода на технологически иные процессы документирования вещь весьма непредсказуемая в плане внедрения - никогда не знаешь где и что вылезет и будет мешать. Но, учитывая особенности самого процесса перехода, понимаю, что данный процесс привязать к какой-либо системе не прокатит. У каждого будут свои болячки и проблемы - кто-то долго будет входить в технологии, кто-то долго перестраивать процессы и переучивать персонал. Вот и у нас такая ситуация - вроде все все понимают и есть модель по переходу, но нет зрелости взглядов, да и заказчик часто давит своими потребностями, что также периодически сбивает с пути. Поэтому команда полностью ЗА переход и хочет работать в новых реалиях, а руководство говорит, что "Вы ребята, конечно, молодцы, но делаем по-старому". )))
Зачем и как планировать трудозатраты технического писателя?