Çevik bir projede müşteri / geliştirici kültürü uyumsuzluğu ile başa çıkmak

Çevik ilkelerden biri ...

Sözleşme görüşmesi üzerinden müşteri işbirliği

... bir diğeri ...

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

Ama benim gördüğüm şekilde, en azından müşteri ile etkileşim söz konusu olduğunda, temel bir sorun var:

Müşterinin nasıl düşündüğü bir yazılım mühendisinin düşündüğünden farklı

Bu biraz genelleme olabilir, evet. Muhtemelen orada olan bu mutlaka doğru olmadığı durumlarda iş alanları --- bu seyrek olsa arasındadır. Yine de birçok alanda tipik müşteri:

1. Günlük operasyonel kaygılarla ilgileniyor - kısa menzilli taktikler ... mutlaka strateji değil;
2. Anlaşılır şekilde, sadece acil çözümle ilgilidir;
3. Pratik düşünürler, soyut düşünürler değil;
4. Çözümün gelecekteki endişeleri nasıl destekleyeceğini düşünmekten daha çok "işi yapmak" ile ilgileniyor.

Öte yandan, ideal olarak , çevik çalışan yazılım mühendisleri:

1. Kalite hakkında çok düşünen insanlar;
2. Açık bir şekilde nasıl çalıştığını takdir eden bireyler, çaba sarf ederek bir ton tasarruf sağlayabilir;
3. Deneyimli, analitik düşünürler.

Dolayısıyla, "müşteri işbirliğini" engelleme eğiliminde olan bir kültür tutarsızlığı var gibi görünüyor.

Bu sorunu çözmenin en iyi yolu nedir?

Yine de birçok alanda tipik müşteri:

• Günlük operasyonel kaygılarla ilgileniyorum - kısa menzilli taktikler ... strateji değil;
• Sadece acil çözümle ilgilidir;
• Genellikle tek boyutlu, soyut olmayan düşünürler;
• Öncelikle kalıcı, kaliteli bir çözüm bulmak yerine "işi yapmak" ile ilgileniyor.

Ve açık konuşmak gerekirse, genellikle böyle düşünmek için iyi nedenleri vardır. Her şeyden önce, uzak bir gelecekte değil bugün ve yarın gelir elde etmesi gereken bir iş yürütüyorlar. İkincisi, teknik uzmanlar değiller - neyin mümkün olup neyin olmadığını ve belirli mimari / tasarım / uygulama seçimlerinin sonuçlarının ne olduğunu bilmiyorlar. Bu ne biz biliyoruz.

Bu yüzden cevap - pek şaşırtıcı değil - iletişim .

Çok fazla iletişim kurmanız, birbirinizi eğitmeniz, birbirinizin en azından temel bir bakış açısıyla birbirinizin bakış açısını anlamasını sağlamanız gerekir. Onlara olası alternatiflerin kısa ve uzun vadeli sonuçlarını açıklamanız gerekir. Ve anladıkları dili kullanmanız gerekiyor .

• Derseniz "bu kod daha az okunabilir ve genişletilebilir kılan bir hack, olurdu" , derler, "evet, ne olursa olsun" .
• Derseniz "Bu uzun vadeli geliştirme ve bakım daha masraflı hale ve böcek girme riski artıracak kısa vadeli düzeltme, olurdu" derler "Bir ha en düşünelim" .
• Ve "bu çözüm size 100 $ 'a mal olur, ancak er ya da geç faizle geri ödemek zorunda olduğunuz 500 $' lık teknik borcu tanıtırsanız; OTOH bu diğer çözümün size maliyeti $ 400 ve hiçbir teknik borcu bırakmıyor; "istemek derler, 'Şimdi biz bahsediyoruz!' .

OTOH, bize iş perspektifi hakkında bir iki şey öğretebilirler. İşletmeler kullanılabilir ve yeterince iyi - neredeyse mükemmel - çözümler istiyor. Ve muhtemelen "mükemmel olanın iyinin düşmanı" olduğunu herkesten daha iyi bilirler. Bu nedenle, işimizin teknik olarak mükemmel bir yazılım üretmek yerine müşterilerimizin sorunlarına çözüm sağlamak olduğunu aklınızda bulundurmanız gerekir. Bazen bu ikisi birbirine yaklaşır, ancak daha sık değildir. Bu birçok kişi tarafından üzücü görünebilir, ancak iş gerçekliğidir. Benim için, eğer müşteri sorunumu çözmeyi başarırsam ve bunun hayatlarını gözle görülür bir şekilde kolaylaştırdığını görürsem, onlar kadar mutluyum. OTOH, aklımda olan mükemmel tasarımı uygulamayı başarabildim, ancak şirket ertesi hafta iflas ettiğinde, hiç kimseye bir kazanç değil mi?

