Forum PHP.pl

Rozglądam się za wykonawcą średniej wielkości serwisu, przy czym mój budżet to ok 40 000 tyś zł. Problem w tym, że nie znam się na tym i nie jestem w stanie przygotować odpowiedniej specyfikacji, tak przy okazji kontaktu z różnymi firmami otrzymałem od jednej kontakt do analityka, który zajmuje się tym na co dzień

za pełen proces analityczny pozyskanie, analiza, specyfikowanie i walidację wymagań powiedział mi 20% wartości budżetu i efektem tego będzie SRS, dokumentacja dot. interfejsów, przypadki użycia i coś jeszcze bezpośrednio odnoszące się do testów. Nie pamiętam teraz, nie mam dostępu do służbowego PC.

To rozsądna według was stawka? Aha i czas pracy oceniał na ok 20 - 25 dni.

Jeżeli jest specjalistą i spędzi miesiąc czasu przy Twoim projekcie, to 8k zł to w miarę normalna cena jak za usługę.

Ok, dzięki wolałem zapytać ponieważ nie znam stawek za takie usługi, tym bardziej że mało słyszałem o tym ponieważ większość firm albo oczekuje specyfikacji (i nic nie powie, nie poleci) albo sporządzą specyfikację w postaci wypunktowanej listy - za co bym nie zapłacił 8 tyś.

Tylko, że na Software House mnie nie stać. Rozmawiałem z jednym (i to z mniejszą firmą), której zespół to 7 osób w tym analityk i przedstawili mi wycenę prawie 70 tyś zł. Nie to że nie rozumiem kosztu, ale po prostu nie mam więcej i nie jestem w stanie pozyskać.

A właśnie ten analityk, którego mi polecili pracował przy startupach i posiada dość dużą wiedzę co mi przedstawił, jakieś wstępny pomysły również przedstawił. Jak mi powiedział jego zakresem nie jest jedynie dokumentacja, ale wejdzie również w Customer Development, aby ukierunkować mój model biznesowy.

No i przy Agile bo czytałem o tym trochę, trzeba mieć w miarę luźny budżet niestety mam sztywny dlatego wolę mieć wszystko na papierze już na początku

Ten post edytował Elfinio 28.11.2015, 20:50:33

@Elfinio, tutaj dosyć ważnym elementem na przyszłość jest obsługa twojego projektu, tzn ty jako założyciel będziesz potrzebował na pewno ludzi którzy będą przy tym pracować.
Pamiętaj o tym że to jest też duży koszt, będziesz potrzebował ludzi/specjalistów którzy w danej dziedzinie cenią swoją roboczogodzinę - weź to również pod uwagę.

Chodzi mi o to że wyłożysz kwote x a możesz nie wyrobić na utrzymanie ponieważ serwis zacznie zarabiać za 1-2-3 lata o tym w dokumentacji nie pisze

Moim zdaniem tak jest z http://grubabiba.pl
właściciel dostał dofinansowanie od anioła biznesu w programie "Jak zostać milionerem", a projekt ledwo dyszy ponieważ właściciela po prostu nie stać na utrzymanie kadr. (Takie jest moje osobiste zdanie)

Ten post edytował ZenekN 28.11.2015, 21:06:14

Pytanie co chcesz zrobić? Czy jest to jakiś szablonowy projekt czy coś kompletnie nieszablonowego. Jesteś trochę w beznadziejnej sytuacji, bo z takim budżetem nie stać Cię nawet na mały Software House. Z drugiej strony, pisanie 20 dni dokumentacji i tworzenie softu wg tego, to XX wiek i nie daj się wrobić w coś takiego. Porozglądaj się wśród lokalnych agencji interaktywnych, czasami mają doświadczonych ludzi, a jakiś project manager czy sam właściciel rozpisze Ci specyfikację za mniej niż 10% tego budżetu.

@Damonsson tylko że PM to PM i on zarządza projektem. A analityk jest w stanie przeprowadzić w miarę skuteczny proces pozyskiwania wymagań i na ogół ma o wiele większą wiedzę od PM w tym zakresie. A termin 20 dni to termin przewidziany na SRS + scenariusze użycia + dokumentacje interfejsów i chyba scenariusze testów akceptacyjnych jak dobrze pamiętam.

