Bir portföy şu soruya cevap vermelidir: bu kişi gerçekte ne yapabiliyor?
Ekip projelerinde ise ikinci bir sorun ortaya çıkar:
bu kişi tam olarak ne yaptı ve ne, tüm ekibin çalışmasının sonucuydu?
Şu cümle:
"100.000 kullanıcının kullandığı bir platform geliştirdim"
çok farklı şeyler anlamına gelebilir. Bir kişi tüm mimariyi tasarlamış olabilir. Yalnızca tek bir modülden sorumlu olmuş olabilir. Projeye yalnızca son iki ayda katılmış olabilir. Ya da onlarca kişilik bir ekipte çalışmış ve ortak sonuç daha sonra tek bir kişinin başarısı gibi sunulmuş olabilir.
İyi bir portföy okuyucuyu tahmin yürütmeye zorlamamalıdır.
Katkının doğru biçimde belirtilmesi neden bu kadar önemlidir?
Değerli ürünlerin, kampanyaların, uygulamaların ve süreçlerin çoğu ekipler tarafından ortaya çıkarılır.
Bu nedenle yalnızca nihai sonucu göstermek, belirli bir uzmanın gerçekte hangi rolü oynadığını açıklamaz.
Portföyü değerlendiren biri için fark büyüktür:
"Satın alma tamamlama sürecinin yeniden tasarımında çalıştım"
ile
"Araştırmayı yürüttüm, yeni satın alma tamamlama akışını tasarladım, prototipi hazırladım ve kullanılabilirlik testlerini gerçekleştirdim. Uygulamayı ayrı bir istemci tarafı geliştirme ekibi yaptı."
aynı şey değildir.
İkinci açıklama, diğer kişilerin emeğini küçültmeden gerçek yetkinliklerin değerlendirilmesini sağlar.
Katkıyı şeffaf biçimde anlatmak için zaten iyi örnekler var
Bu sorun yalnızca profesyonel portföylere özgü değildir.
Bilimsel yayıncılıkta kullanılan örneklerden biri CRediT - Contributor Role Taxonomy standardıdır. Standart 14 katkı türü tanımlar ve bir çalışmanın farklı bölümlerinden gerçekte kimin sorumlu olduğunu daha şeffaf hale getirmek için geliştirilmiştir. CRediT bir kişiye birden fazla rol, bir role de birden fazla kişi atanmasına izin verir. Ayrıca katkıda bulunan kişilerin kendilerine atanan rolleri inceleyip onaylayabilmesi önerilir. [1]
CRediT öncelikle araştırma ve bilimsel yayınlar içindir. Profesyonel portföyler için bir standart değildir. Ancak daha geniş biçimde uygulanabilecek önemli bir ilkeyi gösterir: belirsiz bir "projenin parçasıydım" ifadesi yerine, gerçek katkının türünü açıkça belirtmek daha iyidir.
En yaygın hata: proje başarısını kişisel başarı olarak sunmak
Katkıyı dürüstçe anlatmanın altı unsuru
İyi bir ekip projesi açıklaması altı bilgi etrafında kurulabilir:
1. Proje bağlamı
2. Ekibin yapısı ve kapsamı
3. Kendi sorumluluğunuz
4. Somut eylemler ve kararlar
5. Çalışma çıktıları veya kanıtlar
6. Sonuç ve sonucun nasıl ilişkilendirildiği
Amaç uzun bir rapor yazmak değildir. Amaç en önemli belirsizlikleri ortadan kaldırmaktır.
1. Projenin bağlamıyla başlayın
Önce ekibin gerçekte ne üzerinde çalıştığını açıklayın.
Kısaca şunları belirtmek yeterlidir:
- sorun veya hedef,
- ürün ya da hizmet türü,
- yaklaşık ölçek,
- önemli kısıtlar,
- ilgiliyse uygulama dönemi.
Örnek:
Projenin amacı bir B2B uygulamasındaki satın alma sürecini kısaltmaktı. Ürün birkaç Avrupa pazarında faaliyet gösteriyor ve kurumsal müşterilere hizmet veriyordu.
Böylece okuyucu bireysel katkıyı değerlendirmeden önce bağlamı anlar.
2. Ekibin nasıl yapılandığını açıklayın
Her kişiyi adıyla belirtmeniz gerekmez.
Birçok durumda şu yapı yeterlidir:
Ekip: ürün yöneticisi, kullanıcı deneyimi tasarımcısı, 2 istemci tarafı geliştirici, 2 sunucu tarafı geliştirici ve bir kalite uzmanı.
Bu tek bilgi, tüm proje açıklamasının nasıl yorumlandığını değiştirir.
Okuyucu sonucun tek başına ortaya çıkmadığını ve uzmanın belirli bir sorumluluk dağılımı içinde çalıştığını görür.
3. Kendi sorumluluğunuzu tüm ekibin kapsamından ayırın
Bu en önemli bölümdür.
Şu genel ifade yerine:
"istemci tarafında çalıştım"
şöyle somut yazın:
"ödeme modülünün mimarisinden, satın alma tamamlama sürecinin uygulanmasından, ödeme API'si entegrasyonundan ve bu alandaki değişikliklerin kod incelemesinden sorumluydum."
Belirsizlik yaratabilecekse neyi yapmadığınızı da belirtmek faydalıdır:
"sunucu tarafı katmanı ve ödeme sağlayıcısının sunucu tarafı entegrasyonu ayrı bir ekip tarafından gerçekleştirildi."
Bu ifade portföyü zayıflatmaz. Aksine daha güvenilir hale getirir.
4. Yalnızca rol adını değil, eylemleri ve kararları anlatın
Bir iş unvanı katkının açıklaması değildir.
Bir kıdemli kullanıcı deneyimi tasarımcısı bir projede tüm araştırma sürecini yönetebilir, başka bir projede ise yalnızca son ekranları hazırlayabilir.
Bu nedenle belirli yetkinliklerle ilişkilendirilebilecek eylemleri gösterin:
- çözüm mimarisini hazırladım,
- araştırma yaptım,
- süreç akışını tasarladım,
- verileri analiz ettim,
- uygulamanın kritik bir bölümünü yazdım,
- kampanya stratejisini hazırladım,
- müzakereleri yürüttüm,
- ekipler arasındaki bağımlılıkları koordine ettim,
- çözümü devreye almadan önce doğruladım.
En değerli örnekler, belirli bir kararın neden alındığını da açıklayabildiğiniz örneklerdir.
5. Hukuken gösterebiliyorsanız bir çalışma çıktısı gösterin
Proje gösterilebiliyorsa, bir çalışma çıktısı beyan edilen katkıyı gerçek işle ilişkilendirmeye yardımcı olur.
Örneğin:
- ürün ekranı,
- arayüzün bir bölümü,
- prototip,
- kod parçası,
- herkese açık depo,
- rapor,
- diyagram,
- yayın,
- kampanya materyali,
- fotoğraf,
- belge veya güvenli biçimde gösterilebilen bir bölümü.
Bir çalışma çıktısının her şeyi kanıtlaması gerekmez. Okuyucunun gerçekte ne üretildiğini ve bunun açıklanan katkıyla nasıl ilişkili olduğunu anlamasına yardımcı olmalıdır.
6. Projenin sonucunu kendi çalışmanızın sonucundan ayırın
Kişisel katkıyı abartma riski en çok sonuçlar anlatılırken ortaya çıkar.
Bir şirketin dönüşüm oranı bir projeden sonra %25 arttıysa, bu tek bir kişinin dönüşümü %25 artırdığı anlamına gelmez.
Aynı dönemde şunlar da değişmiş olabilir:
- fiyatlar,
- teklif,
- pazarlama,
- kullanıcı deneyimi,
- altyapı,
- mevsimsellik,
- trafik kaynakları,
- diğer ekip üyelerinin çalışmaları.
Sonucu yalnızca gerçekten gerekçelendirebildiğiniz kesinlik düzeyinde anlatın.
Sonuçla ilişkinizi anlatmanın daha güvenli dört yolu
1. Doğrudan sorumluluk
"Sorumlu olduğum adımları otomatikleştirerek bu sürenin 12 dakikadan 4 dakikaya düşmesini sağladım."
Kendi eyleminizle sonuç arasındaki ilişki doğrudan ve gerekçelendirilebilir olduğunda kullanın.
2. Ortak sonuç
"Ekip olarak kullanıcı uyum sürecini yeniden tasarladık. Devreye alındıktan sonra tamamlama oranı %18 arttı."
Sonuç birden fazla kişinin çalışmasıyla ortaya çıktığında kullanın.
3. Daha geniş bir değişime katkı
"Daha kapsamlı bir satın alma süreci optimizasyonunun parçası olarak satın alma tamamlama sürecinin yeniden tasarımından sorumluydum. Programın tamamı devreye alındıktan sonra şirket dönüşüm artışı kaydetti."
Alanınız birkaç faktörden yalnızca biri olduğunda kullanın.
4. Proje bağlamı olarak sonuç
"Proje satışlarda %40 artışla sonuçlandı. Benim kapsamım istemci tarafı mimarisini ve satın alma tamamlama sürecinin uygulanmasını içeriyordu."
Projenin genel sonucunu bildiğiniz ancak bunun ne kadarının kendi çalışmanızdan kaynaklandığını belirlemek için sağlam bir dayanağınız olmadığı durumlarda kullanın.
Örnek: istemci tarafı geliştirici
Örnek: kullanıcı deneyimi tasarımcısı
Örnek: pazarlama
Örnek: proje yöneticisi
Bir ekip projesi açıklaması nasıl görünmelidir?
Bir projede birden fazla kişi yer alıyorsa, iyi bir açıklama aynı anda iki soruya cevap vermelidir:
Ekip ne teslim etti?
ve
Her kişi neden sorumluydu?
Örnek:
Proje: lojistik uygulamasının ilk sürümü
Ekip: kullanıcı deneyimi tasarımcısı, istemci tarafı geliştirici, sunucu tarafı geliştirici
Ortak sonuç: pilot uygulamaya hazır çalışan ilk ürün sürümü
Kullanıcı deneyimi tasarımcısı: araştırma, kullanıcı yolculuğu, prototip, arayüz tasarımı
İstemci tarafı geliştirici: istemci mimarisi, web uygulamasının gerçekleştirilmesi
Sunucu tarafı geliştirici: API, veri modeli, entegrasyonlar
Böyle bir proje açıklaması hem ekibi hem de bireysel uzmanları güçlendirir.
Katılım düzeyini anlatmak için basit ifadeler kullanmaktan çekinmeyin
Bazı projelerde katılım düzeyini anlatan basit ifadeler faydalıdır:
Lider rol - alanı yönettim ve temel kararlardan sorumluydum.
Ortak sorumluluk - sorumluluğu bir veya daha fazla kişiyle paylaştım.
Destek rolü - alana destek verdim ancak ana sorumlu değildim.
CRediT katkıda bulunan rollerinde benzer bir ayrım kullanır. [1]
Temel ilke basittir: sorumluluk düzeyi anlaşılır olmalıdır.
Mümkünse katkı açıklamanızı ekiple uyumlu hale getirin
Önemli ortak projelerde, kendi katkınıza ilişkin açıklamanızın diğer katılımcıların rolleri nasıl anladığıyla açıkça çelişmediğinden emin olmak yararlıdır.
CRediT, katkıda bulunanların kendilerine atanan rolleri inceleyip doğrulayabilmesini önerir. [1]
Profesyonel bir portföyde bu, her cümlenin resmi olarak onaylanması gerektiği anlamına gelmez. Pratik kural daha basittir: gerçekte başka biri tarafından yönetilen bir çalışmanın sorumluluğunu üstlenmeyin.
Projeye katkı, yazarlık ve yayımlama hakkı farklı konulardır
Kendi katkınızı anlatmak, telif haklarını belirlemekle karıştırılmamalıdır.
Polonya telif hakkı hukukuna göre telif hakkı kural olarak eserin sahibine, ortak eserlerde ise ortak yazarlara birlikte aittir. İş ilişkisi kapsamında oluşturulan eserlerde işveren, kanunun ve çalışma ilişkisinin belirlediği kapsamda mali hakları edinebilir. [2]
Pratikte şu üç soruyu ayrı ele alın:
Projenin oluşturulmasına katıldım mı?
Belirli bir unsurun yazarı veya ortak yazarı mıyım?
Materyali portföyümde yayımlama hakkım var mı?
İlk soruya "evet" cevabı vermek diğer iki sorunun cevabını otomatik olarak belirlemez.
NDA ve ticari sırlar portföyden önce gelir
Her proje gösterilemez veya ayrıntılı biçimde anlatılamaz.
Polonya haksız rekabet mevzuatı, gizli tutulan ve ekonomik değere sahip belirli teknik, teknolojik, organizasyonel ve diğer bilgileri de kapsayan ticari sırları korur. [3]
Bu nedenle gizli bir projede yalnızca müşteri adını kaldırmak yeterli olmayabilir. Kalan ayrıntılar yine de korunan bilgileri açığa çıkarabilir.
Daha güvenli kural şudur:
yalnızca uygulanabilir hukuk, sözleşmeler, alınmış izinler ve sahip olduğunuz diğer haklar kapsamında gerçekten açıklayabileceğiniz bilgileri paylaşın.
İş arkadaşlarınızın verilerini yalnızca projede yer aldıkları için yayımlamayın
Bir proje açıklaması genellikle tüm ekibin özel verilerine ihtiyaç duymaz.
GDPR, diğer ilkelerin yanı sıra hukuka uygunluk, amaçla sınırlılık ve veri minimizasyonu gerektirir; yani kişisel veriler ilgili amaç için gerekli olanla sınırlı tutulmalıdır. [4]
Ekibi şöyle tanımlamak yeterliyse:
1 kullanıcı deneyimi tasarımcısı, 2 istemci tarafı geliştirici, bir sunucu tarafı geliştirici ve bir kalite uzmanı
iş arkadaşlarının adlarını, fotoğraflarını, e-posta adreslerini veya diğer kişisel verilerini yayımlamak için otomatik bir gereklilik yoktur.
Belirli bir kişinin referansını, beyanını, görüntüsünü veya başka verilerini yayımlamak istiyorsanız uygun hukuki dayanağı ve materyalin hangi kapsamda kullanılabileceğini kontrol edin.
Proje açıklanamıyorsa ne gösterebilirsiniz?
İş birliği koşulları deneyimin genel biçimde anlatılmasına izin veriyorsa şunları göstermeyi düşünebilirsiniz:
- müşteriyi tanımlamadan sorun türü,
- kendi rolünüz,
- kullanılan yetkinlik kategorileri,
- sorumluluk türü,
- karar alma sürecinin yeterince genel bir anlatımı,
- yalnızca açıklanmasına izin verilen ölçüde sonuç.
Gizli materyalin yerine hayali ekran görüntüleri, veriler veya sonuçlar üretmeyin.
Belirli bir bilginin açıklanıp açıklanamayacağından emin değilseniz, konu netleşene kadar yayımlamamak daha güvenlidir.
Kesinliği korumaya yardımcı olan ifadeler
Kelimelerdeki küçük farklılıklar sorumluluk düzeyini çok net gösterebilir.
Şundan sorumluydum... - kendi alanınızı açıkça belirtir.
Şunu yönettim... - belirli bir alanın yönü veya uygulanmasından sorumluluğu gösterir.
Birlikte oluşturdum... - sonucun birden fazla yazarı olduğunu gösterir.
Destek verdim... - yardımcı katkıyı dürüstçe anlatır.
Şunu yapan ekibin bir parçasıydım... - bireysel katılımı ekibin toplam sonucundan ayırır.
Proje devreye alındıktan sonra şirket şunu kaydetti... - tüm etkiyi otomatik olarak kendinize mal etmeden sonucu bağlam olarak sunar.
Gerçek kapsam ortaksa otomatik olarak "ben yaptım" demekten kaçının.
Bir açıklamanın katkınızı abarttığını gösteren altı işaret
1. Birçok kişinin gerçekleştirdiği proje için tekil ifade kullanıyorsunuz.
2. Bir iş sonucu gösteriyor ancak kendi çalışma kapsamınızı açıklamıyorsunuz.
3. Ürünün tüm teknolojilerini, hepsiyle çalışmamış olsanız bile kendi yetkinlikleriniz gibi listeliyorsunuz.
4. Hangi bölümleri gerçekten oluşturduğunuzu belirtmeden nihai görsel tasarımı, kodu veya stratejiyi gösteriyorsunuz.
5. Katkıları projeyi anlamak için gerekli olduğu halde temel ekip üyelerini atlıyorsunuz.
6. Kendi çalışmanızla sonuç arasında gerekçelendiremediğiniz nedensel bir ilişki ima ediyorsunuz.
Ekip projesini anlatmak için basit şablon
Proje
Ne oluşturuluyordu ve hangi sorun çözülmek isteniyordu?
Ekip
Projede hangi roller yer aldı?
Benim sorumluluğum
Hangi alandan kişisel olarak sorumluydum?
Eylemlerim ve kararlarım
Somut olarak ne yaptım veya neyi yönettim?
İş birliği
Hangi unsurlar diğer kişilerle birlikte oluşturuldu?
Çalışma çıktıları
Hukuken neyi gösterebilirim?
Sonuç
Proje ne elde etti ve benim katkım bu sonuçla nasıl ilişkiliydi?
Sınırlamalar
Gizlilik veya başkalarının hakları nedeniyle açıklayamayacağım unsurlar var mı?
Yayımlamadan önce proje açıklamasını bir kez daha okuyun
Kendinize yedi soru sorun:
1. Okuyucu ekibin ne kadar büyük olduğunu biliyor mu?
2. Tam olarak neden sorumlu olduğum açık mı?
3. Başkalarının yaptığı işi kendime mal etmekten kaçındım mı?
4. Sonuç uygun bir temkin düzeyiyle anlatılmış mı?
5. Kullanılan materyalleri hukuken yayımlayabilir miyim?
6. Gereksiz kişisel veya gizli bilgileri açıklamaktan kaçınıyor muyum?
7. Dışarıdan biri bu açıklamadan gerçekten hangi yetkinlikleri kullandığımı anlayabilir mi?
Cevaplar açıksa proje açıklaması yalnızca etkileyici bir hikaye değil, yetkinlik kanıtı olarak çalışmaya başlar.
İyi bir portföy uzmanı güçlendirmek için ekibin rolünü küçültmez
En iyi proje açıklaması şu ikisi arasında seçim yapmak zorunda değildir:
"bunu ben yaptım"
ve
"bunu ekip yaptı."
Aynı anda iki gerçeği de gösterebilir:
ekip belirli bir sonucu teslim etti, ben ise belirli bir bölümden, kararlardan ve uygulamadan sorumluydum.
Bu düzeyde kesinlik, diğer insanların emeğini ellerinden almadan uzmanı değerlendirmeyi mümkün kılar.
Güvenilirlik kesinlikle başlar
Portföy mümkün olan en büyük iddiayı kurma yarışına dönüşmemelidir.
Değeri, karşıdaki kişi şunları anlayabildiğinde artar:
ne oluşturuldu, kimler üzerinde çalıştı, siz neden sorumluydunuz, kişisel olarak ne yaptınız ve hangi sonuç makul biçimde katkınızla ilişkilendirilebilir.
Kesin bir açıklama başarıyı küçültmez.
Tam tersine, kendi sorumluluğunuzu anladığınızı, başkalarıyla çalışabildiğinizi ve işinizin sonuçlarını dürüstçe sunabildiğinizi gösterir.
Kaynaklar ve ek okumalar
[1] CRediT - Contributor Role Taxonomy, NISO
Kaynağa git
[2] Polonya Telif Hakkı ve İlgili Haklar Kanunu - madde 8-12, ELI
Kaynağa git
[3] Polonya Haksız Rekabetle Mücadele Kanunu - madde 11, 2026'da yayımlanan birleştirilmiş metin
Kaynağa git
[4] (AB) 2016/679 sayılı Tüzük - GDPR, madde 5, EUR-Lex
Kaynağa git
Metodolojik not: CRediT, araştırma ve bilimsel yayınlarda katkıda bulunan rollerine ilişkin bir standarttır. Bu makale CRediT'i şeffaf katkı atfına örnek olarak kullanır, ancak profesyonel portföy standardı olarak sunmaz. Proje açıklamasının altı unsuru ve sonuçlarla ilişkiyi anlatmanın dört yolu, bu materyalde önerilen editoryal bir modeldir.
Tahmin yürütmeden doğrulanmış bir uzman bulun.
Beceriler, hizmetler, fiyatlar ve uygunluk daha profili açmadan görülebilir.
