Comments 1
На тему сбора требований я бы дополнил статью следующими нюансами, имеющими место быть:
1. Один из залогов успеха сбора требований, четко понимать — кто есть кто. Принимает это лицо решения или нет. Бывают спонсоры, заказчики, пользователи. Надо понимать, кто заказчик и какие цели он ставит к системе, в которой будут трудиться сотрудники.
Опрашивая сотрудника, знакомясь с его видением системы (и требованиями к ней), можно на выходе получить полное противоречие целям заказчика. Работник хочет быть нужным и незаменимым, но при этом выполнять посильный для себя труд. У руководителей как правило другие цели ;)
2. От сотрудников мы получаем видение систему As_Is. Как правило то, как они сейчас работают. А на выходе нам надо систему под цели заказчика(To_Be). Опять включаем голову и не кидаемся делать 1в1, как просят сотрудники. Ну и к тому же, сотрудники как правило профаны в построении систем. Понятия целостности, полноты, непротиворечивости, реальности выполнения требований у них нет.
3. Как можно чаще задаем вопрос «Зачем?» и «Почему?», вместо «Что?» и «Как?». Аналитик должен понять суть вещей, а не потонуть в видении конечного решения сотрудниками.
Разумеется везде нужен здоровый компромисс, без крайностей. Прошу прощения, если кого задел очевидностью нюансов ^^. Просто частенько вижу, как на подобные грабли наступают новички в деле сбора требований. Список нюансов конечно можно продолжать. А вообще, на мой взгляд вот два первых правила сбора требования:
1. Требования надо записывать.
2. Требования надо нумеровать.
До смешного, сколько раз видел. как проблем можно было бы избежать, выполнив эти два примитивных тезиса.
1. Один из залогов успеха сбора требований, четко понимать — кто есть кто. Принимает это лицо решения или нет. Бывают спонсоры, заказчики, пользователи. Надо понимать, кто заказчик и какие цели он ставит к системе, в которой будут трудиться сотрудники.
Опрашивая сотрудника, знакомясь с его видением системы (и требованиями к ней), можно на выходе получить полное противоречие целям заказчика. Работник хочет быть нужным и незаменимым, но при этом выполнять посильный для себя труд. У руководителей как правило другие цели ;)
2. От сотрудников мы получаем видение систему As_Is. Как правило то, как они сейчас работают. А на выходе нам надо систему под цели заказчика(To_Be). Опять включаем голову и не кидаемся делать 1в1, как просят сотрудники. Ну и к тому же, сотрудники как правило профаны в построении систем. Понятия целостности, полноты, непротиворечивости, реальности выполнения требований у них нет.
3. Как можно чаще задаем вопрос «Зачем?» и «Почему?», вместо «Что?» и «Как?». Аналитик должен понять суть вещей, а не потонуть в видении конечного решения сотрудниками.
Разумеется везде нужен здоровый компромисс, без крайностей. Прошу прощения, если кого задел очевидностью нюансов ^^. Просто частенько вижу, как на подобные грабли наступают новички в деле сбора требований. Список нюансов конечно можно продолжать. А вообще, на мой взгляд вот два первых правила сбора требования:
1. Требования надо записывать.
2. Требования надо нумеровать.
До смешного, сколько раз видел. как проблем можно было бы избежать, выполнив эти два примитивных тезиса.
Sign up to leave a comment.
Методы сбора требований или «Как понять, что хочет заказчик?»