Widziałem struktury plików przesłane przez niego i nie wygląda to na prostą specyfikację tylko porządne dokumenty skondensowane o najważniejsze wymagania funkcjonalne, biznesowe, użytkownika. Czyli kompletnie zaprojektowany i opisany system na papierze.

I jeszcze jedna ważna sprawa. Tworzę projekt z własnego kapitału celem pozyskania za X czas inwestora z VC więc zależy mi na poziomie jego wykonania. Pieniądze, które mam płacić agencji interaktywnej (która zazwyczaj nią nie jest, tylko się tak nazywają) gdzie z moich pieniędzy pójdzie na utrzymanie biura, sekretarkę i inne zasoby, które są mi zbędne w projekcie.

A wykonawcy szukam wśród małych firm, zespołów projektowych bo na Software House mnie nie stać.

Nie wiem co to za projekt, Ty go znasz i musisz ocenić czy jest aż tak skomplikowany i nieszablonowy, że musisz 20% budżetu wydać na taką specyfikację (w gwoli ścisłości ta wycena NIE jest zawyżona, budżet po prostu jest mały). Najlepiej gdybyś miał jakąś zaufaną firmę która Ci szczerze powie, czy to jest wykonalne w tej kwocie. Jeżeli ktoś ma siedzieć 25 dni nad specyfikacją, a później ma to się zamknąć w kwocie z budżetu, to wg mnie może być ciężko. Zakładając, że wydasz dobrze te 8.000 i będziesz miał super specyfikację, ale każda firma do której pójdziesz z tą specyfikacją zażąda 100.000 to wiesz co będziesz mógł z nią zrobić?

Mam dwie uwagi.

1. Analityk musi mieć doświadczenie w pracy z wielkimi firmami - bo w takich firmach są prawdziwi specjaliści, są tam też mega projekty dla znanych koncernów. Tam analitycy zdobywają doświadczenie. Ja swego czasu miałem własną firmę, stworzyłem kilka startupów od zera, ale nie ośmieliłbym się nazywać jakimś wykwintnym analitykiem. Liczba startupów to nie jest żadna miara.

2. Mówisz, że do Agile jest potrzebny luźny budżet? Słuchaj, Agile nie został wymyślony dla ludzi z luźnym budżetem, tylko dla bezpieczeństwa klienta - aby nie tworzył najpierw mega dokumentacji, którą później wywali do kosza. Dalej żyjesz w przekonaniu, że analityk przygotuje Ci dokumentację, według której wszystko pójdzie gładko. W świecie programowania jest tylko jedna stała - ZMIANY.

Najlepiej, gdybyś najpierw przygotował samemu jakiś ogólny opis sytemu, następnie dał to do zrobienia jakiejś firmie i dokumentację przygotował dopiero na samym końcu, gdy system będzie już działał i gdy wszystko będzie już jasne.

Ale wiem, że zrobisz i tak wszystko po swojemu - i wiem, że będziesz tego żałował. Przy następnym projekcie będziesz jednak mądrzejszy. ; >

Dobrze napisane, częstym scenariuszem jest to że kolejna osoba do której się zgłosisz z dokumentacją stwierdzi że specyfikację należy napisać od nowa

Ten post edytował ZenekN 28.11.2015, 21:28:00

Tutaj masz ciekawy artykuł: http://www.frogriot.com/blog/pl/time-mater...zeniowy-wybrac/

I jedna ważna rzecz, Agile tylko umożliwia Ci wydanie dodatkowych pieniędzy, żeby produkt wyglądał jednak tak jak chcesz. W modelu Twoim po prostu ta możliwość Ci umyka. Ale czy z niej skorzystasz to tylko Twój wybór.

projekt to B2B dla branży HoReCa.



tylko jak mam na końcu przygotować dokumentacje skoro według dokumentacji system będzie tworzony? nie mówię tu o dokumentacji technicznej po zakończeniu prac, ale o dokumentacji SRS (i kilku innych) którą wielu nazywa specyfikacją

