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

Это можете определить только Вы сами Тем более у Вас  все фиксируется.
Померьте время, затрачиваемое на первоначальные требования, потом - время на изменения.
Померив на одном проекте, сможете в % выражении применять на аналогичные.
Но не прекращайте измерять, т.к. все проекты разные и исходные данные разные. Чем больше статистики, тем точнее прогноз.

да, согласен абсолютно, но как быть в таком случае: в конце месяца составляется план задач  на следующий исходя из загруженности. Так как ТЗ написано, согласовано и передано в ИТ делать по нему "вроде как" ничего и не надо и следовательно можно планировать новые, другие задачи, НО на деле вылазят различные недочеты модели, доп согласования и пр. В итоге, к концу месяца имеем: реализованное ТЗ (отделом ИТ) и не сделанные задачи (аналитиком) зп аналитика за месяц медленно стремится к нулю (запланированные задачи не сделаны), хотя все как всегда при деле....

НО на деле вылазят различные недочеты модели, доп согласования и пр.

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

Так как ТЗ написано, согласовано и передано в ИТ делать по нему "вроде как" ничего и не надо и следовательно можно планировать новые, другие задачи, НО на деле вылазят различные недочеты модели, доп согласования и пр. В итоге, к концу месяца имеем: реализованное ТЗ (отделом ИТ) и не сделанные задачи (аналитиком) зп аналитика за месяц медленно стремится к нулю (запланированные задачи не сделаны), хотя все как всегда при деле....

Это неверный подход, что работа аналитика заканчивается в момент подписания ТЗ.
Она заканчивается в момент сдачи проекта заказчику (т.е. когда заказчик все принял и расплатился).

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

Количественно можно оценить затраты, оценив риски изменения требований. Если они высоки, увеличивайте затраты на анализ после подписания ТЗ (в пределе я бы взяла 50%, но бывает и 100-200 - просто такие проекты как правило долго не живут). Корректировать можно в зависимости от квалификации аналитика. Если риски невелики, то и 10% может хватить. Если вы меняете аналитика после подписания ТЗ или меняются заинтересованные лица у заказчика, увеличивайте.

да, согласен абсолютно, но как быть в таком случае: в конце месяца составляется план задач  на следующий исходя из загруженности. Так как ТЗ написано, согласовано и передано в ИТ делать по нему "вроде как" ничего и не надо и следовательно можно планировать новые, другие задачи, НО на деле вылазят различные недочеты модели, доп согласования и пр. В итоге, к концу месяца имеем: реализованное ТЗ (отделом ИТ) и не сделанные задачи (аналитиком) зп аналитика за месяц медленно стремится к нулю (запланированные задачи не сделаны), хотя все как всегда при деле....

1. Аналитик не занимается управлением проектом, как таковым. Это задача PM-а.
2. Если бы вы работали по итерационной модели жизненного цикла, у вас бы такая проблема скорее всего  и не возникла. Т.к. такая модель подразумевает вовлеченность работы аналитика на всех фазах проекта, другой вопрос что загруженность для разных фаз будет разная. Какая именно - вопрос анализа рисков проекта + немного здравого смысла. Но факт остается фактом, если аналитик вовлечен в проект, при ресурсном планировании следует выделять время на участие аналитика в проекте.
3. Топик озаглавлен как "управление изменениями", но исходя из ваших вопросов, можно сделать вывод, что вы ими не управляете никак. Т.е. делаете изначально неверное предположение о том, что после подписания ТЗ изменений НЕ БУДЕТ. Хотя как правило, они есть. Любые изменения можно проводить как запросы на изменения и по ним назначать аналитика, который выдаст масштаба бедствия. Тем самым вы вполне можете утилизировать аналитика и зафиксировать его время работы.

tо ida,

фактически работа аналитика после передачи ТЗ не заканчивается, а начинаются не запланированные согласования, подчистка косяков и т.д. до момента тестирования, дальше по плану опять вступает аналитик. Задача состоит в том, что нужно оценить время, которое будет затрачивать аналитик на подвинчивание согласованного ТЗ в процессе реализации. 10% это от чего?? от времени, которое заложено на реализацию ТЗ? те если на реализацию ТЗ отдел ИТ определил срок 30 рабочих дней, то 3 дня будет задействован аналитик?

