166
Обучение / Re: Хотите протестировать свои навыки?
« : 15 Марта 2010, 16:29:00 »
Так же спорный вопрос № 8. Я не совсем согласен с тем что сценарий это все состояния Use Case
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Наверно, можно оценить эффективность аналитика по количеству запросов на изменение, вот только анализ этих самых запросов должен быть очень качественным.
LastLegion86, а можно пару уточняющих вопросов - т.е. вы анализируете каждый запрос на изменение и типизируете (дифференцируете) его. Кто участвует в этом процессе (РП, нач. отдела аналитики, ведущий разработчик, архитектор или...).
Перевести "в числовые значения" (некие абсолютные показатели) не сложно. Проблематично провести детальный анализ запросов в условиях большого числа изменений вцелом по фирме.
По поводу запросов на изменение...
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший. На все наши доводы, что дайте нам хотя бы сделать экспресс анализ нескольких объектов для получения сравнительной оценки только отмахнулся.
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение. Но аналитик не виноват...
Если уж судить работу аналитика по количеству запросов на изменение, то надо брать каждый (запрос) и анализировать его природу. Трудоемкая работа.
может такая ситуация еще и повторится в ближайшее время: кризис глубже не пойдет+демографический спад 90х.
Если я правильно понял, причина сомнения многих коллег относительно эффективности этого способа оценки основывается на уверенности в том, что за 3 месяца у заказчика требования поменяются в любом случае, так как он более глубоко осознает задачу по мере наблюдения за разработкой. Я раньше придерживался такого же мнения, тем более, что эта точка зрения помогает аналитику снимать с себя ответственность за большое количество чейндж реквестов на функционал.
Но в последнее время мне кажется, что действительно профессиональный аналитик, умеющий докапываться до корневых проблем, разбирающийся в предметной области, и представляющий современные технологические и бизнес - тенденции должен предвидеть (хотя бы на 90%) такие изменение требований и заранее предлагать их заказчику.
Другое дело, что когда появляется такой человек, то он за одну зарплату долго не работает
Только продукт платный:)
ткните пальцем, где из предыдущего обсуждения четко и ясно следует, что речь шла именно об этом?...
речь шла о запросах на изменение - из 20 человек, участвующих в обсуждении, каждый может подразумевать под "запросами на изменение" все, что угодно.
вот это типичная программерская логика: "а я думал, что это не то, а это..." Елы-палы, ну мало ли кто что думал - не можем же мы друг другу залезть в мозги и поправить там нужные шестеренки.
Остается только один инструмент взаимопонимания - язык. Если пользоваться им по назначению.