Yazılımcı Projeyi Yarım Bıraktı: Teslim Gününü Beklemeden Sözleşmeden Dönme

Yazılımcının özel geliştirme projesini yarım bırakması hâlinde işsahibi her durumda sözleşmedeki son teslim gününe kadar beklemek zorunda değildir. TBK m. 473, işe başlama ve işin yürütülmesindeki belirli aykırılıklarda teslim tarihi beklenmeden sözleşmeden dönme hakkı tanır. Ancak sadece ekip içi iletişimin yavaşlaması veya takvimden duyulan kaygı, bu hakkın bütün koşullarını kanıtlamaz.

Yarım yazılım dosyasında karar verilmeden önce mevcut ürünün seviyesi, kalan iş, yüklenicinin tutumu ve gecikmenin kaynağı belirlenmelidir. Ardından dönme bildirimi, avans hesabı ve başka geliştiriciye geçiş birbirine uyumlu kurulmalıdır. Yeni ekip işe başladıktan sonra eski kod ve proje kayıtlarının değişmesi, ilk yüklenicinin hangi durumda bıraktığının ispatını güçleştirir.

Önce sözleşmenin gerçekten bir yazılım sonucu içerdiği belirlenir

TBK m. 470, yüklenicinin bir eser meydana getirmeyi ve işsahibinin karşılığında bedel ödemeyi üstlendiği sözleşmeyi düzenler. Şirkete özgü uygulama, entegrasyon veya otomasyon sonucunun teslimi taahhüt edilmişse bu yapı incelenir. Sadece belirli saat geliştirici personel temini, sürekli danışmanlık veya hazır yazılım aboneliği aynı sonuca otomatik bağlanmaz. Sözleşmenin adı yerine asli edimlerin niteliği esas alınır.

Tek projede analiz, geliştirme, lisans ve devamlı bakım birlikte bulunabilir. TBK m. 473’e dayanan kararın hangi eser bölümüne ilişkin olduğu açık olmalıdır. Bakım hizmetinin durması, geliştirme aşamasındaki borcun kapsamını kendiliğinden değiştirmez. Müşteri hangi sonucu satın aldığını, hangi teslimlerin tamamlandığını ve hangi aşamanın terk edildiğini sözleşme ekleri üzerinden göstermelidir. Bu ayrım iade hesabının hangi ödemeleri kapsadığını da belirler.

TBK m. 473 hangi hâllerde teslim gününü bekletmez?

TBK m. 473/1; yüklenicinin işe zamanında başlamaması, sözleşmeye aykırı biçimde işi geciktirmesi veya işsahibine yüklenemeyen sebeple oluşan gecikme yüzünden bütün tahminlere göre işi kararlaştırılan zamanda bitiremeyeceğinin açıkça anlaşılması durumlarını düzenler. Kanuni koşullar gerçekleştiğinde işsahibi teslim gününü beklemeksizin sözleşmeden dönebilir. Sözleşmede son tarih bulunması, o tarihe kadar bütün ihlallere katlanma zorunluluğu yaratmaz.

Bu hakkın kullanımı, gecikmenin somut olgularla ortaya konulmasını gerektirir. Başlangıç iş programı, bağlayıcı ara teslimler, tamamlanmış modüller ve kalan iş birlikte incelenir. Sadece toplantı takviminin değişmesi ile taahhüt edilmiş geliştirme faaliyetinin fiilen bırakılması aynı değildir. TBK m. 473 kapsamında erken dönme kuralı, yazılımda teknik ilerlemenin kanıtlanmasıyla somutlaştırılır.

Yazılım projesinin terk edildiği nasıl gösterilir?

Kod deposundaki son değişiklik tarihi tek başına bütün işin durduğunu kanıtlamaz. Ekip çevrimdışı çalışmış, başka depoda geliştirme yapmış veya kod gerektirmeyen analiz yürütmüş olabilir. Bunun için yükleniciden son sürüm, yapılan iş listesi, çalıştırma yöntemi ve kalan iş planı istenir. Açıklama ile fiili çıktı birbirini doğrulamıyorsa bu tutarsızlık kaydedilir. Yalnız taahhüt içeren e-posta, teslim edilebilir ürün yerine geçmez.

