Kaynak kod ve yazılım ürününün fiyatını belirleme


9

Bir proje üstlenmek üzereyim. Bu, kod yazmamı ve tonlarca yazmamı gerektirir. Müşterinin gereksinimi, projenin sonunda tüm kaynak kodunu teslim etmektir.

Sorum şu: Kaynak kodun ve yazılım ürününün fiyatını nasıl hesaplayabilirim? Fiyatlandırmayı belirlemek için takip eden herhangi bir ölçüm var mı? Yazılım ürününü nasıl ölçebilirim?

Ek bilgi: Uygulama, tabletler (iPad, Galaxy sekmeleri vb.), Akıllı Telefonlar (iPhone, Android telefonlar, vb.) Dahil olmak üzere herhangi bir işletim sisteminde ve web üzerinde çalışmalıdır. (Şimdi bunun ne kadar kod olacağını hayal edin) .


2
Birisi, sürekli değişen, belirsiz ve çoğu zaman eksik kullanıcı gereksinimlerine dayalı olarak bir yazılım ürününün fiyatını sihirli bir şekilde nasıl ölçeceğini bulacağında, dünya daha iyi hale gelecektir. Ama yine de soruyu + 1'leyin.
Arseni Mourzenko

Fiyatlandırma yazılımının tek güvenilir yöntemi: (1) programı yazmak ve test etmek; (2) çabanızı ölçün; (3) gerçekte harcadığınız çabayı temel alarak yazılımı satmak.
Doc Brown

Appcelerator , Air ve Haxe'yi kontrol etmelisiniz (her ikisini de hedefleyebilir veya NME kullanabilir ).
back2dos

bu programlama veya yazılıma özgü değildir, programlama ile ilgili bir soru olarak gizlenen fiyatlandırma hakkında genel bir sorudur.

I am about to undertake a project. This requires me to write code.... Programcı + Proje = Kod (genellikle). Neden bariz olanı belirtin?
Dinamik

Yanıtlar:


12

Birçok faktöre bağlı olduğu için asla kesin veya neredeyse kesin bir fiyat bilemezsiniz. Misal:

Vaka Analizi

WordPress'e dayanan küçük bir web sitesi için bir isteğiniz var. Yapmanız gereken tek şey: çekici grafikler oluşturmak için tasarımcınızla birlikte çalışın, ardından web sitesinin kendisini oluşturun (son derece teknik bir şey değil, WordPress'e eklemek için sadece bir dizi eklenti) ve sonra dağıtın. İş gerçekten kolay, 600 dolar teklif ettiniz.

Tasarımcınız ilk taslağı oluşturdu. Müşteri hiç çekici olmadığını açıkladı. Aynı şey ikinci, üçüncü ve dördüncü taslak için de geçerli. Son olarak, iki hafta süren sıkı çalışmanın ardından tasarımcı nihayet müşteri tarafından kabul edilen taslağı aldı.

Ancak ne yazık ki tasarımcı bir otobüse çarptı ve aldığınız tek şey size gönderdiği JPEG'lerdi, ancak orijinal PSD'ler değildi, bu yüzden yeni bir tasarımcıyla baştan başlamanız gerekiyordu. Sonunda grafikleri aldınız ve işinize başladınız.

Sürpriz: A eklentisinin B eklentisi ile uyumsuz olduğunu, C eklentisinin beklendiği gibi çalışmadığını ve D eklentisinin WordPress'in en yeni sürümüne yüklenemediğini keşfettiniz, ancak A eklentisi yalnızca yüklenebilir bu en yeni sürümde. Şimdi elle çok fazla PHP kodlaması yapmak zorundasınız ve bir Python geliştiricisi olduğunuzdan ve PHP'de hiçbir zaman tek bir kod satırı yazmadığından, bu en kolay görev değildir.

Bu arada, müşteri size son aşama bir hafta önce iken işin neden henüz yapılmadığını soran korkunç e-postalar göndermeye başlar. Sonunda PHP kodlamasını bitirirsiniz ve her şey makinenizde mükemmel çalışır. Müşteri mutlu.

Daha sonra, sadece web sitesinin bazı şifreli hatalarla başarısız olmadığını, aynı zamanda barındırma şirketi kodunuzda çok kullandığınız bir PHP özelliğini desteklemediğini keşfetmek için web sitesini barındırma sunucusuna dağıtmaya başlarsınız.

Son olarak, bu projeye 3.000 $ 'dan fazla harcadıktan sonra, web sitenizin hazır ve çalışır durumda olduğunu göreceksiniz. Son teslim tarihi ve "hiçbir şey sizinle beklendiği gibi çalışmadığı için" müşteri öfkeli. 600 dolar ister misiniz? 3000 $?

Neden oluyor?

Bu örnekte gösterdiğim, inandığınızdan çok daha sık oluyor. Neden? Çünkü tahmin edemeyeceğiniz ve riski artıracak çok fazla değişken var. Burada risk şu şekilde artırıldı:

  • Görsel tasarıma ilişkin belirsiz özellikler,
  • Tasarımcının ölümü,
  • Seçtiğiniz eklentilerin uyumsuzluğu,
  • Seçtiğiniz eklentilerin kötü desteği,
  • Daha önce PHP kullanmadığınız gerçeği,
  • Geliştirme ortamı ile üretim ortamı arasındaki fark ve evrelemenin olmaması.

