Як ми можемо реально планувати проекти, враховуючи питання підтримки?

У нас виникають проблеми на роботі: ми намагаємось запланувати роботу, щоб ми могли оцінити масштаби часу та отримати терміни.

Проблема полягає в тому, що складно спланувати проект, не знаючи, що все буде.

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

Проблема в 3 рази:

1. Коли ми плануємо проекти, шкали часу приймаються буквально. Якщо ми оцінюємо три тижні, термін встановлюється на три тижні, повідомляється клієнт, і немає місця для продовження.

2. Проміжна робота та такі засоби, що ми втрачаємо продуктивний час, працюючи над проектом.

3. Іноді клієнти не мають часу, який нам потрібно взяти, щоб виконати роботу, тому вони іноді приходять до нас і кажуть, що їм потрібен проект, зроблений до кінця місяця, навіть коли ми думаємо, що робота займе два місяці - не кажучи вже про те, що у нас вже є робота.

У нас є діаграма Ганта, яку ми намагаємося заповнити всіма своїми проектами, і ми заповнюємо графіки, але вони взагалі не порівнюються з діаграмою Ганта. Це важко сказати: "Ну, ми запланували 3 тижні для цього проекту, але ми втратили тиждень тут, тому термін повинен змінитись на тиждень назад".

Також не професійно дотримуватися пропущених термінів, про які ми повідомили клієнту.

Як інші люди справляються з таким типом ситуації? Як ви керуєте плануванням проектів? Скільки «зайвого» часу ви плануєте в проект для обліку непроектних робіт, що виникають під час проекту? Як ви вирішуєте проблеми підтримки, помилки та інше? Те, що ви не можете врахувати під час планування?

ОНОВЛЕННЯ

Багато хороших відповідей дякую.

Проблема полягає в тому, що складно спланувати проект, не знаючи все, що відбудеться.

Це сенс управління ризиками. Ви не можете все знати, тому ви плануєте виходячи з того, що знаєте, і визначаєте, які речі можуть мати найбільший вплив на ваш план і наскільки це можливо. Оцініть також потенційний вплив розкладу, сказавши, що якщо X трапиться, це спричинить ковзання розкладу на орієнтовну (ключове слово - орієнтовна) Y дні чи тижні.

Все добре і добре говорить про те, що проект займе 3 тижні,

Ніколи не давайте такої конкретної оцінки. Дайте діапазон або кількісно оцініть ймовірність потрапляння цієї оцінки. Наприклад, скажіть, що "цей проект займе 2-5 тижнів" або "85% шансів, що цей проект буде здійснено через 3 тижні, і 95% шансів, що він буде здійснений через 4 тижні".

Це також не є професійним для клієнта, щоб постійно говорити, що ми пропустили термін.

Правда. Однак ви змішуєте поняття "кошторис", "графік" та "термін". Ваша оцінка - це приблизна кількість часу, який знадобиться для виконання задачі чи проекту, та ймовірність його виконання. Кінцевий термін - дата, призначена замовником, на яку проект повинен бути виконаний, щоб додати вартість. Графік - це те, як ви використовуєте наявні ресурси для виконання терміну.

Бувають випадки, коли закінчити призначену роботу просто неможливо в термін, і всі оцінки та планування у світі не змінять значення.

Тож моє запитання ... як це роблять інші люди? Як ви керуєте плануванням проектів? Скільки "зайвого" часу ви плануєте в проект для обліку всього, що відбувається середнього часу?

Я рекомендую прочитати дві книги Стіва МакКоннелла: Оцінка програмного забезпечення: Демістифікація чорного мистецтва та швидкий розвиток: Приборкання диких програмних програм . Оцінка програмного забезпечення - це розробка ваших оцінок, представлення їх клієнтам, а також деякі аспекти переговорів та вирішення нереальних очікувань. Швидкий розвиток - це загальне управління проектами, яке стосується життєвих циклів розвитку, планування, розподілу ресурсів та способів найкращого розкладу та бюджетних проектів відповідно до ваших оцінок та термінів.

Я б запропонував розглянути деталі процесу розробки Scrum . Він охоплює таку діяльність по сторонній відслідковування за focus factorметрикою. В основному вам потрібно відпрацювати 2-3 спринти / ітерації, а потім виміряти фактор фокусу вашої команди (і для кожного члена це також буде корисно). Після цього ви зможете надати більш точні оцінки, що охоплюють щоденну активність.

Погляньте на цю статтю - "Фактор фокусування"

Якщо хтось із вас знайомий з розвитком Agile, ви, напевно, чули про фактор фокусування (або фактор продуктивності). Він використовується для планування, щоб допомогти визначити, скільки «реальних годин» вам над чим потрібно працювати. Це різниця між "реальною годиною" та "ідеальною годиною".

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

