Standartinis produktas ar individuali sistema: kada rinktis

Jūs perkate CRM, nes pardavimo vadovas nebesusitvarko su užrašais, ir po trijų mėnesių šalia sistemos stovi Excel su trimis kainoraščiais ir aplankas su sąskaitomis, kurias kažkas perrašinėja į apskaitą. Produktas nėra prastesnis už tai, už ką buvo parduotas, nes jis žino klientą, sandorį ir kitą skambutį, bet jis nežino Jūsų proceso, nes šis procesas nebuvo tas, kurį gamintojas kūrė šimtams įmonių, ir šis tarpas yra viso šio straipsnio tema: ar Jūs perkate įrankį savo procesui, ar procesą savo įrankiui, o ne spragą funkcijų sąraše, kurią galima užpildyti vienu pritaikymu. Jei spraga yra jungtis tarp sistemų, kurios jau daro savo darbą, tai nėra argumentas kūrimui: pirmiausia sujungiame tai, kas jau yra.

Standartinis produktas ar individuali programinė įranga: kada ką rinktis, nėra klausimas, kurio mygtukas atrodo modernesnis, ir nėra klausimas, ar Jūs „esate pakankamai dideli, kad kurtumėte patys“. Mūsų atsakymas yra tas pats, kurį esame parašę paslaugos puslapyje: jei Jūsų procesas telpa į standartinį įrankį, rinkitės standartinį įrankį, jis atsieis pigiau, o individuali sistema pagrįsta tada, kai procesas yra Jūsų konkurencinio pranašumo dalis arba gatavi sprendimai reikalauja per daug kompromisų, ir šis sakinys nėra pardavimo triukas, kad paskui vis tiek parduotume kūrimą, o testas, kuriuo prarandame eilutes, kuriose reikėtų parašyti dar vieną CRM, ir pasiliekame tas, kuriose procesas yra konkurencinio pranašumo dalis arba standartiniai įrankiai reikalauja per daug kompromisų.

Šis straipsnis nėra el. parduotuvės platformos palyginimas, nes jį jau esame parašę kitur, ir tai nėra individualios programinės įrangos kainoraštis, nes tokio straipsnio mes neturime ir neturėsime — kainų iš piršto nelaužiame, ir tai taip pat nėra pažadas, kad sava sistema visada laimi. Mes parduodame ir standartinio produkto diegimą, ir kūrimą nuo nulio, ir sąžiningas tekstas prasideda tuo, kad kartais brangiausia paslauga, kurią galime Jums parduoti, yra ta, kurios Jums nereikia, todėl toliau yra riba, pagal kurią šį pasirinkimą galima padaryti, prieš kam nors Jums parduodant sprintą.

Standartinis produktas ar individuali programinė įranga: kada ką rinktis

Rinkitės standartinį produktą, jei procesas į jį telpa, ir užsakykite programinę įrangą, jei procesas yra Jūsų konkurencinis pranašumas arba standartiniai įrankiai reikalauja per daug kompromisų: tai visas atsakymas, o likusi šio straipsnio dalis yra tai, kaip šį sakinį patikrinti pagal konkretų darbą, ne pagal prezentaciją. Palyginimas, kuris prasideda funkcijų lentele, baigiasi dar neprasidėjęs, nes lentelė rodo tai, ką gamintojas yra įvardijęs, ne tai, kas po metų spręs Jūsų kitą pakeitimą.

Neteisingoje pusėje pasekmės nėra simetriškos, nes standartinis įrankis, į kurį Jūs esate įgrūdę savo procesą jėga, tampa prenumerata plius Excel plius žmogus, kuris laiko abu kartu, ir šis žmogus po metų yra brangesnis už bet kurią licenciją, o individuali sistema procesui, kuris jau gyvena apskaitoje, pašto programoje ir standartiniame CRM, yra kūrimas, kurį prižiūrėsite patys, nors rinkoje jį jau prižiūri kažkas kitas. Pirmuoju atveju Jūs esate nusipirkę produktą ir paskui parašę antrą sistemą šalia jo, antruoju esate parašę sistemą ten, kur pakako licencijos, ir abi klaidos kainuoja ilgiau, nei atrodo pasiūlyme.

