Продолжаем разбор типовых ошибок, и сегодня ошибка #3 — недостаток коммуникации с командой по поводу структуры и пользования документацией (постановок задач и баз знаний).
Тут можно выделить две абсолютно типовые подпроблемы:
1) Навязывание документации без учёта фидбэка.
Как не стоит делать:
На курсе нас научили / на проекте так исторически сложилось, что мы делаем вот такие убернавороченные срски, сторьки и юз кейсики в лучших традициях предков. А потому, узри, команда, мой гений!
Проблема в том, не всякая команда поднимет бунт, если им что-то не нравится или не работает так, как могло бы в идеальном мире. Классно, если есть ретроспективы, где кто-то под общий шумок может и заметить, что с документацией что-то не так. Но может быть и так, что половину ваших трудов люди не читают, ибо непонятно/сложно/много-бесполезно.
Как стоит сделать: как только вы оказываетесь на новом для себя проекте, соберите фидбэк команды по поводу шаблонов документации, которые вы планируете использовать. Покажите им пример описания требований в виде стори, вертикальных кусков спеки, прототипов, диаграмм, после чего устройте воркшоп / вышлите опросник / подойдите к каждому лично и пообщайтесь — в общем, соберите честный фидбэк насчёт того, хватает ли информации для выполнения работы, нет ли лишнего и понятен ли язык и контент. Естественно, после этого обработайте результаты и в частности те моменты, где на базе фидбеков начинает прослеживаться подобие системной проблемы. Адаптированная под проект и команду документация всегда лучше универсального шаблона на все времена.
2) Отсутствие обучения команды пользованием артефактами.
Хороша ли ситуация, когда ваша модель данных на безукоризненном UML выглядит для джуна Васи как что-то, прилетевшее из космоса? И потому он благополучно скипает это (или, что ещё хуже, интерпретирует по-своему)?
Ваша задача, как вы понимаете, прокоммуницировать информацию. Важно постараться не путать её с задачей "показать всем, какие я высокоинтеллектуальные артефакты писать умею". Тут также могут помочь опросы и получение фидбэка всякими иными способами. И если адресатам вашей документации что-то не очень ясно, то, с одной стороны, вы можете пойти по пути в пункте 1 выше, а с другой — не стесняйтесь сделать мини-тренинг:
- Вот, как читать и в какой последовательности идти по документу, когда вам поступает задача на реализацию/тестирование фичи
- Вот, как интерпретировать мои UML-модели, прототипы, юз кейсы и пр.
- Вот, где у вас есть свобода действий ("могу сам придумать"), а вот где её нет
- Вот, что делать, если что-то неясно или есть подозрения в неполноте и прочих проблемах ("идти ко мне :)" )
Тут можно выделить две абсолютно типовые подпроблемы:
1) Навязывание документации без учёта фидбэка.
Как не стоит делать:
На курсе нас научили / на проекте так исторически сложилось, что мы делаем вот такие убернавороченные срски, сторьки и юз кейсики в лучших традициях предков. А потому, узри, команда, мой гений!
Проблема в том, не всякая команда поднимет бунт, если им что-то не нравится или не работает так, как могло бы в идеальном мире. Классно, если есть ретроспективы, где кто-то под общий шумок может и заметить, что с документацией что-то не так. Но может быть и так, что половину ваших трудов люди не читают, ибо непонятно/сложно/много-бесполезно.
Как стоит сделать: как только вы оказываетесь на новом для себя проекте, соберите фидбэк команды по поводу шаблонов документации, которые вы планируете использовать. Покажите им пример описания требований в виде стори, вертикальных кусков спеки, прототипов, диаграмм, после чего устройте воркшоп / вышлите опросник / подойдите к каждому лично и пообщайтесь — в общем, соберите честный фидбэк насчёт того, хватает ли информации для выполнения работы, нет ли лишнего и понятен ли язык и контент. Естественно, после этого обработайте результаты и в частности те моменты, где на базе фидбеков начинает прослеживаться подобие системной проблемы. Адаптированная под проект и команду документация всегда лучше универсального шаблона на все времена.
2) Отсутствие обучения команды пользованием артефактами.
Хороша ли ситуация, когда ваша модель данных на безукоризненном UML выглядит для джуна Васи как что-то, прилетевшее из космоса? И потому он благополучно скипает это (или, что ещё хуже, интерпретирует по-своему)?
Ваша задача, как вы понимаете, прокоммуницировать информацию. Важно постараться не путать её с задачей "показать всем, какие я высокоинтеллектуальные артефакты писать умею". Тут также могут помочь опросы и получение фидбэка всякими иными способами. И если адресатам вашей документации что-то не очень ясно, то, с одной стороны, вы можете пойти по пути в пункте 1 выше, а с другой — не стесняйтесь сделать мини-тренинг:
- Вот, как читать и в какой последовательности идти по документу, когда вам поступает задача на реализацию/тестирование фичи
- Вот, как интерпретировать мои UML-модели, прототипы, юз кейсы и пр.
- Вот, где у вас есть свобода действий ("могу сам придумать"), а вот где её нет
- Вот, что делать, если что-то неясно или есть подозрения в неполноте и прочих проблемах ("идти ко мне :)" )