Kun joku pyytää projektia, meidän on oletettava, että se on erittäin tärkeä ja että he välittävät syvästi tuotteesta, jonka parissa he työskentelevät. Siksi on turvallista olettaa, että asiakas joutuu rakentamaan korkean odotuksen lopputuotteesta ja voi siten tulla tunnetuksi toimituksen suhteen.

Koko projektin ajan asiakas voi tuntea olevansa hyvin innoissaan toimitetusta suorituksesta ja rakastaa sinua, ja seuraavana päivänä he saattavat huomata, että jokin on vialla ja kiintymys katoaa. Suurimman osan ajasta, se on vain kysymys asiakasviestinnästä mennyt pieleen.

Vaikka menestymisen reseptejä ei ole, kun on kyse ohjelmistojen etäkehitys , Mielestäni on joitain asioita tulisi välttää ylläpitää tuottavaa ja terveellistä suhdetta asiakkaisiin, jotka antavat luottamuksen sinun käsiisi.

Ei vikaa perusviestinnässä asiakkaiden kanssa

Kuvittele, että olet yhteydessä asiakkaisiin samalla tavalla kuin olisit päivittäin yhteydessä työtovereihisi, ystäviisi tai muuhun henkilöön, jolle laajennat kohteliaisuuttasi.

Jos vanha ystävä vierailee heidän talossaan ja suostut nauttimaan paikallisesta herkusta 'heidän kotonaan' muutaman viikon kuluttua keskipäivällä, näytätkö vain siellä? Voisitko pitää yhteyttä sillä välin, soittaa vahvistaaksesi muutama päivä ennen? Tai ehkä luulet hänen olevan liian kiireinen etkä halua häiritä häntä ilman mitään syytä? Voisitko odottaa minun ilmoittavan sinulle, kun he saapuvat?

Et todennäköisesti jatka chattailua joka päivä, ellei sinulla ole paljon tietoa, mutta ylläpidät jonkinlaista viestintää, kohteliaisuudesta ja käytännöllisyydestä - et halua toisen henkilön luulevan unohtaneen heitä, mutta varmasti eivät halua ajaa puolivälissä matkalla kaupungin läpi ilman mitään syytä.

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 vähäisellä viestinnällä, kuten sanomalla 'tavallinen, keskipäivällä, näemme sinut siellä' vahvistaaksemme kevyen lounaan. Vaikka jotain tulee esiin, toinen osapuoli ilmoittaa asiasta sinulle varmasti ja suostuu siirtämään sen uudelleen.

Asiat eivät kuitenkaan ole niin yksinkertaisia ​​tai lineaarisia ohjelmistokehityksen maailmassa.

Jos aloitat projektin parissa, varsinkin kun olet tekemisissä uuden asiakkaan kanssa, he eivät koskaan kuule sinusta, he alkavat epäillä työtäsi ja sitoutumistasi. Vaikka ilmestyisitkin virheettömän tuotteen kanssa muutaman viikon kuluttua, asiakkailla voi olla vähemmän kuin ihanteellinen käsitys sinusta.

Vaikka tunnetkin olevasi epämukavaa ajoittain, ei ole haittaa puhua asiakkaalle, vaikka sinulla ei ole mitään epätavallista raportoida. Onko sinulla kysyttävää käyttäjän tarinan pienestä kohdasta? Jos pidät sitä tärkeänä, ilmoita hänelle. Oletko myöhässä hieman myöhässä etkä ole varma, pystytkö täyttämään arvioidun päivämäärän, jonka olet hyväksynyt? Soita asiakkaalle ASAP! Sinun on parempi kuulla se heti.

Sinulla ei ole epäilyksiä ja projekti sopii täydellisesti, 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, ne dokumentoivat myös edistymisesi ja ylläpitävät säännöllistä yhteydenpitoa asiakkaan kanssa.

Huono asiakasviestintä kasvattaa epärealistisia odotuksia

Aluksi mainitsin, että asiakkaalla on varmasti suuria odotuksia projektista, eikö? Sinulla on niitä. kohta.

Asiakas odottaa jo paljon tuotteesta. Jos se ei käy niin kuin he kuvittelivat, asiakkaat turhautuvat väistämättä. Joten miksi joku lupaa enemmän kuin pystyy toteuttamaan, mikä luo vielä epärealistisempia odotuksia?

Tässä on nopea rinnakkaisuus: Ostit tabletin verkossa ja he lupasivat meille 10 päivän toimituksen. Kahdeksantena päivänä kauppa ilmoittaa sinulle ongelmasta ja viivästyttää toimitusta viikossa. Korvaamaan haittoja jälleenmyyjän lupaukset antavat sinulle 75 dollarin myymäläluoton.

