Her sprint planlama toplantısında ürün sahibi, ürünün değerini, diğer ifadeyle kıymetini, artırmak için bir sonraki adımda yapılması gerekeni Scrum ekibine anlatır. Ve tüm Scrum ekibi, sonraki sprintin hedefini oluşturmaya odaklanır.

Scrum ekibi, ürün sahibi ile işbirliği yaparak, ürün birikim listesinin en üstünden başlayarak hangi öğelerin sprint birikim listesine ekleneceğine karar verecektir.

Ayrıca, sprint birikim listesi, ürün artışını sağlamak ve sprint hedefini gerçekleştirmek için bir plan içerir.

Tam bu noktada, ürün birikim listesi ile sprint birikim listesi arasındaki farkı anlamak için kısa bir açıklama yapalım.

Ürün birikim listesi, üründe olması gereken veya olabilecek fikirlerin veya özelliklerin sıralı bir listesidir. Sprint birikim listesi, her sprint’in başında sıfırdan oluşturulur ve mevcut sprint’te yapılacak ürün iş listesi öğelerini ve planı içerir. Sprint birikim listesindeki tüm öğeler, ürün birikim listesinden gelir.

Plan ise ortaya çıkacak fonksiyonun ve sprint hedefinin nasıl sağlanacağını açıklar. Plan, scrum ekibinin bir artış oluşturmasına izin veren ürün birikim listesi öğesinin ayrıştırılmasıdır. Ayrıştırma ile sprint içinde yapılacak aktiviteler tanımlanmış olur.

Ürün birikim listesi kalemleri, NE’yin teslim edileceğini açıklar. Plan, bunun NASIL olacağını ele alır. Sprint hedefi, sprintin NEDEN değerli olduğunu gösterir. Hepsi, sprint birikim listesinin bir parçasıdır.

Scrum ekibi, bir sprint için ürün birikim listesi öğelerini seçtiklerinde, neyin teslim edileceğine dair bir tahmin oluşturmuşlardır. Sprint için yapılan tahminler asla bir garanti, söz veya taahhüt değildir. Sprint sırasında beklenmedik şeyler olabilir.

Sprint birikim listesini, yalnızca sprint sırasında var olan geçici bir yapı olarak görüntüleyebilirsiniz. Her sprintin yeni bir sprint birikim listesi olacaktır. Sprint’in sonunda sprint birikim listesinde kalan herhangi bir bitmemiş iş, ürün birikim listesine geri konulacaktır.

Bundan sonra ne olması gerektiğine ürün sahibi karar verecektir. Ürün birikim listesi, ürün sahibinin sorumluluğundayken, sprint birikim listesinden, scrum ekibi sorumludur.

Ekip, sprint hedefine ulaşmak için, sprint boyunca gerekli gördükleri değişiklikleri yapabilir. Yapılması gereken işleri belirlediklerinde, sprint birikim listesine eklemeler de yapabilirler.

Sprint birikim listesinde kalan toplam iş, her gün en az bir kez yapılan toplantı ile takip edilir. Ekip üyeleri, sprint hedefine doğru ilerlemeyi takip etmekten sorumludur.

Eğitimlerimiz için İstanbul Kurumsal Gelişim’in Web Sitesini Ziyaret Edebilirsiniz.

Youtube Üzerindeki Videolu Eğitimleri Buradan İnceleyebilirsiniz.

UDEMY Eğitimlerim

9- Ürün Birikimini İyileştirme ve Tahminleme

Bir önceki dersimizde kullanıcı hikayeleri için açıklama ve kabul kriterlerini oluşturmaktan bahsetmiştik.

Bu dersimizde ise bir hikayenin içeriğini herkesin ortak anlamasından ve hikayeyi boyutlandırmaktan, diğer bir ifadeyle, tahminlemeden bahsedeceğiz.

Bunu bir örnek üzerinden görelim.

Ürün sahibi Başlangıç Sayfası Oluşturma maddesini Scrum ekibiyle daha detaylı değerlendirmek üzere bir çalışma başlatır. Gelin birlikte ekip üyemiz Ali Bey, ürün sahibi Zeynep Hanım ve Scrum Ustası Furkan Bey arasındaki konuşmaya bakalım.

Ali: “Aklıma şöyle bir şey geldi, sizinle de paylaşmak istiyorum. Başlangıç sayfasında, telefon numarası, adres bilgileri veya kullanılacak görsellerin kolayca değiştirilebilmesi için bir yönetici paneli gerekir diye düşünüyorum.”

