Комментарии 3
Я даже зарегистрировался ради того, чтобы подушнить.
Итак:
"Слишком много документации" это не проблема. Это наоборот хорошо. Но она должна быть структурирована таким образом, чтобы новому сотруднику было понятно. В вашем примере проблема в плохом подходе, а не в количестве документации. Ну и если только один сотрудник знает, что где лежит и почему - это проблема процессов.
Стесняюсь спросить, что это за контора, где задачи не документируются хотя бы в бэклоге. Если такую вещь надо объяснять, то проблема или с процессами или с кадрами. Скорее всего второе. Нет записи - нет задачи.
"«У нас есть отдельный раздел документации для бизнеса. Он делится на фичи, которые нужно будет выполнить или которые уже выполнены. Дальше системный аналитик описывает, где и какие доработки нужны для этих фичей, размещает ссылки на страницы разработки." Да именно для это и придумали jira и confluence. И как правило является бэклогом. Все что нужно для продукта в ПЭ 2 документа. Инструкция пользователя и инструкция администратора. Дальше можете вести бэклог хоть в Excel или word, хоть на доске кабинета стикеры перевешивать. Как вам удобно. Остальным будет по барабану.
В MVP вместить описание архитектуры, роуд сам, ролевую модель в юзер стори. Советую попробовать
Привет!
Да, мы об этом и пишем. Документация должна быть структурирована и размечена в явном виде: какая актуальная, какая архивная.
Было бы хорошо, если бы все делали хорошо, а плохо бы не делали. Но, к сожалению, часто о качественном оформлении документации забывают.
Да, именно для этого 🙂
Спасибо за совет!
Да, хороший тон для аналитика — качественное документирование требований. Но из практики знаю, что бывает по-разному. Отсюда родилась эта статья с советами.
Что одному - вредные советы, другому - лайфхаки, как стать незаменимым сотрудником :) :(
Как вести документацию, чтобы никто ничего не понял. Немного теории и вредные советы от МТС Диджитал