Program yaptırmak istiyorum diyorsanız, ilk hazırlamanız gereken şey uzun bir özellik listesi değildir. Önce işletmenizde hangi işin aksadığını, bu işi kimlerin yaptığını ve programın hangi sonucu üretmesini beklediğinizi açıklayın. Böylece yazılımcıyla görüşürken yalnızca ekranlardan değil, çözülecek iş probleminden konuşabilirsiniz. Bu rehber; ihtiyaçlarınızı toplamanızı, ilk sürümün sınırlarını belirlemenizi ve karşılaştırılabilir teklifler istemenizi sağlayan bir hazırlık yöntemi sunar.

Program yaptırmak istiyorum diyen bir işletme için stok programı, müşteri takip sistemi veya yönetim paneli aynı başlangıç sorusuna ihtiyaç duyar: Bugünkü çalışma biçiminde ne değişmeli? Örneğin çalışanların aynı siparişi farklı dosyalara yazması, bir ürünün mevcut miktarının bilinmemesi veya müşteri görüşmelerinin kişilerin telefonlarında kalması farklı sorunlardır. Bunları tek bir “otomasyon istiyoruz” cümlesinde toplamak, teklifin kapsamını belirsiz bırakır. Ayrı ayrı tanımlamak ise öncelik belirlemeyi kolaylaştırır.

Buradaki liste bir sözleşme veya hazır fiyat teklifi değildir. Yazılım görüşmesine hazırlık aracıdır. Gereksinimler geliştirme sırasında değişebilir; önemli olan değişikliklerin konuşulabileceği ortak bir başlangıç oluşturmaktır. HD Bilgisayar’ın özel yazılım geliştirme hizmetini incelerken de aynı soruları kendi işletmeniz için kullanabilirsiniz. Teknik terimleri önceden öğrenmek zorunda değilsiniz; işinizi açık örneklerle anlatmanız daha değerlidir.

Program yaptırmak istiyorum: Önce problemi tarif edin

“Her şeyi tek ekrandan yönetmek istiyorum” anlaşılır bir istektir ancak geliştirilecek işlevleri tek başına açıklamaz. Bunun yerine mevcut bir işlemi başından sonuna anlatın. Müşteri talebi nereden geliyor, kim kaydediyor, teklif nerede hazırlanıyor, onay nasıl alınıyor ve teslim bilgisi kime ulaşıyor? Her geçişte kullanılan dosyaları ve yapılan tekrarları not edin. Birkaç gerçek işlem üzerinden yürümek, toplantıda hatırlanması zor ayrıntıları görünür kılar.

Program yaptırmak istiyorum diyenler problemi anlatırken teknik çözümü hemen belirlemek zorunda değildir. “Mobil uygulama gerekiyor” demeden önce çalışanların sahada hangi bilgiye erişemediğini açıklayın. Belki telefondan açılan basit bir web ekranı yeterli olacaktır; belki çevrimdışı çalışma nedeniyle farklı bir çözüm gerekecektir. İhtiyaçla teknik çözümün ayrılması seçenekleri açık tutar. Başlangıç belgesinde sorun, etkilediği kişi ve beklenen iyileşme ayrı satırlarda bulunursa sonraki kararların gerekçesi de izlenebilir.

Hazır program mı, işletmeye özel yazılım mı?

Program yaptırmak istiyorum diyerek seçenekleri araştırırken her işletme problemi için özel yazılım geliştirmek gerekmediğini unutmayın. Hazır bir ürün mevcut sürecinizin büyük bölümünü karşılıyorsa, uyarlama ve eğitimle ilerlemek daha uygun olabilir. Önce deneme hesabı üzerinden gerçek bir işlem yapın. Ürün kaydı oluşturmak, sipariş almak, rapor indirmek ve kullanıcı yetkisi tanımlamak gibi temel işleri deneyin. Yalnızca satış sunumunu izlemek yerine kendi verinizin küçük ve kişisel bilgi içermeyen bir örneğiyle değerlendirme yapın.