to Юрий Булуй,
не будьте столь категоричны, управление требованиями оно происходит, только вот в плане работ никак не отражается . большинство запросов по изменениям необходимо решать в текущем режиме, для того чтоб не затягивать процесс разработки.

хотелось бы услышать методы как определить аналитику время, которое он будет затрачивать в процессе реализации ТЗ?

хотелось бы услышать методы как определить аналитику время, которое он будет затрачивать в процессе реализации ТЗ?

А при чем тут аналитик? ТЗ реализует разработчик - проектировщик и/или программист

фактически работа аналитика после передачи ТЗ не заканчивается, а начинаются не запланированные согласования, подчистка косяков и т.д. до момента тестирования

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

Задача состоит в том, что нужно оценить время, которое будет затрачивать аналитик на подвинчивание согласованного ТЗ в процессе реализации. 10% это от чего?? от времени, которое заложено на реализацию ТЗ? те если на реализацию ТЗ отдел ИТ определил срок 30 рабочих дней, то 3 дня будет задействован аналитик?

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

Ситуация АБСОЛЮТНО идентична разработке нового и багфиксингу.

"ПО разработано, передано в тестирование, разработчик передан на другой проект.
В процессе тестирования выясняется, что нужны разные мелкие правки кода,
разработчик отрывается, в конце квартала плановые задачи не сделаны, бла-бла-бла".

Если тестирование идёт 30 дней, сколько дней надо закладывать разработчику на багфиксинг?

не совсем ясно,- насколько можно нагружать аналитика задачами кроме данного проекта, если да, то в каком отношении и почему?

Ааааааа.... спросить его не пробовали? Почему вдруг МЫ ТУТ должны это знать лучше, чем ОН ТАМ у вас?

приказа по проекту нет. Поэтому команда определена условно. Команда: заказчик-постановщик задачи(контроль по плану проекта, решение спорных вопросов),технолог(планирование проекта, составление и согласование ТЗ, контроль реализации, тестирование, отчетность перед заказчиком), программист (реализация ТЗ, отчетность перед технологом) ну и консультанты по предметным областям (взаимодействуют с технологом).
 

Ааааааа.... спросить его не пробовали? Почему вдруг МЫ ТУТ должны это знать лучше, чем ОН ТАМ у вас?

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

как определить(запланировать) время затрачиваемое аналитиком (и куратором в одном лице) на управление проектом после того, как согласованное ТЗ уже отправлено в отдел ИТ для реализации, определены основные вехи и даты и форма отчетности ИТ.
На данный момент не совсем ясно,- насколько можно нагружать аналитика задачами кроме данного проекта, если да, то в каком отношении и почему? заранее спасибо

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

Мы же можем дать вам просто набор каких-то рекомендаций, которые можно учесть при планировании. Я обычно при выдаче оценок руководствуюсь следующим:
- стараюсь перечислить все предположения/ограничения, на основе которых мои оценки строятся. Это на самом деле очень существенный момент. По этому поводу есть даже цитата - "Мы совсем неплохо оцениваем. Нам просто плохо удается перечислять все допущения, лежащие в основе наших оценок."
- если сроки не "спускают сверху", стараюсь давать "комфортные для себя" оценки. То есть чтобы и руководителя не обманывать явно завышенными сроками и самому по 12 часов не впахивать. При этом при выдаче оценок стараюсь максимально декомпозировать задачу на подзадачи длительностью 4-8 часов, каждую из которых способен обосновать;
- принимаю на себя часть рисков по неверным оценкам. Грубо говоря, в случае если я дал заниженную оценку - то готов компенсировать ее за счет личного времени.

В вашем случае, если есть объективная возможность (и необходимость?) перезаложиться, то лучше воспользуйтесь ей. Если реально вам потребуется меньше времени - потратите ее на вторую задачу и опередите план по ней. Но обязательно фиксируйте свои реальные трудозатраты, чтобы сделать соответствующие выводы. Это и называется опытом.

На и на крайняк - в сутках таки 24 часа, а не 8. И вы являетесь хозяином своего времени.

Может быть Вы что то подчерпнёте для себя полезного из рассказа Макса Дорофеева "Предсказание будущего" http://cartmendum.livejournal.com/46577.html?