Šią ribą įvardijame todėl, kad esame matę abu galus per vieną savaitę: įmonę, kuri norėjo „savo HubSpot“, nors jai reikėjo HubSpot, ir įmonę, kuri trejus metus lenkė gatavą ERP aplink savo kainų lentelę ir galiausiai atėjo su ta pačia lentele kaip su nauju projektu, ne todėl, kad „ERP nemoka“, o todėl, kad kompromisų jau buvo daugiau nei konfigūracijos. Nė viena iš šių būsenų nėra blogos valios rezultatas, nes abi prasideda sakiniu „mums reikia sistemos“, kuris dar nėra testas, o testas prasideda tik tada, kai Jūs užrašote procesą viename puslapyje be įrankio pavadinimo ir tada ieškote, kuris įrankis šį puslapį jau daro.

Prieš pirkimą užrašykite, ką sistema turi daryti pirmąją dieną, ko ji negali pamiršti antraisiais metais, ir kas gali tuos antruosius metus keisti be svetimos versijos, nes jei atsakymai telpa į produktą, kurį galima konfigūruoti, rinkitės produktą. Jei klausimas yra katalogas, kainos, užsakymas ir pristatymas el. parduotuvėje, tai parduotuvės testas, ir mes jo neperrašome; jei atsakymai yra procesas, kurio konkurentas negali nusipirkti kaip standartinio įrankio, tada tik tada prasminga kalbėti apie sprintą. Šis straipsnis toliau parduoda šią tvarką, ne įrankį.

Kas yra standartinis produktas ir kas yra individuali programinė įranga

Standartinis produktas yra programinė įranga, kurią kažkas jau yra parašęs daugeliui ir kurią Jūs įsigyjate arba prenumeruojate, kad ją naudotumėte be esminio perdarymo. Viešojo sektoriaus IRT planavime, kurį Lietuvoje koordinuoja Valstybės skaitmeninių sprendimų agentūra, COTS imame kaip gatavą komercinę programinę įrangą, kurią galima įsigyti ir naudoti be esminio pritaikymo, o SaaS — kaip programą, pasiekiamą internetu kaip prenumeruojamą paslaugą. Tai planavimo apibrėžtys, ne prievolė privačiai įmonei, ir čia jas imame kaip jau įvardytus žodžius, ne kaip įstatymą, kuris Jums uždeda valstybinį derinimą.

Individuali programinė įranga yra sistema, kuri rašoma Jūsų procesui, ir tose pačiose gairėse specializuota programinė įranga yra individualiai sukurta programinė įranga konkrečios įstaigos ar srities poreikiams. Mes ją vadiname ir individualia sistema, paslaugos puslapyje — nestandartine sistema, o antraštėje — individualia programine įranga, ir tai nėra trys produktai, o vienas darbas: kodas, kuris prasideda nuo Jūsų proceso, ne nuo gamintojo prielaidos, kas yra klientas, užsakymas ar sąskaita, todėl skirtumas nėra „geresnis“ prieš „prastesnis“, o tai, kas paskui gali šią prielaidą keisti.

Standartinis produktas nėra nepavykęs individualus kūrimas, o individualus kūrimas nėra geresnis CRM, nes WooCommerce yra gatavas el. prekybos produktas, Moodle yra gatava mokymosi platforma, WordPress yra gatava turinio platforma, ir visus tris parduodame kaip diegimą, ne kaip slėptą kūrimą kitu pavadinimu. Laravel nėra produktas šia prasme: tai karkasas, kuriuo rašome individualias sistemas nuo 4.0 versijos 2013 m., ir jis neduoda katalogo, krepšelio ar CRM, kol kažkas jų neparašo, todėl painioti karkasą su produktu reiškia įsivaizduoti, kad „su Laravel“ jau yra atsakymas, nors tai tik būdas atsakymą parašyti.

Trečias dalykas, kuris šioje vietoje paprastai painiojamas, yra prenumerata ir tai, kas lieka Jūsų, nes SaaS reiškia, kad Jūs mokate už naudojimą ir duomenis laiko tiekėjas, neterminuota licencija reiškia, kad esate sumokėję už teisę naudoti versiją, o atnaujinimai dažnai yra atskira eilutė, o individualus kodas, kurį mes perduodame, reiškia, kad pirminis kodas, dokumentacija ir infrastruktūros konfigūracija yra Jūsų. Nė vienoje iš šių eilučių nėra automatinės pergalės, yra tik aiškumas, ką perkate, nes priešingu atveju po metų ginčijatės, ar „sistema yra mūsų“, kai iš tikrųjų yra prenumerata, kurią galima nutraukti.

