Денис И.

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

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

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

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

вы сами то понимаете, какой толк, какая практическая польза от максимально детализированных отчетов?
почему вас не устраивает скажем 10% погрешность в этих значениях?

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

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

Для начала - читать методологию. Рекоендую RUP 6 (именно 6-й, а не 7-й) в зубы, и вперед.
или OpenUP ( ru.wikipedia.org/wiki/OpenUP, www.ibm.com/developerworks/ru/library/kroll ).

Хотелось бы найти:
— набор этапов разработки;
— набор категорий задач;
— шаблон/пример.

вар.1 Покупайте Rational Method Composer (RMC).
Там редактор "сайта процессов" с примерами и шаблонами и описанием всех процедур, документов, шаблонов и всего прочего что вам вообще может понадобиться. Идеология применения на практике звучит так: из этого безобразия - надергиваете то, что вам надо _на_этом_ проекте - и получаете описание методики и процеcсов на вашем проекте. С шаблонами документов, инструкциями и описаниями процедур.

Там и RUP, и Agile-RUP облегченный есть, и даже классический "водопад" с рекомендациями описан. Сейчас может что и для мобильных приложений тоже впилили. Я года 2 как не смотрю что у них творится, но надеюсь, IBM не сильно испохабил творение компании Rational.

Стоит в принуипе "нехреновых денег", но месяц полнофункционального прогона пр регистрации был бесплатно. IBM щедра как никогда. <_<
www.ibm.com/developerworks/downloads/r/rup
www.interface.ru/home.asp?artId=1524
www.itshop.ru/Dokumentirovanie-i-avtomatizatsiya-p...

вар.2 Или щупайте его бесплатный эклипсовсий прототип Eclipse Process Framwork . Но там многих шаблонов нет. Зато есть куча своих, от сообщества. Включая пригоршню Agile-процессов, описания XP и тому подобного безобразия.
www.eclipse.org/epf
www.ibm.com/developerworks/rational/library/05/101...

PS Вопрос методологии, принципов. Именно они позволяют выстроить набор всего-всего в нечто осмысленное. Бойтесь в EMC рисовать что своё без понимания хотя бы основ RUP (настоятельно рекомендую именно 6-й, потому что в 7-м введены принципы бизнес-ориентирвоанной разработки, которые технически - совершенно неосмыслены).
НО! С другой стороны - только EMC (и только он) может сгенериовать вам самое полное описание всех методов и процедур RUP (включая философию и принципы). В общем - сделаете сайт с полным описанием RUP - глядишь и поймете что. А начать можно с википедии ( ru.wikipedia.org/wiki/Rational_Unified_Process ) или вводных статей по OpenUP ( ru.wikipedia.org/wiki/OpenUP, www.ibm.com/developerworks/ru/library/kroll ).

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

PPS и забудьте про ТЗ ;)
ТЗ - статический артефакт из темного каскадно-водопадного прошлого.
Да здравствует итеративное настоящее, дисциплина "управление требованиями" и UseCases ! (трижды "ура") )))