Дуже багато сучасних методик планування враховують це. Розкручуйте чинники на швидкість. На основі доказів планування також використовує швидкість з довірчим інтервалом для будь-якої заданої оцінки. Помодоро враховує перебої, коли ви вирішуєте, скільки "помподоросів" ви можете розраховувати на виконання у будь-який тиждень. Все це залежить від того, щоб відстежувати історичні вимірювання ваших перебоїв і якось їх враховувати у ваші оцінки. Рекомендую поглянути на них і розробити техніку, яка буде працювати для вашої команди.

Гарна порада навколо.

Ще одна річ, яка може бути корисною для вирішення питань підтримки, - це присвятити людям підтримку на постійній основі.

Наприклад, якщо у вас є 5 розробників, призначте один на кожен день тижня. Коли цей день настає, призначений розробник працює на цей день ТІЛЬКИ на підтримку. Наступного дня інший розробник бере на себе підтримку. Таким чином, кожен має шанс залишитися у своєму "потоці", кожен отримує смак від собак.

Те, як Ви РЕЧИ вирішили розділити звичайну роботу з підтримки, насправді не має значення (круговий робочий день тижня - лише приклад). Важливо лише обмежити час підтримки на фіксовані регулярні інтервали. Це робить час розробки більш передбачуваним, оскільки ви не можете "всі кинути все", щоб вирішити проблеми підтримки.

Це вміння, яке дійсно приходить з досвідом, і часто людей запитують, перш ніж вони зможуть точно оцінити таке. Я завжди працював у досить згуртованій групі з неофіційним стилем, але ми розробили кілька правил, які, здається, добре тримаються.

По-перше, жодне завдання не займає менше тижня. Завжди оцінюйте за тижні, навіть якщо завдання лише здається, що на виконання знадобиться кілька днів. Буде якась причина, що це не буде зроблено до кінця тижня.

По-друге, докладіть максимум зусиль, щоб оцінити кількість часу, яке займе завдання, включаючи перебої, проблеми підтримки клієнтів, отримання його через тестування тощо. Тепер подвойте це число. Це ваша оцінка (в тижнях).

По-третє, переконайтеся, що ваш менеджер уже не додає ваших оцінок. У нашій команді менеджер скаржився на наші оцінки. Виявилося, він вже збирається помножити його на 2.1 (його емпірично отримана оцінка прокладки), і ми вже подвоїли його, перш ніж сказати йому.

Це не фантастичний інструмент і може бути не ідеальним методом, але він працює напрочуд добре.

Люди, які роблять оцінку, повинні розуміти, що жодна команда ніколи не стовідсотково працює над проектом. У вас є лікарняні відпустки, відпустка, обов'язок присяжних, відпустка за невдачу, необхідні зустрічі з персоналом (це вигідний час!), Зустрічі команди, які не пов'язані з проектом, неминуча затримка, перерви у ванній кімнаті, підтримка роботи з предметами, які вже є у виробництві, робота з електронними листами, , налаштування нового комп’ютера після того, як помер старий, відповідав на запитання щодо майбутньої роботи та робив кошториси на цю роботу, наставництво юніорів та ін., які потрібно враховувати. Оцінювач не має відповідальності приймати більше 6 з 8 годин доступний на день. Це гарантія, що термін не може бути дотриманий. Якщо ви гарантуєте, що термін не може бути дотриманий, ви гарантуєте нещасного замовника.

Ви абсолютно вірні - складно спланувати проект, не знаючи, що все буде. Але дуже важливо слідкувати за речами, які є нормою, а також завданнями, які ваш передбачив. Ось де грає управління розкладом . Я використовував управління проектами Microsoft (стандартна версія), для яких також входять функції, що входять до програмного забезпечення для планування проекту.

Ви можете відвідати http://www.microsoft.com/project/en/us/schedule-management.aspx для отримання додаткової інформації.

Здається, що у ваших команд проекту багато прихованих зусиль, завдяки яким ви втрачаєте фокус і швидкість. Справді відокремити завдання для вирішення може бути корисним

..Підтримка підтримки та помилки та інше?

конкретній групі людей, щоб інші члени команди могли зосередитись на нових завданнях розвитку. Завдяки цьому їх загальне виробництво може дещо впасти, але якість покращиться, оскільки відволікається менше. Це натомість зменшить кількість помилок, отже, непередбачена робота, яка робить це дорогою до ваших проектів.

Що стосується планувальної частини, я повністю згоден з відповіддю Томаса Оуенса.