Zeynep: “Evet haklısın, buna ileride kesinlikle ihtiyacımız olacaktır, çok iyi düşündün.”

Ali: “O zaman bu özelliği de ürün birikim listesi öğelerinin içine eklememiz gerekir.”

Zeynep: “Doğru söylüyorsun Ali. Pekî arkadaşlar, sizce bu öğeyi hangi sıraya eklemeliyim?”

Furkan: “Ürün sahibi olarak, kullanıcı hikayesini istediğin sıraya ekleyebilir ve istediğin zaman sırasını değiştirebilirsiniz. Zaman içinde ihtiyaçların aciliyeti ve önem seviyeleri daha da şekillenecektir, ve böylece sırayı belirlemek kolaylaşacaktır.”

İleriki derslerimizde öncelik sırası oluşturma ile ilgili farklı teknikleri detaylı olarak inceleyeceğiz.

Zeynep: “Eğer başka sorunuz yoksa, Başlangıç Sayfası Oluşturma öğesi için boyutlandırma çalışması yapmayı öneriyorum.”

Boyutlandırma veya Tahminleme, belirli bir görevi yerine getirmek için gereken çabanın bir öngörüsüdür. Tahmin, asla bir taahhüt veya verilen söz değildir. Tahminler, varsayımları, belirsizlikleri, riskleri içinde barındırır.

Scrum yaklaşımında tahminler birimsiz değerler üzerinden yapılır. Bir diğer ifadeyle, göreceli büyüklük yaklaşımı esas alınır. Basit bir örnekle açıklayalım. Büyükçe bir binaya baktığınızda, o binanın kaç katlı olduğunu söylemek oldukça zordur, bunun yerine iki binayı karşılaştırıp, hangisinin daha büyük olduğunu söylemek çok daha kolaydır. Buna göreceli boyutlandırma adı verilir.

Benzer başka bir bakış açısı şu şekilde olabilir. Örneğin, parkta yürüyüş yapmak, harcanacak çaba açısından sadece 1 rakamı ile temsil edilsin. Buna karşılık, Everest gibi bir dağa tırmanmanın zorluğu ve karmaşıklığı 100 rakamı ile temsil edilsin. Böylece, ölçek olarak kullanacağımız kriterleri belirlemiş olduk. Bundan sonra, işlerimizin büyüklüğünü düşünürken, parkta yürümeyi, bir yokuşa veya küçük bir tepeye çıkmayı, şehrimizin yakınlarındaki bir dağa tırmanmayı ve en nihayetinde Everest’in zirvesine ulaşmayı düşünerek, tahminleme yapabiliriz. Tahminleme esnasında verilen sayıların doğrusu ve yanlışı yoktur. Takım üyelerinin her birisi, kendisi için işin zorluğunu ve karmaşıklığını düşünerek bir tahminde bulunur.

Ekip üyeleri, “başlangıç sayfası hazırlama” öğesi için tahminlerini birbirlerinden bağımsız olarak bir kağıda yazarlar ve aynı anda birbirlerine gösterirler. Burada amaç, birbirlerinden etkilenmemelerini sağlamak ve her birinin bağımsız tahminde bulunmasını garanti altına almaktır.

Örneğin 9 – 12- 15- 22 – 28 şeklinde rakamlar yazmış olsunlar. Scrum Master, ekip üyelerinden bu rakamları aşağıdaki sayı dizisine uygun şekilde revize etmelerini ister.

0- 1- 2- 3- 5, 8, 13, 20, 40 ve 100 – Bu sayılar, planlama pokeri olarak adlandırılan sayı dizisidir.

Böylece, verilen tahminler 8 -13 – 13 -20 ve 20 olarak revize edilir. Burada amaç, verilen tahminlerin birbirine yakın olanlarını kategorize etmek ve benzer bir ölçeğin içine yerleştirmektir.

Bu tahminlerden sonra, ekip üyeleri tahminler arasındaki farkların neler olduğunu belirlemek üzere tartışırlar. 20 rakamını seçen bir takım üyesi, siteye koyulacak logonun dijital olarak hazır olmadığını ve çizim yapılması gerektiğini söyler. Diğer bir takım üyesi, ana sayfada kullanılacak resimler için profesyonel fotoğraf çekimi gerektiğini ifade eder. Diğer takım üyeleri, bu detayları düşünmediklerini kabul ederler ve işin zorluk seviyesi olarak ekipçe 20 rakamı üzerinde ortak karara varırlar. Bunun üzerine Furkan ekibe bir hatırlatma yapar.