Özel yazılım seçeneği; size özgü onay zincirleri, mevcut sistemlerle bağlantılar veya hazır ürünün desteklemediği iş kuralları varsa anlam kazanabilir. Karşılaştırmayı yalnızca başlangıç ücretine göre yapmayın. Lisans, barındırma, güncelleme, destek ve veri dışarı aktarma koşulları da kararın parçasıdır. Hangisinin daha ucuz olacağını kapsam bilinmeden söylemek doğru olmaz. Görüşmeye giderken değerlendirdiğiniz hazır ürünleri ve karşılamadıkları somut ihtiyaçları paylaşın; böylece gereksiz geliştirme ihtimali azalır.

İhtiyaç listesini 7 adımda hazırlayın

1. Birinci iş problemini seçin

Program yaptırmak istiyorum diyorsanız ilk adım, programın çözmesini istediğiniz en önemli sorunu tek cümlede yazmaktır. Örneğin “Satış ekibi güncel stok bilgisini göremediği için müşteriye yanlış teslim tarihi veriyor” ifadesi, “stok sistemi lazım” cümlesinden daha kullanışlıdır. Ardından sorunun hangi sıklıkta yaşandığını ve nasıl fark edildiğini belirtin. Elinizde ölçüm yoksa tahmini bilgiyi kesin veri gibi yazmayın; başlangıçta ölçülmesi gereken bir başlık olarak işaretleyin.

Program yaptırmak istiyorum diyorsanız sorunun işletmenizdeki etkisini açıklamak da önemlidir. İş tekrar mı yapılıyor, müşteriye dönüş mü gecikiyor, yönetici raporu hazırlamak için dosya mı birleştiriyor? Etkiyi açıklamak, geliştirilecek ilk modülün seçilmesine yardımcı olur. Bu aşamada tüm departmanların bütün taleplerini aynı öncelikte toplamayın. Önce ortak bir problemi seçmek, küçük ama çalışan bir ilk sürümün sınırlarını belirlemeyi kolaylaştırır. Diğer talepleri silmeden sonraki aşamalar listesinde saklayabilirsiniz.

2. Kullanıcıları ve yetkileri belirleyin

Program yaptırmak istiyorum düşüncesiyle kullanıcı listesi hazırlarken kişileri yalnızca sayılarıyla değil, yaptıkları işle tanımlayın. Satış temsilcisi müşteri ve teklif oluşturabilirken depo çalışanı ürün çıkışını işleyebilir. Yönetici raporları görebilir fakat her yöneticiye tüm verileri değiştirme yetkisi gerekmeyebilir. Kimin hangi kaydı göreceğini, oluşturacağını, değiştireceğini ve sileceğini ayrı ayrı düşünün. “Herkes her şeyi görsün” kararı başlangıçta kolay görünse de günlük kullanımda karışıklığa yol açabilir.

Program yaptırmak istiyorum diyerek yetkileri planlarken bir çalışanın işten ayrılması, görevinin değişmesi veya geçici olarak başka şubede çalışması durumlarını da konuşun. Erişim kapatma ve yetki değiştirme işlemlerinden kimin sorumlu olacağı belli olsun. Müşteriler sisteme girecekse onların erişimi çalışanlardan ayrı değerlendirilmelidir. Kullanıcı sayısının ileride artması bekleniyorsa bunu tahmin olarak belirtin. Kesin büyüme rakamı vermeniz gerekmez; aynı anda kaç kişinin işlem yapabileceğini bilmek teknik değerlendirme için yararlıdır.

3. Mevcut iş akışını sırayla yazın

Program yaptırmak istiyorum diyenler için iş akışını açıklamanın pratik yolu, bir işlemi başlangıç, kontrol, onay ve sonuç adımlarına ayırmaktır. Örneğin satın alma talebi çalışan tarafından açılır, yönetici kontrol eder, uygun bulunursa sipariş oluşturulur ve ürün geldiğinde teslim kaydı girilir. Her adımda hangi bilgiye ihtiyaç olduğunu ve sonraki adımı neyin başlattığını belirtin. Bu çalışma için özel çizim programı şart değildir; numaralı bir liste ve örnek belge çoğu zaman başlangıç için yeterlidir.

