Müşteri İletişiminde Sık Yapılan Hatalar: Müşterinizi Nasıl Hayal kırıklığına uğratmamalısınız?

Birisi bir proje talep ettiğinde, bunun çok önemli olduğunu ve üzerinde çalışacağınız ürünle derinden ilgilendiklerini varsaymalıyız. Bu nedenle, bir müşterinin nihai ürün etrafında çok fazla beklenti oluşturmaya bağlı olduğunu ve bu nedenle teslimat söz konusu olduğunda duygusallaşabileceğini varsaymak güvenlidir.

Proje boyunca, bir müşteri teslim edilen bir özellik hakkında çok heyecanlanabilir ve sizi sevebilir ve ertesi gün bir şeyin işe yaramadığını keşfedebilir ve bu sevgi yok olacaktır. Çoğu zaman, bu sadece yanlış giden bir müşteri iletişimi meselesidir.

Uzaktan yazılım geliştirme söz konusu olduğunda başarı için hiçbir reçete olmamasına rağmen, ellerinize bu kadar çok güvenen müşterilerle sağlıklı ve üretken bir ilişki sürdürmek için kaçınılması gereken birkaç şey olduğuna inanıyorum.

Müşterilerle Temel İletişimde Başarısız Olmayın

Müşterilerle, iş arkadaşlarınızla, arkadaşlarınızla veya nezaket göstereceğiniz herhangi bir kişiyle günlük iletişimde yaptığınız gibi iletişim hayal edin.

Eski bir arkadaşınız eve geliyorsa ve birkaç hafta sonra öğlen vakti “eski yerinizde” yerel bir lezzetin tadına varmayı kabul ederseniz, oraya gelir miydiniz? Bu arada irtibatta kalır mısınız, teyit için birkaç gün önceden arar mısınız? Ya da belki onların çok meşgul olduklarını ve sebepsiz yere onları rahatsız etmek istemediklerini düşünürdünüz? Geldiklerinde size haber vermelerini bekler miydiniz?

Konuşacak çok şeyiniz olmadıkça her gün sohbet etmeye devam etmeniz pek olası değildir, ancak nezaket ve pratiklik açısından bir tür iletişim kuracaksınız: Diğer kişinin onları unuttuğunuzu düşünmesini istemezsiniz. , ama kesinlikle iyi bir sebep olmadan şehrin yarısını geçmek istemezsiniz.

Bir noktada, muhtemelen profesyonel iletişiminizde de, uzun süreli ortaklar ve iş arkadaşlarınızla bile benzer durumlar yaşadınız. Bazı projeler, hafif bir öğle yemeğini onaylamak için “her zamanki gibi, öğlen orada görüşürüz” demek gibi minimum iletişimle yürütülür. Bir şey çıksa bile, karşı taraf kesinlikle size haber verecek ve yeniden planlamayı kabul edeceksiniz.

Ancak, yazılım geliştirme dünyasında işler o kadar basit veya doğrusal değildir.

Bir proje üzerinde çalışmaya başlarsanız, özellikle yeni bir müşteriyle uğraşırken, sizden hiç haber alamazlarsa, işiniz ve bağlılığınız hakkında ikinci kez düşünmeye başlayacaklardır. Birkaç hafta sonra kusursuz bir ürünle ortaya çıksanız bile, müşteriler sizin hakkınızda idealden daha az algıya sahip olabilir.

Bazen garip hissetmek zorunda kalsanız da, rapor edecek olağan dışı bir şeyiniz olmasa bile müşteriyle konuşmaktan zarar gelmez! Bir kullanıcı hikayesinin küçük bir noktası hakkında herhangi bir şüpheniz var mı? Bunun önemli olduğunu düşünüyorsanız, onlara bildirin. Biraz geç kaldınız ve üzerinde anlaştığınız tahmini tarihe yetişip yetişemeyeceğinizden emin değil misiniz? Müşteriyi en kısa sürede arayın! Bunu hemen duymaları daha iyi.

