Proje Yönetimi Ekipleri Oluşturma ve Ölçeklendirme (Lodestar Digital’dan Brian Kessman ile)

Deşifreyi Okuyun:

Podcast'lerimizin deşifresini bir yazılım programı kullanarak oluşturmaya çalışıyoruz. Bot her zaman yüzde 100 doğru çalışmadığı için lütfen yazım hatalarını mazur görün.

Ben Aston:

Dinlediğiniz için teşekkürler. Ben Ben Aston ve bu, dijital proje yöneticisi podcast'i. Bugün Brian Kessman konuğum ve bugün, kendisi için yazdığı bir ajans bünyesinde dijital proje yönetimi ekipleri oluşturma ve ölçeklendirme makalesi hakkında konuşacağız. Ancak makaleniz hakkında konuşmaya geçmeden önce Brian, bize biraz kendinizden bahseder misiniz?

Brian Kessman:

Elbette. Öncelikle podcast'inize konuk olduğum ve blog yazısını yazma davetiniz için teşekkür ederim; bunu yapmaktan keyif aldım. Ben Chapel Hill, Kuzey Carolina'da yaşıyorum. Aslen New Yorkluyum; Long Island'da büyüdüm ve birkaç yıl Manhattan'da yaşadım, ancak şimdi buraya yerleştik. Bugün Lodestar Digital adlı bir danışmanlık şirketi işletiyorum. Kısaca yaptığım iş bu.

Ben Aston:

Harika. Bize Lodestar'dan biraz bahseder misiniz? Lodestar ne yapıyor?

Brian Kessman:

Lodestar bir danışmanlık grubu. Odak noktamız, dijital ve yaratıcı ajansların dijital hizmetlerini oluşturmasına ve iyileştirmesine yardımcı olmak. Yaptığım işler kapsamında ajanslara, daha iyi dijital işler sunabilmeleri amacıyla organizasyonel veya ekip yapısı değişiklikleri gibi konularda yardımcı olabiliyorum. Dijital proje yönetimi gibi yeni dijital uzmanlık alanları oluşturmak, iş akışını ölçeklendirmek veya yalınlaştırmak da buna dahil. Bazen çevik uygulamaları hayata geçiriyorum; ancak yaratıcı alan için uyarlanmış bir versiyonunu. Hizmet kategorilerimiz temel olarak bunlar.

Ben Aston:

Harika. Şimdi bu tür işleri danışmanlık yoluyla yapıyorsunuz. Dijital proje yönetimine ve ajanslara bu konuda yardımcı olmaya nasıl başladınız? Geçmişiniz nedir?

Brian Kessman:

Proje yönetimine yıllar önce teknoloji danışmanlığı yaparken başladım. Teknoloji danışmanlığından önce zaten reklamcılık alanındaydım; ancak teknoloji danışmanlığı yapmak için bir süre ara verdim ve proje yönetimiyle orada tanıştım. Daha sonra ajans dünyasına döndüğümde bu becerileri uygulayabildim. Son on yedi veya on sekiz yılın büyük bölümünde dijital ajanslarda ya da geleneksel ajanslarda dijital odaklı rollerde çalıştım.

Deneyimimin genel kapsamı bu. Ancak özellikle son on yılda ajans süreçlerini, teslimatını, web sitesi ve uygulama geliştirmesini iyileştirmeye odaklandım. Çalıştığım ajanslar genellikle küçük veya orta ölçekliydi. Büyüdüklerinde, diğer ajanslarda gördüğüm benzer kalıpları fark etmeye başladım. Bu sorunların bazılarını daha önce çözmüş olduğum için bugün ajanslara aynı konularda yardımcı olmaya karar verdim. Günümüzde çok daha fazla dijital iş yapılıyor ve bence birçok ajans hâlâ zorlanıyor. Bazıları dijitali ilk kez uygulamaya veya genişletmeye çalışıyor, bazılarıysa büyüyen dijital ajanslar olarak bu işi daha iyi yapabilmek için yardıma ihtiyaç duyuyor.

Ben Aston:

Geleneksel ajansların dijitalleşmesine ve ölçeklenmesine yardımcı olmaktan söz ediyorsunuz. Bununla ilgili karşılaştığınız tipik zorluklar neler? İnsanların yaşadığı ve dinleyicilerimizden bazılarının kendini içinde bulabileceği yaygın sorunlar hangileri?

