Yazılım geliştirme teklifi nasıl yazılır

Başarılı bir yazılım geliştirme teklifi nasıl yazılır.

Kevin Languedoc

Bir yazılım geliştirme teklifinin amacı, iş adamları tarafından okunacak bir çözümü iletmektir, bu yüzden onu basit ve isabetli tutun; mümkün olduğunca teknik terimlerden uzak durun. Aşağıdaki taslak, başarılı bir yazılım geliştirme teklifi hazırlamak için olduğu gibi kullanılabilir. Teklifi sunacağınız kişilerin uzun bir belgeyi okumak için fazla zamanları olmadığını unutmamak önemlidir. Benden alabilirsiniz, bilgi teknolojisi alanındaki 20 yılı aşkın süredir yüzlerce teklif yazdım: iş adamları sadece bilinçli bir karar vermelerine izin verecek kadar bilgi istiyorlar.

Bir Teklif İsteğine (RFP) yanıt veriyorsanız ve sayfalar önceden basılmış olduğundan veya içerik gereksinimleri sizi aşırı uzun bir teklif vermeye zorladığı için belirli bir sayfa aralığına uymanız gerekiyorsa, bir Yönetici Özeti kullanmayı düşünün. Aşağıya nasıl hazırlanacağını özetleyen bir bölüm ekledim.

Teklif Süresi

50 sayfa veya sayfa boyunca devam eden teklifleri savunan şablonlar ve tartışmalar gördüm. İnanın bana, beşinci sayfadan sonra iş yöneticisinin ilgisini kaybedeceksiniz. Teklif kabul edildikten sonra, tasarım belgeleri doğal olarak daha ayrıntılı olacak, çünkü bunlar proje ekibine verilecek ve sistem için çalışma planları olacak. Bu, çoğu müşteri için geçerli olacaktır, ancak (evet, her zaman bir ama vardır) teklif bir Teklif İsteğine (RFP) yanıt olarak veriliyorsa, RFP'ye uymanız gerekir. Ayrıca, bir hükümet veya askeri kurum muhtemelen bir yazılım geliştirme teklifinin nasıl hazırlanacağına dair katı yönergelere sahip olacaktır ve sistemin karmaşıklığına bağlı olarak birkaç sayfa (10, 20, 30, 50 veya daha fazla) içerebilir.Bu kural, resmi bir teklif sürecine sahip olabilecek büyük kuruluşlar için, özellikle bir kamu kuruluşuysa ve Sarbannes-Oxley veya ISO düzenlemelerine veya standartlarına uymaları gereken büyük kuruluşlar için hala geçerlidir.

Yönetici Özeti

Teklif 20 sayfadan fazlaysa, teklifin bir sayfalık bölümü olan Yönetici Özeti sağlamayı düşünebilirsiniz. Hatta bir PowerPoint formatında bir Yönetici Özeti de sağlayabilirsiniz. Yazılım geliştirme teklif sunumunda bir Yönetici Özeti kullanmayı planlıyorsanız, teklifi Yönetici Özetini kullanarak sunun ve yönetici, bir iş uçuşu sırasında olduğu gibi, daha sonraki bir zamanda teklifi okuyabilir.

Şablon

Aşağıdaki taslak aslında kendi yazılım geliştirme teklifinizi hazırlamak için kullanabileceğiniz iyi bir şablondur. Teklif hazırlarken her zaman Asansör Konuşması kuralını aklımda tutarım ve siz de yapmalısınız. Temel olarak Asansör Konuşması, teklifinizin, teklif sunma yolunda bir binanın zemin katından en üst katına asansörle çıkma süresinden çok daha uzun olmaması gerektiğini belirtir.

Proje Başlığı

Teklif Üzerine Alt Başlık veya Özet Bilgi ile

Teklifin bir başlığı ve yazılım teklifinin içeriğini özetleyen bir alt bölümü olmalıdır. Ayrıca, projenin amaçlandığı bölüm, hizmet, departman veya kuruluşun adını da dahil edersiniz.

Bir RFP'ye (Teklif İsteği) yanıt veriyorsanız, RFP'de gerekli olan veya zorunlu olarak listelenen tüm bilgileri ekleyin. İlk sayfadaki başlığa ek olarak onay imzalarını da koymanızı isteyen RFP'leri de gördüm, ancak bu örnekte imzaları Değişiklikler bölümü olan sayfaya koydum.

İçindekiler

