Bir Kahramana İhtiyacınız Var: Proje Yöneticisi

Bu makale, kalbinde bir uygulama fikri ve bankada biraz para olan gözüpek girişimciler için. Kokteyl peçetelerine karaladığınız diyagramlar tüm dünyayı alt üst edecek ve şimdiden evinize para dolu damperli kamyonlar gönderildi. Zamanında varmalarını sağlamak için, üretim döngünüzün sorunsuz işlemesi için bazı basit tavsiyeleri burada bulabilirsiniz.

Neden İlk Etapta Bir Proje Yöneticisine İhtiyacınız Var?

Douglas Crockford, “Bilgisayar programları, insanların yaptığı en karmaşık şeylerdir” diyor. Bu ismi daha önce duymamış olabilirsiniz ama bir programcı olarak oldukça ünlü. Şu anda PayPal'da kıdemli bir yazılım mimarıdır ve bu makalenin kapsamı dışında kalan her türlü harika teknolojiye öncülük etmiştir. Büyük projelerde çalışmak hakkında çok şey bilen biri.

Kendime gelince, 13 yıldır programlama yapıyorum ve şimdi bile, bir noktada, her proje beni keşfedilmemiş bölgelere götürüyor. Dışarıda o kadar çok farklı teknoloji var ki ve yeni teknikler o kadar endişe verici bir hızla tasarlanıyor ki, neler olup bittiğinin tamamen üstünde olduğumu asla hissetmiyorum. Her projenin kendine özgü zorlukları olsa da bazı sabitler vardır:

• Projenin zaman baskısı var.
• Bütçe istediğimden küçük.
• Müşterinin isteyeceğinden daha pahalıyım.
• Müşterinin istediği kadar mükemmel dinlemiyorum.
• Müşteri her şeyi istediğim kadar mükemmel açıklamıyor.

Bir bebek bakıcısına ihtiyacımız olduğu açık. Temel kuralları belirlemek, herkesi dürüst tutmak ve önemli hiçbir şeyi unutmadığımızdan emin olmak için birinin devreye girmesi gerekiyor. Birinin tüm taraflar arasındaki iletişimi kolaylaştırması gerekir.

Bu kişi, bu kahraman proje yöneticisidir.

Bu makaleyi yazmaya başladığımda Toptal proje yöneticileriyle sözleşme teklif etmiyordu, ama şimdi yapıyorlar. Sinerji! Aşağıdaki tavsiyeyi okuyan ve büyük bir fırsatı kaçırdıklarını fark eden güçlerin ancak hayal edebiliyorum.

Bir Programcı Neden İyi Bir Proje Yöneticisi Olmaz?

Proje Yönetim Enstitüsü tarafından verilen sertifikalar bir yana, bir proje yöneticisinin masaya getirebileceği en önemli şey deneyimdir. Sonuç olarak, birçok programcı oldukça iyi proje yöneticileri olur; teknik projelerde herkesten daha fazla deneyime sahibiz ve analitik zihinlerimiz bilgileri kataloglama ve somut hedefler belirleme konusunda usta.

Allah bilir, bize yeterince para ödüyorsun, bu yüzden seni başkasının zamanını da ödemeye zorlamaktansa kendi kendimizi idare etmemizi beklemek mantıklı görünüyor, değil mi?

Başlangıç ​​olarak, bize kodlamamız için para ödüyorsun.

Neye öncelik vereceğimize karar vermek veya bu hafta gerçekte ne kadar iş yapılacağını tartışmak için programlama sersemliğinden çıktığımızda, kod yazılmıyor. Ardından "bölgeye" geri dönmemiz en az 10 dakika sürer, özellikle de az önce yaptığımız konuşmadan dolayı stresliysek, ki bu büyük olasılıkla özellik önceliğini tartışıyorsak. Boo hoo, biliyorum, ama bu tamamen pahalı kaynakları en verimli şekilde kullanmakla ilgili.

