Techninė užduotis programuotojui: šablonas iš 12 klausimų, po kurio kaina nebesikeičia

„Reikia sistemos, kur klientai galėtų užsisakyti, o mes matytume užsakymus" — tokį aprašymą gauname dažnai. Jis sąžiningas, bet pagal jį galima padaryti ir už 500 €, ir už 15 000 €. Techninė užduotis — tai ne dokumentas programuotojui, o būdas jums pačiam suprasti, ką perkate. Žemiau — dvylika klausimų, kurie tą trijų sakinių aprašymą paverčia dokumentu, pagal kurį kaina ir terminas fiksuojami.

Kodėl trijų sakinių neužtenka

Programuotojas, gavęs neaiškų aprašymą, turi dvi išeitis: paklausti dvidešimt klausimų arba pats nuspręsti. Antras kelias greitesnis — ir brangiausias, nes po mėnesio paaiškėja, kad „užsakymai" reiškė ir sąskaitas, ir pristatymo sekimą, ir tris darbuotojų roles. Kiekvienas „o dar reikėtų" po starto kainuoja 2–3 kartus daugiau nei tas pats dalykas užduotyje.

Dvylika klausimų

Apie tikslą

1. Kokią problemą sprendžiame? Vienas sakinys: „Užsakymus priimame telefonu ir pamirštame; norime, kad klientas užsisakytų pats, o mes gautume pranešimą." Ne „norime modernios sistemos".
2. Kaip matuosime, kad pavyko? Skaičius: „80 % užsakymų ateina per sistemą per 3 mėn.", „administravimo laikas sumažėja nuo 10 iki 3 val./sav.".
3. Kas naudosis? Visos rolės su skaičiais: 2 administratorės, 6 meistrai, ~300 klientų per mėnesį. Kiekviena rolė — atskiras ekranų rinkinys ir atskira kaina.

Apie darbą

1. Kaip tai daroma šiandien? Žingsnis po žingsnio, su įrankiais: „klientas skambina → užrašome popieriniame kalendoriuje → vakare perrašome į Excel → dieną prieš skambiname priminti". Būtent iš šios eilutės programuotojas mato, kas automatizuojama.
2. Ką sistema turi daryti pirmoje versijoje? Sąrašas iš 5–10 veiksmų, kiekvienas prasidedantis veiksmažodžiu: „klientas pasirenka paslaugą ir laiką", „administratorė mato dienos sąrašą", „sistema išsiunčia priminimą dieną prieš".
3. Ko pirmoje versijoje tikrai NEREIKIA? Lygiai taip pat svarbus sąrašas. „Mokėjimų internetu — ne, „lojalumo programos — ne, „mobiliosios aplikacijos — ne." Tai atpigina pirmą versiją perpus ir leidžia paleisti per savaites, ne mėnesius.

Apie duomenis ir sistemas

1. Kokius duomenis saugome? Objektai ir jų laukai paprasta kalba: „klientas — vardas, telefonas, pastabos; užsakymas — paslauga, laikas, kaina, būsena". Asmens duomenys pažymimi atskirai — nuo to priklauso saugykla ir BDAR dalis.
2. Su kuo turi jungtis? Esamos sistemos ir jų vaidmuo: „WordPress svetainė (forma lieka), apskaitos programa (sąskaitos eksportas), Google kalendorius (meistrų grafikai)". Kiekviena integracija — eilutė sąmatoje.
3. Iš kur ateina esami duomenys? Jei turite 2 000 klientų Excel'yje — perkėlimas yra darbas. Jei duomenų nėra — paprasčiau.

Apie ribas

1. Biudžetas ir terminas. Ne „kiek kainuos?", o „turime iki 3 000 € ir norime iki kovo". Programuotojas tada pasiūlys, kas telpa, vietoj to, kad spėliotų. Rėžiai orientacijai: vienas automatizuotas srautas — nuo 150 €, sistema su savo duomenų baze ir rolėmis — nuo 1 500 €; platesnė web sistemų kainų lentelė — paslaugos puslapyje.
2. Kas iš jūsų pusės priima sprendimus? Vienas žmogus, kuris atsako į klausimus per dieną. Projektai, kur sprendimus priima „komanda", trunka dvigubai.
3. Kas bus po paleidimo? Kas prižiūri, kas keičia tekstus, kam skambinti, jei neveikia. Palaikymo tvarka sutariama prieš, ne po.

