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

Jeśli trafisz na dobrą firmę (najlepiej jakiś Software House - tylko tam są stawki konkretne), to w takiej firmie mają programistów, kierowników projektów i analityków biznesowych, wtedy za analizę biznesową projektu oraz jego wykonanie masz jedną stawkę - i tym wszystkim zajmuje się jedna firma (jeden zgrany zespół).

Przeważnie pracuje się teraz w metodykach zwinnych - przynajmniej w profesjonalnych firmach - i wtedy wykonanie serwisu dzieli się na moduły (tj. części). Analitycy biznesowi pracują nad projektem równocześnie z developerami.

Nie ma tak, że najpierw robi się przez kilka miesięcy dokumentację, a później dopiero zaczyna tworzyć projekt. Wykonuje się to wszystko równocześnie - czyli analityk biznesowy spotyka się z Tobą, przeprowadza wstępną analizę, przygotowuje jakiś pierwszy moduł do zrobienia (przedstawia pomysł), następnie zaczyna tworzyć dokumentację i przedstawiać developerom szczegóły pierwszego modułu - i developerzy zaczynają działać w ciągu pierwszego tygodnia pracy.

I tak tworzy się system moduł po module - dokumentacja jest tworzona na bieżąco, tak samo jak prowadzone są prace. Programiści i analitycy biznesowi muszą być w stałym kontakcie (znam to z praktyki, tak najlepiej się pracuje). i co tydzień lub dwa tygodnie przedstawia się klientowi wersję demonstracyjną systemu, czyli pierwsze działające moduły.

Za dawnych czasów było tak, że oczywiście najpierw tworzyło się mega dokumentację, następnie zaczynało się pracę. Ale to już stare praktyki. Teraz mamy metodyki zwinne, Agile.

Nie wierz w to, że jakiś jajogłowy analityk zrobi Ci dokumentację i później będzie wszystko z głowy - bo jeśli analityk zrobi Ci dokumentację, a później pójdziesz z nią do innej firmy, to po X miesiącach dostarczą Ci system, którego tak naprawdę nigdy nie chciałeś (i załamiesz się myśląc, że zapłaciłeś im za to 40 tys). Ty jako tak zwany właściciel produktu (z ang. "Product Owner") musisz na bieżąco śledzić postępy i domagać się demonstracji (co tydzień lub dwa) tego, co dana firma wykonała.

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

@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)

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

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.

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.

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

@JaroslawK



chodzi ci o zmiane sposobu myślenia klienta ?

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.

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.

No, bo my wtedy przez resztę zaoszczędzonego czasu, patrzymy non-profit przez szybę co robi BA

W dzisiejszych czasach (metodyk zwinnych) nie ma zbytnio miejsca dla BA, chyba, że klient potrzebuje analizy typowo biznesowej, który wpłynie na to czy projekt w ogóle ma sens być realizowany, więc do programistów jeszcze długa droga. Ewentualnie, kiedy naprawdę nie da się dogadać i BA robi za proxy pomiędzy klientem, a team'em. Dokładnie to o czym piszesz jest tym co ja napisałem wcześniej "XX wiek i nie daj się wrobić w coś takiego".

Zresztą Twoje próby wywyższania się są komiczne i nie wiem co chcesz nimi osiągnąć. Jak chciałeś się wyładować na forum to masz na to cały wątek jeszcze, oby ulżyło i możesz dać pomógł.

Evolve or die.

Rozumiem w jakim świecie się obracam, w świecie, gdzie inżynieria wymagań to podstawa, czego większość programistów (i nie tylko) nie rozumie. A moja wcześniejsza wypowiedź odnośnie modeli analitycznych i problemów z ich czytaniem odnosiła się jak zauważyłeś i sam napisałeś do studentów ale nie zawsze, przychodzi programista mówi, że ma parę lat doświadczenia przełożyłem mu dokumentacje, której nie potrafił odczytać. Więc zaznaczyłem "część".

A czy jestem zakompleksionym tłukiem? Nie sądzę, mówi to moje doświadczenie, poparte realizacjami zakończonymi sukcesem i pracy w kilku dużych korporacjach zanim założyłem własną działalność konsultingową.

Damonsson

Nie chciałem się wywyższyć, choć tak to może wyglądać. Ale mniejsza z tym.

W Polsce nadal nie rozumie się idei pracy analityka. W USA nad każdym projektem pracuje w pierwszej kolejności BA i tak w wielu innych krajach. U nas to dopiero wchodzi.