Hiç şüpheniz yok ve proje tam zamanında ilerliyor ama müşteri fazla konuşmuyor mu? Neden birkaç günde bir ilerlemenizi açıklayan bir e-posta göndermiyorsunuz? E-postalar kimsenin canını sıkmayacağından herhangi bir zararı olmaz, ayrıca ilerlemenizi belgeleyecek ve müşteriyle düzenli iletişim kuracaksınız.

Kusurlu Müşteri İletişimi Gerçekçi Olmayan Beklentileri Destekliyor

Yani, başlangıçta müşterinin projeyle ilgili çok fazla beklentisi olması gerektiğini belirttim, değil mi? Doğru. Dönem.

Müşteri zaten üründen çok şey bekliyor. Hayal ettikleri gibi gitmezse, müşteriler kaçınılmaz olarak hüsrana uğrayacaktır. Öyleyse, neden birileri yerine getirebileceğinden fazlasını vaat etsin ki, böylece daha da gerçekçi olmayan beklentiler yaratsın?

İşte hızlı bir paralellik: Çevrimiçi bir tablet satın aldınız ve 10 günlük teslimat sözü aldınız. 8. gün mağaza size bir sorun olduğunu söyler ve teslimatı bir hafta geciktirir. Rahatsızlığınızı telafi etmek için perakendeci size 75 $ mağaza kredisi vermeyi vaat ediyor.

Muhtemelen önümüzdeki birkaç gün boyunca o tablete gerçekten ihtiyacın olmadı, bu yüzden bunun iyi bir anlaşma olduğunu düşünüyorsun! Artık tabletin keyfini çıkarabilir, ayrıca mağaza kredisini çocuklarınıza güzel bir şeyler satın almak için kullanabilirsiniz. Ancak ertesi gün mağaza arar ve her şeyin bir gecede çözüldüğünü söyler.

Tableti ertesi gün alacaksınız. Ekstra yok, mağaza kredisi yok. Şimdi hüsrana uğrayan sensin !

"Ne? Daha dün bana daha iyi bir anlaşma yapacağımı söyledin! Adil değil! Çocuklara zaten söyledim..."

Birkaç gün geri sarın ve beklediğiniz tek şey zaten tabletti. Hiç kimse size daha iyi bir anlaşma sözü vermemiş olsaydı, oyuncağınız ertesi gün geldiğinde memnun olurdunuz. Ama şimdi, dükkanın size bildirme kararı dışında iyi bir sebep olmadan kaçırdığınızı hissediyorsunuz.

Geliştiriciler, özellikle serbest çalışanlar, müşterilerle iletişimlerinde benzer durumlardan nasıl kaçınabilir?

Çıldırmayarak ve aklınıza gelen her şeyi ilk etapta söyleyerek. Öneriler yasak değildir; Aslında, istenen belirli bir özelliğin eldeki sorunu çözmek için çok iyi bir seçenek olmadığını düşünüyorsanız çok hoş karşılanırlar. Ama anahtar şudur: Önce düşünün.

• Müşteriyi dinleyin.

• Sorunlarını analiz edin.

• Önerilen çözümü analiz edin.

• Bütçe/program dahilinde olduğundan emin olun.

• Son olarak, devam edin ve önerinizi sunun.

Bu nedenle müşteri iletişim becerileri zor olabilir, çünkü ilk dört adımdan sadece birinde başarısız olmak, zamanınızı ve daha da kötüsü müşterinizin zamanını boşa harcayabileceğiniz anlamına gelir.

Müşterinin Neye İhtiyacı Olduğunu Bildiğinizi Sanmayın

Mary Schmich'in sözleriyle, '17 sınıfından bayanlar ve baylar: Müşteriyi dinleyin. Sana gelecek için tek bir ipucu verebilseydim, o müşteriyi dinlemek olurdu.

Bir projeye çağrıldıysanız, birinin bir şeye ihtiyacı olduğu içindir. Ve bu gerekliliği müşterinizden daha iyi kim bilebilir? Açık görünebilir, ancak bazen gerçek dünyada insanlar bunu unutur.

Sana bir örnek vereyim. Bir perakendeci, işletmesi için bir "yazılım sistemi" ister. Bunu görür görmez, istedikleri şeyin mevcut tüm ürünleri kaydetmek, yapılan her satın alma işlemini kaydetmek, müşteriler için makbuz oluşturmak ve periyodik olarak nelerin satıldığını ve hangi ürünlerin tükenmekte olduğunu raporlamak olduğu sonucuna varırsınız. stok, mevcut.

