Size: a a a

DocOps-сообщество

2019 January 25

SK

Sergei Kutcher in DocOps-сообщество
Хмм
источник

SK

Sergei Kutcher in DocOps-сообщество
Вот такой вопрос
источник

SK

Sergei Kutcher in DocOps-сообщество
Как вы оцениваете временные затраты на написание документации?
источник

KC

Kseniya Chudakova in DocOps-сообщество
Sergei Kutcher
Как вы оцениваете временные затраты на написание документации?
вот это тоже интересно
источник

NV

Nick Volynkin in DocOps-сообщество
источник

SK

Sergei Kutcher in DocOps-сообщество
О, благодарен за такое
источник

NV

Nick Volynkin in DocOps-сообщество
Кратко: сначала ничего не ясно, потом начинаешь узнавать типичные задачи и предсказываешь сроки точнее
источник

SK

Sergei Kutcher in DocOps-сообщество
А как определяете завершенность документации? Фидбек от пользователей или оценка руководства?
источник

NV

Nick Volynkin in DocOps-сообщество
Документация завершена, когда решает задачу читателя и задачу бизнеса. Про это есть тут: t.me/docops/69
Telegram
DocOps
Целеполагание технического документа

Авторы всех трёх комиксов из прошлого поста проделали отличную работу с целеполаганием:

— Комиксы написаны для конкретной аудитории. Ясон — воплощение целевого читателя. Он руководит админами в крупной компании, уже успел поработать с контейнерами и погибает под ворохом типичных проблем. Гера, воплощение автора, упоминает всё, что он уже должен знать, и подробно объясняет всё новое.

— Решают задачу читателя  — понять основы сложной предметной области. После этого читатель сможет изучать её дальше или использует знания, чтобы принять решение. Все комиксы объясняют сложную тему, при этом развлекают и помогают удержать внимание. Думаю, начинать знакомство с man kubectl мне было бы гораздо тяжелее. Конечно, комикс не заменит документацию, но она решает совсем другие задачи.

— Решают задачу бизнеса. В первом комиксе Гера попутно продаёт читателю Google Cloud. Второй и третий приглашают на сайт компании DNSimple, которая предоставляет DNS и перепродаёт SSL-сертификаты.

Эти…
источник

SK

Sergei Kutcher in DocOps-сообщество
Забавное то, что юзая документацию  Gcloud сложно развернуть достаточный инстанс или api
источник

NV

Nick Volynkin in DocOps-сообщество
Качество проверяется на нескольких слоях: грамотность текста, структура и понятность, полнота и корректность фактов, соответствие бизнесовой задаче. При этом грамотность и факты — критерии объективные и четко проверяемые. А вот структура, понятность и задача бизнеса — субъективные, но с этим тоже можно жить.
Это всё очень похоже на пирамиду тестирования, я об этом тоже писал: t.me/docops/157
Telegram
DocOps
Пирамида рецензирования

В разработке документации есть этапы (слои) рецензирования. Это порядок проверки документа, он примерно такой:

— сам перечитал и проверил на грубые ошибки;
— отдал коллеге на проверку грамотности, структуры и стиля;
— отдал эксперту на проверку смысла и содержания.

Если на конкретном этапе есть замечания, документ возвращают доработку, а не передают дальше.

А в тестировании есть понятие «пирамида тестирования». Тесты выполняются в таком порядке:

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

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

SK

Sergei Kutcher in DocOps-сообщество
Nick Volynkin
Качество проверяется на нескольких слоях: грамотность текста, структура и понятность, полнота и корректность фактов, соответствие бизнесовой задаче. При этом грамотность и факты — критерии объективные и четко проверяемые. А вот структура, понятность и задача бизнеса — субъективные, но с этим тоже можно жить.
Это всё очень похоже на пирамиду тестирования, я об этом тоже писал: t.me/docops/157
Telegram
DocOps
Пирамида рецензирования

В разработке документации есть этапы (слои) рецензирования. Это порядок проверки документа, он примерно такой:

— сам перечитал и проверил на грубые ошибки;
— отдал коллеге на проверку грамотности, структуры и стиля;
— отдал эксперту на проверку смысла и содержания.

Если на конкретном этапе есть замечания, документ возвращают доработку, а не передают дальше.

А в тестировании есть понятие «пирамида тестирования». Тесты выполняются в таком порядке:

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

Если на конкретном уровне продукт не проходит тесты, то тесты на более высоком уровне не имеют смысла; продукт возвращают на доработку.
 
Кажется, между рецензированием документа и тестированием продукта есть что-то общее.
Спасибо, пара сообщений и есть пища для ума.
И все же, хотелось бы услышать, как и что у коллег
источник

NV

Nick Volynkin in DocOps-сообщество
Sergei Kutcher
А как определяете завершенность документации? Фидбек от пользователей или оценка руководства?
Фидбек пользователей — это тоже показатель, но его обычно можно получить только после релиза документации. Он как продуктовая аналитика.
источник

L

Lana in DocOps-сообщество
Sergei Kutcher
А как определяете завершенность документации? Фидбек от пользователей или оценка руководства?
Документация завершена, когда она живет, используется, когда в нее вносят пулл реквесты, хотят дополнить, покритиковать, прокомментировать
источник

L

Lana in DocOps-сообщество
Как наверное и любой продукт
источник

NV

Nick Volynkin in DocOps-сообщество
О, спасибо что об этом вспомнила. Согласен. Definition of done задачи на документацию — это когда документацию опубликовали и ей начали пользоваться и, если дока внутренняя, начали контрибьютить в неё.
Про это я тоже писал: t.me/docops/64. Идея пришла от Игоря Цупко @lovely_it_hell.
источник

A

Antonio in DocOps-сообщество
С другой стороны, контрибьюшн можно считать и признаком того, что документация не завершена и есть пробелы
источник

AK

Anya Kuchumova in DocOps-сообщество
Nick Volynkin
Фидбек пользователей — это тоже показатель, но его обычно можно получить только после релиза документации. Он как продуктовая аналитика.
ну можно ещё исследования проводить. и это можно сделать до релиза. хотя времени занимает безумное количество
источник

NV

Nick Volynkin in DocOps-сообщество
Antonio
С другой стороны, контрибьюшн можно считать и признаком того, что документация не завершена и есть пробелы
Если это дока для пользователей о продукте, то она теряет актуальность с каждой фичей.
Если дока про внутренние процессы в компании, то она точно неполна, потому что один человек не может всё знать. Тут тонкое различие: документация неполна, но задача на её разработку завершена, потому что документация начала жить и собирать знания.
источник

A

Antonio in DocOps-сообщество
Лично для меня критерий завершенности документа, это когда он четко отвечает на вопросы, поставленные в задаче.
Т.е. если это фича - для кого она, что позволяет и как ее настроить. Если, к примеру, эндпоинт, то это параметры, с которыми на него можно отправлять запросы, тело запроса (если нужно), ответ от сервера, ошибки.
Чтобы точно знать о чем писать, мы в задаче оговариваем definition of done
источник