Yazılım firması seçimi, işletmenize program yazacak bir ekibin adını belirlemekten daha kapsamlı bir karardır. İş akışınızı kimin anlayacağını, kararları nasıl kayıt altına alacağınızı ve teslim edilen uygulamayı hangi ölçütlerle değerlendireceğinizi de belirlemiş olursunuz. Bu nedenle yalnızca fiyat, ofisin yakınlığı veya gösterilen ekranların görünümü üzerinden karar vermek eksik kalır. En yararlı başlangıç, bütün adaylara aynı ihtiyacı anlatmak ve verdikleri cevapları aynı sorularla karşılaştırmaktır.

İçindekiler

Bu rehberdeki dokuz kontrol, teklif öncesinde veya ilk görüşmeler sırasında kullanılabilir. Her işletmenin ihtiyacı farklı olduğu için tek bir firma türü bütün projelere uygun değildir. Küçük bir iç araç ile gün boyunca çalışan bir sipariş sistemi aynı değerlendirme ağırlıklarına sahip olmayabilir. Amaç, adaylardan kusursuz sunumlar beklemek değil, sizin işinizle ilgili belirsizliklerin nasıl ele alındığını görmektir. Bilinmeyen bir konuda araştırma gerektiğinin söylenmesi, açıklanmadan verilen kesin bir vaatten daha değerlidir.

Yazılım firması seçimi sürecine başlamadan önce bir sayfalık ihtiyaç özeti hazırlayın. Çözülmesini istediğiniz problemi, kullanıcıları ve ilk teslim beklentisini yazın. Henüz bu belgeyi oluşturmadıysanız program yaptırmak isteyenler için ihtiyaç listesi rehberini kullanabilirsiniz. Özeti paylaşırken kesin kararlarınızla değerlendirmeye açık tercihlerinizi ayırın. Örneğin kullanıcıların telefondan erişebilmesi zorunlu olabilirken ayrı bir mobil uygulama geliştirilmesi henüz kararlaştırılmamış olabilir. Böyle bir ayrım, adayların aynı ihtiyaca farklı teknik çözümler önermesine alan bırakır.

Yazılım firması seçimi neden fiyatla başlamamalı?

Bir teklifin tutarı, hangi işi içerdiğiyle birlikte anlam kazanır. Bir ekip veri temizliğini ve eski kayıtların aktarılmasını kapsama alırken başka bir ekip yalnızca yeni uygulamayı teslim ediyor olabilir. Aynı şekilde test, kullanıcı eğitimi ve kullanım desteği farklı biçimlerde tanımlanabilir. Kapsamlar eşit değilken yalnızca toplam rakamı karşılaştırmak, farklı ürünleri aynı hizmet gibi değerlendirmektir. İlk değerlendirmede fiyatı saklamak gerekmez; fiyatın karşılığını açıklayan iş listesini de görmek gerekir.

Yazılım firması seçimi için tekliflerinizi yan yana koyduğunuzda ilk sütuna işlevleri yazın. Diğer sütunlarda adayın bu işlevi nasıl karşılayacağını, hangi varsayımla çalıştığını ve neleri kapsam dışında bıraktığını belirtin. Bir maddede cevap yoksa bunu olumsuz kanıt saymadan önce sorun. Bazen kısa bir teklifte yer almayan ayrıntı görüşmede açıklanabilir. Önemli olan, karar vermeden önce bu açıklamanın kayıtlı ve karşılaştırılabilir hale gelmesidir. Sonradan hatırlanan sözler yerine ortak bir değerlendirme belgesi kullanın.

İlk görüşmeye aynı bilgileri taşıyın

Yazılım firması seçimi sırasında adayların yetkinliklerini karşılaştırmak istiyorsanız başlangıç koşullarını mümkün olduğunca eşitleyin. Bir firmaya bütün süreç belgelerini verip diğerine sadece “stok programı istiyoruz” demek sağlıklı bir karşılaştırma üretmez. Aynı problem tanımını, örnek kayıtları, tahmini kullanıcı sayısını ve bilinen sistem bağlantılarını paylaşın. Hassas bilgileri anonimleştirin. İlk görüşmede gerçek müşteri listeleri veya çalışan parolaları gerekli değildir; kayıt yapısını temsil eden birkaç satır çoğu zaman yeterlidir.

