Jak możemy realistycznie planować projekty, uwzględniając kwestie wsparcia?

Mamy problem w pracy: staramy się zaplanować pracę, abyśmy mogli ocenić skale czasowe i uzyskać terminy.

Problem polega na tym, że trudno jest zaplanować projekt, nie wiedząc o wszystkim, co się wydarzy.

Na przykład, teraz zaplanowaliśmy wszystkie nasze projekty do początku grudnia, jednak w tym czasie będziemy mieli różne spotkania wewnętrzne i zewnętrzne, telekonferencje i dodatkowe prace. Dobrze jest powiedzieć, że projekt potrwa trzy tygodnie, ale jeśli w tym czasie będzie przerwa na tydzień, data zakończenia zostanie przesunięta o tydzień.

Problem jest 3-krotny:

1. Kiedy planujemy projekty, ramy czasowe są brane dosłownie. Jeśli oszacujemy trzy tygodnie, termin zostanie ustalony na trzy tygodnie, klient zostanie poinformowany i nie ma miejsca na przedłużenie.

2. Praca tymczasowa i takie środki oznaczają, że tracimy produktywny czas pracując nad projektem.

3. Czasami klienci nie mają czasu, który musimy poświęcić na wykonanie pracy, więc czasami przychodzą do nas i mówią, że potrzebują projektu do końca miesiąca, nawet jeśli uważamy, że praca potrwa dwa miesiące - nie wspominając już, że mamy już pracę do wykonania.

Mamy wykres Gantta, który staramy się wypełnić wszystkimi naszymi projektami i wypełniamy karty czasu pracy, ale w ogóle nie są one porównywane z wykresem Gantta. Utrudnia to powiedzenie „Cóż, zaplanowaliśmy 3 tygodnie na ten projekt, ale straciliśmy tutaj tydzień, więc termin musi się cofnąć o tydzień”.

Przestrzeganie terminów, które przekazaliśmy klientowi, również nie jest profesjonalne.

Jak inni ludzie radzą sobie z tego rodzaju sytuacją? Jak zarządzasz planowaniem projektów? Ile „dodatkowego” czasu planujesz w projekcie, aby uwzględnić pracę niezwiązaną z projektem, która występuje podczas projektu? Jak radzisz sobie z problemami pomocy technicznej, błędami i innymi problemami? Czego nie możesz uwzględnić podczas planowania?

AKTUALIZACJA

Dziękuję za wiele dobrych odpowiedzi.

Problem polega jednak na tym, że trudno jest zaplanować projekt, nie wiedząc o wszystkim, co się wydarzy.

To jest punkt zarządzania ryzykiem. Nie możesz wiedzieć wszystkiego, więc planujesz na podstawie tego, co wiesz i identyfikujesz, co może mieć największy wpływ na twój plan i jakie jest prawdopodobieństwo, że się to wydarzy. Oceń również potencjalny wpływ harmonogramu, mówiąc, że jeśli nastąpi X, spowoduje to przesunięcie harmonogramu o szacunkowe (słowo kluczowe - szacowane) dni lub tygodnie.

Dobrze, że projekt potrwa 3 tygodnie,

Nigdy nie podawaj takiej konkretnej oceny. Podaj zakres lub oszacuj prawdopodobieństwo trafienia tego oszacowania. Na przykład powiedz „ten projekt zajmie 2–5 tygodni” lub „istnieje 85% szans, że ten projekt zostanie ukończony za 3 tygodnie, a 95% szans, że zostanie zrealizowany za 4 tygodnie”.

Klient nie jest również profesjonalistą, gdy mówi, że przekroczyliśmy termin.

Prawdziwe. Zmieszacie jednak pojęcia „oszacowania”, „harmonogramu” i „terminu”. Twoje oszacowanie jest przybliżonym okresem, w jakim zajmie ukończenie danego zadania lub projektu, oraz prawdopodobieństwem jego spełnienia. Ostatecznym terminem jest narzucony przez klienta termin, w którym projekt musi zostać wykonany w celu zwiększenia wartości. Harmonogram przedstawia sposób wykorzystania dostępnych zasobów w celu dotrzymania terminu.

