Kun joku pyytää projektia, meidän on oletettava, että se on erittäin tärkeä ja että hän välittää syvästi tuotteestasi, jolla työskentelet. Joten on turvallista olettaa, että asiakas sitoutuu rakentamaan paljon odotuksia lopputuotteen ympärille ja voi siksi tulla tunnetuksi toimituksen suhteen.
Koko projektin ajan asiakas saattaa innostua toimitetusta ominaisuudesta ja rakastaa sinua, ja seuraavana päivänä hän voi löytää jotain, joka ei toimi, ja kiintymys katoaa. Useimmiten kyse on vain asiakasviestinnästä.
Vaikka menestymisen reseptejä ei ole, kun on kyse ohjelmistojen etäkehitys , Uskon, että on olemassa muutamia asioita on vältettävä ylläpitää terveellistä ja tuottavaa suhdetta asiakkaisiin, jotka luottavat niin paljon sinun käsiisi.
Kuvittele kommunikointia asiakkaiden kanssa samalla tavalla kuin jokapäiväistä kommunikointia työtovereiden, ystävien tai muiden henkilöiden kanssa, joille kohteliasit.
Jos vanha ystäväsi vierailee kotona ja suostut nauttimaan paikallisesta herkusta 'vanhassasi paikassa' keskipäivällä, muutama viikko myöhemmin, näytätkö vain siellä? Pitäisitkö sillä välin yhteyttä, soita vahvistaaksesi muutama päivä etukäteen? Tai ehkä oletat, että he ovat liian kiireisiä eivätkä halua häiritä heitä ilman mitään syytä? Voisitko odottaa heidän ilmoittavan sinulle saapuessaan?
Et todennäköisesti jatka chattailua joka päivä, ellet ole paljon puhua, mutta ylläpidät jonkinlaista viestintää kohteliaisuuden ja käytännöllisyyden vuoksi: et halua toisen henkilön luulevan unohtaneen heitä, mutta et todellakaan halua ajaa puolivälissä kaupunkia hyvä syy.
Jossain vaiheessa olet todennäköisesti kokenut samanlaisia tilanteita myös ammatillisessa viestinnässäsi, jopa pitkäaikaisten kumppaneiden ja työtovereiden kanssa. Jotkut projektit toteutetaan mahdollisimman vähäisellä viestinnällä, aivan kuten sanoen 'tavallinen, keskipäivällä, nähdään siellä' kevyen lounaan vahvistamiseksi. Vaikka jotain tulee esiin, toinen osapuoli ilmoittaa asiasta sinulle varmasti, ja suostut siirtämään aikataulua.
Asiat eivät kuitenkaan ole niin yksinkertaisia tai lineaarisia ohjelmistokehityksen maailmassa.
Jos aloitat projektin parissa etenkin silloin, kun olet tekemisissä uuden asiakkaan kanssa, he eivät koskaan kuule sinusta, heillä on toinen ajatus työstäsi ja sitoutumisestasi. Vaikka ilmestyisitkin virheettömän tuotteen kanssa muutaman viikon kuluttua, asiakkailla voi olla jo vähemmän kuin ihanteellinen käsitys sinusta.
Vaikka joskus tuntuu varmasti hankalalta, ei ole haittaa puhua asiakkaan kanssa, vaikka sinulla ei ole mitään tavallista raportoitavaa! Onko sinulla epäilyksiä yhdestä pienestä kohdasta käyttäjäkertomuksessa? Jos pidät sitä tärkeänä, ilmoita heille siitä. Olet myöhässä hieman myöhässä etkä ole varma, pystytkö täyttämään sovitun arvioidun päivämäärän? Soita asiakkaalle ASAP! On parempi, että he kuulevat siitä heti.
Sinulla ei ole epäilyksiä ja projekti on täysin aikataulussa, mutta asiakas ei puhu paljon? Miksi ei vain lähettää sähköpostia, jossa kuvataan edistymisesi muutaman päivän välein? Se ei aiheuta haittaa, koska sähköpostit eivät aiheuta haittaa kenellekään. Lisäksi dokumentoit edistymisesi ja ylläpidät säännöllistä yhteydenpitoa asiakkaan kanssa.
Joten alussa mainitsin, että asiakkaalla on varmasti paljon odotuksia projektista, eikö? Aivan. Aika.
Asiakas odottaa jo paljon tuotteelta. Jos se ei mene niin kuin he kuvittelivat, asiakkaat turhautuvat väistämättä. Joten miksi kukaan lupaa enemmän kuin pystyy toteuttamaan, mikä luo vielä epärealistisempia odotuksia?
Tässä on nopea rinnakkaisuus: Ostit tabletin verkossa ja sinulle luvattiin 10 päivän toimitus. 8. päivänä kauppa kertoo ongelman ja viivästyttää toimitusta viikolla. Jälleenmyyjä lupaa antaa sinulle 75 dollaria myymäläluotoa hyvittääkseen sinulle haitat.
Luultavasti et Todella tarvitset tabletin muutaman päivän ajan muutenkin, joten luulet sen olevan paljon! Nyt voit nauttia tablet-laitteesta ja käyttää kauppahyvitystä ostaaksesi lapsillesi jotain mukavaa. Mutta kauppa soittaa seuraavana päivänä sanoen, että kaikki on järjestetty yön yli.
Saat tabletin seuraavana päivänä. Ei ekstroja, ei myymäläluottoja. Nyt se on sinä se on turhautunut!
'Mitä? Juuri eilen sanoit minulle, että saisin paremman tarjouksen! Tuo ei ole reilua! Kerroin jo lapsille ... '
Kelaa pari päivää taaksepäin ja kaikki odottamasi oli kuitenkin tabletti. Jos kukaan ei olisi luvannut sinulle parempaa sopimusta, olisit ollut tyytyväinen leluasi, kun se saapui seuraavana päivänä. Mutta nyt sinusta tuntuu siltä, että menetät ilman mitään hyvää syytä, paitsi kaupan päätöksen ilmoittaa sinulle.
Kuinka kehittäjät, erityisesti freelancerit, voivat välttää vastaavia tilanteita keskustellessaan asiakkaiden kanssa?
Olemalla hullu ja sanomalla kaikki mitä tulee mieleesi ensinnäkin. Ehdotuksia ei ole kielletty; itse asiassa he ovat erittäin tervetuloa, jos luulet, että tietty pyydetty ominaisuus ei ole kovin hyvä tapa ratkaista ongelmaa. Mutta avain on: Ajattele ensin.
Kuuntele asiakasta.
Analysoi heidän ongelmansa.
Analysoi ehdotettu ratkaisu.
Varmista, että se on budjetin / aikataulun mukaista.
Mene lopuksi eteenpäin ja esitä ehdotuksesi.
Siksi asiakasviestintätaidot voivat olla hankalia, koska epäonnistuminen vain yhdessä ensimmäisistä neljästä vaiheesta tarkoittaa, että saatat tuhlata aikaa ja mikä vielä pahempaa, asiakkaasi aikaa.
Muotoillen Mary Schmich , Hyvät naiset ja herrat luokassa 17: Kuuntele asiakasta. Jos voisin tarjota sinulle vain yhden vinkin tulevaisuutta varten, se olisi asiakkaan kuunteleminen.
Jos sinut kutsuttiin hankkeeseen, se johtuu siitä, että joku tarvitsee jotain. Ja kuka tietää paremmin tarpeesta kuin asiakkaasi? Se voi tuntua itsestään selvältä, mutta joskus tosielämässä ihmiset unohtavat sen.
Annan teille esimerkin. Jälleenmyyjä pyytää yritykselleen 'ohjelmistojärjestelmää'. Heti kun näet sen, päätät, että he haluavat rekisteröidä kaikki saatavilla olevat tuotteet, tallentaa kaikki tehdyt ostot, luoda kuitit asiakkaille ja raportoida siitä, mitä myytiin säännöllisesti ja mistä tuotteista on loppumassa varastossa.
Joten ensimmäisessä tapaamisessasi haluat osoittaa olevasi tehokas ja esitellä heille valmistamasi tuotteet, ehdotetut ominaisuudet, myymälän visuaalisen ilmeen mukaisen perusmallin ja kaiken. Mutta sitten hämmentynyt asiakas sanoo, että itse asiassa he tarvitsevat algoritmin, jolla lasketaan, kuinka tuotteet voidaan paremmin näyttää hyllyillä, ja tavoitteena on kerätä tuloja tietyille tuotemerkeille ja tuotteille!
Virhe tässä ei yksinkertaisesti ollut tunnistaa mikä ongelma sinun piti ratkaista. Tietenkin tässä tapauksessa, koska projektin alkuvaihe oli hyvin varhainen, olisi paljon aikaa sen korjaamiseen, mutta joskus tällainen virhe tapahtuu edelleen. Vaikka se ei voi olla yhtä jyrkkä kuin edellinen esimerkki, se voi silti vahingoittaa projektia ja / tai suhdettasi asiakkaaseen.
Ehdotan: Heillä on hyvä yleiskuva tilanteesta ja he tietävät mitä tarvitsevat. Yritä selvittää, mitä he tällä hetkellä tekevät, joka askeleella, ja selittää, kuinka ohjelmisto olisi kätevä. Haluan sanoa, että kun yritän ymmärtää, mitä asiakas haluaa, tavoitteenani on melkein pystyä suorittamaan työnsä itse. Jos tulet lähelle tätä pistettä, olet todella selvittänyt heidän tarpeet.
Ei ole harvinaista saada jonkinlaista dokumentaatiota käsillä olevasta ongelmasta. Joskus se on vain korkean tason kuvaus, kun taas toisinaan se on yksityiskohtainen asiakirja, jossa on käyttötapauksia ja liiketoimintasääntöjä. Joka tapauksessa, riippumatta siitä, kuinka selkeät tiedot ovat, yksi asia, jota et voi tehdä, on vain olettaa, että kaikki siellä kirjoitettu on absoluuttinen totuus.
Mitä???
Tarkalleen. Ensinnäkin, joku voi merkitä yhtä asiaa tietyssä yhteydessä, ja täysin erilaista ihmisille, jotka eivät kuulu tähän todellisuuteen. Ja jos sinulla ja asiakkaalla ei ole yhteistä, se on konteksti!
Toiseksi kaikki eivät ole kovin ammattitaitoisia kirjailijoita; he yrittävät sanoa A, mutta lopulta kuvaavat B: tä.
Joten kun olet lukenut kaiken, mitä olet lähettänyt, kuinka voit olla varma, että lukemasi on todella sitä, mitä he tarkoittivat? No, sulatat kaiken, teet muistiinpanoja, analysoit kaiken ja… kutsua kokous . (Näetkö? Kyse on vain viestinnästä!) Kokouksessa puhut ongelmasta ja kuvaat ymmärtämäsi omin sanoin. Tässä vaiheessa pystyt todennäköisesti tunnistamaan väärinkäsitykset.
'Voi, mutta minun tapauksessani en saanut mitään asiakirjoja. Istuin vain asiakkaan kanssa ja he selittivät minulle kaiken, kun kirjoitin muistiinpanoja ”.
Ei ole vieläkään mitään takeita siitä, että ymmärrät, mitä he tarkoittivat, ja ehdotukseni pysyy edelleen: Ota aikaa muistiinpanoihisi, mieti koko ongelmaa, järjestä kaikki, mieluiten jonkinlaisella tapahtumien aikajanalla, ja soita / tapaavat sitten uudelleen asiakkaan esittämään mitä ymmärrät. Se saattaa kuulostaa sinulle toistuvalta, mutta joskus edes asiakkaalla ei ole täydellistä näkemystä kaikista prosesseista tietyn tehtävän suorittamiseksi, ja hän näkee sitten kuinka monimutkaisen ohjelmiston on oltava.
Loppujen lopuksi sinun on oltava varma siitä, ettei siinä ole epäselvyyttä tai väärinkäsityksiä.
OK, nyt kun tiedät, että sinun pitäisi kuunnella asiakasta ja vahvistaa ymmärtämäsi, voit vain mennä eteenpäin ja tehdä kaiken, mitä he pyysivät, eikö?
Väärä!
Nyt on hetki, jolloin voit vihdoin käyttää kaikkia kokemuksiasi ja kysyä itseltäsi: Ratkaiseeko heidän ongelmansa se, mitä asiakas kysyi sinulta? Onko mitä he kysyivät sinulta, mitä he todella tarvitsevat?
Olisit yllättynyt nähdessäsi, kuinka monta kertaa vastaus on 'ei'.
Ennen kuin toimitamme vain asiakkaan pyytämän, meidän on analysoitava ongelma ja, jos et ole samaa mieltä työnantajan ehdottaman kanssa, sinun on tehtävä ja ammatillinen vastuu tehdä se selväksi. Tietysti sinun on sen jälkeen selitettävä, miksi heidän mielestään heidän mielestään ei ole hyvä ja mitä vaihtoehtoinen lähestymistapa tekee näiden puutteiden korjaamiseksi. Jälleen kerran viestintä on avain.
Jos sinä ja asiakas olette järkeviä, jatkat joko ratkaisusi tekemistä tai pidät aivoriihi-istunnon keksiäksesi paremman (jos ideasi ei ollut asiakkaalle jostain syystä hyväksyttävä).
Sanoin jo, että sinulla ja asiakkaallasi ei yleensä ole samaa näkökulmaa, eikö? Näin ollen, samalla tavalla kuin se vaikuttaa heidän ymmärrykseen heidän dokumentaatiostaan, se vaikuttaa heidän käsitykseen siitä, mitä toimitat kirjallisesti. Se on myös asiayhteys.
Joten olen samaa mieltä siitä, että jotenkin (ylemmällä tai alemmalla tasolla), meidän on dokumentoitava, mitä aiomme kehittää. Mutta monen sivun tekstin jakaminen ilman visuaalisia elementtejä ei tee sinulle paljon hyvää. Asiakas kyllästyy lukemaan sitä, lakkaa kiinnittämästä huomiota eikä todennäköisesti pysty ymmärtämään, mitä tarkoitat näillä monimutkaisilla liiketoimintasäännöillä - tai he tulkitsevat jotain täysin erilaista kuin olet kuvitellut.
Muista, että nämä väärinkäsitykset voivat olla vielä pahempia, jos asiakkaalla ei ole teknistä taustaa.
Kaikki nämä tekijät voivat johtaa samaan ongelmalliseen lopputulokseen: Asiakkaat valittavat, kun toimitat tuotteen, koska on todennäköistä, että se ei ole heidän mielessään.
Tässä on mitä ehdotan: Aina prototyyppi, vaikka se olisi vain luonnos piirtääksesi suunnitelmasi. Ja mitä määrityksiä sinun on tehtävä, aloita sieltä. Tee viitteitä ja yritä pitää se yksinkertaisena.
Voin melkein olla varma, että jokaisella kehittäjällä on ollut seuraava tilanne: Projektin alussa asiakas sanoo 'Tarvitsen ohjelmiston taustavärin olevan keltainen. Hallitus on jo sopinut siitä. ' Sitten, kun ohjelmisto toimitetaan, he sanovat 'Voi, mutta taustaväri ei voi olla keltainen. Sanoin, että sen oli oltava vihreää! ' Kuinka sinun pitäisi käsitellä tätä?
Varmasti, ei missään tapauksessa ole mitään hyötyä vain vaatia, että olit oikeassa ja he olivat väärässä. Jos jotain, se vain antaa sinulle ja asiakkaalle vaikeaa aikaa.
Aina hyvä pitää hyvät viestinnät asiakkaan kanssa, vain varmistaaksesi, että olet samalla sivulla ja jätät kirjallisen jäljen. Suurimman osan ajasta, jos se on jotain yksinkertaista, voit lähettää sähköpostia asiakkaalle sanomalla: 'Kuten sovimme tuossa kokouksessa, järjestelmän tausta tulee olemaan keltainen.' Ja jos tulevaisuudessa asiakas muuttaa mieltään, voit väittää, että teit niin tällä sähköpostiviestissä mainitun kokouksen takia, mutta jos muokkaus todella on tehtävä, voit suorittaa sen vielä x tunnin ajan (ja joskus ylimääräinen x dollaria).
Mutta jos mikään ei todista, että olit oikeassa, sinulla on todennäköisesti tehtävä päätös (samoin kuin opittava oppi): Onko muutos niin suuri, että se vaatii muutosta nykyisessä arkkitehtuurissa vai vaikuttaako muihin ominaisuuksiin? Jos ei, on luultavasti parasta vain mennä eteenpäin, tehdä se ja saada asiakas puolellesi (mutta silmät auki, jotta se ei toistu). Jos näin tapahtuu, keskustelu asiakkaan kanssa on paras ratkaisu; ei keskity mihinkään 'Kuinka olit oikeassa' mutta edelleen 'Kuinka voimme korjata nykyisen ongelman.'
Joka tapauksessa paras tapa estää suurten muutosten tekeminen on toimittaa lyhyitä uusia ominaisuuksia lyhyessä ajassa. Siksi, jos jotain on muutettava, se ei todennäköisesti ole merkittävä muutos jo olemassa olevaan.
Viimeisenä, mutta ei vähäisimpänä, yksi suurimmista virheistä, joita voit tehdä, on antaa asiakkaalle määräaika, jonka kuluessa projekti on saatettava loppuun. Ja he pyytävät sinua tekemään tuon virheen!
Tietysti haluat asiakkaana tietää, milloin voit käyttää kaikkia niitä hienoja ominaisuuksia, joista olet keskustellut viimeisten viikkojen (kuukausien aikana). Mutta koska projekti ei ole määritelty tuote, paljon voi tapahtua kehityksen aloittamisesta ohjelmiston käyttövalmiuteen.
Ensinnäkin ei voida ennustaa arvaamatonta. On hyvin todennäköistä, että joudut käsittelemään jotain, jota et odottanut. Se voi olla lisenssi, jonka asiakas lupasi ja jota ei ostettu ajoissa, tai jokin muu sisäinen ohjelmisto, jota sinun tarvitsee käyttää, mutta jota ei julkaistu, kun sen olisi pitänyt olla, tai ympäristö oli erilainen kuin alussa sovittu, tai asiakas muutti mieltään (muutamasta) ominaisuudesta ja joudut tekemään uudelleen pari asiaa.
Mikään niistä ei todellakaan ole kehittäjän vika ja voi vaikuttaa syvästi projektin määräaikaan. Mutta jos sinä, halukas miellyttämään asiakasta, lupasit toimittaa kaiken johonkin päivämäärään mennessä ja lopulta, kaikista oikeista syistä, jos et tee niin, voin taata, että asiakas tulee olemaan, ainakin vähän , turhautunut. Jos olet freelancer, sinun on hallittava aikaasi tehokkaasti, kuten tämä ApeeScape Engineering Blog -artikkeli selittää . Älä unohda, että myös asiakassuhteiden hallinta on sinun tehtäväsi.
Joten tee itsellesi ja projektista riippuvaiselle palvelus ja anna ainakin arvio heille, kuinka kauan kestää kaiken kehittäminen, mutta tee aina selväksi, että se on vain arvio eikä määräaika.
Lisäksi suosittelen vahvasti (varsinkin jos olet jo antanut arvion), että kerrot aina asiakkaalle, kun jokin kestää odotettua kauemmin, jotta he voivat toimia auttamaan sinua!
Opi virheistäsi ja keskity ammattimaisen viestinnän ylläpitoon koko ajan. Kysy asiakkailta ja kollegoilta palautetta ja jatka tietysti tällaisten artikkelien lukemista, jos tarvitset muutamia vinkkejä.
Yksinkertaisesti sanottuna mikä tahansa viestintä, joka välittää viestin mahdollisimman pienellä vaivalla, on tehokasta viestintää. Asiakkaat arvostavat ytimekästä, tarkkaa viestintää, eivät hukkaan kuluttavaa aikaa.
Sisäinen viestintä on viestintää projektissa mukana olevien kollegojesi välillä. Tämä artikkeli keskittyy asiakasviestintään, mutta tiimien välinen viestintä yhteistyöhankkeissa on yhtä tärkeää menestyksellesi.
Rauhallisesti ja ammattimaisesti. Heti, kun huomaat, että asiakas voi olla vaikea, tee kaikkesi liikaa kommunikoida, dokumentoida kaikki ja estää mahdolliset riidat. Ennaltaehkäisy on paras toimintatapasi.