Görüşmelerde sorulan ek soruları da listeye ekleyin. Bir adayın fark ettiği önemli bir istisna, diğer adayların da değerlendirmesi gereken bir ihtiyaç olabilir. Güncellenen belgeyi ilgili taraflara aynı şekilde iletin. Bu yöntem yazılım firması seçimi sürecinin uzaması için değil, sonradan ortaya çıkan kapsam farklarının azalması için kullanılır. Belgede kesin kararlarla henüz araştırılacak konuları ayrı işaretleyin. Böylece bir tahminin herkes tarafından bağlayıcı bir beklenti gibi anlaşılması önlenebilir.

Yazılım firması seçimi için 9 kontrol

1. İş problemini nasıl anladıklarını sorun

İlk kontrol, adayın talebinizi kendi cümleleriyle açıklayabilmesidir. “Bir yönetim paneli yaparız” cevabı yerine hangi işlemin nerede aksadığını ve hangi sonucun hedeflendiğini anlatmasını isteyin. Satışın güncel stok görememesiyle ürün sayımının tutarsız olması farklı problemler olabilir. İkisinin de bir stok ekranıyla çözüleceğini varsaymak erken bir karardır. Soruların yalnızca tasarım rengine veya kullanılacak teknolojiye yönelmesi durumunda iş akışının nasıl değerlendirileceğini ayrıca konuşun.

Yazılım firması seçimi görüşmesinde bir yanlış anlaşılma fark ederseniz bunu düzeltin ve adayın yaklaşımını gözlemleyin. Amaç, ilk dakikada her ayrıntıyı bilmesini beklemek değildir. Eksik bilgiyi nasıl tamamladığı, varsayımlarını nasıl açıkladığı ve işletmedeki farklı kullanıcıları dinleyip dinlemediği daha anlamlıdır. İhtiyaç analizi sonucunda hangi belgenin oluşacağını ve bu belgenin kim tarafından onaylanacağını sorun. Ekran listesi, iş akışı ve kabul ölçütleri arasındaki ilişki açıklanabiliyor olmalıdır.

2. Benzer iş akışındaki deneyimi değerlendirin

Aynı sektörde çalışmış olmak yararlı olabilir fakat tek başına yeterli değildir. Firmanın farklı bir sektörde geliştirdiği onay sistemi, sizin çok kademeli satın alma sürecinize daha yakın olabilir. Referans sorarken proje adının yanında hangi problemi çözdüklerini ve hangi bölümden sorumlu olduklarını öğrenin. Tasarımı yapılan bir site ile veri modeli ve iş kuralları geliştirilen bir uygulama aynı deneyim değildir. Portföydeki isimlerin büyüklüğünden çok, sizin ihtiyacınızla ilişkisine bakın.

Yazılım firması seçimi sırasında gerçek müşteri verilerine erişim istemeniz gerekmez. Anonimleştirilmiş bir demo, izinli ekran görüntüsü veya süreç açıklaması yeterli olabilir. Referansı doğrulamak istiyorsanız iletişimin müşteri izniyle kurulmasını isteyin. Gizli bir uygulamanın kamuya açık bağlantısının olmaması otomatik olarak olumsuz işaret değildir. Bunun yerine adayın kendi katkısını açık anlatıp anlatamadığını değerlendirin. Gösterilen ekranların başka ürünlerden alınmış olabileceği ihtimalini de yalnızca görsele bakarak kesin hükme çevirmeyin.

3. Projeyi kimin yöneteceğini netleştirin

Teklif görüşmesini yapan kişiyle günlük çalışmayı yürüten kişi farklı olabilir. Bunun baştan açıklanması normaldir. Proje sorumlusunun kim olacağını, taleplerin nerede toplanacağını ve kararların nasıl onaylanacağını sorun. Her çalışanınızın doğrudan farklı geliştiricilere mesaj göndermesi, çelişen isteklerin ortaya çıkmasına neden olabilir. İşletme tarafında da karar verebilen bir sorumlu belirleyin. İletişim düzeni yalnızca firmanın değil, sizin ekibinizin de yerine getireceği sorumlulukları içermelidir.

