Freelancer İçin En Tehlikeli Cümle: “Bu Küçük Bir İş”

Freelancer olarak çalışırken bazı cümleleri o kadar sık duyarsınız ki daha talebin ayrıntıları gelmeden işin nasıl ilerleyebileceğini tahmin etmeye başlarsınız.

“Zaten hazır bir sistem var.”

“Sadece küçük bir düzenleme yapılacak.”

“Senin için birkaç dakikalık iş.”

“Bir buton eklenecek, o kadar.”

Bunların arasında en tehlikeli olanı ise genellikle şudur:

“Bu küçük bir iş.”

Talep gerçekten küçük olabilir. Bir yazının değiştirilmesi, yanlış yönlendiren bir bağlantının düzeltilmesi veya mevcut alandaki rengin güncellenmesi birkaç dakikada tamamlanabilir. Her işi olduğundan büyük göstermek veya en basit düzenlemeyi bile kapsamlı bir projeye dönüştürmek doğru değildir.

Ancak bir işin küçük olup olmadığı, anlatılırken kullanılan kelime sayısına ya da ekranda kapladığı alana göre belirlenemez.

Bir buton küçük olabilir. O butona basıldığında gerçekleşmesi beklenen işlemler küçük olmayabilir.

Küçük Görünen Talebin Arkasında Ne Var?

Bir müşteri “İletişim formuna bir alan daha ekleyelim” dediğinde talep oldukça açık ve basit görünür. Formda yeni bir kutu açılacak, kullanıcı bilgisini yazacak ve form gönderilecek.

Fakat o alanla ilgili birkaç soru sorulduğunda işin gerçek kapsamı ortaya çıkmaya başlayabilir.

Girilen bilgi yalnızca e-postayla mı gönderilecek, yoksa veritabanında da saklanacak mı? Yönetim panelinde görüntülenecek mi? Zorunlu olacak mı? Belirli bir formata göre doğrulanacak mı? Daha önce gönderilen kayıtlar bu alan olmadan nasıl gösterilecek? Bilgi dışa aktarılan Excel dosyasında yer alacak mı? Başka bir sisteme gönderiliyor mu? Birden fazla dilde alan adı ve hata mesajları hazırlanacak mı?

Ekranda görünen değişiklik hâlâ tek bir form alanıdır. Teknik tarafta ise formun görünümü, doğrulama kuralları, veri tabanı, yönetim paneli, bildirimler, dışa aktarma işlemleri ve entegrasyonlar etkilenebilir.

Müşterinin bunları en başından bilmesini beklemek gerçekçi değildir. Talebi teknik etkilerine ayırmak geliştiricinin sorumluluğudur. Sorun, gerekli sorular sorulmadan “evet, küçük iş” denilerek çalışmaya başlandığında ortaya çıkar.

Ekrandaki Boyut ile İşin Boyutu Aynı Değildir

Web projelerinde yapılan değişikliğin kullanıcıya görünen bölümü, çoğu zaman çalışmanın yalnızca son katmanıdır.

Örneğin bir e-ticaret sitesine “Tükendiğinde haber ver” butonu eklenmesi istenebilir. Kullanıcı açısından bu, ürün sayfasına eklenecek küçük bir butondur. Ancak özelliğin çalışabilmesi için e-posta adresinin alınması, iznin kaydedilmesi, ürünün stok durumunun takip edilmesi ve stok yenilendiğinde bildirim gönderilmesi gerekir.

Aynı kullanıcının aynı ürün için tekrar kayıt olmasının engellenmesi gerekebilir. Gönderilemeyen e-postalar takip edilebilir. Kullanıcının bildirim talebinden vazgeçebilmesi istenebilir. Yönetici bekleyen bildirimleri görmek isteyebilir. Kişisel verilerin saklanmasıyla ilgili bilgilendirme ve açık rıza metinlerinin güncellenmesi gerekebilir.

Talep tek bir butondur. Özellik ise başlı başına bir kullanıcı akışıdır.

Benzer durum “Siteye favoriler özelliği ekleyelim” talebinde de görülür. Yalnızca kalp ikonu eklemek yeterli değildir. Favorilerin giriş yapan kullanıcılara mı ait olacağı, ziyaretçiler için tarayıcıda mı saklanacağı, farklı cihazlarda senkronize edilip edilmeyeceği ve artık yayında olmayan kayıtların nasıl ele alınacağı belirlenmelidir.

Bu ayrıntılar işi gereksiz yere büyütmek için sorulmaz. Özelliğin ne zaman tamamlanmış sayılacağını anlayabilmek için sorulur.

