Bir müşterinin bir projeye katkıda bulunmasına izin vermenin en iyi yolu nedir?

Bir müşteri için bir CRM oluşturuyoruz. Şimdi ilk büyük aşaması bitmiş edilmiş ve müşteri veritabanı şeması ve iş küçük çaplı değişiklikler yapma, işin bazı pick up istiyorum kararlaştırılan ikinci bir ilk aşamasını işler olduğunu biz ikinci inşa ederken .

Bunun hiç pratik olup olmadığına karar veremiyorum, ancak varsayalım, bunu çalışabilir hale getirmek için hangi önlemlerin alınabileceğini düşünüyorum. Şimdiye kadar aldığım şey:

• Şimdiye kadar, müşteri projeyi çoğunlukla kullanıcının bakış açısından görmüştür; açıkça, onu iç işlerle tanıştırdığımız iki bölümlü bir seminer düzenlenmelidir:

  • ilk olarak, mevcut veritabanı şemasını gösterir ve örnek olarak genişletir,
  • daha sonra, bazı örnek kodlar gösterme ve şema geliştirme için yeni bir iş süreci yazma.
• Kod şu anda dahili bir Subversion deposunda bulunur. Üzerinde bir kamu birini veya bir kurmak olabilir iken onun (biz VPN yapabilirsiniz), bir dağıtık sistem daha iyi çalışacak hissetmek ağa. Ancak bu şekilde hisseden tek kişi gibi görünüyorum, bu yüzden iyi ikna edici argümanlar kullanabilirim.

• Nasıl / üretimde çalışan kodun taahhüt emin olmak için emin değilim. Görünüşe göre "x tatile çıkmadan hemen önce kritik, belgelenmemiş bir değişiklik yaptı; şimdi y o zamandan beri meydana gelen bu hatayı anlamaya çalışıyor" felaketler kaçınılmaz. İdeal olarak, dağıtımdan önce tüm değişiklikler:

  • bir sorun izleme sisteminde belgelenmek,
  • önce ayrı bir test ortamında meydana gelir ve
  • otomatik testlerden geçmek zorundadır.

  Ne yazık ki, bunlardan herhangi birinin disiplini hakim olacak.

Bir eklenti mimarisinin veya ayrı bir projenin uygulanabilir seçenekler olmadığını varsayalım, çünkü 1) birincisi yok ve 2) ikincisi müşterinin mevcut koda bakmasını ve muhtemelen değiştireceğini, ısrar etmek.

Bu en az favori cevap olacak - ama yine de burada!

Öyle riskli (acemi yepyeni araba sürmek için izin kadar) - ama kötü bir fikir değildir.

Bunu neden yapmak istediklerini anlayın: yedek kaynaklarının olması değil, sadece kendilerini kontrol altında hissetmelerini sağlamaktır.

Yapmanız gerekenler şunlardır:

1. İstemcinizi eğitin - yazılım bir koddan daha fazlasıdır. Katılmak istiyorlarsa, önce mimari yönleri, tasarımları vb. Gözden geçirmelerine izin verin. Onlara sorular sorun ve önceden yaptıkları seçimlerin sonuçlarını gösterin.

2. Her zaman yaklaşımlarla ilgili pro / eksilerle ilgili seçeneklerle geri dönmelisiniz (ve bu toplantıları iyi belgelendirmelisiniz), ancak bazı karar almalarına izin vermelisiniz. En azından çok fazla şey bilmediklerini anlamaya başlayacaklar - veya kendilerine sahiplenecekler.

3. Dallar gibi ayrı bir alan yaratabilirsiniz, böylece istedikleri her şeyi kodlayabilmeleri gerekir - işler işlemeden veya birleştirilmeden önce uygun şekilde test edilmelidir.

Komplikasyonların olabileceğini bilsem de her sorun bir fırsattır. Her şey yolunda giderse, müşteriniz aslında iç konular hakkında daha fazla takdir görecek ve daha iyi bir güven geliştirecektir çünkü iyi bir iş yaptığınızı (nasıl) biliyorlar!