İletişim kanallarının kapanması, görevlendirilen ekibin çekilmesi, üzerinde anlaşılmış testlerin sürekli yapılamaması, çalışan sürümün sunulmaması ve somut iş planının verilmemesi birlikte değerlendirilir. Personelin değişmesi tek başına sözleşme ihlali değildir; kişisel edim taahhüdü ve sonuç üzerindeki etkisi ayrıca incelenir. Yüklenici şirketin faaliyetine devam etmesi de belirli projeyi yerine getirdiğini tek başına göstermez. İspat, genel şirket durumundan önce bu projedeki borca yönelmelidir.

“Proje yüzde doksan bitti” açıklaması nasıl denetlenir?

Yazılımın tamamlanma seviyesi yalnız yazılan satır veya kapatılan görev sayısıyla ölçülemez. Sözleşmede büyük ekonomik değer taşıyan temel işlevin çalışmaması, çok sayıda küçük görevin tamamlanmış olmasından daha belirleyici olabilir. Kullanıcı arayüzü hazırlanmışken veri işleme, yetkilendirme veya entegrasyon tamamlanmamışsa bunlar ayrı gösterilmelidir. Yüklenicinin yüzdesi hangi teslim listesine dayandığını açıklamalıdır.

İnceleme çizelgesi her modül için taahhüt edilen işlevi, mevcut çıktıyı, çalıştırılabilirliği, test sonucunu ve tamamlamak için gereken işi içerir. Teknik uzman kalan işin gerçek kapsamını değerlendirir; hukuki dönme hakkı hakkında karar vermez. Geliştiricinin harcadığı süre ile müşterinin elde ettiği kullanılabilir sonuç da ayrı hesaplanır. Aynı nedenle yeni ekibin ilk izlenim üzerinden verdiği genel yüzde, ayrıntılı teknik incelemenin yerine geçirilmemelidir.

Çalışan demo, tamamlanabilir ürünün kanıtı mıdır?

Sunumda belirli ekranların çalışması, sözleşmedeki bütün sonucun tamamlandığını göstermez. Demosu sunulan sürümün hangi kaynaktan üretildiği, gerçek veriyle mi yoksa sabit örneklerle mi çalıştığı ve müşterinin ortamına kurulup kurulamadığı belirlenmelidir. Tek bilgisayarda çalışan görüntü ile kurulabilir, belgelenmiş ve sözleşmedeki işlevleri sağlayan teslim farklıdır. Bununla birlikte sözleşme yalnız prototip geliştirmeyi konu alıyorsa tamamlanma ölçütü de o prototipe göre kurulur; üretim sistemi koşulları sonradan eklenmez.

İncelemede kurulum talimatı, gerekli bileşenlerin sürümleri, bağlantı ayarları ve yetki gereksinimleri kaydedilir. Üçüncü taraf lisansı olmadan çalışmayan parça varsa bu lisansı kimin sağlayacağı sözleşmeden kontrol edilir. Çalıştırma başarısızlığının kod eksikliğinden mi yoksa müşteri ortamındaki hazırlıktan mı doğduğu açıklanmalıdır. Yeni uzmanın kurulum hatası eski geliştiricinin aykırılığı gibi gösterilmemeli; tekrarlanabilir deneme adımları tutulmalıdır. Böylece gösterilen sonucun gerçek ilerleme ile ilişkisi ortaya çıkar.

Yüklenici yalnız ekran videosu sunuyorsa işsahibi taahhüt edilmiş teslimlerin hangi bölümünün mevcut olduğunu ayrıca sorabilir. Video, olayın bir delilidir; kaynak, yapılandırma ve işlev incelemesinin her durumda yerine geçmez. Eksik belge nedeniyle teknik devamın mümkün olmadığı ileri sürülüyorsa belgenin sözleşmeyle teslimi gerekip gerekmediği de incelenir. Teslim listesinde bulunmayan yeni dokümantasyon isteği, önceki borcun ihlali olarak sunulmamalıdır.

Gecikmede müşterinin payı varsa erken dönme değişir mi?

TBK m. 473’te işsahibine yüklenemeyen gecikme ayrımı önemlidir. Müşterinin gerekli erişimi açmaması, ilk kapsamı sürekli değiştirmesi veya kararlaştırılmış onayı vermemesi iddiası varsa bunun gerçekten hangi işi etkilediği araştırılır. Yüklenicinin kendi organizasyon eksikliği, müşteriden istenen küçük bir bilgi üzerinden bütünüyle karşı tarafa aktarılamaz. Müşteri de kendi engelini gizleyerek bütün takvimi yüklenici ihlali olarak sunmamalıdır.

