Friday, December 26, 2008

Võlglastest

Täna oli mul mõtlemapanev kohtumine ühe alustava tarkvara firma esindajatega. Nad olid teinud mitmekuise arendusprojekti ühele hindade võrdlemisega tegelevale portaalile. Kahjuks aga hakkas klient projekti lõpus välja tooma tarkvaras igasugu puudusi ja nendele viidates ei ole valmis maksma arvet. Küsimus on kümnetes, isegi sadades tuhandetes kroonides. Alustava ettevõtte jaoks on taoline äriline tüng ilmselt suurem probleem kui juba töötavale ärile. Esiteks pole leping juristi poolt väga põhjalikult läbi töötatud, samuti puudub raha, aeg ja kogemus taoliste probleemide lahendamisel... või siis äärmisel juhul ka kahjumi alla neelamisel.

Kuidas selliseid probleeme vältida? Kas siin võiks olla võimalus OpenCoffee ümber kogunenud inimestel kogemuste vahetamisel? Vahetame vähemalt kogemust selles kuidas taolist ohtu minimeerida. Kas peaks kuidagi riik aitama? Antud juhul olid abiks ka tublid Tallinna Inkubaatori inimesed. Väga tubli neist! Kas tuleks teha mingi tünga tegijate isikute ja ettevõtete üldrahvuslik mustnimekiri?

(Riigi otsene abi oleks muidugi kohane siis küsida kui riik lõpuks võtab käendada veelgi nõrgema sotsiaalse grupi - üksikemad.)