Bu nedenle, ilk görüşmenizde, verimli olduğunuzu göstermek ve onlara hazırladıklarınızı, önerilen özellikleri, mağazanın görsel kimliğine uygun temel bir tasarım ve daha fazlasını sunmak istiyorsunuz. Ama sonra şaşkın müşteri, aslında ihtiyaçları olan şeyin, belirli markalar ve ürünler için geliri artırmayı amaçlayan ürünleri raflarda daha iyi nasıl gösterebileceklerini hesaplayacak bir algoritma olduğunu söylüyor!

Buradaki hata, çözmeniz gereken sorunu tanımlamamaktı. Tabii ki, bu durumda, projede çok erken olduğu için, düzeltmek için bolca zaman olurdu, ancak bazen bu tür hatalar daha sonra olur. Bir önceki örnek kadar şiddetli olmasa da projeye ve/veya müşteri ile olan ilişkinize zarar verebilir.

Benim önerim şudur: Mümkünse gelecekteki kullanıcılarınızla bol bol konuşun ve projedeki çeşitli paydaşlara danışın. Durum hakkında iyi bir genel bakışa sahip olanlar onlar ve neye ihtiyaçları olduğunu biliyorlar. Her adımda şu anda ne yaptıklarını anlamaya çalışın ve yazılımın nasıl kullanışlı olacağını açıklayın. Söylemeyi seviyorum, bir müşterinin ne istediğini anlamaya çalışırken, amacım neredeyse işini kendim yapabilmek. Bu noktaya yaklaşırsanız, ihtiyaçlarının ne olduğunu gerçekten öğrendiniz.

Müşterinin Ne İstediğini Anlamamak

Eldeki sorunla ilgili bir tür belge almak nadir değildir. Bazen yalnızca üst düzey bir açıklamayken, diğer zamanlarda kullanım durumları ve iş kuralları içeren ayrıntılı bir belgedir. Her durumda, kayıtlar ne kadar net olursa olsun, yapamayacağınız tek şey, orada yazılanların mutlak doğru olduğunu varsaymaktır.

Ne???

Kesinlikle. Birincisi, belirli bir bağlamda birisi için bir şey bir şey ifade edebilir ve o gerçekliğe ait olmayan insanlar için tamamen farklı bir şey ifade edebilir. Ve sizin ve müşterinin ortak noktası olmayan bir şey varsa, o da bağlamdır!

İkincisi, herkes çok yetenekli bir yazar değildir; A demeye çalışıyorlar ama sonunda B'yi tanımlıyorlar.

Peki, size gönderilen her şeyi okuduktan sonra, okuduklarınızın gerçekten kastettikleri şey olduğundan nasıl emin olacaksınız? Her şeyi sindireceksin, bazı notlar alacaksın, her şeyi analiz edeceksin ve... bir toplantı yapacaksın. (Görüyor musunuz? Her şey iletişimle ilgili!) Toplantıda sorun hakkında konuşacak ve ne anladığınızı kendi kelimelerinizle anlatacaksınız. Bu aşamada, muhtemelen herhangi bir yanlış anlaşılmayı tespit edebileceksiniz.

“Ah, ama benim durumumda herhangi bir belge almadım. Sadece müşteriyle oturdum ve bazı notlar alırken bana her şeyi açıkladılar”.

Bunların ne anlama geldiğini anladığınızın hala bir garantisi yok ve önerim hala geçerli: Notlarınızla biraz zaman ayırın, tüm problem hakkında düşünün, her şeyi tercihen bir tür olay zaman çizelgesinde organize edin ve sonra tekrar arayın/buluşmaya başlayın. Müşterinin ne anladığınızı sunması. Size tekrarlayıcı gelebilir, ancak bazen müşteri bile belirli bir görevi gerçekleştirmek için gerekli tüm süreçler hakkında tam bir vizyona sahip olmayabilir ve ardından yazılımın ne kadar karmaşık olması gerektiğini görecektir.