Yazılım firması seçimi için toplantı sıklığı kadar toplantının çıktısı da önemlidir. Görüşmede alınan kararların kısa notlarla paylaşılması, açık soruların sorumlularının belli olması ve yeni taleplerin mevcut kapsamla ilişkisinin gösterilmesi beklenebilir. Bunun için pahalı bir proje yönetim aracı şart değildir. Düzenli kullanılan ortak bir kayıt sistemi daha değerlidir. “İstediğiniz zaman yazabilirsiniz” cümlesinin yanında mesajın hangi süreçle değerlendirileceğini de öğrenin; erişilebilir olmak ile işlerin izlenebilir olması farklı konulardır.

4. Çalışan ürünü hangi aralıklarla göreceğinizi sorun

Aylar boyunca yalnızca durum raporu almak yerine temel işlevlerin çalışır örneklerini hangi aşamalarda görebileceğinizi konuşun. Teslim yöntemi projenin yapısına göre değişebilir; her proje aynı yöntemle yürütülmek zorunda değildir. Bununla birlikte değerlendirebileceğiniz somut çıktılar bulunmalıdır. Örneğin müşteri kaydı ve teklif akışı, daha geniş modüller tamamlanmadan denenebilir. Gösterilecek parçanın yalnızca görsel tasarım mı yoksa kayıt tutan bir işlev mi olduğunu açıklığa kavuşturun.

Yazılım firması seçimi esnasında kullanılan yöntem isimlerini tek başına kalite kanıtı saymayın. Bir firmanın “çevik çalışıyoruz” demesi, sizin hangi tarihte neyi değerlendireceğinizi açıklamaz. Scrum Guide, düzenli inceleme ve ortaya çıkan ürüne göre uyarlama yaklaşımını tanımlar; ancak her proje için aynı takvim veya sonuç garantisi vermez. Bu kaynaktaki kavramları adayın gerçek çalışma biçimini anlamak için kullanın. Sizin projede geri bildirimin nasıl alınacağını ayrıca sorun.

5. Test ve kabul sürecini somutlaştırın

Testin yalnızca “kontrol edilecek” diye yazılması yeterli açıklama sağlamaz. Örnek bir işlemin hangi adımlarla deneneceğini, beklenen sonucun nasıl belirtileceğini ve hataların nerede kaydedileceğini konuşun. Kullanıcı yetkisi, yanlış veri girişi ve iptal işlemleri de normal işlem kadar önemlidir. Satış kullanıcısının görmemesi gereken veriye erişebilmesi, ekran güzel görünse bile bir problemdir. Test planında hangi kontrollerin firma, hangilerinin işletmedeki kullanıcılar tarafından yapılacağı belirtilmelidir.

Yazılım firması seçimi sırasında kabul kararının kim tarafından verileceğini de belirleyin. Bütün çalışanların her ayrıntıda anlaşmasını beklemek projeyi belirsiz bırakabilir; tek kişinin günlük kullanıcıları dinlemeden karar vermesi de eksikleri saklayabilir. Sorumlu kişi ve geri bildirim yöntemi baştan konuşulmalıdır. Yeni özellik talebiyle hata düzeltmesinin nasıl ayrılacağını sorun. Kabul ölçütleri yeterince açık olduğunda bu ayrım daha kolay yapılır; her anlaşmazlık kişisel yorumlara dayanmak zorunda kalmaz.

6. Güvenlik sorularına verilen cevapları inceleyin

“Sistem güvenli olacak” ifadesinin hangi kontrollerle desteklendiğini sorun. Kullanıcı yetkileri, parola sıfırlama, oturum yönetimi, yedekleme ve işlem kayıtları üzerinde konuşulabilecek başlıklardır. Gereken kontroller uygulamanın tuttuğu verilere ve işlevlere göre değişir. İlk görüşmede ayrıntılı güvenlik denetimi yapmanız beklenmez; ancak adayın bu soruları doğal bir proje konusu olarak ele alması gerekir. Güvenliği yalnızca barındırma şirketinin sorumluluğu gibi anlatan cevapların kapsamını açmasını isteyin.

