Nic nie posuwa się samym kliknięciem
Większość programów do zarządzania projektami zna znajomy gest: Change Status. Not Started → In Progress → Completed. Bardzo proste. Ale kliknięcie 'Completed' niczego nie kończy. To, co zmienia stan projektu, to fakt biznesowy — wycena zaakceptowana, materiały gotowe, towar dostarczony, pieniądze rozliczone. Status projektu powinien być wynikiem rzeczywistości, a nie listy rozwijanej.
Większość oprogramowania do Project Management ma bardzo znaną operację:
Change Status.
Not Started → In Progress → Completed.
Bardzo proste.
Ale projektując Snappy PM, wyznaczyliśmy sobie zasadę:
Nothing advances on a bare click.
Dlaczego?
Bo kliknięcie "Completed" przez człowieka nie czyni niczego naprawdę zakończonym.
Tym, co naprawdę zmienia stan projektu, jest fakt biznesowy.
Klient zaakceptował wycenę.
Materiały są gotowe.
Produkt jest ukończony.
Towar został dostarczony.
Płatność została rozliczona.
Więc choć pięć Phases Snappy PM wygląda prosto, to, co naprawdę liczy się za każdym etapem, to:
What has actually happened?
Weźmy Scoping & Design.
Naprawdę nie zależy nam na tym, czy Project Manager zmienił Status na "Design Completed".
Zależy nam na tym:
Czy klient zaakceptował naszą ostateczną Quotation?
Jeśli klient potwierdził telefonicznie, mailem, przez WhatsApp lub podpisem, PM może zarejestrować Customer Approved. System zapisuje, kto i kiedy potwierdził — i dopiero wtedy projekt może przejść do następnej fazy.
Tak samo jest z Closing.
To, że kierownik projektu czuje, że projekt się skończył, nie znaczy, że projekt naprawdę można zamknąć.
Jeśli:
Invoices nie zostały w pełni wystawione albo są jeszcze nierozliczone pieniądze,
system powinien mu ten fakt powiedzieć.
Dlatego coraz mniej podoba mi się rozumienie Project Management jako:
Task + Status + Gantt Chart.
Oczywiście mają one wartość.
Ale dla wielu małych firm ważniejsze pytanie brzmi tak naprawdę:
Reality vs. Status.
Zielone światło w oprogramowaniu nic nie znaczy.
Naprawdę liczy się to, czy klient potwierdził, czy towar dostarczono, czy koszty faktycznie powstały, czy pieniądze dotarły.
Dlatego Snappy PM chce budować status projektu w możliwie największym stopniu na prawdziwych danych biznesowych.
Document.
Quotation.
Expense.
Inventory.
Delivery.
Invoice.
Payment.
Te rzeczy i tak dzieją się w codziennym funkcjonowaniu firmy.
Jeśli system potrafi rozumieć te fakty, pracownicy nie powinni musieli dodatkowo utrzymywać oddzielnego "Project Status" oderwanego od biznesu.
A project should move because the business moved.
Not because someone changed a dropdown.
SnapLedger, your life easier.
Reality vs. Status. Zielone światło w oprogramowaniu nic nie znaczy; liczy się to, czy klient potwierdził, czy towar dostarczono, czy koszty rzeczywiście powstały, czy pieniądze dotarły. Jeśli system rozumie dokumenty, wyceny, wydatki, dostawy, faktury i płatności, pracownicy nie powinni musieli utrzymywać osobnego 'statusu projektu' odciętego od biznesu.
Gdyby w twoich obecnych projektach nikt nigdy więcej nie kliknął 'zaktualizuj status' — jak daleko obraz systemu odbiegłby od rzeczywistości i której z tych dwóch byś zaufał?
Projekt powinien przesuwać się, bo przesunął się biznes. Nie dlatego, że ktoś zmienił listę rozwijaną.
Otrzymuj Founder Diary + aktualizacje regulacyjne dla Twojego kraju
E-mail, gdy Richard opublikuje nowy wpis, oraz zmiany w przepisach ważne tam, gdzie mieszkasz. Bezpłatnie, z możliwością rezygnacji w każdej chwili.