Sonunda, belirsizlik veya yanlış anlama olmadığından emin olmalısınız.

Neden Müşterinin İstediği Her Şeyi Düşünmeden Teslim Etmemelisiniz?

Tamam, artık müşteriyi dinlemeniz ve ne anladığınızı doğrulamanız gerektiğini bildiğinize göre, devam edip sizden istedikleri her şeyi yapabilirsiniz, değil mi?

Yanlış!

Şimdi, sonunda sahip olduğunuz tüm deneyimi kullanabileceğiniz ve kendinize şu soruyu sorabileceğiniz an geldi: Müşterinin sizden istediği, sorununu çözecek mi? Size sordukları şey gerçekten ihtiyaçları olan şey mi?

Cevabın kaç kez "hayır" olduğunu görünce şaşıracaksınız.

Müşterinin istediğini teslim etmeden önce, sorunu analiz etmemiz gerekiyor ve işverenin önerdiği şeye katılmıyorsanız, bunu netleştirmek sizin işiniz ve mesleki sorumluluğunuzdur. Elbette, o zaman, tekliflerinin neden iyi olmadığını düşündüğünüzü ve bu eksiklikleri gidermek için alternatif yaklaşımınızın ne yapacağını açıklamanız gerekir. Bir kez daha, iletişim anahtardır.

Siz ve müşteri makul iseniz, o zaman ya çözümünüze devam edeceksiniz ya da daha iyi bir çözüm bulmak için bir beyin fırtınası oturumu yapacaksınız (fikrinizin herhangi bir nedenle müşteri tarafından kabul edilmemesi durumunda).

Prototip—Kapsamlı Belgeler Yazmayın

Senin ve müvekkilin genellikle aynı bakış açısına sahip olmadığınızı söylemiştim, değil mi? Bu nedenle, onların belgelerini anlamanızı etkilediği gibi, yazılı olarak sunduklarınızı anlamalarını da etkileyecektir. Bu da bir bağlam meselesi.

Yani, bir şekilde (daha yüksek veya daha düşük bir seviyede) geliştirmek üzere olduğumuz şeyi belgelememiz gerektiğine katılıyorum. Ancak herhangi bir görsel öğe olmadan birkaç sayfa metin vermek size pek iyi gelmeyecektir. Müşteri onu okumaktan sıkılacak, dikkatini vermeyi bırakacak ve muhtemelen bu karmaşık iş kurallarıyla ne demek istediğinizi anlayamayacak - ya da tasavvur ettiğinizden tamamen farklı bir şey yorumlayacak.

Müşterinin teknik bir geçmişi yoksa, bu yanlış anlamaların daha da kötü olabileceğini unutmayın.

Tüm bu faktörler aynı sorunlu sonuca yol açabilir: Ürünü teslim ettiğinizde müşteriler şikayet edeceklerdir çünkü muhtemelen düşündükleri gibi olmayacaktır.

İşte önerdiğim şey: Planınızın ne olduğunu çizmek için sadece bir eskiz olsa bile, her zaman prototip yapın. Ve yapmanız gereken tanımlar ne olursa olsun, oradan başlayın. Referanslar yapın ve basit tutmaya çalışın.

Müşteriyi Haklı Olduğunuza İkna Etmek İçin Zaman Kaybetmeyi Durdurun

Neredeyse her geliştiricinin aşağıdaki durumu yaşadığından emin olabilirim: Projenin başında müşteri “Yazılımın arka plan renginin sarı olmasına ihtiyacım var. Kurul tarafından zaten kabul edildi. ” Daha sonra yazılım teslim edildiğinde “Oh, ama arka plan rengi sarı olamaz. Sana yeşil olması gerektiğini söylemiştim!” Şimdi, bununla nasıl başa çıkmalısınız?

Elbette, her durumda, haklı olduğunuzda ve haksız olduğunuzda ısrar etmenin hiçbir faydası olmayacaktır. Bir şey olursa, hem size hem de müşteriye zor anlar yaşatacaktır.