Jeżeli mówisz o jakimś start-up i o samej analizie biznesowej/konkurencji/rynku itd. (do programowania jeszcze długa droga) zgoda, to jest potrzebne i BA się na tym zna doskonale. Jeżeli próbujesz stawiać BA nad team i robić z niego Boga, myśląc, że BA nakreśli UMLa (notabene którego małpa nauczy się w 2 dni), a programista tylko to wdroży ściśle wg Twojej specyfikacji, to cofamy się do XX wieku i od tego się odchodzi na całym świecie, z tylko jednego powodu, to co w teorii brzmi idealnie, w praktyce się nie sprawdza.

No i widzisz, napatrzyłeś się na tych studentów plus jednego nieudacznika i teraz nosisz w głowie wyobrażenie, że programista to 20+ letni idiota. Pomyśl o programistach, którzy w fachu są od lat - tacy, którzy mają 10-30 lat doświadczenia. Wielu z nich było programistami, później PM, BA, potem powracali do fachu programowania (i robią to do dzisiaj - znam kilku takich).

Oczywistym jest, że programista nie wykona tak dokładnej analizy, jaką zrobi analityk (programista nie siedzi 8h dziennie nad analizowaniem biznesu). Jednak wiadomo, że wymagania to podstawa. Pisząc oprogramowanie programista musi wiedzieć co robi (poznać domenę) i co ma zrobić (odpowiednio zaprogramować daną funkcjonalność). To muszą także wiedzieć testerzy (aby go zrozumieć, wiedzieć jak do niego podejść, i widzieć gdzie szukać błędów).

