Добрый день, коллеги!

Обсуждаем с тимлидером структурирование и управление требованиями в TFS. Одним из пунктов предложила ему указывать трудоемкость выполнения требований совместно с приоритетом, указанным  Заказчиком. Получила вопрос: "Зачем, как ты будешь это использовать?".

Сходу родились такие варианты ответа:
1. При разговоре с Заказчиком часто возникает вопрос о трудоемкости, в зависимости от этого Заказчик может принять решение о включении этой фичи в текущую или отложить до следующих версий.
2. При указании одновременно приоритета требования и трудоемкости легче строить план работ (на что мне скорее всего аргументированно ответят, что это работа руководителя и я не должна об этом беспокоиться).
3. Слишком большая трудоемкость требования может являться критерием того, что его нужно декомпозировать на несколько. Способ управления качеством моей работы.

Какую еще пользу может принести знание трудоемкости выполнения требования аналитику? И стоит ли настаивать на этом пункте?

Аня, ты хочешь, чтобы мы помогали тебе отмазываться?

Если у тебя вопрос практический  — зачем ТЕБЕ это знать — то тут мы не поможем )

Если вопрос теоретический «для чего вообще может понадобиться оценка трудоёмоксти аналитику», то у меня встречный вопрос — а зачем это тебе?

Обычно эта оценка нужна для управления требованиями как части управления ходом создания продукта (рамки, очерёдность).

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

Для грубых оценок (например, из множества {"просто", "сложно", "ппц"}) польза только одна - понять примерную трудоемкость/стоимость, примерно раскидать требования по релизам/срокам. Применять это можно на коротких проектах, либо при первичной оценке плана/бюджета на разных сценариях решения задач.

Для точных оценок поддержу предложенные Анной варианты, к ним и добавить-то особо нечего, единственное - фактическая трудоемкость реализации требования может пригодиться для оценки трудоемкости/сроков *будущих* проектов, если требования *переиспользуются*.

Если тим-лид по-прежнему не верит в то, что требования можно оценивать, то следует его познакомить с методиками Use Case Points, Funtion Points Analysis
В общем вывод пока такой: это будет полезно, если этим пользоваться, но использование сильно зависит от компании/команды/проекта/бизнеса/продукта.

Аня,

п.1-2 - это чистой воды менеджерская работа, если ты ее выполняешь, то тогда и аргументация на твоей стороне, если нет, то привлеки МП и продай ему это.
п.3 - с трудом верится, что это поможет. Бывает так, что требований 2 строчки, а с т.з. архитектуры это ой как не просто. Ну разобьешь ты это требование на 2-3 штуки и что? Это уже таски разработчикам/арх-ам, причем тут требование? Бывает наоборот, что лучше не бить требования, чтобы выидеть полную картину ...

Тебе реально зачем это надо? Скажи честно

сообщение устарело

Аня,

п.1-2 - это чистой воды менеджерская работа, если ты ее выполняешь, то тогда и аргументация на твоей стороне, если нет, то привлеки МП и продай ему это.
п.3 - с трудом верится, что это поможет. Бывает так, что требований 2 строчки, а с т.з. архитектуры это ой как не просто. Ну разобьешь ты это требование на 2-3 штуки и что? Это уже таски разработчикам/арх-ам, причем тут требование? Бывает наоборот, что лучше не бить требования, чтобы выидеть полную картину ...

Тебе реально зачем это надо? Скажи честно

Саша, по результатам хорошего размышления, честно могу сказать, что это очередная попытка получить обратную реакцию на создаваемые мной требования. Сейчас я в большинстве случаев не получаю вопросов со стороны разработки при создании требований. Это очень смущает. Отсутствие вопросов может быть в двух случаях:
1. все понятно (не могу льстить себе настолько);
2. ничего не понятно (вроде не такой я паршивый аналитик).

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

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

Наверное, предложение указать трудоемкость требований с моей стороны является попыткой получить обратную связь до того, как требования будут пущены в работу и разработчики начнут удивляться: "А что, еще это надо делать?". (Был случай, когда оценка проекта была произведена по первоначальному документу заказчика, а не по выявленным и формализованным мной требованиям, которые были значительно обширнее. И это вовсе не потому, что первичный документ был более читабельным.)

Анна, наверное вопрос не в том "Зачем, как ты будешь это использовать", а "Как ты будешь ее определять?"
Когда Вы сможете описать этот процесс, то поймете, будет ли ценность в этой оценке, насколько она (в соответствии с Вашим процессом определения) будет адекватной. Если эта оценка будет определяться Вами самостоятельно, без общения с проектировщиками/разработчиками и будете называть сразу ее заказчику, то вряд ли будет польза. Может оказаться много конфликтов, как внутри (с РП), так и с внешней стороной - заказчиком.
Поэтому, на мой взгляд, надо сначало описать не просто поля в БД для заполнения, а процесс, который за этим стоит и понять, нужен ли такой процесс Вашей компании.

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

А вот нужен ли такой процесс и как его построить и пытаюсь понять.

Прошу прощения у всех, что создала тему и долго не отвечала. Редко общаюсь на этом форуме и не пришло в голову, что на обновления по созданной мною теме нужно подписываться отдельно. Думала, что все молчат, никто не отвечает. =)

сообщение устарело

Анна,

фактически в предыдущих сообщениях Вы говорите о том, что процесс взаимодействия в коллективе налажен плохо. При этом у Вас полномочий меньше, чем ответственности. Приходиться смотреть в глаза заказчику и отвечать за процесс, которым Вы не управляете, краснеть, бледнеть, в общем чувствовать себя неважно. Аналогично, опуская свои требования в "черный ящик", Вы находитесь все время в состоянии стресса, т.к. не знаете во что это выльется.
Если мои предположения верны, то 
1. Берегите здоровье. Это напоминает классический эксперимент.
2. Введением нового поля Вы не решите эту задачу. Более того, рискну предположить, что ее решение лежит вне области Вашей компетенции. Не в том смысле, что у Вас на это нет квалификации, а в том, что это пока не Ваша задача.
Чтобы решить задачу "слабого" взаимодействия, необходимо желание лидеров коллектива и воля руководства. Если в Вашем коллективе это есть - дерзайте, можно продумывать процесс. Только смотреть надо не на отдельный процесс определения трудозатрат, а на всю систему в целом, искать, что мешает адекватному взаимодействию:
- психология?
- открытая не в том месте форточка?
- неудобный интерфейс RMS?
- разные системы целей?

Спасибо за ответ!

На самом деле, в процессе написания всего этого поняла, что просто команда еще не привыкла к присутствию аналитика, как сервиса. (Воистину, женщине нужно сказать, чтобы подумать. =) ) Никакого отрицательного отношения нет, но и полного понимания как его использовать тоже нет. Просто надо потихоньку встраиваться. Тем более, я уверена на все 100%, что в данном случае я не лишнее звено.

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

Ощущение опускания требований в "черный ящик" присутствует.

Мое здоровье подвергалось гораздо более тяжелым испытаниям, когда ни руководитель, ни заказчик не были готовы обсуждать проблемы в процессах, если ты сейчас же не предложишь решение и не начнешь его внедрять собственноручно без усилий с их стороны. Тут люди готовы обсуждать, так что тут я почти в раю, и моему здоровью мало что угрожает. Но большое спасибо за беспокойство. =)

Введением нового поля задачу не решишь, но есть слабая надежда, что если дергать иногда за разные ниточки, вдруг какая-то сдвинет что-то в голове у руководителя. Хотя рассчитывать на это не стоит, конечно.

сообщение устарело

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