Aynı sayfada olduğunuzdan ve yazılı bir iz bıraktığınızdan emin olmak için müşteriyle iyi bir iletişim kaydına sahip olmak her zaman iyidir. Çoğu zaman, eğer basit bir şeyse, müşteriye "O toplantıda anlaştığımız gibi, sistemin arka planı sarı olacak" diyerek e-posta gönderebilirsiniz. Ve gelecekte, müşteri fikrini değiştirirse, e-postada bahsedilen toplantı nedeniyle bu şekilde yaptığınızı iddia edebilirsiniz, ancak bu değişikliğin gerçekten yapılması gerekiyorsa, fazladan bir x saat boyunca yürütebilirsiniz. (ve bazen fazladan bir x dolar).

Ancak haklı olduğunuzu kanıtlayacak bir şey yoksa, muhtemelen bir karar vermeniz gerekiyor (ve ayrıca öğrenilecek bir ders): Mevcut mimaride bir değişiklik gerektirecek veya diğer özellikleri etkileyecek kadar büyük bir değişiklik mi? Değilse, muhtemelen en iyisi devam etmek, yapmak ve müşteriyi yanınıza almaktır (ancak bir daha olmaması için gözleri sonuna kadar açık). Olursa, müşteriyle konuşmak en iyi çözüm olacaktır; “Nasıl haklı olduğuna” değil, “mevcut sorunu nasıl çözebileceğimize” odaklanan biri.

Her durumda, büyük değişiklikler yapmaktan kaçınmanın en iyi yolu, kısa sürelerde kısa yeni özellikler sunmaktır. Bu nedenle, herhangi bir şeyin değiştirilmesi gerekiyorsa, muhtemelen halihazırda var olanın büyük bir dönüşümü olmayacaktır.

Son Teslim Tarihlerine Ne Zaman Taahhüt Edeceğinizi Bilin

Son olarak, yapabileceğiniz en büyük hatalardan biri, müşterinize projeyi bitirmeniz için bir son tarih vermektir. Ve o hatayı yapman için sana yalvaracaklar!

Elbette, bir müşteri olarak, geçtiğimiz haftalarda (aylarca) tartıştığınız tüm bu güzel özellikleri ne zaman kullanabileceğinizi bilmek istersiniz. Ancak bir proje tanımlı bir ürün olmadığı için geliştirmenin başlangıcından yazılımın kullanıma hazır hale gelmesine kadar pek çok şey olabilir.

Her şeyden önce, tahmin edilemez olanı tahmin edemezsiniz. Beklemediğiniz bir şeyle uğraşmak zorunda kalmanız çok muhtemel. Bu, müşterinin söz verdiği ve zamanında satın alınmayan bir lisans olabilir veya kullanmanız gereken ancak olması gerektiği zaman serbest bırakılmayan başka bir dahili yazılım olabilir veya ortam, başlangıçta kabul edilenden farklı olabilir, veya müşteri (birkaç) özellik hakkında fikrini değiştirdi ve birkaç şeyi yeniden yapmak zorunda kaldınız.

Bunların hiçbiri gerçekten bir geliştiricinin hatası değildir ve bir projenin son tarihini derinden etkileyebilir. Ancak, müşteriyi memnun etmeye istekliysen, her şeyi bir tarihe kadar teslim edeceğine söz verdiysen ve tüm doğru nedenlerle, bunu yapmazsan, garanti edebileceğim bir şey, müşterinin en azından biraz olacağıdır. , hüsrana uğramış. Serbest çalışan biriyseniz, bu Toptal Engineering Blog makalesinde açıklandığı gibi zamanınızı verimli bir şekilde yönetmeniz gerekir. Müşteri ilişkileri yönetiminin de sizin işiniz olduğunu unutmayın.

Bu nedenle, kendinize ve projeye bağlı olana bir iyilik yapın ve en azından onlara her şeyi geliştirmenin ne kadar süreceğine dair bir tahmin verin, ancak her zaman bunun sadece bir tahmin olduğunu ve bir son teslim tarihi olmadığını açıkça belirtin.

Ayrıca, (özellikle zaten bir tahminde bulunduysanız), bir şeyin beklenenden daha uzun sürdüğünü her zaman müşterinize söylemenizi şiddetle öneririm, böylece size yardımcı olmak için harekete geçebilirler!