Tag Archives: Project Management

Agile(Çevik) Olmanın Öncesi ve Ötesi

7 May

30 Yıldan fazla geçmişi 20 yıllık şöhreti ve 10 Yıldır da herkesin gözdesi olmayı başarmış bir kavram Agile yani Çeviklik. Aslına bakarsanız güneşin doğduğu topraklarda yazılıyor bu hikayenin özü. Toyota Üretim Sistemi kurmak için en iyisini yapmaya çalışıyor, israfı ve hatayı önlemeye ve de KAIZEN ile sürekli iyileştirmeye başlıyor bundan neredeyse 60-70 yıl önce. Batı geliyor bunu alıyor herkesin benimseyeceği bir hale LEAN yani YALIN isminde bir tanımlamaya sığdırıyor. Üretimde bu yaklaşımlar yıllar yılı hem kullanılıyor hem geliştiriliyor. Kısıtlar teorisi, KANBAN ,kartlarla durum takibi, POKE YOKE derken. Üretim 5S, Toplam Kalite Yönetimi gibi teknikler uygulayıp kendini çok iyi yerlere getiriyor. Teknolojinin gelişimi ile bugün Endüstri 4.0 konuşulurken aslında süreçler ve sistemler bu mantıkla tasarlanmaya ve iyileştirilmeye devam ediyor.

Peki üretim sürecindeki gibi bir süreç olan proje yönetim sürecinde de kaynak kısıtları varsa, hız önemliyse, kuyrukta bekleme olmamalı diyorsak ve hepsinden de önemlisi ne yapabileceğimizi bilerek ya da yaptığımızın olup olmadığını bilerek hareket etmemiz bizi başarılı yapacaksa üretimin başardığını projelerde de başarabilir miyiz? Bu sorunun cevabına EVET diyenler bir çok fikir attılar ortaya ve sonrasında da bu fikri ortaya atanlar bir araya gelip bunun genel adına Agile dediler. Esinlendikleri üretimden çok fazla esinlendiler ama kendi gerçeklerini göz önüne alarak farklı prensipler de belirlediler. Üretim sürecindeki talimatlardan ziyade ekip içi iletişimin önemli olduğunu, sözleşme maddelerinden ziyade müşterinin beklentilerinin önemli olduğu bir yapı önerdiler. Üst kavramlarda anlaşsalar da onlarca çevik uygulayıcısı kendi pratiklerini yazdı. Çoğu da şirketleşti, kendi kitaplarını, kendi sertifika sınavlarını üretti ve bu konuyu ayrı bir ticarete dönüştürdü. Burada durup düşünmemiz gereken bir şey var. Agile yapılır mı? olunur mu? cevap basit Agile olunur çünkü agile bir felsefe, agile bir kültür agile bir uygulama çerçevesi. Agile’a bizi üretilen farklı yaklaşımlar yakınlaştırmalı diyoruz ama her geçen gün bu yaklaşımların bizi farklı yerlere götürdüğünü de görüyoruz. O nedenle önemli olan agile felsefesini anlamak, benimsemek ve uygulayabilmek. Uygulamada kurallar olabilir ama felsefenin çerçevesini değiştirmeden bu kuralların uygulanması önemli.

Burada da en önemli görev projelerin yürütüldüğü organizasyonların yöneticilerinde. Bu değişim ve dönüşümü başlatmak hiç kolay değil. Önce yöneticilerin kendisi agile olmalı ki biz onlara hizmetkar lider demişiz. Kendi kendini yöneten ekipleri motive eden ve onların sorunlarını çözen yöneticiler. Talimat veren veya kontrol eden değil. Ekip’in tabi ki bir düzeni olacak, tekrarlı döngülerinde neler yapacağını planladığı. Bu planlamada ve yolda ona yardımcı olacak, öncelikleri belirleyen ve son karar veren yetkili bir iş birimi sorumlusu çok önemli. Hız ve kalite ne kadar önemliyse ekip içi görüşmeler de o kadar sık ve kolay olmalı. Aynı yerde çalışmalar, her gün aynı yerde aynı saatte yapılan görüşmeler. Her tekrarlı döngü sonunda yapılanların gözden geçirilmesi ve deneysel olan bu sürecin gerektiğinde başa dönmesi de önemli. Ekibin bir durup düşüneceği kendini sorgulayıp daha iyisini arayacağı görüşmeler de olmalı. Bütün bu yapılması gerekenler için bir süre sınırı olması her günümüz her anımız toplantı olmaması için çok önemli. Felsefemiz iletişim, sık sık yapılanı konuşma ve çözüm odaklı olma iken tüm bu kurallar da bunu yapabilmemize imkan sağlayacak ama büyük olmayan bir ekiple. Bunu yapabilen ve başarabilen proje ekipleri var ama projelerinin yapısı, şirketleri, proje ekip üyeleri ve diğer tüm koşulları onlar için bir avantaj diye düşünüyoruz. Agile olmaya çalışanlar ya da agile olduğunu sanıp agile yapanlar hatta agile kurallarını geleneksel süreçlerde uygulayanlarda var. Bu onların eksikliği değil. Bu onların mecburiyeti. O nedenle Hibrit konuşuyoruz hatta Blended yani Harmanlanmış Yaklaşımlar konuşuyoruz. Her zaman hedefe giden birden fazla doğru yol vardır. Hedefe giderken yolda gidiş tarzınız da değişebilir. Hibrit ve Harman Yaklaşımlar bunu ifade eder. Başka bir deyişle gerektiğinde gerekeni yapmaktadır doğrusunu yapmak.