6 comments:

  1. Hindade võrdlemisega tegelev portaal... hv.ee?

    Praegu oleme oma startupis ühe kliendiga sarnases olukorras. Valus õppetund, põhimõtteliselt. Aga egas midagi. Sai stamplepingule hambad kasvatatud. Tulevikus targem.

    Hinnavõrdlusportaaliga kimpus olevatele tegelastele võiks vihjeks öelda, et Eestis seadusandlus on niivõrd keeruline, et ükski firma ei suuda seda 100% järgida. Maksuametile ja BSA'le anonüümsed vihjed ja maksmisest kõrvale hiiliv klient on mitu kuud rivist väljas :)

    ReplyDelete
  2. Kuidas sellist asja vältida? Lepinguga loomulikult.

    Seal on kirjas mõlema poole kohustused ja õigused. Kui leping oli lohakalt tehtud, siis kahjuks tuleb kogu intsident kanda maha kui kallis õppetund ja edasi minna - teha kogetust enda jaoks järeldusi ja vigadest õppida.

    Otstarbekas oleks alustada sellest, et midagi ei hakata tegema enne kui on olemas kasvõi väike ettemaks. Siit edasi on juba suht lihtne tuletada etappide kaupa maksmist, kus lepingus on kokku lepitud tähtajad ja tingimused, millega teatud hulk tööst on vastu võetud. Kui kuskil tekivad tõrked ühel või teisel poolel, siis vähemalt ei tehta asja edasi.

    Praegu annaks probleemi lahendad ehk mõlema osapoolega maha istudes ja välja selgitades, miks maksmist ei toimu. Kui on konkreetsed puudused ja argumendid, siis võib asjaga edasi tegeleda, kuid kui tellija lihtsalt ei taha või saa maksta, siis pole suurt midagi teha. Kohtutee ette võtmist tasub tõsiselt kaaluda, sest ta on pikk ja enamus juhtudel mõttetu aja ja närvide raiskamine. Väga palju oleneb kaasuse detailidest.

    Riigi poolt on paigas juriidiline raamistik, milles kõik tegutsevad, kui sa ei suuda seda ära kasutada, siis äkki on otstarbekas abi paluda. Hiljem kurta, et ei maksta ja riik võiks aidata, on problemaatiline. Moraaliriski tekkimise ohud on liiga kõrged, kui osade ükskõiksust, lohakust või pealiskaudsust hakatakse tagantjärgi siluma.

    Ettevõtlusega kaasnevad omad riskid. Tellija sigadused on üks nendest ja sellega tuleb lihtsalt arvestada. Kui seda teadmist varem polnud, siis elu õpetab.

    Kogu eelneva võib kokkuvõtta ka fraasiga "common sense". Kui ei ole varasemat kokkupuudet inimesega, siis proovi kedagi leida, kes on varem äriliselt sama inimesega kokku puutunud. Info kogumine pole kunagi olnud lihtsam. Eesti ei ole nii suur riik, et siin saaks anonüümselt tegutseda.

    Nimekirjast. Idee on atraktiivne, kuid praktikas kallis ja problemaatiline. Valimatult ja kontrollimatult nimesid sinna lisada ei saa, sest vahel võib väärarusaamast välja kasvada süüdistusi, mis tegelikult tõele ei vasta. Keegi peaks tegelema kontrolliga ja andmete õigsuse eest ka vastutama, kuid see võtab aega ja raha.

    Kõige praktilisemaks lahenduseks jääb jätkuvalt, et mida suurem töö, seda rohkem tasub kontrollida tellija tausta ja jagada tööd etappideks.

    ReplyDelete
  3. Ma arvan ka, et mõistlikuim on töö ja tasumine võimalikult minimaalseteks etappideks lüüa. Ilmselt on siin firma või tegija suurusest tulenev mõistlik piir. Näiteks, et "kui mulle seda raha ära ei maksta, siis ma suudan arveid siiski tasuda". FIE puhul näiteks nädala töö. Väike-ettevõtte puhul ka midagi sarnast. Kahe mehe nädala töö näiteks.

    Kui mul ehitajad korterit remontisid, siis neil oli just selline nädala skeem. See oli tegelikult mõlema poole jaoks hea, sest siis oli ka iganädalaselt põhjust töö üle kontrollida, suhelda ja võimalikud ümbertegemised kohe ära lasta teha.

    Selles mõttes on IT ja programmeerimine ehitamisega üsna sarnane. Alati võib kvaliteedi kallal norida. Kui 100% täpsusega ei ole projektid ja lähteülesanne paigas, siis võib alati pärast viriseda, et tahtsin hoopis teist asja. Aga 100% täpsusega projekteerimine on jälle nii kallis ja aeganõudev, et seda kunagi ei tehta.

    ReplyDelete
  4. Üks lahendus on pakkuda sellist teenust, et klient oleks 100% rahul.

    Kas antud juhul pole probleem mitte selles, et leping halb, vaid hoopis selles, et teenusepakkuja ei mõistnud kliendi soove ja tegi valmis midagi muud, kui mis olid kliendi ootused?

    Isegi kui see antud hetkel nii polnud, siis kahjuks sageli müüakse kliendile Mercedes ja tarnitakse hiljem hoopis Moskvitš. Minul on sellistel juhtudel kliendist (kes pole IT inimene) sageli väga kahju. Ka tema on oma aega ja ressursse raisanud ja sageli on küsitav, kumb osapool peaks selle projekti oma kahjumisse kirjutama.

    Igatahes on sellistel juhtudel väga harva vaid 1 osapool süüdi. Omavaheline kommunikatsioon ja üksteisemõistmine on siin ikka lahenduseks.

    ReplyDelete
  5. @Jüri Saar: ma arvan, et tugev leping on küll kasulik osapoolte kaitseks aga see ei juuri välja probleemi ennast (hetkel siis tõsiasja, et tellijal kas rahast tuli puudu, äriidee nõrk või siis tõepoolest ei ole tehtud tööga rahul).

    Me (~6 inimest) ise kasutame kahe nädalast tsüklit, mille lõpus toimub kliendile demo ja kohene arveldamine. Arveldamine toimub tehtud tundide alusel (kusjuures minu puhul peaaegu minuti täpsusega). Sellised lühitsükklid on ütlemata kasulikud kõigile osapooltele.

    Esiteks on klient ja tegijad omavahel "pundis" ning teavad väga hästi, kus ja kuhu projekt suundub. Toimib tempokas tagaside kõigi osapoolte vahe, seega iga liige saab juba varakult mõjutada projekti suuda niipea kui näeb vajadust.
    Teiseks õpib nii klient kui ka tegijad iga idee/jubina/liigutuse rahalist hinda, mis aitab üllatus-üllatus väga hästi ebaeffektiivsust vähendada.

    Kokkuvõtvalt: ma teen kõik selleks, et ise mitte sattuda vanakooli waterfall projekti. Minu õnneks on ruby/rails ümber hetkel suht palju lahtise peaga tegijaid ning lausa lust on nendega koostööd teha.

    ReplyDelete
  6. Paul Graham kirjutas mõni kuu tagasi essee, mis sobib igasuguse tausta kontrollimise juurde suurepäraselt:

    http://www.paulgraham.com/artistsship.html

    ReplyDelete