PS: Size bir fikir vermek için - ben Hindistan'lıyım; ve yönetimin çok fazla ipucu olmadığı birçok BT mağazasını biliyorum. Genellikle müşterinin projenin çöp kutusuna girmemesini sağlamak için ek kaynaklar koyduğunu umursamazlar (hatta mutlu hissederler)! Bu onlar için harika çalışıyor; hepsi bir zihniyetle "Ne derseniz efendim!" Bu, kendi vatandaşımı küçük düşürmek değil, ortak kalkınmanın o kadar da kötü bir fikir olmadığını göstermek . Ne de olsa, birçok yönetim gurusunun tasvir ettiği şey , iş problemlerine " Prosumer yaklaşımı " dır .

Ah ... Doğru fikre sahipsiniz ama bunun ne kadar dağınık olabileceğini gördüm ve her iki taraf da önemli ölçüde acı çekti. Şu anda böyle bir uygulamayı sürdürüyorum.

Müşterinin projeye doğrudan katkıda bulunmayı gerekli görmesinin gerçek nedenlerini öğrenin . Artık projenin gerçekçi bir şekilde ortaya çıkarabileceğinizden daha hızlı yapılmasını istiyorlar mı? Zaten değişiklik istiyorlar mı, ancak spesifikasyon değişiklikleri yapmak veya ek özellikler istemek için sizden ek maliyetler almaktan korkuyorlar mı? Kuruluşlarında iç geliştirme kaynaklarının projede daha fazla kontrol ve girdi istediği veya iç geliştiriciler için yoğun iş aradıkları bir siyasi mücadele var mı? (bu sonuncusu benim için eve yakın vurur)

Gerçek motivasyonlarını bulun ve mümkünse onlara hitap edin. Hatta bunu tavsiye ediyorlar ki büyük bir uyarı işareti, yolun aşağısında sorun yaşanıyor. Böyle bir şeyi kabul etmeden önce gerçek kaygılarını hafifletmeye çalışın, çünkü gerçekleşecek olan şey, projenin kontrolünü güçlü hale getirecek ve sizi aşamalı olarak ortadan kaldıracak veya büyük bir kaosa ve başarısız bir projeye neden olacaklardır.

EDIT: Maalesef bu gemi sizin için yelken açtı, ama henüz umutsuzluğa kapılma. Gelecek olan acıyı büyük ölçüde en aza indirmek için yapabileceğiniz şeyler var. Ne olursa olsun, bunların BİR VE SADECE BİR PROJE MÜDÜRÜ ve ÜRÜN SAHİBİ olduğundan ve bu kişinin kuruluşunuz / şirketinizle ilişkili olduğundan emin olun . Bu kişi sprint planlama, kullanıcı öyküleri ekleme veya kaldırma ve hem şirketinizin hem de müşterinizin şirketindeki kaynaklara görev atama yeteneğine sahip olmalıdır. Ne olursa olsun, lütfen şirketinizdeki geliştirme kaynaklarının müşterilerinizin kaynaklarından ayrı çalışmadığından ve daha da önemlisi ÇALIŞMADIĞINDAN emin olun.şirketinizdeki geliştiricilerin proje yöneticilerine veya ürün sahiplerine rapor vermelerine izin verin! Sözleşmenin kapsamına girmeyen ücretsiz çalışmalardan tam olarak yararlanacaklar veya sizi kendi projenizden uzaklaştıracaklar. Bu bir kesinlik.

Yasal açıdan, "Maden sahasında gözü kapalı bir eşek sürmenin en iyi yolu nedir?"

Programlama açısından, daha fazla bilgi isterim - istemcinin istediği şey, kullanıcı tanımlı bir çeşit EAV sistemi kullanılarak veya sisteme eklenebilen kancalarla uygulanabilir mi? İdeal olarak, çeşitli nedenlerle müşterinin kodunu sizinkinden ayrı tutmak istiyorum.

