Ürünler artarken ürün yöneticileri azalıyor
(kitemaker.co)- Ürün ekiplerinde kaç PM bulunması gerektiğine dair tartışma, Airbnb’nin ürün yönetimi organizasyonunu yeniden yapılandırması ve PM olmadan büyüyen startup örneklerinin ardından daha da büyüdü
- PM sayısı arttıkça, ürünün iş sonuçlarından çok proje yönetimi ve yol haritası güncellemelerine zaman harcanan bir yapı oluşabilir
- Deneyimli tasarımcı ve mühendislerin olduğu ekiplerde PM işleri mutlaka tam zamanlı olmak zorunda değildir; ekip başına 1 PM modeli de duruma göre yeniden değerlendirilmelidir
- İlk PM işe alımı, kurucunun tüm önemli ürün kararlarına dahil olmasının zorlaştığı noktada, genellikle 50~100 kişi ölçeğinde ve 3~5 ürün ekibi seviyesinde düşünülür
- PM sayısını artırmak tek başına ürün odaklı bir organizasyon yaratmaz; aksine tasarımcı ve mühendislerin sahip olması gereken ürün sorumluluğunu zayıflatabilir
PM sayısını azaltıp ürün sorumluluğunu genişleten yapı
- PM ihtiyacı tartışması, Airbnb’nin ürün yönetimi organizasyonunu yeniden yapılandırması ve PM olmadan da büyüyen startup örneklerini ele alan yazılardan sonra daha da hareketlendi
- Birçok şirkette PM’ler, ürünü iş hedeflerine göre optimize etmekten çok proje yönetimi, yol haritası güncellemeleri gibi işlerle günlerini dolduruyor
- Genel olarak PM sayısı, ürün ekibi sayısından daha az olmalı; her ekibe 1 PM koyan yapı, ürün ve ekip koşullarına göre yeniden ele alınmalı
- Ürün işi çoksa ve ekip junior ağırlıklıysa, tek bir ekip için adanmış bir PM gerekebilir
- Deneyimli mühendis ve tasarımcıların olduğu ekiplerde PM rolünün tam zamanlı olması gerekmeyebilir ya da olmaması daha doğru olabilir
- Bir startup’ta ilk PM’i işe almak için doğru zaman, kurucunun tüm önemli ürün kararlarına dahil olmasının zorlaştığı andır
- Genellikle organizasyon büyüklüğü 50~100 kişi, ürün ekibi sayısı 3~5 olduğunda bu bir ölçüttür
- Genel ürün stratejisi zaten net olmalı; PM bu stratejiye dayanarak daha alt seviyedeki yön ve karar alma süreçlerine katılmalıdır
- İlk PM için junior PM ya da CPO yerine senior PM daha uygundur
- Aday, organizasyon büyüdükçe CPO rolünü üstlenebilir; ancak kurucu fiilen ürün sorumlusu rolünü sürdürmelidir
Ürün odaklı ekip kurmanın pratik yolları
- Ürün sorumluluğu tek bir PM’de toplanmamalı; tasarım ve mühendislik de kullanıcıyı ve ürün bağlamını doğrudan anlamalıdır
- Tasarımcılar ve mühendisler ürünün şekillenmesine aktif katılmalı ve ayrıntılı ürün tartışmalarına liderlik etmelidir
- PM; UX, wireframe, ilerleme takibi, standup yürütme, PRD/şartnameyi tek başına yazan kişi olmamalıdır
- PM’in odağı ürün vizyonunu ifade etmek, doğru problemi seçmek, ürün yönünü korumak ve iş ihtiyaçlarıyla hizalamaktır
- Michael Seibel’in “Guide to product development” yazısı, Social Cam’de bu yaklaşımın uygulandığı örnekle bağlantılıdır
- Ekip, bağlamı ve kararların dayanaklarını aktif biçimde paylaşmalıdır
- Tasarım ve mühendislik de kullanıcı geri bildirimlerine erişebilmelidir
- Problem çözme PM merkezli değil; ürün, tasarım ve mühendisliğin iş birliği olmalıdır
- Ürün odaklı ekip kurmak için uygulanabilecek yöntemler dört başlıkta özetlenebilir
- Birlikte başlamak: Ticket veya şartname yazmadan önce, çözümü belirlemeden önce tasarım, mühendislik ve ürün/kurucu birlikte tartışarak ilerleme biçimini ve planı hizalar
- Herkesi kullanıcıyla temas ettirmek: Kullanıcı araştırmasına ve kullanılabilirlik testlerine doğrudan katılmalarını ya da video yayını, Lookback gibi araçlarla kullanıcıların ürünü nasıl kullandığını görmelerini sağlar
- Ekip yönetim biçimine dikkat etmek: Performans kapatılan ticket sayısı veya story point ile ölçülürse ekip iyi ürün yerine ticket kapatmaya göre hareket eder
- PM araçlarını kullanmamak: Kullanıcı geri bildirimi, içgörüler, veri, şartnameler ve yol haritası ayrı PM araçlarına hapsolursa tüm ekibin ürün bağlamına erişmesi zorlaşır
- Ürün geliştirme doğası gereği öngörmesi zor bir iştir; dağıtımın kendisinden çok, iş üzerinde etki yaratacak doğru şeyleri dağıtmak daha önemlidir
- Büyük ölçekli ürün odaklı şirketlerde PM çok önemlidir; ancak ihtiyaç duyulan PM sayısı kolayca abartılabilir ve PM sayısındaki artış doğrudan ürün odağının artacağı anlamına gelmez
1 yorum
Hacker News yorumları
Mühendislik yöneticisi ya da fonksiyonel organizasyon lideri olarak ürün yöneticileriyle epey uzun süre çalıştım; ayrıca orta ölçekli bir teknoloji şirketinde iç ürünler için geçici PM rolünü de üstlendim
Ürün yönetimi şirketin yaptığı işler içinde en önemli alanlardan biri bence. Ama iş gerçekten zor ve yetkinliği düşük PM'ler bundan uzaklaşıp, mühendislik ekibini “yönettikleri” iddiasıyla mikroyönetime ya da şirket içi siyasete kaymaya daha yatkın oluyor
Mühendislik ve ürün organizasyonlarının ayrı komuta zincirlerine bölündüğü yapılarda bu sorunu ele almak zor; sorunu yukarı taşısanız bile oradaki bant genişliği doğal olarak çok sınırlı oluyor. EM açısından bakınca bu tür PM'ler en iyi mühendisleri yıpratıyor ve sonunda onların ayrılmasına sık sık yol açıyor
Şu anda en iyi yaklaşımın, her takıma mini-CEO tarzı bir PM yerleştirmek ve teknik açıdan yeterli değilse onu bir mini-CTO ile eşleştirmek olduğunu düşünüyorum. Böylece siyasetin araya girme alanı çok azalıyor, ekip çalışması için de çok daha fazla alan açılıyor
Bulunduğum en başarılı ekiplerde özel bir ürün rolü yoktu; tüm kararları geliştiriciler veriyordu
Şu an en iyi yaklaşımın, geliştiricilerin huzur içinde bir şeyler üretebilmesi için teknik olmayan kişileri ve yarım yamalak teknik kişileri de onların yolundan çekmek olduğunu düşünüyorum
Benim gördüğüm şey, insanların kendi seçeneklerini savunması ve destek toplamaya çalışması. İnsanların şikâyet ettiği o siyaseti hiç görmedim. Belki de şanslıyımdır
Siyaset, teknik olarak yanlış olup daha ikna edici biçimde savunulan şey mi demek? “Siyaset” nedir? Yoksa hâlâ yeterince üst bir pozisyonda değil miyim, senior principal olmama rağmen
Bu yazıyı ve bu konuyu analiz etmeye çalışan birçok kişi temel bir unsuru kaçırıyor: teşvikler
Birçok geliştirici, teknolojinin kendisine; yani kod yazmaya, karmaşık teknik problemleri çözmeye ve verimli çözümler üretmeye daha çok tutkuyla bağlı. Terfi, prim ve takdir gibi resmî ödüller de çoğu zaman teknik başarılarla bağlantılı oluyor
Bir geliştirici müşteri araştırmasına 40 saat harcarsa, bu ekip genelinde fayda sağlayan yeni bir kimlik doğrulama çözümü geliştirmek kadar resmî olarak tanınmayabilir ya da ödüllendirilmeyebilir
Bu dinamiği değiştirmek, geliştiricilere ürün yönetimine daha fazla zaman ayırmalarını önermekle olmaz. Kurumun neye değer verdiğine ve nasıl ödüllendirdiğine dair sistemsel bir değişim gerekir
Teşvik yapısını teknoloji merkezliden kullanıcı merkezliye çevirmek, orta ve üst kademe yöneticilerin rolünü ciddi biçimde etkiler. Böyle bir değişim, onların rol ve sorumluluklarının temelini sarsar ve kontrol ile etki kaybına yol açabilir
Bu yüzden böyle bir değişim, orta ve üst kademe yöneticilerden örtük ama güçlü bir direnç görebilir. Bu kişiler organizasyon içinde çoğu zaman ciddi siyasi güç ve yerleşik çıkar sahibidir
Her zanaat işi, onun gerçek hayata değdiği anda öğrenilir. Bir yönetmen kurgu odasında filmi bin kez izleyebilir ama onu gerçek seyirciyle ilk kez birlikte izlediği tek sefer, o bin saatten daha fazla şey öğretir
Bir marangoz bütün hafta mobilya yapıp tatmin olabilir ama asıl an, o mobilya müşterinin odasına konduğunda gelir. Yazılım da aynıdır
Bir yazılım mühendisinin kullanıcıyı önemsemeye başlaması için neyin iyi, neyin berbat olduğuna dair doğrudan geri bildirim alması ve mümkünse bunu kendi gözleriyle görmesi gerekir
Düzgün bir yazılım mühendisinin, işini iyi yapma konusunda belli bir gururu vardır. Bu gurur sadece koda, commit geçmişine ya da başka soyut kavramlara bağlıysa ve bunun gerçek kullanıcı için ne kadar iyi çalıştığıyla hiç temas etmiyorsa, en başta nasıl önemsemeye başlayabilir ki
Yazıyla neredeyse alakasız ama blog yazılarının kapak görseli olarak AI görselleri kullanma yönündeki güncel akım beni gerçekten delirtiyor
Bir yazıyı yazarken aklında belirgin bir kapak görseli yoksa, bilgisayarın saçmalamasını indirmen için benim bant genişliğimi harcamasan keşke
AI görsellerinin çok değerli bir araç olduğunu düşünüyorum ve buna olumlu bakıyorum. Ama bir sayfadaki tek görsel AI görseliyse bunun gerçekten iyi bir nedeni olmalı; sadece boşluk doldurmak için olmamalı
Hele ki üretilen görseldeki insanların parmak sayısını bile düzgün kürate edemediysen daha da olmamalı
Görselin amacı bir his aktarmak. Yazıdaki soyut kavramları biraz daha dokunulabilir kılmak
Eskiden bu amaca uygun görselleri internette bulup kullanıyordum. Artık bunları DALL-E ile kendim üretebiliyorum ve çoğu zaman çok daha iyi oluyor
Bu görsel yazıyı tamamlamalı. Nasıl yazının metni bilgi, his ve kavram aktarmaya çalışıyorsa, görsel de bunun bir kısmını yapmalı
Kimse tüm büyük ırk gruplarını içeren insanların daire şeklinde durup birbirine tuhaf şekilde gülümsediği, uncanny valley hissi veren bir görsel görmek istemiyor
Bu tuhaf ve ruhsuz kurumsal görsel modası, AI üretimi patlayıcı biçimde popüler olmadan önce de başlamıştı
Muhtemelen arama motoru optimizasyonuyla ilgili bir tür inanç yüzünden
Aynı anda sadece iyi görünmeleri gerekir
Ama bunda biraz komik bir taraf var. Blog şablonu bir görsel alanı istiyor diye insanlar düşünmeden oraya bir şey dolduruyor. Bu çok zorsa sıradan bir stok fotoğraf buluyorlar, o da zorsa bu kez bilerek sıradan bir stok fotoğraf üretiyorlar
İlhamdan ve zevkten yoksun AI çöpü yakında her şeyi kaplayacak gibi görünüyor
PM’lerle ilgili sorunların çoğu, sahada gerçekten koşturmamaları. İyi bir PM, mühendislik ile kullanıcılar arasındaki boşluğu sürekli kapatmalıdır
Bu geri bildirim döngüsü tekrarlanmalıdır
Ama çoğu kişi yalnızca doküman dünyasında çalışabileceğini sanıyor; roadmap dokümanları üretip, bitmeyen check-in’ler ve dırdırla paydaş hizasını korumaya çalışıyor. Sonuçta yaptıkları şey daha çok “proje yöneticiliği” oluyor
Gereksinim toplama, bug’lar yüzünden öfkeli kullanıcılara yanıt verme, haftalık durum toplantıları, önceliklerle ilgili kötü haberleri iletme; hepsi için kıdemli geliştiriciler ya da teknik liderler gönderiliyordu. Meşgul olduğunu söyleyip çevik ritüellerin çoğunu da atlıyordu. Hiç JIRA ticket’ı yazmadı ya da düzeltmedi; bunun teknik organizasyonun yöneteceği bir iş olduğunu söylüyordu. Diğer iki teknik ekipte de PM’lik anlayışı aynıydı
Teknik liderler ve kıdemli geliştiriciler, ilk haftadan itibaren bu PM’in iyi olmadığını anlamıştı; ama biz hepimizden daha uzun süre kaldı ve ancak 4 yıl sonra işten çıkarmalarda ayrıldı
Çevik kültüne kapılmış yönetim katmanı, böyle insanlara kolayca kapılıyor ve bir organizasyonu yıllarca raydan çıkarabiliyor. Teoride PM’in paydaşı kullanıcıdır; pratikte ise onu işe alan üst yönetimin egosunu parlatmak oluyor
Üst yönetim, çevik danışmanlar ve PM’ler arasında kendi kendini güçlendiren kapalı bir döngü oluşabiliyor
Her iki durumda da bunlar rekabetçi olmayan ürünler ve çoğu zaman sonlandırılana kadar oldukları gibi kalmaları muhtemel. Buna rağmen şirketler PM ve PO atayıp SCRUM benzeri yapılar kuruyor, sanki devrim yaratacak ürünler geliştiriyormuş gibi davranıyor. Buna acil işler ve sonuç baskısı da dahil
Böyle ortamlarda PM’lerin ve PO’ların, iyi bir ürün ya da kullanılabilir bir ürünle pek ilgilenmeyip, şirket içi terfi merdivenini tırmanmak için siyasete odaklandığını sıkça gördüm
Özellikler ve iyileştirmeler açısından rastgele yürüyüş gibi görünen parçalı ürünler üretirken bile, projeyi kendilerini yönetim ya da müşteriler nezdinde iyi gösterecek yöne sürüklüyorlar
60’larda, 70’lerde, 80’lerde işler nasıl yapılıyordu bilecek yaşta değilim; ama o zamanlar SCRUM/PM/PO yok gibiydi. Geçmiş on yıllara kıyasla üretkenliğin ciddi biçimde yavaşladığı ve bugün büyük ölçüde geçmişte üretilmiş şeylere yaslandığımız yönündeki karamsar söylem, benim algımla oldukça örtüşüyor
Son dönemde başka PM’lere mentorluk da yapıyorum. Herkesle paylaşılan roadmap’ler var ama benden başka kimsenin bir daha bakmadığı gerçekten çok fazla doküman ve spreadsheet üretiliyor. Bunların, çalışıyor görünmek için yapıldığı hissine kapılıyorum ve bu alışkanlığı kırmaya çalışıyorum
Teknik ürün yönetimini güçlü biçimde savunmamın nedeni, sorunu basitleştirince bazı PM’lerin çok yüksek bir soyutlama seviyesinde sıkışıp kaldığını düşünmem. Ekiple her gün teknik ayrıntılar konuşamadıkları için sonunda proje yönetimi ile ürün yönetimi arasında garip bir gri alanda kalıyorlar
Bu kendi başına sorun değil ama ürün kararlarını vermek isteyen bir HIPPO sendromu varsa, zamanın çoğu kendini savunmaya ve yukarı doğru yönetmeye gidiyor
PM’ler çok dayak yiyor; bazen haklı olarak, ama sonuçta işleri oldurabilmek için şirket içi siyaset yapmak zorunda kaldıkları da çok oluyor
Harika bir PM yalnızca vizyon ya da plan üretmez, uygulamayı ve iterasyonu da sürükler. Plan, bütünün %20’sidir
Birlikte çalıştığım en iyi ürün yöneticisi, sadece çok yetenekli bir insandı; uygulama karmaşıklığını anlıyor, gerekirse bizzat yapabilecek biri gibi duruyor ve aynı zamanda iş ihtiyaçlarını da kavrıyordu
Mühendislik yöneticisi olmadan da şirkete değer katan biriydi
Ne yazık ki ürün yöneticilerinin çoğu, sadece o koltukta oturan insanlardan ibaret. İster takdir ister sorumluluk olsun üstüne alan bir kapı bekçisi ve çoğu zaman kendi çıkarı neredeyse hiç risk altında değil
Genel olarak, ayrı bir ürün yönetimi organizasyonu varsa bunun yanlış yapıldığına inanıyorum
Benim yer aldığım en iyi ve en başarılı ürünlerin hepsinde ürün sahipliği, işi gerçekten yapan insanlardaydı. Mühendisler, tasarımcılar, müşteri başarı ekipleri gibi
Bir mühendis olarak destek nöbetine girmeyi severdim; çünkü bu, yaptığım işle onu her saniye kullanan gerçek insanlar arasındaki soyutlama boşluğunu kapatıyordu
Nadiren gerçekten net değer katan PM’lerle de çalıştım; o durumların hepsinde bu kişiler, isteseler iyi birer mühendis de olabilecek insanlardı
Bunun ana nedeni şu: PM ya da takım içinde o rolü üstlenen kişi aynı mühendislik yönetim zincirine raporluyorsa, her şey sonunda mühendisliğin ihtiyaçlarına doğru kayıyor
İşi gerçekten ileri taşıma potansiyeli yüksek, kesinlikle gerekli özellik çalışmaları bile; teknik borç ya da altyapı işlerinin bir şekilde insanları hep engellediği gerekçesiyle sonunda öncelikte geri düşüyor. Bazen bu gerçekten doğru seçim olabilir, ama böyle kararların sağlıklı alınabilmesi için eşit konumdaki iki organizasyon arasında bir gerilim gerekir. Mühendisliğin parçası olduğunda bu genelde iyi işlemiyor
Elbette sektörümüzün üzücü gerçeği şu ki, ayrı bir PM organizasyonu “iş için iyi olanı” sahiplendiği gerekçesiyle mühendislik organizasyonundan daha fazla güç elde edebiliyor. Buna bir de süreç ve framework’leri takip etmeyi bilen ama kendi ürününü ya da kullanıcılarını gerçekten anlamayan PM’ler eklenince tam bir kâbus çıkıyor
Ben buna oranlar açısından bakıyorum
Frontend mühendisleriyle backend mühendislerinin oranı nedir? Mühendislik yöneticileriyle bireysel katkı sağlayıcıların oranı? Teknik yazarlarla toplam mühendis sayısının oranı? Ürün yöneticileriyle toplam mühendis sayısının oranı?
Sonra da etkiyi en üst düzeye çıkarıp müdahale ve mikro yönetimi en aza indirmek için bu oranları dikkatle ayarlamaya çalışırım
Bu oranların gerçek sayıları organizasyondan organizasyona değişir, ancak müdahale hissediliyorsa ya da “nasıl” kısmı yeterince mühendislerin kendilerinden çıkmıyorsa oranlar değişmelidir
İnsan yöneticisi veya ürün yöneticisi başına düşen mühendis sayısını artırarak onların bu şekilde araya girememesini sağlamalı, dahil olacakları işleri önceliklendirmeye zorlamalı ve mikro düzeyden çekilip yönteme dair özerkliği mühendislere geri vermeliyiz
Aynısı QA, junior mühendisler, senior mühendisler, mimarlar, IK personeli, başkan yardımcıları ve satışçılar için de geçerli
20 yılı aşkın süredir ürün yönetimi yapıyorum ve burada söylenenlerin çoğuna katılıyorum. Oranlar önemli
CPO’lar, PM orduları yönetip imparatorluk kurmaya kolayca kayabiliyor. Organizasyon, PM’lerin tek bir sayfa gibi müşteri deneyiminin ufak parçalarını sahiplendiği, buton tıklanma oranlarını optimize ettiği ama ürün stratejisine ya da vizyonuna anlamlı bir katkı sunmadığı bir hale geliyor
Ürüne gerçekten sahip olmadan ürün yöneticisi olmak zor
PM’ler, şu anda çoğunun olduğundan çok daha fazla iş hedeflerine odaklanmalı. Kullanıcı sorunlarını çözmek gerekli ama yeterli değil. Bu çözümün şirket için de değer üretmesi gerekir
Bunu mümkün kılmak için ürün sezgisi güçlü mühendislik ve UX ortakları şart
Daha kötüsü, “kolayca değiştirilebilir” geliştiriciler dış kaynak şirketlerden geliyor. Artık geliştirmeyi müşteriden daha fazla yönetim katmanıyla yalıtmak gerekiyor
GDP’yi artırmanın harika bir yolu
Örneğin ERP, Oracle Fusion Apps, WorkDay, SAP gibi şeylerle uğraşıyorsanız tek bir PM tüm ürüne sahip olamaz. Bunun yerine birkaç özelliği sahiplenir ve her bir özellik başlı başına karmaşıktır; ERP’nin doğası gereği bunlar genellikle birçok farklı ürünle entegrasyon da içerir
Yine de PM’in anlamlı bir şeye sahip olması gerektiği yönündeki genel fikre katılıyorum
Geliştirici ve geliştirme yöneticisi olarak birlikte çalıştığım en iyi ürün yöneticileri “nasıl” kısmına neredeyse hiç karışmadı
Elbette backlog’da epik seviyesinde ticket’lar oluşturabilirlerdi, ama onun altındaki seviyelerde sana ve projedeki diğer kişilere işi tamamlayabileceğinize güvenirlerdi
Sorun şu ki organizasyonun bunu desteklemesi gerekiyor. Çoğu şirkette en çok ilgi gören işler vizyon ya da büyüme odaklı olanlar değil, en çok gürültü çıkaranlar oluyor
Ve bu tür işler, ürün sorumlularının ya da yöneticilerin gitmek istediği yönle doğrudan çatışıyor
“Nasıl”ı anlamayan PM, yani ürününün nasıl çalıştığını bilmeyen PM en kötüsüdür
Birlikte çalıştığım en iyi PM’lerin teknik geçmişi vardı
İnsanlar başkasının alanına girmeye kalktığında sonuç her zaman felaket olur. Bu iki yönde de geçerli. Mühendisler “nasıl?” açısından çok düşündükleri için “neden?” ve “ne?”de zayıf kalırlar; ürün yöneticileri de “ne?”yi ya da “neden?”i netleştirmek için gerekmediği sürece “nasıl?”dan uzak durmalıdır
Bir denge olmalı. PM/PO’nun da temel bir kavrayışı olmalı. Bilgisayarı bile zor kullanan biri olmamalı
İyi PM’ler bile çevrelerinde çok fazla vasat PM varsa epey kısıtlanabiliyor
Birçok Fortune 500 şirketiyle çalışırken epey bozuk kültür gördüm
Böyle yerlerde PM’ler çoğu sorunu ellerindeki tek araç olan toplantı ile çözmeye çalışıyor. Terfi teşvikleri de toplantı ne kadar büyükse kişinin o kadar önemli görünmesini sağlıyor
Yüzlerce saatlik çapraz fonksiyonlu ekip toplantılarına girdim; gerçekten çalışan sadece 1-2 kişi oluyor, genelde PM baştan sona konuşuyor, 10-20 kişi ise sessizde bekleyip en sonda varlıklarını kanıtlar gibi onay veriyor
Sonuç olarak mühendis ekiplerinin motivasyonu düşüyor, gerçek teknik iş yapacak zamanları kalmıyor ve ortada kod araştırması ya da anlayış yokken o anda tahmin ya da taahhüt vermeleri isteniyor
PM’in teknik tasarımı, rakamları ya da “point”leri hoşuna gitmediği için reddettiğini; mühendislerin de bilinmeyen bir PM estetiğini tatmin etmek için aynı fikri farklı bir “ticket” olarak yeniden paketlemek zorunda kaldığını da gördüm
Anlayış eksikliği ve anlamsız statü gösterisi ritüelleri yüzünden tüm projelerin gecikip raydan çıktığını gördüm
Buna karşılık harika PM’lerle de çalıştım; onlar ekipleri bu saçmalıklardan koruyup doğru hedeflere odaklanmalarını sağlıyordu. Böyle insanlar çok değerli, ilk gruptakiler ise aynı ölçüde zararlı
Bu, PM sayısından bağımsız olarak, birlikte çalışmak istediğim PM tipine dair bir yorum.
Sektörde dört şirkette çalıştım; 40 kişiden az çalışanı olan startup'lardan JP Morgan Chase'e kadar deneyimim var.
“Teknik” insanların “teknik olmayan” insanlardan daha zeki olduğu fikrini reddediyorum. Aslında bir mühendis olarak ben de sık sık ayrıntılara gömülüp büyük resmi kaçırıyorum ve bir PM'in beni oradan çekip çıkarmasına çoğu zaman ihtiyaç duyuyorum.
Yine de benim deneyimime göre, bir mühendis olarak birlikte çalışması en kolay PM'ler, kodla gerçekten az da olsa temas etmiş kişiler oluyor.
Çok büyük bir şey olması gerekmiyor. Yıllar önce HTML ve CSS ile bir web sitesi yapmış olmak, geçici bir SQL sorgusu yazmış olmak ya da yüksek lisans sırasında bir Python dersi almış olmak yeterli.
Yeter ki PM'in, kod yazmanın ne tam anlamıyla kesin bir bilim ne de bütünüyle bir sihir olmadığını anlamasını sağlayan bir şey olsun.
Bu tür PM'ler birlikte çalıştıkları mühendisleri savunuyor ya da en azından iş gereksinimleriyle mühendislik gerçekleri arasında denge kurmaya çalışıyor.
Hiç teknik maruziyet olmadan PM olan kişiler ise daha “iş odaklı” olma eğiliminde; işin belirli bir anında tam olarak gereken şey bu olabilir ama her zaman değil. Bir mühendis olarak, benim bakış açımı da daha iyi anlayan biriyle çalışmak isterim.
Hiç alınmış değilim :p