Proje dünyası bunları kendi içinde yaşarken hızını alamayan uygulayıcılar çoktan Organizasyonel Çeviklik ve İş Çevikliği söylemlerini yaygınlaştırdılar yani sadece bir projede değil diğer tüm iş birimi çalışmalarında aynı felsefe verim, hız ve kalite getirecek dendi ve denendi. Bunun da güzel uygulandığı şirketler oldu. Çünkü işin sırrı değişimi ve dönüşümü başarmak. İletişimi geliştirmekle başladılar çalışmalara daha kısa döngülerle planlama yapıp, sonuçları yani olası başarısızlıkları erken fark ettiler. Bu da işin en önemli parçası olan değişime adaptasyonu sağladı. Kimi zaman öncelik kimi zaman talep değişti, kimi zaman da devir değişti. Onlar da bu değişime ayak uydurarak iş yaptıkları ölçüde başarılı oldular. Herkes bunu başarabilir mi? diye sorarsanız bence EVET. Çünkü bu anlatılanlar insanlarla ilgili, bizim yaşadığımız sorunlarla ilgili. Temelinde yine bizden çok önemli kilit konular var. İletişim, iş birliği, ekip olma, güven, hız, kalite ve memnuniyet. Bunlar uygulanırsa başarı da elde edilir.

Uzun lafın kısası 100 yıldan fazla geçmişi olan modern proje yönetiminin 30 yıllık çevik yaklaşımlarla mücadelesi her geçen gün farklı değişikliklerle bizi şaşırtan dünyada beklendiği gibi çevik yaklaşımların galibiyetiyle devam ediyor. Fakat bu iki kavramı bir birine rakip görmemiz gerektiğini de bildiğimiz için bu yenilgiyi resmileştirmeden yapabileceğimiz en iyi şey projesine hatta projenin içinde sürecine uygun geleneksel, çevik, hibrit ve harman yaklaşımı uygulamak olacaktır. Çünkü çevik yaklaşımların cevap vermeye uğraşmadığı bir çok sektördeki uygulamalara sahip olduğumuz geleneksel kaynaklar cevap verebiliyor. Bu nedenle gelecek, geçmişine hakim, geleceğe hazır, bugünün değişimini yönetecek kadar tüm yönetim yaklaşımlarını bilerek uygulayanların olacaktır.

Reklam

PMI PMP ve Proje Yönetimi

21 Oca

PMI (Project Management Institute) 1969 Yılında Amerika merkezli olarak Proje Yönetimi Sürecinin standartlaştırılması için kurulmuştur. Geçen 50 yıllık süreçte yaklaşık 600 Bin üyesi olan organizasyonun akredite ettiği sertifika sahiplerinin sayısı 1 Milyonu geçmiştir.

PMI Proje Yönetimi ve ilgili konularda standart, uygulama pratikleri ve rehber kitapları yayınlamakta ve Proje Yönetimi ile ilgili yan uzmanlık alanlarının sertifika sınavlarını merkezi olarak düzenlemektedir.

PMBOK(Project Management Body of Knowledge) Proje Yönetimi Bilgi Birikimi Kılavuzu 6.Versiyonu yayındadır. Bu kitap PMI’ın dünyadaki tüm PMI gönüllülerinin katkıları ile hazırlanmıştır. Geniş bir kitlenin tecrübesini içeren ve Proje Yönetim Standardının da referansı olan bu kitap en iyi pratikleri içerdiği ve genel olarak kabul gördüğü için PMI Proje Yönetim Standardı dünyada en çok kabul gören Proje Yönetim Standardıdır. Bu standart konu, meslek ve branş bağımsız tüm proje tipleri için standarttır.

PMI, kendini liderlik enstitüsü olarak tanımlar. Ülkelerdeki dernek uzantılarıyla proje yöneticileri için profesyonel gelişim anlamında kariyer yolu sağlar. PMI tarafında gönüllü olarak görev alan profesyoneller PMI toplantı ve etkinlikleriyle profesyonel gelişimini destekler. Türkiye’de de 1.000’e yakın PMI üyesi ve 4 Binden fazla PMP® Sertifikalı profesyonel vardır. İnşaat Sektöründen Bilgi Teknolojilerine, Savunma Sanayinden Finans Sektörüne tüm sektörlerden üye ve sertifikalı proje yöneticileri üyeler arasındadır.