Buradaki müşterinin rolünde olan biri dürüstçe bu problemi yaşamazdım çünkü bu kadar ileri giderse, kaynak kontrolümde olacaksın, şeyleri test etmek için CI kurulumumu ve KG kurulumumu kullanacaksın. Bu düzenlemenin kurulması oldukça zor olabilir - danışmanlardan çok fazla geri dönüş alıyorum, özellikle işlerin başlamasını sağlıyorum. Sürecin faturalandırılabilir saatlerle etkileşime girdiği anlaşılıyor.

Bence bakış açınız biraz dürüst. Öncelikle, bunun kod tabanınız değil, kod tabanımız olduğunu unutmayın. İkincisi, çoğu durumda, istemci tarafındaki BT mağazası, bu ürünün tasarlandığı gibi çalıştığından ve ileride bakımı, yönetimi ve desteklenmesi kolay olduğundan emin olmak için çok daha fazla motivasyona sahiptir. Hataları düzeltmek için tekrar dalmak, çoğu danışmanın aksine bize faturalandırılamaz saatler değildir . Ayrıca, paranın işlem tarafına da sahip olduğunuzda, işleri kolayca yapılandırılabilir ve öngörülebilir şekillerde başarısız olacak şekilde oluşturmak çok daha önemlidir. Geliştirme ekibinin bir kısmı faturalandırılabilir saatlerle kısıtlanmadığından daha kaliteli bir projeyle sonuçlanabilirsiniz.

Nasıl çalıştıracağı konusunda DCVS kesinlikle gerçekleştirilebiliyorsa gidilecek yoldur. Nötr bir şey (bitbucket, github) seçmek yardımcı olabilir. CI'nin yerinde olması da burada bir nimettir - herkesin son işleyişte boktan çıktığını bildiklerinde işlerden kurtulmak daha zordur. Bazı şeyleri CI aracılığıyla dağıtmaya zorlayabilirseniz - genellikle satıcıları zorlamamız gereken bir şeydir - tüm değişikliklerin yapılmasını gerçekten sağlayabilirsiniz. Eğitim açısından, müşteriyle birkaç gün eşleştirmeyi düşündünüz mü? İhtiyacınız olan yanal bağları kurmak için iyi bir yol olabilir. Genel olarak en iyi bahis, herkesi aynı takımda olduklarına ikna etmektir. Çünkü aynı takımdalar.

Teknik bir sorun olduğu için bu çok bir yönetim meselesi gibi görünüyor. Hem danışmanlık hem de yazılım firmalarında böyle durumlarla başa çıktım. Genel olarak "Müşteri yazılımdan ne kadar değer çıkaracak?" ve "Post-prodüksiyonun sürdürülmesi için ne kadar çabaya ihtiyacım olacak?" bu aslında sizin için iyi bir durum. Birçok müşteri çalışanlarının katılımı konusunda ısrar ediyor. Yine de çok iş alacak.

Sonunu göz önünde bulundurarak, ihtiyacınız olacak iyi bir Çalışma Bildirimi . Bu, kancada ne için olduğunuzu ve kancada ne için olduğunu listeler. Bir Rol ve Sorumluluklar matris ilgilenmektedir her öğeyi, sahibi ve kim sadece bilgilendirilmesi gerekmektedir kim açıklayan az hukuki belgedir. Her ikisi de, her bir görevin ne olduğunu düşük bir seviyede (tahmin etmeye yetecek kadar düşük) listeleyen iyi tanımlanmış bir İş Dağılımı Yapınız olduğunu varsayar .

Yaratılış açısından, bu genellikle ters sıradadır: Kapsam (zaten açık olan) -> WBS (sahip olabileceğiniz) -> Roller ve Sorumluluklar matrisi -> SOW.