Bir İşin Süresi Yalnızca Kod Yazılan Zamandan Oluşmaz

Freelancerların fiyatlandırma yaparken düştüğü en yaygın hatalardan biri, yalnızca değişikliği uygulamak için gereken süreyi hesaba katmaktır.

Bir düzenlemenin kod tarafı gerçekten on dakika sürebilir. Ancak çalışmaya başlayabilmek için önce müşteriyle yazışmak, talebi anlamak ve projeye erişmek gerekir. Ardından mevcut yapı incelenir, ilgili dosya bulunur, değişiklik uygulanır ve farklı ekranlarda test edilir.

Canlı projede doğrudan değişiklik yapılmıyorsa geliştirme ortamının hazırlanması, güncel kodların alınması ve yayınlama sürecinin tamamlanması gerekir. Değişiklikten sonra önbellek temizlenebilir, derleme yapılabilir veya kuyruk işlemleri yeniden başlatılabilir. Sonuç kontrol edilir ve müşteriye bilgi verilir.

Küçük bir işin gerçek süresinde şu aşamalar bulunabilir:

• Talebi anlama: Müşterinin istediği sonuç ile teknik olarak yapılması gereken işlem aynı olmayabilir. Doğru çözüm için önce ihtiyacın netleşmesi gerekir.

• Projeye yeniden hâkim olma: Aylar önce tamamlanmış bir projede ilgili yapının nerede ve nasıl kurulduğunu hatırlamak zaman alabilir.

• Erişim ve ortam hazırlığı: Sunucuya, yönetim paneline, kaynak kodlara veya harici servislere erişim sağlanması gerekebilir.

• Mevcut yapıyı inceleme: Küçük değişikliğin başka alanları etkileyip etkilemediği kontrol edilmeden yapılan müdahale yeni sorunlara yol açabilir.

• Uygulama: Kullanıcının doğrudan iş olarak gördüğü bölüm çoğunlukla burasıdır.

• Test: Değişikliğin yalnızca ilgili ekranda görünmesi değil, farklı cihazlarda ve bağlantılı işlemlerde doğru çalışması gerekir.

• Yayınlama: Dosyanın sunucuya aktarılması, derleme, önbellek temizliği veya servislerin yeniden yüklenmesi gerekebilir.

• Geri bildirim ve takip: İşin tamamlandığının bildirilmesi ve müşteri tarafından yapılan kontrolden sonra ortaya çıkan soruların cevaplanması da sürecin parçasıdır.

Bu aşamaların her biri uzun sürmek zorunda değildir. Fakat toplam süre hesaplanırken yok sayılmaları, birkaç dakikalık değişikliğin gün içinde beklenenden çok daha fazla yer kaplamasına neden olur.

“Hazır Sistemde Küçük Değişiklik” Her Zaman Daha Kolay Değildir

Sıfırdan geliştirilen projede sistemin nasıl kurulduğunu bilirsiniz. Başka biri tarafından hazırlanmış veya uzun süredir güncellenmemiş bir projede ise küçük bir düzenleme bile önce yapıyı anlamayı gerektirir.

Müşteri, hazır bir web sitesindeki butonun yerini değiştirmek istediğinde bunun birkaç satırlık CSS düzenlemesi olduğunu düşünebilir. Bazen gerçekten öyledir. Ancak ilgili görünüm bir sayfa oluşturucudan, tema ayarından, eklentiden veya derlenen bir dosyadan geliyor olabilir.

Dosyada yapılan değişiklik görünmeyebilir çünkü CDN eski içeriği sunuyordur. Tema güncellendiğinde düzenleme silinebilir. Butonun konumu yalnızca masaüstünde düzelirken mobil görünüm bozulabilir. Aynı sınıf başka sayfalarda da kullanıldığı için tek bir değişiklik beklenmeyen alanları etkileyebilir.

Burada zaman alan bölüm birkaç satır kod yazmak değil, o birkaç satırın güvenli biçimde nereye yazılması gerektiğini bulmaktır.

Mevcut projeye müdahale etmek bazen boş bir sayfadan başlamaktan daha fazla sorumluluk taşır. Çünkü çalışmayan bir özelliği düzeltirken çalışan bölümleri de korumanız gerekir.

Küçük İşler Neden Büyür?

Küçük bir talebin büyümesi her zaman müşterinin kötü niyetli olduğu anlamına gelmez. Çoğu zaman başlangıçta ihtiyacın tamamı düşünülmemiştir.

