Dış kaynak kodu uzun vadede daha mı pahalı? Kod kalitesine zarar veriyor mu? [kapalı]

İyi bir yazılım ürününün fikri mülkiyetine sahip olan ve yıllık lisanslamadan mükemmel bir gelir elde eden bir şirketin farkındayım. Bununla birlikte, direktör (teknik olmayan), kâr marjlarında önemli ölçüde yer aldığı için geliştirme ekibini sürdürmenin maliyetinden şikayet ediyor ve belirli modüllerin geliştirilmesini daha düşük bir ücret alan diğer ülkelere dış kaynak kullanımını düşünüyor.

Şahsen, bunun uzun vadede daha uygun maliyetli bir çözüm olacağını düşünmüyorum. Bu, sorun olduğunda iletişim arızalarına yol açabilir, ayrıca spesifikasyonların su geçirmez olması gerekir ve bu da yine de daha fazla zaman alabilir. Kanımca, ekipler halinde çalışırken iletişim önemlidir - ya da bu işi yapmanın etkili bir yolu var mı?

Eminim birisinin bu işe bir örneği vardır, ama görmedim.

Uzun yıllar boyunca Fortune 500 şirketinde çalıştım ve bir çok gelişmeyi dışarıdan aldılar. Dış kaynaklı bir projenin, kendimiz yapmış olduğumuzdan (şirket içi) daha düşük maliyetli olduğu bu yıllarda tek bir örneğim yok.

Programlama oranları bizimkinden düşük olsa da, dışarıdan tedarik edilen ekibi yönetmek için kurum içi ekiplere kıyasla 3 kat daha fazla zaman harcadık. Bu, gereksinimlerin şirket içi ekibimizin ihtiyaçlarından daha ayrıntılı olması için gereken ilave sürenin ve kalite güvencesinde gereken ilave sürenin üstünde, çünkü kod hiçbir zaman doğru olmaya yakın değildi.

Hızlı bir şekilde sahip olabilirsiniz, ucuza sahip olabilirsiniz veya iyi bir şekilde yapabilirsiniz. Üçüne de sahip olamazsınız ve her üç kişiden ikisinin bile bir streç olabileceğini iddia ediyorum.

Bir yazılım şirketi için bu sadece aptalca. Oldukça akıllı bir karara varabilecekleri en yakın şirket daha ucuz yeteneklere sahip başka bir yere taşınmak olacaktır.

Yazılım geliştirmelerini dışarıdan temin eden bir yazılım şirketi artık bir yazılım şirketi değil. Kazandığınız kazançların kısa ömürlü olacağını savunuyorum, çünkü kendi rekabetinizi yaratıyorsunuz. Ürünü sizden daha iyi tanıdıklarını anladıktan sonra, artık size ihtiyaç duymadıklarını da fark ederler.

Başka bir ülkedeki bir şirkete dış kaynak sağlama konusundaki tek deneyimim sonuncum olacak. İşe alınan, çalışmalarını zamanında tamamlayamayan ve hatta spesifikasyonları uzaktan yerine getiremeyen şirket, her şeyi tekrar şirket içinde tekrar yapmak zorunda kalmamıza neden oldu.

Bununla birlikte, güvenebileceğiniz güvenilir bir şirket bulabilirseniz (yani, diğer insanlardan onlar hakkında iyi şeyler gördünüz / duydunuz), belki de faydalıdır.

Yönetmen, deneyimli yerel geliştiricilerinden bazılarını, uzmanlığı yargılamaya yetkili olmayan, kodla hiç deneyimi olmayan ve bilen herhangi bir kişi tarafından doğrudan denetlenemeyen veya mentorluk edemeyen uzak bir ülkedeki insanlarla değiştirmek istiyor. kod.

Bunu iki kez yaşadım. Her iki durumda da, ucuz yabancı firmalar zamanında ve yeterli kalitede teslim edemediler. Yerel geliştiriciler işin denizaşırı ülkelere gittiğini duyduklarında, gereksiz hale getirilmeyi beklemek yerine başka işler buldular. Uzmanlık kanaması devam ettikçe, programlar düştü, kritik hatalar düzeltilmedi, müşteriler sinirlendi ve rakiplere geçti ve sonunda her iki şirket de katlandı.

İletişim, beklentiler ve kültürle ilgili garip sorunlar da vardı. Örneğin, yabancı bir ekip fazla kodu kontrol etmiyor veya e-postaya hemen yanıt vermiyordu. Yerel BT yöneticisinin maliyetleri düşürmek için bir bonus aldığı ortaya çıktı, bu yüzden tüm ofisi düşük hızlı bir İnternet bağlantısına sahipti. Başka bir zaman, üçüncü dünya KG test uzmanları rutin olarak aynı hata raporuna çılgınca farklı hatalar ekledi; menajerleri hata numaralarının tükenmesinden korkuyordu.

Ucuz yerlerde bazı takımlar iyi. Duyduğum kadarıyla Red Hat, Pekin'de çok yetkin bir ekibe sahip gibi görünüyor. Ama bunu yapmaya başlamadan önce dünyanın her yerinden telekomünikasyon yoluyla çalışan insanlarla yıllarca deneyime sahiplerdi ve Pekin'deki insanlar bir dış kaynak firması değil Red Hat çalışanları.

Evet - sizin için ne ödeme olsun.

Deneyimlerime göre, pazar ve geliştirme ihtiyaçlarınız o kadar basit değilse, olası bir dil engeli olan herhangi bir geliştiriciye e-posta yoluyla kolayca açıklanabilir ve o kadar basittir ki, şirkete gerçekten yatırım yapmayan bir geliştirici bile yine de başarılı olabilir kaliteli bir ürün oluştururken, evet ürününüz acı çekecektir .

