Comments 8
Здесь ключевой момент — найти тех, кто действительно является конечным потребителем документации
Скупая слеза скатилась по щеке техписа, пишущего документацию для внешних клиентов.
Написано хорошо, но верхнеуровнево, а дьявол обычно в деталях)
Отлично! Спасибо!
Привет, а коллегу себе не ищете, случайно? 😅
Отличная статья, спасибо!
Понравился скриншот про использование заголовков 2 уровня. Это откуда?
По погружению в проект вплоть до тестирования разными ролями: в идеале так и нужно делать. Но в реальности времени на такое погружение нет. Хотелось бы какую-нибудь более подробную статью на эту тему, в духе "искали медь, нашли золото: как собирать информацию для проекта"
Первочередная задача для техписа - умение организовать свою работу задолго до сдачи проекта / релиза продукта. Особенно если он первый в компании или вообще один продолжительное время (у меня это частый случай).. Редкий руководитель или ПМ может грамотно организовать работу писателя, "вчера документация никому не сдалась, сегодня - давай все, что есть, немедленно". Так что приходится учить вышестоящих выстраивать процесс, а они это далеко не всегда любят и стремятся поддерживать. Со своими проблемами, в большинстве случаев, остаешься один, внутренняя "кухня" твоей работы почти никому не интересна (кроме немногочисленных коллег по документированию, если они есть). От тебя мало кто зависит из команды, но ты зависишь почти от всех - они дают информацию, консультируют. Да, и вклад твой в продукт для вышестоящих, как правило, мало заметен, оценивается по остаточному принципу, в основном - "таски закрыты, доки есть к сроку, и хорошо", а упор в качество чаще не приветствуется.
Это основные минусы присутствовали почти во всех компаниях (от производственных до интеграторов и софтовых разработчиков).
Несмотря на вышеперечисленное, профессия нравится, в ней уже более 12 лет, Senior. О плюсах профессии умолчу, у каждого они свои))
Как создаются шедевры: будни технического писателя