Müşteri bir düzenlemenin ilk sonucunu gördüğünde yeni ihtimalleri daha rahat fark eder.

“Buraya telefon numarası da ekleyelim.”

“Bu bilgi yönetim panelinde de görünsün.”

“Hazır burayı yapmışken filtreye de ekleyelim.”

“Mobilde biraz farklı dursun.”

“Bunun bir de İngilizcesini ekleyebilir miyiz?”

Her talep tek başına küçük görünebilir. Ancak başlangıçta konuşulan işle birlikte değerlendirildiğinde yeni bir kapsam oluşturur.

İlk düzenleme bir saat sürecekken sonradan eklenen beş küçük talep işi bir güne çıkarabilir. Freelancer, başlangıçta “küçük iş” diyerek sabit ve düşük bir fiyat verdiyse ek talepleri ayırmakta zorlanabilir. Müşteri ise bunları aynı düzenlemenin doğal devamı olarak görebilir.

Bu noktada sorun genellikle sonradan gelen talepler değil, başlangıç kapsamının açık biçimde tanımlanmamış olmasıdır.

Freelancer Bu Cümlenin Kurulmasına Nasıl Katkıda Bulunur?

“Bu küçük bir iş” ifadesi her zaman müşteriden gelmez. Freelancer da bazen işi hızlıca almak, karşı tarafı bekletmemek veya yardımcı olabileceğini göstermek için daha ayrıntıları öğrenmeden aynı cümleyi kurar.

“Kolay, hallederiz.”

“En fazla yarım saat sürer.”

“Onu aradan çıkarırız.”

Bu cevaplar o an iletişimi hızlandırır. Fakat henüz incelenmemiş bir iş için verilen süre ve fiyat, kısa süre içinde freelancerın kendi taahhüdüne dönüşür.

Proje açıldığında beklenmeyen bir yapı görülebilir. Erişim bilgileri çalışmayabilir. Kullanılan paket güncel PHP sürümünü desteklemeyebilir. Basit değişiklik için önce başka bir hatanın çözülmesi gerekebilir.

Freelancer bu noktada işin tahmin edilenden büyük olduğunu söylediğinde müşteri doğal olarak ilk verilen cevabı hatırlar. Çünkü müşteri açısından değişen bir şey yoktur. Talep başından beri aynıdır.

Bu nedenle işi incelemeden kesin süre vermemek güvensizlik oluşturmaz. Tam tersine, rastgele tahmin yerine mevcut yapıya bakılarak cevap verileceğini gösterir.

“Talep küçük görünüyor ancak mevcut yapıda hangi bölümleri etkilediğini kontrol ettikten sonra süre ve fiyatı netleştirebilirim” demek, “kolay, yaparız” demekten daha uzun bir cümledir. Fakat iki taraf için de daha güvenli bir başlangıç sağlar.

Her Küçük İş İçin Büyük Bir Teklif Dosyası Gerekmez

Kapsamı belirlemek, birkaç dakikalık düzenleme için sayfalarca sözleşme hazırlamak anlamına gelmez.

Talep gerçekten sınırlıysa kısa bir yazılı teyit yeterli olabilir:

“İletişim sayfasındaki mevcut form alanlarının sıralaması değiştirilecek ve telefon alanı zorunlu hâle getirilecek. Yönetim paneli, bildirim metinleri ve diğer formlar bu çalışmaya dahil değildir.”

Bu açıklama hem yapılacak işi hem de sınırını gösterir. Müşteri daha sonra telefon bilgisinin yönetim panelinde ayrı bir sütunda görünmesini isterse bunun yeni bir talep olduğu kolayca anlaşılır.

Küçük işlerde en büyük sorun çoğunlukla resmi belgenin olmaması değil, iki tarafın yapılacak işi farklı anlamasıdır. Birkaç açık cümle bile bu farkı büyük ölçüde ortadan kaldırabilir.

Minimum İş Bedeli Neden Gereklidir?

Freelancer için küçük taleplerin oluşturduğu başka bir sorun da günün parçalanmasıdır.

Bir müşteriden on beş dakikalık, diğerinden yirmi dakikalık ve bir başkasından yarım saatlik talepler gelebilir. Kâğıt üzerinde toplam süre birkaç saat görünür. Fakat her proje arasında bağlantı kurmak, farklı sunuculara erişmek, yazışmaları takip etmek ve yapılan işi test etmek gerekir.

Gün sonunda saatlerce çalışılmış olmasına rağmen kesintisiz biçimde ilerleyen tek bir iş tamamlanmamış olabilir.