Furkan Scrum master: “Arkadaşlar, bu 20 rakamının karşılığının 20saat veya 20 gün olmadığını hatırlatmak isterim. Fakat bundan sonra, diğer öğeleri tahmin ederken, bu öğe ile karşılaştırıp, zorluk ve karmaşıklık açısından puan vermemiz daha kolay olacaktır.”

Diğer öğelerin tahminlenmesiyle, ürün birikim listesindeki öğelerin her birisine, hikaye puanları verilmiş olur.

Yüksek Performanslı Proje Ekipleri

Proje Yönetimi Discord Kanalı Açılmıştır

Proje Yönetimi Discord Kanalına üye olmak için aşağıdaki linki kullanabilirsiniz.

https://discord.gg/PPtMzzt

Sanal grupların başarılı işler çıkaracağına inancım çok eskilere dayanır.

1999 yılında msproject@egroups.com adlı sanal grubu kurmuştum. Sonra adı, msproject@yahoogroups.com olmuştu. Yıllar içinde 1000 kişiden fazla üyesi olmuştu grubumuzun ama etkileşim çok sınırlı kalmıştı.

Yanlış hatırlamıyorsam 2008 yılında Google Groups’da Proje Yönetimi içerikli bir grup kurmuştum, sonrasında ilgilenemediğim için kapatmıştım ama Google Groups halen devam ediyormuş ve bakın ne buldum?

15 Kasım 2008’de PMI Türkiye Grubunun üyesiymişim ve o yıllarda yapılan kongre davetiye mesajları hala duruyor.

2010 Eylül ayında Linkedin üzerinden açtığım Proje Yönetimi grubundan şu anda 1900 üyesi var fakat sınırlı sayıda kişi paylaşım yapıyor.

Discord Kanal’ı herkese açıktır ve proje yönetimi temelinde herkes istediğini paylaşabilecektir. Umarım, proje yönetimine gönül verenler için faydalı olur.

Şimdilik ana başlıklar aşağıdaki gibi. Yeni kanal başlıkları için lütfen öneride bulunun.

Hoşgeldiniz: Kendinizi kısaca tanıtınız.

Eğitim Duyuruları,

Kongre Duyuruları

Py-ödevleri

Proje fikri olanlar

İş ilanları

Makale linkleri

Video Linkleri

Podcast linkleri

Sınav deneyimleri

Py yazılımları

Sektörel Paylaşımlar

Proje Yönetimi Sertifikaları

Projelerde Eğitim Planı Oluşturmak

Projelerde eğitim planı geliştirmenin ilk adımı, paydaşların ihtiyaç duyacağı gerekli becerileri belirlemektir.

Eğitimler, bilgi birikimi aktarmak, kabiliyet gelişimi sağlamak veya geçmiş deneyimleri aktarmak şeklinde olabilir.

Farklı paydaşların farklı eğitim ihtiyaçları olabilir. Bazıları, eğitimde öğrendiklerini hemen kullanırken, bazılar işi denetlemek için eğitimden yararlanıyor olabilir.

Proje ekip üyelerine verilecek eğitimler, projenin hedefleri şekillendikçe, netleşmeye başlar. Özellikle, müşterinin sektörüne yönelik kavramlar, iş yapış şekilleri, yasal kısıtlar, sektör dinamikleri gibi faktörler eğitimlerin içeriğini oluşturur. Özetle, proje ihtiyaçlarının anlaşılması, hangi konularda eğitim gerektiğinin belirlenmesi için ön koşuldur.

Eğitim, ekip üyelerinin yeni veya geliştirilmiş beceri, bilgi kazandığı bir etkinliktir. Konular, yönetim yaklaşımları, teknik veya farkındalığı artırıcı içerikler olabilir.

Eğitim birçok şekilde verilebilir. Kapsamlı bir liste olmasa da, bazı eğitim sunum modelleri şunlardır:

• Eğitmen liderliğindeki sınıf eğitimi

• Sanal sınıf eğitimi

• Kendi hızınızda e-öğrenme

• Belge incelemeleri

• Etkileşimli simülasyonlar

• İşbaşı eğitimi

Paydaşların eğitim ihtiyaçları ve öğrenme biçimleri farklı olacaktır ayrıca bütçe kısıtı da farklı öğrenme araçlarını gündeme getirecektir.

