Serbest yazılım geliştirmede, firmalar son başvuru tarihlerini kaçırdıklarında ne tür cezalara sahip olmalıdır? [kapalı]


12

Ortak geliştirici ile konuşuyordum.

Zamanında teslimatını sağlamak isteyen bir müşterisi var. Müşteri, kaçırılan son teslim tarihleri ​​için yankılar ister.

Serbest çalışma yapmasam da cevap veremedim.

Benim sorum şu:

Teslim edileceklerinizdeki (işten atılmanın yanı sıra) son tarihleri ​​kaçırırsanız (serbest çalışanlar) müşterinizle hangi yankıları kabul ediyorsunuz?


2
En azından değişen gerekliliklere dayalı bir kurtulma maddesi olmadan herhangi bir cezayı kabul etmek aptalca olacaktır. Görev tahmini, değişim yönetimini hesaba katmadan önce en iyi ihtimalle korkunç bir şekilde yanlıştır. Temelde. Run
Matt D

4
Yani müşterin, son tarihi kaçırmamanız için mali çıkarları olur mu? Gerçekten iyi bir fikir gibi gelmiyor. Bu sadece müşterinin geç kaldığınızda (MainMa örneğinde olduğu gibi) zor bir mali kaybı olması durumunda mantıklı olacaktır.
Doc Brown

2
Bu benim için tamamen kabul edilebilir görünüyor. Yorumlar beni oldukça şaşırttı. İnsanların iş için ödeme yapmasını bekliyorsunuz, son teslim tarihi ve son teslim tarihini karşılama teşviki yok mu? "Görev tahmini çok yanlış" - olmak zorunda değil.
NimChimpsky

@DocBrown, müşterinin son teslim tarihini karşılama konusunda çok daha büyük bir mali çıkarına sahip olduğu için, son teslim tarihiyle çalışmayı öder. Programcıların zaman sınırlarından ve yapıdan hoşlanmadığını bazen şaşırtıcı buluyorum. Yeni bir mutfak taktığınızı hayal edin ve dükkan oooooo diyor ki hayır, ne zaman biteceğini söyleyemeyiz, sadece saat başına ücret alacak. Ondan bir mil koşardım. Programlama, herhangi bir projeden niteliksel olarak farklı değildir.
NimChimpsky

5
Yeni bir mutfak takıyorsanız, yapıya göre belirtilecektir. Kesme yüzeyini, fayansları, muslukları ve lavabo malzemelerini değiştirmeye başlarsanız, her iki malzeme için de harcanacak ve harcanan zaman için ekstra ücret ödersiniz. Bu durumda neden ücretlendirildiğinizi anlamak kolaydır, fiziksel bir ilişki vardır. Değişen yazılım gereksinimleri genellikle aynı anlayışla gelmez ve X'i Y tarafından teslim edilmesini gerektiren herhangi bir sözleşme, X'in tam olarak çivilenmediği yerlerde sorun ister. İşler değişecek, bunu açıklayamamak aptalca.
Matt D

Yanıtlar:


25

En etkili olanlardan biri: gecikme gününe göre ceza. Bu aynı zamanda büyük projeler için de yapılır, ceza bazen günde binlerce dolar olur.

Eğer kesin bir son tarih önemliyse (örneğin, Olimpiyat Oyunları için 2014'teki etkinliğin yayınını idare edecek bir web uygulaması geliştirilirse, son tarih 2014'teki Olimpiyat Oyunlarının başlangıcı olacaktır), o zaman etkili önlem proje geç kaldığında, şirkete hiçbir ücret ödenmez ve ayrıca bir ceza ödemek zorundadır.

Böyle sert önlemler uygun değilse, o zaman iyi bir müşterinin proje geç kalması durumunda ayrılacağı hile yapabilir.

