Proje Yönetimi Araçları Neden Çalışmaz?
April 21, 2022Canı sıkılan firmanın yazdığı, herbirinin birbirinden farklı olduğunu iddia ettiği ama özünde hepsi aynı olan proje/iş yönetimi araçları üzerine fikirlerimi kaleme alacağım.
Peşin not: Öncelikle backlogunu daha temizleyememiş gönül dostlarına başarılar. Yazıyı mesai sonrasında okumanızı tavsiye ediyorum.
Kabaca proje yönetimi sisteminin özelliklerini basit bir formatta ortaya koyarsak
- id
- iş tipi: bug, task, review, dizayn
- birimi
- tanım
- kime atandığı
- başlangıç tarihi
- atanmış bitiş tarihi
- gerçek bitiş tarihi
- önceliği
- ilişkili olduğu diğer sistemler(versiyon kontrolu, build aracı, review vs)
- ilişkili olduğu altgörevler
- revizyonlar
- task puanı
Bu sistemin size cevap verebileceği sorulara bakalım.
- Mart ayı içinde A projesinde kapatılan taskların sayısı: 252
- 3 ten fazla insanla etkileşim gerektiren task sayısı: 33
- 2 günden fazla gecikmiş task sayısı: 22
Benim sisteme sormak istediğim sorular
- Bus Factorü 1 olan işler nelerdir: ?
- Aynı tempo ile çalışmaya devam ederse kafayı yakacak developerlar: ?
- Önümüzdeki 3 ay içinde bize problem çıkarması olası modüller hangileri: ?
- 1 ekibin 1 hafta işleri geciktirmesi sonucunda çıkacak maliyet: ?
- Hangi işleri yapmasak daha iyi olurdu: ?
- 1 ay içinde kodun kendisine veya operasyona kaç tane bağımlılık eklendi: ?
Görüldüğü üzere metrik verisini yapılan işlerin içeriğine erişmeden yorumlamak imkansız. O halde bu sistemleri bu kadar populer yapan nedir? Yalancı takip hissinden hoşlanan, tek boyutlu düşünebilenler için metrikler sağlaması oldukça ilgi çekici.
Bu sistemleri verilere timestamp iliştirip başka idlerle eşleştirmekten çok da fazlasınını yapmıyor. Hele ki kimilerinin dünya algıları tamamen yanlış.
Üstteki resmi Asananın youtube tanıtımından aldım. Tam olarak bir ideal dünya tanımı herşeyin hiyerarşik şekilde ağaç şeklinde dallandığı durum. Eğer ordu gibi katı bir yapı işletiyorsanız muhtemelen ihtiyaçlarınızı görür ki askerlik yaptığım dönemde bunun ordu da bile bazı zamanlarda çalışmadığına şahit oldum. Kişisel gözlemlerim gösteriyor ki yazılım işlerinde genellikle graph şeklinde gelişiyor. Hatta yeri geliyor hiç ummadığımız bağıntılara rast geliyoruz. Ağaç şeklinde düşünmek kolaya kaçmaktır. Durumların birbiri ile etkileşimlerini gözardı etmek için kör olmak lazım gelir.
Özelleştirilmiş statüsler
Etiketleme yapmanın bizim dünya idrağımızı kolaylaştırdığım malum lakin kimi projelerde bu etiketlerin nasıl olacağını belirlemek için toplantılar bile yapıldığına şahit oldum. Projenin boyutu büyüdükçe bunların sayısı gittikçe artıyor. Buna ortagonal başka bir parametre geldiği zaman kartezyen çarpımı kadar özel durum ortaya çıkıyor. En basit işlerde bile zincirler oluşmaya başlıyor. Ticketlar arasında navigasyon yapmak imkansız hale geliyor.
Kısıtlı durumlar ile düşünmek
Bir basit düşünme örneği olarak kanban board. Tüm firmanın işleyişini 5 tane state e indirgemek nasıl mümkün olabilir? Yazılımcıya fabrika işçisi muamelesi etmek kimin aklına geldi bilemiyorum.
Kimi memnun edeceğiz ?
Proje yönetimi araçları kendi başına kötü değiller ve sağladığı metrikler tamamen değersiz değil. Bu metrikleri geleceği tahminlemek için kullanmamızda bir sakınca yok. Ama bu metriklerin kendiliğinden kötüye evrilmesi sık görülen bir şey.
Gördüğünüz resmi redmine isimli bir araçtan aldım. Buna timetable deniyor. Zaman içinde olacak olayları bir çizelgeye koyduğunuzda neyin ne zaman başlayıp ne zaman sonlanacağını gösteriyor. İşlere süre biçmekte acemi olduğumuzu varsayalım.
- Gerekenden az zaman verirsek işler baton halinde sağa kayacak.
- Gerekenden fazla zaman verirsek işini bitirenin boş durması söz konusu.
%100 uyulabilen bir plan yapmanın başarı olduğu düşünülür ancak ben tam tersini düşünüyorum. Eğer planlarınıza 3 ay üstüste %100 uyabiliyorsanız bu durum birçok yönden tutarsızdır.
Sebeplerine gelelim.
- Müneccimsinizdir.
- Çok basit hedefler koymuşsunuzdur kolayca yapılmıştır.
- Hiç sürpriz çıkmamıştır.
En kötüsü ise iş takip sisteminiz çalışanlarınızı eğitmiştir. Yalan yanlış eksik fazla demeden iş takip sistemini memnun etmiştir. Asıl memnun olması gerekenler son kullanıcı olması gerekirken iş takip sisteminiz memnun olmuştur.
Entegrasyonlar
Bunu da monday isimli uygulamadan aldım.
Kullandığınız iş takip sistemini çeşitli uygulamalar ile entegre edilebiliyor olması onun sadece başka uygulamalar ile entegre olabildiği anlamına gelir. Bunu kullanıp problemlerinizi çözeceğinizi garantilemez.
Biraz Entropi
Benim katı, Nicholas Taleb’ in kırılgan diye tasvir ettiği durumda siz sistemi kontrol altına tutmaya zorlarsınız, sistem de bozulmakta ısrarcıdır. Baskılamak yalnızca sistemi daha kötü noktaya evirir. Korkularınızda size hak veriyorum. Birşeylerin öngörülemez olması elbette herkes için korkutucudur. Ön görülemeyen zaten öngörülemeyecektir. Bu korkuyu, kaynaklarınızı
- Jira makinasını tatmin etmeye,
- Sizin işinize yaramadığınızı bildiğiniz metodolojileri kullanmaya devam etmeye,
Harcamayınız.
hidden
John von Neumann – The Man from the Future
Before I read The Man from the Future by Ananyo Bhattacharya, I only knew about John von Neumann in two contexts: that computers use the von Neumann architecture, and that he appeared in a story about a mathematical problem I … Continue reading →
via Henrik Warne's blogThe Review Is the Action Item
2024/05/30The Review Is the Action ItemI like to consider running an incident review to be its own action item. Other follow-ups emerging from it are a plus, but the point is to learn from incidents, and the review gives room for that to happen.This is no…
via Ferd.caHOWTO: Change your behavior
In theory, behavior change should be easy. At first glance, it seems like you control your behavior. So, if you desire different behavior, why doesn’t your behavior change as instantly as your desire to change it? In short, lasting change of habitual behavio…
via Matt Might's blog