Brian Kessman:

Yaratıcı bir ajansta karşılaşılan birçok zorluğun temelinde, uzmanlık alanlarının birbirinden kopuk çalıştığı yapı bulunuyor. İş hâlâ bir ekipten diğerine devrediliyor veya üzerinde çalışması gereken sonraki ekibe aktarılıyor. Bu durum eskisi kadar kötü olmasa da özellikle büyük geleneksel ajanslarda hâlâ yaşanıyor. Ben onlara, disiplinler arası ekip modelini sunmaya çalışıyorum. Burada sabit veya geçici olarak görevlendirilmiş, farklı uzmanlıklardan oluşan ekipler birlikte çalışıyor; daha fazla şeffaflık ve herkesin rolü hakkında daha iyi bir anlayış oluşuyor. Bu da herkesin dijital farkındalığını ve beceri setini artırıyor.

Örneğin bir tasarımcı web sitesi tasarımı üzerinde çalışıyor olabilir; ancak dijital odaklı değilse duyarlı düzen gibi konuları dikkate almayabilir. Tasarım dijital tasarımcıya veya geliştiriciye aktarıldığında, bazı düşünceler hesaba katılmadığı için ciddi miktarda yeniden çalışma gerekebilir.

Ben Aston:

Bu çok tanıdık geliyor. Daha önce hiç web sitesi tasarlamamış birinin çılgınca düzen ölçüleri kullanması ve sizin “Bir dakika, web sitelerini böyle yapmıyoruz” demeniz gibi. Bazen bu tür ayrıntılar gözden kaçabiliyor.

Brian Kessman:

Ya da “İşte reklam panosu tasarımı” deniyor ama bunun yönlendirdiği açılış sayfası hakkında hiç düşünülmemiş oluyor.

Ben Aston:

Evet, reklam panosunu bir düğmeyle açılış sayfasına dönüştürmek yeterli, değil mi? Dijital proje yönetimi konusuna gelelim. Ajanslara daha iyi işler yapmaları için danışmanlık veriyorsunuz. Araç setinizde hangi araçlar var? Son zamanlarda keşfettiğiniz ve “Bu harika, herkes kullanmalı” dediğiniz bir şey oldu mu?

Brian Kessman:

Bağlandığım şeylerden biri oldukça yeni. Envision'ın yakın zamanda yayımladığı Designbetter.co adlı bir kaynak; bilmiyorum, aşina mısınız?

Ben Aston:

Hayır, sanırım görmedim.

Brian Kessman:

İnsanların tasarım uygulamalarını geliştirmelerine yardımcı olmaya çalışıyorlar. Bu yalnızca dijital tasarım değil; iş sorunlarını çözmeye yönelik tasarım. En iyi tasarım liderlerinden harika podcast'ler, blog yazıları ve e-posta kursları var. Harika ürünlerin ve ekiplerin nasıl oluşturulacağını anlamak için inanılmaz bir kaynak. İçerik gerçekten zengin. Şu sıralar buna bayılıyorum ve mümkün olduğunca çok şey dinliyorum. Herkese öneriyorum; hangi disiplinde olursanız olun faydalı. Ancak bu daha çok eğitim ve gelişimle ilgili. Benim araç setime gelince, işim danışmanlık yapmak ve mutlaka dijital proje yönetimi yürütmek olmadığı için...

Ben Aston:

Evet.

Brian Kessman:

Atölyelere, görüşmelere ve anketlere büyük ölçüde güveniyorum. Bir ajans içindeki ilişkilerin nerede bozulmuş olabileceğini göstermek için paydaş haritalama gibi yöntemler kullanıyorum. Ardından olağan süreç haritalama ve beceri açığı analizi geliyor. Blog yazısında paylaştığım beceri matrisini ve benzeri araçları kullanıyorum.

Ben Aston:

Güzel. Araçlar konusuna dönersek, herkes araçları sever. Ajansların daha dijital odaklı hâle gelmesine veya ekipler hâlinde birlikte çalışmaya başlamasına yardım ederken, bu geçişi kolaylaştıran araçlar buldunuz mu?

Brian Kessman:

Sanırım daha çok iş akışı yönetimi yazılımlarından söz ediyoruz. Seçenek çok fazla; ajansın kendini en rahat hissettiği araca bağlı. JIRA  yazılım ürünü geliştirme için olağanüstü; birçok ajans onu yaratıcı işler için de kullanıyor. Ancak asıl konu, iş konusunda şeffaflık oluşturmak ve iş birliği yoluyla iş akışını daha düzenli hâle getirmek.

Ben Aston:

Makalenize geçelim. Brian'ın dijital proje yönetimi ekiplerini ölçeklendirme ve bunu doğru yapma üzerine makalesini yayımladık. Henüz okumadıysanız mutlaka göz atın. Dijital proje yönetimi ekibinizde lider konumunda olsanız da olmasanız da harika bir kaynak. Dijital proje yönetimi ekibi oluşturmak için adım adım bir rehber. Makalede bir PM ekibini ölçeklendirmenin beş P'sinden söz ediyorsunuz: amaç, insanlar, ortaklıklar, süreç ve performans.

Amaç, dijital proje yönetimini neden ölçeklendirdiğinizi kararlaştırmak için paydaşları bir araya getirmekle ilgilidir. İnsanlar, doğru becerilere, deneyime ve ücret düzeyine sahip doğru kişileri bulmaktır. Ortaklıklar, kurum içi ilişkileri ve proje yöneticilerinin başarılı olmasını sağlayacak ekip yapısını ifade eder. Süreç, tutarlı olmayı ve değer sunmayı sağlayacak süreç araçları ve şablonlarıdır. Performans ise iyileştirmeleri zaman içinde izlemek ve uygulamaktır.

İlk olarak amaca, yani dijital proje yönetimi ekiplerinin neden var olduğuna bakalım. İnsanların ajans içinde dijital proje yönetimi görevini üstlenmek üzere görevlendirildiğini sıkça görüyoruz. Slack ekibimizde insanlar “Dijital proje yönetimi rolü verildi; şimdi ne yapmam gerekiyor?” diye soruyor. Çoğu zaman bu, bir şeyler ters gittikten sonra verilen ani bir tepkidir. Dijital projeler diğer projeler gibi yürümüyor olabilir veya projeler sürekli bütçeyi aşabilir ve geç teslim edilebilir. Sonra da bir suçlu aranır ve birine “Sen DPM ol” denir. Ajans içinde dijital proje yönetiminin “neden”i konusunda nasıl bir çeşitlilik görüyorsunuz?

Brian Kessman:

Bence farklı amaçlardan çok, insanların amacı nasıl ifade etmeyi seçtiği değişiyor. Temelde amaç her zaman aynı. Asıl farklılık, bir grubun amacını açıkça tanımlamak için zaman ayırıp ayırmadığı. Tanımlanmamış bir DPM rolüne getirildiğinizde ne yapmanız gerektiğini bilemezsiniz; başkaları da sizden ne beklediğini bilmez. Yardım ve destek alamazsınız ve başarıya ulaşmanız için gerekli koşullar oluşturulmamış olur. Bu nedenle, biri amacı tanımlamak için zaman ayırdığı sürece özünde büyük bir farklılık olduğunu düşünmüyorum.

Ben Aston:

Bir dijital proje yönetimi ekibi kurarken mevcut durumla yeni dönem arasında bir denge kurmak gerekiyor. Başlangıçta ekip küçük oluyor. Bir ekip kuran kişinin kaldırabileceğinden fazlasını üstlenmediğinden emin olması ve kendini tamamen bunalmış hâlde bulmaması için ne önerirsiniz?

Brian Kessman:

Bütün adımlar birlikte çalışan bir sistemdir. Amacı gerçekten tanımladıysanız sonraki adım kolaylaşır: uzmanlaşma. Rolünüzde sağlayacağınız belirli değere veya sonuçlara odaklanmanız gerekir. Tek bir uzmanlık alanına odaklanırsanız çok fazla yük üstlenmezsiniz. Örneğin PM'ler için verdiğim amaç, planlama yoluyla riskleri ve sorunları azaltarak başarılı projeler üretmektir. Odaklanmanız gereken sonuç başarılı projedir; değer ise riskleri ve sorunları azaltmaktır. Geliştirmeniz gereken uzmanlık da proje planlamasıdır.

Ben Aston:

Sonra insanlardan söz ediyorsunuz. Ekibe doğru kişinin liderlik etmesinin kritik olduğunu belirtiyorsunuz. Liderleri nasıl belirlersiniz? Bir PMO'ya liderlik etmek isteyen kişilerin geliştirmesi gereken beceriler nelerdir?

Brian Kessman:

Bu, teknik becerilerle sosyal becerilerin bir dengesidir. Günlük taktik işleri yapabilmek için deneyiminiz ve yaşadığınız zorluklardan edindiğiniz dersler var mı? Ancak liderlik rolü açısından daha önemli olan sosyal becerilerdir. Ekibinize ilham verebilir ve onları motive edebilir misiniz? Onlara yardım ederken saygılarını kazanmanız, ilham verici olmanız ve günlük işlerinde empati kurmanız gerekir. Bu, hizmetkâr liderlik anlayışına benzer: işi onlar adına yapmak yerine onların işi yapmasına yardımcı olursunuz. Önlerindeki engelleri kaldırır, öğrenmeleri ve gelişmeleri için gerekli desteği sağlarsınız. Harika bir lider olmanın önemli bir parçası budur.

Ben Aston:

Ekip liderinin zamanının yüzde 50'sini veya daha fazlasını mentorluk ve desteğe ayırması gerektiğinden söz ediyorsunuz. Bunu yapmayan liderler için mentorluk ve destek ne anlama geliyor?

Brian Kessman:

Onlarla konuşmak için hazır bulunmakla başlar. Neyi dinlemeniz gerektiğini biliyorsanız zorlandıkları, ancak kendilerinin farkında olmadığı alanları tespit edebilirsiniz. Haftalık veya aylık bire bir görüşmeler yapmak, her PM ile ayda bir kahve içmek ya da öğle yemeği yemek faydalıdır. Ayrıca toplantılarına, örneğin başlangıç veya işe alıştırma toplantılarına katılıp nasıl davrandıklarını gözlemleyebilirsiniz. Sonra gözlemlerinize dayanarak geri bildirim verirsiniz.

Bu, yazıda sözünü ettiğim beceri matrisiyle de bağlantılıdır. Giriş veya orta seviye bir PM'in sahip olması gereken becerileri tanımladıysanız, gözlemleriniz yoluyla beceri düzeyini haritalayabilirsiniz. Örneğin bir toplantıda gerçek bir örnek üzerinden “Beceri matrisinde bu puanı vermemin nedeni bu; altı ay sonra burada olmanı bekliyorum ve oraya ulaşman için şunları yapacağız” diyebilirsiniz. Mentorluk fikrinin önemli bir parçası budur.

Ben Aston:

Dijital proje yöneticileri için mesleki gelişim açısından neler önerirsiniz? PMP, Scrum Master veya başka sertifikaların faydası var mı?

Brian Kessman:

Ben proje yönetirken PMP sınavına çalıştım ancak sınava girmedim. Sertifikanın özgeçmişimde bir satır daha oluşturacağını düşündüm ve o noktada buna ihtiyaç duymadım. Sertifikalı Scrum Master ve Ürün Sahibi eğitimlerine katıldım ve bunları çok değerli buldum. Herkesin bunu yapması gerektiğini düşünüyorum. Çevik yönteme aşina değilseniz, yapılan işe bakmak için tamamen farklı bir yol sunuyor. Sektörün yöneldiği yer de bu. Ajansların tamamı bunu veya çevikliğin uyarlanmış bir versiyonunu değerlendirmeli.

Ayrıca günlük işinizi yapmanıza yardımcı olacak şekilde başka disiplinleri bir ölçüde öğrenin. PM'ler kurumdaki neredeyse her role dokunur; tasarım ve geliştirme disiplinlerini anlamanız gerekir. Kodlama konusunda elinizi kirletin veya bahsettiğim Envision podcast'ini dinleyin. Böylece dokunduğunuz alanları daha iyi anlayabilir, daha iyi iş birliği yapabilir ve daha iyi destek olabilirsiniz.

Ben Aston:

PM'ler olarak ekiplerimizin ne yaptığını ne kadar iyi anlarsak, önümüzdeki engelleri o kadar iyi tespit edebiliriz. Strateji, kullanıcı deneyimi, tasarım, geliştirme veya kalite güvencesi olsun, ekiplerin yaptığı iş hakkında farkındalık sahibi olmak; sorunları ortaya çıkmadan önce öngörmemizi ve doğru soruları sormamızı sağlar.