Testas, kuriuo mes šį pasirinkimą darome

Testas nėra „ar mums patinka šis ekranas“, o tai, ar procesas, kurio Jūs negalite atiduoti konkurentui, telpa į įrankį, kurį konkurentas gali nusipirkti toje pačioje parduotuvėje: jei telpa, įrankis yra teisingas atsakymas, nes bus pigiau ir jį prižiūrės kažkas, kurio vienintelis darbas yra šis įrankis, o jei netelpa, nes kainų lentelė, užsakymo patvirtinimas ar pristatymo sąlygos yra tai, kuo Jūs skiriatės, tada standartinis produktas tampa kompromisu, ir kompromisas čia reiškia, kad procesas pradeda gyventi Excel šalia sistemos.

Antroji to paties testo pusė pernelyg dažnai pamirštama, nes poreikiai dažniau būna bendri nei unikalūs, ir pašto programos nestatome, apskaitos, kuri jau daro tai, ko reikalauja įstatymas, nestatome, ir standartinio pardavimo piltuvėlio, kuriame sandoris yra sandoris, taip pat nestatome. Įstaigos, kurios savo pinigus leidžia pagal rašytinius kriterijus, tą pačią formą yra įvardijusios kitaip: pirmiausia klausia, ar rinkoje jau yra toks dalykas, ir kuria tada, kai prieinami produktai branduolio neapima arba kai tą dalyką reikia valdyti patiems, ir tai nėra privačios įmonės prievolė, ir mes jos tokia nepaverčiame, bet tai ta pati forma, kuria sakome ne kūrimui, kurį galima nupirkti.

Trečioji klaida yra produkto perdarymas, kol jis nebėra produktas, nes konfigūracija lieka palaikomose ribose (laukai, vaidmenys, srautai, kuriuos gamintojas yra numatęs), o pritaikymas, kuris perrašo branduolį, kad procesas „pagaliau tiktų“, praranda būtent tą pranašumą, dėl kurio produktą pirkote: atnaujinimus, dokumentaciją, tai, kad klaidą randa kažkas kitas. Tai esame matę Moodle diegimuose, kur pirmiausia patikriname, ar papildinys jau egzistuoja, ir tik tada rašome savą, ir WordPress svetainėse, kur gatavos temos nededame, nes ji atneša dešimtis funkcijų, kurių Jums nereikia ir kurios tampa saugumo rizika, todėl produktas su svetimu branduoliu nėra individuali sistema, o produktas, iš kurio Jūs esate išėmę gamintojo branduolį.

Šį testą atliekame atradimo (discovery) dirbtuvėse, ne pasiūlymo skaidrėje, nes skaidrėje visada laimi kūrimas, kuris atrodo kaip rūpinimasis Jumis, o dirbtuvėse laimi procesas, kurį galima įvardyti. Jei po dviejų dienų paaiškėja, kad procesas telpa į standartinį įrankį, mes tai sakome, net jei tai reiškia, kad šios savaitės sandoris nėra mūsų nestandartinė sistema, nes straipsnis, kuris visada baigiasi „sukurkime Jums savą“, nėra testas, o pasiūlymas, kuris slepiasi už klausimo.

Kada standartinis produktas yra teisingas atsakymas

Standartinis produktas yra teisingas atsakymas ten, kur procesas jau yra įvardytas veiklos srityje ir Jūs nesate tie, kurie šį pavadinimą išrado, nes el. paštas, apskaita, kuri išrašo sąskaitą taip, kaip reikalauja įstatymas, standartinis pardavimo CRM, mokymosi platforma, kuri registruoja kursą ir įvykdymą, ir maža parduotuvė su viena kaina ir vienu sandėliu yra vietos, kur kūrimas neduoda nieko tokio, už ką vertėtų mokėti skirtumą tarp licencijos ir sprinto. Šių eilučių neparduodame kaip „laikino sprendimo, kol būsite pasirengę tikrajai sistemai“, nes jos ir yra tikrosios sistemos šiems procesams.