Her gecikme kaydı, talep edilen girdi ve alınma tarihiyle eşleştirilmelidir. Girdi beklenirken bağımsız işlerin neden yapılmadığı sorulmalıdır. Eserin zamanında veya gereği gibi ortaya çıkmasını tehlikeye düşüren durumun TBK m. 472 uyarınca hemen bildirilip bildirilmediği de incelenir. Bu kontrol, dönme bildiriminin dayanağını güçlendirir ve karşı tarafın “işi müşteri durdurdu” savunmasının hangi belgeye dayandığını açıklığa kavuşturur.

Dönme bildirimi hangi içeriği taşımalıdır?

Bildirim sözleşmeyi, ilgili eser bölümünü, ihlal edilen yükümlülükleri ve dayanılan olguları göstermelidir. Belirsiz bir “çalışmaktan memnun değiliz” ifadesi yerine işe başlamama, somut geciktirme veya tamamlamanın zamanında mümkün olmadığını ortaya koyan kayıtlar açıklanmalıdır. Dönme iradesi, yalnız performans hakkında şikâyet edilmesinden farklıdır. Hangi sözleşmenin hangi hukuki sebeple sona erdirildiği muhatap tarafından anlaşılmalıdır.

Tacirler arasındaki temerrüt, fesih ve dönme bildirimlerinde TTK m. 18/3 dikkate alınır. Noter, taahhütlü mektup, telgraf veya güvenli elektronik imzayla kayıtlı elektronik posta yöntemleri kanunda sayılmıştır. Tacirler arasındaki ihtar yöntemleri, proje sohbetindeki mesajla hukuki sona erdirme bildiriminin ayrılması bakımından önemlidir. Teknik kayıtlar bildirim ekleriyle birbirine bağlanmalıdır.

TBK m. 473’ün iki fıkrası aynı işlemi düzenlemez

Birinci fıkra, belirtilen erken dönme durumlarına ilişkindir. İkinci fıkra ise eser meydana getirilirken yüklenicinin kusuru yüzünden ayıplı veya sözleşmeye aykırı sonuç ortaya çıkacağının açıkça görülmesini düzenler. İşsahibi, uygun süre içinde aykırılığın giderilmesini; aksi hâlde onarımın veya işe devamın hasar ve masraf yükleniciye ait olmak üzere üçüncü kişiye verileceğini ihtar edebilir. Bu ayrı yolun süre ve ihtar içeriği korunmalıdır.

Salt işin terk edilmesi iddiasına dayanıp ikinci fıkranın bütün sonuçlarını otomatik uygulamak doğru değildir. Hangi olgunun hangi fıkraya uyduğu belirlenmelidir. Genel yapma borcunda başkasına yaptırma bakımından TBK m. 113’ün mahkeme izni düzeni de ayrı bir hukuki yoldur. Taraflar geçerli bir tamamlama protokolünde uzlaşırsa onun kapsamı ayrıca esas alınır. Yeni geliştiriciye ödeme yapılması, eski yüklenicinin bütün bu tutarı her durumda borçlandığını tek başına göstermez.

Yeni ekip dokunmadan önce mevcut sürüm korunmalıdır

Yarım yazılımın mevcut hâli tespit edilmeden yeni ekibin kodu değiştirmesi, sonradan aykırılığın hangi yükleniciden kaynaklandığını belirsizleştirir. Yetkili erişim çerçevesinde kod deposunun ilgili sürümü, çalıştırma dosyaları, bağımlılık listesi, yapılandırma bilgisi ve test sonuçları korunmalıdır. Erişim sınırını aşan veri alma veya yetkisiz sisteme giriş, delil toplama gerekçesiyle haklı hâle gelmez.

HMK m. 400, delilin kaybolması veya ileride ileri sürülmesinin önemli ölçüde zorlaşması tehlikesi gibi hukuki yarar durumlarında delil tespiti imkânı sağlar. Delil tespiti talebinde incelenecek sürüm, fonksiyon ve kayıtlar somutlaştırılır. Tespit, davanın esasını çözen karar değildir. İncelemede hangi ortamın kullanıldığı ve eski sürümün sonradan değişmediği gösterilmelidir.