Brian Kessman:

Strateji tarafı son derece önemli. PM'ler genellikle tasarımcılar ve geliştiricilerle yakın çalışır, ancak strateji ekibiyle aynı yakınlıkta çalışmaları daha nadirdir. Strateji ekibiyle biraz daha yakın çalışabilirseniz projelerinize nasıl baktığınız ve onları nasıl yönettiğiniz konusunda büyük ilerleme sağlayabilirsiniz.

Ben Aston:

Stratejik olmak, projenin temel olarak sonuç üretmesini sağlamak açısından çok önemli. Doğru yerlerde tasarruf edebilir ve projeyi doğru şekilde geliştirebilirsiniz. Daha önce sözünü ettiğiniz beceri matrisine dönelim. Bir kurum, örneğin proje planlama becerisinin farklı seviyelerde nasıl görünmesi gerektiğine nasıl karar verir?

Brian Kessman:

Bu, her ajans için farklıdır. Projelerin karmaşıklığına ve sahip olduğunuz müşteri türlerine bağlıdır. Bazı ekiplerde giriş seviyesi PM yoktur; yalnızca kıdemli PM'ler işe alınır. Bu nedenle ekip çalışması gerekir. “Yaptığımız iş türleri neler, hangi sorun alanlarımız veya fırsatlarımız var, hangi boşlukları doldurmamız gerekiyor ve her rol bunları nasıl ele almalı?” diye konuşmalısınız. Becerileri tanımlamak ortaklaşa yürütülen bir çalışma olmalıdır. Herkes bunun olumsuz değerlendirme için değil, gelişim ve hedef belirleme için kullanıldığını anladığında süreç çok daha iyi işler.

Ben Aston:

Bütçe dahilinde doğru kişileri işe alma konusunda ne önerirsiniz? İnsan kaynakları genellikle istediğiniz kıdemli kişiyi işe almak için bütçe olmadığını söyler.

Brian Kessman:

Beceri matrisi bu yüzden çok önemlidir. Her PM türünün veya seviyesinin neler yapabileceği konusunda ortak bir anlayış oluşturmalısınız. İnsan kaynakları veya finans ekiplerini de matrise dahil ederseniz, kıdemli PM'e neden ihtiyaç duyduğunuzu proje zorluklarına ve gerekli becerilere dayanarak gösterebilirsiniz. Her seviyeye bir ücret aralığı atamak, piyasadaki rekabetçi ücretleri önceden tanımlamak ve kurumun bu yapıyı kabul etmesini sağlamak işe alım sırasında güçlü bir dayanak oluşturur.

Ben Aston:

Üçüncü P ortaklıklar. Ajans içindeki ilişkilerden ve genel ajans süreci için RACI matrisinden söz ediyorsunuz. RACI matrisinin ne olduğunu ve ne kadar ayrıntılı olması gerektiğini açıklar mısınız?

Brian Kessman:

RACI matrisi oluşturmak çok fazla iş ve tüm disiplinler arasında iş birliği gerektirir. Sürecinizin her adımını istediğiniz ayrıntı düzeyinde ele alırsınız; ancak gereğinden fazla planlama yapmamak gerekir. RACI; sorumlu, hesap verebilir, danışılan ve bilgilendirilen anlamına gelir. Her adımda kimin sorumlu, kimin hesap verebilir, kimin danışılan ve kimin bilgilendirilen olduğunu bir ızgara üzerinde işaretlersiniz. Yalnızca bir hesap verebilir kişi olabilir. Hesap verebilir kişi, işin doğru şekilde ve doğru beklentilerle tamamlanmasını sağlar. Sorumlu kişiler işi yapanlardır; danışılan ve bilgilendirilen kişiler ise bilgi alışverişinde bulunduğunuz kişilerdir.

Örneğin tasarımcı bir şey oluşturmaktan sorumludur; ancak vereceği karar kapsamı veya zaman çizelgesini etkileyebilir. Bu durumda proje yöneticisine danışmalıdır. Küçük başlayın ve ek netliğe ihtiyaç duydukça zaman içinde geliştirin.

Ben Aston:

Özellikle bir ajans dijitalleşirken herkes her adımda bilgilendirilmek veya kendisine danışılmak isteyebilir. Projeyi herkesin fikrini sormak zorunda kalmadan nasıl yalınlaştırırsınız?