Son kullanıcı eğitimleri, yeni sisteme geçişe yakın zamanda yapılması gerektiğinden, zaman planlamada dikkatli olmak gerekir.

Eğitim Boşluk Analizi: Projenizin paydaş analizine dayanarak, mevcut becerileri ve gerekli becerileri nelerdir?

Müşterinin iş akışlarında ve rollerinde yapacağı değişiklikleri değerlendirerek eğitim eksikliklerini belirlemelisiniz.

Ekip üyeleri de, projeyi hızlandırmak veya proje ortamını daha detaylı anlamak için eğitim alabilir.

Bütün bu değerlendirmeler sonunda, eğitim planı hazırlanır; Bu planda hangi paydaşın, hangi konuda eğitim alması gerektiği, eğitimlerin ne zaman yapılacağı, eğitimin güncel tutulması için tekrar sıklığı gibi faktörler tanımlanır.

Eğitim Seçenekleri

Eğitmen liderliğinde eğitim: Sınıf veya sanal eğitim ortamında canlı eğitmen liderliğinde eğitim verme şeklidir.

Kendi hızınızda e-öğrenme: Öğrencilere çevrimiçi olarak sunulan ve genellikle zengin medya videosu, benzetilmiş laboratuvar egzersizleri içeren bir tarayıcı kullanılarak tüketilen e-öğrenme içeriğidir. Bu yaklaşımın en büyük faydası pek çok öğrenciye ulaşma imkanı olmasıdır.

Belge incelemeleri: Basit bilgi aktarımı için, ilgili belgeleri paylaşmak yeterli olabilir.

Proje personeli ve müşteri paydaşları için yapılacak eğitimlerin maliyetleri proje bütçesini hesaplarken mutlaka düşünülmelidir.

Bu maliyetler şunları içerebilir:

• İçerik oluşturma ve düzenleme maliyetleri

• İçerik barındırma ve dağıtım maliyetleri

• Eğitmen maliyeti

* Eğitim malzemesi çoğaltma ve dağıtma

• Eğitim salonu maliyetleri

Lojistik maliyetleri (konaklama, yiyecekler)

Proje yöneticisi zaman çizelgesi içinde , eğitim tarihi ve yerini duyurması gerekir.

Eğitimin paydaşlara yayınlanması, kayıt, kayıt onayı, hatırlatma mesajı gönderme ve paydaş katılımını doğrulamak için bir mekanizma kurmak gerekebilir.

Son kullanıcı eğitimlerinde, içeriğin hazırlanması ve eğitim verilmesi aktiviteleri, projenin kritik yolundaysa, projenin teslimini geciktirebileceği için zaman planına büyük özen gösterilmelidir.

Kendi Kendine Organize Olan Ekipler

Bir projede kullanılan metot ne olursa olsun (çevik veya öngörücü) projedeki faaliyetleri detaylı olarak tanımlamaktan ve o işlerin tamamlamaktan, ekip üyeleri sorumludur.

Çevik yaklaşımda, ekibin aktiviteleri tanımlaması ve işleri üstleniyor olması, ekibin kendi kendine organize olması olarak tanıtılır ve öngörücü yaklaşıma göre üstünlük olarak gösterilir.

Halbuki, öngörücü yaklaşımlarda da proje yöneticisinin tek başına aktiviteleri belirlemesi mümkün değildir. Proje yöneticisi, iş kırılım yapısını çıkardıktan (kapsamı belirledikten) sonra detay aktiviteler için ya takım liderlerinin, ya da ekip üyelerinin bilgi birikimine başvurmalıdır.

“Bir işin detayını en iyi bilen, o işi yapandır.”

Takım liderleri (veya ekip üyeleri), iş paketlerinin hedeflediği teslimata ulaşmak için aktiviteleri tanımlamalı, işlerin yapılış sıralarını oluşturmalı, kaynak ve süre tahmin etmeli ve bu detayları diğer iş paketlerinin arasına entegre etmelidir.

Pratiğe baktığımızda, pek çok şirkette, planlama eylemi, sadece proje yöneticisinin göreviymiş gibi algılanır ve bu yanlış algı, öngörücü yaklaşımın dezavantajı olarak gösterilir.

Hangi metot seçilirse seçilsin, planlamayı proje yöneticisininin tek başına yapması mümkün değildir.