Sonraki sayfada, teklifin ana bölümlerini listeleyen bir içindekiler tablosu eklemelisiniz. Teklif beş sayfayı aşıyorsa veya RFP gerektiriyorsa, isteğe bağlı olarak sayfa numaralarını ekleyebilirsiniz.

Onaylar

Bu bölüm, ister bir RFP'ye bir yanıt olsun, ister bu şablondan veya başka bir kaynaktan olsun, süreç için çok önemlidir. Bu bölüm, projenin devam ettiğine dair teyitleri belgeler ve projenin çeşitli üyeleri arasında bağlayıcı bir anlaşma sağlar. Gerekli tüm imzaları alana kadar asla bir projeye başlamamalısınız ve proje şampiyonu ve paydaşlardan projeye başlamak için bir taahhütte bulunmalısınız. Aksi takdirde, proje iptal edilirse veya projenin kapsamı veya teslimatları değişirse kendinizi bir bağın içinde bulabilirsiniz.

Onaylar yürürlükteyken, kapsam ve teslim edileceklerde değişiklik yapmak çok daha zordur ve anlaşmazlıklar varsa, imzalanmış onaylara sahip olmak, neyin üzerinde anlaşmaya varıldığına dair net bir anlayış sağlayacaktır. Elbette her zaman bir yorumlama sorunu vardır.

Onaylar kişinin adını, unvanını, ardından imzasını ve son olarak belgenin imzalandığı tarihi içermelidir.



İsim	Başlık / Rol	İmza	Tarih

Değişiklikler

Değişiklikler bölümü, Yazılım Geliştirme Teklifi belgesinde yapılan veya yapılacak tüm değişikliklerin bir günlüğünü sağlar. Projenin kendi kapsamında veya projenin başka herhangi bir yönündeki herhangi bir değişikliği belgelemez. Değişiklikler bölümü asgari olarak değişikliği yapan kişinin adını, değişikliğin tarihini ve değişikliğin bir yorumunu veya açıklamasını içermelidir.



Yazar	Değişim Tarihi	Açıklama veya Yorum

Sözlük ve Kısaltmalar

Herhangi bir terimi veya kısaltmayı ve bunların tanımlarını listeleyin. Herkesin terimlerin veya kısaltmaların anlamını bildiğini varsaymayın, özellikle dışarıdan danışmanlar kullanmayı planlıyorsanız ve terimler şirket kültürünüze ve dilinize gömülü ise. Her organizasyonun kendi dili ve kısaltmaları vardır. Uygun şekilde belgelendirildikleri sürece bunları teklifte kullanmakta sakınca yoktur.

Ayrıca sektöre özgü kısaltmalar kullanılırsa, bunların da belgelenmesi gerekir, böylece herkes terimlerin ve kısaltmaların anlamını net bir şekilde anlar ve daha iyi yorumlar formüle eder.

Aşağıdaki kısaltmalar mevcut şablondan alınmıştır. Örnek olarak verilmiştir.

RFP: Teklif İsteği
YG: Yatırım getirisi
CAGR: Bileşik Yıllık Büyüme Oranı
IT: Bilgi Teknolojisi
CAPEX: Sermaye Harcaması
Ölçü Birimi: Ölçü Birimi

Dürbün

Teklifin kapsamı, nelerin dahil edilip nelerin hariç tutulduğunu, genel proje ayrıntılarını yüksek düzeyde ana hatlarıyla belirtmelidir. Kapsam, genel bir tanım, projenin uzunluğu ve ana hedefler sağlamalıdır. Önerilen yazılım geliştirme projesine yapılan bu yatırımla neyi başarmaya çalışıyorsunuz?

Zaman çizelgesi

Bu bölüm, başlangıç ve bitiş tarihlerini (tahmini) içerecektir. Bir tampon oluşturduğunuzdan ve beklenmedik durumlar için plan yaptığınızdan emin olun. İyi bir Kural, zaman çizelgenize% 75 tampon eklemektir.

Proje Üyeleri

Proje üyeleri proje şampiyonunu ve paydaşları içermelidir. Şampiyon genellikle genel projeyi ve bütçeyi yöneten bir yöneticidir. Paydaş genellikle dahili bir destekçi veya sponsordur. Ayrıca, projenin kapsamına ve veya yazılım geliştirme teklifini talep eden organizasyon türüne bağlı olarak şampiyon olabilirler. Kalan liste, insanların bir projede gerçekleştirdiği tipik rolleri içerir.