Program yaptırmak istiyorum diyen bir işletme yalnızca sorunsuz ilerleyen işlemi anlatmamalıdır. Talep reddedilirse, sipariş kısmen gelirse veya yanlış ürün kaydedilirse ne olacağını da ekleyin. İptal ve düzeltme adımları sonradan düşünülürse ekranların yeniden düzenlenmesi gerekebilir. Sürecin hangi noktalarında bildirim beklendiğini belirtin ancak her işlem için bildirim üretmeyi hedeflemeyin. Gereksiz uyarılar kullanıcıların önemli mesajları da görmezden gelmesine neden olabilir. Bildirimin alıcısı, zamanı ve amacı açık olmalıdır.

4. Verileri ve örnek belgeleri toplayın

Program yaptırmak istiyorum diyorsanız programda tutulacak müşteri, ürün, sipariş ve ödeme gibi kayıtları listeleyin. Her kayıt için gerekli alanları yazın: Ürün kodu zorunlu mu, aynı müşteri birden fazla şubeyle çalışabilir mi, siparişte birden fazla teslim adresi olabilir mi? Bu sorular ekranda görünen kutulardan daha fazlasını belirler. Kayıtların birbirleriyle ilişkisi raporları, aramaları ve veri aktarımını etkiler. Örnek bir ürün veya sipariş kartı üzerinden konuşmak açıklamaları somutlaştırır.

Program yaptırmak istiyorum diyerek mevcut dosyaları paylaşmadan önce kişisel ve ticari bilgileri ayıklayın. Gerçek müşterilerin adları, telefonları veya fiyat anlaşmaları yerine örnek değerler kullanılabilir. Dosyanın sütun yapısını göstermek için tüm müşteri listesini göndermek gerekmez. Eski verinin yeni programa aktarılması isteniyorsa dosya biçimini, kayıt sayısını ve bilinen eksikleri not edin. Yinelenen kayıtların nasıl birleştirileceği ve eski sistemin ne zaman kapatılacağı ayrı bir veri geçişi planında değerlendirilmelidir.

5. İlk sürümün sınırını çizin

Program yaptırmak istiyorum diyen işletmeler taleplerini “ilk kullanım için zorunlu”, “yararlı ama bekleyebilir” ve “ileride değerlendirilecek” şeklinde ayırabilir. Bu ayrım kalıcı bir vazgeçiş değildir. Amaç, birbirinden bağımsız özelliklerin ilk teslimi geciktirmesini önlemektir. Örneğin müşteri ve teklif takibi başlamadan gelişmiş satış tahmini üretmek anlamlı olmayabilir. Önce düzenli veri toplanmasını sağlayan işlevleri kurmak, sonraki raporların doğru temele dayanmasına yardımcı olur.

Program yaptırmak istiyorum diyenler ilk sürümdeki her zorunlu özellik için neden gerekli olduğunu yazabilir. Bir talebin tek gerekçesi “başka programda gördük” ise işletmenizde hangi işe yarayacağını yeniden değerlendirin. İlk sürümün sonunda kullanıcıların hangi işi programdan tamamlayabileceği açık olsun. Ayrıca kapsam dışında kalanları da belirtin: Muhasebe bağlantısı, mobil uygulama veya çoklu dil desteği ilk aşamada olmayabilir. Yazılı sınırlar, tekliflerin aynı iş için hazırlanmasını ve sonraki taleplerin ayrı değerlendirilmesini kolaylaştırır.

6. Entegrasyon ve çalışma ortamını açıklayın

Program yaptırmak istiyorum diyerek görüşmeye hazırlanırken programın bağlanacağı muhasebe sistemi, e-ticaret altyapısı, kargo hizmeti veya başka bir uygulama varsa adlarını ve kullanılan sürümleri paylaşın. Bir sistemin adını bilmek entegrasyonun kesin yapılabileceğini göstermez. Veri erişimi, sağlayıcının sunduğu API, izinler ve varsa ek kullanım ücretleri incelenmelidir. Henüz araştırılmamış bağlantıları “inceleme gerektiriyor” olarak işaretlemek, teklifin varsayımlarını açık tutar. Parola ve erişim anahtarlarını ilk ihtiyaç belgesine yazmayın.

