After-party с Григорием Циперманом. Обсуждаем нюансы оценки аналитика.

А если кодер игнорирует постановку и пишет код по названию постановки, как оценивать качество работы аналитика?

Вот аналитик работает на проекте и быстро пишет подробные требования. В них все детально и с примерами изложено, спроектировано. Но разработчики по каким-то причинам не вникают в требования и часто игнорируют дескрипшен и делают задачу по заглавию и своим соображениям, или делают часть описания и закрывают фичу, или делают по-своему при этом не согласовывая ни с кем и не ставя в известность. Как в этом случае можно оценивать качество работы аналитика? Ведь невозможно отвечать за качество работы других людей.

Ну, это, скорее, не относится к качеству работы аналитика. Правильно поставленный процесс разработки четко регламентирует ответственность за результат. Предложенная ситуация крайне плоха и говорит о неспособности кодера работать в команде.
Отлавливаются несуразности кода только в процессе внутренней приемки кода: здесь достаточно сравнить предложенный вариант программы с исходной постановкой.

А если кодер не воспринимает консультации аналитика, что делать?

Про консультацию разработчиков сталкивалась с такой ситуацией, когда кодер переспрашивал раз по 10+ один и тот же вопрос. И были описаны требования, и каждый раз получал один и тот же ответ и говорил "понятно". Но на просьбу повторить как понял отвечал диаметрально противоположное и в кодинге игнорировал большую часть сказанного. По уровню квалификации младший миддл. Но как при этом оценивать где решает квалификация аналитика, а где кодера? Кто выше по грейду тот и прав?

Это клинический случай. Требует хирургического вмешательства руководителя проекта. Пусть он поприсутствует на консультации с таким кодером.
Что же касается ответственности – см. предыдущий ответ.

А что делать, если заказчик постоянно меняет требования? И согласование ЛПР оперативно не доступно?

Или допустим, аналитик расписал бизнес-модель достаточно быстро, но заказчик постоянно добавляет детали и изменяет предыдущие показания. Это замедляет процесс согласования по причинам, на которые напрямую может быть сложно влиять. Например, часть ЛПР вне доступа и участвует в согласовании только раз в месяц.

А вот эта ситуация относится к ответственности руководителя проекта. Вернее, руководителей проекта (от исполнителя и от заказчика).
Изменение требований заказчика, как учат нас титаны разработки, есть процесс объективный, которым, впрочем, можно управлять.
А управление основывается на факте совпадения интересов руководителей проекта: оба ограничены временем и ресурсами проекта. Я сталкивался с подобной ситуацией не один раз и, как руководитель проекта, поступал следующим образом:
• Есть согласованная модель, к которой поступают новые требования.
• Первым шагом – оцениваю к чему это приведет по времени и по затратам.
• Затем, обсуждаю это с эккаунт менеджером и вырабатываем, что реально предъявлять заказчику.
• То же обсуждение проводим с руководителем проекта от заказчика и согласовываем предъяву (обязательно согласуем – он тоже заинтересован).
• Передаем предъяву на утверждение ЛПР.
Далее возможны два варианта:

1. Источник новых требований получает по голове, и мы продолжаем разработку так, как и было.
2. Наша предъява принимается в каком-то виде, что дает нам возможность хотя бы перенести сроки.
   

Бывало, выкручивали руки – приходилось на тех же условиях делать доработки. Но в любом случае, предложенный алгоритм снижал уровень ответственности руководителей проекта.
Но самое главное: методика создания систем на всех этапах должна обеспечивать максимально легкую модификацию модели системы и ее кода. И такие методики я знаю!

1) Источник новых требований получает по голове, и мы продолжаем разработку так, как и было
2) Наша предъява принимается в каком-то виде, что дает нам возможность хотя бы перенести сроки.

Что делать, если интервью с ЛПР противоречат тому, что говорили их подчиненные?

При этом встречи с ними [ЛПР] сильно изменяют процесс от того что говорили их подчиненные

У ЛПР и персонала разные уровни восприятия процесса: первые определяют целеполагание деятельности, абстрагируясь от деталей, а вторые – детализируют ее.
Беда, если ЛПР начнут в деталях излагать те работы, которые выполняют их подчиненные. И наоборот, философские рассуждения рядовых сотрудников о смысле процессов могут оказаться не верными.
Поэтому я предпочитаю использовать материал, полученный от респондентов, по его прямому назначению. (Хотя, на интервью слушаю все и всех).
Еще раз: процесс согласования разработанной модели имеет критическое значение. Его игнорировать опасно! Тем более, при наличии противоречий в результатах интервью.

Является ли ошибкой аналитика не выяснение критически важной информации, которую не озвучивал заказчик?

Если в процессе работы на проекте от заказчика начинают появляться новые вводные по требованиям. Так называемые "серые зоны". То, что при сборе требований заказчик никак не озвучивал, в документации не фигурировало. Но это влияет на уже сделанный функционал. Является ли это ошибкой аналитика, что не выяснил, не провел настолько тщательное расследование?

Важный и сложный вопрос, не имеющий однозначного ответа.
В притче об ученике зеркальщика, который через три года обучения не смог сделать зеркало потому, что мастер не передал ему важный секрет: на амальгаму, разлитую по стеклу, необходимо подуть. Виноват ли ученик? С другой стороны, информацию из респондентов вытягивает аналитик: как спросит, так и ответят.
Думаю, что количество «серых зон», не вскрытых аналитиком, является оценкой его квалификации (см. «Аналитика: получение модели as-is и переход к to-be»). Но трагедии из этого делать не надо: 100%-ный результат – это как 100 баллов по ЕГЭ. И еще раз отмечу важность процесса согласования модели.
Наличие в команде проекта высококлассного аналитика, специалиста с большим опытом в значительной мере страхует от этого эффекта. Что такое классный аналитик? Это специалист с опытом, достаточным, чтобы на интервью рассказывать заказчику, как он работает и зачем. А заказчик восхищенно слушает этого умника: ведь все верно…