Sahipliği açıkça tanımladıktan sonra, kodu ve ortamları yönetmenin zamanı geldi. Kod yönetim araçları konusunda oldukça agnostim. Ne söyleyeceğim çekirdek ekibi dışında biri tarafından yapılan her şey için bir kod inceleme yapmak hayati olduğunu. Kullandığınız araç bunu işaretlerse, daha iyi olur. Birisinin daha önce alınan temel mimari kararlara aykırı bir şey yapmasını önlemek istiyorsunuz. 4 göz kavramı (her şeyi inceleyen 2 ek göz) verebileceğiniz tek önemli taktik karardır.

Ortamları yönetmek de acı vericidir. Genellikle "Çalışmalarımızı çevremiz üzerinde yaparız, işimiz bittiğinde sizinkine gider" ve hem satıcının hem de müşterinin uğraştığı durumlar yaşadım. Durumunuz daha karmaşık geliyor. Proje bitene kadar çevrenizde çalışmalarının bir yolunu bulmayı denemenizi tavsiye ederim. Müşteriyi ortamlarını yönetme konusunda eğitmenin bir yolunu bulabilirseniz (bu konuda iyi olduklarını varsaymayın) o zaman daha iyi.

Birkaç uyarı daha ...

1. Müşterinin ekibinizle aynı üretkenliğe sahip olduğunu varsaymayın. (Etki alanı bilgisi konusunda yukarı doğru sürprizler, yazılımınıza özgü hızda aşağı doğru sürprizler alacaksınız.)

2. Müşteriye metodolojinizi bildiğini varsaymayın.

3. Müşterinin ekibinizin çalışma biçimini paylaştığını varsaymayın. (Yukarı ve aşağı doğru sürprizler gördüm.)

4. Eğitim ve birlikte yerleştirme için çok zaman harcayın.

5. Müşteriye sorun gidermeyi öğretmek için her saat harcaması, gelecekte birçok gün kazandıracaktır.

6. Müşteriyi sizin için kendi iç organizasyonu aracılığıyla çalışmak üzere kullanın ve içerik ve alan adı soruları konusunda uzmanlar bulun.

7. Organizasyonlarını eğitmek için müşteriyi kullanın.

8. Varsayılan olarak, müşterileri geliştirme sürecinize dahil etmek sizi profesyonel bir hizmet firması gibi düşünmeye zorlayacaktır. David Maister konuyla ilgili en iyi kitabı yazdı . Sadece% 20'si sizin için uygun olsa bile, okumaya değer.

Tüm bu uyarılara rağmen, ekiplerinizdeki müşteriler de dahil olmak üzere sizi alıcılarınıza yaklaştırmak için harikalar yaratabilir. Bu istemciler gelecekteki referanslar olma olasılığı en yüksek olanlardır. Bu durumdan en iyi şekilde yararlanmak için iyi şanslar!

Müşterinize kesinlikle her şeyin nasıl kurulduğuna dair bir yol gösterilmelidir, ilk aşamada çıkış için bir gereklilik olmalıydı. Müşterinizin herhangi bir şeyi doğrudan düzenlemesine izin vermeyi geri çekmelisiniz, sorun izleme sisteminize girilen ve işin geri kalanıyla önceliklendirilen bir değişiklik isteği doldurmalıdır. Hangi taleplerin sözleşme kapsamı dışında olduğuna karar vermek size ve müşterinize bağlı olacaktır. Bunun nasıl bir tür değişiklik yönetimi iş akışında / belgesinde tasarlanması gerekir, eğer bir tane yoksa, bir tane oluşturmanızı ve müşterinizin bunun bir şeyi değiştirebileceği ve bunu elde edebileceği süreç olduğunu kabul etmesini şiddetle tavsiye ederim. yazı. Aksi takdirde hiçbir şey yanlış gitmezse dua etmekten başka yapabileceğiniz çok şey yoktur.