Yazılım firması seçimi için OWASP ASVS gibi açık bir doğrulama çerçevesi referans olarak konuşulabilir. ASVS, web uygulamalarının güvenlik gereksinimlerinin belirlenmesi ve test edilmesi için kullanılabilen bir kaynaktır. Bu kaynağın adının teklif metninde bulunması tek başına uygulamanın denetlendiğini göstermez. Hangi gereksinimlerin uygulanacağı, hangilerinin test edileceği ve sonucun nasıl belgeleneceği açıklanmalıdır. Adaydan projenizin risklerine uygun, anlaşılır bir yaklaşım bekleyin.

7. Veri ve erişim sorumluluklarını konuşun

Uygulamanın çalışacağı hesapların kimin adına açılacağını, alan adı ve barındırma erişimlerinin nasıl yönetileceğini öğrenin. İşletmenin kendi uygulamasına erişiminin tek bir kişinin hesabına bağlı kalması iş sürekliliği açısından değerlendirilmelidir. Bunun çözümü bütün parolaları ortak bir dosyada tutmak değildir. Yetkilerin hangi rollerle dağıtılacağı ve gerektiğinde nasıl devredileceği planlanmalıdır. Geliştirme, test ve canlı ortam erişimleri de birbirinden farklı ihtiyaçlar taşıyabilir; bunların aynı kabul edilmemesi gerekir.

Yazılım firması seçimi sırasında verinin dışarı aktarılma biçimini sorun. Programı yıllarca kullanmayı planlasanız bile kayıtların okunabilir biçimde alınabilmesi önemlidir. Ancak “Excel’e aktarırız” cevabının bütün ilişkileri koruyup korumadığını kontrol edin. Müşteri, sipariş ve sipariş satırları ayrı veri kümeleri olabilir. Dışa aktarımın hangi kayıtları kapsadığı ve işlemi kimin yapabileceği belirlenmelidir. Kaynak kodun teslimi, kullanım hakkı ve üçüncü taraf lisansları farklı başlıklardır; her biri teklif ve anlaşma kapsamında ayrıca açıklanmalıdır.

8. Destek ve değişiklik yöntemini öğrenin

Teslim sonrasında bir kullanıcı sorusu, uygulama hatası ve yeni özellik talebi aynı şey değildir. Bunların hangi kanaldan iletileceğini ve neye göre değerlendirileceğini sorun. Her talebin aynı hızla çözüleceğini varsaymayın. İşlemi tamamen durduran bir hata ile ek rapor isteğinin önceliği farklı olabilir. Destek kapsamının, geçerli saatlerin ve varsa yanıt koşullarının açık yazılması gerekir. Belirli bir süre veya kesintisiz destek, ancak gerçekten kararlaştırılmışsa beklenti haline getirilmelidir.

Yazılım firması seçimi görüşmesinde kapsam değişikliğinin nasıl ele alındığını örnek üzerinden sorun. Yeni bir depo eklendiğinde yalnızca bir kayıt mı açılacak, yoksa yetki ve rapor mantığı da değişecek mi? Bu fark yeni geliştirme gerektirebilir. Değişikliklerin yazılı değerlendirilmesi, maliyet ve takvim etkisinin açıklanması beklenebilir. Her yeni talebi tartışma konusu yapmayan fakat bütün ek işleri de sınırsız kabul etmeyen, açık bir yöntem aranmalıdır. İşletmeniz için öngörülebilirlik, sınırsız vaatlerden daha kullanışlıdır.

9. Devamlılık ve devir ihtimalini değerlendirin

Projede çalışan kişinin izinli olması, görev değiştirmesi veya ekibin büyümesi durumunda işlerin nasıl sürdürüleceğini sorun. Bir firmanın çok sayıda çalışanı olması tek başına devamlılık kanıtı değildir. Projeye ait kararların, kurulum adımlarının ve teknik yapı bilgisinin nerede tutulduğu daha açıklayıcı olabilir. Küçük bir ekibin de düzenli dokümantasyonla çalışması mümkündür. Değerlendirmeyi çalışan sayısından önce bilgi paylaşımı ve sorumluluk düzeni üzerinden yapın.