Bu sorunları belirli yaklaşımlarla çözebiliriz:

  • Açık ve kesin fonksiyonel ve işlevsel olmayan gereksinimler,
  • Otobüste isabet senaryosu yönetimi (yani tasarımcı, projeden ödün vermeden her an ölmek için her belgeyi sizinle paylaşmak zorundaydı),
  • Kullanmanız gereken araçlar ve diller hakkında önceden bilgi ( çok fazla çalışma gerektirir ),
  • Evreleme, yoğun testler vb.

Tek sorun, bu yaklaşımla, müşterinize ilk etapta en az 5.000 $ ödeyeceğini söylemelisiniz, çünkü aslında gereksinimlerin fiyatı, şartname, tasarım, test vb. teklifiniz son derece düşük.

Yani yapacak bir şey yok mu?

Çok kesin bir fiyat veremiyorsanız, yine de işin her bir parçasını ayrı ayrı yapmayı göz önünde bulunduran ve her bir parçadan bir risk endeksi etkilenen bir tahmin verebilirsiniz. Tahmin edilebilir risk ne kadar yüksekse, fiyat da o kadar yüksektir.

Bunu yapmanın iki yolu var:

1. Watefally yolu

Şelale / V-Model'e uyan projeler üzerinde çalışıyorsanız, bu işe yarayabilir:

  1. Bir projenin işlevsel ve işlevsel olmayan gereksinimlerini listeler. Sözleşmeyi imzaladığı şekilde müşteri tarafından imzalanan belgeyi alın.

  2. Bu belgeyi aldıktan sonra, aşağıdakilere zaten sahipsiniz:

    • Gereksinimleri toplamak ve bu belgeyi oluşturmak için harcadığınız fiyat. Bu, önemli miktarda parayı temsil edebilir, çünkü bu belgeler sıradan bir proje için yirmi ila yüz sayfa arasında değişebilir ve büyük projeler için yüzlerce veya binlerce sayfa olabilir.

    • Yapmanız istenen ürünün net, hassas ve eksiksiz anlaşılması.

  3. Ekibinizle adım adım ilerleyin, her gereksinimi analiz edin ve değerlendirin:

    • Projenin bu bölümünün ortalama fiyatı,

    • Riski dikkate almadan maksimum fiyat,

    • Bir risk endeksi.

    Üçü de müşteriye vereceğiniz fiyatı belirlemek için dikkate alınacaktır.

  4. Belirli bir gereksinime bağlı olmayan, daha ziyade gereksinimler veya genel olarak sistem arasındaki uyumluluğa bağlı riski kabul edin.

Sualtı yaklaşımının artıları: Müşteri, yapılacak iş ve ortaya çıkabilecek riskler hakkında çok net bir vizyona sahip olduğunuzu göz önünde bulundurarak oldukça kesin bir fiyat alır.

Waterfally yaklaşımının eksileri: Fiyatı vermeden önce 200 sayfalık bir belge yazmalısınız. Müşteri bu arada projeyi iptal ederse veya eşzamanlı olarak giderse ne olur? Tüm süreç de son derece ağırdır ve gereksinimler daha sonra değiştirilemez.

2. Çevik yol

Scrum veya diğer çevik modellere uyan projeler üzerinde çalışıyorsanız:

  • ya projenin genel fiyatını değil, her bileşenin fiyatını verir,
  • veya başlangıçta çok yaklaşık bir genel fiyat belirtebilir ve daha sonra daha kesin bir fiyat verebilirsiniz.

Her iki durumda da, sizinle müşteri arasında güçlü bir güveni olmalı veya satış departmanında mükemmel insanlara sahip olmalısınız. Aksi takdirde,

  • ilk durumda, kişi parasını tekrar tekrar küçük miktarlar isteyerek çaldığınıza inanacaktı ve bu asla bitmeyecek,

  • ikinci durumda, kişi fiyatınızı neden sürekli değiştirdiğinizi, özellikle de fiyat çoğu zaman yükseliyorsa, anlamaz.

Agile yaklaşımının artıları: müşteri istediği zaman iptal edebilir. Ayrıca, erken aşamalarda iptal ederse, hala çalışan bazı kaynak kodu vardır.

Agile yaklaşımının eksileri: fiyat çok belirsiz veya hatta verilmiyor. Çoğu müşteri, ne kadar ödemek zorunda kalacaklarını söylemezseniz sizinle iş yapmak istemez.


3

Hem sonucu hem de müşterinin ödemesi gereken parayı netleştirmediğinde bir projeyi kabul etmeyin. Sadece aşağıdakileri yapıyorum:

  • Müşterinin yapması gereken adımlar ve ödemelerle gelin.
  • Bir önceki adım tamamlandığında ve tamamen ödendiğinde ve müşteri mutlu olduğunda bir sonrakine geçin.

Ödeme yöntemi için ödemeyi özelliklere göre seçin. Yani eğer müşteri tüm projeyi ödeyemezse özellikleri düşürme şansına sahipse.

Kod satırlarına (LOC) göre ödeme almak aptalca bir şeydir. Çünkü LOC hiçbir şey ifade etmiyor !. Akıllı olun iyi bir kod yazmak ve özelliğine göre şarj !.

İyi şanslar,


1
LOC'yi belirtmek için +1 yanlış metrik. Ve kilometre taşları ödeme almanın akıllı yoludur
jqa

0

Açık uçlu bir taahhüt için sabit bir fiyatı kabul etmeyin. Her seferinde mahvolursun.


+1 'sabit fiyat gelişimi' birçok başarısız işletmenin stratejisiydi
jqa
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.