Program yaptırmak istiyorum diyen bir işletmenin çalışma ortamı da çözümü etkiler. Kullanıcılar yalnızca ofisteki bilgisayarlardan mı girecek, sahada telefon kullanacak mı, internet kesildiğinde işlem devam etmeli mi? Barkod okuyucu, etiket yazıcı veya başka cihazlar kullanılacaksa modellerini belirtin. Web tabanlı bir uygulamanın her cihazla sorunsuz çalışacağını varsaymayın. Tarayıcı desteği ve cihaz denemeleri ayrıca değerlendirilir. Özel ağ, uzaktan erişim veya şirket içi sunucu beklentileri varsa bunlar da başlangıç görüşmesinde gündeme gelmelidir.

7. Teslim ölçütlerini yazın

Program yaptırmak istiyorum diyorsanız “program düzgün çalışacak” ifadesinin teslimi değerlendirmek için yeterli olmadığını bilmelisiniz. Bunun yerine kullanıcı tarafından denenebilen sonuçlar yazın. Örneğin satış kullanıcısı teklif oluşturduğunda kayıt numarası oluşmalı, onaylanan tekliften sipariş açılabilmeli ve yetkisiz kişi satış fiyatını değiştirememelidir. Her sonuç için deneme adımını ve beklenen davranışı belirtin. Böylece teslim toplantısında yalnızca ekranların açılıp açılmadığına değil, işin tamamlanıp tamamlanamadığına bakılır.

Bu yaklaşım, kullanıcı ihtiyacını rol, amaç ve faydayla açıklayan kullanıcı hikâyeleri ile birlikte kullanılabilir. Örneğin “Depo görevlisi olarak çıkış yapmadan önce kullanılabilir miktarı görmek istiyorum” cümlesi bir başlangıçtır. Kabul ölçütleri bunun hangi koşullarda sağlanacağını netleştirir. Testte örnek verileri, sonucu kontrol edecek kişiyi ve hataların nasıl bildirileceğini belirleyin. Teslim sonrasında destek ve değişiklik taleplerinin hangi kapsamda ele alınacağı ayrıca konuşulmalıdır.

Görüşmeye götüreceğiniz kısa ihtiyaç belgesi

Program yaptırmak istiyorum diyen bir işletmenin başlangıç belgesi onlarca sayfa olmak zorunda değildir. İlk bölümde işletmenin çalışma alanını ve çözülmek istenen problemi açıklayın. İkinci bölümde kullanıcıları ve temel iş akışını gösterin. Ardından ilk sürümün işlevlerini, veri kaynaklarını ve bilinen bağlantıları sıralayın. Son bölümde teslim ölçütlerini ve henüz cevaplanmamış soruları bırakın. Belirsiz başlıkları saklamak yerine görünür kılmak, görüşmenin verimini artırır ve hatalı varsayımları azaltır.

Program yaptırmak istiyorum diyerek hazırladığınız belgeyi bir sürüm numarası veya tarihle kaydedin. Toplantı sonrasında değişen kararları aynı dosyaya işleyin ve ilgili kişilerle paylaşın. Bir talep kaldırıldıysa nedenini kısa notla belirtmek ileride aynı tartışmanın tekrarını önler. Görüşmeye yalnızca karar verici değil, işi günlük olarak yapan bir kişinin de katılması yararlı olabilir. Yöneticinin görmek istediği raporlarla çalışanın veri girebildiği ekranların birlikte değerlendirilmesi, kullanım güçlüklerinin daha erken fark edilmesine yardımcı olur.

Program yaptırmak istiyorum diyenler için kontrol listesi

Aşağıdaki listeyi ilk görüşmeden önce doldurun. Her başlığa uzun cevap vermeniz gerekmez; bir örnek işlem ve açık bir ihtiyaç çoğu zaman genel ifadelerden daha yararlıdır. Cevabını bilmediğiniz maddeleri boş bırakmak yerine “birlikte değerlendirilecek” diye işaretleyin. Böylece görüşmenin hangi soruları çözmesi gerektiği anlaşılır. Bu liste fiyatı tek başına belirlemez; kapsamın daha anlaşılır konuşulmasını sağlar.

• Çözülmesini istediğiniz ana problemi bir cümlede yazın.
• İşlemi yapan kullanıcıları ve görevlerini belirtin.
• Günlük çalışma akışını başlangıçtan sonuca sıralayın.
• İptal, hata ve düzeltme durumlarını ekleyin.
• Kişisel bilgi içermeyen örnek kayıtlar hazırlayın.
• İlk sürümün zorunlu işlevlerini ayırın.
• Bağlanacak sistemleri ve kullanılan cihazları listeleyin.
• Teslimde denenecek somut işlemleri belirleyin.

