Bir Proje Talep ve Personel İsteme Uygulamasının ihtiyaçları nasıl topladığını, onayları nasıl yönlendirdiğini, yetkinlikleri nasıl eşleştirdiğini ve personel kararlarını nasıl kaydettiğini öğrenin.
Bir Proje Talep ve Personel İsteme Uygulaması, çoğu ekibin çok iyi bildiği bir sorunu çözer. Yeni işler e-postada başlar, bilgiler elektronik tablolara kopyalanır, kararlar sohbette alınır ve kimse hangi sürümün doğru olduğundan tam emin olmaz.
Bu, birkaç talep için işe yarayabilir. Hacim arttığında işlevini yitirir. Bir yönetici gelecek ay bir geliştirici ister ama proje hedefi, hedef tarih, bütçe, aciliyet veya gerekli yetkinlikleri belirtmez. Personel ekibi temel bilgileri takip etmek zorunda kalır; inceleme bile başlamadan önce. Yanıtlar geldiğinde, talep üç farklı yerde farklı görünmeye başlamış olabilir.
Basit bir örnek sorunu gösterir. Bir satış lideri müşteri portalı için iki kişi ister. Bir mesaj ön yüzten, diğeri API değişikliklerinden bahseder, bir elektronik tablo satırı sadece "acil" yazar. Kaynak yöneticisi incelediğinde hala bir full-stack geliştirici, iki uzman veya kısa süreli sözleşmeli destek mi gerektiğini bilemez.
Sahipliğin belirsiz olması durumu daha da kötüleştirir. Kim kapsamı inceler, kim kadroyu onaylar ve kim atamayı onaylar bilinmiyorsa talepler takılır. İnsanlar aynı soruları farklı yerlerde sorar. İyi adaylar, karar yolu belirsiz olduğunda atanmaz.
Uygulama her talebe tek bir adres ve tek bir standart yol vermelidir. Pratikte bu, talepleri göndermek için bir yer, inceleme başlamadan önce doldurulması gereken bir zorunlu bilgi seti, görülebilir bir durum ve her personel kararı veya değişikliğinin kaydının bulunduğu bir yer demektir.
Yapılandırılmış bir giriş akışıyla ekipler tahmin etmeyi bırakır. Ne gerektiğini, bir sonraki adımı kimin üstlendiğini ve birinin neden atandığını veya atanmamasını görebilirler. AppMaster gibi bir no-code platformunda bunu kurarken amaç sadece talepleri toplamak değildir. Amaç tüm iş akışını takip etmesi, izlenmesi ve geliştirilmesi kolay hale getirmektir.
İyi bir talep formu üç soruyu hemen yanıtlamalı: hangi iş yapılacak, ne zaman yapılmalı ve ne tür bir kişiye ihtiyaç var.
Talebi tanımlayan temel bilgilerle başlayın. Proje adı, sorumlu kişi ve kısa bir iş hedefi isteyin. "Destek talepleri için müşteri portalı başlatmak" gibi açık bir ifade, "yeni sistem gerekli" demekten çok daha faydalıdır.
Tarihler önemlidir, ama sadece bağlamları varsa. Planlanan başlama tarihi, hedef son tarih ve beklenen iş yükünü toplayın. Bu, yarı zamanlı veya tam zamanlı, kısa süreli veya sürekli ya da haftalar/aylar cinsinden bir tahmin şeklinde olabilir.
Personel ihtiyacını spesifik yapın. Tek bir büyük metin kutusu yerine hangi rollerin gerektiğini ve her rol için kaç kişinin gerektiğini sorun. 1 backend geliştirici, 1 QA uzmanı ve 1 tasarımcı talebi nettir. "Küçük bir ekip" talebi ise net değildir.
Yetkinlikler de yorumlarda gömülü olmamalı, yapılandırılmalı. Gerekli yetkinlikleri, tercih edilen araçları ve gereken deneyim seviyesini ayrı alanlarda yakalayın. Zorunlu yetkinlikleri ve tercih edilen yetkinlikleri ayırmak işe yarar; böylece sonraki personel kararları çok daha kolay olur.
Çoğu ekip için formun şu alanları kapsaması gerekir:
İş sınırları baştan görünür olmalı. Bütçe aralığı, öncelik seviyesi ve onay yetkilisini dahil edin. Bunlar yoksa ekipler ilerleyemeyecek talepleri vakit kaybederek inceleyebilir.
Riskler veya özel kısıtlamalar için kısa bir not alanı bırakın. Bir proje müşteri teslim tarihine, uyumluluk incelemesine veya haftada yalnızca iki gün müsait olan bir iç uzmana bağlı olabilir.
Formu kısa ama katı tutun. Mümkün olduğunca açılır menüler, zorunlu alanlar ve basit seçimler kullanın. Gerçekten açıklama gerektiren detaylar için serbest metin bırakın.
İyi bir giriş akışı, her talebi sonraki karar noktasına manuel takip olmadan taşır. Doğru kişi doğru zamanda, hızlı karar vermek için yeterli detayla incelemelidir.
Akış, birisi talep gönderdiğinde başlar. Bu noktada uygulama takım, proje türü, öncelik, bütçe aralığı ve istenen başlama tarihi gibi birkaç temel alanı kontrol etmelidir. Bu alanlar, talebi tek bir ortak kuyruğa düşürmek yerine doğru incelemeye yönlendirir.
Çoğu ekip için önce basit yönlendirme kuralları en iyisidir. Departman talepleri ilgili takım liderine gidebilir. Yüksek bütçeli talepler yöneticiye veya finans onayına yönlendirilebilir. Acil talepler açık bir inceleme süresiyle daha hızlı bir yoldan gidebilir. Eksik talepler yorumlarla talep edene geri gönderilmelidir.
İlk incelemeden sonra yetkinlik ve kapasite kontrolü ekleyin. Personel kararlarının iyileştiği yer burasıdır. Bir takım lideri veya kaynak yöneticisi iki şeyi doğrulamalıdır: gerekli yetkinlikler takımda var mı ve bu kişiler gerçekten müsait mi? Kâğıt üzerinde mükemmel görünen biri, önümüzdeki altı hafta dolu olabilir.
Bu adımı yapılandırılmış tutun. İnceleyenler onaylandı, reddedildi veya değişiklik istendi gibi net bir sonuç seçmelidir. Değişiklik gerekiyorsa talep yorumlarla geri dönmeli ve tam geçmiş korunmalıdır ki kimse bağlamı kaybetmesin.
Onaylandıktan sonra talep doğrudan atama takibine geçmelidir. Bu noktada artık sadece bir fikir değildir. Atama yapacak kişiler, durum, hedef tarihler ve belirli kişilerin neden seçildiğine dair bir kayıt olan aktif bir personel maddesine dönüşür.
Burada birçok ekip hata yapar. Onay olur ama kimin işi gerçekten yapacağı belirsizdir. Net bir devrediş bunu çözer.
AppMaster'da bu tür bir akış, kural tabanlı yönlendirme ve gönderimden atamaya kadar otomatik durum güncellemeleriyle görsel bir iş süreci olarak iyi eşleşir.
Uygulamayı kurmanın en kolay yolu önce yolu tanımlamak, sonra formu, izinleri ve uyarıları bu yol etrafında oluşturmaktır.
Durumlardan başlayın. Bunları kısa ve anlaşılır tutun: Draft, Submitted, Under Review, Approved, Staffing in Progress, Assigned ve Closed. Bir talep düzenleme için geri gitmesi gerekiyorsa, çok fazla yan yol oluşturmaktansa Changes Needed gibi tek bir ek durum ekleyin.
Sonra süreci basit bir sırayla kurun. Önce akışı kağıda çizin. Bir talep nerede başlar, kim inceler, kim onaylar ve kimin nihai atamayı yaptığına karar verin. Sonra form alanlarını oluşturun ve hangilerinin gönderimden önce zorunlu olduğunu işaretleyin. Ardından acil veya yüksek öncelikli taleplerin standart yolu takip etmemesi için yönlendirme kuralları ekleyin. Sonra role göre izinleri ayarlayın ve her devrede bildirimlerle işi tamamlayın.
İzinler net olmalı. Talep edenler talepler oluşturmalı ve kendi durumlarını görmelidir. İnceleyenler yorum yapıp öğeleri değişiklik için geri gönderebilmelidir. Onaycılar onaylayıp reddedebilmelidir. Personel liderleri insanları atayıp tahsisi onaylamalıdır. Yöneticiler kuralları, roller ve bildirimleri yönetmelidir.
Onayları hafif tutun. Çok fazla kişinin imzası gerekiyorsa talepler hareketsiz kalır. Birçok ekipte bir inceleyen ve bir onaylayan, personel ataması başlamadan önce yeterlidir.
Ana hedef basittir: her talebin her zaman bir sahibi, bir güncel durumu ve açık bir sonraki adımı olmalıdır.
İyi personel ataması temiz verilerle başlar. Yetkinlikler özgeçmişlerde, sohbetlerde ve tablolarda dağınıksa kararlar yavaş ve tutarsız olur. Her çalışan için bir profil tutun ve herkes için aynı yapıyı kullanın.
Çoğu ekip için profil; rol, ana yetkinlikler, yetkinlik seviyesi, mevcut kullanılabilirlik, konum veya saat dilimi ve yarı zamanlı saatler veya sözleşme bitiş tarihi gibi sınırları içermelidir.
Talepler de en az profiller kadar net olmalı. Gereksinimleri must-have ve tercih edilen olarak ayırın. Haftaya başlayabilecek bir React geliştiricisi gerektiğini belirten bir talep, sağlık sektörü deneyimi gibi daha yumuşak tercihlerle karıştırılmamalıdır.
Basit bir eşleştirme kaydı genellikle şu alanlara ihtiyaç duyar:
Yetkinlik puanlaması tutarlı olmalı. Beginner, working, strong, expert gibi basit bir ölçek veya 1–5 puan aralığı kullanın. Serbest metin açıklamalardan kaçının. Bir yöneticinin "ileri" dediği başka birine göre çok farklı anlam taşıyabilir.
Kullanılabilirlik yetenek kadar önemlidir. Mükemmel bir aday zaten doluysa acil bir taleple gerçek bir seçenek değildir. Konum da zaman dilimi uyumu, dil veya yerinde erişim gerektiğinde önem taşır.
Yöneticilerin hızlı karar vermesine yardımcı olmak için adayları yan yana gösterin. Görünüm birkaç temel soruyu hızla yanıtlamalı: must-have yetkinlikleri karşılıyorlar mı, ne kadar güçlüler, müsaitler mi, nerede bulunuyorlar ve neden önerildikleri kısa bir notla açıklanmalı.
Bu son kısım genellikle atlanır. Eşleştirme nedenini atama sonrasında bile kayıtta görünür tutun. "SQL ve destek iş akışı deneyimi talebe uydu ve haftada 30 saat müsait olduğu için seçildi" gibi kısa bir not, daha sonra neden o kişinin seçildiği sorulduğunda zaman kazandırır.
AppMaster'da bunu kuruyorsanız talepleri, çalışan profillerini ve yetkinlik kayıtlarını ayrı veri yapıları olarak tutmak faydalıdır. Bu, filtreleme, karşılaştırma ve atama takibini ekip büyüdükçe daha kolay yönetilebilir kılar.
Gerçek bir örnek süreci canlandırmayı kolaylaştırır.
Bir takım lideri, müşterinin giriş yapıp güncellemeleri görebildiği ve servis ekibine istek gönderebildiği yeni bir müşteri portalına ihtiyaç duyar. Formu açar ve proje adı, müşteri, hedef lansman tarihi, iş hedefi ve beklenen iş yükünü girer. Personel bölümünde üç rol ister: bir backend uzmanı, bir tasarımcı ve bir testçi.
Talep ayrıca her rolün arkasındaki yetkinlikleri yakalar. Backend rolü API ve veritabanı çalışmalarını gerektirir. Tasarımcı basit müşteri odaklı paneller konusunda deneyimli olmalı. Testçi güçlü test senaryosu yazımı ve regresyon testi bilgisine sahip olmalıdır. Bu, talebi basit bir kadro notundan çok daha kullanışlı hale getirir.
Gönderim sonrası iş akışı talebi finans ve teslimat ekiplerine yönlendirir. Finans beklenen çabanın bütçeye uyup uymadığını kontrol eder. Teslimat, zaman çizelgesinin ve kapsamın mevcut kapasiteyle uyumlu olup olmadığını kontrol eder. Her iki ekipten biri endişe bildirirse talep notlarla geri gider, uzun bir e-posta zincirine karışmaz.
Her iki onay da alındıktan sonra yöneticiler gerekli yetkinliklere uyan mevcut kişileri inceler. Sadece müsait birini aramazlar. Kullanılabilirlik, mevcut atamalar, başlama tarihleri ve her kişinin işe ne kadar uyduğunu karşılaştırırlar.
Bir backend adayı gelecek Pazartesi müsait olabilir ama sadece yarı zamanlı çalışabilir. Bir başkası daha sonra başlayabilir ama daha güçlü veritabanı deneyimine sahip olabilir. Tasarımcı ilk hafta müsait olmayabilir; yönetici geçici bir boşluk veya revize edilmiş bir plan kaydeder.
Nihai atama talep kaydında saklanır. Kim atandığı, ne zaman başlayacağı, seçim onaylayan kişi ve takaslar veya yedek seçeneklerle ilgili notlar görünür. Bu, herkesin en son kararı kontrol edebileceği tek bir yer sağlar.
Çoğu kabul süreci basit nedenlerle başarısız olur. Form çok gevşek olur, devrediş belirsizdir veya kimsenin neden bir kişiyi seçtiğini açıklayan kaydı yoktur.
En çok soruna yol açan birkaç hata vardır. Birincisi çok fazla isteğe bağlı bilgi istemek. Formun yarısı isteğe bağlıysa insanlar önemli bölümleri atlar ve "yakında bir geliştirici gerekiyor" gibi belirsiz talepler gönderir. Bir diğeri sahipliğin belirsiz bırakılmasıdır. Kimse onay veya personel incelemesini üstlenmezse talepler durur çünkü her ekip diğerinin hareket edeceğini varsayar.
Serbest metin yetkinlikleri başka bir yaygın sorundur. Bir yönetici "React" der, bir diğeri "frontend", bir başkası "JS UI çalışması" yazar. Sonrasında arama ve eşleştirme karmaşaya döner. Aynı durum atama kararları sadece sohbette yaşandığında da olur. Birisi "bunu Sam'e ver" der fakat uygulama kim karar verdi, ne zaman oldu veya nedenini kaydetmez.
Durum adları da göründüğünden daha önemlidir. "In Review" bir ekip için bütçe incelemesi anlamına gelirken diğer için nihai onay anlamına geliyorsa karışıklık kaçınılmazdır.
Küçük bir örnek bunun nasıl ters gidebileceğini gösterir. Bir satış direktörü "uygulama desteği" için net öncelik, son tarih veya gerekli yetkinlik belirtmeden talep gönderir. Personel lideri takip sorularını sohbette sorar, bir yönetici sözlü onay verir ve nihai atama bir toplantıda yapılır. Bir hafta sonra kimse talebin onaylanıp onaylanmadığı, personel atandığı veya hala beklemede olduğu konusunda hemfikir değildir.
Çözüm genelde basittir. Zorunlu alanları sıkı tutun, standart bir yetkinlik listesi kullanın, her karar noktasında bir sahip atayın ve her onay ve atamayı uygulama içinde kaydedin.
Yapı burada en çok önem taşır. Net alanlar, sabit durumlar ve kaydedilmiş kararlar süreci daha güvenilir ve yönetilebilir hale getirir.
Yayından önce süreci gerçek bir ekibin yoğun bir Pazartesi sabahı kullanacağı şekilde test edin. İnsanlar ne dolduracaklarını, kimin onaylayacağını veya talebin şu anda nerede olduğunu tahmin etmek zorunda kalıyorsa uygulama işi yavaşlatır yerine yardımcı olmalıdır.
İyi bir son kontrol basittir: bir talep göndermeden atamaya yan mesajlar, ek tablolar veya manuel takibe gerek kalmadan ilerleyebiliyor mu?
Canlıya geçmeden önce birkaç temel noktayı doğrulayın:
Durum görünürlüğü form kadar önemlidir. İşe alım uzmanları, takım liderleri, proje yöneticileri ve talep edenler e-posta arasında kazı yapmadan mevcut aşamayı görebilmelidir.
Kısa bir durum satırı genellikle en iyi sonucu verir: Submitted, Under Review, Approved, Matching in Progress, Assigned veya Closed. Bir talep engelliyse, nedeninin görünür olması gerekir.
Yayına almadan önce bir gerçek test vakası çalıştırın. Örneğin, Kotlin deneyimi olan bir mobil geliştirici için, iki hafta sonra başlama tarihi ve yönetici onayı gerektiren bir talep gönderin. Ardından uygulamanın yetkinliği doğru yakalayıp yakalamadığını, yönlendirmenin doğru kişilere gidip gitmediğini, onayların kaydedilip kaydedilmediğini ve herkesin en son durumu görüp görmediğini kontrol edin.
Küçük başlayın. Bir ekip, bir onay yolu ve yeni müşteri projeleri, dahili destek işleri veya acil yedekleme gibi kısa bir ortak talep listesi seçin.
İlk sürüm bir işi iyi yapmalıdır: talebi toplamak, doğru inceleyene göndermek ve hangi kararın verildiğini göstermek. Her kenar durumunu ilk günde ele almaya çalışırsanız uygulama test etmeyi zorlaştırır ve göz ardı edilmesi kolaylaşır.
İki ila dört haftalık bir pilot dönemi genellikle sürecin nerede çalıştığını ve insanların hâlâ e-posta veya sohbete geri döndüğü yerleri ortaya çıkarır. En önemli olan, uygulamanın kaç alanı olduğu değil, sürecin daha net ve hızlı hale gelip gelmediğidir.
Başlangıçta birkaç basit metriği takip edin: gönderimden ilk incelemeye geçen süre, taleplerin eksik bilgi yüzünden kaç kez geri gönderildiği, kaç personel kararının tekrar işlenmesi gerektiği, hangi talep türlerinin atamasının en uzun sürdüğü ve yöneticilerin iş akışını ne sıklıkta atladığı.
Bu sayılar gerçek sürtüşme noktalarını gösterir. Gecikmeler inceleme başlamadan önce oluyorsa form muhtemelen fazla belirsizdir. Atamalar sıkça değişiyorsa yetkinlik verisi muhtemelen çok yüzeysel veya tutarsızdır.
İlk birkaç döngüden sonra formu ve yönlendirme kurallarını sıklaştırın. Hiç kimsenin kullanmadığı alanları kaldırın. Eksik bilgi gerçek gecikmelere neden oluyorsa sadece o alanları zorunlu yapın. Bir talep türü farklı bir yol gerektiriyorsa, tüm vakaları aynı sürece zorlamak yerine ona özel bir yol verin.
Sonra talep edenler, inceleyenler ve takım liderlerinden gelen geri bildirimlerle ikinci sürümü oluşturun. Her grup farklı bir sorun görür. Talep edenler henüz bilmedikleri detayları sormamaları gerektiğini söyleyebilir. İnceleyenler daha net öncelik seviyelerine ihtiyaç duyabilir. Takım liderleri onaylamadan önce gereken yetkinlikleri, başlama tarihini ve mevcut kapasiteyi daha hızlı görmek isteyebilir.
Ağır kodlama olmadan süreci kurmak istiyorsanız AppMaster pratik bir uyum sağlar; formu, iş mantığını ve izleme ekranlarını tek bir yerde oluşturup süreç netleştikçe tam bir backend, web uygulaması veya mobil uygulamaya genişletebilirsiniz.
En iyi sonraki adım küçük bir lansman, kısa bir geri bildirim döngüsü ve her seferinde bir iyileştirmedir.
Proje talep ve personel isteme uygulaması tam olarak ne yapar?Her bir talebe tek bir başlangıç noktası, standart bir inceleme yolu ve son personel kararının kaydı sağlar. Bu, dağılan e-posta, sohbet ve elektronik tablolar yerine takip edilebilir bir iş akışı sunar.
Talep formu önce hangi bilgileri toplamalı?Önce proje adı, sorumlu kişi, iş hedefi, başlama tarihi, hedef bitiş tarihi, bütçe aralığı, öncelik ve onay yetkilisini isteyin. Ardından hangi roller gerektiğini, her rol için kaç kişi gerektiğini, gerekli yetkinlikleri, tercih edilen araçları ve beklenen iş yükünü ekleyin; böylece inceleyenler temel bilgileri takip etmeden karar verebilirler.
Kabul akışı hangi durumları kullanmalı?Basit tutun. Genellikle Draft, Submitted, Under Review, Approved, Staffing in Progress, Assigned ve Closed gibi kısa bir akış yeterlidir. Düzenlemeler sık ise Changes Needed gibi tek bir ek durum ekleyin.
Personel talebini kim incelemeli ve onaylamalı?Çoğu durumda bir inceleyen ve bir onaylayıcı yeterlidir; ardından atama için personel liderine devredin. Çok fazla onay adımı her şeyi yavaşlatır ve sahipliği belirsizleştirir.
Eksik talepler nasıl ele alınmalı?Eksik talepleri yorumlarla birlikte talep edene geri gönderin ve tam geçmişi aynı kayıt içinde tutun. Böylece talep kaybolmaz ve herkes ne değiştiğini ve nedenini görebilir.
Personel yetkinliklerini nasıl takip etmeliyiz?Yetkinlikleri serbest metin yerine standart bir formatta saklayın. Sabit yetkinlik adları, basit bir derecelendirme ölçeği ve kullanılabilirlik, saat dilimi ve rol için açık alanlar kullanın; böylece eşleştirme tutarlı olur.
Bir kişi talebe neden iyi bir eşleşme sayılır?İyi bir eşleşme hem uyum hem de zamanlama sağlar. Kişi must-have yetkinlikleri karşılamalı, işe başlama zamanında müsait olmalı ve konum ya da iş yükü sınırlamalarına uymalıdır. Seçim nedenini kısa bir notla kaydetmek ileriye dönük fayda sağlar.
Taleplerin ekipler arasında takılmasını nasıl durdururuz?Her talebe tek bir güncel sahip, tek bir görünür durum ve tek bir sonraki adım verin. Çoğu gecikme belirsiz devredişlerden, muğlak formlardan veya uygulama dışında yapılan onaylardan kaynaklanır.
Uygulamayı yayına almadan önce ne test etmeliyiz?Gönderimden atamaya gerçek bir test çalıştırın. Zorunlu alanların net olduğunu, yönlendirmenin doğru kişilere gittiğini, onayların kaydedildiğini ve herkesin sohbet veya e-posta sormadan en son durumu görebildiğini kontrol edin.
Neden bu iş akışını AppMaster ile kuralım?AppMaster, formu, iş akışını ve takip ekranlarını kod ağırlığı olmadan kurmak isteyenler için pratik bir seçenektir. Veritabanı yapısını, yönlendirme mantığını ve durum güncellemelerini tek bir yerde ayarlayıp süreç büyüdükçe genişletebilirsiniz.
10 Mar 2026
7 dk
08 Mar 20268 dk
07 Mar 202611 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