Šiuos produktus mes ir parduodame, ir tai nėra slėptas pažadas, kad po metų ateis kūrimas: WordPress lieka turinio platforma su tema, kurią rašome mes, ne su gatava tema iš parduotuvės; mažai parduotuvei su standartiniais procesais patys sakome WooCommerce; Moodle lieka mokymosi platforma, kurią konfigūruojame, migruojame ir apipavidaliname, ne išradinėjame iš naujo. Kainos šioms eilutėms stovi paslaugų puslapiuose ir vienoje vietoje žemiau šiame straipsnyje, kur reikia parodyti, kad individualaus kūrimo apatinė riba nėra automatiškai brangiausia eilutė, ir čia pakanka pasakyti, kad produktas lieka produktu.

Pasekmės, jei šioje vietoje vis tiek užsakote kūrimą, yra ne „geresnė kontrolė“, o priežiūra, kurios Jūs nebesidalijate su tūkstančiais kitų, nes pašto programos saugumo pataisą kažkas išleidžia visiems, o savos pašto programos pataisą išleidžiate Jūs, ir tai skamba kaip laisvė, kol nėra antros nakties, kurioje tenka taisyti tai, ką gamintojas jau yra pataisęs savo produkte. Šią laisvę parduodame ten, kur procesas jos nusipelno, ne ten, kur pakanka licencijos, nes priešingu atveju parduodame Jums darbą, kurį po metų Jūs nekęsite kaip brangų dublikatą.

Todėl sąžiningiausias dalykas, kurį galime pasakyti prieš bet kurią nestandartinę sąmatą, yra sąrašas produktų, kuriuos Jums siūlytume vietoj to: jei procesas yra mokymai, pradėkite nuo Moodle, jei procesas yra turinys, pradėkite nuo WordPress, jei procesas yra maža parduotuvė, pradėkite nuo WooCommerce, ir jei procesas yra sąskaitos ir įstatymo nustatyta apskaita, pradėkite nuo apskaitos, kurią jau turite, ir tik tada klauskite, ar kam nors iš to reikia tapti sava sistema. Šis sąrašas nėra partnerystės sutartis, tai testas, kurį taikome sau.

Kada individuali programinė įranga pagrįsta

Individuali programinė įranga pagrįsta tada, kai procesas yra Jūsų konkurencinio pranašumo dalis arba gatavi sprendimai reikalauja per daug kompromisų, ir procesas gali likti pagalbinis prekės atžvilgiu ir vis tiek būti šio testo dalis, nes testas yra kompromisų skaičius, ne tai, ar Jūs parduodate programinę įrangą. Jei standartinis produktas pradeda reikalauti, kad taptumėte vidutiniu klientu, o vidutinis klientas nėra Jūsų konkurencinis pranašumas, kūrimas pagaliau yra testas, kurį procesas išlaikė, ne noras turėti savą ekraną.

Integracija čia nėra argumentas pati savaime, nes produktai irgi turi sąsajas, ir mes jas prijungiame, o argumentas prasideda tik tada, kai sąsajos nepakanka ir procesas reikalauja, kad tiesa apie likutį, kainą ar būseną gyventų vienoje vietoje, kurią Jūs kontroliuojate. „Sadales tīkls“ žemėlapių portalas, kurį esame sukūrę su Laravel ir Leaflet, rodo atjungimus, laisvą galią ir prijungimo mokestį, ir tai nėra „žemėlapis plius įskiepis“, nes mokestis ir galia yra operatoriaus procesas, ne žemėlapių produkto laukas; „Elektrum“ portale SSO sesija prisijungia prie kiekvienos užklausos, prieš Vue konfigūratoriui piešiant, ir tai nėra „energetikos tema WordPress“, nes sesija yra paslaugos dalis, ne dekoracija.

Spalva, logotipas ir meniu tvarka nėra šis testas, nes juos galima padaryti produkte, ir mes juos darome produkte: Moodle tema su Jūsų palete, WordPress tema be pertekliaus, WooCommerce parduotuvė, kuri atrodo kaip Jūs. Jei vienintelis dalykas, kurio negalima padaryti standartiniame įrankyje, yra „kad atrodytų kaip mes“, Jūs nesate priėję iki individualios programinės įrangos, o iki temos, ir sumaišyti šiuos du dalykus reiškia mokėti už kūrimą ten, kur pakanka dizaino, ir paskui stebėtis, kodėl priežiūra brangi sistemai, kurios vienintelis skirtumas yra spalva.