Öngörücü veya çevik metot farketmeksizin, aktiviteleri detaylandırmaktan ekip üyeleri sorumludur.

Ayrıca, ekip üyeleri, işlerin ilerleme durumunu da düzenli olarak (yazılı veya sözlü) proje yöneticisine aktarılmalıdır ki, projenin mevcut durumu ve gelecek tahmini yapılabilsin.

Proje Yönetiminde SWOT Analizi

SWOT Analizi, ürününüzü, ekibinizi, tedarikçilerinizi ve hatta kendinizi detaylı olarak anlamak için çok etkili bir araçtır.

Biz, bu değerlendirmeyi bir proje ekibi için ele alalım.

Güçlü Yönler (Strengths):

Projenizin içindeki, projeyi başarıya ulaştırmada yardımcı faktörler, sizin güçlü yönlerinizdir.

Birbirini çok uzun zamandır tanıyan bir ekibinizin olması,
Geçmiş projelerde bir arada çalışmış ekip üyelerinin olması,
Belirli bir konuda ortak eğitime katılmış ekip üyelerinin olması,
Projede üst yönetimin projenizi destekliyor olması,

gibi faktörleri Güçlü Yönler olarak düşünüp, yazabilirsiniz.

Proje boyunca güçlü yönlerinizin bozulmamasına dikkat etmeniz gerekiyor. Birbirini uzun zamandır bilen ekip üyeleri dağılırsa, bu durum, projeniz için Zayıf Yönünüz olarak karşınıza çıkacaktır.

Zayıf Yönler (Weakness):

Projenizin içindeki ve projenizin başarıya ulaşmasını zorlaştıran faktörler zayıf yönlerinizdir.

Birbiriyle ilk defa bir araya gelen ekip üyeleri,
Ekibin yeni bir metot veya araç kullanma ihtiyacı,
Proje yöneticisinin, proje yönetimi eğitimi almamış olması,

gibi faktörleri Zayıf Yönler olarak düşünüp, yazabilirsiniz.

Bu faktörleri, iyileştirmek için gerekli aktiviteleri belirleyip, proje planınızın içine dahil etmeniz gerekir. Zayıf yönleri, iyileştirmek için zaman ve para harcamalısınız.

Proje hedeflerinizi ortaya koyarken, bu faktörleri dikkate alarak, daha gerçekçi proje hedefi belirleyebilirsiniz. Bu faktörleri görmezden gelirseniz, proje hedefine ulaşma ihtimaliniz azalacak ve projeniz başarısız olarak görülecektir.

Fırsatlar (Opportunities):

Projenizin dışındaki ve projenizi başarıya ulaştırma ihtimalini artıran faktörler, sizin için Fırsat niteliğindedir.

Çıkacak bir kanunla, projenizin devlet desteği kapsamına girmesi,
Projede bazı ara ürünlerin, farklı pazarlara sunulabilir olması,
Bir akademik araştırmanın, projenizin süresini ve maliyetini azaltacak olması,
İşinde uzman bir tedarikçinin, proje risklerini üstlenebilmesi,

gibi tanımları fırsat olarak görüp, yazabilirsiniz.

Fırsatların, faydaya dönüşebilmesi için bir takım adımlar atmak gerekmektedir. Bu adımlar, temelde dört başlıkta değerlendirilir;

Yararlanma: Fırsatın oluşması durumunu garanti altına almayı hedefler.
Geliştirme: Fırsatın olma ihtimalini ve/veya yaratacağı etkiyi artırmayı hedefler.
Paylaşma: Bir başka firmayla fırsatı paylaşmayı hedefler.
Kabul etme: Fırsatın oluşmasını ummak ve herhangi bir aksiyon almama halidir.

Tehditler (Threats)

Projenizin dışındaki ve projenizi başarıya ulaştırma ihtimalini azaltan faktörler, sizin için tehdit niteliğindedir.

Çıkacak bir çevre koruma kanunu ile projenizin süresinin ve maliyetinin artması,
Bir rakip firmanın sizden önce ürünü piyasaya çıkarması,
Ekonomik sebeplerden proje maliyetlerinizin artması,

gibi maddeleri tehdit olarak görüp, yazabilirsiniz.

Tehditlerin, proje veya şirkete zarar vermemesi için yapılacaklar dört başlıkta değerlendirilir;