215’den fazla ülkede 300’den fazla yerel organizasyonla yaygınlaşma ve farkındalık çalışmalarını yürüten PMI’a üye olmanın ve PMP®(Project Management Professional) yani Proje Yönetimi Profesyoneli Sertifikasına sahip olmanın avantajları aşağıdaki gibidir.

  1. PMP® Sertifikası sahiplerinin proje yönetimi konusundaki bilgileri, becerileri ve tecrübeleri yapılan sınavla tescillenmiştir.
  2. PMP® Sertifikası, proje yöneticilerinin uluslararası olarak bu unvana sahip olduğunu ifade eder.
  3. PMP® Sertifikası Proje Yönetimi için planlama teknikleri ve iletişim yönetimi gibi önemli yeteneklerin Proje Yöneticisinde olmasını sağlar.
  4. PMI Üyeleri Proje Yönetimi konusunda kitap, makale ve yayınlara ücretsiz erişir.
  5. PMP® Sertifikalı Proje Yöneticileri Projenin uçtan uca tüm süreçlerinde neyi nasıl yapacağına hakimdir. Bu hakimiyet sayesinde Proje Planlama ve Koordinasyon becerisini projeye yansıtarak Projenin başarılı olmasını sağlar.
  6. PMP® Sertifikası bir çok ihale sürecinde Proje Yöneticisi niteliği olarak aranmaktadır.
  7. PMP® Proje Yönetim Süreçleri projelerde iş birliği yapan şirketler arasında ortak dilin oluşturulması için önemlidir.

Dünya’daki güncel PMI Üye ve Sertifikalı profesyonel sayıları aşağıdaki gibidir:

Kaynak Kısıtı ve Bekleme Süresi Teorisi

16 Ağu

#ProjeYönetimi‘nde kaynak kısıtlarına dair #Agile olmak için bilmeniz gereken bir teori:Bekleme süresi, kaynağın meşgul olduğu sürenin, boşta olduğu süreye bölünmesiyle elde edilir.Kaynak %50 dolu ise bekleme süresi 1 Birim/Saattir. Kaynak doldukça bekleme süresi katlanarak artar

 

Kargo Kültü

16 Ağu

Kamu Kurumlarında da sık karşılaştığımız “Yapılan işlerin yüzeysellikle Anlamadan, Kavramadan, Neden Yapıldığı Bilinmeden Yapıldığında İyi Olacağı Düşünülen İnanca” “Kargo Kültü” Diyoruz!

Nedir Bu Kargo Kültü:

İkinci Dünya Savaşı sırasında Güney Pasifik’te daha önce kimsenin uğramamış olduğu ve yerlilerin yaşadığı bir kaç ada stratejik önem kazanmaya başlıyor. Japonya ve ABD uçakları yakıt ikmali yapmak için bu adalarda üsler kuruyorlar ve teknoloji ile alakası olmayan yerliler bir anda medeniyet ile tanışıyor.

Adalara sık sık askerlere takviye için kargo uçakları iniyor ve uçaklar; giysi ve konserve gibi temel ihtiyaç malzemeleri getiriyorlar. Elbette bu ürünlerden yerlilere de dağıtılıyor.

Savaşın bitmesinin ardından da herkes pılını pırtını toplayarak adaları bir başına bırakıyor. Yerliler ise batılıların tekrar gelip ürün dağıtlamaları için çok ilginç bir yönteme başvuruyorlar.

Bambulardan uçak modelleri ve kontol kuleleri yapıp yerlere uçuş pistlerini anımsatan yollar çizip ateşle aydınlatıyorlar. Hatta kule görevlisi ile uçuş görevlileri gibi davranıp uçakların inmesini bekliyorlar.

Kargo kültü terimi de buradan doğmuş. Anlamına gelecek olursak; bir süreci anlayamadığımız ya da kavrayamadığımız taktirde, yüzeysel görünümünü taklit ederek aynı işlev ve fonksiyonda çalışmasını ummak diyebiliriz.

Kaynak: https://www.yirmilerim.com/kargo-kultu-nedir/

I, T, Pi ve Tarak Tipi Çalışanlar

16 Ağu

Çalışanlardan beklenenler zamanla çok değişti. Eskiden I tipi dediğimiz tek bir konuda dikey uzmanlık aranırken, bu zamanla yerini T tipi yani yatayda da bazı konuları bilmesi istendi. Fakat bu da yetersiz olunca en az iki konuda yetkinlik arayışıyla Pi Tipi Söz konusu oldu.

Şimdi de değişen dinamik ortam ile artık Tarak Tipi yani hem çoklu uzmanlığa sahip olmak hem de diğer ilgili yatay disiplinleri bilmek aranan gerekli özellik oldu.

Değişimi Yönetmek

25 Mar

Bir tavsiye üzerine değişim yönetimi ile ilgili güzel bir fabl kitabı okudum. Bu kitapta organizasyonların karşılaştığı değişim ihtiyacında izlenecek yol güzel bir şekilde tarif edilmiş. Kitabın adı: “Buzdağımız Eriyor” Buradan hem kitabın okunmasını önermek için detaylarını paylaşmak istedim hem de bu kitabın bana çocuklarımız için de değişimi ve proje yönetimini anlatan bir kitap yazma konusunun ne kadar önemli olduğunu düşündürdüğünü paylaşmak istedim. Evet, kolları sıvıyoruz bu kültür küçük yaşta verilmeli. Kitap için çalışmalara başladım.

tumblr_inline_otjjyckCz61sosog6_1280Kitabın içeriğine gelince:

Kitabın yazarları, John Kotter ve Holger Rathgeber’dir.