Brian Kessman:

Bu aslında iyi bir sorun; herkes işine önem veriyor ve projeye yatırım yapıyor demektir. Ancak her toplantıda yirmi kişinin bulunması mümkün değil. İş akışı yönetimi yazılımı burada şeffaflık sağlar. Alınmakta olan veya alınmış bir karara ilişkin mesajlar paylaşılabilir. İnsanlara e-posta güncellemeleri göndererek bilgilendirme sürecini otomatikleştirebilirsiniz. Böyle bir araç, gereksiz katılımı ve sürecin şişmesini önler.

Ben Aston:

Süreç için standardizasyon hakkında konuşalım. Bir PM sabahları hizmet tasarımı, öğleden sonraları ise web sitesi yeniden tasarımı projesi üzerinde çalışabilir. Farklı proje türleri arasında anlamlı olacak kadar genel, ancak her proje türüne uyarlanacak kadar esnek bir süreci nasıl oluşturursunuz?

Brian Kessman:

Bu kısmen ajansın stratejik kararıdır. Ajans yeterince uzmanlaşırsa farklı proje türlerinde tekrarlanabilir bir süreç oluşturmak kolaylaşır. Ancak uzmanlaşmasanız bile projelerinizde kalıplar olacaktır. İlk adım, proje türlerini kategorilere ayırmak ve bu kalıpları belirlemektir. Tekrarlanan şeyleri standardize edebilir, ardından bunları optimize edip yalınlaştırabilirsiniz.

Ben Aston:

Benim faydalı bulduğum yaklaşım, ajansın yapabileceği en karmaşık proje türünü seçip standart süreci onun çevresinde oluşturmak. Daha küçük proje türleri, bu genel sürecin alt kümeleri hâline gelir. Böylece her yeni projede insanların kafası karışmaz, bütçe aşımı ve gereksiz görevler azalır.

Brian Kessman:

Katılıyorum.

Ben Aston:

Son olarak performans. Bunu ne sıklıkta incelemeliyiz ve sürekli iyileştirme yaptığımızı nasıl ölçmeliyiz?

Brian Kessman:

Küçük başlayın. Odaklanmak istediğiniz bir veya iki konu seçin. Örneğin ortalama proje tamamlanma süresi, zamanında teslim oranı veya kârlılık gibi temel performans göstergeleri kullanılabilir. Bunları nasıl ölçeceğinizi belirleyin. Yumuşak hedefler için kurum içi ve müşteri anketlerinden yararlanabilirsiniz. Kurum içinde üç ayda bir anket yapmak uygun olabilir: “Sürecimizi ve çalışan deneyimini geliştirme konusunda nasıl ilerliyoruz?” Sonuçlara göre bir sonraki çeyrekte neyi değiştireceğinize karar verin.

Müşteri anketleri de çok güçlüdür. Tavsiye skoru, müşterinin sizi başkasına önerip önermeyeceğini sorar ve nitel geri bildirim için bir alan sunar. Böylece yalnızca kurum içinde gelişmekle kalmaz, müşterilerinize sunduğunuz değeri de artırırsınız.

Ben Aston:

Müşterilerin bu anketleri doldurmasını nasıl sağlarsınız? Anketler kısa olsa bile insanlar anketlerden hoşlanmıyor.

Brian Kessman:

Anketlere yalnızca güvenmemek gerekir. Müşterilerle konuşmalı ve onlara bir ankete veri sağlayan kişiler değil, ilişkiye yatırım yapan bir ortak olduğunuzu hissettirmelisiniz. Yanıt vermiyorlarsa arayabilirsiniz. Anketin mobil cihazlarla uyumlu olması da temel bir gereklilik. Sonuçta bu, ilişkinin gücüne bağlıdır.

Ben Aston:

Brian, katıldığınız için çok teşekkürler. Ekip oluşturma ve ölçeklendirme üzerine yaptığımız bu konuşma çok önemliydi.

Brian Kessman:

Ben teşekkür ederim Ben, eğlenceliydi.

Ben Aston:

Siz de konuşmaya katkıda bulunmak isterseniz gönderiye yorum yapın ve topluluk bölümüne giderek Slack ekibimize katılın. Bir sonraki bölüme kadar dinlediğiniz için teşekkürler.