Kaçınma: Kapsamı daraltmak suretiyle riskli aktiviteleri ortadan kaldırmak.
Azaltma: Tehdidin olma ihtimalini ve/veya yaratacağı etkiyi azaltmayı hedefler.
Devretme: Riskli aktiviteyi bir başka firmaya aktarmaktır.
Kabul etme: Tehdidin etki gücü veya olasılığı az ise, herhangi bir eyleme geçmeme hali ile kabul etme stratejisi uygulanmış olur.

Hizmet Seviyesi Sözleşmeleri

Hizmet Seviyesi Sözleşmeleri (Service Level Agreement), hizmet sağlayıcı (dahili veya harici) ile son kullanıcı arasında düzenlenir ve hizmet sağlayıcıdan beklenen hizmet düzeyini açıklayan içeriğe sahiptir.

Müşterinin, hizmet kullanımı (ürünün performans) ve hizmet garantisi (kullanılabilirlik, hız, güvenlik, süreklilik ve diğer kullanılabilirlik özellikleri) beklentilerini içerirler.

Hizmet Seviyesi Sözleşmeleri, proje teslim edildikten sonra, hizmetin devam edebilmesi için beklenen performans seviyesini tanımlar.

Tedarikçi firma, müşterisine verdiği ürünün sorunsuz bir şekilde çalışacağına dair teminat verir. Projeden sonra eğer ürün yaşam döngüsünde müşteri sorun yaşarsa, tedarikçi firma verdiği taahhüt çerçevesinde ürünün işlevselliğini sağlamayı garanti eder. Tedarikçi firma sunduğu garantiyi yerine getiremezse bu durumda müşterinin zararını karşılamak zorunda kalır.

Hizmet Seviyesi Sözleşmelerinin geçerliliği genellikle ürün yaşam döngüsüne paraleldir. Buna karşılık, sözleşmenin içeriğinin netleştirilmesi, proje yaşam döngüsü veya daha erken safhada yapılmalıdır.

Tedarik Yönetiminde Müzakerenin Önemi

Müzakereler, tarafların bir anlaşmaya varmasını amaçlayan tartışmalardır.

En çok kullanıldığı yer, tedarik sürecindedir ve karşılıklı anlaşmayı netleştirmek, satın alma haklarını, yükümlülükleri ve şartları belirlemek içindir.

Tedarik yönetiminde şirketler arası müzakereleri proje yöneticisinin veya proje ekibinin idare etmesi mümkün olmayabilir. Özellikle satın alma departmanından ve hatta hukuk departmanından uzmanların da katılması gerekebilir.

Tedarik sürecinde müzakere edilecek konular aşağıdaki maddeler olarak düşünülebilir:

Şartname veya ana teslimatlar
Kilometre taşları ve tarihleri içeren bir zaman çizelgesi
Performans raporlama beklentileri
Fiyatlandırma ve ödeme koşulları
Tetkik, kalite gereklilikleri ve kabul kriterleri
Garanti ve gelecekteki destek
Teşvikler veya cezalar
Sigorta ve kesin teminat
Taşeron onayları
Şartlar ve koşullar
Değişiklik talebi ele alma prosedürü
Fesih hükümleri ve anlaşmazlıkların çözümü

Şunu da unutmamak gerekir: Proje daha büyük bir programın parçasıysa, tedarik süreçleri ve bu çerçevede yürütülecek müzakereler program hedeflerine göre yönetilmelidir.

Projelerde Çatışma Kaçınılmazdır

Ben, eğitimlerimde çatışmanın faydalı olup, olmadığını sorarak, bu konuya giriş yaparım. Farklı fikirlerin ortaya çıkması açısından çatışmalar gereklidir ve çatışma işle ilgiliyse, farklı bakış açılarının değerlendirilmesi açısından proje ekibine fayda sağlayacaktır. Buna karşılık, çatışma bireyselleşmiş ise bu durumda çatışan kişilere de, ilgili şirkete de zarar vermeye başlar.

Çatışma yönetimi, takım performansına zarar verebilecek anlaşmazlıklar ile başa çıkmak için bir veya daha fazla stratejinin uygulanmasıdır.

Kaçınılmaz olarak, takımlar zaman çizelgeleme, sorumluluklar, efor tahminleri, işlerin yapılış yöntemleri, gereksinimlerin önem seviyeleri veya aciliyeti gibi pek çok konuda çatışmalar yaşarlar.

Bu yazıda bahsettiğim üzere; Takım Başlatma Belgesi proje ilerlerken, yaşanabilecek çatışmaların nasıl ele alınabileceği konusunda proje ekibine yardımcı olacaktır.