Büyük bir yerel geliştirme ekibimiz olan bir şirkette çalıştım ve ürünümüz sadece yönetim ekibi satışlara daha fazla para ve çaba harcadığı için acı çekti. Satışlara çok fazla çaba sarf edildiğinden, "iyi" yaptığımız anlaşıldı - ama gelir elde etmek için satış sürecine para ve kaynak koymaya devam etmemiz gerekiyordu.

Uzak bir ekibimiz vardı ama onları şirkete tamamen entegre ettik ve yerel ekiplerimizle aynı seviyeye katıldılar. Çalışabilmesinin tek yolu bu . Onlar için yerel ekip lideriydim ve onlarla düzenli olarak sahada çalışmak için uçtuk. Yerel ekipler gibi onlara şirket gömlekleri ve ceketleri verdik. Her şeyden sonra, belki bizi% 20-30 kurtardı. Maliyetleri bundan daha fazla azaltmaya çalışan bir sistemi bir araya getirirseniz, ürününüz buna göre acı çekecektir.

Kaliteli bir dış kaynak ekibi ile çalışıyorsanız ve yönetim kabul kriterlerini iletmeye ve uygulamaya istekliyse.

Daha sonra maliyet, şirket içi geliştirilmiş bir ürünle aynı oranda olacaktır.

Şanslıysanız, aynı kaliteyi de alabilirsiniz.

Biraz önyargılı olabilirim, çünkü şirketim şirket içi bir geliştirme personeli tutuyor ve herhangi bir ürün geliştirmesi için dış kaynak kullanmıyor. Dış kaynaklı gelişimi olan entegrasyon ortaklarıyla yaşadığımız deneyimlerin bu kararla ilgisi olduğunu düşünüyorum.

Deneyimlerime göre, bir projeden dış kaynak kullanımı, daha iyi marjlar elde etmeye çalışırken en iyi çözüm değildir.

İş yerinde böyle bir şey vardı ve diğerleri de söylediği gibi, delik işini yeniden yaptık ve bir üretim sunucusunda olanı koruduk. Bu konuda sonuç, iki katına mal oldu.

Konuyla ilgili düşüncem, dış kaynak kullanımındaki marjlar üzerinde bir fark yaratmayı düşünüyorsanız, yatırımınızı atmış olabilirsiniz. Bunu düşünürseniz, ürün başarısı belirtildiği gibi çalışan şeyler meselesidir, bu nedenle dev ekibini değiştirirseniz, işler çirkinleşebilir.

İyi planlanmış / yapılmış açık kaynaklı yazılım sizin cevabınız olabilir, çünkü oldukça karlı olabilir ve bakım bir topluluğa devredilir, ancak başarı için bir reçete yoktur. Verebileceğim en iyi tavsiye, gerçekten açık kaynak ve onun parlaklığı hakkında birkaç görüşme tavsiye etmektir:

• Jeremy Ruston (BT) "Açık Kaynaklı Bir Proje Nasıl Başlatılır" http://vimeo.com/856110
• Chris DiBona (Google) tarafından "Açık Kaynak Büyülüdür" http://www.youtube.com/watch?v=hmZyyBVbkOQ
• Jono Bacon tarafından "Topluluk Motorları" (Standart) http://www.youtube.com/watch?v=zKOrWubmzAY
• "Açık Kaynak Projeleri ve Zehirli İnsanlar" Ben Collins-Sussman ve Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "Benim İçin Neler Var? Açık Kaynak Kodundan Yararlanıyor " Ben Collins-Sussman ve Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

Ve belki de:

• Roan Lavery (FreeAgent) tarafından "İş Modeli Nasıl Seçilir" http://vimeo.com/5588154

Bence açık kaynak ile ilgili olan şey, sadece sizin için değil, herkese göre açık kaynakların gücü topluluklar içinde yatıyor.

Ayrıca, patronunuz / şirketiniz yazılımı açmak konusunda isteksizse, kendi iş mantığınızın ve know-how'ınızın özelliklerini izole edin. Yani, ne yapardınız:

1. Kaynaklarınızla açık kaynaklı bir proje inkübe edin
2. Topluluk büyüt
3. ???
4. Kâr =)

Evet, ciddiyim ve "???" yeterince ilgi topladıktan sonra takip etmek istediğiniz stratejileri içerir. Github ve twitter gibi günümüz araçlarıyla kelimeyi daha kolay yayabilirsiniz, ancak ilk izlenimin yeterince ilginç olması gerektiğini unutmayın.

Aslında açık kaynak istemiyorsanız ( uygulamadan önce bir iş modeli olarak anlamalısınız, başarılı olmak istiyorsanız ), Carsonified videosunu kontrol etmek için her zaman bir hizmet olarak başlatabilirsiniz, ancak bu bir bütün anlamına gelir şirketiniz için birçok şey.

Sonuçta, açık kaynak olması ya da bir hizmet olarak başlatılması, projeyi uzun vadede sürdürülebilir kılmanın yollarıdır.

Bu alıntı yazarı hatırlamıyorum, ama çivi vuruyor.

" Sıkı birleştirilmiş bileşenler üzerinde birlikte çalışan gevşek bağlı takımlar başarısız oluyor. Kaçınılmaz olarak "

Dış kaynak kullanımı = gevşek bağlı takımlar.

Birbirine bağımlı bileşenler üzerindeki çalışmaları coğrafi olarak bölerek maliyetleri düşürmeye çalışmak her zaman başarısız olur.

Öte yandan, tecrübelerime dayanarak, yazılım portföyünün bir kısmının taşınması işe yarayabilir, bu da düşük maliyetlerle iyi kalitede geliştirilebileceği anlamına gelir.