Bir Yazılım Projesini Tamamlamak - Uyuşmazlık Çözümü [kapalı]

Bazı Ukraynalı geliştiricilere dış kaynaklı bir projeyi yönetmekle görevlendirildim.

Şirket aracılığıyla işe Elance bir de sabit fiyat . Bu noktada patronum onları idare etmek ve işi halletmek için beni yalnız bıraktı . Yapılması gereken her şeyin ayrıntılı bir belirtimini oluşturdum.

Proje XMPP, RabbitMQ ve Database gibi şeylerle uğraşmayı içeriyordu. Onlarla ilk görüşmemde (her zaman IM) ne yapmaları gerektiğini iyice açıkladım . Anlıyor gibiydiler - ve bunun kolayca yapılabileceğinden çok emindiler.

Çok uzak çok iyi. Fakat bir hafta sonra tekrar karşılaştığımızda, yapılması gerekenler hakkında yanlış anlaşılmalarla doluydu. Geliştiricilerden birine XMPP tanıyıp tanımadığını sorduğumda, onunla ilk kez çalıştığını söyledi. İlk toplantımızda projenin karmaşıklığından ve ilgili teknolojilerden çok bahsetmiştim. Artı, tekrar tekrar onlardan tam olarak NASIL yapacaklarını gösteren fonksiyonel bir özellik yazmalarını istemiştim . Ama HAYIR dediler ve kodu yazmayı tercih ettiler. Tamam dedim.

Proje 3 hafta sonra tamamlandı ve ihtiyaç duyulanları teslim etti. Bu noktada kodu gözden geçirmeye başladım. Çoğunlukla iyiydi, ama bazı önemli sorunlar var:

• bir yapılandırma dosyasına ayrılması gereken bazı şeyleri kodladılar
• Birinde birleştirmem gereken birden fazla yapılandırma dosyası vardı
• kesinlikle HİÇBİR doküman yazmamışlar
• diğer bazı küçük değişiklikler

Onlardan bu değişiklikleri yapmalarını istedim (belgeler hariç) - Ve bir tartışmamız vardı.

Onlar, fiyat sabit olduğundan, çalışma kodunu tamamladıktan sonra herhangi bir değişiklik yapmalarını istemekten haksızlık ettiğimi söylediler. Projede makul olmayan bir süre çalıştıklarını ve şimdi herhangi bir şey istemek tamamen yanlış olduğunu.

Sonunda değişiklikleri yaptılar ve proje bitti. Ama aklımda bazı sorular var ...

• İhtiyaç duydukları şeyi yaptılar ama düzgün bir şekilde yapmam gerekiyordu ve bu yüzden değişiklikler. gerçekten haksız mıydım?

• İşlevsel bir belirtime sahip olmadan kodlamalarına neden izin verdim?

• Neden her şeyi ilk kez anladıklarından emin olamadım?

Kendilerini aynı pozisyonda bulan var mı? Dış kaynaklı projeleri yönetmenin daha iyi bir yolu olduğunu düşünüyor musunuz?

-- GÜNCELLEME --

Tüm görüşler için teşekkürler - tüm deneyime odaklandıktan sonra, sonuçlandırabilirim ...

• Her ne kadar benim tarafımdaki özelliklerde belirsiz olmasam da, kesinlikle önerildiği gibi onları zırhlı yapmadım . Yani götürmek: her zaman olabildiğince spesifik olun - spesifikasyonlarınızı onların bakış açısından da okuyun ve bir şeyleri kaçırıp kaçırmadığınızı görün. En az üç kez tekrarlayın.

• Sadece kodun ne yapması gerektiğini belirtmek yeterli değil. Kodun neye benzemesi gerektiğini belirtmelisiniz. Dizin yapısının ne olacağı; mümkünse dosya adlarını bile. Bu sizi daha sonra çok fazla sıkıntıdan kurtaracaktır. Kodlama yönergelerini, değişken adlandırma kurallarını, dahili dokümantasyon biçimini vb. Kesin olarak belirtin. Bu yönergelere uyduklarını ve çığlık atmadıklarını görün.

• İşlevsel bir özelliği yanlarından talep edin - herhangi bir koddan önce yazılması konusunda ısrar edin. Bu, birçok karışıklığı ve yanlış anlaşılmayı önleyecektir.

• Anormallikleri daha önce tanımlamak ve düzeltmek için geliştirilmekte olan kodu inceleyin. Onlarla her gün en az bir kez konuş.

• Son olarak, onlarla iyi bir ilişki kurmaya çalışın. Çalışmalarını takdir ettiğinizi hissettirin. Onları yönergelerinize uyacak şekilde abartılı bir şekilde zorlamayın; bunun yerine bunu yapmalarını isteyin ve projeyi tamamladıktan sonra kodun sizin için çok daha kolay olmasını sağlayacağını söyleyin.

Öncelikle bu bir itiraz sorunu değil, bir satıcı yönetimi sorunu

Evet, yapılan ALOT hatalardan ...

İhtiyaç duydukları şeyi yaptılar ama düzgün bir şekilde yapmam gerekiyordu ve bu yüzden değişiklikler. gerçekten haksız mıydım?

