Geliştiricileriniz tarafından rehin alınmaktan kaçının

rehine 100107Bu hafta sonu, patronunun sahip olduğu birkaç web uygulamasının yönetiminde patronuna yardımcı olan yerel bir sanatçıyla sohbet etmeye başladım.

Konuşma bir dönüş yaptı ve birlikte çalıştıkları geliştiriciyle herhangi bir ilerleme görmeden haftalık geliştirme ücretlerini ödeme konusunda bazı girişimler devam etti. Şimdi geliştirici, projeyi tamamlamak için onlardan başka bir toplu ücret ve diğer talepleri karşılamak için haftalık bakım ücreti almak istiyor. Daha da kötüleşiyor.

Geliştirici, alan adlarını yönetebilmesi için aktardı. Geliştirici ayrıca uygulamayı kendi barındırma hesabında barındırır. Kısacası, geliştirici şimdi onları rehin tutuyor.

Neyse ki, birlikte çalıştığım kadın geçmişte sitenin bazı şablon dosyalarını düzenlemek için yönetici erişimi istedi. Geliştirici ona sınırlı erişim sağlayabilirdi ama vermedi. Ona (tembelce) siteye yönetici girişi sağladı. Bu gece sitenin tüm kodunu yedeklemek için bu erişimi kullandım. Ayrıca hangi yönetim yazılımını kullandığını buldum ve hem uygulamaların verilerini hem de tablo yapılarını dışa aktarabildiğim veritabanı yönetimine gittim. Whew.

İşletme sahibi, geliştirme tamamlandıktan sonra siteleri yeni alan adlarına taşımayı planlıyordu. Bu çok büyük çünkü geliştirici ile şirket arasında öfkeli bir ayrılık olması durumunda mevcut alan adlarının süresinin dolabileceği anlamına geliyor. Bunun daha önce olduğunu görmüştüm.

Dış kaynaklı bir geliştirme ekibi alacaksanız bazı ipuçları:

  1. Alan Adı Tescili

    Alan adlarınızı şirketinizin adına kaydedin. Geliştiricinizin hesapta Teknik İrtibat Kişisi olması fena değil, ancak asla etki alanının sahipliğini şirketiniz dışındaki herhangi birine devretmek.

  2. Uygulamanızı veya Sitenizi Barındırma

    Geliştiricinizin bir barındırma şirketine sahip olması ve sitenizi sizin için barındırması harika, ancak bunu yapmayın. Bunun yerine, uygulamayı nerede barındıracağına dair tavsiyelerini sorun. Geliştiricilerin yönetim yazılımı, sürümleri ve kaynakların konumu hakkında bilgi sahibi oldukları ve bu ürünün daha erken tamamlanmasına yardımcı olabileceği doğrudur. Bununla birlikte, barındırma hesabına sahip olun ve geliştiricinizi kendi giriş ve erişimiyle ekleyin. Bu şekilde, ihtiyaç duyduğunuz her an fişi çekebilirsiniz.

  3. Kod Sahibi Olun

    Kodun size ait olduğunu varsaymayın, yazılı olarak yazın. Geliştiricinizin kendisine ödediğiniz çözümleri başka bir yerde geliştirmesini istemiyorsanız, buna sözleşme sırasında karar vermelisiniz. Bu şekilde çözümler geliştirdim ama aynı zamanda bunları kod haklarına sahip olduğum yerlerde de geliştirdim. İkinci durumda, şirketin bana haklar vermesi için bir teşvik oluşması için başvurunun maliyetini daha düşük pazarlık ettim. Geliştiricinizin kodunuzu başka bir yerde kullanmasının bir sakıncası yoksa, o zaman en yüksek doları ödememelisiniz!

  4. İkinci bir görüş alın!

    İnsanların bana teklif aldıklarını veya diğer profesyonellere danıştıklarını söylemeleri duygularımı incitmiyor. Aslında tavsiye ederim!

Sonuç olarak, geliştiricinizin yeteneği için para ödüyorsunuz, ancak fikir üzerindeki kontrolü ve sahipliği elinizde tutmalısınız. Sizin. Ona yatırım yapan sizdiniz, işinizi ve karlılığınızı riske atan sizdiniz… ve onu elinde tutması gereken sizsiniz. Geliştiriciler değiştirilebilir ve bu asla uygulamanızı ya da daha kötüsü işinizi riske atmamalıdır.