Makul bir işletme sahibi - eğer kendi dillerini kullanarak açıklarsanız - yazılımları temiz tutmak, birim testleri yazmak, refactor vb. İçin neden önemlidir? uzun süreli bakım için gereklidir. Ve mantıklı müşteriler, işletmelerinin uzun vadeli sürdürülebilirliğini önemsiyorlar, bu nedenle yatırımlarının yarattığı değeri gördüklerinde kesinlikle yatırım yapmaya hazırlar. Bununla birlikte, hem kaynakları hem de zamanınız sınırlıdır, bu nedenle en önemli şeylere öncelik vermeniz ve odaklanmanız gerekir. Ancak , sadece ikiniz için de önemliyse önemlidir .

A modülünü yeniden incelemek isteyebilirsiniz, çünkü oradaki kod sadece korkunçtur ve az önce okuduğunuz bir tasarım deseni kullanarak kodu özlü, zarif ve temiz olacak şekilde nasıl yeniden düzenleyeceğinize dair muazzam bir fikriniz var. Ancak, bu modüle yıllarca dokunulmadıysa ve güvenilir bir şekilde çalışıyorsa, önümüzdeki hafta çok önemli bir yeni özellikle genişletilecek olan ve tonlarca hata içeren modül B'ye odaklanmanız daha iyi olacaktır. zaten.

Müşterinizin kendilerini nasıl gördüğü:

• En kısa zamanda bitirmem gereken bir projem var
• İşletme ihtiyaçlarımı biliyorum
• Sorunu mevcut iş uygulamalarına zarar vermeyecek bir şekilde çözmem gerekiyor
• Bunu yapmak için sınırlı bir bütçem var.

Öte yandan, grubunuzu şu şekilde görürler:

• Bütçemden para emdiğini alamayan çocuklar.
• İşimizin ihtiyaçlarını anlamıyorum
• İşi uygulamayı zorlaştıracak olsa bile her şeyi yeniden tasarlamak istiyorum.
• Tüm bütçe için fonksiyonel ve etkili olduğunda akıllı kaygan bir çözüm istiyorum.

Birincil sorununuz hiçbirinizin karşı tarafın neye ihtiyacı olduğunu anlamak değildir.

Her şeyden önce, Agile projenizdeki tüm sorunların çözümü değildir.

Müşterinin nasıl düşündüğü, bir yazılım mühendisinin nasıl düşündüğünden temel olarak farklıdır

Evet. Bazen doğrudur. Müşterilerin neyi ve nasıl istediklerini bilmedikleri bir durum bile vardır (yani, gereksinimler açık değildir). Hiç Ne, sen her sürat sonra sonuç almak çevik ise (2 hafta demek) ve müşteri geri bildirim almak için bir fırsat olsun ve aynı sayfada tüm emin olun. Bu, dahili olarak güven oluşturulmasına yardımcı olacak sorunların erken tanımlanmasına ve düzeltilmesine yardımcı olur.

Ayrıca bir deyiş var, kullanıcılar çılgın çocuklar gibidir, bu yüzden silah istediklerinde ve güvenli olmadığını bilirseniz, onları sakinleştirmek için bir oyuncak tabanca vermeyi düşünebilirsiniz .

Bu sorunu çözmenin en iyi yolu nedir?

Daha önce de söylediğim gibi , tüm tez problemlerini çözebilecek sihirli bir sopa yok . Birbirinizin ne yaptığına dair iyi bir anlayış olması için müşterilerinizle daha fazla etkileşim kurmanız gerekir. Site ziyaretini, açık geri bildirimi vb. Tanıtın.

Ürün sahibinizin ve paydaşların sprint demolarına katıldığından ve ürünü geliştirmek için değerli önerilerde bulunduğundan emin olun .

Müşteriden satın alma işleminiz yoksa, Agile neredeyse imkansız olabilir.

Satın alma ile, bir müşteri temsilcisinin haftalık veya aylık zamanının bazı teminat yüzdesini almayı kastediyorum. Bu yüzde, projeye bağlı olarak değişecektir.

Açıkçası onların günlük işleri var, bu yüzden sadece müşteri temsilcisi kendilerine değil, onlara zaman ayırmak onların yönetimine de bağlı.

Bu nedenle, müşteri tarafında yönetimden anlaşma almak bu sorunun anahtarıdır

Çevikliğin, müşterinin günlük standup'lara veya çevikliğin diğer günlük yönlerine dahil olduğu anlamına gelmediğini unutmayın. Çevik, müşteri açısından iletişim ile ilgilidir. Bu, uygulama ayrıntıları hakkında mühendislerle iletişim kurdukları anlamına gelmez.

Müşteriler, sürekli geri bildirim almak ve vermek için ürün sahibiyle işbirliği yapar. Konu özelliklerdir, ancak nasıl uygulandıkları değil. Uygun özellikleri mi sunuyorsunuz? Zamanında mısın? Uyum sağlamanız gereken değişen gereksinimleri var mı?

Agile sizin ve müşterinizin bu soruları yanıtlamasına yardımcı olur.