Et todennäköisesti tarvitse sitä tablettia seuraavina päivinä, joten luulet sen olevan paljon! Nyt voit nauttia tablet-laitteesta sen lisäksi, että ostat kaupallisten luottojen avulla jotain mukavaa lapsillesi. Mutta kauppa soittaa seuraavana päivänä sanomalla, että kaikki on korjattu yhdessä yössä.

Saat tabletin seuraavana päivänä. Ei ekstroja, ei myymäläluottoja. Nyt olet turhautunut!

'Että? Sanoit vasta eilen, että saisin paremman tarjouksen! Se ei ole reilua! Sanoin jo lapsille ... '

Kelaa pari päivää taaksepäin, ja kaikki odottamasi oli kuitenkin tabletti. Jos kukaan ei olisi luvannut sinulle parempaa tarjousta, olisit tyytyväinen tablet-laitteeseesi, kun se saapui seuraavana päivänä. Mutta nyt sinusta tuntuu siltä, ​​että menetät jotain muuta hyvistä syistä kuin myymälän päätöksestä ilmoittaa sinulle.

Kuinka kehittäjät, erityisesti freelancerit, voivat välttää vastaavia tilanteita keskustellessaan asiakkaiden kanssa?

Olemalla hätkähdyttämätön ja sanomalla kaiken mitä tulee mieleesi. Ehdotuksia ei ole kielletty; Itse asiassa ne ovat erittäin tervetulleita, jos luulet, että tietty pyydetty ominaisuus ei ole kovin hyvä vaihtoehto ongelman ratkaisemiseksi. Mutta avain on: 'Ajattele ensin.'

• Kuuntele asiakasta.

• Analysoi ongelmasi.

• Analysoi ehdotettu ratkaisu.

• Varmista, että se on budjetissa / aikataulussa.

• Mene lopuksi eteenpäin ja lähetä ehdotuksesi.

Siksi asiakasviestintätaidot voivat olla hankalia, koska epäonnistuminen vain yhdessä ensimmäisistä neljästä vaiheesta tarkoittaa, että saatat tuhlata aikaa ja pahempaa asiakkaasi aikaa.

Älä oleta, että tiedät mitä asiakas tarvitsee

Muotoillen Mary Schmich Hyvät naiset ja herrat luokan 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äisi paremmin tästä tarpeesta kuin asiakkaasi? Se saattaa tuntua itsestään selvältä, mutta joskus tosielämässä ihmiset unohtavat sen.

Annan teille esimerkin. Jälleenmyyjä pyytää 'ohjelmistojärjestelmää' liiketoiminnalleen. Heti kun näet sen, tulet siihen tulokseen, että he haluavat tallentaa kaikki saatavilla olevat tuotteet, kirjata kaikki tehdyt ostot, luoda kuitit asiakkaille ja raportoida siitä, mitä myytiin säännöllisesti ja mitkä tuotteet ovat loppumassa. arvot.

Siksi haluat ensimmäisessä kokouksessasi osoittaa, että olet tehokas ja esität heille valmistamasi tuotteet, ehdotetut ominaisuudet, perusmallin, joka sopii myymälän visuaaliseen identiteettiin ja kaikkeen. Mutta sitten hämmentynyt asiakas sanoo, että mitä hän todella tarvitsee, on algoritmi, jolla lasketaan, miten tuotteet voidaan parhaiten näyttää hyllyillä, tavoitteena lisätä tiettyjen tuotemerkkien ja tuotteiden tuloja.

Virhe tässä ei yksinkertaisesti ollut tunnistaa mikä ongelma sinun pitäisi ratkaista. Tietenkin tässä tapauksessa, koska projektin alkuvaihe oli hyvin varhainen, olisi paljon aikaa saada se oikein, mutta joskus tällainen virhe tapahtuu myöhemmin. Vaikka se ei olekaan niin jyrkkä kuin edellinen esimerkki, se voi vahingoittaa projektia ja / tai suhdettasi asiakkaaseen.

Ehdotan, että: puhu tuleville käyttäjillesi, paljon mahdollisuuksien mukaan ja ota yhteyttä projektin eri sidosryhmiin. Heillä on hyvä yleiskuva tilanteesta ja he tietävät mitä tarvitsevat. Yritä selvittää, mitä he tekevät tällä hetkellä, joka askeleella, ja selitä, kuinka ohjelmisto olisi hyödyllinen. Haluan sanoa, että kun yritän ymmärtää, mitä asiakas haluaa, tavoitteenani on melkein pystyä tekemään työ itse. Jos tulet lähelle tätä kohtaa, olet todella selvittänyt, mitä heidän tarpeitaan ovat.