Teklifleri hangi başlıklarda karşılaştırmalısınız?

Program yaptırmak istiyorum diyerek aldığınız iki teklif, aynı başlığı taşısa bile farklı işleri kapsayabilir. Bir teklif veri aktarımını içerirken diğeri yalnızca boş sistem kurulumu sunabilir. Birinde eğitim ve test süreci bulunabilir, diğerinde bunlar ayrıca fiyatlandırılabilir. Bu nedenle tutarı karşılaştırmadan önce işlev listesinin, teslimlerin ve kapsam dışı başlıkların eşleştiğini kontrol edin. İhtiyaç belgenizi her firmaya aynı haliyle iletmek başlangıçta eşit bir değerlendirme zemini oluşturur.

Program yaptırmak istiyorum diyenler teklifte hangi varsayımların bulunduğunu da sormalıdır. Kullanıcı sayısı, veri miktarı, entegrasyon erişimi ve müşteri tarafından sağlanacak içerikler süreyi etkileyebilir. Ödeme planını yalnızca takvim tarihleriyle değil, tanımlanmış teslimlerle birlikte değerlendirin. Kaynak kod, kullanım hakkı, barındırma ve bakım koşullarını ayrıca okuyun. Bunların tüm projelerde aynı şekilde sunulduğunu varsaymayın. Görüşmede verilen bir açıklamanın sizin için önemli olması halinde teklif metnine de açık biçimde eklenmesini isteyin.

Bütçe ve süre konuşulurken ne paylaşılmalı?

Program yaptırmak istiyorum diyen işletmenin bütçe aralığı paylaşması, ekibin hangi kapsamın ilk aşamaya sığabileceğini değerlendirmesini kolaylaştırabilir. Ancak karşılığında hangi teslimlerin sunulduğunu açıklayan bir çalışma bekleyin. Bütçeyi sadece geliştirme bedeli olarak düşünmeyin. Alan adı, barındırma, dış hizmet ücretleri, veri taşıma ve kullanım desteği gibi kalemlerin hangilerinin geçerli olduğunu sorun. Her projede aynı giderler oluşmaz; amaç olmayan bir masrafı eklemek değil, mevcut kalemleri açıkça görmektir.

Program yaptırmak istiyorum diyerek takvim konuşurken süre beklentinizi bir gerekçeyle anlatın. Yeni şubenin açılışı veya eski programın kullanımının sona ermesi gibi tarihler planı etkileyebilir. Buna rağmen inceleme yapılmadan kesin teslim günü beklemek sağlıklı değildir. Örnek ekranların değerlendirilmesi, geri bildirim, test ve veri geçişi için sizin tarafınızda da zaman ayrılmalıdır. Proje sorumlusunun geç yanıt vermesi veya veri hazırlığının tamamlanmaması geliştirme takvimini etkileyebilir. Sorumlulukları ve karar bekleyen başlıkları birlikte takip edin.

Örnek senaryo: Sipariş bilgisini tek yerde toplamak

Bir toptan satış işletmesi düşünelim. Siparişler telefon ve mesajla geliyor, satış çalışanı bunları bir tabloya yazıyor, depo ise farklı bir dosyadan hazırlanacak ürünleri takip ediyor. Müşteri sipariş durumunu sorduğunda birkaç kişiye danışılması gerekiyor. İşletmenin ilk isteği kapsamlı bir yönetim programı olabilir. Fakat hazırlık görüşmesinde asıl problemin sipariş bilgisinin farklı yerlerde tutulması olduğu görülür. Bu senaryo açıklama amaçlıdır; gerçek bir müşteri sonucu değildir.

İlk sürüm için müşteri kaydı, sipariş oluşturma ve hazırlık durumunun güncellenmesi seçilir. Muhasebe bağlantısı ve gelişmiş raporlar sonraki aşamaya bırakılır. Depo kullanıcısının fiyat alanlarını görmemesi, satış kullanıcısının da teslim edilmiş siparişi doğrudan değiştirememesi istenir. Örnek verilerle birkaç sipariş hazırlanır. Eksik ürün, kısmi hazırlık ve iptal durumları ayrıca yazılır. Böylece geliştirme ekibine yalnızca ekran isimleri değil, işlemlerin nasıl ilerlemesi gerektiği anlatılmış olur.