Aşağıdakiler sadece proje katılımcılarının sahip olabileceği rol türlerine bir örnek olarak verilmiştir. Bazı kişilerin birden fazla rolü olabilir. Projenin kapsamına bağlı olarak, proje üyeleri listesi çok uzun olabilir veya aynı kişi farklı roller üstlenebilir.

Liste, kişiyi, projedeki rolünü, onlara nasıl ulaşılacağını ve sorumluluklarının neler olduğunu doğru bir şekilde tanımlayan her türlü bilgiyi içermelidir. RFP'ye veya birlikte çalışacağınız kuruluşun türüne ve iç politikalarına bağlı olarak başka bilgiler ekleyebilirsiniz.



Takım üyesi	Rol	İletişim bilgileri	Sorumluluklar
	Şampiyon
	Menfaat sahibi
	Proje Müdürü
	Mimar
	Analist
	Geliştirici

İş fırsatı

Mevcut şablonların çoğu bu bölümü "İş Sorunu" veya "Sorun Bildirimi" olarak tanımlamaktadır, ancak iş birimlerinde veya süreçlerinde bir sorun yaşadıkları gerçeğine gücenen iş liderleriyle sık sık karşılaştım. Bir yönetmenin tam anlamıyla beni ofisinden attığını hatırlıyorum çünkü bir süreci düzelttiğimizi söylemiştim ve bana bir sorunu olup olmadığını dikte edecek kişinin BT (Bilgi Teknolojisi) 'den biri olmayacağını söyledi. süreçleriyle ya da değil.

Bu yüzden ifadelere dikkat edin. Her zaman "İş Fırsatı" terimini kullanırım çünkü sonunda teklif, bir süreci iyileştirmek, bir süreci desteklemek veya bir süreci otomatikleştirmek için bir iş fırsatına yanıt olarak sunulur



İş Bildirimi	Sistem gereksinimi nasıl karşılayacak
Etkilenen iş süreci, durum, sorun	Önerilen çözüm, hedef iş alanını nasıl geliştirecek?
Ne ihtiyaç karşılanıyor	Mevcut proje bunu nasıl ele alacak?

Çözüme Genel Bakış

Çözüme Genel Bakış bölümünde, sisteme üst düzey bir genel bakış sağlayabilirsiniz. Teklif bir web sitesi veya web uygulaması içinse, bu genel bakış bir navigasyon haritası içerebilir. Ayrıca süreç akışının bir akış çizelgesini de ekleyebilirsiniz. Ayrıca, sistemin ana bileşenlerinin bir şemasını da ekleyebilirsiniz.

Buradaki amaç, kararı veren kişiye sistemin ne olduğunu, nasıl çalışacağını ve temel yapı taşlarının neler olduğunu anlaması için yeterli bilgi vermektir. Elbette, bu yalnızca bir kılavuzdur, çünkü bir kuruluş teklifte sunmanız gerekenleri tanımlayan resmi bir formata sahip olabilir, özellikle de bir devlet kurumu veya savunma bakanlığı ile uğraşıyorsanız.

Özellikler ve Çıktılar

Bu bölüm, önerilen sistemin bir özelliğini somut bir çıktıyla eşleştirmek için bir mekanizma sağlar. Ayrıca, teslimatı tamamlamak için bir zaman tahmini içeren bu bölümü de gördüm, ancak bunu kullanmayı sevmiyorum çünkü çok kısıtlayıcı ve bir bağ oluşturuyor. Proje üzerinde çalışırken, teslim edilecekler tam olarak yazıldığı gibi sıralanmayabilir Bu nedenle, bir teslimatı belirli bir zamana kadar bitirmek için kağıt üzerinde taahhüt verdiyseniz, daha sonra projeyi fiilen yaparken herhangi bir esnekliği kaldırır veya azaltır.

Eklenebilecek diğer bir sütun, Teslim Edilebilir'in ait olduğu Yayın'dır. Bu, proje daha uzun bir süre boyunca teslim edilecekse ve birkaç sürüm olacaksa kullanışlıdır. Bu, her bir özelliğin veya Kullanıcı Hikayesinin bir Sürüme ait olduğu Çevik veya Yalın tabanlı bir proje için de geçerli olabilir.

Kavram basittir; sistemdeki her özellik için, özelliğin adını, kısa bir açıklamayı ve hangi teslim edilebilir özellik, özellik gereksinimini karşılayacaktır.



Özellik	Açıklama	Teslim edilebilir

Bütçe ve YG