En önemlisi, ağaçlar için ormanı gerçekten göremiyoruz. Bu makaleden başka bir şey almazsanız, lütfen şunu anlayın: Bütün günümü birkaç belirli hataya bakarak geçirdiğimde, beynim büyük resmin izini kaybediyor.

Bu hataları düzelttiğimde beynim beni ödüllendiriyor ve harika şeyler yaptığımı ve şimdi video oyunları oynayabileceğimi varsayıyorum. Biri bana ana sayfanın hala bozuk olduğunu hatırlattığında, bu tam bir sürpriz oluyor çünkü günü beynimi genel projenin çok küçük bir parçasının çok ayrıntılı bilgisiyle doldurarak geçirdim ve geri kalanını bir nevi unuttum. Beynim tam da böyle çalışıyor ve diğer birçok programcı da benzer bir psikolojik yapıya sahip.

Bir Müşteri Neden İyi Bir Proje Yöneticisi Olmaz?

O halde, biz programcılar proje yönetimiyle ilgili işleri halletmek için sorumluluk almak istemiyorsak, o zaman bu size, yani müşteriye düşmelidir. Bu senin paran. Bu senin vizyonun. Her neyse, sonuçta her şeyden sen sorumlusun.

Bununla birlikte, tabağınızda da çok şey var.

Pek çok müşteri, geri kalanımız gibi günlük işleri olan ölümlülerdir ve bazılarının erteleme veya unutkanlıktan muzdarip olduğu bile bilinmektedir. Bu sizi özellikle tanımlamasa da, lütfen tüm projeyi canlı tutmanın önemli işine geri dönebilmeniz için etrafınızda bir Profesyonel Hatırlatıcı bulundurma fikrini aklınıza getirin.

Benzer kapsamda bir teknik proje üzerinde çalıştıysanız veya denetlediyseniz, projeniz için gerçekten iyi bir yönetici olabilirsiniz. Eğer yapmadıysanız, ortaya çıkabilecek sorunları önceden tahmin edebilecek birinin değerini lütfen küçümsemeyin. Zaman tahminleri her zaman sadece tahminlerdir ve hatalar en uygun olmayan zamanlarda ortaya çıkma eğilimindedir. Etrafta sürecin hangi bölümlerinin en fazla ilgiye ihtiyaç duyduğunu veya muhtemelen gerekeceğini bilen birinin olması, başka bir (yalnızca yarı zamanlı olsa da) çalışanın maliyetine değer.

Örneğin kalite güvencesini (QA) alın. Herhangi bir projeden istediğinizi elde etmek için uygun QA şarttır ve asla hak ettiği ilgiyi görmez. İyi bir proje yöneticisi, sınırlı QA kaynaklarından en iyi şekilde yararlanacak ve ayrıca programcılarınızın sizin için kalite güvencesini sağlayacaktır. Bazen derinliğimizden çıkarız, bazen de hata yaparız. Programcınızın sadece boş bir gün geçirip geçirmediğini veya aslında proje için uygun olup olmadığını belirlemek için denetleyici rolünde teknik olarak yetkin bir kişiye ihtiyacınız var. Personel sorunlarından erken kurtulmak, projeniz için ölüm kalım arasındaki fark anlamına gelebilir.

Son olarak, müşteri olarak siz bile bazen biraz kontrole ve/veya dengeye ihtiyaç duyarsınız. Bunu yazmam zor, çünkü biz bilgisayar programcıları açık sözlü doğamızla pek tanınmayız. Müşterinin her şeyin birinci öncelik olduğu ve kesinlikle yapılması gereken her şey olduğu konusunda kararlı olduğu birçok projede çalıştım. Bunun kesinlikle doğru olduğundan hiç şüphem olmasa da, bu müşteriler ne yazık ki bir gün içindeki saat sayısı üzerinde kontrole sahip değillerdi. İstedikleri ve/veya hak ettikleri olumlu sonucu elde edemediler ve müşteri, iş yükünü değerlendirmek ve dikkatli ama kararlı bir şekilde işleri kontrol altında tutmak için bir proje yöneticisine yetki vermiş olsaydı, bu sonucun önlenebileceğini düşünüyorum. . Konu sizin fikriniz ve hatta paranız söz konusu olduğunda ve siz ya da ben ağlayıp bağırmamız bilgisayar umurunda değilken, çoğu teknik projenin gerektirdiği tarafsız kararlar vermek zordur. (Bunun doğru olduğunu biliyorum çünkü birçok kez denedim.)