Meraklı ve gözlemci bir penguen olan Fred zamanını buzdağını ve okyanusu gözlemleyerek geçirir. Bir gün kimsenin görmediği ve fark etmediği bir sorunu, buzdağının altında kırıklar ve çatlaklar oluşmaya başladığını gözlemler. Bunu arkadaşları ve kolonide lider durumda bulunan penguenlerle paylaşır. Böylece değişimin hikâyesi ve var olan ama görünür olmayan problemlerle başa çıkacakları hikâyeleri başlar.

Fred’i dinlemek isteyen penguenlerin yanı sıra değişimden hoşlanmayan ve sorunları görmezden gelen, NoNo(HayırHayır-Hayırcı-İstemezükçü 🙂 ) gibi penguenlerde vardır.

Kitabın Ders Bölümünde anlatılan Başarılı bir değişimin sekiz yolu;

Hazırlık Yapın

  • Acil Durum Hissi Yaratın

Değişimin gerekli olduğunu ve derhal harekete geçmenin önemini diğerlerinin görmesi için yardım etme.

  • Yol Gösterecek Takımı Kurunuz

Değişime, liderlik, güvenilirlik, iletişim özellikleri iyi, analitik yetenekleri yüksek ve aciliyet duygusuna sahip olan güçlü bir grubun rehberlik ettiğinden emin olun.

Ne Yapılacağını Kararlaştırınız

  • Değişim Vizyonunu ve Stratejisini Oluşturunuz

Geleceğin geçmişten nasıl farklı olacağını ve bu geleceğin nasıl gerçekleşebileceğini açıklama…

Gerekeni Yapınız ve Gerçekleştiriniz

  • Anlayış ve Ortaklık İçin İletişimde Bulunun

Diğerlerinin vizyon ve stratejiyi anladığından ve kabul ettiğinden emin olunması.

  • Diğerlerini Hareket Geçmeleri İçin Güçlendirin

Bir düşünceyi gerçeğe dönüştürmek isteyenlerin önünde bulunan engelleri ortadan kaldırmaya çalışın böylece düşünceyi gerçeğe dönüştürebilsinler.

  • Kısa Vadede Kazançlar Üretin

Mümkün olan en kısa zamanda görülebilir, açık başarılar yaratın.

  • Gevşemeyin ve Yorulmayın

İlk başarılı sonuçtan sonra daha sert ve daha zor işlerde başarılı olmaya çalışın. Düşünce gerçek olana dek değişikliklerde yorulmaz olun.

Kalıcı ve Sürdürülebilir Olmasını Sağlayın

  • Yeni Bir Kültür Oluşturun

Yeni davranış yollarına tutunun ve bunların başarılı olduklarından emin olun ta ki eski geleneklerle yer değiştirecek kadar güçlü oldukları zamana dek.

Hikaye şu önemli dersi anlatır;

Kendinize sorun, eriyen ya da eriyebilecek olan bir buzdağında yaşar mıydınız? Buzdağlarının erimesi birçok şekilde ortaya çıkabilir: yaşlanan ürün bantları, ilgisiz duruma gelen okullar, kaliteyi düşüren hizmetler, anlamı olmayan iş stratejileri, uygulaması okyanusta batan yeni bir strateji.

Organizasyonunuzdaki değişim savunucuları kimler? Değişime hayır diyenler kimler? Sizin rolünüz ne olabilir?

Proje Yönetimi Hakkında Özlü Sözler

26 Haz

Proje Yönetimi ve Liderlik

Proje yönetimi üç topla jonglörlük yapmak gibidir: zaman, maliyet ve kalite. Program yönetimi ise bir daire oluşturmuş, her biri 3 top çeviren ve çevirirken ara sıra toplarını değiş tokuş eden bir sirk topluluğu gibidir. G. Reiss

Proje yöneticileri orkestra şefi gibidir; her biri bireysel notaları ve enstrümanlarında uzman olan ekip üyelerini bir araya getirir. Liderlerinin yönetiminde hepsi aynı tempoyu yakalar. L.R. Sayles
Yaptığım tüm işler arasında en hayati olan, bizim için çalışanların hünerlerini koordine etmek ve ortak bir amaca doğru yönlendirmekti. Walt Disney
Her proje yöneticisi Pazartesi sabahı problemlerle karşılaşır, iyi proje yöneticisi ise gelecek Pazartesinin sorunlarıyla uğraşır.
Güçlü proje yöneticisi problem çözmez, problemleri bertaraf eder.
Bir geyik tarafından kumanda edilen aslanlar ordusu hiçbir zaman aslanlar ordusu olamayacaktır. Napoleon Bonaparte
Bilgece yönetirseniz seve seve itaat edilirsiniz. Thomas Fuller
İyi proje yöneticileri hataları itiraf eder. İyi proje yöneticilerinin ender görülmesi bu yüzdendir.