Aby programiści nie musieli wchodzić za głęboko w biznes, zastępują ich analitycy, których celem jest zrozumienie domeny i wyjaśnienie zespołowi o co tak naprawdę chodzi (a także późniejsze pilnowanie, aby wszyscy byli świadomi praw danej domeny). Aby programiści nie musieli za głęboko wchodzić w testowanie systemu, zastępują ich testerzy (choć osobiście uważam, że programista powinien jednak poświęcić więcej czasu na zrozumienie domeny, a także przemyślenie wszystkich use-case'ów i odpowiednie oprogramowanie i zabezpieczenie systemu).

Zgadzam się z tym, że zdarzają się bezmyślni programiści, którzy pracują jak roboty - którzy nie mają ochoty na wgłębianie się w biznes, którzy wymagają tylko tego, aby im przedstawić czarno-na-białym co mają zrobić (i to prostymi poleceniami). Tam gdzie pracuję (jeden z dobrych Software Housów) są programiści myślący, a także tacy, którzy mnie irytują swoją pracą (naprawdę nie znoszę programistów, którzy nie testują swojego kodu - mogę palcem wskazać kilku, którzy mówią "skończyłem", a później jeszcze pół dnia wprowadzają poprawki do swoich wypocin, bo co chwilę ktoś im wynajduje proste bugi, ręce często opadają).

Tak, są programiści-sieroty, tacy "do ubicia", są też tacy, którym zależy i którzy wiedzą na czym polega ich praca.

Życzę Ci tego, abyś wiedział na czym polega Twoja praca - zawsze wydawało mi się, że to polegało na współpracy, tj. aby pomagać programistom zrozumieć biznes i potrafić im to przedstawić w prosty sposób. Dla Twojego dobra i dobrych kontaktów z ludźmi z fachu zachęcam Cię do zmiany tonu w pracy z programistami. Jeśli będziesz zachowywał się jak gbur, który codziennie wygaduje jaki to on nie jest ważny i czego bez niego by się nie dało zrobić, wtedy skończysz marnie - jak to mawiają "You get what you give". Jeśli natomiast będziesz spełniał swoje obowiązki, tj. pomagał programistom zrozumieć biznes, wtedy uzyskasz uznanie.

Pamiętaj - It's a long road to wisdom, but it's a short one to being ignored.

Chłopaki sorry, faktycznie trochę źle to wszystko napisałem jak teraz na to popatrzyłem.

Współpraca w zespole to podstawa, to fakt i to źle przede wszystkim ująłem.

Zakresem analityka biznesowego, bardziej architekta systemów czy jak kto woli projektanta systemów nie jest wyłącznie analiza biznesowa, zakresem obowiązków analityka jest przede wszystkim dostarczenie szczegółowej dokumentacji. Scenariusze użycia powinny składać się z przepływów normalnych, wyjątków itd. opisywać zachowanie i reakcje systemu w rożnych sytuacjach - tu programista otrzymuje kompletnie zaprojektowany system, który wystarczy wyłącznie zaimplementować, ba jeszcze lepiej jeżeli jest możliwość konsultacji BA-PROGRAMISTA to wtedy analizowanie jest to na bieżąco.

W naszym kraju wielu jeszcze nie rozumie, że BA jest odpowiedzialną funkcją w projekcie, nie rozumie się idei związanej z jego pracą nawet nad małymi projektami. Nie rozumie się idei pracy nad inżynierią wymagań. Niestety.

Damonsson

Przy sztywnym budżecie jaki ma autor tematu nie ma sensu pracować przyrostowo. Przy sztywnych budżetach widzę model kaskadowy i tygodniowe/dwutygodniowe iteracje celem statusu (raportu) projektu klientowi. Umowa Fixed Price.

Przy umowie T&M i Agile doskonale pewnie wiesz, że może mu nie wyjść to na dobre, bo koszty mogą wzrosnąć i co zrobi jeżeli końcowa faktura wyniesie X zł więcej niż ma, albo praca developerów zatrzyma się na jego budżecie i będzie niepełna wersja produktu.

Zaobserwowałem, że jesteś zwolennikiem Agile i bardzo dobrze, dobra metodyka zarządzania projektami ale przy większych i "luźnych" budżetach, gdzie można klientowi powiedzieć od - do jako ramy budżetowe.



Możliwości tu są dwie:
1. Sponsor projektu zaangażuje kontakt pomiędzy analitykiem a potencjalnym wykonawcą (po podpisaniu z nim wstępnej lub właściwej umowy), aby mieli ze sobą kontakt na etapie analizy i specyfikowania
2. Sponsor projektu może skorzystać z usług analityka jako "konsultanta" w projekcie i przy właściwych pracach.

Czemu firma X i Z mają dostarczyć inny system sponsorowi (autorowi tematu) skoro będzie spójna dokumentacja? Może on się jedynie różnić jakością wykonania, nie każda firma ma doświadczenie i zatrudnia doświadczonych programistów o czym pisaliśmy.

Ja bym na miejscu autora tematu zlecił przygotowanie dokumentacji oraz bazy odniesienia - najważniejsze wymagania. Poszukałbym wśród doświadczonych, wiarygodnych freelancerów przedstawił im bazę odniesienia celem wstępnej wyceny, przedstawienia oferty i nawiązał właściwą współpracę z odpowiednim kandydatem. Tu być może i analityk pomoże dobrać odpowiedniego kandydata jako konsultant.

Sądząc po budżecie, nie sądzę że będzie to duży projekt więc jeden programista (ew. być może będzie miał godnego znajomego będącego programistą gdzieś na miejscu) będą w stanie pociągnąć prawidłowo ten projekt. A branding można zlecić na zewnątrz, wielu świetnych grafików jest.

a nie lepiej zamiast jechać z koksem po całości zrobić na początku MVP? (MVP czyli minimal viable product, czyli wersja produktu, która może być kijowa, może mieć jakieś bugi, niedoskonałości, może się nieskalować ale będzie miała 2 podstawowe zalety: 1. będzie działać (nie będzie to kot w worku - projekt na kartce), a jak będzie działać to będzie można pomyślić czy dalej, czy w ogóle jest popyt na coś, co chcesz zrobić. 2. zrobisz ją szybko, małymi kosztami. A w razie czego gdyby apka się przyjęła, możesz zawsze się brać za coś z wiekszym rozmachem i robić większe specyfikacje i robić kolejną wersję.

W końcu nie robisz chyba statków kosmicznych, oprogramowania medycznego czy czegoś dla przemysłu, żeby być jak saper.

Bo co robisz - jakis tam serwis internetowy dla branży hotelarskiej? Naprawdę potrzebna jest ci szczegółowa specyfikacja na samym początku? W sytuacji, gdy nie wiesz, czy coś się w ogóle przyjmie?

Tym zajmuje się inżynieria wymagań. Próbuje zbudować się projekt (produkt) który przez pozyskanie wymagań będzie w stanie zwiększyć swoją szanse ustabilizowania się na rynku i rozwoju na nim.

Druga kluczowa sprawa, wchodzące na nasz rynek Customer Development próbuje, pomaga nam stworzyć skalowalny i powtarzalny produkt.

A słaba strona MVP jest taka, że produkt w wersji minimal może się w ogóle nie sprawdzić.

Tak na prawdę, nie potrzeba setek tyś zł na wdrożenie ciekawego startup'a. Potrzeba dobrego i kreatywnego zespołu, który może sponsorowi projektowi nie tylko w wytworzeniu projektu (produktu). Nie dostrzega się wartości w projekcie jaką może zaoferować BA, wielu klientów (zwłaszcza tych) małych żyje w przekonaniu, że BA zatrudnia się do dużych, korporacyjnych projektów.