Bireysel gelişim planı, bir kişinin önümüzdeki birkaç ayda nasıl gelişeceğine dair kısa, yazılı bir anlaşmadır: hangi beceriler üzerinde çalışacağı, gerçekte ne yapacağı ve ne zamana kadar. Kulağa evrak işi gibi gelir ve birçok şirkette gerçekten de öyledir — yılda bir kez doldurulan ve bir daha açılmayan bir form. Böyle olmak zorunda değil.
Bu rehber, gerçekten uygulanan bir gelişim planının nasıl yazılacağını gösteriyor: hedeflerin nereden geldiği, bir adımı neyin somut yaptığı, kopyalayabileceğiniz bir şablon ve destek, satış, mühendislik ve yöneticilik rolleri için örnekler.
Bireysel gelişim planı nedir, ne değildir
İşe yarar bir gelişim planında üç şey vardır:
- Bir yön. Genellikle kişinin kariyer merdivenindeki bir sonraki seviye, bazen farklı bir kariyer yoluna ya da role geçiş.
- Bir iki odak beceri. Kişi ile o yön arasında duran açıklar.
- Bitiş tarihleri olan birkaç somut adım — gerçekten bir şeyi değiştiren kısım.
Bir performans iyileştirme planı değildir. Performans iyileştirme planı, birinin mevcut rolünün gerisinde kalmasına verilen resmî bir yanıttır. Bireysel gelişim planı ise işini iyi yapan ve daha fazlasını yapmak isteyenler içindir. İkisi karıştırılırsa insanlar gelişim planından korkmaya başlar.
Bir eğitim bütçesi talebi de değildir. Kurslar bir planın parçası olabilir, ama gelişimin çoğu işin kendisinden gelir: daha zor bir problemi üstlenmek, bir şeye ilk kez liderlik etmek, başkalarına öğretmek.
Bir istek listesinden değil, açıktan başlayın
Bir gelişim planı için en iyi kaynak bir check-in’dir: çalışan kendini rolünün beklediği becerilere göre değerlendirmiş, yönetici de aynısını yapmış ve ikisi de değerlendirmelerin nerede ayrıştığını ya da seviyenin gerisinde kaldığını görmüştür. Bu açıklar ham maddedir.
Bunlardan bir ya da ikisini seçin. Seçerken şunları sorun:
- Bir sonraki seviye için en önemli açık hangisi? Bir sonraki seviyenin beklentilerini okuyun ve en büyük sıçramayı bulun.
- Kişi hangisini önemsiyor? Kişinin ilgilenmediği bir plan uygulanmaz.
- Yardımcı olacak bir iş geliyor mu? Gelecek çeyreğin işiyle kapatılabilecek bir açık, üzerine gitmesi en kolay olanıdır.
Kariyer merdiveni olmadan da bir gelişim planı yazabilirsiniz, ama hedefler rolün ihtiyacından çok kulağa hoş gelen şeylere — “daha stratejik olmak” — kayma eğilimindedir. Net seviye başına beklentiler planı yazmayı çok kolaylaştırır.
Gerçekten yapılan bir adım nasıl yazılır
Gelişim planlarının çoğu bu adımda çöker. “İletişim becerilerini geliştirmek” bir adım değil, bir dilektir. İyi bir adım beş soruyu yanıtlar:
- Tam olarak ne yapacaksınız? Bir fiil ve bir çıktı.
- Hangi beceriyi geliştiriyor? Rolden tek bir beceri ya da birine uymuyorsa daha geniş bir hedef.
- Bittiğini nasıl anlayacağız? İki tarafın da görebileceği bir bitiş çizgisi.
- Ne zamana kadar? Birkaç hafta ile üç ay sonrası arasında gerçek bir tarih.
- Hangi destek gerekiyor? Zaman, erişim, bir mentor, bir bütçe, bir tanıştırma.
Karşılaştırın:
| Belirsiz | Somut |
|---|---|
| Topluluk önünde konuşmada daha iyi olmak | Üç aylık destek raporunu aralıktaki şirket toplantısında sunmak; önce ekip lideriyle bir kez prova yapmak |
| Ürün hakkında daha çok şey öğrenmek | Ay sonuna kadar çözüm ekibinin iki onboarding görüşmesine gözlemci olarak katılmak ve müşterilerin sorduğu üç soruyu yazıya dökmek |
| Daha fazla sorumluluk almak | Önümüzdeki iki sürümün yayın kontrol listesini, yayına çıkıp çıkmama kararı dahil, üstlenmek |
Adım türlerini karıştırın. İşe yarar bir denge, çoğunlukla yaparak (gerçek iş üzerinde zorlayıcı bir görev), biraz başkalarından öğrenerek (gölgeleme, mentorluk, geri bildirim) ve az miktarda resmî eğitimle (bir kurs ya da bir kitap) gelişmektir — tersi değil. Yalnızca kurslardan oluşan bir plan yeni davranış değil, sertifika üretir.
Bir bireysel gelişim planı şablonu
Bunu kullandığınız araca kopyalayın. Tek bir ekrana sığar; amaç da budur.
Kişi / rol / seviye: ad — rol — mevcut seviye
Yön: örneğin “12 ay içinde 3. seviyeye hazır olmak” ya da “yöneticilik yoluna geçmek”
Odak beceriler: rolün beklentilerinden bir ya da iki tane
| Adım | Beceri | Bittiğinde | Tarih | Gereken destek |
|---|---|---|---|---|
| Ne yapacağınız | Beceri adı | Görünür bir bitiş çizgisi | Tarih | Zaman, mentor vb. |
Gözden geçirme: bir sonraki check-in, tarih
Aynı anda iki ile dört adımı açık tutun. Biri bittiğinde, baştan on tane yazmak yerine bir sonrakini ekleyin.
Dört rol için örnekler
Müşteri destek uzmanı, 2. seviye 3. seviye
Yön: karmaşık bir alanda başkalarının dayandığı kişi olmak. Odak beceriler: ürün ve teknik bilgi, destek operasyonları. Seviye beklentileri için müşteri desteği şablonuna bakın.
| Adım | Beceri | Bittiğinde | Tarih |
|---|---|---|---|
| En sık karşılaşılan beş fatura sorunu için iç notlar yazmak | Ürün ve teknik bilgi | Notlar yayımlandı; iki meslektaş bunları kullandı | 6 hafta |
| Fatura yapılandırması üzerine 30 dakikalık bir ekip oturumu yapmak | Ürün ve teknik bilgi | Oturum yapıldı, sorular toplandı | 10 hafta |
| Geçen ayın taleplerine dayanarak üst kademeye aktarma sürecinde bir değişiklik önermek | Destek operasyonları | Öneri destek ekip lideriyle konuşuldu | 12 hafta |
Account executive, orta seviye kıdemli
Yön: çok paydaşlı, daha büyük anlaşmaları tek başına yürütmek. Odak beceriler: ihtiyaç analizi ve nitelendirme, anlaşma yönetimi ve kapanış. Account executive şablonuna bakın.
| Adım | Beceri | Bittiğinde | Tarih |
|---|---|---|---|
| Üç ya da daha fazla paydaşın olduğu iki anlaşmada, yönetici gözlemlerken ihtiyaç analizi görüşmesini yürütmek | İhtiyaç analizi ve nitelendirme | İki görüşme yürütüldü, her birinin ardından geri bildirim yazıldı | 8 hafta |
| Belirli bir büyüklüğün üzerindeki her aktif anlaşma için ortak bir eylem planı yazmak | Anlaşma yönetimi ve kapanış | Planlar müşteriyle paylaşıldı ve güncel tutuluyor | Sürekli, 12 haftada gözden geçirme |
| Bu görüşmelere katılan iki meslektaştan yazılı geri bildirim istemek | İhtiyaç analizi ve nitelendirme | Geri bildirim alındı ve check-in’de konuşuldu | 10 hafta |
Yazılım mühendisi, 2. seviye 3. seviye
Yön: bir yıl içinde senior mühendis olmak. Odak beceriler: sistem tasarımı, mentorluk ve ekip gelişimi. Yazılım mühendisi şablonuna bakın.
| Adım | Beceri | Bittiğinde | Tarih |
|---|---|---|---|
| Rapor dışa aktarımı için tasarım belgesini yazmak ve incelemesini yürütmek | Sistem tasarımı | Belge iki senior mühendis tarafından incelendi ve onaylandı | 6 hafta |
| Ekibe en son katılan mühendisle haftada bir eşli çalışmak | Mentorluk ve ekip gelişimi | Sekiz oturum yapıldı; yeni mühendis ilk özelliğini tek başına yayına aldı | 10 hafta |
| Kendi alanınız dışındaki pull request’leri haftada en az iki kez incelemek | Sistem tasarımı | Alışkanlık tam bir çeyrek boyunca sürdürüldü | 12 hafta |
Yeni engineering manager, ilk altı ay
Yön: bireysel işe geri dönmeden ekibi yönetmek. Odak beceriler: insanların gelişimi, teslim ve yürütme. Engineering manager şablonuna bakın.
| Adım | Beceri | Bittiğinde | Tarih |
|---|---|---|---|
| Doğrudan bağlı her çalışanla bir kariyer check-in’i yapmak | İnsanların gelişimi | Tüm check-in’ler tamamlandı, her birinde üzerinde anlaşılan adımlar var | 8 hafta |
| Nöbet rotasyonunu ve yayın kontrol listesini iki ekip üyesine devretmek | Teslim ve yürütme | İkisi de bunları tam bir ay boyunca siz olmadan yürüttü | 12 hafta |
| İki haftada bir daha deneyimli bir yöneticiyle görüşmek | İnsanların gelişimi | Altı görüşme yapıldı; birebir görüşmeleri yürütme biçiminizde bir değişiklik yapıldı | 12 hafta |
Örneklerin ortak noktasına dikkat edin: neredeyse her adım, kişinin zaten kısmen yapacağı gerçek bir iştir; yalnızca bilinçli hâle getirilmiş ve bir bitiş çizgisi verilmiştir.
Planı canlı tutmak
Yazılıp dosyalanan bir plan bir ay içinde unutulur. Üç alışkanlık onu canlı tutar:
- Her check-in’de gözden geçirin. Her check-in’e açık adımlarla başlayın: ne yapıldı, ne takıldı, ne artık anlamlı değil. Anlamını yitirmiş adımları iptal edin — bu bir başarısızlık değil, dürüstlüktür.
- İlerlemeyi anında yazın. Bir şey ilerlediğinde düşülen kısa bir not — “ilk oturum yapıldı, 6 kişi katıldı” — üç ay sonra hatırlamaya çalışmaktan iyidir ve bir terfi gerekçesi için kanıta dönüşür.
- Adımı çalışan kapatsın. İşi yapan kişi, nasıl geçtiğine dair bir notla birlikte işin ne zaman bittiğini söyler. Yönetici katılmayıp adımı yeniden açabilir, ama başkası adına kutucuk işaretlememelidir.
Bitiş tarihleri ancak biri onları fark ederse işe yarar. Planınız bir belgede duruyorsa tarihleri bir takvime ekleyin. LadderKit’te gelişim planındaki her madde, bitiş tarihi, kişinin rolünden bir beceriye isteğe bağlı bağlantısı, iki tarafın da yazdığı bir not akışı ve bitiş tarihinden önce ve sonra gönderilen hatırlatmaları olan bir gelişim görevidir; onu tamamlandı olarak yalnızca çalışan işaretleyebilir.
Sık yapılan hatalar
- Çok fazla hedef. İki odak beceri, iki ile dört adım. Geri kalan her şey bekler.
- Bitiş çizgisi olmayan adımlar. Bitip bitmediğini anlayamıyorsanız hiçbir zaman bitmez.
- Yalnızca kurslar. Öğrenme işin içinde olur; kurslar onu destekler.
- Yalnızca yöneticinin yazdığı plan. Kişinin onu kendi planı olarak benimsemesi gerekir.
- Rolden kopuk. Bir sonraki seviyenin beklentilerini hedeflemeyen hedefler terfiye yardımcı olmaz ve insanlar bunu fark eder.
- Bir daha hiç bakılmaması. Bir sonraki check-in’de konuşulmayan bir gelişim planı bir formaliteydi.