Net kategoriler, alım formları, yönlendirme kuralları ve durum güncellemeleri ile kaosu ve kaybolan işleri azaltan bir dahili talep kataloğu spesifikasyonu nasıl yazılır öğrenin.
Geçici istekler genelde zararsız görünür: “hızlıca bir alan ekler misin?” diyen bir DM, beş kişinin CC’li olduğu bir e-posta dizisi, koridorda sorulan bir soru ya da bir grup sohbete atılan bir yorum. Her biri "bir form doldurmaktan" daha hızlı hissettiği için bu alışkanlık devam eder.
Asıl sorun istek sonrasında ortaya çıkar. Mesajı gören kişi çevrimdışına çıkınca, takım değiştirince ya da basitçe unutunca işler kaybolur. Öncelik pazarlığı haline gelir çünkü kimin üzerinde çalıştığına dair ortak bir görüş yoktur. Farklı insanlar aynı şeyi farklı yerlerde ister, bu yüzden ya işi çoğaltırsınız ya da aynı soruları defalarca yanıtlamak zorunda kalırsınız. Ve yanıtlar yavaşsa, genellikle takımın umurunda olmamasından değil; istekte eksik ana detaylar olduğundan ve uzun bir gidip gelme sürecine dönüştüğünden kaynaklanır.
Herkes acıyı hisseder, ama farklı şekillerde. İstek sahipleri bunun görülüp görülmediğini, ne zaman yapılacağını ya da "tamamlandı"nın ne demek olduğunu bilmez. Onaylayanlar bağlam, son tarih veya etki olmadan muğlak kararlar almak zorunda kalır. Operasyon ve yapanlar kesintilerle uğraşır ve en yüksek sesliye tepki verir. Yöneticiler iş yükünü, eğilimleri veya zamanın gerçekten nereye gittiğini göremez.
"İzlenebilir iş" bu kaosun tersi demektir. Her istek tek bir yerde (örneğin bir dahili talep kataloğunda) yaşar, net bir sahibi, güncel bir statüsü ve kararlarla güncellemelerin görünür bir geçmişi vardır. Ayrıca istekler karşılaştırılabilir: sıralayabilir, önceliklendirebilir ve neyin değiştiğine dair bir kayıtla kapatabilirsiniz. İş izlenebilir olduğunda daha az istek takılır ve daha az kişi cevap kovalamak zorunda kalır.
İlk sürümünüzün bir işi iyi yapması yeterli: “hızlıca yapar mısın…” cümlesini bir sahibin, net bir sonraki adımın ve görünür bir statünün olduğu bir işe dönüştürmek. Hedefleri basit tutun ki dağıtımı anlatmak ve ölçmek kolay olsun.
Başlangıçta hangi takımların dahil olacağını isimlendirin. Dar bir lansman grubu kafa karışıklığını azaltır ve pürüzleri hızlıca düzeltmenize yardımcı olur. Örneğin, IT (erişim, cihazlar, hesaplar), Operasyon (tesisler, tedarikçiler, süreç düzeltmeleri), Finans (satın alma talepleri, faturalar), People Ops (onboarding, politika soruları) ve Müşteri Destek Operasyonları (araçlar, makrolar, raporlama) dahil edilebilir.
Kapsam konusunda açık olun. Katalog, net bir çıktısı olan küçük-orta ölçekli istekler için en iyi şekilde çalışır. Daha büyük çabaları farklı ele alın ki katalog sessizce bir proje takip aracına dönüşmesin.
Uygun örnekler: “Yeni bir Slack kanalı oluştur,” “Bir dizüstü ayarla,” “Bir forma alan ekle,” “Erişimi sıfırla,” veya “Bir yazılım lisansı sipariş et.” Uymayanlar: haftalar süren girişimler, çapraz takım projeleri, yol haritası çalışmaları ve “tamamlandı”nın ne olduğunu tanımlamadan önce keşif gerektiren işler.
Başarı metriklerini haftalık kontrol edebileceğiniz şekilde seçin, çeyreklik değil. İyi başlangıç noktaları: ilk yanıt için medyan süre, isteklerin yüzde kaçı 1 iş günü içinde bir sahip atanmış, yeniden açılma oranı, vaat edilen süre içinde tamamlanan yüzde ve istek sahibi memnuniyeti (basit 1–5 puanlama).
Hizmet saatleri ve “acil”in ne anlama geldiği konusunda anlaşın. Bunu bir cümleyle yazın, örneğin: “Acil, işin engellendiği ve hiçbir geçici çözümün olmadığı durumları ifade eder.” Eğer acil iş kabul ediliyorsa, kimin işaretleyebileceğini ve hizmet saatleri içindeki yanıt beklentisini belirtin.
Bir talep kataloğu, insanların saniyeler içinde bir kategori seçebilmesi durumunda işe yarar. İlk versiyonu küçük tutun. Genelde 6–12 kategori yeterlidir. Daha fazlasına ihtiyaç varsa, bu etiketlerin çok teknik olduğu veya çok farklı iş akışlarını karıştırdığınız anlamına gelir.
İstekçi dilini kullanın, iç takım dilini değil. “Yeni dizüstü” "Endpoint procurement"dan daha iyidir. “Salesforce erişimi” "CRM permissioning"den daha iyi. Bir kişi kafasında çevirmek zorundaysa yanlış şeyi seçer veya kataloğu atlar.
Her kategori için basit bir tanım yazın: bir iki cümle ve birkaç yaygın örnek. Bu uzmanlara yönelik dokümantasyon değil; yoğun insanlar için bir kılavuzdur. Örneğin, “Hesap erişimi” yeni erişimleri, rol değişikliklerini ve kaldırmaları kapsayabilir. “Donanım” yeni dizüstü, yedek veya aksesuarları kapsayabilir.
İşte istekçilerin konuşma diliyle yazılmış beş örnek kategori:
Her zaman bir “Emin değilim” kategorisi ekleyin. Davranışını öngörülebilir kılın: bunu kısa bir SLA ile triage kuyruğuna yönlendirin (genelde IT helpdesk veya bir operasyon koordinatörü), böylece belirsizlik sessizliğe dönüşmez.
Bir kategoriyi yalnızca işin nasıl yürüdüğünü değiştiriyorsa bölün. Yaygın tetikleyiciler: farklı onaycılar, formda farklı bilgi gereksinimleri veya anlamlı derecede farklı yanıt süreleri. Aynı takım aynı adımlarla ele alıyorsa, şimdilik birlikte tutun ve gerçek talep hacmine ve yanlış yönlendirmelere göre sonra iyileştirin.
İyi bir alım formu hem iki tarafın zamanını kurtarır. Amaç her şeyi toplamaktan ziyade olağan gidip gelmeleri durduracak birkaç detayı toplamaktır. Bir dahili talep kataloğu çalıştırıyorsanız, tutarlılık mükemmellikten daha önemlidir.
Her kategori için görünür olan ortak bir çekirdekle başlayın. Bu, raporlama ve triage'ı kolaylaştırır ve istekçilerin paterni öğrenmesine yardımcı olur:
Sonra, her kategori için sıkça sonra sorulan detayları yakalayan alanlar ekleyin. Bir erişim talebi genellikle sistem adı, rol/izin seviyesi ve onaylayıcı yönetici bilgisi ister. Bir veri talebi rapor adı, zaman aralığı ve çıktının nereye gitmesi gerektiğini isteyebilir.
Formu kısa tutmak için koşullu sorular kullanın. Birisi bir sistem seçtikten sonra yalnızca “Gerekli rol”u gösterin. “Ortam = Production” seçildiğinde yalnızca “Production erişimi” uyarılarını gösterin. AppMaster gibi kodsuz araçlar bu tür mantığı temiz şekilde yönetebilir, böylece insanlar sadece kendileri için geçerli olanı görür.
Gerekli ile isteğe bağlı arasındaki farkı açık tutun. Eksik gerekli bilgi olduğunda isteği rehavsizce geri çevirmeyin. Bunun yerine bir kural koyun: isteği “İsteyen bekleniyor” statüsüne taşıyın ve tam olarak ne gerektiğini listeleyen tek odaklanmış bir soru sorun.
Dosya yüklemeleri yardımcı olabilir, ama risk de getirir. Başta basit kurallar koyun: izin verilen dosya türleri (örneğin PDF, PNG, CSV), boyut limiti ve neyin sansürlenmesi gerektiği (kişisel veriler, şifreler, API anahtarları). Bir ekran görüntüsü hassas detaylar içeriyorsa, çalışmaya başlamadan önce sansürlenmiş bir versiyon isteyin.
Onaylar işi korumalı, yavaşlatmamalı. İşin püf noktası öngörülebilirliktir. İnsanlar baştan kimin onaylayacağını, kimin gönderebileceğini ve sonrasında ne olduğunu bilmelidir.
Her kategori için kimlerin gönderebileceğini tanımlayın. Bazı kategoriler “herkes gönderebilir” (kırık bir aracın onarımı gibi) olabilir. Diğerleri belirli rollere (yeni tedarikçi oluşturma gibi) veya yalnızca yöneticilere (işe alım veya kadro değişiklikleri gibi) sınırlı olmalıdır. Bunu atladıysanız, gürültülü talepler gelir ve yöneticiler insan filtreleri gibi davranmak zorunda kalır.
Her kategori için minimum onaycıları listeleyin ve tutarlı tutun. Birçok takım küçük bir standart kontrol seti kullanır: isteğin yöneticisi (öncelik ve kaynak), bütçe sahibi (harcama ve yenilemeler), güvenlik (yeni araçlar, entegrasyonlar, erişim değişiklikleri), veri sahibi (yeni raporlar, veri paylaşımı, hassas alanlar) ve gerektiğinde hukuk veya uyumluluk.
Düşük riskli, düşük maliyetli işler için otomatik onay eşiklerini kullanın. Örneğin, “müşteri verisi içermeyen aylık 100$/altı yazılım” otomatik onaylanabilir; üretim sistemlerini veya PII’yi ilgilendiren her şey her zaman güvenliğe ve veri sahibine gider.
İstisapların nasıl çalıştığını yazılı hale getirin ki insanlar yorumlarda tartışmasın. İstekçi “acil” derse bir gerekçe (müşteri etkisi, kesinti, son tarih) isteyin ve on-call onaycısına veya isimlendirilmiş bir yükseltme yoluna yönlendirin.
Onaycıların yokluğunu planlayın. Bir yaklaşım seçin ve ona sadık kalın: bir delege, bir zaman aşımı (örneğin 24 saat sonra otomatik yönlendirme) veya yedek onaycı (örneğin yöneticinin yöneticisi). AppMaster gibi platformlarla yapılan araçlarda bu kuralları iş kuralları olarak uygulayabilirsiniz, böylece onay süreçleri birinin süreci hatırlamasına bağlı kalmaz.
Yönlendirme, bir dahili talep kataloğunun sadece bir liste olmaktan çıkıp bir sisteme dönüşmesidir. Amaç basittir: doğru kişi isteği hızlıca görsün ve net bir sonraki adım olsun.
Her kategori için tek bir atama yöntemi seçin. Bazı kategoriler takım kuyruğu (herkes alabilir) olarak en iyi çalışır. Diğerleri yükü dağıtmak için round-robin gerektirir. Birkaç iş her zaman belirli bir sahibine gitmelidir, örneğin bordro değişiklikleri veya güvenlik erişimi.
Triage, dağınık girdi için güvenli bir yol gerektirir. “Emin değilim” kategorisini tutun ve şu kuralı ekleyin: bir koordinatör kısa bir süre içinde inceler, sonra isteği sahibine tekrar yönlendirir; isteği sahibine geri göndermeden yeniden dosyalama yapar. Yanlış dosyalanmış istekler için de aynı uygulamayı yapın. Atanan kişi doğru kategoriye taşır ve neyin değiştiğini açıklayan kısa bir not bırakır.
Önceliği basit dille tanımlayın ki insanlar sonuçları öngörebilsin. Pratik bir model etki (kaç kişiyi etkilediği), zaman duyarlılığı (son tarihler) ve görünürlük (müşteri odaklı mı, dahili mi) kullanır. “Acil”i serbest metin alanı yapıp kural koymaktan kaçının.
Gerçekçi hedefler belirleyin. Küçük bir set yeterlidir: ilk yanıt süresi (örneğin erişim talepleri için aynı gün), kategori bazında beklenen tamamlanma pencereleri (örneğin 2–3 iş günü), bir yükseltme tetikleyicisi (örneğin 48 saat güncelleme yoksa), devralmalarda sahiplik (kim isteği günceller) ve “tamam” tanımı (ne teslim edilmeli).
Çoğaltmalar, bağımlılıklar ve engellenen işler için kurallar ekleyin. Bir istek mevcut bir taleple eşleşiyorsa birleştirin ve isteği bilgilendirin. Eğer başka bir takıma bağımlıysa “Blocked” olarak işaretleyin, bağımlılığı adlandırın ve tekrar kontrol etmek için hatırlatma koyun. AppMaster gibi araçlar bu yönlendirme kurallarını ve statüleri görsel mantıkla modelleyebilir, böylece kategoriler büyüdükçe kurallar tutarlı kalsın.
İnsanlar ne olduğunu göremezse tekrar sohbet, DM veya çoğaltma yaratırlar. Hizmet talebi durum şeffaflığı, dahili talep kataloğunuzu kara kutu yerine ortak bir gerçek kaynağına çevirir.
İşi gerçekçi şekilde hareket ettiren küçük bir statü setiyle başlayın. Daha az seçenek daha az tartışma ve daha tutarlı güncellemeler demektir.
İş akışını basit tutun ve her statüye girip çıkmak için neyin gerçek olması gerektiğini tanımlayın:
Statüler tanımlandıktan sonra, istek sahiplerinin her zaman neyi görebileceğine karar verin. Pratik bir minimum: güncel statü, sahip, bir sonraki eylem, son güncelleme zamanı ve kilit zaman damgaları (gönderildi, başladı, tamamlandı). “Bir sonraki eylem” uzun yorumlardan daha önemlidir çünkü gerçek soruyu cevaplar: sırada ne var ve kim kimin beklediği?
Bildirimleri takipleri azaltmak için kullanın, spam için değil. Basit bir set iyi işler: gönderimde bir onay (içinde bir sonraki beklenen adım), statü değişiminde bir uyarı (neden tek cümleyle), birisi yorum yaptığında veya soru sorduğunda uyarı ve Done olduğunda bir kapatma mesajı (ne teslim edildi ve nasıl doğrulanır dahil).
Zamanlama konusunda, gerçekten taahhütte bulunabilecekseniz kesin tarihler vermekten kaçının. Bunun yerine hedef aralık gösterin: “ilk yanıt 1 iş günü içinde” ve “triage sonrası tipik teslimat 3–5 iş günü” gibi.
Örnek: bir onboarding erişim talebi, yönetici gereken araçları listelemediği için Waiting on requester olur. İstek sahibi “Bir sonraki eylem: araç listesini sağlamak” ve yalnızca onların yanıtından sonra başlayacak bir hedef pencere görür. Bu sessiz gecikmeleri önler ve beklentileri adil tutar.
AppMaster gibi bir araçta kataloğunuzu oluşturursanız, bu alanları sade bir istekçi portalında gösterebilir ve statü değişikliklerinden bildirim tetikleyebilirsiniz, böylece güncellemeler ekstra manuel çalışma olmadan tutarlı şekilde yapılır.
Kataloğu fikirler değil, gerçek işler üzerine kurun. Son 30–90 gündeki talepleri sohbetten, e-postadan, ticketlardan ve toplantı notlarından çekin. Tekrarları arayın: farklı sözlerle gelen aynı istekleri not edin.
Bu tekrarları insan isimleriyle kısa bir iş talepleri kümesine dönüştürün. İsimleri insan odaklı tutun (örneğin “Erişim talebi” yerine “Access request”). Yayınlamadan önce kategori listesini 5–10 sık istek yapan kişiye okuyun ve bir soru sorun: “Son isteğinizi nereye dosyalarınız?” Sonra kafa karıştırıcı etiketleri düzeltin.
Her istek için çalışacak kısa bir temel form oluşturun, sonra en yüksek hacimli kalemler için yalnızca iki–üç kategori-özgü form ekleyin. Sağlam bir ilk sürüm şöyle görünür:
Tek sayfalık kurallar için “bir sonraki sahibi kim” ve “tamamlanmış ne demek”e odaklanın. Her yerde aynı statü setini kullanın (New, Triage, In progress, Waiting on requester, Done) ve her birini tetikleyenleri tanımlayın.
AppMaster gibi bir araçta iş akışını kuruyorsanız, ilk sürümü kasıtlı olarak sade tutun: tek bir temiz form, net statüler ve otomatik yönlendirme. Pilot, gerçekten eksik olanı gösterene kadar karmaşıklık eklemeyin.
Bir satış müdürü Priya, Jordan'ı işe alıyor. Pazartesi sabahı iki şeye ihtiyacı var: CRM erişimi ve bir dizüstü. Üç farklı kişiyi mesajlamak yerine iç talep kataloğunu açar ve iki istek başlatır.
Önce Kategori: “Yeni işe alım erişimi” seçer. Alım formu kısa ama spesifiktir: yeni çalışan adı, başlama tarihi, takım, yönetici (Priya’nın profili otomatik doldurulur), hangi sistemlerin gerektiği (CRM, e-posta, sohbet) ve çalışanın uzaktan olup olmadığı. Ayrıca “İş sebebi nedir?” diye bir satırlık örnek verilir ki insanlar fazla düşünmesin.
Sonra ikinci isteği Kategori: “Donanım ve ekipman” altında açar. Bu form dizüstü model tercihini (veya “standart”), gönderim adresini, maliyet merkezini ve monitör veya kulaklık gerekip gerekmediğini sorar.
Onaylar arka planda sessizce gerçekleşir. Erişim talebi yalnızca yönetici onayı gerektiriyorsa Priya yönetici kaydında olduğu için otomatik onaylanır. Dizüstü talebi tahmini maliyeti kontrol eder. Eğer takımın ödeneğinin üzerindeyse bütçe sahibini otomatik olarak ekler; değilse doğrudan IT tedarikine gider.
Priya her iki isteği de kimseyi rahatsız etmeden takip edebilir:
Priya dizüstü isteğini yanlışlıkla “Yeni işe alım erişimi” altında dosyalarsa, triage bunu düzeltir, kategoriyi değiştirir ve tedarike yönlendirir. İstek aynı ID, yorumlar ve eklerle korunur, böylece hiçbir şey kaybolmaz.
Bu kataloğu basit bir iç portal olarak (örneğin AppMaster ile) kurarsanız aynı spesifikasyon temiz formlar, yönlendirme kuralları ve takipleri azaltan bir statü sayfası üretebilir.
Bir iç talep kataloğu yalnızca insanlar ona güvendiğinde işe yarar. Başarısızlıkların çoğu “araç”la ilgili değildir. Süreci mesaj göndermekten daha zor hissettiren tasarım seçimleridir.
Tekrarlanan problemler ve çözümleri:
Kısa bir gerçeklik kontrolü: istek sahipleri takip mesajları göndermeye devam ediyorsa genelde statüleriniz belirsizdir veya alım formunuz ilerlemek için gereken tek detayı yakalamamıştır.
AppMaster gibi bir no-code araçta kataloğunuzu kurarsanız aynı kurallar geçerlidir: kategorileri tanıdık tutun, formları adaptif yapın ve gerçek bekleme noktalarını yansıtan statüler modelleyin.
Yayınlamadan önce netlik ve tutarlılık için son bir tur yapın. Takımlar nadiren özellik eksikliğinden başarısız olur; başarısızlık kuralların belirsiz olması, kategorilerin çakışması ve istekçilerin ne olacağını önceden tahmin edememesi yüzündendir.
Bu kontrol listesini 2–3 gerçek istekçi ve her teslim ekipten bir kişiyle birlikte gözden geçirin:
Basit bir test: e‑posta veya sohbetteki son beş geçici isteği alın ve bunların temiz şekilde bir kategoriye, bir forma, bir sahibe ve öngörülebilir bir statü yoluna eşlenip eşlenmediğini kontrol edin.
Yüksek hacimli bir alan seçin (örneğin onboarding, erişim talepleri veya raporlar) ve bir hafta içinde ilk versiyonu yayınlayın.
Tek sayfalık bir spesifikasyon taslağı hazırlayın (kategoriler, gerekli alanlar, yönlendirme kuralları, onaylar ve statü tanımları). Yanıt beklentilerini belirleyin: kim onaylıyor, ne zaman ve "tamam" ne demek. Alımı ve iş akışını tek bir iç uygulama olarak oluşturun ki talepler, yönlendirme ve statüler tek yerde yaşasın. Temel raporlama ile başlayın: kategoriye göre istek sayısı, ilk yanıta geçen süre ve kapanış süresi.
Formları ve kuralları sık değiştirecekseniz, kataloğu AppMaster (appmaster.io) gibi bir yerde kurmak yardımcı olabilir; iş mantığını güncellemenize ve gereksinimler değiştikçe uygulamayı yeniden üretmenize olanak sağlar, tam bir mühendislik döngüsünü beklemeden.
Geçici istekler neden bu kadar karışıklığa yol açıyor?Geçici istekler hızlı hissedilir, ama netlik gerektiğinde işler parçalanır. Bir katalog her talebin tek bir yerde, bir sahibinin, bir statüsünün ve geçmişinin olmasını sağlar; böylece işler DM'lerde kaybolmaz ve insanlar güncelleme kovalamak zorunda kalmaz.
Kaç tane talep kategorisiyle başlamalıyız?İnsanların saniyeler içinde seçebileceği küçük bir küme ile başlayın. Bir kişi düzenli olarak tereddüt ediyorsa veya yanlış seçeneği seçiyorsa, kategorileriniz çok benzer veya fazla teknik demektir—birleştirin veya yeniden adlandırın.
Kategorileri nasıl isimlendirmeliyiz ki insanlar gerçekten kullansın?İnsanların sohbet ve e-postada zaten kullandığı kelimeleri kullanın; iç takım terimlerini değil. İyi bir kategori adı, uzman olmayan birinin kafasında çevirmeye gerek kalmadan seçebileceği bir isimdir.
Her alım formunda hangi alanlar olmalı?Her talepte ortak olacak kısa bir alan seti yapın ki triage tutarlı olsun. Ardından, sıradan geri dönüşleri engelleyecek birkaç kategori-özgü soru ekleyin ve insanların yalnızca ilgili alanları görmesi için koşullu mantık kullanın.
Bir istek temel bilgiler eksik olduğunda ne yapmalıyız?Talebi "daha fazla bilgi gerekli" diye belirsizce geri çevirmeyin. Onu net bir bekleme statüsüne taşıyın ve ilerlemek için tam olarak ne gerektiğini söyleyen tek, odaklanmış bir soru sorun, böylece talep sahibi nasıl engeli kaldıracağını bilir.
Herkes her şeyi acil olarak işaretlemeden acil istekleri nasıl ele alırız?“Acil”i bir cümleyle tanımlayın ve bir çözüm yolu olmadığında işin engellendiğine bağlayın. Kimlerin acil olarak işaretleyebileceğini sınırlandırın, bir sebep isteyin ve hizmet saatleri içinde yanıt beklentisini belirtin; böylece aciliyet bir boşluk haline gelmez.
Darboğaz yaratmadan onay kurallarını nasıl belirleriz?Onaylar, riske göre öngörülebilir ve minimum olmalı. Kategori başına tutarlı bir onay haritası kullanın ve düşük riskli, düşük maliyetli işleri otomatik onaylayarak gereksiz beklemeleri kaldırın.
Talep sahipleri hangi statüleri görmeli ve bunlar nasıl güvenilir olur?İşi gerçekten nasıl ilerlediğini yansıtan küçük bir statü seti kullanın ve her birine girip çıkmak için neyin gerekli olduğunu tanımlayın. Talep sahipleri her zaman güncel statüyü, sorumlu kişiyi, bir sonraki eylemi ve son güncelleme zamanını görmelidir.
İç talep kataloğu için en iyi başarı metrikleri hangileri?Haftalık inceleyebileceğiniz metriklere odaklanın: ilk yanıta geçen süre, sahibin atanma süresi ve taleplerin yeniden açılma sıklığı gibi. Bunu basit bir memnuniyet puanıyla eşleştirin, böylece sayılar gözden kaçırdığı sorunları yakalarsınız.
Bu iç talep kataloğunu AppMaster ile kurabilir miyiz?Evet—AppMaster, formlar, yönlendirme, onaylar ve bir talep portalını tek bir iç uygulamada toplamak istediğinizde iyi bir seçimdir. AppMaster iş akışını görsel araçlarla modellemenize ve pilottan sonra ihtiyaçlar değiştikçe uygulamayı tekrar üretmenize olanak tanır.
10 Mar 2026
9 dk
08 Mar 202610 dk
07 Mar 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