Yazılım firması seçimi sürecinde başka bir ekibe geçişin gerektireceği teslimleri konuşmak, mevcut adayla çalışmak istemediğiniz anlamına gelmez. Kurulum belgeleri, gerekli erişimler ve üzerinde anlaşılmış teslim dosyaları işin sürdürülebilirliğiyle ilgilidir. Her projenin aynı devir modelini sunduğunu varsaymayın. Kaynak kodun veya belirli araçların kapsamda olup olmadığını ayrıca sorun. Belirsiz bir başlığı son güne bırakmak yerine karar öncesinde netleştirmek, iki tarafın da sorumluluklarını daha iyi anlamasını sağlar.

Referans görüşmesinde hangi sorular sorulabilir?

Yazılım firması seçimi için izinli bir referans görüşmesi yapabiliyorsanız “memnun musunuz?” sorusuyla sınırlı kalmayın. İletişimin nasıl yürüdüğünü, kapsam değişikliklerinin nasıl ele alındığını ve teslimde hangi belgelerin sağlandığını sorun. Cevapları kendi projenize doğrudan genellemeyin; farklı bir kapsamda yaşanan deneyim aynı sonucun sizde de oluşacağını kanıtlamaz. Bununla birlikte sürecin anlatılış biçimi adayın çalışma düzeni hakkında yararlı sorular üretir. Referans kişiden gizli fiyat veya müşteri verisi istemeyin.

Referansın olumlu olması yazılım firması seçimi kararını tek başına tamamlamaz. Gösterilen projenin ne zaman geliştirildiğini ve bugün aynı ekibin görev yapıp yapmadığını da sorun. Eski bir başarı hâlâ değerli olabilir, ancak mevcut kapasiteyi ayrıca değerlendirmek gerekir. Yeni kurulan bir ekibin kamuya açık çok sayıda referansı olmayabilir; bu durumda kapsamı sınırlı bir başlangıç, açık teslimler ve ölçülebilir değerlendirme daha fazla önem kazanır. Kanıtın türünü proje ihtiyacına göre tartın.

Karşılaştırma belgesini nasıl hazırlarsınız?

Yazılım firması seçimi için kısa bir karşılaştırma tablosu kullanabilirsiniz. Satırlarda iş anlayışı, benzer süreç deneyimi, teslim yöntemi, test, veri erişimi ve destek bulunsun. Her satıra yalnızca puan vermek yerine puanın gerekçesini de yazın. “Destek iyi” yerine “destek kanalı ve kapsamı teklifin ilgili bölümünde açıklanmış” gibi gözlenebilir ifadeler kullanın. Eksik bilgiye düşük puan vermeden önce adaydan açıklama isteyin. Böylece sessizlikle olumsuz kanıt birbirine karışmaz.

Başlıkların ağırlığını kendi işletmenize göre belirleyin. Gün boyunca kullanılan bir sipariş sisteminde devamlılık ve veri bütünlüğü önemli olabilir. Sınırlı süreli bir kampanya aracında ise teslim takvimi ve içerik yönetimi öne çıkabilir. Yazılım firması seçimi sonunda en yüksek toplamı alan adayı otomatik seçmek zorunda değilsiniz. Kararın gerekçesini tartışmak için bu belgeyi kullanın. Büyük bir belirsizlik varsa tek toplam puanın onu gizlemesine izin vermeyin; önce ilgili soruyu çözün.

Yazılım firması seçimi için kısa kontrol listesi

• Bütün adaylara aynı ihtiyaç özetini ilettiniz mi?
• İlk sürümde tamamlanacak iş akışı açık mı?
• Referanslarda firmanın gerçek katkısı anlaşılabiliyor mu?
• Proje sorumlusu ve karar yöntemi belli mi?
• Test ve kabul ölçütleri yazılı mı?
• Veri aktarımı, erişim ve yedekleme sorumlulukları konuşuldu mu?
• Destek ile yeni geliştirme arasındaki ayrım açık mı?
• Kapsam dışı işler ve teklif varsayımları listelendi mi?
• Son kararın gerekçesi bir belgeye işlendi mi?