Bütçe ve YG, muhtemelen bazı yöneticiler için en önemli kısımdır. Hepsi, sistemin kendilerine ne kadara mal olacağını veya bu projenin departman bütçeleri üzerinde ne kadar etkisi olacağını bilmek konusunda endişeli. Bu, özellikle mali yılın başında proje Capex'e dahil edilmediyse geçerlidir.

Bazen, proje için bütçelenmiş olsa bile, başka bir proje mevcut tekliften öncelikli olabilir ve fonlar amaçlanan kaynağından yönlendirilebilir. Yürütme ve yönetim düzeyinde, bir projeyi zeminden çıkarmak için genellikle bir miktar siyasi çekişme yaşanır ve genellikle planlanan projelerden öncelikli olabilecek öngörülemeyen koşullar vardır.

Bu nedenle, müzakerelere yardımcı olmak için paydaşınızla birlikte çalışmaya hazır olun veya bir bütçe durumu ters giderse çalışan bir çözüm sağlamak için esnek ve proaktif olun. Projeyi bütçe gerçekliğine uyarlamak, hatta sistem çıktılarını daha uzun bir süreye yaymak veya hatta projeden uzaklaşmak daha iyidir. Bir proje üzerinde çalışıp para almamak ve yolun aşağısında dava açmak zorunda kalmaktansa oradan uzaklaşmak çok daha iyidir.

Aşağıdaki tablo, size bir bütçenin nasıl hazırlanacağına dair bir fikir vermek amacıyla sadece tanıtım amaçlıdır. Doğal olarak, projenize uyması için kendi satır öğelerinizi eklemeniz gerekecektir. Ardından miktarı, birim fiyatı, ölçü birimini ve toplam kalemini girersiniz. Ardından, alt kısımdaki satır öğesi toplamlarını hesaplayın.

Bu, yazılım projesini yapmak için gereken yatırımın iyi bir resmini sağlayacaktır. Birlikte çalıştığım çoğu yönetici, geri dönüş oranının ne olacağını veya bu projenin zaman içinde ne kadara mal olacağını bilmek ister, bu nedenle, ya kendi tahminlerimi ve varsayımlarımı kullanarak basit bir ROI değeri ve bir CAGR de dahil ediyorum (açıklanmış) teklifte veya verilen tahmin ve varsayımları kullanarak.



Proje Öğesi	Miktar	Birim fiyat	Ölçü birimi	Toplam
Yazılım lisansı
Makine (ler)
Sunucu Lisansı
Veritabanı lisansı
Geliştirme Danışmanı
Proje Yönetimi
Eğitim (Zaman + Malzemeler)

ROI

ROI hesaplaması çok kolaydır. Temel olarak formül kazançtır - maliyetin maliyete bölünmesi. Formül aşağıda verilmiştir:

Tek dezavantajı, hesaplamanın zaman almamasıdır, bu nedenle ROI kısa vadeli projeler için iyidir, ancak uzun vadeli projeler için genellikle bir CAGR (Bileşik Yıllık Büyüme Oranı) dahil ediyorum. CAGR hesaplaması, belirli bir zamandaki yıllık getiri oranıdır.

YBBO

CAGR formülü:

İlk bölüm, bitiş değerinin başlangıç değerine bölünmesidir. Sonuç, yatırım yapılan yıl sayısı içinde 1 gücüne yükseltilir. Elde edilen değer 1 çıkarılır.

Faydaları

Bu bölümde, yazılım projesinin sağlayacağı ticari faydaları listelersiniz. Genel hedeflerle bağlandıkları sürece madde işareti biçiminde listelenebilirler. Yazılımın veya sistemin iş değerini nasıl artıracağını göstermeleri gerekir.

Özetle, önerilen çözüm işletmenin daha başarılı olmasına ve açıklama hedeflerine ulaşmasına nasıl yardımcı olacak? Olumlu sözler ve cümleler kullanın.

Kısıtlamalar

Kısıtlamalar bölümü, öngörebileceğiniz tüm somut ve soyut kısıtlamaları listelemelidir. Bu, ekipmanla ilgili olabilir, örneğin çoğu fabrikanın yılda en az bir kez yaptığı üretim tesisinin kapatılması gibi bazı mevsimsellik faktörleri.

Kısıtlamaları küçümsemeye çalışın veya asgari düzeyde resmetmeye çalışın. Yazılımın veya sistemin olumsuz yönlerini listelemeyin veya gerekiyorsa geçici çözümler sunun.