Prosedürler

Genel kanıya göre organizasyonlar büyüdükçe iş yapma biçimlerini yazılı hale getirmeye, yani prosedürlere/süreçlere ihtiyaç duyuyorlar. Bunun ne kadar doğru olduğunu şimdilik bir kenara bırakalım. Temel sav işlerin tekrarlanabilir/öngörülebilir bir kalite seviyesinde yapılabilmesi. Prosedürler özellikle hataları önleme görevi görüyorlar. Ezberci, "olsa iyi olur" yaklaşımlarla prosedürler hazırlandığında ise pratikle alakasız fantazilerle dolu hale geliyorlar. Prosedürleri hazırlarken sorulması gereken üç soru var:

* Çözmeye çalıştığımız problemin oluşma olasılığı yüksek mi?
* Sorun oluştuğunda hayati problemlere yol açacak mı?
* Yazılı kurallar olmadan sorunu aşmak zor mudur?

Eğer bu üç sorunun hepsine birden EVET demiyorsak yazılı kurala gerek yok demektir. Antoine de Saint-Exupery'nin tasarım için söylediği prosedürler için de aynen geçerlidir.

Yazılı kuralların esnekliği, yaratıcılığı, dolayısı ile de motivasyonu ve verimliliği olumsuz etkileme gibi çok ağır bedelleri olabileceği unutulmamalıdır. Atılan taş ürkütülen kurbağaya değmelidir.

Üç soruya evet dedikten sonra kuralları yazarken de her maddenin yanına mutlaka kuralın neden yazıldığını, neye dayandığını belirtmek gerekir (Geçmişte yaşanmış X olayı, ISO 9000 madde bilmemkaç gereksinimi vb.) Böylece kuralın neden var olduğunu herkes anlayabilir, izlenebilirlik sağlanmış olur.

İşyerindeki yazılı süreçlerin başarısı, süreçten ne kadar az bahsedildiği ile doğrudan ilgilidir. Eğer sürekli süreçlerden bahsedilmeye başlamışsa süreçler aksıyor demektir. Başarılı prosedürler görünmez olanlarıdır.

Başarıya giden en kısa yol ise prosedürlerden değil, insanlardan geçer. İşyerine çalışan olarak süper kahramanları alın ve gelişmeye, eleştiriye açık uygun ortamı sağlayın (misal vasat insanları Dar-ül Aceze'ye havale edin). Süper kahramanlar işleri düzgün yapmak için ne gerekiyorsa (hem teknik, hem de idari manada) zaten yapacaklardır.

Hitting the high notes:

"The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce."

Clay Shirky on Process: "...Clay Shirky’s observation that “Process is an embedded reaction to prior stupidity”. ...an organization slowly forms around avoiding the dumbest behaviors of its mediocre employees, resulting in layers of gunk that keep its best employees from doing interesting work, because they too have to sign The Form Designed to Keep You From Doing The Stupid Thing That One Guy Did Three Years Ago"

"Take a quick read through the (Joel recommended) book “Slack”. The author makes an interesting observation about process: the hard part is not covered by the process.

For example, to fix a bug:
a) create a branch
b) create a test
c) when the work lasts more than 4 hours, write a spec
d) fix the code
e) checkin and test

Obviously, the real work is in b & d and maybe c, but the process doesn’t help you do that. The process is helping with the easy things."