Ticket Oluşturma Standartları

Daha önce indash isimli jira’ya benzeyen bir proje yönetim sistemi kodlamıştım. O zamanlarda çok dikkat etmediğim bir noktaya değineceğim.

Mevzu;

Proje yönetimi, buglar, yenilikler için önemli olan bir sistem kullanmak işe yaramıyor. Bu nedenle kullandığınız yönetim sistemini de doğru kullanmak gerekiyor. Örneğin bir yazılım için açılmış bug grubuna yeni bir hata yazacaksınız. Genelde sadece hatayı o an aklımıza gelen iki üç kelimeyle belirtir geçeriz. Yada karşılaştığımız sorunu yazarız uzun uzununa, belkide sadece çözüm aklımıza gelir onu yazarız. Diyelim ki bu şekilde yazdık. Personeli projenin tamamına hakim olmasını beklemek çok acınası bir durum olur. Bazen bu yapıldığında yeni personelin işlere adaptasyonu 6-7 ay sürebilecektir.

Kötü Sonuçlar;

İş kolundaki kişi sizin gönderdiğiniz ticket yada bildirimi anlamayacaktır muhtemelen ve tekrar sormak zorunda kalacaktır. Bu senaryo soracak kimse olmadığı zaman dahada kötüleşir. İşi devrettiğiniz bir personelin elinde anlamadığı bir todolist’le kalmasıdır. Zaman ve kaynak israfı olacağı aşikardır. Yada siz sorunu yazdınız güzel güzel anlattınız, personel söz konusu problemde karar yetkisine sahip değilse çözüm için gene size sormak zorunda kalır. Hangi çözümü uygulaması adına karar veremeyecektir veyahut insiyatif alır ve sonucu yanlış kararsa işleri başa saracaktır. En kötü karar kararsızlıktan iyidir denebilir ama, verilecek kötü kararlar zaman ve kaynak israfına yol açıyor ve bunu engellemek elimizdeyse neden yapmayalım. Diğer bir senaryo siz çözümü yazdınız, personelin en sevdiği ticket bildirim şekli, hemen tak tak yapar geçer. Ama bu tarz sorunların %60’ı tekrar gönderilir veya başka sorunlara yol açar. Personel yazanı yapar ama bu sorunun neden kaynaklandığını bilmediği için uyguladığı çözüm ya başka bir varyasyonu karşılayacak yada başka varyasyonlarda işe yaramayacaktır. Genel itibariyle zaman ve kaynak israfı sözkonusu olacaktır.

Nasıl Çözeriz;

Ticket içeriğinin düzgün şekilde belirlenmesi gerekir. Yani sorun, sonuçlar, çözüm ve varyasyonlar (yan etkileri) belirlenip o şekilde oluşturulmalıdır. Ek olarak olacak olan çözümden sonra ne fayda sağlanacak bu belirtilebilir. Bu sayede açılan bildirimin yada ticket ın yada ismine ne diyorsanız anlaşılır olacak  ve hızlı bir şekilde çözüme kavuşacaktır.

Ne Sağlar;

Personel oryantasyon süreçlerini yokeder, projede dış kaynak yani outsource denilen kaynakları dahil edebilirsiniz. 20 yıl sonrada baksanız, ne ne için nasıl neden yapılmış anlamanıza yardımcı olur. Hangi nedenle ne düşünülerek bu işin yapıldığını rahatlıkla görebilirsiniz. Personel açısından bakacak olursak karşısındaki dolu bir todolist olur, gözgezdirirken bağlantıları farkeder ve sorma anlama araştırma ve çözüm süreçleri hızlanır. Daha fazla iş yapar mutlu olur :)

Notlar;

Peki herşeyi verdik kalanınıda biz yaparız düşüncesine kapılanlar olabilir veya herşeyi ben söyledikten sonra ne anlamı var adam sorsun bulsun yapsın diyebilirsiniz. Varsa o kadar zamanınız kaynağınız tabi keyfinize bakın. Ama işi verdiğiniz developer, usta, işçi, eleman, personel neyse ne gözle baktığınızı bilmiyorum, işine odaklanırsa o iş düzgün güzel ömürlük olur. Geri kazanılamıyacak tek şey zamandır, fazladan vereceğimiz bir iki satır bilgi bize saatler günler belkide haftalar kazandırabilir.



Bu yazı 514 kez görüntülendi.


Bir Cevap Yazın