Ei ymmärretä, mitä asiakas pyytää

Ei ole harvinaista saada jonkinlaista dokumentaatiota kyseisestä 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 ei voida tehdä, on yksinkertaisesti olettaa, että kaikki siellä kirjoitettu on absoluuttista totuutta.

Että???

Tarkalleen. Ensinnäkin, joku voi merkitä yhtä asiaa tietyssä kontekstissa ja täysin erilaista ihmisille, jotka eivät kuulu tähän todellisuuteen. Ja jos sinulla ja asiakkaalla ei ole yhteistä asiaa, se on konteksti!

Toiseksi, he eivät kaikki ole kovin ammattitaitoisia kirjailijoita; He yrittävät sanoa A, mutta lopulta kuvaavat B: tä.

Joten kun olet lukenut kaiken, mitä he ovat lähettäneet sinulle, kuinka voit olla varma, että lukemasi on todella se, mitä he halusivat sanoa? No, voit sulattaa kaiken, tehdä muistiinpanoja, analysoida kaiken ja ... kutsua kokous . (Katso? 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ä olet ymmärtänyt, mitä ne tarkoittavat, ja ehdotukseni on edelleen voimassa: vie aikaa muistiinpanoihisi, ajattele koko ongelmaa, järjestä kaikki, mieluiten jonkinlaisella tapahtumien aikataululla, ja soita / tapaa uudelleen asiakkaan kanssa esitelläksesi ymmärtämäsi. Se saattaa kuulostaa sinulle toistuvalta, mutta joskus edes asiakkaalla ei ole täydellistä kuvaa kaikista prosessista, jotka liittyvät tietyn tehtävän suorittamiseen, ja näet kuinka monimutkaisen ohjelmiston on oltava.

Loppujen lopuksi sinun on oltava varma siitä, että ei ole epäselvyyttä tai väärinkäsityksiä.

Miksi sinun ei pitäisi toimittaa kaikkea, mitä asiakas pyytää ajattelematta

Okei, nyt kun tiedät kuunnella asiakasta ja vahvistaa ymmärtämäsi, voit mennä eteenpäin ja tehdä mitä tahansa heiltä kysyvät, eikö?

Väärä!

Nyt on aika, jolloin voit vihdoin käyttää kaikkia kokemuksiasi ja kysyä itseltäsi: Onko asiakas pyytänyt sinua ratkaisemaan? Onko mitä he kysyivät sinulta, mitä he todella tarvitsevat?

Olisit yllättynyt, kuinka monta kertaa vastaus on 'ei'.

Ennen kuin toimitamme vain asiakkaan pyytämät tiedot, 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. Sinun pitäisi tietysti selittää, miksi heidän mielestään heidän ehdotuksensa ei ole hyvä ja mikä on vaihtoehtoinen lähestymistapasi näiden puutteiden korjaamiseksi. Jälleen kerran viestintä on avain.

Jos sinä ja asiakas olette järkeviä, jatka ratkaisuasi tai pidä aivoriihi-istunto löytääksesi paremman (jos ideasi ei jostain syystä ole asiakkaan hyväksymä).

Prototyyppi - Älä kirjoita paljon dokumentaatiota

Sanoin jo, että sinulla ja asiakkaallasi ei yleensä ole samaa näkökulmaa, eikö? Siksi, samoin kuin se vaikuttaa heidän käsitykseen heidän dokumentoinnistaan, se vaikuttaa heidän käsitykseen siitä, mitä toimitat kirjallisesti. Se on asiayhteyden asia.

Joten olen samaa mieltä siitä, että jollakin tavalla (ylemmällä tai alemmalla tasolla) meidän on dokumentoitava, mitä aiomme kehittää. Mutta monen sivun tekstin toimittaminen ilman visuaalia ei tee sinulle paljon hyvää. Asiakas joko kyllästyy lukemaan sitä, lakkaa kiinnittämästä huomiota sinuun eikä todennäköisesti pysty ymmärtämään, mitä tarkoitat niillä monimutkaisilla liiketoimintasäännöillä, tai hän tulkitsee jotain aivan muuta kuin mitä he olivat kuvitelleet.

Muista, että nämä väärinkäsitykset voivat olla vielä pahempia, jos asiakkaalla ei ole teknistä koulutusta.

Kaikki nämä tekijät voivat johtaa samaan hankalaan lopputulokseen - asiakkaat valittavat, kun toimitat tuotteen, koska se ei todennäköisesti ole mielessä.

Tätä ehdotan: Aina prototyyppi, vaikka se olisi vain luonnos piirtääksesi suunnitelmasi. Ja mitä määrittely sinun on tehtävä, aloita sieltä. Tee viitteitä ja yritä pitää se yksinkertaisena.

Lopeta ajanhukkaaminen yrittäessäsi vakuuttaa asiakkaasi, että olet oikeassa

Voin melkein olla varma, että jokainen kehittäjä on kokenut seuraavan tilanteen: Projektin alussa asiakas sanoo ”Tarvitsen ohjelmiston taustavärin keltaiseksi. 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ä?

Itse asiassa se ei missään tapauksessa tee mitään hyvää vaatimalla, että olit oikeassa ja he olivat väärässä. Jos jotain, se antaa sinulle ja asiakkaalle vain vaikeaa aikaa.

On aina hyvä saada hyvä asiakasviestintätieto, vain varmistaaksemme, että olet samalla sivulla ja jätät kirjallisen jäljen. Suurimman osan ajasta, jos se on jotain yksinkertaista, voit lähettää asiakkaalle sähköpostia sanomalla: 'Kuten sovimme kokouksessa, järjestelmän tausta on keltainen.' Ja jos tulevaisuudessa asiakas muuttaa muistiinpanojaan voidakseen väittää tekevänsä sen sähköpostissa mainitun kokouksen takia, mutta jos muokkaus todella on tehtävä, voit suorittaa sen vielä x tunnin ajan ( ja joskus x ylimääräistä dollaria).

Mutta jos mikään ei osoita, että olit oikeassa, sinulla on todennäköisesti tehtävä päätös (oppitunnin lisäksi): Onko muutos niin suuri, että se vaatii muutosta nykyisessä arkkitehtuurissa vai vaikuttaako se muihin ominaisuuksiin ? Jos ei, on luultavasti parasta mennä eteenpäin, tehdä se ja pitää asiakas vieressäsi (mutta silmät auki, jotta se ei toistu). Jos teet niin, keskustelu asiakkaan kanssa on paras ratkaisu; ei keskity 'Kuinka hän oli oikeassa' , mutta sisään 'Kuinka voimme ratkaista nykyisen ongelman' .

Joka tapauksessa paras tapa välttää suurten muutosten tekemistä on toimittaa lyhyitä uusia ominaisuuksia lyhyessä ajassa. Joten jos jotain on muutettava, se ei todennäköisesti ole merkittävä muutos jo olemassa olevaan.

Opi milloin sitoutumaan toimitusaikoihin

Viimeisenä mutta ei vähäisimpänä, yksi suurimmista virheistä, joita voit tehdä, on antaa asiakkaalle määräaika projektin loppuun saattamiseksi. 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 viime viikkojen (kuukausien aikana). Mutta koska projekti ei ole määritelty tuote, kehityksen alusta voi tapahtua paljon, kunnes ohjelmisto on käyttövalmis.

Ensinnäkin, et voi ennustaa arvaamatonta. On hyvin todennäköistä, että joudut käsittelemään jotain, jota et odottanut. Se voi olla lisenssi, jota asiakas ei luvannut, 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 alun perin sovittiin, tai asiakas muutti mieltään. (muutamasta) ominaisuudesta ja piti tehdä uudelleen muutama asia.

Mikään niistä ei todellakaan ole kehittäjän vika ja voi vaikuttaa syvästi projektin aikatauluun. Mutta jos sinä halusi miellyttää asiakasta, lupasit toimittaa kaiken tiettyyn päivämäärään mennessä ja et pääse mihinkään syystä, voin taata, että asiakas on ainakin hieman turhautunut. Jos olet freelancer, sinun on hallittava aikaasi tehokkaasti, kuten on selitetty ApeeScape Dev -blogiartikkeli . Älä unohda, että asiakassuhteiden hallinta on myös sinun tehtäväsi.

Joten, tee itse ja kuka tahansa projekti riippuu palveluksesta, ja ainakin anna heille arvio kuinka kauan kestää kaiken kehittäminen, mutta tee aina selväksi, että se on vain arvio eikä määräaika.

Lisäksi suosittelen voimakkaasti (varsinkin jos olet jo antanut arvion), että kerrot aina asiakkaalle, milloin jokin kestää odotettua kauemmin, jotta he voivat toimia auttamaan sinua.