Комментарии 7
Без технического писателя (ТП) можно обойтись. В небольших компаниях этим занимается РП (тимлид).
Есть один серьезный кейс, когда без ТП сложно. Для корректного закрытия контракта с серьезным заказчиком. У которого есть требования к оформлению, собственная коллекция стилей строго по ГОСТ, проверки Счетной палаты, выделенный человек, который безжалостно заставляет перепечатывать страницы в переплетенном томе и т.п.
В остальном РП ищет ТП когда ему уже совсем надоело все делать самому. В этом случае он дает доступ к постановкам аналитиков и макетам в Figma - все остальное ТП сделает сам.
Еще есть кейс с реально вкалывающими клиентами. Например, использование МИС в частных стоматологических клиниках. Им нужны пошаговые инструкции прежде всего. В принципе, менеджер техподдержки этого клиента может и сам их сделать - но ТП сделает красивше, а у него таких клиник 20 и более.
Последний кейс - это управление знаниями внутри команды. Базы знаний в Confluence, Git и т.п. Это уже не ТП, вообще-то. Требования ну очень сильно не совпадают к тем же ТП п.2. Я бы сказал, что этим должен заниматься методолог, специально обученный из числа самых опытных аналитиков, архитекторов или владельцев продукта.
Все хотят на роль ТП всезнающего универсала. И с заказчиком общается, и требованиями управляет, и ТЗ/ЧТЗ/ПиМИ сам напишет, и код читает. Все ГОСТы и ISO наизусть цитирует. И т.д.,и т.п. Я только не понимаю, почему - если уж так нужен спец с такой подготовкой - почему не взять упомянутого менеджера техподдержки, аналитика или разраба и из него сделать ТП? Потому что разница в зарплате большая?
*
Отдельно выражаю сочувствие в связи с тем, что вас заставили выдавливать из себя этот текст. Слабый он получился.
Добрый вечер! 4 - это так называемый knowledge manager и таких позиций в РФ почти нет. Еще не пришли к пониманию зачем это нужно. Я могу ошибаться, но мне кажется, что KM отличается от методолога и техписа наличием проактивной позиции - он не ждет поставленной задачи, а сам способен ее инициировать.
Вы задайте себе вопрос, кто может занимать "проактивную" позицию по управлению знаниями фирмы.
*
Методолог - это и есть knowledge manager. Причем это значительно более осмысленное, устоявшееся понятие.
*
Тематику управления знаниями тянут желающие раздуть штат фирмы, деньги осваивать. В IBM есть чем управлять. А чем в фирме на 100 сотрудников управлять? да еще выделять под это человека? это дополнительная нагрузка для архитектора или РП если генеральный так озабочен подобными вещами, нмв.
*
Позиций таких много. Они по разряду "технический писатель" пока идут.
Пришлось снова включить компьютер...
С одной стороны - да, я не топлю за новомодное название уже существующего понятия, а с другой - у меня методологи больше ассоциируются с написанием методик обучения и т.п. То есть узкая специализация, не манагерская. Да и по вакансиям смотрю - как-то не то.
А кто же тогда за базу знаний отвечать должен? Почему это лишняя позиция, которая раздувает штат фирмы? Конечно это можно возложить на аналитиков - им же проще свои ТЗ на человеческий перевести, но точно не на РП.
Позиций таких мало, потому что техпис воспринимается как исполнитель - пишущая машинка. Если открыть описание KM, то читать задачи приятнее.
Что приятнее - охотно верю. Мастеров красиво болтать развелось много.
*
Давайте конкретно. Какими знаниями обладает фирма? И в каких кейсах знания используются?
*
Если мы о know how - то такая инфа потому так и называется, что ее не раскрывают. Если это всякие бэкдоры и недокументированные функции ПО (типа черной кассы) - тоже самое. Если стек технологий - то этим хвастаются и никакого знания в этом нет. Какими конкретно знаниями требуется управлять.
*
Работники делятся на тех, кто знанием обладает и на новичков, которых - возможно - требуется обучать. Так это уже давно решалось в рамках пресловутого "онбординга":) Сам проходил 10-ти дневный курс по BI с получением сертификата. Это система обучения. Учебные материалы, юниты, курсы, тесты и пр. Есть острое желание ее переименовать в управление знаниями? для повышения статуса и оплаты? Ну. дерзайте, понты наше все. И подход классический: "выкинем буржуазные пережитки с корабля революции!!" А потом втихаря перетащим все в свою новейшую систему:)
*
Термины knowledge management/manager появились где-то в конце 90-х. И весьма меня (тогда) воодушевили. Но за более чем 20 лет я так и не увидел реального содержания. Возможно, я чего-то не знаю...
Сорри, не смог ответить раньше. Разве мы о чем-то спорим?
Я понимаю управление проектами и процессами, а знания? Их нужно выявлять и/или как-то упаковывать. Кто это должен делать, какая роль?
Кейс_1: есть компания, где большинство сведений в головах конкретных людей пенсионного возраста. Как построить систему, чтобы работа компании не была на них завязана?
Кейс_2: в компании накопилось критичное количество вордовских документов и было принято решение сделать базу знаний с удобной навигацией. То есть задача носит скорее административный характер - найти систему, возможно как-то ее доработать, перенести в нее все свое "барахло" и уже потом отдать техписам на поддержку.
Если это все задача методолога - ок, принято.
Из обучающих курсов - очень хороший у documentat.io: бесплатный есть в Ютубе/ на сайте, на платный очередь в месяцы
Роль технического писателя в IT компании. Внедрение тех. писателя в компанию