Planlama Süreci
Plan hiçbir şeydir, planlama her şey…  Dwight D. Eisenhower
Planlamayı başaramıyorsanız, başarısızlığı planlıyorsunuz demektir.
Projelerin hepsi sonunda başarısız olmaz, bazıları baştan başarısız olmuştur.
Başarılı proje yöneticisi yoktur, sadece şanslı proje yöneticisi vardır.  Ne kadar plan, o kadar şans!
Plan yapmamanın en güzel yanı başarısızlığın tam anlamıyla bir sürpriz olmasıdır, endişe ve stresle dolu bir ön süreç yaşamazsınız.
Projeler iki yolla olur: a) Planlanır ve yürütülür. b) Yürütülür, durdurulur, planlanır ve sonra yürütülür.
Acil olarak aksiyona dökülmeyen plan sadece iyi bir dilek olarak kalır.  Peter Drucker

Risk Yönetimi

Bir işin ters gitme olasılığı varsa, ters gider.   Murphy Yasası
Bir işin ters gitme olasılığı yoksa da ters gider.  O’Malley’s
Olabilecek en kötü şekilde ters gider.  Sod Yasası
Bir iş, tamamlanması için müsait olan tüm zamanı dolduracak şekilde genişler. Parkinson Yasası
Murphy, O’Malley, Sod ve Parkinson yaşıyorlar ve emin olun sizin projenizde de çalışıyorlar.

Zaman Yönetimi
Crashing: Bir kadın bir bebeği 9 ayda doğurur. En iyi dokuz kadın gelse bir bebeği bir ayda doğuramaz.
Uyarı: Takvimdeki tarihler sandığınızdan daha yakındır.
Kritik Yolu olmayan bir proje dümensiz bir gemiye benzer.  D. Meyer, Illinois Construction Law

Kapsam Yönetimi
Bir proje yöneticisinin sözcük dağarcığındaki en değerli ama en az kullanılan kelime “HAYIR”dır.
Herhangi bir şeyi değiştirecek zaman kalmayıncaya kadar değişebilecek her şey değişecektir.
Değişim hakkında konuşmak her zaman yapmaktan daha kolaydır. Alvin Toffler
Mükemmel iyinin düşmanıdır.
Kullanıcı; size ne istediğini, talep ettiği şeyi verdiğiniz anda söyleyen kişidir.

WBS’in Önemi Üzerine
WBS olmadan bir projeyi yürütmek, haritanız olmadan yabancı bir ülkede gezmeye benzer. J. Phillips

Öğrenilmiş Dersler Üzerine:
NASA’da hiçbir zaman hataları cezalandırmayız, ama hatanın saklanmasını cezalandırırız. Al Siepert
Öğrenilmiş derslerden öğrendiğimiz, öğrenilmiş derslerden bir şey öğrenemediğimizdir.  T. Block
Akıllı adamlar kendi hatalarını ve başkalarının hatalarını tekrarlamaz. Konfüçyus

Proje Yönetimi, Projeler

Proje Yönetimi:  Gerçekte şans eseri olan çıktıların, bilinçli olarak önceden planlanmış aksiyonların bir sonucu olduğu yanılsamasını yaratma sanatıdır. Harold Kerzner, 1995
Asıl işleri yangın söndürmek olduğu halde,  neden bazı profesyoneller proje yönettiklerini söyler?  Colin Bentley, 1997
Diğer tüm organik varlıklar gibi, projelerin de bir yaşam döngüsü vardır. Yavaş bir başlangıçtan başlayıp büyür,  zirve yapar, düşüşe geçer ve en sonunda biter (Ve diğer organik varlıklar gibi bu sona direnirler).  Meredith & Mantel
Projeler bebek gibidir; ilgi ister, ilgiyi hemen ister.
Vereceğiniz her kararın uzun vadede etkileri olacaktır. Bütün bu etkileri önceden tahmin edemezsiniz, ama onlarla yaşamak zorundasınız.
İşler yolunda giderken mutlaka yanlış giden şeyler de olacaktır, her şey daha iyiye gidiyormuş gibi görünüyorsa kesinlikle gözden kaçırdığınız bir nokta var demektir.
Başarısız olan birçok proje, daha başlamadan başarısız olmuştur.
MS Word kullanmak sizi ne kadar yazar yapabilirse, MS Project kullanmak da ancak o kadar proje yöneticisi yapar.
Proje Yönetiminde Büyük Günahlar:
•    Başının belada olması
•    Başının belada olması ama farkında olmamak
•    Başının belada olması, farkında olmak ve görmezden gelmek

Planlama ve Tahmin
Hızlı, ucuz ve iyi; istediğiniz herhangi ikisini seçebilirsiniz.
On farklı kişi aynı anda veya aynı kişi on ayrı zamanda,  aynı şartlar altındaki ayni iş için farklı tahminler yapacaktır.
Bir iş için en uzun süre ve en büyük bütçe tahmini yapan kişi, işin gerçekten nasıl yapılacağı ile ilgili fikri olan tek kişidir.
Her proje doğru şekilde tahmin edilebilir (tamamlandıktan sonra).
Bir kişiyi mantıksız bir teslim tarihine taahhüt vermek için ikna edebilirsiniz, ama bu taahhüdü yerine getirmesini sağlayamazsınız.  Edwards, Butler, Hill & Russell, 1997
Bitiş tarihi, projenin daha önce tamamlanamayacağını kanıtlayabildiğiniz en erken tarihtir.
Verilen tarih ne kadar mantıksız olursa, onu karşılamak için o kadar çok para boşa harcanır.
İyi bir plan risk analizine yardımcı olsa da hiçbir zaman projenin pürüzsüz yürümesini garanti edemez.  Bentley & Borman 2001
Bir proje ancak sizin için çalışmaya başladığında tamamlanmış sayılır, siz onun için çalışıyorken değil.  Scott Allen
Altın Kurallar:
•    Plan yap
•    Plana uy
•    Bu kadar basit
•    Yapması ise bir o kadar zor