Mes taip pat nesakome, kad kiekviena veiklos sritis automatiškai reikalauja savos platformos, nes srities pavadinimas nėra testas, o testas yra, ar šios srities procesas Jūsų įmonėje yra tas pats, kurį gamintojas jau yra įdėjęs į paketą, ar tai Jūsų būdas, kaip sritis dirba, ir šio būdo negalima nupirkti šalia. Jei galima nupirkti, pirkite; jei negalima, tada kalba eina apie individualią verslo sistemą, ir tik tada verta kalbėti apie atradimo dirbtuves, ne apie temą.

Trečiasis kelias: produktas su mūsų kodu viršuje

Tarp standartinio produkto ir kūrimo nuo nulio yra trečiasis kelias, kurį mes irgi parduodame ir kurį palyginimai dažniausiai praleidžia: produktas lieka produktu, o viršuje rašome tai, ko produktas nedaro, ir tai nėra „šiek tiek individualios programinės įrangos“, o sprendimas palikti branduolį ten, kur jį prižiūri gamintojas, ir rašyti tik tą sluoksnį, kuris yra Jūsų. „Sadales tīkls“ paslaugų portalas stovi ant October CMS, o skaičiuoklės, kalendoriai ir pranešimas apie gedimą yra darbas ant produkto, ne naujas turinio variklis; Moodle diegime pirmiausia patikriname, ar vertinimo ar ataskaitos papildinys jau egzistuoja, ir tik tada rašome savą, nes priešingu atveju parduodame Jums dublikatą.

Jei klausimas yra katalogas, kainos, užsakymas ir pristatymas, tai parduotuvės testas, ir jis jau parašytas straipsnyje apie WooCommerce ar Laravel pasirinkimą, todėl čia jo neperrašome ir nedarome iš jo nestandartinės sistemos numatytojo. Jei klausimas yra apie CRM, ERP, vidinį skydelį ar srities procesą, likite čia, nes parduotuvė yra vienas to paties testo atvejis, ne viso pasirinkimo turinys.

WordPress pusėje trečiasis kelias atrodo kaip atsisakymas, nes gatavų temų nededame, jos atneša funkcijas, kurios tampa saugumo rizika, ir kuriame švarią temą tik su tuo, ko reikia, ir tai vis tiek yra produktas: redaktorius rašo WordPress redaktoriuje, ne mūsų išrastame, o atnaujinimai ateina iš WordPress, ne iš vieno mūsų leidimo. Skirtumas tarp šito ir individualios sistemos yra tas, kad turinio procesas telpa į produktą, o temos procesas netelpa į ThemeForest temą, ir sumaišyti juos reiškia arba įdėti svetimą temą ir paskui stebėtis įskiepiais, arba kurti savą CMS turiniui, kuriam CMS jau egzistuoja.

Ši riba yra ir vieta, kur sakome ne „nedideliam perdarymui“, kuris po trečio mėnesio yra branduolys, nes jei pritaikymų tampa daugiau nei konfigūracijos, jei kiekvienas atnaujinimas pirmiausia reikalauja mūsų kodo, jei gamintojo laukas nebėra tiesa, Jūs nebesate trečiajame kelyje. Jūs jau esate kūrime, kuris slepiasi už produkto pavadinimo, ir tada sąžiningiau įvardyti kūrimą ir skaičiuoti jį kaip kūrimą, nes priešingu atveju mokate už produktą, kurio nebegalima atnaujinti, ir už sistemą, kurios dar negalima perimti.

Pinigai ir laikas yra forma, ne kainoraštis