Bu nedenle bazı freelancerlar minimum çalışma bedeli veya minimum süre uygular. Bu bedel, birkaç satır kodun değerini olduğundan yüksek göstermek için değil; işin başlamasıyla oluşan toplam operasyonu karşılamak için kullanılır.

Bir teknik servise gittiğinizde yalnızca vidanın sıkılması için geçen saniyeye ödeme yapmazsınız. Sorunun doğru anlaşılması, gerekli aracın kullanılması ve işlemin sorumluluğunun alınması da hizmetin parçasıdır.

Freelancerın yıllar içinde edindiği ve bir sorunu kısa sürede çözmesini sağlayan deneyim de aynı şekilde değerlendirilmelidir. Bir işi hızlı tamamlayabilmek, o işin değersiz olduğu anlamına gelmez.

Ancak minimum iş bedelinin müşteriye açık biçimde anlatılması gerekir. Beklenmedik biçimde faturaya eklenen bir tutar yerine, çalışmaya başlamadan önce paylaşılan yöntem iki taraf için de daha sağlıklıdır.

Küçük Talep Mevcut Proje Kapsamındaysa Ne Olur?

Devam eden bir projede gelen her küçük talep ayrıca fiyatlandırılmak zorunda değildir.

Başlangıçta konuşulan işin doğru biçimde tamamlanması için gereken düzenlemeler zaten proje kapsamındadır. Hazırlanan sayfa üzerinde başlığın hizasının düzeltilmesi, kararlaştırılan işlevdeki hatanın giderilmesi veya eksik uygulanan bir ayrıntının tamamlanması yeni geliştirme olarak değerlendirilemez.

Burada önemli olan hata düzeltme, revizyon ve yeni geliştirme arasındaki farktır.

Hata, sistemin kararlaştırılan biçimde çalışmamasıdır. Revizyon, mevcut kapsam içindeki sonucun belirli sınırlar içinde düzenlenmesidir. Yeni geliştirme ise daha önce konuşulmayan bir özelliğin veya davranışın sisteme eklenmesidir.

Bu ayrım yapılmadığında freelancer her talebi ek iş olarak değerlendirebilir veya tam tersine sınırsız değişikliği mevcut projeye dahil edebilir. İki yaklaşım da uzun vadede müşteri ilişkisini zedeler.

Kapsamın amacı müşterinin her talebine karşı bir savunma alanı oluşturmak değildir. Hangi işlemin mevcut sorumluluğun parçası olduğunu ve hangi talebin yeni çalışma gerektirdiğini anlaşılır hâle getirmektir.

“Hazır Buradayken” Talepleri

Küçük işlerin büyümesinde en sık karşılaşılan ifadelerden biri de “hazır buradayken” olur.

Bir sayfadaki düzenleme tamamlanırken benzer değişikliğin diğer sayfalara da uygulanması istenebilir. Bu istek mantıksız değildir. Tasarım tutarlılığı açısından gerekli bile olabilir.

Ancak bir sayfada yapılan değişikliğin on farklı sayfaya uygulanması, aynı işin otomatik olarak birkaç saniyede çoğalacağı anlamına gelmez. Sayfalar aynı bileşeni kullanıyorsa işlem kolay olabilir. Her biri ayrı hazırlanmışsa tek tek düzenleme ve kontrol gerekebilir.

Aynı durum veri güncellemelerinde de yaşanır. Bir ürünün kategorisini değiştirmek küçük bir işlemdir. Binlerce ürün için doğru kategoriyi belirlemek, kayıtları güncellemek ve sonuçları kontrol etmek ayrı bir çalışmadır.

“Hazır buradayken” cümlesi işi küçültmez. Yalnızca yeni talebin mevcut çalışmayla ilişkili olduğunu gösterir. İlişkili olması ise otomatik olarak aynı kapsama dahil olduğu anlamına gelmez.

Küçük Bir Talebe Nasıl Cevap Verilebilir?

Her talebe uzun teknik açıklamalarla cevap vermek iletişimi gereksiz yere zorlaştırabilir. Çoğu durumda birkaç doğru soru yeterlidir.

Öncelikle istenen sonucun ne olduğu anlaşılmalıdır. Müşteri teknik çözümü tarif ediyor olabilir, fakat asıl ihtiyacı daha basit bir yöntemle karşılanabilir.

Ardından değişikliğin nerelerde geçerli olacağı sorulmalıdır. Yalnızca tek bir sayfa mı etkilenecek, benzer bütün alanlar mı güncellenecek? Masaüstü ve mobil görünümde aynı davranış mı beklenecek? Birden fazla dil bulunuyorsa bütün diller dahil mi?

