Her kılavuz, büyük bir projeyi iş akışlarına bölmenizi önerir. Ancak neredeyse hiçbiri, bu akışlar arasındaki alanları nasıl doldurmanız gerektiğini söylemez. Oysa bu alanlar, projelerin başarısını veya başarısızlığını belirler.
Proje yönetimideki iş akışlarını basit bir bölme problemi olarak düşünmek kolaydır. İşi parçalara ayırır, her birine bir sorumlu atar ve işlerin ilerlemesine izin verirsiniz. Ancak işi bölmek sadece ilk adımdır. Bir iş akışı mükemmel bir şekilde ilerleyebilir, ancak bir sonraki takıma devredilme süreci kimse tarafından izlenmezse yine de sorunlara yol açabilir.
Bu kılavuz, aşamalar arasında gerçekleşen süreçlerin yönetilmesine odaklanmaktadır. Örneğin, görev devirleri, bağımlılıklar ve ortak son tarihler.
Özet: İş akışları, karmaşık bir projeyi her biri tek bir sorumluya sahip paralel aşamalara böler. Bu kısım kolaydır ve neredeyse herkes bunu doğru yapar. Projeleri batıran şey ise bu aşamaları birbirine bağlayan görev devirleri, bağımlılıklar ve ortak tarihlerdir. Çoğu zaman, bu boşlukları doldurmakla görevlendirilmiş kimse olmaz.
Başarılı takımlar sadece iş akışlarını daha iyi yürütmekle kalmaz. Her bağlantı noktasını günlük olarak izlenmesi gereken bir unsur olarak ele alırlar. Sorumlulukları net bir şekilde belirler, basit “evet-hayır” kontrol noktaları kullanır ve bir sorunun ne zaman üst yönetime iletileceğine dair açık kurallara uyarlar. Tek bir şey hatırlayacaksanız şunu unutmayın: sadece iş akışlarını değil, bağlantı noktalarını da yönetin.
Proje Yönetimi'nde İş Akışı Nedir?
İş akışı, birbiriyle ilişkili görevlerin oluşturduğu ayrı ve bağımsız bir yoldur. Aynı ana proje hedefine ulaşmak için diğer yollarla paralel olarak ilerler. Her yolun kendi proje çıktıları, zaman çizelgesi ve tek bir sorumlusu vardır: iş akışı lideri.
Buradaki anahtar kelime "yapı"dır. Birbiriyle gevşek bir şekilde bağlantılı görevler grubunun sınırları yoktur ve net bir sorumlusu bulunmaz. Buna karşılık, bir iş akışının tanımlanmış bir kapsamı, net devir noktaları ve ilerlemeden sorumlu tek bir kişi vardır. Bu yapı, paralel yürütülen çalışmaların birbiriyle çakışmasını önler.
İş akışları, karmaşık bir projeyi anlaşılır kılan unsurlardır. Her bir iş akışının durumunu, projenin tamamını tek tek incelemek zorunda kalmadan görebilirsiniz. İş akışları olmadan büyük projeler çöker. Her şey eşit derecede acil görünür, takımlar birbirine bağlı bağımlılıkları gözden kaçırır ve tek bir gecikme bile tüm proje zaman çizelgesini mahveder.
İş akışları, "track", "proje akışı" veya "teslimat akışı" olarak da adlandırılabilir. Bunlar, farklı etiketler altında aynı yapısal birimdir.
İş akışı ve ş akışı: Aralarındaki fark nedir?
İş akışı, geniş bir çalışma alanını ifade eder. Ş Akışı ise bir görevin bu alan içinde ilerletildiği belirli bir süreçtir. İnsanlar genellikle bu terimleri birbiriyle karıştırır. Ancak, bu terimleri karıştırmak, sahipliğin belirsiz kalmasına yol açar.
İş akışı, bir proje içindeki ilgili görevler, takımlar ve teslim edileceklerin oluşturduğu bütün bir alandır. İş akışı ise, tek bir görevin baştan sona izlediği adımların tam sırasıdır. Örneğin: Taslak, İnceleme, Onaylama, Yayınlama.
İşte anahtar farklılıklar yan yana:
| Kapsam | İlgili işlerin geniş kapsamı | Tekrarlanabilir tek bir süreç |
| Sahiplik | İş akışı lideri, bir takımı yönetir | Süreç sahibi adımları tanımlar |
| Süre | Proje süresince devam eder | Bir görev her başladığında tekrarlanır |
| Proje Roli | Önemli bir paralel süreç | Bir iz içinde çalışan bir süreç |
| Örnek | Ürün lansmanı için pazarlama | Bu lansman kapsamında içerik onayı |
Temel kural: İlişki, kapsama esasına dayanır. Her iş akışı, birden fazla ş akışını içerir.
Temel kural: İlişki, kapsama esasına dayanır. Her iş akışı, birden fazla ş akışını içerir.
İş akışını bir kap, iş akışlarını ise bu kap içindeki tekrarlanabilir mekanizmalar olarak düşünün. Örneğin, bir ürün lansmanı için oluşturulan pazarlama iş akışı, üç ayrı iş akışını çalıştırabilir: içerik oluşturma iş akışı, reklam onay iş akışı ve lansman günü kontrol listesi iş akışı.
İş Akışlarının Faydaları Nelerdir?
İş akışları size altı somut avantaj sunar: sınırlı gecikmeler, net sahiplik dağılımı, görünür iş yükleri, izole edilmiş riskler, daha kolay raporlama ve daha hızlı işe alım. İş akışları sadece bir projeyi düzenlemekle kalmaz; baskı altında projenin nasıl davrandığını da değiştirir. İşte elde edeceğiniz faydalar.
- Gecikmelerin sınırlandırılması. Bir iş akışındaki gecikme, diğerlerine yayılmaz. Düz bir görev listesinde, herhangi bir yerdeki gecikme tüm süreci yavaşlatır. İş akışları sayesinde, altyapıdaki iki haftalık bir gecikme, doğrudan bir paylaşım olmadığı sürece kullanıcı deneyimi (UX) tasarımını etkilemez. Etki alanı “tüm proje”den “tek bir iş akışı”na indirgenir. Kaçırılan bir ara teslim tarihi ile kaçırılan bir lansman arasında kolayca ayrım yapabilirsiniz.
- Net sahiplik dağılımı. Her iş akışının atanmış bir lideri vardır. Bir aksaklık olduğunda kimse "Bu kimin işiydi?" diye sorarak zaman kaybetmez. Lider ya sorunu çözer ya da üst yönetime bildirir. Sahipliğin paylaşımı, sorunların çözülmeden kalmasına neden olur: herkes başka birinin ilgileneceğini varsayar
- Görünür iş yükleri. Tükenmişlik ortaya çıkmadan önce fark edebilirsiniz. Kişiler ve araçlar, tek bir devasa iş birikimi yerine belirli iş akışlarına aittir. Bir mühendisin, aynı anda yoğunluğa ulaşan üç farklı iş akışında görevlendirilip görevlendirilmediğini gösterir. Bu çakışma, düz bir listede görünmezken iş akışı görünümünde açıkça görülür.
- İzole risk. Bir tedarikçi veri taşıma sürecinde bir son tarihi kaçırsa bile, değişiklik yönetimi süreci eğitim materyallerini hazırlamaya devam eder. Teknik kurulum süreci de ilerlemeye devam eder. Tek bir blok, beş süreci değil, sadece bir süreci durdurur. Bir proje haftası yerine, bir iş akışı haftasını kaybedersiniz.
- Daha kolay raporlama. Liderler, projenin tamamını okumadan tek bir akışı kontrol edebilir. Yalnızca uyumlulukla ilgilenen bir paydaş, cevap bulmak için o belirli akışı inceleyebilir. Durumu anlamak için 200 görevı tek tek gözden geçirmelerine gerek kalmaz.
- Daha hızlı işe alım. Yeni takım üyeleri birkaç gün içinde verimli hale gelir. Projenin ortasında ekibe katılan bir mühendis, yardımcı olmak için tüm girişimi öğrenmek zorunda kalmaz. Sadece kendi iş akışının kapsamını öğrenir ve çalışmaya başlar. İş akışı, küçük ve yönetilebilir bir sınır oluşturur
Projeler iş akışlarının içinde başarısız olmaz. Başarısızlık, iş akışları arasındaki kesişme noktalarında yaşanır. İşte nedeni:
Bir projeyi iş akışlarına bölmek işin kolay kısmıdır. Herkes Boxları çizebilir. Projeleri başarısız kılan ise bu Boxlar arasında yaşananlardır. Bunlar, görev devirleri, bağımlılıklar ve bir iş akışının, başka bir iş akışının bağlı olduğu bir son teslim tarihini kaçırdığı anlardır.
Kararlar, durum değişiklikleri ve ertelenen son tarihler, süreçlerin kesiştiği noktalarda kaybolur. Ne kadar çok iş akışı oluşturursanız, o kadar çok devir teslim sürecini takip etmeniz gerekir.
Bu, " The Mythical Man-Month " kitabındaki matematiksel formülün insanlara değil, yapıya uygulanmış halidir. Yazar, bu formüle göre iletişim yollarının karekare orantılı olarak arttığını göstermiştir:
n(n-1)/2: Kişi sayısı arttıkça koordinasyon maliyeti ikinci dereceden artarken, çıktı sadece birinci dereceden artar.
"Kişiler" yerine "iş akışları" kelimesini kullanırsanız, bu ders yine geçerlidir. Üç iş akışı, yönetilmesi gereken üç arayüz demektir. Altı iş akışı ise on beş arayüz demektir. Eklediğiniz her iş akışı sadece iş yükünü artırmakla kalmaz; işin aksama ihtimalinin olduğu noktaların sayısını da kat kat artırır.
Bu, işin tamamını yeniden çerçeveler. Bir liderin işi sadece kendi iş akışını yürütmek değildir. Aynı zamanda sınırlarını korumaktır. Diğer iş akışlarına ne borçlu olduklarını ve bu akışların kendilerine ne borçlu olduğunu tam olarak bilmelidirler.
Aynı şekilde, bir proje yöneticisinin işi sadece görevleri yönetmekle sınırlı değildir. Bu iş, akışlar arasındaki etkileşimleri yönetmekle ilgilidir. Proje yöneticileri, görev devirlerini izlemeli, bağımlılıkları takip etmeli ve akışlar arası riskleri erken aşamada tespit etmelidir.
Burada da bir tuzak var. Conway Yasası olarak bilinen ünlü bir kural, kuruluşların doğal olarak kendi iç iletişim hatlarını taklit eden sistemler kurdukları konusunda uyarıyor. Başka bir deyişle, farkında olmadan iş akışlarınızı mevcut organizasyon grafiklerinize göre gruplandırmanız muhtemeldir.
Ardından, iki farklı takımı kapsayan görevlerin aksama yaşayanlar olduğunu fark ettiğinizde şaşıracaksınız. İş akışlarınızı, kimlerin zaten bir arada çalıştığına göre değil, iş türüne göre azaltın. Bu kılavuzun geri kalanı, Boxları çizmekle ilgili değildir. Boxlar arasındaki bağlantıları tasarlamakla ilgilidir.
Proje Yönetimi'nde İş Akışı Türleri
Dört ana iş akışı türü vardır: fonksiyonel (departmana göre), işlevler arası (sonuca göre), coğrafi (bölgeye göre) ve teknoloji/sistem (teknik katmana göre). Sınırları nereye çizdiğiniz, proje boyunca hangi devir teslim süreçlerini savunmak zorunda kalacağınızı belirler.
| İşlevsel | Herkesin anlayabileceği net sınırlar | Takımlar arası görevler gözden kaçıyor | İşleri büyük ölçüde bağımsız olan takımlar |
| Fonksiyonlar arası | Akışın içinde yer alan geçişler, kolayca izlenebilir | Personel bulmak zor; çalışanlar farklı iş akışlarına dağılmış durumda | Sıkı bir işbirliği gerektiren sonuçlar |
| Coğrafi | Gerçek yerel farklılıkları yansıtıyor | Bölgeler arasında tekrarlanan çabalar | Gerçek yerel kapsamda küresel uygulamalar |
| Teknoloji/sistem | Dikişler, gerçek sistem arayüzlerini haritalar şeklinde gösterir | Tüm entegrasyon riskleri sonuçta ortaya çıkar | Farklı katmanlara sahip yazılım ve BT |
İşlevsel iş akışları
İşlevsel iş akışları, mühendislik, pazarlama veya hukuk gibi departman veya disiplin bazında çalışır. Bu, birkaç takım için ön tanımlı seçimdir çünkü bu sınırlar organizasyon şemasında zaten mevcuttur. Bir akışın nerede bittiği ve bir sonrakinin nerede başladığı konusunda kimse tartışmaz.
Neler iyi sonuç veriyor:
- Herkesin anladığı sınırlar: Kimin neye sahip olduğu konusunda tartışma yoktur; bu durum, insanların günlük rollerine ilişkin mevcut düşünce biçimlerini yansıtmaktadır
- İşler bağımsız olduğunda devir teslim süreçleri sorunsuz olur: Mühendislik ekibi çoğu zaman hukuk ekibini beklemeden geliştirme yapabiliyorsa, süreçler arasında geçişler kolayca yönetilebilir
- Basit sahiplik yapısı: Her bölüm başkanı, görevin açıkça belirlenen lideri olarak görev yapar; böylece sorumluluklar ilk günden itibaren net bir şekilde belirlenir
Sınırlamalar:
- Departmanlar arası görevlerin bir "yeri" yoktur: Aynı anda üç takımın katılımını gerektiren her şey, kimsenin görevi haline gelmez (görev, tek bir iş akışına tam olarak uymaz)
- Akışlar yalnızca yerel olarak optimize edilir: Her takım kendi akışını mükemmelleştirir ve devrin sorumluluğunun başka birine ait olduğunu varsayar
Aşağıdaki durumlarda atlayın: En önemli hedefleriniz, üç veya daha fazla departmanın sürekli olarak uyumlu bir şekilde çalışmasını gerektiriyorsa. Bu durumda, iş akışları arasındaki uyumsuzluklar hızla artacaktır.
En uygun olduğu durumlar: Her takımın işinin nispeten bağımsız olduğu ve birkaç net, iyi tanımlanmış devir noktası bulunan projeler.
Fonksiyonlar arası iş akışları
Fonksiyonlar arası iş akışları, belirli bir çıktı veya sonuç etrafında yapılandırılır. Bu akışlar, farklı departmanlardan çalışanları tek bir akışta bir araya getirir. Örneğin, bir "kullanıcı onboarding" akışı bir tasarımcı, bir mühendis ve bir destek temsilcisini içerebilir. Bu akış, tüm parçaları liderin günlük olarak görebileceği bir akışta bir araya getirir.
Neler iyi sonuç veriyor:
- En zorlu görev devirleri görünürlük kazanır: Tasarım ve mühendislik arasındaki sürtüşmeler, tek bir iş akışı içinde, tek bir günlük toplantı sırasında ortaya çıkar. Uzak bir organizasyonel sınırın ötesine taşmaz.
- Farklı becerilere sahip ekipler arasında daha sıkı işbirliği: Aynı sonuca ulaşmak için çalışan kişiler, kendi alanlarını korumaya çalışanlardan daha hızlı koordinasyon sağlar
- Net sahiplik: Lider, tamamlanmış bir çıktının sahibidir. Başarı, basit faaliyetlerden ziyade teslim edilen işlerle ölçülür.
Sınırlamalar:
- Personel tahsisi sürekli bir mücadeledir: Çalışanları kendi takımlarından ayırıyorsunuz, ancak onların asıl yöneticileri hâlâ onları istiyor. Bu durum, çalışanların bağlılıklarını bölüyor
- Sorun, çalışanların takvimlerine kayıyor: Üç farklı fonksiyonlar arası akışa dahil edilen bir kişi, tek bir akış aşırı yüklenmiş olmasa bile yeni bir darboğaz haline gelir
Şu durumlarda atlayın: Bölüm başkanlarından, çalışanlarını bu çalışmaya ayırma konusunda gerçek bir taahhüt alamıyorsanız. Personel sayısı yarı yarıya eksik olan fonksiyonel akışlar, fonksiyonel akışlardan daha kötüdür.
En uygun olduğu durumlar: Farklı beceriler arasında sıkı bir işbirliği gerektiren ve takım sınırları ötesinde değil, yakından yaşanan sürtüşmeleri yönetmeyi tercih ettiğiniz teslimatlar.
Coğrafi iş akışları
Coğrafi iş akışları, Kuzey Amerika Lansmanı ile EMEA Lansmanı gibi, bölge veya konuma göre işler. Bu yapı, yerel yasalar, diller veya pazar koşullarının farklı görevler ortaya çıkardığı küresel lansmanlarda yaygın olarak kullanılır.
Neler iyi sonuç veriyor:
- Yerel farklılıkları gerçekçi bir şekilde yansıtıyor: Yerel yasalar veya piyasa koşulları farklılık gösterdiğinde, bölgesel iş akışları her takımın kendi hızında ilerlemesine olanak tanır
- Yerel sahiplik ve eylem: Pazarı iyi tanıyan bir bölge sorumlusu, uzaktan tahminlerde bulunan merkezi bir proje yöneticisinden daha doğru kararlar alır
- Bölgesel risk kontrol altında: Avrupa’daki bir uyum gecikmesi, Kuzey Amerika’daki lansmanı aksatmaz
Sınırlamalar:
- Çabaların tekrarlanması, başarısızlığın ön tanımlı nedenidir: Yerel işler ile paylaşım yoluyla yapılan işler arasında bir sınır olmadığı için, iki bölge aynı sorunu iki kez çözüyor.
- Ortak temel ögeler ihmal ediliyor: Marka kuralları, veri modelleri ve fiyatlandırma yapıları tüm bölgelerde tutarlı kalmalıdır. Bu ögelerin merkezi bir sorumlusu olması gerekir, ancak bölgesel akışların tümü bu işin başka biri tarafından halledildiğini varsayar.
Aşağıdaki durumlarda atlayın: Bölgeleriniz arasında yalnızca saat dilimi farkı varsa. Aslında var olmayan farklılıklar nedeniyle koordinasyon maliyetlerinizi gereksiz yere artırmış olursunuz. Bu durumda işlevsel bir kurulum kullanmak daha uygun olacaktır.
En uygun kullanım alanı: Yerel koşulların tamamen farklı görevler ortaya çıkardığı, ancak altında net bir şekilde sahipliği belirlenmiş ortak bir temel bulunan küresel uygulamalar.
Teknoloji/sistem iş akışları
Teknoloji/sistem iş akışları, çalışmaları Front-End, Back-End, Veritabanı veya Altyapı gibi teknik katmanlara göre gruplandırır. Bu kurulum, yazılım ve BT sektörlerinde yaygındır. Her katmanın farklı sahipleri ve risk profilleri vardır. Bu, "projeler birleşim noktalarında başarısız olur" ifadesinin en somut örneğidir; çünkü buradaki birleşim noktaları, sistem arayüzleridir.
Neler iyi sonuç veriyor:
- Bağlantılar, gerçek kod sözleşmelerine karşılık gelir: Devir teslimler, kod bağlantıları ve API'lerdir. Bunlar tanımlanabilir, sürümleri belirlenebilir ve test edilebilir. Bunlar, belirsiz bir takımdan takıma devir tesliminden çok daha somuttur.
- Uzmanlaşmış sahiplik: Her katmanın lideri, o katmanın riskleri konusunda derin bir uzmanlığa sahiptir. Bu, sorunların, onları anlayan kişiler tarafından erken aşamada tespit edildiği anlamına gelir.
- Eşzamanlı ilerleme: Front takımı ve arka uç takımı, üzerinde anlaşmaya varılan bir sözleşme çerçevesinde eşzamanlı olarak geliştirme yapabilir
Sınırlamalar:
- Entegrasyon riski son aşamada artar: Katmanların birbirine nasıl bağlantı kuracaklarına dair ertelenen her karar, entegrasyon aşamasında birdenbire ortaya çıkar. İşte bu yüzden son aşama sıklıkla başarısızlıkla sonuçlanır.
- Sözleşme değişiklikleri sessizce gerçekleşir: Bir katman, diğerlerine haber vermeden arayüzünü değiştirirse, en sonunda her şey bozulur
Aşağıdaki durumlarda atlayın: Projeniz, tüm teknik altyapının tek bir takım tarafından yönetilebilecek kadar küçükse. Katman tabanlı akışlar, ihtiyacınız olmayan ek arayüzler ekler.
En uygun olduğu durumlar: Her sistem katmanının farklı sahipleri, kendine özgü risk profilleri ve aralarında net bir kod arayüzü bulunan yazılım ve BT projeleri.
Çoğu büyük proje, karma bir yapı kullanır
Bu stilleri bir araya getirmek genellikle doğru bir yaklaşımdır, ancak aynı zamanda organizasyon grafiği tuzaklarının en çok etkisini gösterdiği nokta da budur. Küresel bir lansman, en üst düzeyde coğrafi akışları yürütürken, her bölgenin içinde pazarlama, lojistik veya uyum gibi fonksiyonel alt akışları barındırabilir.
Daha önce bahsedilen matematiği hatırlayın: her iç içe geçme düzeyi, ek yerlerinin sayısını katlar. Yalnızca görev devirlerini net bir şekilde görebileceğiniz kadar derine kadar iç içe geçirin.
Her İş Akışının İhtiyacı Olan Şeyler
Her iş akışının on şeye ihtiyacı vardır: tek bir sorumlu, net bir kapsam, belgelenmiş girdiler ve çıktılar, devretme dönüm noktaları, bağımsız durum izleme, bir eskalasyon kuralı, özel bir kanal, standart bir güncelleme biçimi, geçiş noktalarında tampon süre ve tek bir doğru bilgi kaynağı. Bir projeyi nasıl bölerseniz bölün, bir iş akışı ancak bunlar mevcut olduğunda ayakta kalabilir.
- Tek bir sorumlu. İş akışının ilerlemesinden ve devir teslimlerinden sorumlu tek bir iş akışı liderine ihtiyacınız vardır. Bu, bir komite veya takım olamaz. Sorumluyu tek kelimeyle ifade edemiyorsanız, o iş akışı henüz mevcut değildir.
- Net bir kapsam ve teslim edilecekler. Bu iş akışının neyi ürettiğini ve neyi üretmediğini açık ve net bir şekilde yazın. Belirsiz bir kapsam, ya aynı şeyi üreten iki iş akışına ya da her ikisinin de diğerinin bunu yaptığını varsaymasına yol açar.
- Giriş ve çıkışların listesi. Akışın başlaması için diğer akışlardan neye ihtiyacı olduğunu ve bittiğinde onlara ne borçlu olduğunu tanımlayın. Bu, yazılı hale getirilmiş bir bağlantı noktasıdır. Eğer bunu belgelemezseniz, planlama amaçları açısından bu bağlantı noktası mevcut sayılmaz.
- Devir teslim dönüm noktalarını netleştirin. Bu iş akışının işin başka bir akışa devredildiği noktalara, basit "evet-hayır" kontrol noktaları yerleştirin. Bir proje dönüm noktası ya tamamlandı ya da tamamlanmamıştır. Bir devir teslim işlemini asla "%80 tamamlandı" olarak etiketlemeyin.
- Bağımsız durum izleme. Her akışın, planlandığı gibi ilerleyip ilerlemediğini, risk altında olup olmadığını veya bloklanmış olup olmadığını göstermesi gerekir. Bu sayede liderlik ekibi, akıştaki her görevin detayını tek tek okumadan tek bir akışı kontrol edebilir.
- Eskalasyon için net bir kural. Bir bloğun ne zaman iş akışından çıkıp ana proje yöneticisine iletileceği konusunda önceden anlaşın. Örneğin: “iki günden uzun süren herhangi bir blok veya risk altındaki herhangi bir bağımlılık.” Bir kural olmadan, ya her şey eskalasyona gider ya da hiçbir şey gitmez
- Özel bir sohbet kanalı. Bu projeye ait güncellemeler, kararlar ve dosyalar için tek bir yer oluşturun. Önemli ayrıntıların kaybolmaması için bunu ana proje sohbetinden ayrı tutun.
- Standart bir güncelleme biçimleri. Liderin durumu ne sıklıkla raporlayacağını ve hangi şablonu kullanacağını belirleyin. Proje yöneticisinin bunları kolayca karşılaştırabilmesi için bu biçimleri tüm akışlarda aynı tutun.
- Geçiş noktalarında tampon süre ayırın. Özellikle görev devri noktaları civarında programa fazladan günler ekleyin. İş el değiştirdiğinde gecikmeler katlanarak artar
- Tek bir güvenilir kaynak. İş akışının planı ve durumuna ilişkin, herkesin güvendiği tek bir ana sürüm tutun. Ayrıntıları farklı uygulamalara dağıtırsanız, iş akışlarının ortadan kaldırması gereken kaosu yeniden yaratmış olursunuz.
Projeniz için Bir İş Akışı Nasıl Oluşturulur?
Bir iş akışı oluşturmak beş adımdan oluşur: kapsamı tanımlayın, projeyi teslimatlara bölün, her bir iş akışı için bir sorumlu atayın, bağımlılıkları ve dönüm noktalarını belirleyin ve ardından iletişim ve izleme sistemini kurun.
İster bir elektronik tabloda, ister bir proje yönetimi platformunda, ister bir Beyaz Tahta'da planlama yapın, asıl iş, işin sınırlarının ötesine geçmeye başladığında bile geçerliliğini koruyan sınırlar çizmektir.
1. Adım: Proje kapsamını ve hedeflerini tanımlayın
Tek bir iş akışı çizmeden önce, projenin neleri sağladığını ve neleri sağlamadığını yazın. İş akışı sınırları, kapsamdan kaynaklanmalıdır; tersi olmamalıdır. İşi anlamadan iş akışlarını belirlerseniz, kritik görevleri gözden kaçırabilir veya gereksiz iş yükü yaratabilirsiniz.
Devam etmeden önce şu üç şeyi belgelendirin:
- Nihai durum: Piyasaya sürülen bir ürün veya taşınan bir sistem gibi, tamamlanmış sonuç
- Kesin kısıtlamalar: Bütçe, son teslim tarihi ve tüm uyum kuralları
- Başarı kriterleri: İşin tamamlandığını nasıl anlarsınız? Örneğin, paydaşların onayları gibi.
Kısa ve öz olun. Bu adımın sonucunda basit, tek sayfalık bir kapsam belgesi ortaya çıkmalıdır.
Profesyonel İpucu: Projenin hedefini açıklayan tek bir cümle yazın. Bu cümlede "ve" kelimesi birden fazla kez geçiyorsa, muhtemelen içinde birden fazla iş akışı gizlidir.
2. Adım: Projeyi teslim edileceklere bölün
Projenin üretmesi gereken ana varlıkları belirleyin. İlgili öğeleri, her birinin kendine özgü bir çıktısı olan izlere göre gruplandırın.
Burada aşırı detaylandırmadan kaçının. Eklediğiniz her akış, daha fazla kesinti yaratır. On parçaya bölünmüş bir proje, devam eden işlerden çok toplantılara daha fazla zaman harcanmasına neden olabilir.
Gruplarınızda Bağımsızlık Testi'ni kullanın:
- İki görev grubu birbirini beklemeden ilerleyebiliyorsa, bunları birbirinden ayırın
- Birbirleriyle sıkı bir şekilde bağlantılıysa ve günlük olarak aynı kişilerle çalışıyorsa, bunları bir arada tutun
- Bir grubun 5'ten az görevi varsa veya sadece 1 kişi varsa, bu grupları tekrar dahil edin
3. Adım: İş akışı sahiplerini ve rollerini atayın
Her iş akışına tam olarak bir adet, adı belirtilen bir lider atayın. Bu kişi, zaman çizelgesinden, teslim edileceklerden ve devretme işlemlerinden sorumludur. Sahipliği bir komiteye veya takıma atamayın. Tek bir isme odaklanın.
Bu tek sorumlu kişi etrafında rolleri belirleyin:
- Lider: Akıştan sorumlu tek kişi
- Katkıda Bulunanlar: İşi fiilen yürüten kişiler
- Onaylayıcılar: Tamamlanan çıktıları onaylayan kişiler
- Paydaşlar: Güncellemelere ihtiyaç duyan ancak görevler üzerinde iş yapmayan kişiler
Profesyonel İpucu: Liderlerinize gerçek anlamda günlük yetki verin. Bir lider, ana proje yöneticisine önceden danışmadan kendi takımının önündeki engelleri kaldıramıyorsa, bu yapı sahte demektir.
4. Adım: Bağımlılıkları haritalandırın ve dönüm noktalarını belirleyin
Açık ve görünür bağlantılar kullanarak akışların birbirine nasıl bağlı olduğunu belgelendirin. Varsayımlara güvenmeyin. Bir bağımlılık yalnızca bir kişinin zihninde varsa, zaman çizelgesi aşıldığında uyarı tetiklenemez.
İzlerin kesiştiği noktaları tam olarak belirleyin:
- Bağımlılıklar: Her akış için, o akışa gelen engelleyicileri ve o akıştan çıkan çıktıları listeye alın
- Devir teslim dönüm noktaları: Her kesişme noktasına yerleştirilmiş basit "evet-hayır" kontrol noktaları
- Ortak tarihler: İki iş akışının son teslim tarihi aynıysa, her iki liderin de bu tarih üzerinde mutabık kalması gerekir
Profesyonel İpucu: Bir elektronik tabloda "bağımlılık" sütunu kullanın. Bir proje yönetimi aracında ise görsel zaman çizelgesi görünümü kullanarak tüm akışlardaki kritik yolu tek seferde görüntüleyin. Daha da iyisi, ClickUp Bağımlılık Eşleme Şablonu gibi yapılandırılmış bir düzen, bağımlılıkları kafanızda izlemek yerine bunları kaydetmeniz için hazır bir alan sunar.
5. Adım: İletişim ve izleme sistemini kurun
Her akışa güncellemeler, kararlar ve dosyalar için kendine özgü bir alan ayırın. Bunu ana proje sohbetinden ayrı tutun. Bu sayede, bir akışın günlük sohbeti, başka bir akışın acil uyarılarını gömmez.
Her iş akışı için basit bir iletişim planı oluşturmak üzere şu üç öğeyi belirleyin:
- Tek doğru kaynak: Herkesin güvendiği tek bir ana plan sürümü
- Standart bir güncelleme programı: Proje yöneticisinin ilerlemeleri kolayca karşılaştırabilmesi için, liderin uygun bir şablon kullanarak ne sıklıkla durum raporu sunduğu
- Bir eskalasyon kuralı: Bir sorunun ne zaman proje yöneticisine iletileceğine dair üzerinde anlaşmaya varılmış bir kural
Profesyonel İpucu: Proje başlangıcından önce durum şablonlarınızı standartlaştırın. Her lider kendi biçimini oluşturursa, proje yöneticisi proje risklerini yönetmek yerine güncellemeleri çevirmekle zaman kaybeder.
İş Akışlarını Yönetmeye Yönelik En İyi Uygulamalar
İş akışlarını iyi yönetmenin sırrı altı alışkanlıkta yatıyor: haftalık olarak kesişme noktalarını denetlemek, çalışma oturumları düzenlemek, farklı akışlardaki kişileri izlemek, akışlar arası bir risk kaydı tutmak, dönüm noktalarında sınırları gözden geçirmek ve tamamlanan akışları kapatmak. Bunları ayarlamak bir anlık görüntüdür. Bunları yürütmek ise bir film gibidir.
Başlangıç toplantısında tasarladığınız yapı, işin başladığı gün değişmeye başlar. Bir lider ayrılır, bir bağımlılık değişir veya küçük bir iş akışı aniden takımın yarısını içine çeker. İşte bu yüzden pek çok kurulum, ikinci haftaya gelindiğinde bozulur.
Bu altı uygulama, gerçeklik değiştiğinde iş akışlarınızı bozulmadan korur:
- Bağlantı noktalarını denetleyin. Durum kontrolleri genellikle tek bir iş akışının içinde, işlerin planlandığı gibi ilerleyip ilerlemediğini kontrol eder. Ancak, iş akışları arasındaki bağlantılar başarısızlığa yol açar ve bu gerçekten de olur. Bir ekip lideri, başka bir iş akışının dayandığı bir çıktıyı sessizce yeniden planlayabilir. Haftada bir kez, ekip liderlerinin birbirlerine ne zaman neyi teslim etmeleri gerektiğini yeniden teyit etmelerini sağlayın.
- Çalışma oturumları düzenleyin. Liderlerin, engelleri paylaşmak ve çatışmalar sertleşmeden çözmek için düzenli toplantılara ihtiyacı vardır. Bu, paydaşlara yönelik gösterişli bir durum güncellemesi değildir. Her lider, kendisini engelleyen unsurları, yaklaşan dönüm noktalarını ve zaman çizelgesinde neler değiştiğini belirtir. Proje yöneticisi, konuşmayı domine etmeden yönlendirir. Uzun süreli projeler için haftalık, hızlı ilerleyen etkinlikler için ise günlük toplantılar düzenleyin.
- Kişileri izleyin. Bir iş akışı tamamen sorunsuz görünebilirken, üç farklı iş akışına atanan bir kişi darboğaz haline gelebilir. İş akışlarını tek tek incelediğinizde bu çakışma görünmez. Tüm iş akışları aynı hafta içinde zirveye ulaşan mühendis veya tasarımcıları takip edin. Bu çakışmayı erken tespit etmek, takımın tükenmesini önler
- Akımlar arası bir risk kaydı tutun. Tek bir akım içinde yer alan riskler, liderin sorumluluğundadır. Geciken bir tedarikçi gibi birden fazla akımı etkileyen riskler ise projeleri mahveder. Her bir riskin hangi akımları etkilediğini belirten basit bir kayıt tutun. Her akımlar arası riske tek bir sorumlu atayın ve liderler arası senkronizasyon toplantılarında bu riskleri gözden geçirin.
- Önemli dönüm noktalarında sınırları gözden geçirin. Başlangıçta mükemmel görünen sınırlar, üç ay sonra yanlış olabilir. Önemli dönüm noktalarında resmi gözden geçirme noktaları oluşturun. Liderlerin, iş akışlarının, bağlantıların ve personel dağılımının hâlâ uygun olup olmadığını sormasını sağlayın. Sınırları her hafta değiştirmeyin, aksi takdirde takımlar odaklarını kaybeder. Veriler gerektirdiğinde sınırları değiştirin.
- Tamamlanan akışları kapatın. Her akış, gerektirdiği toplantılar ve görev devirleri nedeniyle zaman ve çaba gerektirir. Bazı akışlar, varlık gerekçesini oluşturan işten daha uzun süre devam eder. Bir akış, geriye sadece birkaç görev kaldığında, onu komşu bir akışa dahil edin. Akışı devam ettirmek için fazladan koordinasyon maliyeti ödemeyin. Tamamlanan bir akışı kapatmak, projenizi yalın tutar. Ayrıca, daha az akış olması, işlerin aksama ihtimalinin azalması anlamına gelir.
Farklı Sektörlerden 3 İş Akışı Örneği
İş akışları, pazarlama kampanyaları, yazılım geliştirme ve inşaat projeleri gibi çeşitli projelerde karşımıza çıkar; her seferinde aynı yapıya sahip olmakla birlikte, bağımlılık düzeylerinin katılık derecesi değişiklik gösterir. İşte bu iş akışlarının üç yaygın projede pratikte nasıl uygulandığına bir göz atalım.
1. Pazarlama kampanyası iş akışı
Diyelim ki bir şirket, bir ürünü çeşitli kanallardan piyasaya sürüyor. Kampanyayı bir kampanya yöneticisi yürütüyor. Dört iş akışı paralel olarak çalışıyor ve hepsi tek bir lansman tarihine odaklanıyor. İşte bu iş akışlarının dağılımı:
- İçerik üretimi: Blog yazıları, vaka çalışmaları, açılış sayfaları. Sorumlu: İçerik Pazarlama Müdürü
- Ücretli medya: Reklam içeriği, hedefleme ve bütçe. Sorumlu: Talep Yaratma Müdürü
- Etkinlikler: Web semineri kurulumu, konuşmacı koordinasyonu, tanıtım. Sorumlu: Etkinlik Uzmanı
- Satış destekleme: Sunum materyalleri, rekabet analizleri, demo senaryoları. Sorumlu: Ürün Pazarlamacısı
Kritik nokta: Ücretli Medya ekibi, içerik ekibi onaylanmış mesajları ve marka varlıklarını teslim edene kadar reklam tasarımını tamamlayamaz.
Bunu farklı kılan şey: Bağımlılıklar esnektir. Çoğu iş akışı, belirli süreler boyunca kendi başına ilerleyebilir. Dolayısıyla risk, katı bir zincirden kaynaklanmaz. Asıl risk, aşağı akıştaki her şeyi bloke eden bir veya iki mesaj aktarım noktasıdır. Takvime değil, geçiş noktalarına dikkat edin.
Kritik nokta: Ücretli Medya ekibi, içerik ekibi onaylanmış mesajları ve marka varlıklarını teslim edene kadar reklam tasarımını tamamlayamaz.
Bunu farklı kılan şey: Bağımlılıklar esnektir. Çoğu iş akışı, belirli süreler boyunca kendi başına ilerleyebilir. Dolayısıyla risk, katı bir zincirden kaynaklanmaz. Asıl risk, aşağı akıştaki her şeyi bloke eden bir veya iki mesaj aktarım noktasıdır. Takvime değil, geçiş noktalarına dikkat edin.
2. Yazılım geliştirme iş akışı
Şimdi, yeni bir müşteri odaklı uygulama geliştiren bir takımı hayal edin. Bir mühendislik lideri, bu çalışmayı farklı takımlar arasında koordine eder ve her takım bir katmandan sorumludur. Bağımlılık zinciri her iş akışından geçer; bu nedenle herhangi bir noktada yaşanan bir gecikme, sürüm tarihini erteler. İşler şu şekilde bölünmüştür:
- UX araştırması: Tel kafesler ve doğrulanmış kullanıcı akışları sunar
- Ön uç: Tasarımlara uygun bileşenler oluşturur
- Arka Uç/API: Mutabık kalınan bir sözleşme kapsamında eşzamanlı olarak hizmetler oluşturur
- Kalite güvencesi ve testler: Kabul kurallarına göre testler
- DevOps/kurulum: Staging ve canlı sitelere dağıtım yapar
Kritik nokta: Kalite Güvencesi (QA) ekibi, test döngülerini planlayabilmek için hem ön uç hem de arka uçtaki ilerlemelere görünürlük sağlamalıdır.
Bunu farklı kılan nedir: Agile kurulumlarda bu akışlar, ekiplerle eşleşir. Her ekip kendi sprint planlaması takvimini yürütür ve yalnızca özellik dondurma gibi paylaşılan dönüm noktalarında senkronizasyon yapar. Entegrasyon riski, sürecin sonunda birikir. Dolayısıyla dikkat edilmesi gereken noktalar, katmanlar arasındaki kod sözleşmeleridir.
3. İnşaat projesi iş akışı
Son olarak, bir ticari bina projesini ele alalım. Projeyi bir genel müteahhit yönetir ve sırası değiştirilemeyen iş kollarını koordine eder. Bu, tüm sektörler arasında en katı bağımlılık yapısıdır. Bu durum, iş devirlerini affetmez hale getirir. İş akışları, dönüm noktalarına sabit bir sırayla ulaşmak zorundadır:
- Şantiye hazırlığı: Temizleme, tesviye, temel hazırlığı
- Yapısal mühendislik: Çerçeve ve yük taşıyıcı işler
- Elektrik ve sıhhi tesisat: Yapısal çalışmaların dönüm noktalarına ulaşılana kadar başlayamayan kaba tesisat işleri
- İç mekan kaplama işleri: Onaylanmış kaba inşaat denetimini takip eder
- İzinler/uyum: Paralel olarak yürütülür, ancak fiziksel inşaatın başlamasını bloklar
Kritik bağlantı noktası: Elektrik ve sıhhi tesisat kaba inşaatına başlanabilmesi için, yapı işlerinin tanımlanmış kontrol noktalarını tamamlaması gerekir.
Bunu diğerlerinden ayıran özellik: İşlerin sırasını değiştiremezsiniz. Diğer ikisinde bulunan “sadece paralel olarak taşıyın” gibi bir kaçış yolu yoktur. Dolayısıyla bağımlılık haritalaması burada “olsa iyi olur” türünden bir şey değildir. Bu, ilk günden itibaren işin tamamını oluşturur. Bir devir teslim işleminin kaçırılması, sitenin durmasına neden olur.
ClickUp'ta İş Akışlarını Nasıl Kurarsınız?
ClickUp, işleri Alanlar, Klasörler ve Listeler halinde düzenler. Her iş akışı, kendine özgü durumlar, görevler ve belgelere sahip kendi Listesine sahiptir. Her görünüm aynı verileri paylaşır. Bir görevde bir değişiklik yapın veya bir tarihi değiştirin; bu değişiklik her yerde otomatik olarak yansıtılır.
İş akışları için özellikle etkili olan yöntemler:
- Hiyerarşi, iş akışı sınırlarıyla eşleşir. Proje için bir Alan veya Klasör oluşturun, ardından her iş akışı için bir Liste oluşturun. Her Liste kendi durumlarını alır (örneğin, mühendislikte "Yapılacaklar" → "İlerleme" → "Kod İncelemesi" → "Tamamlandı" akışı varken, pazarlamada "Taslak" → "İnceleme" → "Onaylandı" → "Yayınlandı" akışı vardır). İş akışı sınırı, Liste sınırıyla aynıdır; böylece ek bir yapılandırmaya gerek kalmadan kapsam sınırları içinde kalır.
- Bağımlılıklar akışlar arasında zincirleme yayılır. Gantt Şeması Görünümü'nde farklı Listelerdeki görevleri, bağımlılık çizgileri çizerek birbirine bağlayın. "Bağımlılıkları Yeniden Planla" seçeneğini etkinleştirin. Bir iş akışında bir devir teslim geciktiğinde, bir sonraki akıştaki tüm aşağı akış görevleri otomatik olarak kayar. Akışlar arasındaki bağlantı kopmak yerine görünür kalır
- Gösterge panelleri akışlar arası görünürlük sağlar: Listeye göre filtrelenmiş ClickUp gösterge panelleri oluşturarak her iş akışının durumunu, engellerini ve dönüm noktalarındaki ilerlemeyi tek bir ekranda görüntüleyin. Proje yöneticisi, güncelleme almak için beş farklı kişiyi takip etmekten kurtulur ve bunun yerine risk yönetimine odaklanır
- AI, iş akışları arasında özet oluşturur: ClickUp Brain, birden fazla listeden durumu aynı anda alır ve iş akışları arası bağımlılıkları ortaya çıkarır. Taslak, iş akışı liderleri için güncellenir. Doğal olarak tam bağlam bilgisine sahip olduğundan, paralel akışlar arasındaki koordinasyon yükü azalır
- Bağlantı noktalarını koruyan bir Süper Ajan. Projeye bir ClickUp Süper Ajanı atayın, o da bağlantı noktalarını sizin için izlesin. Bir devir teslim dönüm noktası geciktiğinde uyarı verir, yukarı akıştaki bir bağımlılık değiştiğinde alıcı akışın liderine bildirim gönderir ve tek akışlı durum kontrolünün gözden kaçırdığı akışlar arası riskleri ortaya çıkarır. Bu, haftalık bağlantı noktası denetiminin her zaman aktif olan sürümüdür; böylece gösterge paneli tamamen yeşile dönerse, başarısız bir devir teslimini sessizce gizlemez.
Sınırlamalar:
- Bir öğrenme süreci vardır. Trello veya paylaşılan elektronik tablolardan gelen takımlar, hiyerarşilerini (Alanlar → Klasörler → Listeler) önceden planlamalıdır. Bu yapıyı atlayıp her şeyi tek bir Listeye yığarsanız, iş akışlarının ayrımını tamamen kaybedersiniz. Çoğu takım, kendilerine uygun kurulumuna alışmak için bir veya iki hafta sürer.
- Basit projeler için ihtiyacınız olandan daha fazla bir araçtır. Tek bir küçük takımla üçten az paralel iş akışı yürütüyorsanız, "bağımlılık" sütunu içeren bir elektronik tablo işlerinizi daha hızlı ilerletmenizi sağlar
Aşağıdaki durumlarda atlayın: Projeniz tek bir takımdan oluşuyorsa, görev devri azsa ve iş akışları arasında gerçek bir bağımlılık yoksa.
En uygun kullanım alanı: Paralel iş akışları arasında gerçek bağımlılıklar bulunan ve bir akıştaki gecikmenin diğerlerine de açıkça görünür bir şekilde yansıması gereken çoklu takım projeleri.
Öngöremeyeceğiniz Dört Dikiş Arızası
Bariz hataları şimdiden fark edebilirsiniz. Bunlar arasında, sorumlu kişinin belirlenmemiş olması, organizasyon grafikinizin etrafına akışlar çizilmesi veya bir kişinin üç akışa birden yayılması sayılabilir.
Ancak bazı hatalar, işlenirken hata gibi görünmez. Her şey yolunda gidiyormuş gibi görünür. İşte gözünüzün önünde saklı olan dört sorun:
Gizlice alev alev yanan, tamamen yeşil görünen proje. Her lider, kendi akışını "planlandığı gibi ilerliyor" olarak işaretler. Gösterge paneli tamamen yeşil görünse de, lansman tarihi yine de ertelenir. Bunun nedeni, her bir akışın içindeki durumu ölçmeniz, ancak devir teslim sürecinin kendisinin ayrı bir durum bilgisi olmamasıdır.
Çözüm: Her bir devir teslim işlemine kendi durumunu atayın. Durumu "planlandığı gibi", "riskli" veya "blok" olarak işaretleyin. Ardından, bu durumu devralan takımın sorumluluğuna verin.
Kimsenin yazıya dökmemiş olduğu anlaşma. Birisi şöyle der: “Pazarlama departmanı dosyaları bize her zaman zamanında ulaştırıyor, bu yüzden resmi bir kurala ihtiyacımız yok.” İşte sorun tam da burada yatıyor. İnsanların yazıya dökmeyi atladıkları bağlantılar, kolay ve güvenilir olanlardır. Yazıya dökülmedikleri için, aksaklık yaşandığında otomatik bir uyarı gelmez.
Çözüm: Önce kolay devir teslimleri not edin. Bunu, tam da kimse bunların için endişelenmediği için yapın. Planlama için sadece iyi niyete dayanan bir bağlantı yoktur.
Toplantıların yükü. Görev devirlerini güvence altına alma telaşında, her bir bağlantı noktası için tekrarlanan bir toplantı ayarlıyorsunuz. Artık liderleriniz, işi yapmak yerine iş hakkında konuşmaya daha fazla zaman harcıyor. Bu da diğer hatalar kadar zaman kaybına neden oluyor.
Çözüm: Toplantı programınızı riske göre ayarlayın. Tek bir aksaklığın her şeyi durdurduğu sıkı zincirler, günlük olarak senkronizasyon gerçekleştirilmelidir. Bir süre sapma gösterebilen esnek bağlantılar ise yalnızca önemli dönüm noktalarında senkronizasyon gerçekleştirilmelidir.
Sözde paralel çalışma. Proje grafiğinde iki iş akışı yan yana yer alır. Birbirinden bağımsız görünürler. Ancak her ikisi de aynı kişinin karar vermesini beklemektedir. Ya da aynı yöneticinin bütçeyi onaylamasını. Kağıt üzerinde işler eşzamanlı olarak ilerler. Gerçekte ise iş akışları birbiri ardına ilerler.
Çözüm: Kaynaklarınızı kontrol ederek bu sorunu erken aşamada tespit edebilirsiniz. Yalnızca görevlere değil, ortak çalışanlara ve onaylayıcılara da bakın. Bir kişiyi ekipten çekmek iki iş akışını durduruyorsa, bu iş akışları aslında hiçbir zaman tam anlamıyla paralel olarak ilerlemiyordu demektir.
Ölçeklendirme sırasında kesintiye uğramayan iş akışları oluşturun
Sonuç veren projelerle sürüncemede kalan projeleri ayıran şey, bu akışlar arasındaki bağlantıların birileri tarafından tasarlanıp tasarlanmadığıdır. Yoksa bunların kendiliğinden çözüleceği varsayılmış mıdır?
Bu durumun gidişatı tahmin edilebilir. İlk hafta her şey harika görünür. Net iş akışlarınız, belirgin sahipleriniz vardır ve herkes hızlı ilerler. Dördüncü haftaya gelindiğinde, bir iş akışında alınan bir karar, başka bir iş akışındaki çalışmaları mahveder. Kimse bunu fark etmez çünkü takımların toplandığı noktadaki boşluğu kimse takip etmemektedir.
İşlerini zamanında teslim eden takımların planları daha iyi değildir. Onlar, her bir iş akışının diğerlerine karşı ne gibi yükümlülükleri olduğu konusunda daha iyi bir görünürlüğe sahiptir. Bu görünürlüğü günlük bir alışkanlık olarak görürler; çünkü bu yapı, ancak proje yöneticisi tarafından sürdürüldüğü sürece ayakta kalabilir.
Projelerinizde aynı son teslim tarihine doğru çalışan birden fazla takım düzenli olarak yer alıyorsa, ClickUp her bir iş akışını kendi listesinde yürütmenize olanak tanır. Bunlar arasında bağımlılıklar oluşturabilir ve her şeyi tek bir gösterge paneli üzerinden izleyebilirsiniz. Hatta yapay zeka kullanarak, insanları tek tek aramaya gerek kalmadan iş akışları arası durum bilgilerini alabilirsiniz. Tüm bunlar tek bir platformda gerçekleşir, böylece farklı araçları birbirine entegre etmek zorunda kalmazsınız.
ClickUp ile ücretsiz olarak başlayın.
Proje Yönetimi'nde İş Akışı Hakkında Sık Sorulan Sorular
İş akışı ile proje aşaması arasındaki fark nedir?
Bir aşama sıralıdır, oysa bir iş akışı paraleldir. Aşamalar, planlama, yürütme ve kapanış gibi bir projenin sırayla geçtiği aşamalardır. Buna karşılık, iş akışları projenin ömrü boyunca paralel olarak yürütülür. Mühendislik gibi tek bir iş akışı, her aşama boyunca aktif kalır. Aşamaları, işin ne zaman gerçekleştiğini gösteren unsurlar olarak düşünün. İş akışları ise zaman çizelgesi boyunca hangi yolun kime ait olduğunu gösterir.
Bir iş akışı, bir proje ve bir programdan nasıl farklıdır?
Aradaki fark, boyutlarına ve birbirleriyle nasıl bütünleştiğine bağlıdır. Bir program, birbiriyle ilişkili projelerin bir koleksiyonudur. Bir proje ise net bir son teslim tarihi olan tek bir girişimdir. Bir iş akışı, o projenin içindeki paralel bir yoldur. Bir iş akışı asla tek başına var olmaz. Yalnızca daha büyük bir proje hedefinin bir parçası olarak var olur. Bitiş tarihini ve ana hedefini üst projesiyle paylaşır. Öte yandan, ayrı bir projenin kendine ait bağımsız bir şartnamesi vardır.
PMBOK veya PRINCE2 gibi resmi standartlar "iş akışı" kavramını tanımlar mı?
Hiçbir önemli proje yönetimi standardı "iş akışı" kavramını resmi olarak tanımlamaz. Ne PMI'nin PMBOK Kılavuzu, ne APM Bilgi Birikimi ne de PRINCE2 kılavuzunda bu terimden bahsedilmez. Bu, gerçek hayattaki proje teslimatlarından doğan pratik bir terimdir. Bunu standartlaştıran bir düzenleyici kurum bulunmadığından, kullanım şekli şirketten şirkete farklılık gösterir.
İş akışı ile iş paketi arasındaki fark nedir?
Bir iş paketi çok daha küçüktür ve iş bölünme yapısı içinde yer alır. Resmi terimlerle ifade etmek gerekirse, iş paketi tahmin edilebilen ve atanabilen en alt düzeydeki görevdir. İş akışı ise çok daha geniştir. Birçok iş paketini ve birden fazla ş Akışını içerebilen, devam eden bir süreçtir. Basitçe ifade etmek gerekirse, iş paketleri çıktı birimleridir. İş akışları ise bu çıktıları bir araya getiren sahiplik birimleridir.
Bir kişi birden fazla iş akışını yönetebilir mi?
Bu mümkün, ancak gizli bir darboğaz yaratmanın en hızlı yoludur. Tek bir sorumlu atamanın asıl amacı, bir iş akışındaki devir teslimlerin sorumluluğunun net bir şekilde belirlenmesidir. Bir kişiyi üç iş akışına birden atarsanız, darboğaz o kişinin takvimine kayar. Böylece her iş akışı, sürekli görevler arasında geçiş yapan tek bir kişiyi bekler hale gelir. Bir kişiyi birden fazla iş akışına atamanız gerekiyorsa, bunu yalnızca küçük ve düşük riskli iş akışları için yapın. Ayrıca, aynı hafta içinde yoğunluğun zirveye ulaştığı zaman çizelgelerine de dikkat edin.
İyi bir iş akışı liderini ne yapar?
İyi bir iş akışı lideri, her karar için ana proje yöneticisine danışmak zorunda kalmadan kendi takımının önündeki engelleri kaldıracak kadar yetkiye sahiptir. Bu rol, iş akışının zaman çizelgesinden, teslim edileceklerden ve devretme süreçlerinden sorumludur. En iyi liderler sınırlarını korurlar. Devretme süreçlerini yakından izlerler ve bir bağımlılık sorunu ortaya çıktığında sorunları erkenden bildirirler. Rutin kararlar için izin istemek zorunda kalan bir lider, sadece isim olarak liderdir.