Tag Archives: Project Management

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?

Reklamlar

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

Proje Yönetimi ve Daha Fazlası

24 Tem

Proje yönetimi, belirli bir projenin hedef ve amaçlarına ulaşıp bitirilmesi için kaynakların planlanması, organize edilmesi, tedarik edilmesi ve yönetilmesi disiplinidir.

Projeler belirli özgün hedef ve amaçlara ulaşmak amaçlı uygulanır,genellikle faydalı bir değişim getirmek ya da değer katmak için. Projelerin esneklik payı ile birlikte belirli başlangıç ve bitiş tarihi vardır. Projelerin geçici olması; onları kalıcı, sürekli tekrarlanan, üretim ve servis amaçlı her zamanki işletme operasyonlarından farklı yapar. Pratikte, bu iki tür sistemin yönetimi oldukça farklıdır ve farklı teknik beceriler gerektirmektedir.

Proje yönetiminde gösterilen temel çaba, proje hedef ve amaçlarına ulaşmaya çalışırken önceden belirlenmiş proje kısıtlarının da dışına çıkmamaktadır. Tipik proje kısıtları kapsam, zaman ve bütçedir.

Bu kısıtlar proje yöneticisi tarafından iyi kontrol edilmeli amaç edinilerek proje paydaşlarının proje katkıları engellenmemelidir.

Bir disiplin olarak proje yönetimi, inşaat, mühendislik ve ağır savunma aktivitelerinin uygulamalarından geliştirilmiştir. Proje yönetiminin en önemli fikir babalarından biri, Gantt çizelgesini  tasarlamış olması ile ünlü olan Henry Gantt’tır. Diğer bir önemli fikir babası ise proje yönetiminde 5 yönetim fonksiyonunu kullanan Henri Fayol’dur.

1950’li yıllar, temel mühendislik alanlarının birlikte yürütüldüğü modern proje yönetimi döneminin başlangıcını oluşturmuştur. Proje yönetimi disiplini mühendislik modeli üzerine kurulu yönetim disiplininden ayrı bir disiplin olarak tanınmaya başlanmıştır. 1950’li yıllara kadar projeler resmi olmayan araçlar ve teknikler ile yürütülüyordu, Gantt çizelgesi de proje yönetiminden bağımsız özel amaçlar için kullanılıyordu. Bu dönemde ayrıca iki matematiksel proje zamanlama tekniği geliştirilmiştir. Kritik Yol Yöntemi, tesis bakımı projelerini yönetmek için DuPont ve Remington Rand Şirketleri tarafından geliştirilmiştir. Program Değerlendirme ve Gözden Geçirme Tekniği (PERT) ise Amerikan Donanması’nın bir deniz altı programı sırasında Booz Allen Hamilton tarafından geliştirilmiştir. Bu matematiksel teknikler hızla özel girişimlere de yayılmıştır. Proje zamanlama modelleri geliştirilirken, aynı zamanda proje maliyeti tahmini, maliyet yönetimi ve mühendislik ekonomisi gibi alanlar için teknoloji oluşmaktaydı.

Proje Yönetiminde başarı kriterleri olarak gösterilen maliyet, performans, zaman
ve kapsam faktörleri ise birbirlerine bağlı değişkenlerdir.
Maliyet(C)= f (Performans(P), Zaman(T), Kapsam(S)

Genellikle müşteriler ve üst yönetim bir projenin hem ucuz, hem kaliteli, hem kısa zamanda hem de geniş kapsamlı olmasını isterler. Proje tarafları, bir proje uygulamasında bütün bu faktörlerin birbirlerine bağımlı olarak değişkenlik göstereceği bilincinde olmalıdır.

Günümüzde çeşitli Proje Yönetim metodolojileri vardır. PMI metodolojisi Bunlardan son zamanlarda en çok talep gören yöntemdir. Project Managment Instutue (PMI) tarafından geliştirilen bu metodolojiye hakim olan proje yöneticileri sınavla PMP(Project Management Proffessional) ünvanına sahip olurlar.

Bir kurum bünyesinde projeler programlar altındaki portföyler kapsamında yönetilir. Benzer veya bir birini kapsayan projeler aynı portföy dahilinde ele alınırken aynı hedefe hizmet eden portföylerde bir program kapsamında ele alınır. Projelerin portföyler ve programlar şeklinde yukardan takip edilmesi risklerin minumum seviyeye düşmesini sağlar ve yapılacak işte harcnacak zaman ve kaynak’tan tasarruf edilerek, yapılan işlerin birbiriyle konuşması da sağlanarak kurum için verimlilik sağlanır.