Kapsam, İhtiyaç Analizi
Batmış bir projeye giden yol iyi niyet taşlarıyla döşelidir. (Yani altın kaplama yok!)
Müşteri size sadece sorduğunuz şeyi anlatacaktır, daha fazlasını değil.  (Gerekli olan her şeyin sorulduğundan emin olmalıyız).
Bana neye ihtiyacın olduğunu söyle, sana onsuz nasıl yaşayabileceğini anlatayım.
Kullanıcı gereksinimlerini keşfetmek için en iyi zaman ille de teslim aşaması değildir. :o)
Şartlı bir söz verildiğinde, şartlar unutulur söz hatırlanır.  Edwards, Butler, Hill & Russell, 1997
Proje kapsamının özgürce değişmesine izin verirseniz, bir süre sonra değişim oranı gelişim oranını geçer.
Siz kullanıcı taleplerini dondurabilirsiniz, ama onlar beklemekten vaz geçmeyecekler.
Hiçbir şey, onu kendisi yapmak zorunda olmayan kişi için zor değildir.  –Weiler’s Law
Çok miktarda gereksiz detay,  ‘açık ve net anlatım’ ihtiyacını karşılamaz.
Benim kadar kafan karışıksa benim kadar şey biliyorsun demektir.
Söylediğimi düşündüğün şeyi anladığına inandığını biliyorum; ama duyduğun şeyin kastettiğim şey olmadığının fakında olup olmadığından emin değilim.
Eğer bir yazılım projesi ilk seferde çalışıyorsa, bir yanlışlık var demektir.
Kod yazmak kesinlikle çok önemlidir. Erken teslim etmek de. İkisinden daha önemli olan ise “çözmeye çalıştığın problemi anlamak” ve daha da önemlisi “doğru yapmak”tır.
Başarılı bir yazılım projesinin sonunda hiç kimse tasarım aşamasında çok fazla zaman harcadığı için şikayet etmemiştir.
Süre ne kadar yakın, maliyet o kadar yüksek. (Proje ilerledikçe düzeltme maliyetinin daha çok artajağından söz ediyor.)

Yürütme ve Kontrol
Hararetli çalışma her zaman ilerleme anlamına gelmez.
Hiçbir zaman ‘efor’u ‘sonuç’la karıştırmayın. İlerlemeyi görmek için, harcanan eforu ölçüyorsanız doğru şeyi ölçmüyorsunuz demektir.
Dikkate alınması gereken çalışılan saatler değil, o saatlerde ne yapıldığıdır.
Bir işin nasıl yapılacağını bilmiyorsanız, sadece yapmaya başlayın.  Sizin kadar bile bilmeyen en az on kişi nasıl yapacağınızı anlatacaktır.
Fazla mesai, acemi proje yöneticisinin hayal gücünün bir ürünüdür.
‘Elimizden gelenin en iyisini yapıyoruz’ demenin hiçbir faydası yok. Ne gerekiyorsa onu yapmayı başarmalıyız.  Winston Churchill
Gecikmiş bir yazılım projesine adam gücü eklemek projeyi daha da geciktirir.  Brooks’ Law
Büyük gemileri batıran küçük yarıklardır. (Sorunları ve riskleri küçümsemeyelim)
Şans, hazırlık fırsatla bir araya geldiğinde olan şeydir. Seneca
En iyi şans, kendin için kendi yarattığın şanstır. Douglas MacArthur

Proje Ekibi ve İletişim
Ekibinize doğru insanları seçin,  daha sonra neyi yanlış yaparsanız yapın sizi kurtaracaklardır. İşte yönetim tam anlamıyla budur.  Tom DeMarco, The Deadline
Yönetim çoğu zaman uygulamalı klinik psikoloji gibidir. Takım üyelerinin karakterleri ve anlaşmazlıklarıyla ilgilenmek gibi, bulaşacağınızı hiç tahmin etmediğiniz işleri içerir. Donald Norman
Problem yaratan insanlar olmasaydı problemleri çözen insanlara da ihtiyaç olmazdı.
Güvendiğin insanları ekibe al, yola devam et ve onlara güven!  Dan Lyons
Herkese güvenmek de hiç kimseye güvenmemek kadar feci bir şeydir. Hesiodus, İÖ 700
Bir insana, ona sorumluluk vermek ve ona güvendiğini bilmesini sağlamak kadar yardım edebilen çok az şey vardır.   Booker T. Washington
Hiçbir koç oyunu kendi bildikleriyle kazanmamıştır, zaferi ancak oyuncularının bildikleri getirir.
Öğrendim ki büyük lider, diğer insanlara yapmak istemedikleri şeyleri yaptırmak ve de sevdirmek yeteneğine sahip olan kişidir.  Harry S. Truman
Hayatta en büyük ders, aptalların bile bazen haklı olabileceğini bimektir.  Winston Churchill