Bir anlaşmazlığın ortaya çıkması halinde, takım üyelerinin oy birliği veya oy çokluğuyla karar vermesi en doğru yöntem gibi düşünülebilir fakat bu her zaman mümkün olmaz. Proje devam ederken, bir kriz yaşandığında, bir veya iki kişinin acilen inisiyatif alması gerektiği durumlarda oylama tekniği kullanma fırsatı veya zamanı olmayabilir. Ekip üyelerinin böyle durumları kabul etmesi beklenir.

Etkili çatışma yönetimi, ortak anlayışın gelişmesine, performans ve üretkenliğin artmasına imkan sağlar.

Çatışma yönetilemez ise yıkıcı davranışlar, düşmanlık, ekibin düşük düşük performans göstermesi ve üretkenliğin azalması ile karşılaşırız – bunların hepsi projenin çıktılarının başarıya ulaşmasını engeller.

Detaylarını sonraki yazılarımızda ele alacağımız çatışma çözme teknikleri vardır: Çatışmanın yoğunluğu ve önemi, çatışmayı çözmek için ayrılacak zaman, çatışan tarafların kurum içindeki pozisyonları, çatışmaları kısa veya uzun vadede çözme ihtiyacı gibi faktörlere dayanan teknikleri ilerleyen günlerde yayınlayacağım yazılarda ele alacağım.

Takım Başlatma Belgesi (Takım Tüzüğü)

Takım Başlatma Belgesi, ekibin bir arada çalışırken bağlı olacakları temel değerlerini, aralarındaki anlaşmalarını ve bir takım pratik uygulamalarını belirlemeye yarayan bir içeriğe sahiptir.

İçeriğinde şu başlıklar yer almalıdır:

Ekibin paylaşılan değerleri.
Ekip iletişimi ve araçların kullanımı ile ilgili yönergeleri.
Takımın ortak olarak nasıl karar vereceği hakkında yöntemler.
Anlaşmazlıklar ortaya çıktığında ekibin çatışmaları nasıl çözeceğinin adımları.
Ekip üyelerinin nasıl ve ne zaman bir araya gelecekleri.
Ayrıca ortak çalışma saatleri, mevcut süreçlerini iyileştirmek için geçilecek adımlar üzerine yönergeler.

Bu doküman ekip tarafından hazırlanmalıdır ki ekip üyelerince sahiplenilsin. Periyodik olarak gözden geçirilir ve güncellenir.

Proje Takımını Kurarken Bunlara Dikkat

Proje ekibi içindeki sorumlulukların tanımlanması bir dizi faktöre bağlıdır. Bazı ekiplerde, ekip üyelerinin sorumlulukları açıkça delege edilir, bazılarında ise ekip kendi kendini organize olur ve ekip üyeleri kimin hangi işi yapacağına beraber karar verirler.

Bir sorumluluğu yerine getirmek için uygun bir kaynağın belirlenmesi aşağıdakilere faktörlere dayalıdır:

• Deneyim: Ekip üyesi, aktiviteyi gerçekleştirmek için gerekli deneyime sahip midir?

• Bilgi: Ekip üyesi, ilgili işi yapabilmesi için gerekli bilgiye sahip mi?

• Beceriler: Ekip üyesi gerekli becerilere sahip mi?

• Tutum: Ekip üyesinin işi yapmak için gerekli motivasyonu var mı?

• Uluslararası faktörler: Ekip üyesinin coğrafi yeri, saat dilimi ve iletişim ihtiyaçları göz önünde bulunduruldu mu?

Yeni bir ekip oluştururken, ekiple projenin amaç ve hedefleri, ekibin sorumlulukları ve gerekli roller ve beceriler hakkında bilgi paylaşmalısınız.

Açık iletişim ve etkili işbirliği, projenin başarısı açısından kritik öneme sahiptir.

Proje yöneticisi, proje bütçesinden sorumludur. Kaynak gereksinimleri, projenin ihtiyaçları, kaynak mevcudiyeti ve diğer faktörler göz önüne alındığında en uygun maliyetli kaynağı kullanarak projesini yönetmelidir.

Proje yöneticisinin projeye atanan ekip üyelerini, rollerini ve sorumluluklarını belgelemesi beklenir ve bir projede kaynak yönetim planı, proje organizasyon şemasını ve kaynak takvimlerini, kaynakların kapasitelerini içerir. Bu içerik, proje yönetim planının önemli bir bölümünü oluşturur.

