(направление - инструкции по продукту для внешних пользователей)?
Как вообще можно оценить эффективность работы?
чем реже внешние пользователи достают техподдержку вопросами, тем выше эффективность работы техписателя) НО, это в том случае, когда пользователи вообще читают документации и делают это нормально, а не по принципу "люди читают жопой")) в качестве критериев эффективности можно взять понятность, полноту, логичность, непротиворечивость и актуальность документации, но для KPI это надо докручивать до измеримых единиц, что проблематично само по себе
Пытались у нас ввести, в итоге ничего не вышло, потому что руководитель говорил что-то из серии «не берите больничный и отпуск, больше работайте»…
вот да, типовой тупиковый подход. у нас обещали +5к годовой премии для некурящих... но так ее никто ни разу и не получил
Вот и мы уперлись в то, что по сути - с развитием системы процесс переписывания пользовательской документации бесконечный. И все это - просто входит в мою работу. С несопоставимыми объемами по отдельным процессам - где-то больше, где-то меньше. Даже в количестве документов не измерить
сделать документацию полной и совершенной можно только к закрытой и неработающей системе)) а так это бесконечное занятие
Можно пытаться следить за тем, чтобы в документации были максимально описаны фичи этой системы, доступные читателям той документации, таким образом понятие "полнота" трансформируется в "полнота для такой-то версии системы". Ещё можно стремиться к тому, чтобы если релиз документации происходит отдельно от релиза системы, разрыв во времени между релизами новой версии системы и соответствующей ей новой версии доки был не более N дней/спринтов/других единиц измерения, которые вам подходят
Релиз документации отдельно от релиза системы это что-то за гранью фантастики
Почему же. Только что на работе обсуждали, что у нас фактически релиз-ноты должны выходить при разливке изменений компонентов на 30% рынка. А это лаг во времени до 1,5 месяцев.
увы, у нас до дня релиза не знаешь, что и на какие клиентские базы накатят. То есть, черновой список я собираю. Но правишь его в последний день. И уже точно не успеваешь внести изменения сразу в руководства, когда планировали включить новую функциональность в одном варианте, не доработали, внесли в урезанном.
у нас хочешь-не хочешь, а процессы идут параллельно и все дописывается вплотную до релиза. если что-то не успевается, то правится после испытаний. самое прекрасное - это когда думаешь, что "ура, все дописала", а они берут и выкатывают новую фичу..
И это тоже. И в бэклоге про эту новую фичу - ни гугу. "Я художник, я так вижу". Вот мы с руководителем и застряли с моим kpi, потому что слишком много образуется зависимостей для итогового результата.
а вы с руководителем сформулировали цель вашей работы, вашего присутствия в команде?
С этим как раз все понятно. Приведение в структурированный порядок и актуализация всей базы знаний, которой до моего прихода просто не существовало. Это, в целом, верхнеуровневая задача.
А зачем вообще хотите ввести кпи для тебя?
как дополнительная мотивация, которая оплачивается отдельно
Не существует точной метрики, на собесе спрашивают иногда, типа сколько страниц вы можете за день сделать, можно и одну, а можно и 20-20. Все зависит от того, есть или нет исходные данные. В вашем случае определить kpi это пустая затея, так как для этого нужно определить все процессы в компании и у каждого в разработке должен быть свой kpi, скажите это руководству своему, а если не гоните желанием этого делать, то придумайте, что то связанное с простым форматированием текста для отчетности
Обсуждают сегодня