Testte amaç, siparişin kayıt altına alınması ve durumunun yetkili kullanıcı tarafından izlenebilmesidir. Beklenen sonuç sağlanmadan daha fazla özellik eklemek yerine temel akış düzeltilir. Kullanım başladıktan sonra hangi raporların gerçekten gerekli olduğu daha net görülebilir. Bu örnekten belirli bir zaman veya maliyet tasarrufu yüzdesi çıkarılamaz. Böyle bir değerlendirme için uygulama öncesi ve sonrası aynı yöntemle ölçülen veriler gerekir. Önce ölçülebilir hedef belirlemek, sonucu sonradan değerlendirebilmeyi sağlar.

Program yaptırırken sık yapılan yanlışlar

Bütün özellikleri ilk sürüme koymak

Her talebi ilk teslimin şartı haline getirmek, temel iş akışının kullanılmaya başlanmasını geciktirebilir. Ayrıca kullanıcıların henüz denemediği ekranlara dayanarak ayrıntılı beklentiler oluşturmasına yol açar. Öncelik belirlemek eksik ürün istemek değildir; ilk sürümde kendi başına tamamlanan bir işi seçmektir. Sonraki talepleri kayıt altında tutarak bunların ne zaman ve hangi koşulda değerlendirileceğini konuşabilirsiniz. Kararları sözlü bırakmak yerine kısa bir kapsam listesinde saklayın.

Görsel olarak beğenilen programı aynen istemek

Başka bir uygulamanın ekranı fikir verebilir, fakat aynı görünüm sizin sürecinizi karşılamayabilir. Bir ekran görüntüsünü paylaşırken hangi davranışı beğendiğinizi açıklayın: Hızlı arama mı, sade ürün listesi mi, tek ekrandan onay mı? Başka işletmenin verilerini veya erişimi kısıtlı ekranlarını izinsiz paylaşmayın. Amaç başka ürünü kopyalamak değil, kullanıcı ihtiyacını anlaşılır hale getirmektir. Kendi çalışma biçiminizi örneklerle anlatmak tasarım kararlarını daha sağlam temele oturtur.

Testi yalnızca yazılımcının yapmasını beklemek

Program yaptırmak istiyorum diyorsanız testteki rolünüzü de baştan konuşun. Teknik kontroller geliştirme ekibinin işidir; buna rağmen iş akışının gerçek ihtiyacı karşılayıp karşılamadığını işletmedeki kullanıcıların da denemesi gerekir. Normal kayıt oluşturmanın yanında yanlış, eksik ve tekrarlanan işlemleri deneyin. Sorunu bildirirken yaptığınız adımı, beklediğiniz sonucu ve gördüğünüz davranışı yazın. Ekran görüntüsü eklenebilir, ancak müşteri bilgileri görünmemelidir. Testi tek kişinin hafızasına bırakmak yerine kısa bir senaryo listesi kullanmak geri bildirimleri daha düzenli hale getirir.

Veri geçişini son güne bırakmak

Eski kayıtların yeni programa aktarılması, dosyayı yüklemekten ibaret olmayabilir. Tarih biçimleri, ürün kodları ve müşteri adları tutarsız olabilir. Bazı alanlar boş, bazı kayıtlar ise yinelenmiş olabilir. Küçük bir örnek aktarım yaparak eşleştirmeyi erkenden kontrol edin. Aktarımın sonucunu kimin onaylayacağı ve eski sistemde hangi tarihe kadar işlem yapılacağı belli olsun. Aynı anda iki yerde kayıt tutulacaksa tutarsızlıkların nasıl giderileceği ayrıca planlanmalıdır.

Teslim sonrasını konuşmamak

Program yaptırmak istiyorum diyenler için önemli bir diğer konu da teslim sonrasıdır: Programın teslim edilmesi bütün ihtiyaçların sona erdiği anlamına gelmez. Kullanıcı soruları, hata bildirimleri ve yeni işlev talepleri farklı konulardır. Bunların hangi kanaldan iletileceğini, neyin mevcut kapsamda olduğunu ve ek çalışmanın nasıl değerlendirileceğini sorun. Otomatik olarak kesintisiz destek veya belirli bir yanıt süresi sunulduğunu varsaymayın. Bakım, güvenlik güncellemeleri ve yedekleme sorumlulukları da anlaşmada açık olmalıdır. Bu konuları teklif aşamasında konuşmak sonradan beklenti farkı oluşmasını azaltır.