Tutaj masz jedno z lepszych b2b w naszym kraju w dziedzinie elektryki

i spróbuj sobie napisać specyfikację na podstawie takiego sklepu.

Ten post edytował ZenekN 28.11.2015, 21:32:33

Przykład struktury dokumentacji SRS którą otrzymałem od tej osoby wygląda mniej więcej tak, do tego dochodzi jeszcze dokumentacja interfejsów

Historia zmian
1. Wstęp
1.1. Konwencje przyjęte w dokumencie
1.2. Zakres projektu
1.3. Źródła
2. Informacje ogólne
2.1. Perspektywa produktu
2.2. Klasy użytkowników i ich charakterystyki
2.3. Środowisko robocze
2.4. Ograniczenia projektowe oraz implementacji
2.5. Założenia i zależności
3. Funkcje systemu 1
3.1. Opis
3.2. Sekwencje bodziec/reakcja
3.3. Wymagania funkcjonalne
4. Wymagania dotyczące danych
4.1. Logiczny model danych
4.2. Słownik danych
4.3. Raporty
4.4. Pozyskiwanie, integralność, przechowywanie i usuwanie danych
5. Wymagania dotyczące interfejsów zewnętrznych
5.1. Interfejsy użytkownika
5.2. Interfejsy programowe
5.3. Interfejsy sprzętowe
5.4. Interfejsy komunikacyjne
6. Atrybuty jakościowe
6.1. Użyteczność
6.2. Wydajność
6.3. Bezpieczeństwo
6.4. Ochrona
7. Wymagania dotyczące internacjonalizacji oraz lokalizacji
8. Inne wymagania

a funkcje opisywane są w przypadkach użycia.

Ten post edytował Elfinio 28.11.2015, 21:33:07

Może powiem Ci co ja bym zrobił mając 40.000zł budżetu. Szukałbym jakiejś początkującej/rozwijającej się firmy (niższe stawki), która pracuje/próbuje pracować w metodykach zwinnych. Spisałbym swoje podstawowe wymagania i jeżeli firma załapie temat (tworzyła podobny projekt/lub po prostu ma doświadczonych ludzi, którzy to łapią) to bym działał z nimi. Budżet masz myślę na max 2 miesiące pracy takiej raczkującej firmy, więc coś tam sensownego powinno z tego wyjść.

Witam,

Przeglądam to forum od dłuższego czasu jako niezarejestrowany użytkownik, ale przy okazji ciekawego tematu postanowiłem się zarejestrować.

Odpowiadam jako analityk, architekt systemów niegdyś PM (certyfikowany)

O sukcesie produktu (nie projektu) decyduje analiza biznesowa. Agile może zadecydować o sukcesie projektu. Analiza biznesowa opiera się na czterech etapach:

- pozyskanie wymagań (identyfikowanie klas użytkowników, identyfikowanie wymagań użytkowników, identyfikowanie zdarzeń i reakcji systemu, przeprowadzenie wywiadów, analizowanie dokumentów, analizowanie raportów o problemach)