Individuali sistema pas mus prasideda nuo 8 000 €, o visas ciklas paprastai trunka nuo 12 iki 32 savaičių, ir tai yra nuo, ne sąskaita, o 12 savaičių nėra tie patys pirmi trys mėnesiai, kuriuose pažadame naudojamą MVP: apatinė riba yra trumpiausias kūrimas, MVP yra žingsnis, po kurio sistema jau naudojama, o 32 savaitės yra didesnio darbo viršutinė riba, kuri telpa ir į tai, ką bendrajame DUK vadiname šešiais–aštuoniais mėnesiais didelei individualiai sistemai. Laravel puslapis prasideda nuo tos pačios 8 000 € apatinės ribos ir 6–24 savaičių, ir tai nėra pigesnė individuali programinė įranga: tai puslapis žmogui, kuris jau žino, kad darbas yra Laravel, ne testas, ar darbas apskritai yra kūrimas.

Šie skaičiai negali tapti sakiniu „individuali programinė įranga yra brangiausias pasirinkimas“, nes Moodle diegimas prasideda nuo 15 000 €, parduotuvės Pro versija kainuoja 9 500 €, ir abu yra virš individualaus kūrimo apatinės ribos, nes vienas yra didelio produkto diegimas, kita — parduotuvė su sandėliu ir B2B kainomis. Lyginti 8 000 € ribą su Moodle riba kaip „kūrimą prieš produktą“ yra neteisinga aritmetika, nes lyginti galima tik to paties proceso du kelius, ir net tada abi pusės yra apatinės ribos, ne sumos; didesniuose nestandartiniuose darbuose skaičiuojame pagal laiko ir sąnaudų modelį su savaitine viršutine riba, nes fiksuota kaina ten paprastai reiškia antkainį rizikai arba ginčą dėl apimties, o valandos įkainis yra 50 €.

Prenumerata prieš kūrimą taip pat nėra formulė, kurioje po N metų viena pusė automatiškai laimi, o viešojo sektoriaus išlaidų planavimas įvardija tai, ką matome ir privačiose sutartyse: SaaS mokestis gali kilti su naudotojų skaičiumi ar indeksavimu, integracijos lieka Jūsų sąnaudos, o tiekėjo keitimui reikia išėjimo plano, nes duomenys stovi pas jį. Tai nėra procentas nuo kūrimo, kurį čia cituotume, nes išnaša už tokių skaičių veda į tiekėjų tinklaraščius, ir tokių skaičių nerašome, bet forma lieka: prenumerata yra eilutė kiekvienais metais, kūrimas yra apatinė riba plius priežiūra, ir nė vienas iš jų nėra be eilutės.

Duomenų aktas, Sąjungoje taikomas nuo 2025 m. rugsėjo 12 d., padeda iškelti eksportuojamus duomenis iš debesijos paslaugos ir draudžia tiekėjui kelti kliūtis keitimui, bet funkcinio lygiavertiškumo jis reikalauja infrastruktūros paslaugai, ne CRM, kurį Jūs tiesiog „perkeliate“, ir reglamentas 2023/2854 nežada, kad procesas persikels kartu su failu. Bendrojo duomenų apsaugos reglamento 20 straipsnis perkelia asmens duomenis, kuriuos subjektas pateikė, ne programą, ne Jūsų konfigūraciją, ne verslo taisykles, todėl jei norite sistemos, kurią galite perkelti pas kitą kūrėją, tai yra pirminis kodas, kurį mes perduodame, ne eksportas iš svetimo skydelio, ir čia baigiasi šis skyrius, nes kitas sakinys jau būtų kainoraštis, kurio šiam klausimui neturime.

Ko mes nesakome, kai kalbame apie individualią programinę įrangą

Nesakome, kad sava sistema visada yra išmintingesnė, kad standartinis produktas yra tiems, kurie „dar neišaugo“, ar kad po trejų metų kūrimas tikrai yra atsipirkęs, nes tokia kreivė be Jūsų proceso yra išgalvojimas. Straipsnis, kuris po sąžiningos pradžios vis tiek prieina prie to, kad reikia pirkti kūrimą, nukrypo per toli, ir tai esame matę pakankamai dažnai, kad čia sustotume, nes sąžiningumas yra apribojimas, o trumpas testas yra tikslas.

Taip pat nesakome, kad Laravel yra atsakymas į standartinio produkto klausimą, nes Laravel yra būdas, kuriuo rašome, kai testas jau davė kūrimą, o parduoti karkasą žmogui, kuriam reikia Moodle, reiškia parduoti plaktuką žmogui, kuriam reikia lentynos. Mūsų Laravel puslapis prasideda nuo 8 000 € ir kalba apie API, eiles ir testus, o šis straipsnis kalba apie tai, ar Jums apskritai reikia to puslapio, ir sumaišyti juos reiškia, kad renkatės įrankį, dar nepasirinkę darbo.

