Sveikiname jus kompetentingas nepriklausomas kūrėjas . Nuo savo kuklios pradžios, galbūt dirbdami testuotoju, jūs perėjote į komandos kūrėją, paskui - į vyresnįjį kūrėją, o dabar padarėte dar vieną šuolį, didžiausią iš jų, - tiesioginį darbą su klientais.
Bet ten, kur kiti perėjimai buvo tiesiniai, šis paskutinis buvo eksponentinis. Anksčiau žygių užsakymus gaudavote iš darbdavio, kuris dirbo su klientais arba pats užsiėmė programinės įrangos verslu, dabar visos tos pareigos, kurios kažkada buvo paskirstytos tarp ekspertų bandymų, programų valdymo ir t. T. O dabar jūs dirbate su klientais, kurie nėra programinės įrangos verslas; jie yra kitame versle, kuriam reikalinga programinė įranga, ir jie neturi aiškios ir tikslios vizijos, ko nori iš tavęs. Tai kur kas didesnis iššūkis nei atrodo.
* Pastaba: * Čia aš apibūdinu mažesnius klientus, kurie nori vieno žmogaus armijos iš savo kūrėjo. Tai nėra vienintelis maršrutas, kurį gali eiti laisvai samdomas darbuotojas, ir tai nėra vieninteliai klientai, su kuriais dirbame „ApeeScape“, tačiau man labiausiai patinka maršrutas. Žinoma, jei dirbate komandoje, o ne pats , kai kurie iš žemiau pateiktų elementų nebus taikomi. Pavyzdžiui, jei naudojate Judrios metodikos arba Scrum , tikriausiai norėsite šiek tiek kitaip suformuoti savo etapus.
Jūs visi girdėjote apie aukščiausią bendravimo svarbą. Jūs negalite dirbti, gaudami kelis trumpus aprašymo sakinius per „Skype“ ir sakydami 'Iki pasimatymo po trijų mėnesių, kai baigsiu'. Turite bendrauti su savo klientu ir kiekviename savo darbo etape įsitikinkite, kad turite tikslių idėjų, nes iš tikrųjų retai klientas jums atsiųs vielinius rėmus ir išsamią funkcinę specifikaciją. Jūs gausite labai bendrą supratimą apie tai, ką programinė įranga turėtų daryti, atrodyti ir tekėti. Jei parašote paraišką pagal paviršutinišką aprašymą, nuo kurio paprastai pradedate, beveik nėra tikimybės, kad jūsų klientas bus patenkintas rezultatu. Kiekviename etape turite kartoti savo kelią arčiau susitarimo.
Jūs negalite dirbti, gaudami kelis trumpus aprašymo sakinius per „Skype“ ir sakydami „Iki pasimatymo per tris mėnesius, kai aš baigsiu“.
Daugelį metų dirbęs įmonėse, kurios pačios užsiėmė programinės įrangos verslu, kur visi komandos nariai buvo iš tos pačios kultūros, kalbėjo ta pačia gimtąja kalba, dirbo tame pačiame koridoriuje, kasdien susitiko ir t. T., Pažymėtina, kad įmonė vis tiek pusę laiko negavau to, ko norėjo. Nesuklyskite: iššūkis čia milžiniškas.
Taigi, kai imsitės naujo projekto, prieš net atidarydami „Xcode“ ar „Visual Studio“, turite turėti aiškius ir sutartus dizaino tikslus . Šie tikslai turėtų būti nustatyti specifikacijos dokumente. Jei klientas dar nerašė, turėtumėte jį parašyti ir pateikti jam peržiūrėti dar neatidarę savo IDE. Ir jei susiduriate su klientu, kuris sako: „Mes neturime laiko projektavimo dokumentams“, atvirai, turėtumėte nueiti nuo projekto nes jūsų laukia nemalonumai. Specifikacija neturi būti ypač ilga; tai gali būti tik keli puslapiai, bet bent jau turėtų būti išdėstyta vartotojo sąsaja, įtraukti laidų rėmai (jei yra vartotojo sąsajos komponentas) ir nustatyti užbaigimo etapai.
Be šį dokumentą pateksite į aštrią pašaipą, kai klientai ginčys tai, ką jums pasakė ar ką jūs jiems sakėte, piktai siuntinėdami ankstesnių pranešimų iškarpas, aiškindamiesi ir ginčydamiesi, kol ateis laikas, kai klientas to pareikalaus atliekate pakeitimus, kad paraiška atitiktų „tai, ko jie iš tikrųjų paprašė“, ir tikitės, kad atliksite tuos pakeitimus nemokėdami.
Su Šiame programinės įrangos projektavimo dokumente turėsite atsakymą į bet kokį tokį ginčą: iškilus nesutarimams, galite nurodyti specifikaciją, kurią klientas sutiko ir pasirašė, nurodydamas, kad laiške ją įvykdėte. Vietoj piktų ginčų atliksite dokumento pakeitimus ir paaiškinimus. Jei kas, klientas atsiprašys, kad iš pradžių leido praslysti.
Mes visi norime patenkintų klientų. Mes visi norime draugiškų darbo santykių. Mes visi norime pasididžiavimo gerai atliktu darbu. Tačiau jų negalima pasiekti, jei yra kokių nors neaiškumų, koks iš tikrųjų yra darbas yra . Jei jūsų klientas sako, kad dizaino dokumentas yra per didelis papildomas darbas, tai jūsų darbas paaiškinti jiems, kad tikras papildomas darbas atsiras, kai dėl kažkokio nesusipratimo reikės atlikti pataisas. Jei klientas vis tiek primygtinai reikalauja, kad žengtumėte be tokio dokumento, turėtumėte susitaikyti su tuo, kad jūsų santykiai neveikia, ir nueikite.
Tai turėtų būti bent jau norimos paraiškos aprašymas, užbaigimo kriterijai ir gairės. Atminkite, kad bendrinate tai, kas geriausiai apibūdinama kaip reikalavimų ir funkcijos dokumentas, o ne diegimo specifikacija. Ir nebent konkretus įgyvendinimas yra nurodytas kliento tikslas, kaip jūs jį pritaikysite, priklauso nuo jūsų.
Dauguma projektų yra programos, o ne bibliotekos ar sistemos. Bet jei atsitiks, kad vienas iš šių būdų bus pasiekiamas, suskaičiuokite, ar jums pasisekė, nes vartotojo sąsaja yra pats problemiškiausias jūsų dizaino dokumento šablono komponentas ir beveik visada sukelia nesusipratimų. Daugelis klientų atsiųs jums tobulas iliustracijas, kurias grafiniame redaktoriuje sukūrė grafikos dizaineris, kuris nėra programuotojas. Tačiau problema yra tokia: šiose iliustracijose nieko nėra pasakyta apie animacijas, valdymo būsenas (pvz., Ar šis mygtukas išjungtas? Ar jis dingsta, kai jo negalima naudoti?) Ar net kokius veiksmus reikia atlikti paspaudus mygtuką.
Daugelis klientų atsiųs jums tobulas iliustracijas, kurias grafiniame redaktoriuje sukūrė grafikos dizaineris, kuris nėra programuotojas. Tačiau šios iliustracijos nieko nepasako apie animacijas, valdymo būsenas ar net kokius veiksmus reikia atlikti paspaudus mygtuką.Prieš pradėdami rašyti kodą už šių iliustracijų, turėtumėte galėti atsakyti į visus šiuos klausimus. Tiksliau, turėtumėte žinoti:
Jei nuo jūsų priklauso sugeneruoti vartotojo sąsają, kad klientas sutiktų, atlikite tą patį veiksmą atvirkščiai: naudokite vielos rėmo įrankį ir sukurkite visą ekrano išdėstymo rinkinį, įskaitant visus variantus, kuriuos rodiniai rodo skirtingose programos būsenose. Tai gali būti išsamus ir varginantis darbas, tačiau jūs nesigailėsite - tai gali jus sutaupyti nuo naujo daugybės kodų rašymo ir sąsajų atkūrimo dėl nedidelio nesusipratimo, turinčio didelių pasekmių. Jei kuriate dvigubą programą (pvz., Abiem „iPhone“ ir „iPad“), sukurkite atskirus laidinius rėmus abiem.
Ekrano matmenys taip pat yra svarbūs. Yra (rašymo metu) trijų dydžių „iPhone“ ekranai. Atskirų laidų rėmeliai 3,5 ir 4 colių ekranams tikriausiai yra per dideli, tačiau gali tekti juos sukurti; daugeliu atvejų galite tiesiog pakeisti proporcijas.
Jei jūsų klientas jums pateikia grafikos, įsitikinkite, kad jos dydis yra tinkamas, atsižvelgiant į tinkamus formato santykius; morfijavus bet kokį bitmap, kuriame yra teksto ar objektų (pvz., apskritimų), atsiras iškraipymų. Jei jie nesutampa, liepkite klientui juos iš naujo sukurti pritaikius dydžius. Nemanykite, kad galite ištiesti 3,5 colių ekraną į 4 colių pliūpsnį ir tiesiog su juo riedėti.
Pagrindiniai klausimai, kuriuos reikia užduoti paraiškos projekto dokumente:
Apibendrinkite šias idėjas ir būkite kuo išsamesni ir kruopštesni, nes klaidos ar nesusipratimai reiškia kodo perrašymą.
Jūsų specifikacijos šablonas turėtų išdėstyti aiškius etapus. Jei jūsų klientas rašo funkcinės ir vartotojo sąsajos dizainą, vėliau turėtumėte susitarti dėl gairių rinkinio. Kartais tai yra ir atsiskaitymo slenksčiai, tačiau jie bent jau pateikia aiškią metriką link užbaigimo. Tarpiniai tikslai gali būti funkcionalumas ir (arba) komponentai; jie gali būti net atskiros programos, jei koncerte yra daugybė rinkinių. Kai įmanoma, etapų trukmė turėtų būti maždaug vienoda.
Čia išdėstysiu tinkamo projektinio dokumento struktūros pavyzdį. Žinoma, šis šablonas turėtų būti koreguojamas pagal poreikį. Kitą pavyzdį žr Joelio Spolsky pavyzdžio specifikacija , remiantis šį rašymą . Jis prie dokumento priartėja šiek tiek kitaip, tačiau panašios nuotaikos.
koks yra artumo principas
Įtraukite trumpą pastraipą, kurioje aprašomas projektas ir jo numatoma auditorija.
Ką veikia programa padaryti ? Su kokiomis programos būsenomis (aukšto lygio pagrindinių scenarijų aprašymais) susidurs vartotojas?
Pavyzdžiui, jūsų funkcinis aprašymas gali atrodyti taip:
Kiekviename puslapyje įtraukite laidinius rėmus, išsamiai aprašydami:
Čia yra laidų rėmai, susiję su mano naujausia „iOS“ programa „NotifEye“:
Jei jus domina, aš panaudojau šiuos maketus „Balsamiq“ vielinio rėmo įrankis .
Pavyzdžiui, jūsų Vartotojo sąsajos aprašymas gali atrodyti taip:
Kaip aprašyta aukščiau, užbaigimo terminai ir numatomi rezultatai.
Pvz., Jūsų dizaino dokumento šablono etapai gali atrodyti taip:
Nenoriu pasakyti, kad projektavimo etapas bus baigtas, kai jūs ir jūsų klientas susitarsite dėl specifikacijos dokumento. Visada bus detalių, kurių nė vienas iš jūsų nepagalvojote, ir jūs, ir klientas, žiūrėdami į tarpinius rezultatus, susidurs su naujomis idėjomis, dizaino pakeitimais, netikėtais dizaino trūkumais ir neveikiančiais pasiūlymais.
Dizainas tobulės, o pakeitimai turėtų būti užfiksuoti jūsų dokumente. Per savo 25 metų patirtį aš niekada nedirbau projekte, kuriame taip neatsitiko - ir tai apima mano paties programas (t. Y., Kai buvau pats savo klientas). Jau tada sukūriau projektinį dokumentą su išsamiomis specifikacijomis ir prireikus jį pakoregavau.
Visų pirma palaikykite ryšį. Bent kelis kartus per savaitę susisiekite su savo klientu, praneškite apie savo pažangą, paprašykite paaiškinimo ir įsitikinkite, kad turite vienodų vizijų. Pabandykite užtikrinti, kad jūs ir jūsų klientas tai atliktų kaip lakmuso popierėlį tas pats atsakymai į šiuos tris klausimus:
SDD reiškia programinės įrangos projektavimo dokumentą arba programinės įrangos aprašą.
Funkcinio dizaino dokumente aprašomos programinės įrangos gaminio galimybės, išvaizda ir funkcijos, kurias jis turi atlikti. Projektavimo dokumentai taip pat vadinami funkcinėmis specifikacijomis arba funkcinių specifikacijų dokumentais (FSD) arba funkcinių reikalavimų specifikacijomis.
Aukšto lygio projektavimo dokumente (HLDD) aprašoma architektūra, naudojama kuriant konkretų programinės įrangos produktą. Paprastai jame pateikiama schema, vaizduojanti numatytą programinės įrangos sistemos struktūrą. Kadangi tai yra aukšto lygio dokumentas, dažnai vartojama netechninė kalba.
Programinės įrangos projektavimo dokumente (SDD) paprastai aprašomas programinės įrangos produkto duomenų dizainas, architektūros dizainas, sąsajos dizainas ir procedūrinis dizainas. SDD turinį ir organizavimą nurodo IEEE 1016 standartas.