Hazırlıktan kullanıma geçiş planı

Program yaptırmak istiyorum düşüncesinden kullanıma geçişin hazırlık aşamasında ihtiyaç belgesi ve örnek veriler toplanır. Kapsam görüşmesinde ilk sürüm ve açık sorular değerlendirilir. Tasarım aşamasında temel ekranlar üzerinden iş akışı kontrol edilir. Geliştirme sürecinde kararlaştırılmış teslimler incelenir; değişiklikler ayrıca kayda alınır. Test aşamasında örnek işlemler tamamlanır ve sorunlar bildirilir. Kullanıma geçişte veri aktarımı, kullanıcı hesapları ve gerekli eğitim birlikte ele alınır. Her aşamanın sorumlusu ve beklenen çıktısı belli olmalıdır.

Program yaptırmak istiyorum düşüncesiyle başlayan çalışma kullanıma geçtiğinde ilk geri bildirimleri bir yerde toplayın. Her talebi acil değişiklik olarak ele almak yerine işin tamamlanmasını engelleyen sorunlarla iyileştirme önerilerini ayırın. Öncelikleri kullanıcı etkisine göre değerlendirin. İlk hafta görülen bir alışkanlık sorunu eğitimle çözülebilirken, yanlış hesaplanan bir işlem uygulamada düzeltme gerektirebilir. Hangi durumda nasıl hareket edileceğini önceden konuşmak, hem işletmenin hem geliştirme ekibinin daha düzenli çalışmasına yardımcı olur.

Temel terimler: Görüşmede duyabilecekleriniz

Gereksinim: Yazılımın karşılaması beklenen ihtiyaç veya davranıştır. “Müşteri kaydı aranabilmeli” bir başlangıç ifadesidir; hangi alanlardan aranacağı ayrıca açıklanır.

Kapsam: Projede yapılacak ve yapılmayacak işlerin sınırıdır. Bir işlevin konuşulmuş olması, otomatik olarak ilk teslim kapsamına alındığı anlamına gelmez.

İlk sürüm: Kullanıcıya belirli bir işi tamamlatan başlangıç teslimidir. Sadece görsel taslak değildir; üzerinde anlaşılmış temel iş akışının çalışması beklenir.

Entegrasyon: İki sistemin belirli kurallarla veri paylaşmasıdır. Bir siparişin başka sisteme aktarılması örnek olabilir; yön, zamanlama ve hata davranışı ayrıca belirlenir.

Kabul ölçütü: Bir işlevin beklentiyi karşılayıp karşılamadığını değerlendirmek için kullanılan somut koşuldur. Test sırasında gözlenebilir ve üzerinde anlaşılabilir olması gerekir.

Veri geçişi: Mevcut kayıtların yeni sisteme hazırlanması ve aktarılmasıdır. Temizleme, alan eşleştirme, örnek aktarım ve sonuç kontrolü bu çalışmanın parçaları olabilir.

Maltepe, İdealtepe ve Anadolu Yakası için hazırlık

Program yaptırmak istiyorum diyerek Maltepe veya İdealtepe’deki işletmeniz için yazılımcı ararken bölgesel yakınlığı bir değerlendirme başlığı olarak kullanabilirsiniz. Bunun yanında ekibin işinizi anlaması, kapsamı açıklaması ve teslim sürecini anlaşılır biçimde sunması önemlidir. Anadolu Yakası içindeki bir işletme için de Türkiye’nin başka bir şehrindeki işletme için de ihtiyaç belgesinin temel mantığı aynıdır. İletişim yöntemi, görüşme düzeni ve çalışma koşulları proje özelinde netleştirilmelidir; konuma bakarak otomatik hizmet koşulu varsayılmamalıdır.