Są chwile, kiedy po prostu nie można zakończyć przydzielonej pracy w terminie, a wszystkie szacunki i harmonogramowanie na świecie nie zrobi różnicy.

Więc moje pytanie ... jak inni to robią? Jak zarządzasz planowaniem projektów? Ile „dodatkowego” czasu planujesz w projekcie, aby uwzględnić wszystko, co dzieje się w międzyczasie?

Polecam przeczytać dwie książki Steve McConnell: Ocena oprogramowania: Demystifying the Black Art i Szybki rozwój: Taming Wild Software Schedules . Szacowanie oprogramowania polega na przedstawianiu szacunków, przedstawianiu ich klientom oraz niektórych aspektom negocjacji i radzeniu sobie z nierealistycznymi oczekiwaniami. Rapid Development to ogólne zarządzanie projektami, zajmujące się cyklami rozwojowymi, planowaniem, alokacją zasobów oraz najlepszym sposobem planowania i budżetowania projektów w celu dotrzymania szacunków i terminów.

Proponuję zagłębić się w szczegóły procesu rozwoju Scrum . Obejmuje takie działania związane z bocznym śledzeniem według focus factormetryki. Zasadniczo musisz przepracować 2-3 sprinty / iteracje, a następnie zmierzyć współczynnik skupienia swojego zespołu (i dla każdego członka byłby również pomocny). Po tym będziesz w stanie podać dokładniejsze szacunki, które obejmują codzienną aktywność.

Spójrz na ten artykuł - „Fokus”

Jeśli ktoś z was zna programowanie zwinne, prawdopodobnie słyszał o współczynniku skupienia (lub współczynniku produktywności). Służy do planowania, aby określić, ile „godzin rzeczywistych” trzeba nad czymś popracować. To różnica między „godzinami rzeczywistymi” a „godzinami idealnymi”.

Przerwy polegają na tym, że dla poszczególnych osób lub zespołów zdarzają się one z niewielkim prawdopodobieństwem. Na przykład masz mniej więcej taką samą liczbę spotkań co tydzień lub mniej więcej tyle samo godzin spędzonych na pilnych naprawach błędów co miesiąc lub tyle samo czasu poświęconego na odpowiadanie na pytania dla osób, które wpadają do twojego biurka, zwłaszcza gdy uśredniasz ponad długi okres czasu.

Uwzględnia to wiele nowoczesnych technik planowania. Scrum rozkłada to na prędkość. Planowanie oparte na dowodach wykorzystuje również prędkość z przedziałem ufności dla każdego oszacowania. Pomodoro bierze pod uwagę przerwy, kiedy decydujesz, ile „pomodorosów” możesz liczyć na ukończenie w danym tygodniu. Wszystko to zależy od śledzenia historycznych pomiarów twoich zakłóceń i jakoś uwzględnienia ich w twoich szacunkach. Polecam przyjrzeć się im wszystkim i opracować technikę, która będzie działać dla Twojego zespołu.

Dobra rada dookoła.

Inną rzeczą, która może być pomocna w rozwiązywaniu problemów związanych z pomocą techniczną, jest poświęcenie ludzi na wsparcie na podstawie stałej procedury „round-robin”.

Na przykład, jeśli masz 5 programistów, przydziel jeden do każdego dnia tygodnia. Kiedy ten dzień nadejdzie, przydzielony programista działa na ten dzień TYLKO na wsparcie. Następnego dnia inny programista przejmuje wsparcie. W ten sposób każdy ma szansę pozostać w swoim „przepływie”, każdy może skosztować jedzenia dla psów.

