Управління проектами: функції (етапи, завдання та цикли зворотного зв’язку)
Управління проектами є багатогранним, і те, як ми всі збираємося розбивати різні аспекти наших проектів, швидше за все, залежить від того, як це робиться на нашому місці роботи, як хоче це зробити клієнт або як ми вирішимо зробити це самостійно.
У цьому дописі, коли йдеться про роботу конкретно над будь-яким проектом, я конкретно говорю про те, як ми беремо вимоги проекту та розбиваємо їх на більш керовані частини та результати для людей, для яких ми працюємо. І, роблячи це, я вважаю, що важливо, щоб вони були в курсі та могли бачити прогрес на відповідних контрольних точках, щоб отримати відгук.
Незважаючи на зміни в різних аспектах мого бізнесу, коли я дізнався більше про те, що працює, а що ні, одна річ залишилася незмінною в тому, як я керуюся аспектами, пов’язаними з розробкою, функцій проекту.
Особливості: віхи, завдання та цикли зворотного зв’язку
Щоразу, коли ми починаємо говорити про такі речі, легко перейти до жаргону нашої галузі. І хоча я не думаю, що в «віхах» і «завданнях» є щось надто технічне, «цикл зворотного зв’язку» — це дещо інше. Але я зупинюся на цьому зараз.
Маючи набір вимог, незалежно від того, наскільки він великий, я негайно починаю переглядати документ – незалежно від того, як ми його отримуємо – і думати про всі частини, які знадобляться для досягнення певної функції. Незалежно від мов, інструментів, фреймворків або програм, з якими ви вирішите працювати, я вважаю, що глибоке знайомство з тим, з чим ви працюєте, має велике значення.
Розбиття функцій на віхи, а віхи – на завдання.
Потім я візьму певну функцію, розділю її на різні завдання, і я повторю це для кожної функції. Зазвичай я намагаюся зробити кожну функцію важливою віхою, але деякі функції більші, ніж інші, і їх потрібно розділити на кілька частин. З цією метою проект зазвичай розбивається таким чином:
- Функція стає віхою (або віхами),
- Віха – це група завдань,
- І завдання відповідає функціональній одиниці (проте, не обов’язково функції в загальній кодовій базі).
Потім ви можете повернутися до цього, щоб побачити, як це відповідає випуску:
- Завдання зазвичай відповідає коміту,
- Набір комітів відповідає тегу,
- Тег відповідає об’єднанню функції,
- Функція відповідає вісі.
На цьому етапі віха має бути готова до розгортання в середовищі проміжки часу, щоб клієнт міг оцінити її з тим, що він/вона має на увазі (і у вимогах), щоб переконатися, що вона виконана.
Ось тут і вступає в дію цикл зворотного зв’язку. Але спочатку я визначу цикл зворотного зв’язку просто так:
Обговорення певної функції, яка визначає, чи її завершено, чи вимагає додаткової роботи.
Хоча інші входять у набагато більші деталі. Але я відволікся.
Тож, чекаючи, поки клієнт зв’яжеться щодо останнього етапу, я або ми зазвичай переходимо до наступного етапу. Ось чому важливо мати послідовний спосіб роботи з етапами, завданнями та зворотним зв’язком (разом із гілками в середовищах керування джерелами та проміжних середовищах).
Почніть працювати над новою функцією після того, як передасте останню для керування джерелами та постановки.
Якщо відгук надходить від клієнта, ми, як правило, беремо відгук, визначаємо, що можна робити, а що не можна, а потім об’єднуємо це в новий етап. Іноді віху додають до кінця; в інших випадках він додається як наступний пункт пріоритету. Все залежить від характеру роботи, відгуків і того, наскільки це вписується в рамки проекту.
Більше ніж функції
Загалом, це лише високорівневе уявлення про те, як я намагаюся керувати аспектами розробки функцій. Але перегляд основних етапів, завдань і циклів зворотного зв’язку – це те, що важливо, тому що коли ця система налагоджена, вона створює передбачуваний спосіб, за яким ви та ваша команда можете впроваджувати рішення.
Крім того, це забезпечує передбачуваність результатів і спілкування з клієнтом, і це особливо добре працює з постійними клієнтами, оскільки вони знають, чого очікувати.
Як і багато інших речей, про які я пишу, я не намагаюся представити це як євангеліє, але я вважаю, що наявність певної системи є важливою. Я не думаю, що будь-коли варто відкривати проект, якщо це не лише особистий, побічний проект.
Тож незалежно від підходу, який ви виберете, принаймні майте підхід.