Тим

Redmine. Проверен, всем нравится

Элия Голдратт - Цель1,2,3
Мой выбор. Отмечу, что это не учебник как запуститься или сценарий как делать продукты.
Это философская история, очень глубокая. Которую хорошо читать после базы и теории по менеджменту, управлению предприятиями и т.д.

Часто перечитываю и осознаю насколько она глубокая. Главное осознать аналогии.

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

Почта обязательно должна быть корпоративная. Что бы в случае разбирательств, вы имели доступ к перепискам и логам. Тоже самое звонки, не по какой то мобилке на корп счету, а через SIP'ы. Благо можно и телефоны поставить и софтинку. А переговоры записывать и хранить в архивах на пару месяцев. Что бы, опять таки, в случае разборок или "контрольной выборки" можно было проверить.

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

Коэффициенты и метрики по трудозатратам в неделю-месяц.
Ваш разработчик работает ~160 часов в месяц. Если вы ему вписали 1500$, то 1 час его работы обходится вам в 9.3$. Насколько я знаю, что бы ваш бизнес был рентабельным то вы должны зарабатывать с работника на 60-80% больше, что бы оплатить счета, офисы, обеды, и прочее. Выходит, что в вашем случае, условно говоря, он должен приносить вам 30$ в час, что бы окупить свою зарплату. В противном случае он превращается в "содержанца".

Надеюсь логика понятна.

Делаю это в MS Project. А redmine(в моем случае Jira) служит лишь для трекинга времени и багтрекинга. В проджекте это можно делать либо прописывая приоритеты задач в единицах (1-500) либо ручное планирование при помощи последователей-предшественников.

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

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

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

критерии эффективности ИТ-проекта для того, чтобы выявить факторы, влияющие на его эффективность.

Эффективность для чьей стороны? Я так понимаю, для стороны заказчика?!
Например, наш заказчик очень хотел что бы его приложение попало в топ аппстора. И что бы собрав аналитику за N месяцев в ней не было крешей больше чем в 2% случаев.

Как выше уже сказали, метрики должны быть от заказчика.

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

Jira, Redmine

Прототип это MVP (Minimum valuable product). Что бы заказчик оценил концепцию конечного продукта раньше, чем пройдут месяцы-года разработки и он поймет надо ему это или нет. Чаще всего прототипы пишутся на простейших фреймворках которые позволят показать сценарии и процессы, а затем утвердив приступают к написанию на конкретном фреймворке\языке\платформе с нуля.

То о чем пишите вы, это модель. Старшая сестра Mockup'a и Wirefram'a.
По ней можно делать простые проекты, но без ТЗ будете косячить. Как бы детально вы эту модель не нарисовали.

Всем надоело писать ТЗ, но надо.
Модель должна идти параллельно с ТЗ, как визуализация ТЗ.
Она позволяет упрощать донесение задач, или стейкхолдеров\фич проекта как то разработчиков так и до заказчиков у которых проблемы с чтением документов на большое количество страниц.