Evet, bu adil, Belli bir şekilde yapılmasını istiyorsanız, fiyat kabul edilmeden önce söylemeliydiniz, böylece teklif verebilirler.

İşlevsel bir belirtime sahip olmadan kodlamalarına neden izin verdim? Çünkü spec için ÖDEME istemiyordu ! Dokümantasyon zaman alıcı ve pahalıdır, sadece ücretsiz mi yapmalılar?

Neden her şeyi ilk kez anladıklarından emin olamadım?

Anladılar. Ancak , sözleşme imzalandıktan SONRA ilk toplantınızda (ve kabul edilen sabit fiyat) BİZİ KEŞFEDİNİZ! Yani maliyeti (saat) kesmek için gereken her yerde .. Temelde haftada sadece bir toplantı tutarak, herhangi bir confuting seçenekleri vererek.

Bir dahaki sefere bunu nasıl yapacağınız… İki aşamada…

Aşama 1: Gereklilikleri toplayın, sistem analizini gerçekleştirin ve Teknik Tasarım ve \ veya fonksiyonel Spesifikasyonu yazın (Veya kendiniz yazın). Bu Aşama için bir fiyat üzerinde anlaşın. Onlara geliştirme aşaması verme taahhüdü olmadığını açıkladığınızdan emin olun. Fiyata toplantı için zaman ayırdığınızdan emin olun.

Aşama 2: Şimdi (ve siz) sahip oldukları spesifikasyona göre geliştirilenlere teklif vermelerini sağlayın ve çabaların gerçekten dahil olduğunu bilin. Yine fiyata toplantı zamanını eklediğinizden emin olun. Çünkü değişiklikler için küçük bir isteğe bağlı bütçe dahil etmek.

Düzenleme: Ek bir nokta eklemek istiyorum .. Satıcı burada da hatalı, orada bir iş proje yönetimi ile size rehberlik çok yardımcı olduğunu ve süreç kısa geliyor nerede olduğunu size bildirin.

Düzgün yapmam lazım

O zaman dış kaynak kullanmayın, aksi takdirde proje ekibinizde çalıştıklarından ve kod incelemelerine katıldığınızdan emin olun.

Proje 3 hafta sonra tamamlandı ve ihtiyaç duyulanları teslim etti. Bu noktada kodu gözden geçirmeye başladım.

Yine, proje sırasında kodu gözden geçirmiş olmalısınız, sonra değil.

Onlar, fiyat sabit olduğundan, çalışma kodunu tamamladıktan sonra herhangi bir değişiklik yapmalarını istemekten haksızlık ettiğimi söylediler.

Onlara çalışma kodu için sabit fiyat ödediniz. Hata. Bu onların hatası değil, senin. Kontrol ettiğiniz sprintlere katılmak için zaman ayırın ve bu sorunla karşılaşmazsınız. Onlara kod için değil, zaman ve kabul edilen kullanıcı hikayeleri için ödeme yapmalısınız.

Onlarla ilk görüşmemde (her zaman IM) ne yapmaları gerektiğini iyice açıkladım. Anlıyor gibiydiler - ve bunun kolayca yapılabileceğinden çok emindiler.

Tamamen dış kaynaklı bir projeyle uğraşırken, spesifikasyonlarınızın demir kaplı olduğundan emin olmanız gerekir. Birkaç cümleden daha uzun süren herhangi bir şeyi açıklamanız gerekiyorsa, spesifikasyonunuz tam değildir. Bu yüzden şartnameden saptılar.

Geliştiricilerden birine XMPP tanıyıp tanımadığını sorduğumda, onunla ilk kez çalıştığını söyledi.

Popüler düşük maliyetli offshoring ülkelerine dış kaynak kullanımı yaparken, geliştiricilerin sadece işi indirmek için özgeçmişlerini ve becerilerini şişirmeleri yaygındır. Birçoğu, iniş yapana kadar yetenekleri hakkında endişelenmezler, çünkü birçoğu aslında rahat bir yaşam ücreti ödeyen konseri inşa etmeye devam ediyor.

İşlevsel bir belirtime sahip olmadan kodlamalarına neden izin verdim?

Bunu sadece kendiniz cevaplayabilirsiniz, ancak bir dahaki sefere bir öğrenme deneyimi olarak kabul edin.

Şirket bunları sabit bir fiyatla Elance aracılığıyla kiraladı. Bu noktada patronum onları idare etmek ve işi halletmek için beni yalnız bıraktı. Yapılması gereken her şeyin ayrıntılı bir belirtimini oluşturdum.

Yani ikiniz önce bir sözleşme yaptınız ve sonra bir spesifikasyon yazmanıza izin verdiler ve bu spesifikasyonu sözleşmenizin bir parçası olmayı kabul ettiler mi? Eğer böyleyse, o zaman sizin hatanız değil, bu yüklenicinizin bir hatasıdır. Hepsi aynı fiyata 3 hafta yerine 3 ay iş veren bir spesifikasyonu kolayca yazmış olabilirsiniz.