HD Bilgisayar Yazılım Sistemleri, Maltepe’de Altayçeşme, Oba Çıkmazı No:3 adresindedir. Yazılım ihtiyacınızı konuşmadan önce bu rehberdeki ana problemi, kullanıcıları ve ilk sürüm beklentisini not edebilirsiniz. Yazılım hizmeti ve proje vitrini üzerinden çalışma alanlarını inceleyebilir, HD Bilgisayar web sitesinden iletişim bilgilerine ulaşabilirsiniz. Görüşme için 0532 396 34 71 numarasını kullanabilirsiniz. Teklif ve uygulanabilirlik, projenin gereksinimleri değerlendirildikten sonra konuşulmalıdır.

Sık sorulan sorular

Program yaptırmak istiyorum, teknik bilgi bilmem gerekir mi?

Hayır. İşinizi nasıl yaptığınızı ve nerede sorun yaşadığınızı anlatmanız başlangıç için yeterlidir. Mevcut dosya yapısı, örnek işlem ve beklenen sonuç teknik terimlerden daha yararlı olabilir. Geliştirme ekibi bu bilgileri teknik gereksinimlere dönüştürürken size sorular yöneltebilir. Anlamadığınız terimlerin günlük işinizdeki karşılığını açıklamalarını isteyin; bir kararı sadece teknik göründüğü için kabul etmek zorunda değilsiniz.

İlk görüşmede fiyat belli olur mu?

Basit ve sınırları açık bir ihtiyaçta erken değerlendirme yapılabilir. Buna karşılık veri aktarımı, farklı kullanıcı rolleri veya dış sistem bağlantıları olan işlerde inceleme gerekebilir. Program yaptırmak istiyorum diyerek hazırladığınız ihtiyaç belgesi belirsizliği azaltır ancak tek başına sabit fiyat garantisi oluşturmaz. Teklifin hangi kapsam ve varsayımlarla verildiğini öğrenin. Sonradan istenecek ek işlerin değerlendirme yöntemini de başlangıçta konuşun.

Programı önce küçük başlayıp geliştirebilir miyim?

Birçok ihtiyaç aşamalara ayrılabilir, ancak ilk sürümün kendi içinde kullanılabilir olması gerekir. Örneğin sipariş kaydı açılıyor fakat sipariş tamamlanamıyorsa iş akışı eksik kalabilir. Geliştirme ekibiyle ilk aşamada hangi işlemin baştan sona yapılacağını belirleyin. Sonraki işlevleri ayrıca listeleyin; gelecekteki her talebin mevcut yapıya değişiklik gerektirmeden eklenebileceğini varsaymayın.

Sadece Excel dosyamı göstermek yeterli mi?

Dosya iyi bir başlangıçtır, fakat kullanıcıların dosya dışında yaptıkları kontrolleri de anlatmak gerekir. Bir sütundaki değer kimin kararıyla değişiyor, yanlış kayıt nasıl düzeltiliyor ve aynı dosyada kaç kişi çalışıyor? Bu bilgiler programın davranışını etkiler. Paylaşacağınız örnekte gerçek kişi bilgilerini ve hassas ticari verileri çıkarın. Yapıyı göstermek için temsilî birkaç satır çoğu zaman yeterlidir.

Yazılım tesliminde hangi belgeleri istemeliyim?

İhtiyaca göre kullanım açıklaması, kullanıcı yetki listesi, test sonuçları ve teslim edilen işlevlerin listesi istenebilir. Barındırma, erişim, yedekleme ve destek sorumlulukları da açık olmalıdır. Kaynak kod ve kullanım hakları ayrı koşullardır; otomatik olarak devredildiğini varsaymayın. Sizin için gerekli teslimleri teklif aşamasında belirtin ve bunların hangi biçimde sağlanacağını yazılı olarak netleştirin.

Başlamak için bugün ne yapabilirsiniz?

Program yaptırmak istiyorum düşüncesini uygulanabilir bir görüşmeye çevirmek için bugün tek bir işlem seçin. O işlemin mevcut adımlarını, yaşanan sorunu ve beklediğiniz sonucu yazın. Ardından kullanıcıları, örnek verileri ve ilk sürümün sınırını ekleyin. Belgenin kusursuz olması gerekmez; anlaşılır olması yeterlidir. Böyle bir hazırlıkla yazılım görüşmesi, genel isteklerin sıralandığı bir konuşmadan somut seçeneklerin değerlendirildiği bir çalışmaya dönüşebilir.