Послушал несколько дискуссий про роль аналитика на проекте, и, кажется, очень часто понимание работы (со стороны руководителей!) сводится к механическим вещам: сколько требований описано, насколько документация процессов или системы соответствует реальности, то есть, аналитик выступает таким механизмом для составления компактного описания системы — "модели" в классическом понимании, как "более простой системы, которая несёт информацию о более сложной системе".
При этом разговор про качество модели почему-то идёт туго, сбиваясь на "описание системы соответствует системе", то есть где-то тут есть неразличение описания и модели. Соответственно, возникает непонимание способов оценки качества работы аналитика. Количественно, по строкам документов? Так их должно быть наоборот меньше — чем выше соотношение "объяснительная сила модели" / "размер модели" — тем лучше. По отзывам от потребителей — чем меньше уточняющих вопросов от программистов / тестировщиков — тем лучше? Хорошая характеристика, но лукавая — может, программист вообще эти постановки не читает, тогда и вопросов не будет :)
Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.
Другая распространенная история, когда аналитик транслирует требования в постановки. По сути, делает непонятное понятным. Было непонятно, что делать, теперь стало понятно. Тут возникает неясность: насколько подробной и исчерпывающей должна быть постановка задачи? Нужно ли программисту максимально четко написать, что делать, или достаточно описать общую потребность, а дальше программист уже сам решит? Такие обсуждения тоже были, но ответ обычно "это зависит от многих параметров". От чего конкретно зависит, правда, мало кто говорит. Ну, от опыта программиста зависит. Тут происходит интересная подмена: если аналитик ставит задачу детально, то он уже не аналитик, а проектировщик — он принял решение по тому, как система должна быть сделана, а не по тому, что можно делать при помощи системы. Это происходит незаметно, поэтому и оценить это сложно. И это меня сильно тревожит, так как сутевая часть работы заметается под ковер.
При этом разговор про качество модели почему-то идёт туго, сбиваясь на "описание системы соответствует системе", то есть где-то тут есть неразличение описания и модели. Соответственно, возникает непонимание способов оценки качества работы аналитика. Количественно, по строкам документов? Так их должно быть наоборот меньше — чем выше соотношение "объяснительная сила модели" / "размер модели" — тем лучше. По отзывам от потребителей — чем меньше уточняющих вопросов от программистов / тестировщиков — тем лучше? Хорошая характеристика, но лукавая — может, программист вообще эти постановки не читает, тогда и вопросов не будет :)
Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.
Другая распространенная история, когда аналитик транслирует требования в постановки. По сути, делает непонятное понятным. Было непонятно, что делать, теперь стало понятно. Тут возникает неясность: насколько подробной и исчерпывающей должна быть постановка задачи? Нужно ли программисту максимально четко написать, что делать, или достаточно описать общую потребность, а дальше программист уже сам решит? Такие обсуждения тоже были, но ответ обычно "это зависит от многих параметров". От чего конкретно зависит, правда, мало кто говорит. Ну, от опыта программиста зависит. Тут происходит интересная подмена: если аналитик ставит задачу детально, то он уже не аналитик, а проектировщик — он принял решение по тому, как система должна быть сделана, а не по тому, что можно делать при помощи системы. Это происходит незаметно, поэтому и оценить это сложно. И это меня сильно тревожит, так как сутевая часть работы заметается под ковер.