Teknik Bir Projeyi Yönetmek için Eksik Teknikler Listesi

İster önceki 1000'lik kelimeyi görmezden gelip projenizi kendiniz yönetmeye karar verdiyseniz, ister birini işe alıp süreç hakkında daha fazla bilgi sahibi olmak istiyorsanız, bu liste size yardımcı olacaktır. Hiçbir zaman (resmi olarak) bir proje yöneticisi olmadım, bu nedenle herhangi bir proje yöneticisinin hangi araçları kullanacağını söyleyemem, ancak bu tekniklerin hepsinde iyi bir başarı elde ettim:

kilometre taşları

Yeni bir projeye başlarken, çoğu insan sezgisel olarak projeyi biraz daha yönetilebilir parçalara ayırmanın önemli olduğunu bilir, her bir parça birkaç haftadan birkaç aya kadar değişen bir çalışma aralığındadır. Projenin başında, bu kilometre taşlarını oluşturmak için bir başlangıç ​​toplantısı yapmak iyidir. Onlara nasıl ulaşacağınız konusunda biraz belirsiz olmak sorun değil, en önemli şey, herkesin projeyi daha iyi anlamasından faydalanmak için her dönüm noktasından sonra kontrol etmeye devam etmek ve projenin kilometre taşlarının hala olduğundan emin olmaktır ( kabaca) başlangıçta inanıldığı gibi aynı boyutta.

Zaman Tahminleri

Biz programcılar tahminlerden kesinlikle nefret ederiz çünkü yanlış olacaklarını ve bize karşı kullanılacaklarını biliyoruz. Yanlış olmaları sorun değil çünkü tanım gereği bir avuç bilinmeyene dayanıyorlar. Ayrıca bize karşı kullanılmaları da sorun değil çünkü işlerimiz oldukça rahat ve arada sırada kamçının kırılmasının bir zararı yok.

Bu nedenle, yeni bir dönüm noktasında her çalışma başladığında tahmin istemekten çekinmeyin. Bu özelliğin ne kadar süreceğine dair kaba bir tahminle birlikte her ana özellik için bir veya iki satır beklemeniz gerekir. Genelde iyimser bir tahminde bulunurum, sonra ikiye katlarım. Çoğu zaman, bu fazladan zaman, görünmeyen tuzaklara neden olur.

Kullanıcı hikayeleri

Kullanıcı hikayeleri, uygulama içindeki tek bir işlevsellik parçasının kısa açıklamalarıdır. Önemli özelliklerin bir kaydı olarak kullanışlıdırlar ve bir lokma büyüklüğünde olmalı, bir indeks kartına sığabilmeli ve genellikle küçük bir çizim eşlik etmelidir. Daha da önemlisi, müşterinin istediği ile programcının bilgisayara söylemesi gereken arasında bir köprü görevi görürler. Bunlar, siz müşteri için birkaç dakika içinde devre dışı bırakacak kadar basit, ancak biz programcılar için dişlerimizi batıracak kadar ayrıntılı.

Kullanıcı hikayeleri hakkında bazı hızlı bilgiler için, Mountain Goat Software ve Roman Pichler'in bu eğitimlerini yüksek kaliteli ve özlü buldum. Çevik proje yönetiminin tüm felsefesi hakkında daha fazla bilgi için, bu Toptal blog gönderisini deneyin, Paul Barnes tarafından yazılan Çevik Proje Yönetimine Nihai Giriş.