Bu kontrol listesi, yazılım firması seçimi görüşmelerinden sonra açık kalan başlıkları görmek için kullanılabilir. Her maddeye aynı anda kesin cevap bulamayabilirsiniz. Önemli olan araştırılacak konunun sorumlusu ve bir sonraki adımının belli olmasıdır. Kritik bir entegrasyonun teknik incelemesi tamamlanmadıysa, değerlendirmeyi bu belirsizlikle birlikte yapın. İmza veya ödeme kararını yalnızca listede bütün kutular dolu görünsün diye hızlandırmayın. Belirsizliği görünür tutmak, sahte kesinlik üretmekten daha yararlıdır.

Örnek senaryo: Üç farklı teklifi değerlendirmek

Bir dağıtım işletmesinin müşteri ve sipariş takibi için üç adayla görüştüğünü düşünelim. İlk aday görsel olarak etkileyici bir panel sunuyor ancak veri aktarımını teklif dışında tutuyor. İkinci aday aynı tutara daha az ekran öneriyor fakat mevcut dosyalardaki kayıtların düzenlenmesini ve aktarım denemesini kapsama alıyor. Üçüncü aday ise muhasebe bağlantısının önce araştırılması gerektiğini belirtiyor. Bu örnek açıklama amaçlıdır; gerçek bir HD Bilgisayar müşterisi veya tamamlanmış proje sonucu değildir.

İşletme, yazılım firması seçimi belgesinde üç teklifi aynı başlıklarla karşılaştırır. Önceliğin mevcut sipariş bilgisinin kaybolmadan taşınması olduğu görülür. Paneldeki bazı ek raporların ilk aşamada zorunlu olmadığı anlaşılır. Muhasebe bağlantısındaki belirsizliğin ise bütün adaylar tarafından değerlendirilmesi gerektiği fark edilir. Böylece karar, “en güzel ekranı kim gösterdi?” sorusundan uzaklaşır. İşletmenin gerçekten kullanacağı ilk iş akışı ve geçiş planı üzerinden yeni sorular hazırlanır.

Sonraki görüşmede adaylardan aynı örnek siparişin nasıl aktarılacağını ve nasıl test edileceğini açıklamaları istenir. Karar için gereken bilgiler tamamlandığında teklif kapsamları yeniden değerlendirilir. Yazılım firması seçimi sonunda hangi adayın seçileceği bu örnekten çıkarılamaz; veriler eksiktir. Ama yöntem, fiyat farkının nedenini ve değerlendirmede hangi kanıtların eksik olduğunu göstermiştir. Belirli bir maliyet tasarrufu veya başarı yüzdesi uydurmadan da sürecin nasıl iyileştirilebileceği açıklanabilir.

Sık yapılan değerlendirme hataları

Yazılım firması seçimi sırasında yalnızca kullanılan teknoloji adına bakmak yaygın bir hatadır. Bir teknoloji sizin ihtiyacınıza uygun olabilir ancak kalite, tek başına dil veya çerçeve seçimiyle açıklanamaz. Gereksinimlerin anlaşılması, test, bakım ve veri modeli de önemlidir. Adaydan neden o çözümü önerdiğini ve alternatifleri hangi nedenle elediğini anlatmasını isteyin. Teknik terimleri anlamadığınızda günlük işinizdeki karşılığını sorun; kararın anlaşılır bir gerekçesi olmalıdır.

Bir başka hata, bütün taleplere hızlıca “yaparız” denmesini olumlu kanıt saymaktır. İyi bir değerlendirmede sorular, sınırlar ve araştırılması gereken konular bulunabilir. Yazılım firması seçimi için bunları isteksizlik olarak yorumlamak yerine nasıl yönetileceklerini inceleyin. Aynı şekilde küçük bir eleştiriyi bütün projeyi reddetmek gibi algılamayın. Adayın daha basit bir çözüm önermesi, gereksiz geliştirmeyi azaltmayı amaçlıyor olabilir. Gerekçesini dinleyin ve ilk iş probleminizle karşılaştırın.

