Тим

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

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

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

Пройдут года, релизы, методологии и вы все равно вернетесь к Trello или его аналогам (Pivotal tracker). Гант - от лукавого. Гоните прочь.

Предпочитаю не приступать к исполнению проекта пока не согласованы критерии приемки и форма поставки. Иногда оценка проекта и деньги меняются радикально когда услышишь критерии приемки и форму поставки. Одни сейлзы подписали контракт где заказчик прописал "Не более 2х минорных багов в продакшене" и компания встряла на треть стоимости проекта в попытке исправить всё.

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

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

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

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

Записывать фичи нужно сразу в трекер заказчика, какой нибудь Trello, Pivotal. Это нужно что бы всегда перед глазами видеть юз кейсы, задавать им приоритет.

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

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

Microsoft Word + Onedrive/GoogleDrive/Dropbox. Любой документ пишется в режиме рецензирования, что бы можно было увидеть любые правки. Разбиваем по файлам, модулям, и пишем. Потом объединяем. Никакого мазохизма.

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

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

Те кто ходят на 9:30 и уходят в 17:30 и обедают 1.5 часа получают в соотв. % зарплату в конце месяца. Колво рабочих дней * 8 - сумма по трекингу в офисе или удаленке для тех кто злостный нарушитель.

Todoist.

Смотря что для вас управление проектами. Чаще всего под "ПМ" видят иллюзию управления. Процесс идет сам по себе, по инцерции, и люди думают, что чем то управляют. Управление такая же тонкая наука как психология. Можно управлять результатом тысячей способов. Уже зависит персонально от человека. Кто то сделает сам, кто то делегирует, кто то наймет, кто то заставит, кто то убедит не делать, кто то отложит и т.п.

Зависит от ролей и количества исполнителей.

В связи с обилем .net проектов - Team Foundation Server. Туда Requirement, по ним менеджерские Task, к ним Test Case, и Change Set. Разработчики в праве бить на сабтаски в любом кол-ве. Занимается этим тимлид. Если ПМу утвердили требования и поставили как таск, то запланировал, передал в работу тимлиду, дальше тот уже отвечает за исполнение. По сути конвеер.

Можно поручить эту работу тестировщику ;)

В своё время начал с PM BOK и Гибкие методологии о Agile и фреймворках Scrum и т.п. Этого было достаточно. Спустя год уже полез в аналитику, тестирование, разработку, continuous integration, continuous delivery. По началу переживал и читал тоннами разный фуфел, но потом осознал, что он больше мешает чем помогает. Зная в голове тонну чьих то примеров я руководствовал ими а не думал головой. Т.к. мне это мешало, я перестал читать книги которые излагают чьей то опыт или историю, и больше сфокусировался на методичках, теории, процессах.

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

Вы уверены, что люди которые поставлены отвечать вам на вопросы это компетентные люди?!

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

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

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

В этом и суть TM. У вас нет четкого понимания трудозатрат по проекту. Соответственно, вы не можете дать фиксированную сумму и подписатся под ней. Оплата производится по договору по факту трудозатрат. А как вы будете их согласовывать - до исполнения, после это уже тонкости. Чаще всего люди понимают ТМ под "будем пилить пока пилится, а в конце месяца выставим счет". На деле, ТМ это тот же Scrum. Вы оценили на итерацию себе работ, клиент согласился и вы делаете. Сделали, приняли, инвойс отправили и пошли дальше. И так пока проект не закончится (у клиента кончатся деньги).