Öğrenilmiş Dersler
Hata yapmak insani bir şeydir, bir hatada ısrar etmek ise ahmaklıktır.  Cicero, İÖ 43
Hiç hata yapmayan kişi genellikle hiçbir şey yapmıyor demektir.  William Connor Magee
Yaptığın şeyin gerçekten işe yarayıp yaramadığını kontrol et, gerçek delilik aynı şeyi tekrar tekrar yaparak farklı sonuçlar beklemektir.

Bardak Boş mu Dolu mu?

Yarısı su dolu bir bardağı gösterip bu soruyu sorduğunuzda;
•    İyimser yarısının dolu olduğunu söyler,
•    Kötümser,  yarısı boş der,
•    Yazılımcı tamamen boş olduğunu,
•    Proje Yöneticisi bardağın ihtiyaç duyulandan iki kat büyük olduğunu söyler,
•    Sihirbaz ise bir numara yapar, bardağın dolu yarısı üstteymiş gibi gösterir.

Kaynaklar:
http://www.projectauditors.com/Company/Project_Management_Quotes.html
http://www.citehr.com/110518-project-management-quotes.html
http://projectsteps.blogspot.com/2006/03/collection-of-project-management.html

Lessons Learned in Software Development

21 Nis

Development

1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution.

I like this quote from John Gall: “A complex system that works is invariably found to have evolved from a simple system that worked.”

2. Change one thing at a time. When you develop, and some tests fail, or a feature stops working, it’s much easier to find the problem if you only changed one thing. In other words, use short iterations. Do one thing, make sure it works, repeat. This applies down to the level of commits. If you have to refactor the code before you add a new feature, commit the refactoring first, then (in a new commit) add the new feature.

3. Add logging and error handling early. When developing a new system, one of the first things I do is adding logging and error handling, because both are useful from the very beginning. For all systems that are bigger than a handful of lines of code, you need some way of knowing what happens in the program. Perhaps not when it is working as expected, but as soon as it doesn’t, you must be able to see what’s happening. The same goes for error handling – errors and exceptions happen in the beginning too, so the sooner you handle them in a systematic way, the better.

4. All new lines must be executed at least once. Before you are done with a feature, you have to test it. Otherwise, how do you know that it does what it is supposed to do? Often, the best way is by automatic tests, but not always. But no matter what, every new line of code has to be executed at least once.

Sometimes it can be hard to trigger the right conditions. Fortunately, it’s easy to cheat a bit. For example, the error handling on a database call can be checked by temporarily misspelling a column name. Or, an if-statement can be temporarily inverted (“if error” becomes “if not error”) in order to trigger something that rarely happens, just to make sure that code is run and does what it should.

Sometimes I see bugs that show that a certain line of code can never have been run by the developer. It can look fine when reviewed, but still not work. You avoid embarrassment if your policy is to always execute every new line you write.

5. Test the parts before the whole. Well-tested parts save time. Often there are problems with integrating different parts, for example from mismatched or misunderstood interfaces between modules. If you can trust that the parts work as expected, it becomes much easier to track down the integration problems.

6. Everything takes longer than you think. Especially in programming. It is hard to estimate how much time a feature will take even if everything goes smoothly. But when developing software, it is quite common to run in to unexpected problems: a simple merge turns out to cause a subtle bug, an upgrade of a framework means some functions must be changed or an API call doesn’t work as promised.

I think there is a lot of truth in Hofstadter Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

7. First understand the existing code. Most coding requires changing existing code in some way. Even if it is a new feature, it needs to fit into the existing program. And before you can fit the new stuff in, you need to understand the current solution. Otherwise you may accidentally break some of the existing functionality. This is means that reading code is a skill that is as necessary as writing code. It is also part of the reason why seemingly small changes can still take a long time – you must understand the context in which you make the change.

8. Read and run. Fortunately, there are two complementary methods for understanding code. You can read the code, and you can run the code. Running the code can be a great help when figuring out what it does. Be sure to make use of both methods.

Troubleshooting

9. There will always be bugs. I don’t like approaches to software development that claim to “get it right the first time”. No matter how much effort you put in, there will always be bugs (the definition of a bug pretty much is: “we didn’t think of that”). A much better approach is to have a system in place that lets you quickly troubleshoot problems, fix the bugs and deploy the fixes.

10. Solve trouble reports. Every developer should spend a portion of their time handling trouble reports from customers and fixing bugs. It gives you a much better understanding of what the customers are trying to do, how the system is used, how easy or hard it is to troubleshoot and how well the system is designed. It’s also a great way of taking responsibility for what you develop. Don’t miss out on all these benefits.

11. Reproduce the problem. The first step when fixing a bug is to reproduce the problem. Then you make sure that when the fix is added, the problem is gone. This simple rule makes sure you are not assuming something is a problem when it isn’t, and makes sure the solution actually does what you think it does.

12. Fix the known errors, then see what’s left. Sometimes there are several problems present that you know about. The different bugs can interact with each other and cause strange things to happen. Instead of trying to work out what happens in those cases, fix all the know problems and then see what symptoms remain.

