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

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

Nobody faults but mine... (LZ)

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

Основная задача это КАК руководителю добится завершения работы в срок и с должным качеством ?

Вот вы составите план проекта, пускай даже в том же MS Project. И сроки в нём запишете те, что сами разработчики вам назвали. Каждый получит свой кусок работы и...??? Надеюсь вы не думаете, что вам останется только собрать готовую работу например в конце недели?:) Если вы имеете такой коллектив разработчиков, то я вам искренне завидую (как думаю и подавляющее большинство руководителей, особенно те кто не имеет специального технического образования и вынужден выслушивать иногда полную чушь в качестве оправданий невыполненой в срок работы). Практика показывает, что процент сотрудников с чувством ответственности за выполняемую ими работу, которое позволяет им сделать вовремя и качественно - к сожалению крайне мал, хотя бы по той причине, что к этому качеству, человек к тому же должен уметь планировать своё рабочее время .

Давайте даже упростим задачу: у вас есть сотрудники и все поголовно специалисты (стаж 3-4 года в среднем и не просто кодеры, но вполне думающий люди) и ответственные (не гоняют в кваку в ущерб работе). Практически идеальный вариант, который в жизни встретить крайне сложно.
В конце дня они присылают вам данные по выполненым работам за день, что бы вы могли скорректировать свой план (в MS project)... Среда - середина недели. Вы как обычно анализируя отчёты от 10 человек обнаруживаете, что дневное задание не было выполнено тремя:

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

Второй: Из самых лучших побуждений, сотрудник при решении поставленной задачи, старался сделать решение как можно более универсальным. Похвально, но только вот сроки на это не были расчитаны и вместо 2 часов на решение части его дневной задачи, он потратил все 8 отведённые на всю задачу...Результат - вероятность того, что работающий релиз вы в пятницу не увидите становится вполне ощутимой...

Третий: При анализе задачи, подумал что тут можно применить новую технологию по работе с XML, которая должна по идее упростить с ним работу...Занимался 6 часов изучением этой технологии и её апробацией...Результат - вы скорее всего не увидите свой релиз в пятницу либо вообще, либо с тем функционалом что у вас был запланирован...

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

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

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

Dogen DogenПод винду, если сильно поискать, наверное аналог найдется :)

...и даже не один

Очень ценный совет...
Теперь мы знаем, что есть оказывается "очень полезный ресурс" - google , т.е. на самом деле есть Internet, в котором ну очень много всего есть и если кому надо, то пусть там пороется и чего то наверняка найдёт...
Если верить счётчику, то данную тему просматривала масса народу, ну почему не зашёл каждый и не оставил такой ценный совет - поищите в инете ?
Давайте всё таки уважать друг друга, всё таки раз человек спрашивает конкретно, то и отвечать нужно конкретно, а не давать такие "советы"...

Я например 3 дня (часов по 10) убил на поиск с помощью того же google чего то похожего... Среди того, что хоть близко подходит по описанию:
не один десяток отсеялся при просмотре в инете, скачал и "потрогал ручками" больше десятка программ... Основной упор в каждой, это как правило функционал посвящённый управлению проектом, т.е. некие аналоги MS Project. В некоторых есть функции по назначению задач. В считаных единицах, есть возможность выбора текущей задачи над которой работает исполнитель, но они все расчитаны как правило на управления задачами в рамках неких бизнес-процессов, и довольно специфичны - для разработки ПО мало пригодны. Хотя конечно, наверное можно их как то адаптировать под процесс разработки, но это будет "притянуто за уши", а хотелось бы видеть всё таки нормальное решение данного вопроса.
Была правда одна интересная вещь, заточенная конкретно под процесс разработки в стиле XP, но она ещё в стадии разработки. И там кстати, можно оперировать терминами именно процесса разработки, такими как итерация, что согласитесь даже на этапе планирования отнюдь не лишне...