Başka geliştirici mevcut kod üzerinde çalışabilir mi?

Mevcut kodun şirkete teslim edilmesi ile kod üzerinde değişiklik yapma veya üçüncü kişiye kullandırma yetkisi aynı değildir. FSEK m. 48 ve m. 52 kapsamında ruhsatın ve mali hak düzeninin kapsamı incelenir. Mali haklara ilişkin sözleşme ve tasarrufların yazılı olması ve hakların ayrı ayrı gösterilmesi gerekir. Lisansın devri iddiasında FSEK m. 49’daki yazılı muvafakat şartı da ilgili işlem yönünden değerlendirilir.

Yeni ekibin hangi erişim ve değişiklik yetkisiyle görevlendirildiği belgeye bağlanmalıdır. Yazılımın telif hakkıyla korunması konusundaki esaslar, bedelin ödenmiş olmasının bütün hakları otomatik devretmediğini açıklar. Kodu teslim borcu, mali hak iddiası ve acil teknik devam ihtiyacı ayrı talep başlıklarıdır. Şirketin kendi verisinin korunması ile başkasına ait kodun hukuki kullanım sınırı birbirine karıştırılmamalıdır.

Ödenen avansın tamamı geri alınır mı?

Dönmenin hukuki sebebi ve kapsamı belirlendikten sonra tasfiye hesabı yapılır. Peşin ödenen tutarın adı, tek başına iade miktarını belirlemez. Analiz, tamamlanmış bağımsız modül, lisans veya bakım için ayrı bedeller bulunuyorsa hangi edimin gerçekleştiği değerlendirilir. Müşterinin elinde kalan ve kullanılmaya devam edilen sonuç ile hiç teslim edilmemiş bölüm aynı hesap satırına yazılmamalıdır.

İşsahibi hem tamamlanmış sonuçları hangi hukuki temelde elinde tutacağını hem talep ettiği iadeyi açıklamalıdır. Yüklenici de yalnız harcadığı bütün zamanı göstererek her avansı hak edilmiş bedel sayamaz. Sözleşmenin yapısı, teslim edilen değer, karşılıklı iade yükümlülükleri ve taleplerin hukuki niteliği birlikte belirlenir. İade çizelgesinde ödeme tarihi, ödeme amacı, karşılık gelen teslim ve tartışmalı bakiye ayrı gösterilir; aynı tutar hem iade hem zarar kalemi olarak tekrar istenmez.

Yeni geliştiricinin bedeli zarar hesabına nasıl girer?

İşi tamamlama gideri ile ilk sözleşmede bulunmayan yeni özelliklerin bedeli ayrılmalıdır. Yeni ekibin teklifinde devralma incelemesi, mevcut aykırılığı düzeltme, kalan kapsamı tamamlama ve ek geliştirme ayrı kalemlerde bulunmalıdır. Daha modern bir tasarımın bütünüyle yeniden yapılması tercih edilmişse bunun zorunlu kısmı ve ticari iyileştirme kısmı açıklanır. Eski yükleniciye her yeni yatırımın yüklenmesi kanuni zarar hesabı değildir.

TBK m. 112 çerçevesinde borca aykırılık, zarar ve uygun nedensellik ortaya konulur; borçlu kusursuzluğunu ispat etmedikçe sorumludur. Dönme, ifadan vazgeçme, üçüncü kişiye tamamlattırma veya sözleşmeyi sürdürme yollarının tazminat sonuçları aynı değildir. Bu nedenle müşterinin kullandığı hak ile talep ettiği gider birbiriyle uyumlu olmalıdır. Tasarruf edilen ilk sözleşme bedeli ve aynı zararı karşılayan ödemeler de hesapta gözetilmelidir.

Proje gecikmesinden doğan satış kaybı nasıl somutlaştırılır?

Planlanan satışların tamamını yazılımın bırakılmasına bağlamak yeterli değildir. Gerçekleşmiş siparişler, zorunlu alternatif sistem giderleri, manuel işlem maliyeti ve sözleşmesel yükümlülükler olayla bağlantıları içinde incelenir. Brüt ciro ile net zarar aynı değildir. Yapılmayan iş nedeniyle katlanılmayan giderler düşülmeden bütün beklenen gelir zarar olarak sunulamaz. Tahmin tablosunun dayandığı somut kayıtlar açıklanmalıdır.