Proje yöneticisi, proje bütçesinden ve ödemelerden sorumludur. Kaynak gereksinimleri, projenin ihtiyaçları, kaynak mevcudiyeti ve diğer faktörler göz önüne alındığında en uygun maliyetli kaynak kullanılarak karşılanmalıdır.

Proje yöneticisinin projeye atanan ekip üyelerini, rollerini ve sorumluluklarını belgelemesi beklenir ve bir proje ekibi dizini, proje organizasyon şemaları ve proje çizelgeleri içerebilir. Bu görevler proje yönetim planının önemli bir bölümünü oluşturur.

Örnek PMP Sınav Sorusu

Aşağıdakilerden hangisi aktivitelere kaynak atarken dikkat etmeniz gereken bir özellik değildir?

a- Ekip üyelerinin becerileri

b- Ekip üyelerinin cinsiyetleri

c- Ekip üyelerinin tutumları

d- Ekip üyelerinin uyrukları

Sanal Ekipler

Günümüzde birçok proje ekibi, farklı yerlerde bulunan birden çok üyeye sahip sanal ekiplerdir. Sanal ekipler, yüz yüze görüşmeye çok az zaman ayırarak veya hiç zaman harcamadan rollerini yerine getiren ortak bir amacı olan bir grup insan olarak tanımlanır.

Sanal ekipler, yüksek becerilere sahip ekip üyelerini daha düşük maliyetlerle bulmak için fırsatlar yaratır ve projenin ulaşım ve konaklama masraflarından kurtulmasına imkan verir.

Ayrıca, sanal ekip kullanımı artıkça engelli insanlar için iş yapma imkanları da artmaktadır. Bu yüzden, istihdamı artırmak için çok önemli avantajları vardır.

Sanal ekipler, yüz yüze iletişimi kolaylaştırmak, dosyaları depolamak ve paylaşmak, etkili tartışmalar yönetmek ve ve ekibin takvimini takip etmek için teknolojik çözümlerden yararlanmalıdır.

Sanal ekipler, şeffaflığı artırmak, işbirliğini teşvik etmek, görevlerin durumunu takip edebilmek için bilgi radyatörlerinden yararlanırlar. Bilgi Radyatörleri, herkesin en son bilgileri hızlı bir şekilde görebilmesi için oldukça görünür bir konuma yerleştirilen görsel ekranlar için kullanılan genel bir terimdir. Kanban veya Scrum Panoları örnek olarak verilebilir. Bu yapıda çalışan Trello.com gibi web siteleri de örnek olarak verilebilir.

Sanal ekip üyeleri coğrafi olarak farklı konumlarda olduğu için aşağıdaki zorluklarla karşılaşmak söz konusudur.

• Ekip ruhu ve işbirliği duygusu sağlamanın yollarını bulmak zor olabileceğinden, bağ ve ekip ruhu oluşturmak zor olabilir.

• Ekipler yüz yüze görüşemediği için iletişim ve bilgi paylaşımının çeşitli teknoloji türlerine dayanması gerekir.

• Ekipteki herkesin birbirine güvenilir bir şekilde bilgi iletebilmesi ve bilgilere erişebilmesi için elektronik ortamdaki işbirliğini yönetmek zor olabilir.

• Dağınık bir ekipte roller, raporlama ve performansı izlemek daha zor olabileceğinden, bireysel performanslar gözden kaçabilir.

• İletişimde vücut dilinin etkisi %50’den fazladır. Sanal ekiplerde iletişim hatalarının daha fazla yaşanması yüz yüze iletişime göre daha sık karşılaşılan bir durum olabilir.

• Sanal ekip üyelerinin bulundukları ortamlardaki dikkat dağıtıcı faktörleri ortadan kaldırmak, proje yöneticisinin kontrolünde olamayacağından ekip üyelerinin performansını doğru değerlendirmek mümkün olmayabilir.

• Sanal ekip üyeleri arasındaki saat farklılıkları, ekip performansını olumsuz etkileyebilir.

• Teknik yanı yoğun projelerde yer alan sanal ekip üyeleri farklı ölçü birimlerini (ağırlık, uzunluk gibi) gündelik hayatlarında kullanıyor olabilirler; Bu tip projelerde iletişim esnasında ölçü birimleri üzerinde farklı algılar veya yanlış anlamalar oluşabilir.