Управление проектами: функции (этапы, задачи и циклы обратной связи)

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

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

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

Особенности: вехи, задачи и циклы обратной связи

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

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

Разбивка функций на вехи, а вех на задачи.

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

• Функция становится вехой (или вехами),
• Веха — это группа задач,
• И задача соответствует функциональной единице (хотя и не обязательно функции в общей кодовой базе).

Затем вы можете вернуться к этому, чтобы увидеть, как это соответствует выпуску:

• Задача обычно соответствует фиксации,
• Набор коммитов соответствует тегу,
• Тег соответствует слиянию функций,
• Функция соответствует вехе.

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

Здесь вступает в действие петля обратной связи. Но сначала я определяю цикл обратной связи просто как:

Обсуждение данной функции, которое определяет, закончена ли она или требует дополнительной работы.

Хотя другие вникают в гораздо более подробную информацию. Я отвлекся, однако.

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

Начните работу над новой функцией после фиксации последней в системе контроля версий и промежуточной стадии.

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

Больше, чем функции

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

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

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

Так что независимо от того, какой подход вы выберете, по крайней мере, имейте подход.