Müşterinin makul biçimde önleyebileceği kaybı büyütmesi de değerlendirilir. TBK m. 114’ün yollamasıyla TBK m. 52, zarar görenin katkısının etkisini düzenler. Geçici çözüm kurulması, mevcut sistemi belirli süre kullanma imkânı veya riskin zamanında bildirilmesi dosyanın parçasıdır. Bunlar zarar görenin her maliyetle sorunu çözmek zorunda olduğu anlamına gelmez; önlemin uygunluğu ve olayla bağlantısı incelenir.

Müşterinin projeden vazgeçmesiyle yüklenici ihlali aynı değildir

TBK m. 484, işsahibine eser tamamlanmadan yapılmış kısmın karşılığını ödemek ve yüklenicinin bütün zararını gidermek koşuluyla sözleşmeyi feshetme hakkı verir. Bu serbest sona erdirme yolu ile yüklenicinin ihlaline dayanan TBK m. 473 aynı mali sonuçları doğurmaz. Bildirimde hangi sebebe dayanıldığının açık olması bu yüzden önemlidir. Şirketin ticari planını değiştirmesi, kendiliğinden yüklenicinin işi terk ettiği anlamına gelmez.

İşsahibi gerçek bir ihlal bulunmadan yalnız yeni sağlayıcıyı daha uygun bulduğu için sözleşmeyi sonlandırmışsa değerlendirme farklıdır. Yüklenici de açık ihlalini görmezden gelip müşterinin her sona erdirme bildirimini otomatik TBK m. 484 sayamaz. Tarafların kullandığı sözcükler kadar olaylar ve gerçek irade incelenir. Dosyada yazışmaların tamamı, ödeme düzeni ve işin durduğu aşama birlikte sunulmalıdır.

Yeni geliştiriciye geçiş tutanağında hangi bilgiler bulunmalıdır?

Geçiş tutanağı, devralınan kod sürümü, çalışır modüller, açık hata listesi, eksik teslimler ve erişim yetkilerini göstermelidir. Müşterinin verileri, üretim ortamı, test ortamı ve üçüncü taraf hesapları ayrı listelenir. Yeni ekip önceki yüklenici hakkında hukuki kabul beyanı vermek zorunda değildir; gördüğü teknik durumu tarafsız biçimde kaydeder. Eski sözleşmenin borç hesabı, yeni iş emrinin içine belirsiz şekilde karıştırılmamalıdır.

Yeni sözleşmede kalan kapsam, teslim ölçütleri ve önceki koddan kaynaklanan sorunların nasıl ele alınacağı açıkça yazılmalıdır. Devirden sonra yapılacak değişiklikler ayrı sürümle tutulmalı; ilk tespit kaydı korunmalıdır. Gizli bilgiler yalnız işin gerektirdiği ölçüde yetkililere açılır. Canlı sistem üzerinde işlem yapılacaksa geri dönüş planı ve yetkili erişimler önceden belirlenir; inceleme sırasında müşteri kayıtlarının bozulması yeni bir sorumluluk sorunu doğurmamalıdır. Teknik devamın sağlanması ile eski yükleniciden talep edilen iade ve zarar dosyası birlikte izlenir, ancak birinin sonucu diğerine ilişkin kanuni koşulları ortadan kaldırmaz.

Sık sorulan sorular

Yazılımcı işi bırakınca son teslim tarihini beklemek gerekir mi?

TBK m. 473/1 koşulları oluşmuşsa teslim günü beklenmeden sözleşmeden dönülebilir. İşe başlamama, sözleşmeye aykırı geciktirme ve zamanında bitirmenin açıkça mümkün görülmemesiyle ilgili olgular somutlaştırılmalıdır.

Kod deposunda uzun süre değişiklik olmaması yeterli delil midir?

Tek başına bütün işin bırakıldığını göstermez. Son sürüm, başka çalışma kayıtları, yapılan işler ve kalan plan incelenir. İddia belirli proje borcunun fiilen yerine getirilmemesine bağlanmalıdır.

Tamamlanma yüzdesini kim belirler?

