Võtame projekti eest täieliku vastutuse: kontseptsioonist arhitektuuri, arenduse, testimise, juurutamise ja jooksva hoolduseni. Üks meeskond, kes vastutab terviku eest, ja standardid, mille järgi ehitatakse, on kirjas, mitte lubatud.
Valmistoode sunnib teid kohanema sellega, mida see oskab; meie ehitame selle järgi, kuidas teie töö päriselt käib. Ja kui valmislahendus teeks sama töö odavamalt, ütleme seda ette — meie huvi ei ole müüa teile projekti, mida te ei vaja.
Katame kogu tsükli ühe meeskonnaga: kontseptsioonist arhitektuuri, arenduse, testimise, juurutamise ja jooksva hoolduseni. Levinud alternatiiv on osta etapid eri kohtadest — disain agentuurist, arendus tarnijalt, käitamine kelleltki kolmandalt — ja see töötab seni, kuni midagi läheb valesti. Siis selgub, et disainer eeldas ühte, arendaja teist ja keegi neist ei vastuta selle eest, mis nende vahele jäi.
Üheksa valdkonda sama meeskonna all. Enamik projekte puudutab neist mitut korraga — ja just seepärast ei ole mõistlik neid eri tarnijatelt osta.
Töötav toode päris kasutajate käes, et kontrollida kõige riskantsemat oletust enne täismahus investeeringut. Esimene tulemus tuleb kahe nädalaga.
Arhitektuur lepitakse kokku enne arendust ja valitakse koormusprofiili järgi, mis teil kolme aasta pärast on. Hilisem ümberkirjutamine on kallim kui esimene otsus.
Veebirakendused, mis töötavad igal ekraanil — serveripoolse renderdusega seal, kus see on nõutav, ja mõõdetud jõudlusega, mitte loodetud jõudlusega.
Natiivne Android ja iOS või üks jagatud koodibaas, koos avaldamise ja platvormimuudatustega kaasas käimisega. Arhitektuur liidestub teie backendi ja ERP/CRM-iga.
Serveripoolsed süsteemid, mis kannavad äriloogikat ja kasvavat koormust. Andmemudel ja liidesed on läbi mõeldud enne, mitte pärast esimest tõrget.
API-d ja vahekihid, mis ühendavad eraldiseisvad süsteemid üheks tervikuks ja kaotavad andmesaared — koos sellega, mis juhtub siis, kui teine pool on maas.
Vana süsteem tänasele platvormile ilma tööd seisma panemata. Funktsioonid liiguvad ükshaaval ja vana töötab kõrval, kuni uus on end tõestanud.
CI/CD, konteinerid ja taristu koodina. Väljalase peab olema rutiin, mitte sündmus, mille jaoks kalendrisse aeg broneeritakse.
Ühik-, integratsiooni- ja otsast-otsani testid koos staatilise analüüsi ja turvakontrolliga. Testid käivad koos koodiga, mitte eraldi faasina lõpus.
Valime tööriistad, mis nende kihtide vahel kokku sobivad, ja eelistame pika toehorisondiga tehnoloogiat uuemale. Järgmine meeskond peab selle jaoks inimesi palkama.
Need ei ole turundusfraasid, vaid kontrollitavad nõuded. Küsige neid iga pakkumise juurde — kui tarnija ei oska öelda, mille järgi ta ehitab, siis ta ei ehita millegi järgi.
Skaleeritavus ja hooldatavus otsustatakse esimeses kuus, mitte siis, kui koormus kasvab.
Turvalisus ei ole faas enne väljalaset, vaid osa igast sprindist — ja seda saab kontrollida.
Testimine ei ole eraldi rida pakkumises. Ilma selleta ei ole see meie meelest valmis tarkvara.
Projekti seis peab olema loetav ilma koosolekuta, ja üleandmine peab olema võimalik ilma meieta.
Tarne käib kuues etapis ja te olete igaühes kaasatud: avastus, kus lepime kokku nõuded, tehnoloogia ja arhitektuuri; disain koos prototüüpide ja API kirjeldustega; arendus kahenädalastes sprintides; testimine koos jõudluse ja turvakontrolliga; juurutamine koos andmemigratsiooni, dokumentatsiooni ja väljaõppega; ning jooksev tugi. Iga etapp lõpeb millegagi käegakatsutavaga, nii et te teate alati, kus projekt seisab.
Koostöö ise käib kolmel moel ja valik sõltub sellest, mis teil juba olemas on. Kui meeskonda ei ole, katame terviku. Kui teil on tootejuht ja oma arendajad, aga käsi jääb lühikeseks, tuleme lisavõimekusena teie protsessi sisse. Ja kui te vajate ainult suunda — kas see idee on üldse tarkvaraprojekt ja mis see maksma läheks — on see eraldi tellitav nõustamine, mis ei kohusta midagi ehitama.
Osa oma tegevusest välisele partnerile usaldada ei ole kerge otsus. Küsige, kes täpselt tööd teeb ja kas te saate temaga rääkida. Küsige, millal hinnang antakse ja millele see tugineb. Ja küsige, kellele kuuluvad repositooriumid ja pilvekontod ning mis juhtub, kui te soovite lahkuda. Kui mõni vastus teile ei sobi, on parem see enne välja selgitada kui pärast.
Ütleme ette, kui valmistoode teeks sama töö odavamalt. Meie huvi ei ole müüa teile projekti, mida te ei vaja.
Inimesed, kellega te vestlusel kohtute, kirjutavad ka koodi. Juuniori tööd vanemarendaja hinnaga me ei müü.
Arhitektuuri-, turva- ja kvaliteedinõuded on dokumenteeritud ja kontrollitavad, mitte pakkumise lubadus. Need on allpool lahti kirjutatud.
Iga sprint lõpeb millegagi, mida saab testkeskkonnas läbi klõpsida. Esimene töötav tulemus tuleb kahe nädalaga.
Kood, disainifailid, repositooriumid ja pilvekontod on teie nimel esimesest commit’ist. Üleandmine on ligipääsu muudatus, mitte migratsiooniprojekt.
Asume Tallinnas, samas ajavööndis ja samas lepinguraamistikus. Andmed jäävad soovi korral täielikult EL-i.
Valmistoode on ehitatud paljudele korraga ja pakub standardset komplekti, mis teenindab laia publikut. Kohandatud tarkvara ehitatakse teie töövoogude, vastavusnõuete ja kasvuplaanide järgi. Valmistoode läheb kiiremini käiku, aga sunnib teie äri kohanema sellega, mida see oskab.
Praktikas taandub vahe neljale asjale. Funktsioonid: valmistootes on palju, mida te kunagi ei kasuta, ja sageli puudub see üks, mida vajate. Liidestused: kohandatud süsteem ühendub teie olemasolevaga otse, valmistoode nõuab sageli kallist vahekihti. Skaleerumine: kohandatud lahendus kasvab teie plaanide järgi, valmistoode võib saada piiranguks. Kogukulu: kohandatud tarkvara nõuab suuremat alginvesteeringut, aga ilma korduvate litsentsitasudeta.
Kui teie protsess ei ole konkurentsieelis ja valmistoode katab vajaduse, soovitame valmistoodet. Seda juhtub sagedamini, kui meie ärimudel eeldaks.
Jah — nii algab enamik projekte. Avastusfaas ongi selleks, et spetsifikatsioon tekiks: kaardistame valdkonna, lepime kokku mahu ja anname arhitektuuri ja eelarve, millega saab planeerida.
Teile, täies ulatuses. Kogu intellektuaalomand, lähtekood ja projekti materjalid kuuluvad teile alates esimesest commit’ist.
Töötame teie repositooriumides ja teie taristukontodel, nii et omandi üleandmiseks ei ole eraldi sammu vaja — see on ligipääsu muudatus. Litsentsipiiranguid ei ole ja lukustust ei teki: te võite koodi muuta, hooldust jätkata ise või anda selle ükskõik millisele teisele partnerile.
Enne töö algust sõlmime NDA, mis katab teie ärisaladused ja protsessid. Koos koodiga antakse üle dokumentatsioon: arhitektuuriotsused, API-kirjeldused, andmemudel ja käitusjuhendid, et teie meeskond saaks süsteemi vajadusel iseseisvalt üleval hoida.
Paljud kliendid jätkavad meiega tugilepinguga, aga see on valik, mitte tingimus.
Kaks võimalust, mõlemad normaalsed: jätkate tugilepinguga, kus me monitoorime ja hooldame, või võtate süsteemi täielikult majja. Teisel juhul kuulub üleandmine ja meeskonna koolitamine projekti hinna sisse.
See sõltub mahust, aga suurusjärgud on olemas. Esimese töötava tulemuse näete kahe nädalaga. Selgepiiriline MVP jõuab kasutajateni tavaliselt kuue nädalaga. Täismahus äritoode, millel on kasutajahaldus, liidestused ja halduspool, on pigem nelja kuni üheksa kuu küsimus. Ettevõttesüsteem, mis peab asendama midagi olemasolevat, on pikem.
Me ei anna tähtaega enne avastusfaasi. Selle tulem ongi tarneplaan, kus iga etapp on eraldi hinnatud ja eraldi otsustatav — nii et te ei pea kogu projekti korraga kinnitama, et esimest osa näha.
Vähem, kui kardetakse, aga mitte üldse ei saa. Vajame ühte otsustajat, kes vastab küsimustele päeva või kahe jooksul, ja umbes tund aega nädalas sprindi ülevaatuseks. Avastusfaasis on koormus suurem — 6–10 tundi võtmeisiku kohta, jaotatuna intervjuudeks.
Millest me päriselt sõltume, on ligipääs inimestele, kes tööd praegu teevad. Enamik valesid eeldusi tuleb sellest, et küsiti juhilt, kuidas protsess käib, aga mitte inimeselt, kes seda igapäevaselt teeb.
Jah, ja teeme seda enne, kui te meile midagi sisulist räägite. Kasutame oma standardset vastastikust NDA-d, mille saame kohe saata, aga allkirjastame sama meelsasti teie oma — tavaliselt ei nõua see läbirääkimisi.
Konfidentsiaalsus kehtib ka ilma eraldi paberita: me ei nimeta kliente ega näita tööd, milleks meil luba ei ole. Kui te lubate hiljem enda nime viidata, on see eraldi ja kirjalik kokkulepe, mitte lepingu peenikeses kirjas.
Kuus etappi, ja te olete igaühes kaasatud. Avastus: töötoad, kus selgitame välja ärivajaduse, lepime kokku nõuded, valime tehnoloogia ja paneme paika arhitektuuri. Disain: UX/UI, prototüübid, disainisüsteem ja API kirjeldused. Arendus: kahenädalased sprindid, mis katavad nii frontendi, backendi, mobiili kui liidestused. Testimine: automaat- ja käsitsitestid, jõudluskontroll ja turvaülevaatus. Juurutamine: toodangukeskkond, andmemigratsioon, väljalase ilma seisakuta, dokumentatsioon ja väljaõpe. Tugi: monitooring, parandused ja edasiarendused.
Igal etapil on käegakatsutav väljund — nõuete dokument, prototüüp, CI/CD toru, testiaruanne, töötav rakendus — nii et te ei pea kunagi küsima, kus projekt seisab.
Hinnang antakse pärast avastusfaasi, mitte enne. Enne seda ei ole kellelgi piisavalt infot ja number, mis siis öeldakse, on müügiargument, mitte hinnang.
Hindamisel arvestame kogu tarneahelat, mitte ainult arendustunde: nõuete analüüs, disain, arendus, testimine, projektijuhtimine, koosolekud ja puhkepäevad. Enamik ületatud eelarveid tuleb sellest, et hinnati ainult koodi kirjutamise aega. Tulem on tarneplaan, kus iga etapp on eraldi hinnatud ja eraldi otsustatav — te ei pea kogu projekti korraga kinnitama.
Koormusprofiili ja meeskonna järgi, mitte moe järgi. Mikroteenused lahendavad organisatsioonilise probleemi — mitu meeskonda, kes tahavad eraldi välja lasta — ja tekitavad vastu tasuks võrgu-, seire- ja andmekooskõla probleeme. Kui teil on üks meeskond, on korralikult tükeldatud monoliit peaaegu alati parem valik, ja selle saab hiljem lahku võtta.
Sündmuspõhist ja olekuta disaini kasutame vaikimisi, sest need lihtsustavad skaleerimist. Mitme kliendi SaaS-i puhul projekteerime andmeeralduse algusest sisse — tagantjärele lisatuna on see üks kallimaid muudatusi, mida teha saab. Iga oluline otsus kirjutatakse ADR-ina lahti koos põhjendusega, et järgmine inimene teaks, miks nii tehti.
Turve on osa igast sprindist, mitte kontroll enne väljalaset. Enne koodi kirjutamist teeme ohumudeldamise: mis võib valesti minna, kes on ründaja ja mida ta tahab. Arenduse ajal jooksevad CI/CD torus staatiline analüüs ja sõltuvuste haavatavuste kontroll, nii et probleem tuleb välja liitmisel, mitte auditil.
Ligipääs on rollipõhine ja vähima õiguse põhimõttel. Krüpteerime nii liikumisel kui salvestatuna, saladused hoiame võtmehoidlas, ja logime, kes mida millal tegi. GDPR-i osas on lähtekoht andmete minimeerimine: kogume ainult seda, mida süsteem päriselt vajab, ja säilituspoliitika on kirjas enne, mitte pärast.
Kood on algusest teie repositooriumis, mitte meie omas — üleandmine on ligipääsu muudatus, mitte migratsiooniprojekt. Koos koodiga antakse üle arhitektuuridokumentatsioon, ADR-id koos otsuste põhjendustega, käitusjuhendid ja tehnilise võla nimekiri.
Taristu on kirjeldatud koodina, nii et keskkonna saab vajadusel nullist üles ehitada ilma, et keegi peaks mäletama, mis seadeid kunagi käsitsi muudeti. Eesmärk on lihtne: teie meeskond või uus tarnija peab saama tööd jätkata ilma meid küsimata.
Jah, ja need kuuluvad sama teenuse alla. Valik natiivse ja jagatud koodibaasi vahel sõltub sellest, mida rakendus teeb: kui suur osa on seadmespetsiifiline — kaamera, taustatöötlus, kaardid — tasub natiivne, ja kui suurem osa on äriloogika ja ekraanid, on üks jagatud koodibaas kiirem ja odavam hooldada.
Mobiilirakendus ei ole eraldi projekt: ta vajab backendi, liidestusi ja sama ligipääsumudelit mis ülejäänud süsteem. Just seepärast on need siin koos — eraldi telliduna jääb kõige rohkem asju just nende kahe vahele. Katame ka avaldamise App Store’is ja Google Plays ning platvormimuudatustega kaasas käimise.
Kirjeldage oma olukorda paari lausega. Vastame ühe tööpäeva jooksul.