Talebin veri ve yönetim tarafına etkisi de kontrol edilmelidir. Görünen alana eklenen bilgi nereden gelecek, kim tarafından değiştirilecek ve nerede saklanacak?

Son olarak kabul ölçütü belirlenmelidir. İşin tamamlandığını iki taraf hangi sonuca bakarak anlayacak?

Bu soruların tamamı her küçük iş için gerekli olmayabilir. Ancak talebin türüne göre doğru soruları seçmek, işe başlamadan önce görünmeyen kapsamı ortaya çıkarır.

Küçük İşleri Reddetmek Zorunda Değilsiniz

Küçük talepler freelancer için değersiz değildir. Mevcut müşterilerle ilişkinin sürmesini sağlar, daha büyük işlerin önünü açabilir ve bazen yoğun bir geliştirme projesinden çok daha rahat tamamlanabilir.

Sorun küçük işi yapmak değil, onun gerçek maliyetini görmeden kabul etmektir.

Talep açık, erişimler hazır ve değişikliğin etkisi sınırlıysa kısa sürede tamamlanabilir. Böyle bir işi sırf küçük olduğu için reddetmek gerekmez. Ancak günün planını bozacak, eski bir projeyi yeniden incelemeyi gerektirecek veya sorumluluğu yüksek bir müdahale olacaksa buna uygun süre ayrılmalıdır.

Bazı işler de teknik olarak küçük olmasına rağmen acildir. Mesai dışı gelen, satışları durduran veya canlı sistemi etkileyen bir talebin fiyatı yalnızca işlem süresine göre değerlendirilemez. Acil müdahale, mevcut planın değiştirilmesini ve başka işlerin ertelenmesini gerektirebilir.

Küçük, kolay ve acil aynı anlama gelmez.

Asıl Tehlike Cümlede Değil, Belirsizliktedir

“Bu küçük bir iş” kendi başına kötü niyetli bir cümle değildir. Müşteri, gördüğü bölüm üzerinden doğal bir tahminde bulunur. Teknik yapıyı bilmediği için işin başka alanlara nasıl yayıldığını göremeyebilir.

Freelancerın görevi müşteriye işin ne kadar karmaşık olduğunu kanıtlamaya çalışmak değildir. Talebin kapsamını anlaşılır hâle getirmek, gerekli çalışmayı belirlemek ve buna göre süre ile fiyat sunmaktır.

Eğer iş gerçekten küçükse bunu açıkça söylemek güven oluşturur. Beklenenden daha genişse nedenini müşterinin anlayabileceği biçimde açıklamak gerekir. Yalnızca “çok uğraştırır” demek yerine hangi alanların değişeceğini göstermek daha ikna edicidir.

Aynı şekilde her ihtimali baştan büyük bir probleme dönüştürmek de doğru değildir. Profesyonel yaklaşım, işi otomatik olarak küçümsemek veya büyütmek değil; inceleyip doğru boyutta değerlendirmektir.

Küçük İş Diye Başlayan Büyük Ders

Freelancer olarak çalışırken zaman içinde yalnızca daha hızlı kod yazmayı öğrenmiyorsunuz. Hangi talebin arkasında başka ihtiyaçların bulunabileceğini, hangi sorunun önce incelenmesi gerektiğini ve nerede kesin cevap vermemek gerektiğini de öğreniyorsunuz.

Başlangıçta birkaç dakikalık görünen ama günün tamamını alan işler, bu deneyimin pahalı bir parçası oluyor.

Bir süre sonra “Bu küçük bir iş” cümlesini duyduğunuzda doğrudan itiraz etmek yerine birkaç soru sormaya başlıyorsunuz.

Tam olarak ne değişecek?

Değişiklik nerelerde uygulanacak?

Mevcut sistem bunu destekliyor mu?

İş ne zaman tamamlanmış sayılacak?

Bu sorular işi büyütmez. Zaten var olan ancak henüz konuşulmamış kapsamı görünür hâle getirir.

Freelancer için en tehlikeli küçük iş, gerçekten küçük olan iş değildir. İncelenmeden küçük kabul edilen, sınırları belirlenmeyen ve her yeni taleple biraz daha genişleyen iştir.

Çünkü bir işin maliyetini artıran her zaman kodun zorluğu olmaz.

Bazen yalnızca iki tarafın “küçük” kelimesinden farklı şeyler anlaması yeterlidir.