- analiza wymagań (modelowanie środowiska, funkcjonalny prototyp, analizowanie wykonalności, modelowanie wymagań, analizowanie interfejsów

Kolejnym etapem jest specyfikowanie wymagań. Analityk NIE tworzy specyfikacji, tworzy dokumentację odpowiadającą na najważniejsze wymagania, które przedstawione zostały już w temacie. Wymagania te, to wymagania użytkownika, wymagania biznesowe, wymagania funkcjonalne. Wymagania te rozdzielają się na inne wymagania na przykład wymagania pozafunkcjonalne, atrybuty jakości, ...

- walidacja i ocena pozyskanych wymagań, które zostały wyspecyfikowane

etapy, czynności powtarzane są wielokrotnie...

Na etapie ANALIZOWANIA WYKONALNOŚCI analizuje się możliwość wykonania projektu w budżecie na uprzednio zebranych i wstępnie wyspecyfikowanych wymaganiach. Jedne odrzuca się (złocenie), inne będą implementowane za X czasu, a wymagania Y będą implementowane w tej wersji. Etap ten nie odnosi się wyłącznie to analizowania wykonalności w budżecie projektu.

PM/Programista nie ma (zazwyczaj) odpowiedniej wiedzy, aby stworzyć DOKUMENTACJE, nie specyfikację.

Dokumentacja to zazwyczaj kompletnie zaprojektowany i opisany poprzez scenariusze użycia (use case) projekt. Dobra dokumentacja to dokumentacja, przy której programista nie będzie musiał myśleć jak co zrobić, jak co rozwiązać, jak co logicznie połączyć, a tylko pisać kod.

Jak pokazują (światowe) badania analityk to najważniejsza osoba w projekcie:

Business Analysis ? 70%
Architecture and IT strategy/planning ? 66%
Project management ? 65%
Security ? 62%
Service management ? 60%
Client relationship management ? 56%
Business continuity nad IT financial management ? 55%
Portfolio management ? 50%

Narzędzia, które przestawiają wymagania klienta

71,4 % ? modele procesów,
50,1 % ? prototypy,
47,5 % ? modele interfejsu użytkownika,
46,5 % ? diagramy przypadków użycia,
31,1 % ? diagram aktywności,
30,1 % ? schematy/odręczne rysunki,
6,6% % ? inne

Problemy wpływające na porażkę w projekcie

Brak informacji wejściowych od klienta
Niekompletne wymagania i specyfikacje projektu
Zmiana wymagań i specyfikacji projektu
Brak wsparcia ze strony kierownictwa
Brak kompetencji w danej dziedzinie
Brak zasobów ludzkich
Nierealne oczekiwania klienta
Niejasne cele
Nierealne ramy czasowe projektu
Nowe technologie

Pogrubione dotyczą ściśle roli analityka

---------------------------------

Problem na naszym rynku jest taki, że wielu nawet i "specjalistów", programistów nie rozumie idei inżynierii wymagań. Nie rozumieją, że od tego zależy powodzenie projektu i sukces produktu na rynku. Nie rozumieją obowiązków analityka biznesowego. Analityk biznesowy (jeżeli nim faktycznie jest) powinien swojemu klientowi dostarczyć projekt (dokumentacja), który przy dobrej implementacji, projektowaniu i zarządzaniu będzie mógł ustabilizować swoją pozycję na rynku i ją zwiększać.

Ludzie się dziwią czemu większość produktów po chwili kończy działalność bo nie poświęcili odpowiedniego nakładu finansowego i czasu na pracę nad wymaganiami.

Programista myśli, że jest cudo twórcą, a prawdę mówiąc to przez nich większość projektów po chwili kończy działalność, nie potrafią właściwie przeprowadzić najważniejszego w projekcie, tak najważniejszego bo sama implementacja ma priorytet średni w sukcesie produktu, duży zaś na etapie projektu - pracy nad wymaganiami i identyfikacji potrzeb.

Dziwi mnie Panowie programiści, że jako "programiści" nie rozumiecie idei pracy nad wymaganiami i że sukces osiągają wyłącznie te projektu (produkty) w których interesariusze (głównie sponsor) zrozumieli ideę kosztów i czasu prac nad wymaganiami - dowodem są badania rynkowe, opinie ekspertów.

Odpowiadając autorowi tematu.
8 000 zł przy 40 000 zł projektu budżetu to rozsądna propozycja.

Dobry analityk wskaże, podpowie, przeprowadzi SWOT + Customer discovery, customer validation pomoże w określeniu modelu który jest powtarzalny i skalowalny.

Panowie Programiści, opisałem nie wiele, ile z wyżej opisanych rzeczy jesteście w stanie wykonać dla swojego klienta? Na odpowiednim poziomie. Od tego jak to zostanie zrobione, udokumentowane zależy powodzenie projektu, nie od Waszej pracy (nie zrozumcie Panowie mnie źle, ale to analityk odpowiada za główny sukces produktu, nie projektu, programista odpowiada co najwyżej za (część) sukcesu projektu).

Ten post edytował JaroslawK 28.11.2015, 22:35:14

@JaroslawK



chodzi ci o zmiane sposobu myślenia klienta ?

Ten post edytował ZenekN 28.11.2015, 22:47:33

ZenekN

Nie rozumiem, co rozumiesz przez zmianę myślenia klienta.
Według przedstawionego przeze mnie schematu powinno się przekształcać wymagania klienta. Narzędzia te wyjaśniają wątpliwości klienta. Łatwiej jest przedstawić je dalej (zespołowi) w takiej formie, niż formie tekstowej.
Dokumentacja dla zespołu programistycznego powinna być stworzona w postaci modelów analitycznych, wiem, że część programistów nie potrafi prawidłowo czytać tych modeli i trzeba dla nich specjalnie tworzyć scenariusze użycia nie opisane przy pomocy modeli analitycznych, tylko przy pomocy zwykłego tekstu.

Dokumentacja dla klienta powinna zaś być tworzona w przejrzystej formie, choć nie zawsze jest taka potrzeba. Analityka zatrudnia się do pracy nad wyspecyfikowaniem wymagań dla programistów, nie dla klienta.



Przytaczam jeszcze korzyści (od swojego kolegi branżowego z dokumentu, który przesyła swoim klientom).

Korzyści z posiadania dokumentacji, przeprowadzenia procesu analitycznego
? Mniejsza liczba defektów w wymaganiach oraz gotowym produkcie
? Mniejsza liczba przeróbek na etapie projektowania i implementacji
? Szybsza implementacja funkcjonalności
? Mniejsza liczba niepotrzebnych i nieużywanych funkcjonalności
? Niższe koszty ulepszeń
? Mniej błędów w przepływie informacji
? Ograniczenie pełzania informacji
? Ograniczenie chaosu w projekcie
? Większą własną satysfakcję również końcowych użytkowników
? Produkt, który robi to, co powinien robić

Panowie zgodzicie się ze mną, że jeżeli do projektu dostarczona została szczegółowa dokumentacja ze szczegółowymi scenariuszami użycia pracuje się wam wygodniej.
Zgodzicie się ze mną, że mimo, że klient wyda na tym etapie X kwotę, to na etapie Y ją zaoszczędzi. Programista bierze za godzinę od 50 zł wzwyż, poprzez dokumentacje jest w stanie zaoszczędzić Z godzin, co pokrywa ok 10 - 30% kosztów na implementację (w zależności). Reszta poniesionych przez niego kosztów jest dodatna w postaci (zwiększonego) sukcesu produktu.

Fakt faktem, że Wy zarabiacie wtedy mniej.

Ten post edytował JaroslawK 28.11.2015, 23:09:03

Może zaczniemy od tego, że gdy się jest samozwańczym ekspertem, który pracuje dla firmy "Krzak", to można tam spotkać programistów-studentów, którzy dopiero uczą się fachu i za wiele nie wiedza o tym, jak się porozumieć z osobami z fachu, które nie koniecznie się programistami.

Ale mamy swoje narzędzia, np. schematy UML które, w przypadku doświadczonych programistów są często używane, a także przekładane na modele analityczne, tak aby taki przykładowy analityk potrafił je zrozumieć i aby można było się z nim dogadać (stworzyć coś w stylu adaptera). Ja zawsze odbierałem to jako takie przyjacielską wymianę informacji osób z dwóch branż. Z Twoim nastawieniem widzę jednak, że jesteś zwykłym, zakompleksionym tłukiem, który raczej nie rozumie w jakim świecie się obraca.

Nie potrafisz nawet zrozumieć znaczenia słowa "zespół". W IT mamy zespoły składające się z programistów, testerów, PM-ów, analityków. Każdy jest specjalistą w swoim ściśle określonym fachu, trzeba być tłukiem, aby kompetencje jednych porównywać z kompetencjami innych. Zespół jest jak organizm, składa się z różnych organów, które siebie nie zastąpią i organizm do dobrego funkcjonowania potrzebuje działania wszystkich organów. Sam analityk może sobie w nosie pogrzebać bez reszty fachowców.

Ten post edytował Dejmien_85 28.11.2015, 23:43:01