Sposób, w jaki faktycznie zdecydujesz się podzielić regularną pracę wsparcia, nie ma tak naprawdę znaczenia (robin w dni tygodnia jest tylko przykładem). Istotne jest ograniczenie czasu wsparcia do stałych regularnych odstępów czasu. Dzięki temu czas programowania jest bardziej przewidywalny dzięki kompromisowi polegającemu na tym, że nie można sprawić, że „wszyscy upuszczą wszystko”, aby poradzić sobie z problemami wsparcia.

Jest to umiejętność, która naprawdę wiąże się z doświadczeniem i często ludzie są pytani, zanim będą w stanie dokładnie osądzić coś takiego. Zawsze pracowałem w dość zwartej grupie o nieformalnym stylu, ale opracowaliśmy kilka praktycznych zasad, które wydawały się dobrze trzymać.

Po pierwsze, żadne zadanie nie zajmuje mniej niż tydzień. Zawsze szacuj w tygodniach, nawet jeśli zadanie wydaje się, że jego wykonanie zajmie kilka dni. Będzie jakiś powód, dla którego nie zostanie to zrobione przed końcem tygodnia.

Po drugie, dołóż wszelkich starań, aby oszacować czas wykonania zadania, w tym przerwy, problemy z obsługą klienta, przeprowadzenie go przez testy itp. Teraz dwukrotnie podwoj tę liczbę. To jest twój szacunek (w tygodniach).

Po trzecie, upewnij się, że Twój menedżer nie dodaje już dopełnienia do twoich oszacowań. Nasz zespół skarżył kierownika na nasze szacunki. Okazało się, że już zamierza pomnożyć go przez 2,1 (jego obliczenia wypełnienia uzyskane empirycznie) i już go podwoiliśmy, zanim mu o tym powiedziałem.

Nie jest to wymyślne narzędzie i może nie być idealną metodą, ale działa zaskakująco dobrze.

Ludzie dokonujący oszacowań muszą zrozumieć, że żaden zespół nigdy nie jest w 100% zaangażowany w projekt. Masz zwolnienie chorobowe, urlop, pracę przysięgłych, urlop żałobny, wymagane spotkania HR (czas na korzyści!), Spotkania zespołu, które nie są związane z projektem, nieuniknione opóźnienie, przerwy w łazience, wsparcie prac nad produktami już produkowanymi, obsługa wiadomości e-mail, , konfigurowanie nowego komputera po śmierci starego, odpowiadanie na pytania dotyczące przyszłej pracy i dokonywanie szacunków dla tej pracy, mentoring dla juniorów itp., które muszą zostać uwzględnione. Estymator nie jest w stanie przyjąć więcej niż 6 z 8 godzin dostępne na dzień. To gwarancja, że ​​termin nie może być dotrzymany. Jeśli gwarantujesz, że termin nie zostanie dotrzymany, gwarantujesz niezadowolonego klienta.

Masz całkowitą rację - trudno jest zaplanować projekt, nie wiedząc o wszystkim, co się wydarzy. Ale bardzo ważne jest, aby śledzić rzeczy, które są normą, a także zadania, które widzisz. Tutaj odgrywa rolę zarządzanie harmonogramem . Korzystam z zarządzania projektami firmy Microsoft (wersja standardowa), do którego należą również funkcje będące częścią oprogramowania do planowania zarządzania projektami.

Więcej informacji można znaleźć na stronie http://www.microsoft.com/project/en/us/schedule-management.aspx .

Wygląda na to, że zespoły projektowe czerpią wiele ukrytego wysiłku, przez co tracicie koncentrację i szybkość. Dobrym rozwiązaniem może być rozdzielenie zadania

..wspierać problemy, błędy i inne rzeczy?

do określonej grupy osób, aby pozostali członkowie zespołu mogli skupić się na nowych zadaniach programistycznych. Dzięki temu ich ogólna produkcja może nieco spaść, ale jakość poprawi się, ponieważ rozproszenie jest mniejsze. To w zamian zmniejszy liczbę błędów, stąd a-hoc praca, która trafia do twoich projektów.

Jeśli chodzi o część dotyczącą planowania, całkowicie zgadzam się z odpowiedzią Thomasa Owensa.