İletişimin yalnızca satış aşamasındaki hızına göre karar vermek de eksik kalır. İlk mesajlara hızlı yanıt verilmesi yararlıdır, fakat geliştirme ve destek aşamalarındaki düzeni kanıtlamaz. Yazılım firması seçimi görüşmesinde işin ilerleyişinin hangi kayıtlarla izleneceğini öğrenin. Sunumdaki kişiyle günlük proje sorumlusunun farklı olması normal olabilir; roller açıkça belirtilmelidir. Devam eden işlerin kapasiteye etkisini ve projenizin ne zaman başlayabileceğini de gerçekçi biçimde konuşun.

Maltepe, İdealtepe ve Anadolu Yakası’nda firma aramak

Yazılım firması seçimi yaparken Maltepe veya İdealtepe’ye yakın bir ekiple görüşmek iletişim tercihiniz olabilir. Bunun yanında iş kapsamı, teslim ve destek yöntemlerini değerlendirmeyi sürdürün. Anadolu Yakası içinde aynı ilçede olmak bütün toplantıların yüz yüze yapılacağı anlamına gelmez. Türkiye genelindeki uzaktan projelerde de çalışma yöntemi ayrıca belirlenir. Yerinde görüşme veya belirli bir hizmet koşulu ancak taraflarca kararlaştırılmışsa beklentiye dönüştürülmelidir; adres üzerinden otomatik bir vaat çıkarılmamalıdır.

HD Bilgisayar Yazılım Sistemleri’nin merkezi Altayçeşme, Oba Çıkmazı No:3, Maltepe / İstanbul adresindedir. Özel yazılım geliştirme hizmeti ve aynı sayfadaki proje vitrini üzerinden çalışma alanlarını inceleyebilirsiniz. Yazılım firması seçimi için hazırladığınız kısa ihtiyaç belgesini görüşmede kullanabilir, 0532 396 34 71 numarasından iletişim kurabilirsiniz. Güncel iletişim bilgileri için HD Bilgisayar web sitesini kontrol edin. Projenin uygulanabilirliği ve teklif kapsamı gereksinimlere göre değerlendirilir.

Sık sorulan sorular

Yazılım firması seçimi için kaç adayla görüşmeliyim?

Herkes için geçerli bir sayı yoktur. Aynı ihtiyacı farklı yaklaşımlarla değerlendiren birkaç aday, kapsam farklarını görmenize yardımcı olabilir. Çok sayıda görüşme yapıp karşılaştırılabilir kayıt tutmamak ise karar vermeyi zorlaştırabilir. Önce hangi sorulara cevap aradığınızı belirleyin. Yeni bir adayın mevcut belirsizlikleri çözmeye katkısı olmayacaksa yalnızca sayıyı artırmak için görüşme planlamanız gerekmez.

En düşük fiyatlı teklif mutlaka riskli midir?

Hayır. Fiyat, kapsam ve çalışma modeline göre değişir. Küçük kapsamlı bir iş için düşük tutar makul olabilir. Bununla birlikte eksik işlevlerin, dış hizmet giderlerinin veya veri aktarımının sonradan eklenip eklenmeyeceğini öğrenin. Yazılım firması seçimi sırasında ucuz ya da pahalı etiketi vermeden önce teklifin neyi kapsadığını netleştirin. Açıklanamayan farklar, soru sormak için bir nedendir; tek başına son karar değildir.

Teknik bilgim yoksa yazılım firması seçimi yapabilir miyim?

Evet. İş akışınızı, kullanıcılarınızı ve beklediğiniz sonucu anlatabilirsiniz. Adaylardan teknik önerilerinin işletmenize etkisini sade biçimde açıklamalarını isteyin. Kritik veya karmaşık bir projede bağımsız teknik değerlendirme seçeneği de düşünülebilir. Bu değerlendirme, firmanın kendi sorumluluğunu ortadan kaldırmaz. Teknik dilin yoğunluğu yerine açıklamaların anlaşılır, sınanabilir ve teklif kapsamıyla tutarlı olmasına bakın.

Projeyi küçük bir aşamayla başlatmak uygun olur mu?

İhtiyaç izin veriyorsa sınırlı ve kullanılabilir bir ilk aşama değerlendirilebilir. Bu aşamanın hangi işi tamamlayacağı açık olmalıdır. Yalnızca tasarım örneğini gerçek uygulama teslimi gibi değerlendirmeyin. İlk aşamanın sonrasında devam etme, kapsamı değiştirme veya durma koşullarını konuşun. Aşamalı başlangıç bütün riskleri ortadan kaldırmaz ancak iş birliği biçimini somut çıktılar üzerinden değerlendirmek için kullanılabilir.

