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

13

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.

Thomas Clayson
źródło
1
Spójrz na Liquid Planner ( liquidplanner.com ). Pozwala wprowadzić optymistyczne i „realistyczne” godziny pracy dla zadania i oblicza szacunkową datę wydania (z dokładnością 50%, 90%, 98%). I robi o wiele więcej, więc gdybym był tobą, spróbowałbym demo
jao
2
Z twojego profilu widzę, że jesteś programistą. Twoje kierownictwo musi sobie z tym poradzić i z klientem. Twoim zadaniem jest oszacowanie, ile to zajmie, i przejrzysta komunikacja, gdy coś pójdzie nie tak. Zarząd bierze to stąd.
JohnDoDo
1
O punkcie 3: wyjaśnij klientowi trójkąt projektu : tani, dobry, szybki: wybierz dowolne dwa.
mouviciel
1
Mouviciel - to dobrze w teorii, ale niestety nie w praktyce. mamy to już na uwadze.
Thomas Clayson
3
@ThomasClayson To nie zmienia faktu, że trójkąt projektu jest prawdą. Jeśli Twoja firma nie rozumie prostego zarządzania projektami, być może czas odejść.
Thomas Owens

Odpowiedzi:

14

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.

Thomas Owens
źródło
bardzo przydatne i bardzo dobre spostrzeżenia. :) Dziękuję Ci bardzo. Rzuć okiem na te książki, dziękuję.
Thomas Clayson
4

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”.

wprowadź opis zdjęcia tutaj

sll
źródło
3
Sugerowanie konkretnego SDLC bez znajomości charakteru projektu i zespołu jest niebezpieczne (na przykład Scrum jest nieodpowiedni dla zespołu mniejszego niż 5 lub zespołu większego niż 10, i wskakiwanie do Scrum bez odpowiednich badań, wpisowego i dostosowania kulturowe przygotowują projekty do niepowodzenia), jednak dyskusja na temat pomiaru czynnika fokusowego jest rzeczywiście istotna i może być przydatna w dowolnej metodologii, w tym metodologii opartej na planach.
Thomas Owens
@Thomas Owens: OP mógł po prostu rzucić okiem i być może uzyskał spostrzeżenia na temat pomiaru czegoś takiego lub innych myśli ...
sll
Dzięki, na pewno się na to spojrzę. Mamy naprawdę trzyosobowy zespół, ale w praktyce i tak sami pracujemy nad projektami. Argument czynnika skupienia jest interesujący. :) Dziękuję Ci.
Thomas Clayson
1

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.

Karl Bielefeldt
źródło
Ale o to chodzi, nasze przerwy tak się nie zdarzają. Na przykład w tym tygodniu powinienem był robić X, ale spędziłem 80% czasu na robieniu przerw. W tym tygodniu odbyło się więcej spotkań niż zwykle i dużo wsparcia. Poza tym zostałem zmuszony do założenia kilku stron internetowych, które zostały zaprojektowane w tym tygodniu, i musiałem skonfigurować serwer programistyczny i zapewnić wsparcie techniczne dla reszty biura. W przyszłym tygodniu nie może być żadnych spotkań ani wsparcia. Albo może będę musiał zaktualizować routery, wykonać kopię zapasową laptopa lub czegoś takiego. Tutaj jest duży zakres sond.
Thomas Clayson
1
Przez tydzień lub dzień masz rację, że jest to nieprzewidywalne, ale jeśli będziesz śledzić to z miesiąca na miesiąc lub dłużej, prawdopodobnie okaże się, że się wyrównuje. Jeśli naprawdę jesteś bardziej dziki niż normalnie, spójrz na pomysł przedziału ufności z EBS. Uwzględnia historyczne prawdopodobieństwa, takie jak: „90% czasu, mam 5 godzin nieprzerwanej pracy, ale pozostałe 10% nie robi nic przez cały dzień”. Z tej historii, zamiast trudnych dat, otrzymujesz wyniki takie jak „Istnieje 85% szans, że skończymy za miesiąc, ale 99% prawdopodobieństwa, że ​​skończymy za 6 tygodni”.
Karl Bielefeldt,
1

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.

Angelo
źródło
0

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.

MattG
źródło
0

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.

HLGEM
źródło
0

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 .

Garry Burks
źródło
-1

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.

Carlo Kuip
źródło