Nesakome ir to, kad atradimo dirbtuvės yra slėptas būdas Jus įvesti į kūrimą, nes dirbtuvių rezultatas yra planas, kuris lieka naudingas net jei nuspręsite mūsų nenaudoti, ir kartais planas sako: rinkitės produktą, kurį jau esate įvardiję, ir mes jį įdiegsime, arba įdiegs kažkas kitas. Jei šis sakinys Jums skamba kaip prarastas sandoris, taip yra todėl, kad tai ir yra prarastas sandoris, ir mes verčiau prarandame kūrimą, kuriame reikėtų parašyti dar vieną CRM, nei gauname klientą, kuris po metų klausia, kodėl jis prižiūri sistemą, kurią galėjo prenumeruoti.

Valstybės pirkimui šis testas neveikia taip pat kaip privačiai įmonei be pritaikymo, nes valstybės planavime pirmiausia klausiama, ar rinkoje jau yra gatavas sprendimas, ir tai priklauso pirkimui, ne šiam sakiniui, o privačioje pusėje priklauso Jūsų procesas ir mūsų kainoraštis. Abi pusės gali prieiti prie to paties atsakymo, ir jos prie jo prieina ne todėl, kad viena būtų kitos įstatymas.

Kaip šį sprendimą priimame pas mus

Darbas prasideda dviejų–trijų dienų atradimo dirbtuvėmis, kuriose kartu su Jūsų komanda aptariame procesus, naudotojų vaidmenis, rizikas ir MVP apimtį, ir tai nėra skaidrių rytas, o darbas, po kurio galime pasakyti, ar procesas telpa į standartinį įrankį, ar jam reikia trečiojo kelio, ar tai kūrimas. Jei atsakymas yra produktas, dirbtuvės atsipirko šiuo sakiniu; jei atsakymas yra kūrimas, kitas žingsnis nėra kodas.

Prieš produkcinį kodą per dvi–tris savaites parengiame spustelėjamą prototipą, nes jame mintis keisti pigiau nei veikiančioje sistemoje, ir prototipas nėra „kad būtų ką rodyti valdybai“, o vieta, kur Jūs matote, kad kainų lentelė, kurią vakar įvardijote, iš tikrųjų yra kita lentelė, ir kur šis atradimas kainuoja dienas, ne mėnesius. Tik tada prasideda kūrimas: pirmaisiais trimis mėnesiais pastatome MVP, kurį galima realiai naudoti, ir toliau plečiame iteratyviai, dviejų savaičių sprintais su demonstracija po kiekvieno.

Pabaigoje Jūs gaunate pirminį kodą, dokumentaciją ir infrastruktūros konfigūraciją ir galite juos perkelti pas kitą kūrėją, ir tai nėra pažadas, kad perkėlimas bus malonus, o pažadas, kad nesate pririšti prie mūsų paskyros. Didesniuose projektuose liekame prie laiko ir sąnaudų modelio su savaitine viršutine riba, o MVP ribą vis tiek fiksuojame, nes priešingu atveju „agile“ tampa žodžiu, už kurio dingsta apimtis, ir jei po dirbtuvių einate kitu keliu, planas lieka Jums, kaip esame parašę paslaugos puslapyje, ir šis straipsnis to nekeičia.

Prieš rašydami mums, užrašykite procesą viename puslapyje be įrankio pavadinimo ir pažymėkite, kurių eilučių negalite atiduoti svetimai versijai: jei puslapis tuščias arba jame tėra „kad būtų sava sistema“, Jums reikia produkto, ir mes tai taip pat pasakysime, o jei puslapyje yra procesas, kurio konkurentas negali nupirkti kaip standartinio įrankio, tada verta kalbėti apie kūrimą. Parašykite mums, jei norite, kad šį puslapį perskaitytume kartu su Jumis ir pasakytume, kuri pusė Jums priklauso, net jei atsakymas yra imti produktą, kurį Jūs jau esate įvardiję.