13. Assume no coincidences. When testing and troubleshooting, never believe in coincidences. You changed a timer value, and now the system restarts more often. Not a coincidence. A new feature was added, and an unrelated feature becomes slower? Not a coincidence. Instead, investigate.

14. Correlate with timestamps. When troubleshooting, use the timestamp of events as a help. Look for even increments. For example, if the system restarted, and a request was sent out around 3000 milliseconds before, maybe a timer triggered the action that lead to the restart.

Cooperation

15. Face to face has the highest bandwidth. When discussing how to solve a problem, being face to face beats video, call, chat and email. I am often amazed at how much better the solutions are after discussing them in person with colleagues.

16. Rubber ducking. Whenever you are stuck, go to a colleague and explain the problem to them. Many times, as you talk, you realize what the problem is, even if your colleague doesn’t say a word. Sounds like magic, but works surprisingly often.

17. Ask. Reading and running the code is often great for figuring out what it does and how it works. But if you have the possibility to ask someone knowledgeable (perhaps the original author), use that option too. Being able to ask specific questions, and follow-up questions to those, can give you information in minutes that would otherwise take days to get.

18. Share credit. Make sure to give credit where credit is due. Say: “Marcus came up with the idea to try…” (if he did), instead of “we tried …”. Go out of your way to mention who else helped or contributed.

Miscellaneous

19. Try it. If you are unsure of how a certain language feature works, it is easy to write a little program that shows how it works. The same applies when testing the system you are developing. What happens if I set this parameter to -1? What happens if this service is down when I reboot the system? Explore how it works – fiddling around often reveals bugs, and at the same time it deepens your understanding of how the system works.

20. Sleep on it. If you are working on a difficult problem, try to get in a night’s sleep before you decide. Then your subconscious mind works on the problem even when you aren’t actively thinking about it. As a result, the solution can seem obvious the next day.

21. Change. Don’t be afraid to change roles of jobs every once in a while. It is stimulating to work with different people, on a different product or in a different company. In my view, too many people just passively stay at the same job year after year, only changing if they are forced to.

22. Keep learning. One of the great things with software development is that there is always room to learn and know more. Try out different programming languages and tools, read books on software development, take MOOC courses. Small improvements soon add up to make a real difference in your knowledge and abilities.

Kaynak: http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/

Yazılım Projeleri Yönetiminde 10 Temel Sorun

11 Şub

Yazılım Proje Yönetiminde 10 Temel Sorun

  1. Yazılım, soyut ve kolay değiştirilebilir bir üründür. Yazılım kaynak kodlari text metinler şeklinde yazılır . Birçok durumda yazılım geliştirme takımları paylaşılan dokümanları (gereksinimler, tasarım özellikleri, kodlar ve test planları) oluşturur ve revize eder.
  2. Yazılım Geliştirme proje süresince öğrenme sürecinde sıklıkla kazanılan bilgi ve oluşturulan bilgi olarak nitelendirilir.
  3. Yazılım projelerini zorlaştran anahtar nitelikler: proje ve ürünün karmaşıkligi, lineer olceklenemeyen kaynaklar, proje ve ürünün ölçümü, başlangıçta proje kapsamının kesinleşmemiş oluşu ve projenin gelişimiyle kazanılan bilgidir.
  4. Yazılım gereksinimleri proje süresince kazanılan bilgi, projenin aciliyeti ve projenin kapsamına göre değişir.
  5. Yeni ve değişiklik yapılan yazılım için gereksinimler çoğu kez organizasyonların iş süreçleri ve personelin iş akış süreçlerinden etkilenir ve etkilenmiş olur.
  6. Yazılım takımları ve proje Paydaşları arasında sıkça iletişim ve koordinasyon eksikliği net bir şekilde görülür.Yazılım Mühendisliğinde iletişim ve koordinasyou geliştirmeye yönelik birçok araç ve teknik kullanılmaktadır.
  7. Yazılım projeleri için başlangıçtaki planlama ve tahminleme zorluktur çünkü bu aktiviteler Uygulanamaz veya çoğu eksik geçmişe ait verinin bir bölümü veya çoğu kesin gereksinimlere bağlıdır. Doğru tahminlerin hazırlığı da zorludur çünkü yazılım geliştiricilerinin etkililik ve efektifligi derin bir değişkendir.
  8. Yazılım Geliştirmede sıkça farklı Ürün tedarikçileri ve diğer yazılımlar için arayüz geliştirme edinilmesi gerektiğinden entegrasyon ve performans sorunu ortaya çıkabilir.
  9. Yazılım kalitesinin ölçümü ve hedefin niteliği zordur çünkü yazılımın doğası soyuttur çalıştırılabilir yazılım tek başına bir ürün değildir. o işleyen donanımda çalışır ve çeşitli donanımlardan oluşan sistemin, diğer yazılımların ve manüel prosedürlerin bileşenidir.
  10. Platform teknolojileri, altyapı yazılımları ve tedarikçi destekli yazılımlar sıklıkla değişir veya güncellenir bu o platformlarda geliştirilmiş olunan yazılımda değişiklikler gerektirir.

Kaynak: PMBOK 5 Software Extension