Kaynak kod teslimi firma seçimini tek başına belirler mi?

Hayır. Kaynak kodun kapsamı ve teslim şartları önemlidir; fakat kodun varlığı tek başına başka bir ekibin uygulamayı hemen sürdürebileceğini göstermez. Kurulum bilgileri, bağımlılıklar ve gerekli erişimler de değerlendirilmelidir. Yazılım firması seçimi içinde bu başlığı kullanım ihtiyacınızla birlikte konuşun. Üçüncü taraf lisansları veya hizmetlerin koşulları varsa bunların da açıklanmasını isteyin.

Sözlü vaatleri nasıl değerlendirmeliyim?

Kararınız için önemli bir açıklamanın teklif veya anlaşma kapsamında yazılı hale gelmesini isteyin. Örneğin veri aktarımı, eğitim veya destek konuşulduysa hangi sınırlarla sunulduğu açık olsun. Yazılım firması seçimi sürecinde tutulan toplantı notları yararlıdır ancak nihai kapsamla çelişmemelidir. Metinleri anlamadığınızda açıklama isteyin; farklı yorumlanabilecek bir ifadeyi imza sonrasına bırakmayın.

Karar vermeden önce son adım

Karara katılan kişiler aynı şeyi ölçmüyor olabilir. Yönetici raporlamaya, satış ekibi hızlı kayda, bilgi işlem sorumlusu ise erişim ve işletim konularına öncelik verebilir. Bu farklılıkları toplantının sonuna bırakmayın. Değerlendirme başlıklarını başlangıçta birlikte belirleyin ve neden önemli olduklarını yazın. Bir kullanıcı grubunun bütün taleplerinin diğerlerini bastırması, teslim sonrasında kullanım sorunlarına neden olabilir. Ortak hedef, tek bir kişinin en çok beğendiği ekranı seçmek yerine işletmenin temel işlemini tamamlayabilmektir.

Bir adayın cevabını anlamadığınızda aynı soruyu başka biçimde sormaktan çekinmeyin. “Bu rapor için ayrı geliştirme gerekir” deniyorsa bunun mevcut veriden mi, ek hesaplamadan mı yoksa yeni bir iş akışından mı kaynaklandığını öğrenin. Anlaşılır açıklama almak karşı tarafı sorgulamak için değil, kararınızın neye dayandığını bilmek içindir. Açıklamalar görüşmeden görüşmeye değişiyorsa son kapsamı tek bir belgede toparlayın. Hangi notun güncel olduğu belli olsun; eski teklif satırlarıyla yeni toplantı kararlarının karışmasına izin vermeyin.

Seçim tamamlandığında değerlendirme belgesini çöpe atmayın. Proje başlangıcında ilk varsayımları ve açık soruları yeniden gözden geçirmek için kullanabilirsiniz. Örneğin henüz araştırılmamış bir entegrasyon veya geçerli olmayan bir kullanıcı sayısı tahmini değişmiş olabilir. Bunların ortaya çıkması sürecin mutlaka kötü yürüdüğünü göstermez; değişimin nasıl kaydedildiği ve plana nasıl yansıtıldığı önemlidir. Başlangıç kararlarının izlenebilir olması, teslim sırasında neden bazı işlevlerin önce yapıldığını ve bazı taleplerin sonraya bırakıldığını açıklamayı kolaylaştırır.

Yazılım firması seçimi için bütün belgeleri topladıktan sonra en önemli üç ihtiyacınızı yeniden okuyun. Önerilen kapsam bu ihtiyaçları karşılıyor mu, kritik belirsizlikleri kimin çözeceği belli mi ve ilk teslimi nasıl değerlendireceğiniz açık mı? Bu sorulara verdiğiniz cevaplar fiyat ve sunumun yanında somut bir karar zemini oluşturur. Görüşme için hazırladığınız belgeyi güncel tutun; kararın gerekçesini kaydedin ve proje başlarken aynı beklentilerin paylaşıldığını tekrar kontrol edin.