Müşteri için not:

  1. Birçok gecikme müşterilerin kendisinin hatasıdır. Nedenleri birden fazla olabilir:

    • SRS yok, bunun yerine müşterinin ihtiyaçları olduğunu düşündüğünü daha iyi açıklayan iki paragraf (ve elbette, müşteri bu adımı bir zaman kaybı olarak düşünerek gereksinimlerin toplanması için ödeme yapmak istemiyor).

    • Son tarihten iki hafta önce geliyor ve projenin bugüne kadar Java'da yapıldığını ve Oracle'ı kullandığını fark etmediğini söylüyor: Python'da yeniden yazılması ve MySQL kullanması zorunludur, çünkü müşteri dün bir dergi okumuş bu teknolojilerin gelecek olduğunu söylüyor.

    • Her toplantıda yeni bir dizi gereksinimle geliyor. Bu gereksinimlerin şimdiye kadar verilen hemen hemen her gereksinimle çeliştiği bonus puanları.

  2. İyi bir proje için iyi iletişim şarttır.

    Diğer birçok gecikme iletişim eksikliğinden kaynaklanmaktadır. Müşterinin şirketle aylarca hiçbir iletişiminin olmadığı ve sadece ürün bittiğinde ve cilalandıktan sonra iletişim kurulmasını beklediği uygulamalar bir felakete neden olur.

  3. Ödediğini alırsın.

    Projeyi organize tutmaya yardımcı olan özel prosedürler vardır ve aslında programlama büyük projeler için sadece% 10 ila 15, orta projeler için% 15 ila% 20 zaman almalıdır. Bu projeler de ne yaptıklarını bilen insanlar tarafından yapılmalıdır.

    Uygulamada, müşteriler mimari ve yazılım tasarımı yaratacak bir analiste günde 800 $ ödemeye razı değiller ve diğer adımlar için de ödeme yapmak istemiyorlar. Günde 50 dolara çalışmaktan mutluluk duyan bir acemi Arnavut programcı çok daha avantajlı görünüyor.

    Yalnızca felaketli projeler için ödeme yapmaya hazır olduğunuzda projenin bir felaket olduğundan şikayet etmeyin.

  4. İşi yapmak için gereken zamanı müzakere etmeyin.

    Sık sık böyle tartışmalarla karşılaşıyorum:

    Geliştirici: gereksinimleri göz önüne alındığında, bunu dört ay içinde teslim edebilirim.
    Müşteri: bu imkansız. Proje iki ay içinde yapılmalıdır.
    Geliştirici: iyi, bazı özellikleri kesmedikçe ...
    Müşteri: Yapamıyorum! Tüm özellikler gereklidir. Neden iki ay içinde işi yapamıyorsun? Bir Hintli programcı, bir arkadaşımla iletişime geçtim, bunu bir buçuk ay içinde teslim edebilir ve fiyatın sadece yarısını sorar!

    Müzakere zamanı felaket için bir reçetedir.

  5. Önceliklerinizi bilin.

    % 90 bitmiş kuralını dikkate alın. Proje yanlış yönetildiğinde, geliştiricilerin projeye başladıktan bir ay sonra projenin% 90'ını yaptıklarını söylediklerini görmek olağandışı değildir. Sonra, bir ay sonra, hala% 90. Ve bir ay sonra.

    Bunun iki nedeni olabilir:

    • Proje doğru bir şekilde yapılmadığında, yani zamanın% 100'ü programlamaya ayrılır, bu da gereksinim toplama, mimari, tasarım ve test için% 0 bırakır, ne olur, programcıların yapacakları iş hakkında hiçbir fikri yoktur ve keşfederler Projenin ömrü boyunca yeni görevler. Projeyi hazırlamak, gerçekleştirilmesi gereken tüm görevleri daha iyi anlamanıza yardımcı olacaktır.

    • Müşteri acele ettiğinde, bazı şirketlerin hızlı bir saçmalık sağlaması alışılmadık bir durum değildir, daha sonra hataları çözmek için çok fazla zaman harcar. Bazı şirketler sadece böyle çalışırlar, bu da rekabetçi kalmalarına yardımcı olur ve üç hafta içinde belirli bir projeyi başardıklarını söyler, daha sonra bile dağınıklığı çözmek için üç yıl geçirdiler.

    Öncelikleri düz koymak ve projenin doğru bir şekilde yapılmasını istemek, bu şirketleri aday listesinden çıkarmaya yardımcı olur.


3
"Sadece felaketli projeler için ödeme yapmaya hazır olduğunuzda projenin bir felaket olduğundan şikayet etmeyin." Bunu kullanabilir miyim? Bu harika bir yazı btw ve her iki tarafın risklerini güzel bir şekilde özetliyor.
Matt D

+1 Çok iyi puanlar. Ayrıca, okumak için bir zevk :)
Radu Murzea

5
@MattD: Stack Exchange'deki cevaplar Creative Commons Attribution-ShareAlike 3.0 Unported altında lisanslanmıştır, bu nedenle evet yapabilirsiniz. Ayrıca, blogumda ilgili bir yayını okumaktan çekinmeyin: Zaman ve maliyeti hesaplama: Neden her zaman yanlış anlıyoruz? , yanı sıra buradaki sorumun cevapları: programmers.stackexchange.com/q/158640/6605
Arseni Mourzenko

Neden bu blog yazısında bir bölüm 4, 5, 6 vb. Yok?
Radu Murzea
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.