Vienas lapas, ne dvidešimt

Gera techninė užduotis smulkiam projektui — 1–2 puslapiai. Jei išeina dešimt, projektas per didelis pirmai versijai: grįžkite prie 6-ojo klausimo ir perkelkite pusę į „vėliau".

Pavyzdys: užpildyta per 40 minučių

Autoservisas, 3 meistrai. Problema: registracija telefonu, 15 skambučių per dieną, dvigubos registracijos kartą per savaitę. Sėkmė: pusė registracijų internetu per 2 mėn., dvigubų — 0. Rolės: klientas, administratorė, meistras. Šiandien: skambutis → popierius → vakare į Excel. Pirma versija: klientas renkasi paslaugą, meistrą, laiką; administratorė mato dieną ir keičia; meistras mato savo dieną telefone; sistema siunčia SMS priminimą dieną prieš. Ne pirmoje versijoje: mokėjimai, dalių užsakymas, klientų istorija su nuotraukomis. Duomenys: klientas (vardas, telefonas, automobilis), rezervacija (paslauga, meistras, laikas, būsena). Jungtys: nėra; vėliau — apskaita. Esami duomenys: nėra. Biudžetas: iki 2 500 €, iki vasario. Sprendžia: savininkas, atsako tą pačią dieną. Po paleidimo: tekstai patys, techninė priežiūra — pagal poreikį.

Pagal tokį lapą pasiūlymas tiksliu skaičiumi — kitą dieną.

Ko į užduotį nerašyti

• Technologijų. „Turi būti PHP" arba „norime React" — nebent turite komandą, kuri tai prižiūrės. Technologiją rinkti pagal užduotį — programuotojo darbas.
• Dizaino detalių. „Mygtukas mėlynas, apvalus" — tai sprendžiama su maketais, ne užduotyje. Užtenka: „stilius kaip mūsų svetainėje" arba dviejų pavyzdžių nuorodų.
• „Paprasta", „intuityvi", „moderni". Šie žodžiai nieko nefiksuoja. Vietoj jų — konkretus veiksmas ir laikas: „klientas užsiregistruoja per 3 paspaudimus".

Ką daryti rytoj

Nukopijuokite dvylika klausimų į dokumentą. Atsakykite į pirmus šešis — tai pusė darbo ir užtenka pirmam pokalbiui. Likusius užpildykite kartu su programuotoju: tai geriau nei spėlioti. Jei po 6-ojo klausimo sąrašas „nereikia" trumpesnis už „reikia" — grįžkite ir perkelkite dar bent du punktus.

Dažniausi klausimai

Ar techninę užduotį turi rašyti programuotojas?

Pirmą versiją — jūs: tik jūs žinote, kaip dirbate ir ko norite. Programuotojas ją papildo klausimais ir techninėmis pastabomis. Jei agentūra siūlo užduotį parašyti už jus už atskirą kainą — tai normalu didesniems projektams (nuo kelių tūkstančių), smulkiems — perteklinis žingsnis.

Kas, jei projekto eigoje norėsime pakeisti?

Normalu ir tikėtina. Skirtumas — kad pakeitimas vertinamas atskirai („tai +2 dienos ir +300 €") ir jūs sprendžiate, ar jo verta dabar, ar antroje versijoje. Be užduoties nėra, su kuo palyginti, ir ginčas „tai buvo akivaizdu" neišvengiamas.

Ar užduotis fiksuoja kainą?

Taip — mes kainą ir terminą sutariame pagal ją prieš pradedant, ir ji nesikeičia, jei nesikeičia užduotis. Tai ir yra jos esmė: abi pusės žino, kas bus padaryta.