Kompozisyonlar (Mockup'lar)

Bu, bir tasarımcıya neden ihtiyaç duyduğunuzla ilgili bir makale değil çünkü çoğu müşterinin bunu zaten anladığını hissediyorum, ancak tekrar etmekte fayda var çünkü programcılarınızın önünde somut, iyi düşünülmüş bir tasarımı tokatlarsanız muazzam üretkenlik kazanımları göreceksiniz. Her tasarım kararı vermemiz gerektiğinde, “bölgeden” ayrılmamız gerekiyor ve her seferinde geri dönüp bir şeyi değiştirmemiz gerekiyor çünkü bize nihai taslak sağlanmadı, peki, hesabı sen yap… Ben. Şikayet etmiyorum, çünkü tasarım eğlenceli, ama benim deneyimime göre, bu kaçınılabilir, ekstra faturalandırılabilir saatlerin 1 numaralı kaynağı.

Çoğu tasarımcı, Adobe Photoshop, Adobe Illustrator veya Sketch'te kompozisyonlar olarak da bilinen kompozisyonlar sağlar. Kendiniz yapıyorsanız, Balsamiq veya InVision gibi sayısız çevrimiçi araçtan birini kullanabilirsiniz. Kompozisyon, bitmiş ürünle aynı renklere ve stillere sahip olmak zorunda değildir (çünkü bunlar daha sonra kolayca değiştirilebilir), ancak lütfen tüm UI öğelerinin mevcut olduğundan ve hesaba katıldığından emin olmak için fazladan zaman ayırın.

Stand-up Toplantıları

Uzun toplantılar bazen kaçınılmazdır, ancak gerçekten programcılarınızı aşırı yüklemek veya gereğinden fazla zamanlarını almak istemezsiniz. İki buçuk saatlik bir toplantıda söylenen her şeyi hatırlamamı bekleyen müşterilerim oldu; fena halde hayal kırıklığına uğradılar. Bir stand-up toplantısı genellikle 15 dakika ile sınırlıdır ve bu süre boyunca ayakta durmak gelenekseldir. Ayakta duran yönün, herkesin katılmasını sağlamanın yanı sıra toplantıyı kısa tutması gerekiyor.

Stand-up'lar sırasında, herkes kısa bir durum raporu sağlamak için bir daire içinde dolaşarak tüm ekip üyelerini birbirlerinin ilerlemeleri hakkında güncel tutar. Stand-up'lar hakkında daha fazla bilgiyi ExtremeProgramming.Org'da bulabilirsiniz. Hepiniz uzaktan çalışıyorsanız ve herkesin her gün Skype'a girmesini istemiyorsanız, stand-up'lara alternatif olarak 15Five gibi eğlenceli bir aracı deneyebilirsiniz. 15Five, ekip üyelerinin kendileri için uygun olduğunda girdilerini sağlamalarına izin verir ve daha derinlemesine yanıtlar almak için onlara anket soruları soracaktır.

Biletleme Sistemi

Herkes yapışkan notlar ve Google Dokümanlar sistemini (herkesin görevleri farklı renklerle vurgulanmış olarak) sürdürebilirken, bu gerçekten gerekli değildir; birçok kişi sizin için bu sorunu çözmeye çalıştı. Basecamp ve Trello, kullanım kolaylıkları ile ünlüdür, Pivotal ise tüm "çevik" felsefeyi çok kaygan bir pakette özetlemeye çalışır. Seçiminiz ne olursa olsun, iyi bir biletleme sistemi en azından şunları yapmanızı sağlar:

• Görev oluştur
• Öncelik ve son tarih atama
• Görevleri ve alt görevleri bağlama
• "Tamamlandı" veya "başarısız test" gibi farklı çözünürlükler atayın
• Belirli bir kullanıcıya atanan tüm görevleri göster

Bir proje yöneticisi size aynı gün içinde vadesi dolacak 40 parlak kırmızı en öncelikli bileti gösterdiğinde, projenin bu kuş bakışı görüntüsünün değerini gerçekten anlayacaksınız.

Kaynak kontrolü

Projenizin sürüm kontrol sistemindeki koda asla bakmayabilirsiniz, ancak kaynak kontrolü (veya sürüm oluşturma) elimizdeki en önemli araçlardan biri, hayal edilebilecek en büyük yedekleme sistemidir.

Çoğu modern proje Git kullanır, ancak bazen bir süredir var olan projeler üzerinde çalışırken Subversion (SVN) ile karşılaşırsınız. Github, sınırsız halka açık depoları ücretsiz olarak barındırmanıza izin verir (artı, dünyanın açık kaynaklı projelerinin çoğunu içerir), Bitbucket ise sınırsız özel depo barındırmanıza izin verir ve bu nedenle ticari projeler için tercih edilen seçimdir.

Hangi sürüm kontrol sistemini seçerseniz seçin, herhangi bir şey olması durumunda kodumuzu uzaktan depolar, ayrıca koda her "taahhüt ettiğimizde" izler ve bizi ne üzerinde çalıştığımızı açıklayan küçük bir mesaj yazmaya zorlar. Bu, farklı geliştiricilerin birbirlerinin kodunun üzerine yazmasını engeller, belirli bir zaman diliminde yapılan tüm değişiklikleri görmemizi sağlar ve hemen yayınlanmayan özellikleri depolamak için yeni kod dalları oluşturmamıza olanak tanır. Hatta belirli bir kod satırından kimin sorumlu olduğunu ve ne zaman işlendiğini gösteren “suçlama” adında bir komutu bile var.

Kaynak kontrolü en büyüğüdür.

Test Odaklı Geliştirme

Bu nispeten pahalı bir uygulamadır, yani bütçenin birkaç serbest çalışanla sınırlı olduğu projelerde sıklıkla kullanılmaz. Bu nedenle, bir girişimci girişimci olarak, bunu yapmadığınız için kendinizi çok kötü hissetmemelisiniz, ancak bu fikri önünüze salmalıyım çünkü böceklere karşı nihai savunmayı sağlıyor. Temel olarak, programcılarınız, uygulamanın belirli bölümlerinin belirli, tahmin edilebilir ve tekrarlanabilir şekillerde çalışmasını sağlayan testler (küçük kod blokları) yazmak için ek değerli saatler harcar. Örneğin, “login” butonuna tıklandığında, içinde kullanıcı adı alanı olan bir açılır pencerenin açıldığını iddia eden bir test yazabilirim.

Testlerin güzelliği, onları bir kez yazdıktan sonra hepsini tek bir komutla çalıştırabilmemdir. Yazılmış 200 testim varsa, bu 200 özelliğin hiçbirinde herhangi bir hata bulunmadığından emin olmak için uygulamanın yeni bir sürümünü yayınladıktan sonra bunları çalıştırabilirim. Mükemmel değil, ancak hatasız (en azından bug-lite) uygulamaları garanti etmeye alabildiğimiz kadar yakın.

Sarmak

Proje yönetimi hakkında bildiğim tek şey bu. Bunun ne kadarının Proje Yönetim Enstitüsü'nde gözden geçirileceğinden emin değilim, ancak bunların hepsi son on yılda web projeleri üzerinde çalışarak edindiğim şeyler. Tabii ki, deneyiminden yararlanmak için birini işe almanızı tavsiye ederim, ancak bu, yapabileceğiniz bir şey olmasa bile, bu bilgiyi yararlı bulacağınızı umuyorum. Bu projede nihai otorite siz olacaksınız, bu yüzden onun iç işleyişini ne kadar çok anlarsanız, onu zafere götürme olasılığınız o kadar artar.