6 Yorumlar

  1. 1

    Ben bir web uygulaması geliştiricisiyim ve puanlarınızın çoğuna (belki de tümüne) katılıyorum ancak #3 hakkında bir açıklama istiyorum.

    Başka bir şirkete (veya daha kötüsü bir rakibe) satılan bir sitenin veya uygulamanın toptan kopyalanması etik değildir ve sözleşmenizde her zaman kabul edilemez olarak belirtilmelidir. Bununla birlikte, bir müşterinin kendi işleriyle hiçbir ilgisi olmayan veya genel çözümün önemli bir bölümünü temsil etmeyen bir projesi üzerinde çalışırken yaygın sorunlara yenilikçi çözümler geliştirdim.

    Örnek:
    Müşteri, kullanıcı rollerine bağlı sayfa seviyesi ve alan seviyesi kontrolü istedi. ASP.Net için "kullanıma hazır" işlevi, klasör düzeyinde izinler sağlar. Böylece .Net için yerel izinleri genişlettim ve çözümü genel bir web uygulamasının parçası olarak teslim ettim.

    Tüm kod tabanına (sözleşmede belirtildiği gibi) haklarına sahip olduklarına inanıyorum, ancak gelecekteki projelerde bu uzantıyı gerçekleştirmek için aynı metodolojiyi ve kod parçalarını kullanmanın haklı olduğunu düşünüyorum.

    Başka bir kırışıklık:
    Bunu bir danışmanlık şirketi tarafından çiftlikte yetiştirilirken yaptım. Danışmanlık şirketinin geri dönüp bu çözümü kopyalayıp kendi çözümü gibi pazarlama hakkı var mı sizce?

    • 2

      Tam olarak değil,

      Bence anlaştık. Buradaki amacım, koda sahip olduğunuzdan ve onunla kapıdan çıkabildiğinizden emin olmaktır. Geliştiriciniz sizin için kod derliyor ve sitenize gönderiyorsa, kod sizde değildir. Bunun grafiklerden, Flash'tan, .NET'ten, Java'dan… kaynak dosya gerektiren ve çıktısı alınan her şeyde olduğunu gördüm.

      Doug

  2. 3

    Nereden geldiğinizi anlıyorum ve her şeye %100 katılmasam da (ihtarlarım var), şirketler bunu her zaman akıllarında tutmalı.

    1. KESİNLİKLE. Bunu yeterince vurgulayamam. Bunu yapan küçük bir şirkette çalıştım ve dahil olduğum için ezici bir suçluluk hissettim. Oradan çıkabildiğim için çok mutluyum. Müşteriler, alan adlarının kontrolünü kesinlikle elinde tutmalıdır. Yeterince bilgili birine sahiplerse, geliştiriciye buna erişim izni vermeyin. Değilse, geliştiricinin en azından bir tür bayi arayüzü aracılığıyla bilgileri değiştirmeniz/alanı aktarmanız için bir yolu olduğundan emin olun.

    2. Buna kısmen katılıyorum ama sonra duruma göre değişir. Basit bir PHP uygulaması dağıtıyorsanız ve düşük maliyetli barındırmaya ihtiyacınız varsa, elbette, bir LunarPages veya DreamHost hesabı veya başka bir şey alın ve oraya atın. Geliştiriciye erişim izni verin. Ancak, düşük maliyetli paylaşımlı barındırma kesinlikle dezavantajlara sahiptir… özellikle daha büyük şeyler için. Ancak, bunun için endişelenecek kadar büyükseniz, bununla başa çıkabilecek teknik personele sahip olmalısınız. Çoğunun güven ile ilgili olduğu açıktır. Elbette, bu tür şeyler hakkında (kısıtlamalar ve benzeri) yapabiliyorsanız, bir sözleşmeye bir şeyler koyun. Geliştiricinin süslü bir şey yapması gerekmiyorsa, üçüncü taraf barındırma harikadır. Parçalandığımı kabul ediyorum çünkü bu gerçekten durumsal bir şey. Ayrıca sitenin boyutuna, kullanılan teknoloji dizisine de bağlıdır. Eğer büyük olacaksa, personelden birini işe almayı düşünüyorum. Her zaman bir seçenek değildir, ancak büyük şeyler için daha güvenlidir.

    3. Bu aynı zamanda eski şirketimin yaptığı bir şey. Ayrılabilirsin, sana HTML, resimler vb. verirlerdi. ama kod yok. Kod temelde kiralık bir hizmetti. Olduğu söyleniyor, sahip olmak ve sahip olmak var. Her zaman münhasır olmayan bir satış yaptım. Temel olarak, bileşenlerimi yeniden kullanabilmem gerekiyor. Müşterinin ona sahip olmasıyla, onunla istediğini yapmasıyla ve hatta üzerinde başka birinin çalışmasıyla ilgili bir sorunum yok… ama kendimi ipotek etmeyeceğim ve her seferinde tekerleği yeniden icat etmem gerekecek.

    4. Her zaman. Her zaman. Her zaman.

  3. 4

    Güzel gönderi… aferin ama bir maddeye katılmasam da (#2):

    "Geliştiricinizin bir barındırma şirketi olması ve sitenizi sizin için barındırması harika, ancak bunu yapmayın."

    Bunun arkasındaki mantığı anlasam da, bazı durumlarda projenizin başka bir yerde barındırılmasını zorunlu kılmak ters tepebilir. Sitenizi veya uygulamanızı geliştiren şirketin kullanmayı tercih ettiği bir barındırma platformu varsa, onu kullanmaları daha verimli ve üretken olacaktır.

    Ek olarak, felsefi bir bakış açısından, “rehin tutulmak” istemediğiniz için geliştiricinizin barındırma platformunu kullanmayı reddederseniz, bu en başından itibaren bir güvensizlik tonu oluşturur. Geliştiricinize onlarla ev sahipliği yapacak kadar güvenmiyorsanız, ilk etapta gerçekten onlarla çalışmak istiyor musunuz?

    Bu tür durumlarla ilgili birçok korku hikayesi olduğunu biliyorum, ancak genel olarak güvendiğiniz bir geliştirici bulmaya odaklanmanızı tavsiye ederim. Geliştiricinizin barındırma hizmetini kullanabilir ve yine de yönetici erişimi talep ederek ve kendi yedeklerinizi oluşturarak kendinizi koruyabilirsiniz.

    Yine güzel bir yazı ve çok faydalı bilgiler.

    Teşekkürler!
    Michael Reynolds

    • 5

      Merhaba Michael,

      Bir güven sorunu gibi görünebilir ama öyle olduğunu düşünmüyorum – bu gerçekten bir kontrol ve sorumluluk sorunu. Web sitenizin gelişimine önemli miktarda yatırım yapacaksanız, ortamını kontrol edebileceğinizden emin olmalısınız.

      İş hayatında ilişkileri bozan şeyler olur ve bunların olumsuz olması gerekmez. Belki de geliştiriciniz/firmanız çok büyük bir müşteri alıyor ve size zaman ayıramıyor. Belki de iş hedeflerini değiştirirler. Bazen hosting şirketlerinin sorunları olabilir.

      Barındırma işleminizi sizin kontrol etmenizi ve sorumlu olmanızı savunuyorum, böylece en iyi olduğu şey olan geliştirme konusunda geliştiricinize güvenebilirsiniz!

      Geri itmeyi takdir ediyorum, Michael.

  4. 6

    Ben de bir web uygulaması geliştiricisiyim ve bence isabetli oldunuz. Bazı düşünceler:

    Bence çoğu kişi aynı fikirdedir (ve aşağıdaki yorumlara dayanmaktadır) 1 numara mutlaktır. Asla, asla yapma. Durmadan. Her koşulda.

    #2 konusunda belki de bazı geliştirici arkadaşlarımdan farklı bir görüşüm var: Müşterilerimiz için nihai ürünü barındırmayı reddediyoruz (elbette, müşterilerin geliştirme sırasında ürünü test etmeleri için bir test sunucusuna ev sahipliği yapıyoruz). Müşterilerin, kendilerini barındırmak veya bir barındırma sağlayıcısı bulmak için kurulum yapmalarına yardımcı olmaktan memnuniyet duyarız. Biz sadece hosting işine girmek istemiyoruz. Bu, işi geri çevirmek anlamına geliyorsa, öyle olsun. Bu hizmeti çok daha ucuza sağlayabilecek çok sayıda büyük hosting şirketi veya altyapı firması var. Çalışmamızın taşınabilirliğini teşvik ediyoruz ve müşteri, yıllar sonra barındırma sağlayıcılarını değiştirse bile, barındırılmasına yardımcı olmak için elimizden gelen her şeyi yapacağız.

    #3 için, müşterilerimiz tek bir uyarı ile nihai ürünün tüm kaynak kodunu alırlar: Çözümde kullanılan üçüncü taraf ürünler için (Telerik veya Bileşen Bir'den web kontrolleri gibi), müşteriye derlenmiş dll'yi verebiliriz. üçüncü taraf kontrolü (bir ızgara söyleyin). Bu üçüncü taraf şirketlerle (müşteriye sağladığımız) lisans anlaşmalarımız, bu tür kontroller için kaynak kodunu yeniden dağıtmamızı yasaklar, çünkü bu bizim değil üçüncü tarafların fikri mülkiyetidir. Bu tür ürünlerin kullanımı, müşteri için geliştirme süresinden tasarruf sağlar ve aynı işlevselliği sıfırdan oluşturmaktan çok daha ucuzdur. Herhangi bir iş yapılmadan önce bu politika hakkında ön saflardayız. Tabii ki, müşteri özel kontrol geliştirme için ödeme yapmak isterse (üçüncü şahıstan önceden oluşturulmuş ürünü kullanmak yerine), diğer her şeyle birlikte bu özel kontrolün kaynak kodunu sağlarız.

    Kodun yeniden kullanımı söz konusu olduğunda, herhangi bir çalışma yapılmadan önce özel olarak müşterinin kullanımı için (örneğin tescilli bir iş süreci için) özel olarak geliştirilmediği sürece, kodun bölümlerini yeniden kullanabileceğimiz konusunda netiz. Müşteri elbette özel kod geliştirmek istiyorsa, bu onlar için kullanılabilir.

    Diğerlerinin de söylediği gibi, #4 her zaman tavsiye edilir. Her zaman!

    Saygılarımızla,
    Tim Genç

Ne düşünüyorsunuz?

Bu site spam'i azaltmak için Akismet'i kullanıyor. Yorum verilerinizin nasıl işlendiğini öğrenin.