Ten arty­kuł jest pew­ną kon­ty­nu­acją poprzed­nie­go. Potraktujmy go jako ​„prost­szą wer­sję” 🙂 popar­tą ocze­ki­wa­nia­mi przy­szłe­go wyko­naw­cy, któ­ry w swo­im arty­ku­le nie­ja­ko ​„skła­da zamó­wie­nie na doku­ment wymagań”.

Wpadła mi swe­go cza­su przed oczy stro­na pew­ne­go deve­lo­pe­ra stron WWW. Dlaczego mnie zain­te­re­so­wa­ła? Bo po pierw­sze słusz­nie ocze­ku­je od swo­je­go klien­ta kon­kre­tów, po dru­gie potra­fi krót­ko i zwięź­le opi­sać cze­go potrze­bu­je, by mógł wytwo­rzyć opro­gra­mo­wa­nie (opi­sał to w kon­tek­ście two­rze­nia stron WWW, któ­re obec­nie bar­dzo czę­sto tak­że są wyni­kiem dzia­ła­nia oprogramowania):

Podstawowym doku­men­tem, któ­ry nale­ży przy­go­to­wać jest spe­cy­fi­ka­cja tech­nicz­na. Powinna ona wyszcze­gól­nić funk­cjo­nal­no­ści, któ­re mają zna­leźć się na stro­nie. Niestandardowe funk­cje powin­ny zostać dokład­nie opi­sa­ne. Opis może przy­brać for­mę zarów­no słow­ną, jak i gra­ficz­ną (sche­mat dzia­ła­nia, dia­gra­my UML).

Jak widać podzie­lił wyma­ga­nia na funk­cje (funk­cjo­nal­no­ści) stan­dar­do­we i nie­stan­dar­do­we. Dlaczego? Uważam, że słusz­nie, stan­dar­do­we (opi­sa­ne już gdzieś lub ogól­nie uzna­ne) funk­cjo­nal­no­ści nale­ży wydzie­lić i przy­to­czyć ich zna­ne i typo­we opi­sy lub nazwy (np. okno logo­wa­nia) dzię­ki cze­mu uni­ka­my nazbyt szcze­gó­ło­wych (czy­taj kosz­tow­nych bo pra­co­chłon­nych) opi­sów zacho­wu­jąc już jed­nak pew­ną jed­no­znacz­ność. Po dru­gie, zapew­ne będą one reali­zo­wa­ne przez pre­de­fi­nio­wa­ne w wie­lu narzę­dziach, modu­ły (czy­taj wyko­na­ne taniej). Niestandardowe funk­cjo­nal­no­ści wyma­ga­ją dokład­niej­sze­go opi­su – bo są niestandardowe ;).

I dalej:

Poza dany­mi czy­sto tech­nicz­ny­mi war­to opo­wie­dzieć tak­że o swo­im biz­ne­sie. Im wię­cej poten­cjal­ny wyko­naw­ca stro­ny będzie wie­dział o fir­mie tym lepiej będzie mógł dosto­so­wać ją [stro­nę WWW, opro­gra­mo­wa­nie] do cha­rak­te­ru fir­my. Warto powie­dzieć co wyróż­nia fir­mę na tle kon­ku­ren­cji, co robi lepiej, jakie umie­jęt­no­ści posia­da. Należy rów­nież okre­ślić cel reali­zo­wa­ny przez stronę.

Opis funk­cjo­nal­no­ści zawsze będzie zacho­wy­wał pewien poziom ogól­no­ści (autor opi­su nie pro­gra­mu­je a opi­su­je co chce dostać i z pomo­cą tego co dosta­nie, osią­gnąć). Skoro więc ist­nie­je pew­ne pole manew­ru dla wyko­naw­cy (a zawsze tak będzie), pomo­że mu w wytwo­rze­niu lep­sze­go pro­duk­tu, zro­zu­mie­nie celu zama­wia­ją­ce­go. Jak prze­ka­zać wie­dzą ​„pozwa­la­ją­cą zro­zu­mieć”? Od tego jest ana­li­za biz­ne­so­wa i zapis jej wyni­ków, w tym model biz­ne­so­wy fir­my i cel biz­ne­so­wy projektu.

Model biz­ne­so­wy powi­nien zawie­rać nie tyl­ko opis zama­wia­ją­ce­go. Jeżeli jakie­kol­wiek funk­cjo­nal­no­ści są dedy­ko­wa­ne klien­tom zama­wia­ją­ce­go (publicz­na stro­na WWW, por­tal samo­ob­słu­gi CRM itp.) opis typo­we­go klien­ta (gru­pa doce­lo­wa) i jego cele, tak­że powin­ny zna­leźć się w tre­ści ana­li­zy biznesowej:

Kolejnym ele­men­tem jest prze­ka­za­nie infor­ma­cji o klien­cie, do któ­re­go kie­ro­wa­na jest stro­na. Takie czyn­ni­ki jak wiek, wie­dza czy zapo­trze­bo­wa­nia na infor­ma­cję odbior­ców wpły­wa­ją na spo­sób reali­za­cji stro­ny. Strona two­rzo­na jest dla naszych odbior­ców, tak więc im lepiej będzie dosto­so­wa­na do ich potrzeb, tym lep­szy będzie jej odbiór.

Pora na część najtrudniejszą:

Na koniec nale­ży zamie­ścić infor­ma­cje orga­ni­za­cyj­ne takie jak budżet oraz ter­min uru­cho­mie­nia strony.

Jak nie ​„po dobro­ci” to pod­czas nego­cja­cji umo­wy. Ogólnie zawsze powin­na to być tak zwa­na umo­wa ​„fixed pri­ce” czy­li umo­wa o dzie­ło o usta­lo­nym zakre­sie (powyż­szy opis), budże­cie (war­tość umo­wy) i ter­mi­nie (har­mo­no­gram).

(na pod­sta­wie arty­ku­łu Jak przy­go­to­wać zapy­ta­nie ofer­to­we? | Firma w sie­ci).