Sözleşmedeki teslim ve işlevlere dayanan teknik inceleme gerekir. Satır veya kapatılan görev sayısı tek başına ölçüt değildir. Uzman teknik ilerlemeyi değerlendirir; hukuki dönme sonucunu mahkeme belirler.

Müşteri erişim vermemişse de bütün gecikme yazılımcıya yüklenir mi?

Hayır. Müşteriye ait hazırlık işleminin hangi işi durdurduğu incelenir. Yüklenicinin bağımsız gecikmeleri ve TBK m. 472 uyarınca engeli hemen bildirme yükümlülüğü de ayrıca değerlendirilir.

İşi hemen başka yazılımcıya verip bütün bedelini isteyebilir miyim?

Otomatik olarak değil. TBK m. 473/2 uygun süre ve ihtarla üçüncü kişiye devam ettirme yolunu belirli koşullarda düzenler. TBK m. 113 mahkeme izni yolu ve diğer hakların koşulları ayrı değerlendirilir.

Yarım yazılımın kodunu yeni ekip serbestçe değiştirebilir mi?

Kod üzerindeki kullanım ve değişiklik yetkisi incelenmelidir. FSEK m. 48, m. 49 ve m. 52 kapsamında ruhsat, devir izni ve yazılı hak düzeni önemlidir. Ücret ödemesi bütün mali hakları otomatik devretmez.

Dönme hâlinde bütün avans otomatik geri gelir mi?

İade hesabı sözleşmenin yapısına, kullanılan hakka ve gerçekleşen edimlere göre kurulur. Bağımsız teslimler, elde tutulan sonuçlar ve karşılıklı iade ayrı değerlendirilir; avans adı tek başına tutarı belirlemez.

Yeni yazılıma eklenen bütün özellikler zarar sayılır mı?

Hayır. İlk kapsamı tamamlama ve aykırılığı giderme giderleri ile yeni yatırım ayrılır. Talep, kullanılan hukuki yolun sonuçları, gerçek zarar ve nedensellik temelinde hesaplanır.

Müşterinin ticari planını değiştirmesi TBK m. 473 sayılır mı?

Tek başına sayılmaz. İşsahibinin serbest sona erdirme hakkı TBK m. 484 kapsamında yapılmış kısım ve yüklenicinin zararlarının karşılanması koşuluna bağlıdır. İhlale dayalı dönme bundan ayrılır.

Yeni ekip başlamadan delil tespiti zorunlu mudur?

Her dosyada zorunlu değildir. HMK m. 400 kapsamındaki hukuki yarar ve delilin kaybolma veya ileri sürülmesinin önemli ölçüde zorlaşma tehlikesi değerlendirilir. Mevcut sürümün güvenilir biçimde korunması önemlidir.

İstanbul ve Mersin ofislerinde yarım kalan yazılım projesi incelenirken sözleşme, ilk iş planı, son çalışır sürüm, ödemeler ve yükleniciyle yazışmalar birlikte ele alınır. Teknik inceleme eski ekibin bıraktığı durumu yeni ekibin çalışmasından ayırmalıdır. Dönme bildirimi, delil koruma, iade hesabı ve yeni geliştiriciye geçiş belgeleri aynı proje dosyası üzerinden hazırlanır.

Kanun maddeleri ve resmî kaynaklar

• 6098 sayılı Türk Borçlar Kanunu — güncel resmî UYAP metni: m. 52, 112–114, 470–473 ve 484
• 6102 sayılı Türk Ticaret Kanunu — güncel resmî UYAP metni: m. 18/3
• 6100 sayılı Hukuk Muhakemeleri Kanunu — güncel resmî UYAP metni: m. 400
• 5846 sayılı Fikir ve Sanat Eserleri Kanunu — güncel resmî UYAP metni: m. 48, 49 ve 52

Av. Halil Bakırcı tarafından hazırlanmış, Av. Emirhan Keskin tarafından incelenmiştir.

Yazar Bilgisi

Avukat Halil BAKIRCI, Mersin Barosu 3472 sicil numarasına kayıtlıdır. Bakırcı & Keskin Hukuk Bürosu bünyesinde ceza, aile, iş, gayrimenkul ve ticaret hukuku alanlarında hukuki danışmanlık ve dava takibi sunmaktadır.

İnceleyen: Av. Emirhan Keskin · Mersin Barosu Sicil No: 5507

Av. Halil Bakırcı profilini inceleyin →