Spisu treści:
- Długość propozycji
- Streszczenie dla kierownictwa
- Szablon
- Tytuł Projektu
- Spis treści
- Aprobaty
- Zmiany
- Glosariusz i akronimy
- Zakres
- Oś czasu
- Członkowie projektu
- Możliwości biznesowych
- Omówienie rozwiązania
- Funkcje i elementy dostarczane
- Budżet i zwrot z inwestycji
- Korzyści
- Ograniczenia
Jak napisać udaną propozycję rozwoju oprogramowania.
Kevin Languedoc
Celem propozycji rozwoju oprogramowania jest przedstawienie rozwiązania, które zostanie przeczytane przez ludzi biznesu, więc postaraj się, aby było ono proste i na temat; unikaj terminów technicznych tak bardzo, jak to możliwe. Poniższy schemat może być wykorzystany w obecnej postaci do przygotowania udanej propozycji rozwoju oprogramowania. Należy pamiętać, że osoby, którym zamierzasz przedstawić propozycję, nie mają zbyt wiele czasu na przeczytanie obszernego dokumentu. Możesz mi to odebrać, napisałem setki propozycji przez ponad 20 lat mojej pracy w informatyce: biznesmeni chcą tylko tyle informacji, aby umożliwić im podjęcie świadomej decyzji.
Jeśli odpowiadasz na zapytanie ofertowe (RFP) i musisz przestrzegać określonego zakresu stron, ponieważ strony są wstępnie wydrukowane lub wymagania dotyczące treści zmuszają Cię do złożenia zbyt długiej oferty, rozważ użycie podsumowania wykonawczego. dodałem sekcję opisującą, jak ją przygotować poniżej.
Długość propozycji
Widziałem szablony i dyskusje opowiadające się za propozycjami, które działają na 50 lub stronach. Uwierz mi, po piątej stronie stracisz zainteresowanie dyrektora biznesowego. Po zaakceptowaniu propozycji dokumenty projektowe będą oczywiście bardziej szczegółowe, ponieważ będą przeznaczone dla zespołu projektowego i będą stanowiły robocze plany systemu. Dotyczy to większości klientów, ale (tak, zawsze jest „ale”), jeśli propozycja jest odpowiedzią na zapytanie ofertowe (RFP), należy zastosować się do zapytania ofertowego. Ponadto agencja rządowa lub wojskowa prawdopodobnie będzie mieć surowe wytyczne dotyczące przygotowania propozycji rozwoju oprogramowania i może zawierać kilka stron (10, 20, 30, 50 lub więcej) w zależności od złożoności systemu.Ta zasada nadal obowiązuje w przypadku dużych organizacji, które mogą mieć formalny proces składania propozycji, zwłaszcza jeśli są korporacjami publicznymi i muszą przestrzegać wszelkich przepisów i norm Sarbannes-Oxley lub ISO.
Streszczenie dla kierownictwa
Jeśli oferta ma ponad 20 stron, możesz rozważyć dostarczenie streszczenia, które stanowi jednostronicowy zbiór sekcji propozycji. Możesz nawet dostarczyć podsumowanie wykonawcze w formacie PowerPoint. Jeśli planujesz wykorzystać podsumowanie dla kierownictwa w prezentacji propozycji rozwoju oprogramowania, przedstaw propozycję, korzystając z podsumowania wykonawczego, a kierownik może przeczytać propozycję w późniejszym czasie, np. Podczas lotu biznesowego.
Szablon
Poniższy schemat jest w rzeczywistości dobrym szablonem, którego możesz użyć do przygotowania własnej propozycji rozwoju oprogramowania. Przygotowując propozycję, zawsze pamiętam o zasadzie „Elevator Pitch”. Ty też powinieneś. Zasadniczo, „Prezentacja w windzie” określa, że Twoja propozycja nie powinna być dużo dłuższa niż czas potrzebny na przejazd windą z parteru na najwyższe piętro budynku w celu przedstawienia oferty.
Tytuł Projektu
Z podtytułem lub podsumowaniem informacji na temat wniosku
Propozycja powinna mieć tytuł i podsekcję podsumowującą kontekst propozycji oprogramowania. Należy również podać nazwę oddziału, usługi, działu lub organizacji, dla której projekt jest przeznaczony.
Jeśli odpowiadasz na zapytanie ofertowe (zapytanie ofertowe), podaj wszelkie informacje, które są wymagane lub wymienione jako obowiązkowe w zapytaniu ofertowym. Widziałem również zapytania ofertowe, w których prośba o umieszczenie podpisów zatwierdzenia oprócz tytułu na pierwszej stronie, ale w tym przykładzie umieściłem podpisy na stronie z sekcją Zmiany.
Spis treści
Na następnej stronie powinieneś załączyć spis treści, wyszczególniający główne sekcje wniosku. Opcjonalnie możesz podać numery stron, jeśli oferta pakietowa przekracza pięć stron lub wymaga tego zapytanie ofertowe.
Aprobaty
Ta sekcja ma kluczowe znaczenie dla procesu, niezależnie od tego, czy jest to odpowiedź na zapytanie ofertowe, czy z tego szablonu, czy z innego źródła. Ta sekcja dokumentuje potwierdzenia, że projekt jest gotowy i zawiera wiążącą umowę między różnymi członkami projektu. Nigdy nie powinieneś rozpoczynać projektu, dopóki nie uzyskasz wszystkich niezbędnych podpisów i nie uzyskasz zobowiązania ze strony mistrza projektu i interesariuszy do rozpoczęcia projektu. W przeciwnym razie możesz znaleźć się w opozycji, jeśli projekt zostanie anulowany lub jeśli zakres projektu ulegnie zmianie lub wyniki.
Po wprowadzeniu zatwierdzeń zmiany zakresu i rezultatów są znacznie trudniejsze do wprowadzenia, a w przypadku sporów posiadanie podpisanych zezwoleń zapewni jasne (lepsze) zrozumienie tego, co zostało uzgodnione. Oczywiście zawsze istnieje kwestia interpretacji.
Zatwierdzenia powinny zawierać nazwisko osoby, jej stanowisko, podpis, a na końcu datę podpisania dokumentu.
Nazwa | Rola tytułowa | Podpis | Data |
---|---|---|---|
Zmiany
Sekcja Zmiany zawiera dziennik wszystkich zmian, które zostały lub zostaną wprowadzone w dokumencie Propozycja rozwoju oprogramowania. Nie dokumentuje żadnych zmian w zakresie samego projektu ani w żadnym innym aspekcie projektu. Sekcja Zmiany powinna zawierać co najmniej imię i nazwisko osoby dokonującej zmiany, datę zmiany oraz komentarz lub opis zmiany.
Autor | Data zmiany | Opis lub komentarz |
---|---|---|
Glosariusz i akronimy
Wymień wszelkie terminy lub akronimy i ich definicje. Nie zakładaj, że wszyscy znają znaczenie terminów lub akronimów, zwłaszcza jeśli planujesz korzystać z usług konsultantów zewnętrznych, a terminy są wewnętrzne, osadzone w kulturze korporacyjnej i żargonie. Każda organizacja ma swój własny żargon i akronimy. Wykorzystanie ich w propozycji jest w porządku, o ile są odpowiednio udokumentowane.
Ponadto, jeśli używane są akronimy specyficzne dla danej branży, należy je również udokumentować, aby każdy miał jasne zrozumienie znaczenia terminów i akronimów oraz formułował lepsze interpretacje.
Następujące akronimy pochodzą z bieżącego szablonu. Podano je jako przykład.
- Zapytanie ofertowe: Zapytanie ofertowe
- ROI: zwrot z inwestycji
- CAGR: złożona roczna stopa wzrostu
- IT: technologia informacyjna
- CAPEX: Nakłady inwestycyjne
- JM: jednostka miary
Zakres
Zakres wniosku powinien określać na wysokim poziomie ogólne szczegóły projektu, co jest uwzględnione i wyłączone. Zakres powinien zawierać ogólny opis, czas trwania projektu, główne cele. Co próbujesz osiągnąć dzięki tej inwestycji w proponowany projekt rozwoju oprogramowania.
Oś czasu
Ta sekcja będzie zawierać daty rozpoczęcia i zakończenia (szacunkowe). Pamiętaj, aby zbudować bufor i zaplanować nieprzewidziane okoliczności. Dobrą praktyczną zasadą jest dodanie 75% bufora do osi czasu.
Członkowie projektu
W skład członków projektu powinni wchodzić mistrz projektu i interesariusze. Mistrz jest zwykle dyrektorem, który kieruje ogólnym projektem i budżetem. Interesariusz jest zwykle wewnętrznym promotorem lub sponsorem. Mogą być również mistrzami w zależności od zakresu projektu i / lub rodzaju organizacji, która prosi o propozycję rozwoju oprogramowania. Pozostała lista zawiera typowe role, jakie ludzie pełnią w projekcie.
Poniższe informacje podano jedynie jako przykład typów ról, jakie mogą pełnić uczestnicy projektu. Niektórzy ludzie mogą mieć więcej niż jedną rolę. W zależności od zakresu projektu lista członków projektu może być bardzo długa lub ta sama osoba może pełnić różne role.
Lista powinna zawierać wszelkie informacje, które właściwie identyfikują osobę, jej rolę w projekcie, jak do niej dotrzeć i jakie są jej obowiązki. Możesz dołączyć inne informacje w zależności od zapytania ofertowego lub typu organizacji, z którą będziesz pracować, i jej wewnętrznych zasad.
Członek zespołu | Rola | Informacje kontaktowe | Obowiązki |
---|---|---|---|
Mistrz |
|||
Interesariusz |
|||
Menadżer projektu |
|||
Architekt |
|||
Analityk |
|||
Deweloper |
Możliwości biznesowych
Większość dostępnych szablonów definiuje tę sekcję jako „Problem biznesowy” lub „Opis problemu”, jednak często spotykałem liderów biznesu, którzy obrażają się, że mają problem w swojej jednostce biznesowej lub procesie. Pamiętam, jak jeden dyrektor dosłownie wyrzucił mnie ze swojego biura, ponieważ powiedziałem, że naprawiamy proces, a ona powiedziała mi, że to nie będzie ktoś z IT (informatyka), który będzie dyktował, czy ma problem z jej procesami, czy nie.
Dlatego uważaj na sformułowanie. Zawsze używam terminu „okazja biznesowa”, ponieważ ostatecznie propozycja jest odpowiedzią na możliwość biznesową usprawnienia procesu, wsparcia procesu lub zautomatyzowania procesu
Oświadczenie biznesowe | Jak system spełni wymagania |
---|---|
Proces biznesowy, sytuacja, problem, na który ma to wpływ |
W jaki sposób proponowane rozwiązanie poprawi docelowy obszar biznesowy |
Jaka potrzeba jest adresowana |
W jaki sposób obecny projekt ma to rozwiązać |
Omówienie rozwiązania
W sekcji Omówienie rozwiązania można przedstawić ogólny przegląd systemu. Ten przegląd może zawierać mapę nawigacyjną, jeśli propozycja dotyczy witryny internetowej lub aplikacji internetowej. Możesz również dołączyć schemat blokowy przebiegu procesu. Możesz również dołączyć diagram głównych komponentów systemu.
Celem jest przekazanie osobie podejmującej decyzję wystarczających informacji, aby zrozumiała, czym jest system, jak będzie działał i jakie są główne elementy składowe. Oczywiście jest to tylko wskazówka, ponieważ organizacja może mieć formalny format, który definiuje, co będzie potrzebne we wniosku, zwłaszcza jeśli masz do czynienia z agencją rządową lub departamentem obrony.
Funkcje i elementy dostarczane
W tej sekcji przedstawiono mechanizm mapowania cechy proponowanego systemu do namacalnego produktu. Widziałem również tę sekcję zawierającą oszacowanie czasu potrzebnego do ukończenia produktu dostarczanego, ale nie lubię tego używać, ponieważ jest zbyt restrykcyjny i tworzy powiązanie. Podczas pracy nad projektem rezultaty mogą nie zgadzać się dokładnie z zapisanymi, więc jeśli zobowiązałeś się na papierze do ukończenia elementu dostawy w określonym czasie, usuwa to lub zmniejsza elastyczność później, kiedy faktycznie wykonujesz projekt.
Kolejną kolumną, którą można dodać, jest wydanie, do którego należy element dostarczany. Jest to przydatne, jeśli projekt będzie dostarczany przez dłuższy czas i będzie kilka wydań. Może to również dotyczyć projektów opartych na metodach Agile lub Lean, w których każda funkcja lub historia użytkownika należy do wersji.
Koncepcja jest prosta; dla każdej funkcji w systemie podaj nazwę funkcji, krótki opis oraz to, który produkt będzie spełniał wymaganie funkcji.
Funkcja | Opis | Dostarczalne |
---|---|---|
Budżet i zwrot z inwestycji
Budżet i zwrot z inwestycji są prawdopodobnie najważniejszą częścią dla niektórych kierowników. Wszyscy chcą wiedzieć, ile będzie ich kosztował system lub jaki wpływ ten projekt będzie miał na budżet ich działu. Jest to szczególnie prawdziwe, jeśli projekt nie został uwzględniony w Capex na początku roku podatkowego.
Czasami, nawet jeśli projekt został uwzględniony w budżecie, inny projekt może mieć pierwszeństwo przed obecną propozycją, a fundusze mogą zostać przekierowane z zamierzonego źródła. Często na szczeblu wykonawczym i kierowniczym toczą się spory polityczne, mające na celu uruchomienie projektu, i często występują nieprzewidziane okoliczności, które mogą mieć pierwszeństwo przed projektami planowanymi.
Przygotuj się więc na współpracę z interesariuszem, aby pomóc w negocjacjach lub bądź elastyczny i proaktywny, aby zapewnić działające rozwiązanie, jeśli sytuacja budżetowa się pogorszy. Lepiej jest dostosować projekt do realiów budżetowych, nawet rozłożyć wyniki systemu na dłuższy okres lub nawet odejść od projektu. O wiele lepiej jest odejść niż pracować nad projektem i nie otrzymywać zapłaty i uciekać się do sporów sądowych.
Poniższa tabela służy wyłącznie do celów demonstracyjnych, aby dać wyobrażenie o tym, jak przygotować budżet. Oczywiście będziesz musiał dodać własne pozycje, aby dopasować je do swojego projektu. Następnie wpisujesz ilość, cenę jednostkową, jednostkę miary i sumę pozycji towarowej. Następnie zsumuj sumy pozycji na dole.
Zapewni to dobry obraz inwestycji wymaganej do wykonania projektu oprogramowania. Większość menedżerów, z którymi pracowałem, lubi wiedzieć, jaka będzie stopa zwrotu lub ile ten projekt będzie kosztował w czasie, więc dołączam również prostą wartość zwrotu z inwestycji i CAGR, korzystając z własnych szacunków i założeń (które muszą być wyjaśnione) we wniosku lub przy użyciu dostarczonych szacunków i założeń.
Element projektu | Ilość | Cena jednostkowa | JM | Całkowity |
---|---|---|---|---|
Licencja oprogramowania |
||||
Maszyna (y) |
||||
Licencja na serwer |
||||
Licencja bazy danych |
||||
Konsultant ds. Rozwoju |
||||
Zarządzanie projektami |
||||
Szkolenie (czas + materiały) |
ROI
Obliczenie zwrotu z inwestycji jest bardzo łatwe. Zasadniczo formuła to zysk - koszt podzielony przez koszt. Wzór znajduje się poniżej:
Jedynym minusem jest to, że obliczenia nie uwzględniają czasu, więc zwrot z inwestycji jest dobry w przypadku projektów krótkoterminowych, ale w przypadku projektów długoterminowych generalnie uwzględniam CAGR (złożony roczny wskaźnik wzrostu). Obliczenie CAGR to roczna stopa zwrotu dla określonego momentu.
CAGR
Wzór CAGR to:
Pierwsza część to podzielenie wartości końcowej przez wartość początkową. Wynik jest podnoszony do potęgi 1 przez liczbę zainwestowanych lat. Wynikowa wartość jest odejmowana przez 1.
Korzyści
W tej sekcji wymienisz korzyści biznesowe, które zapewni projekt oprogramowania. Mogą być wymienione w formie punktorów, o ile są zgodne z ogólnymi celami. Powinni pokazać, jak oprogramowanie lub system zwiększy wartość biznesową.
Krótko mówiąc, w jaki sposób proponowane rozwiązanie pomoże firmie odnieść większy sukces i osiągnąć założone cele? Używaj pozytywnych słów i zdań.
Ograniczenia
Sekcja dotycząca ograniczeń powinna zawierać listę wszelkich materialnych i niematerialnych ograniczeń, które można przewidzieć. Może to dotyczyć wyposażenia, pewnego czynnika sezonowego, takiego jak zamknięcie zakładu produkcyjnego, co na przykład większość zakładów robi co najmniej raz w roku.
Spróbuj bagatelizować ograniczenia lub pomalować je jako minimalne. Nie wymieniaj żadnych negatywnych aspektów oprogramowania lub systemu, a jeśli musisz, zastosuj obejścia.
© 2012 Kevin Languedoc