Çoğunlukla iyiydi, ama bazı önemli sorunlar var:

• bir yapılandırma dosyasına ayrılması gereken bazı şeyleri kodladılar
• Birinde birleştirmem gereken birden fazla yapılandırma dosyası vardı
• kesinlikle HİÇBİR doküman yazmamışlar
• diğer bazı küçük değişiklikler

Bunlar senin şartlarının bir parçası mıydı? Eğer olsaydı, bu onların suçu. Değilse, bu sizin. Bu şeylerin spesifikasyonda bulunup bulunmadığı gerçekten açık değilse, belgeyi yazdığınız için bu da sizin hatanızdır. Bir dahaki sefere daha iyi bir spesifikasyon yazmaya çalışın.

Bir süre önce offshoring hakkında bir sunum yaptım. "Global Dış Kaynak Kullanımı, işinizi güçlendirmek için 10 ipucu" olarak adlandırıldı. İşte 10 ipucunun bir özeti (400'e kadar dış kaynaklı projeden gelir):

Bir seçim

1. En düşük ve en yüksek teklif sahiplerinden kaçının . Bu sadece açıktır, daha düşük teklif sahipleriyle risk almak istemezsiniz ve en yüksek teklif sahipleri medyandan daha az değerli (değer / fiyat) olma eğilimindedir.

2. Derecelendirmeleri (veya referansları) kontrol edin . Referansları ve derecelendirmeleri her zaman kontrol ederim.

3. Motivasyona öncelik verin . Eşit fiyatla, motive edilen teklifi seçiyorum. Örneğin, teklif sahibinin projeniz hakkında doğru konuşmasını sağlamak çok iyi bir işarettir.

B. Denetim

1. Fikri mülkiyetinizi koruyun . Bu en büyük hatalardan biri. Genellikle kullandığınız platform (vworker veya elance gibi) tarafından yönetilir.

2. Özel çerçeveleri reddet . Ya da ona veya daha özel olarak onu yazan geliştiriciye bağlı olma riskiyle karşı karşıya kalırsınız;)

3. Standartları uygulayın . Önceki ipucu ile ilgili. Standart kullanılması, kaynak kodunuzun değerini, daha fazla sayıda geliştirici tarafından anlaşılabileceği için artırır.

4. Erken gözden geçirin, sık sık gözden geçirin . Kaynak kodunu ilk hafta veya işten sonra gözden geçirirseniz, çoğu sorun "ayarlanabilir".

C. Strateji

1. Küçük projeleri olan test sağlayıcıları . Bir tedarikçiye büyük bir proje vermeden önce, bir veya iki küçük proje ile test ediyorum.

2. Riski azaltmak için birden fazla teklif sahibini kabul edin . Kritik proje için iki veya üç teklifçi seçiyorum, sonra en iyi uygulamayı seçiyorum. Küçük projelerle en iyi çalışın (5000 $ 'ın altında).

3. Bileşenleri monte edin . Başka bir strateji, daha sonra bir araya getirdiğiniz bileşenleri dış kaynak olarak kullanmaktır. Bir avantaj, sağlayıcılar arasında kolayca geçiş yapabilmenizdir ve hiçbiri her şeye gerçekten erişemez (fikri mülkiyet risklerini azaltır).

Maple_shaft'ın cevabına tamamen katılıyorum.

Kodu kabul ettiniz ve çek yazdım, sonra kodu inceledim, her şeyi geriye doğru yaptınız.

İşlevsel bir belirtime sahip olmadan kodlamalarına neden izin verdim?

Çünkü sözleşmeye yazmadınız. İşin yapılmasını istediğinden beri, seni belaya sokan şey olsa da, nedenlerini kabul ettin.

Neden her şeyi ilk kez anladıklarından emin olamadım?

Onlara işe yarayacağını düşündüğünüz bir tasarım sağlamalısınız. O zaman tam olarak anlamadılarsa gerçekten önemli olmazdı. Yani onlara para ödemedin, o zaman kim yapacak? Bu kod, herhangi bir dokümantasyon ve tasarım belirtimi olmadan nasıl korunacaktır. Cevap muhtemelen olmayacak .

Onlar, fiyat sabit olduğundan, çalışma kodunu tamamladıktan sonra herhangi bir değişiklik yapmalarını istemekten haksızlık ettiğimi söylediler.

İstediğiniz değişiklikleri yaptıkları için şanslısınız. Şunu söyleyebilirlerdi: zor şanslar

Kendilerini aynı pozisyonda bulan var mı? Dış kaynaklı projeleri yönetmenin daha iyi bir yolu olduğunu düşünüyor musunuz?

Tabii ki diğer insanlar sizin durumunuzdadır, tüm "dış kaynak" endüstrisi zarar vermeyecektir, birçok şirket bunu yapmak için ödeme yapmak (veya beklemek) zorunda kalmaya başlamaktadır. .

En azından kendiniz yaparak projenin durumunu günlük olarak kontrol edebilirsiniz. Arkanızdaysa, en azından teoride, hasarı kontrol etmek için yapabileceğiniz şeyler var.