BAŞA DÖN

İş takip ve verimli toplantılar ile başarıya ulaşın.

Bir firma'da işlerin akışının kontrol altında tutulabilmesi için en önemli şey "takip" olsa gerek. Atanmış bir iş ne durumda, hangi aşamada takip edilemiyorsa işin başarısızlıkla sonuçlanması (mutlak başarısızlık olmasa da, süre aşımları, tutarsız sonuçlar, teslim edilse de mutsuz müşteri) kaçınılmaz olacaktır. İş takibi için herkese uygun kesin bir kurallar silsilesi tanımlamak oldukça zor. Her yiğidin yoğurt yemesi farklı olduğu gibi her kurumun, hatta alta doğru indikçe her birim yöneticisinin kendine has yeme tarzları ortaya çıkabilir, gayet normaldir. Yeter ki yoğurt yenirken etraf batırılmasın (insanlar/kurum zarar görmesin.)

İş takibi deyince 3 ana madde aklıma geliyor:

  1. Kişinin iş sürecini raporlaması (gün sonunda, haftalık, iş ara kademelerinde raporlama). Böylelikle işiniz ile ilgili ana hatları amirleriniz rahatlıkla görebileceklerdir.

  2. İşin akışında (karar mercisi kendiniz de olsa) ilgili kişilerin haberdar edilmesi. (Söz uçar yazı kalır misali, firma içi dahil olmak üzere ilerleyişin email ortamında kayıt altına alınması ve ilgililerin cc yapılması. İlla sorun olacak diye birşey yok, üzerinden vakit geçmiş projelerde email geriye dönük olarak çok güzel bir arşiv aracı olarak kullanılabilir) İyi oturmuş bir kurum içi mesajlaşma (en pratik yolu ile email) sistemi ile ilgili herkes işler ile ilgili kendilerine bakan durumlara hızla vakıf olup müdahil olabilecektir.

  3. Rapor ve bilgilendirmeler ekibi ve yöneticileri canlı tutsa da mutat (düzenli) toplantılar ile ilgili birimlerin koordine edilmesi ve sorun olmadan önce frekans farklılıklarının normalleştirilmesi.

Bu 3 süreç içerisinde yukarıda bahsettiğim gibi farklı yorumlamalar, yeni alt modeller rahatlıkla geliştirilebilir. Mesela nadir de olsa bazı çok uyumlu frekansla çalışan ekipler arasında 3 değil 2 madde ile de süreçler işletilebilir. (sonra onlar da 3'lü bu yapıya dönerler :) Rapor mantığı her ekipte farklı işleyebilir, kimi ekip email ile raporları alırken, yazılım tabanlı işler için raporlar bir istek takip sisteminde (issue / bug track) tutulabilir, sözün özü bunlar tamamen sizin kendi yoğurt yeme tercihinizle ilgili.

İlk 2si konusunda olmasa da toplantılar konusunda belirli standartlar zaman içinde oturmuş durumda. Bunu teknoloji seviyenize göre internet üzerinden de (Skype vb.) yapabilirsiniz. İster sanal ister canlı kanlı bir araya gelin, o da çok farketmez, yeterki yanlış anlaşılmalara fırsat vermeden birbirinizin sesini duyarak, mümkünse görerek, işlerin önünü açın. Toplantılar için de birkaç şey net söylenebilir:

  1. Toplantı işin bir parçası, bunu hem siz hem ekibiniz kabul etmeli ve angarya olarak görmemeli. Verimli bir toplantı işlerin daha kaliteli ve değerli sonuçlar üretmesine yardımcı olacaktır.

  2. Toplantınızın gündemi olsun. Eğer özel bir toplantı ise (bir iş ile ilgili düzenli toplantılarınız dışında, müşteri projesi vb.) 2-3 gün önceden gündemi katılımcılar ile paylaşın. Ne konuda görüşüleceğini bilmeli ve hazırlanmalılar. Eğer mutat bir toplantı ise (haftalık değerlendirme toplantısı gibi) katılımcılar bir önceki haftadan gündeme sahip olacaklardır. Katılımcıların da varsa genel gündemlerini alın. (Sizin de hazırlanmanız gerek, alamadı iseniz toplantı başlangıcında da alabilirsiniz.)

  3. Önceki toplantıdan kalan maddelerin üzerinden geçin. İşler konuşuluyor, kalıyor durumuna düşmesin.

  4. Gündemde sabit kalın. (Ara maddeler almayın)

  5. Soru cevaplar ile sırası gelen gündem üzerinde çözüm odaklı olarak görüşmeleri yapın. Karşıdaki düşmanınız değil, iş arkadaşınız (veya müşteriniz)

  6. Tartışma zeminine girmeyin, çözüm bulamıyorsanız, ilgili maddeyi üzerinde düşünmek üzere erteleyin.

  7. Sohbet (geyik) zemininden kaçının. Çay, kahve servisi sırasında bile (özel bir madde değilse, bütçe vb.) görüşmeleri kesmeyin. Geyik başlarsa toplamak zor olacaktır. Fren yapan araba gibi hızınızı kaybedersiniz.

  8. Nokta atışı ilerleyin. Yan meselelerde boğulmayın, ana konuyu çözün. Ana konu hedeflenirse yanlar için çözüm bulunacaktır.

  9. ve en önemlisi, toplantı için süre sınırı belirleyin ve o süreyi aşmayın. 2 saatlik bir görüşme çoğu insanının limitlerini zorlayacaktır. Bu yüzden mümkünse gün başlarken mesai başlangıcında, zihinler berrak, işler henüz hücum etmemişken toplantılarınızı yapın. Az zamanda çok iş yaparak sonuca ulaşın.

Elvedâ emektar...

İlk ne kullanıyorduk sunucu olarak hatırlamıyorum ama sonrasında Gandalf(*) isimli bir sunucu kurduğumu biliyorum. 1 küsür yıl kadar Gandalf ile merkezi işlerimizi hallettikten sonra "Bu sefer Türk kökenli bir bilge olsa?" diye düşünerek, Akşemsettin'de karar kılıp, ismi -network ortamında daha rahat kullanılabilmesi için- "ŞEMS/SEMS" olsun diyerek SBS 2003 kurmuştuk.

Geçtiğimiz haftalarda başladığımız günceli yakalama ve yaz temizliği operasyonunda sıra Şems'e geldi. Yeni Active Directory + Exchange sunucu donanım ayarlamasından sonra isim olarak ELBEY seçtik(*).

Şems'i yayından kaldırmadan önce kurulum zamanına bir bakayım dedim, 10 Aralık 2004'de kurmuşuz.  4.5 yıldır durmaksızın bize hizmet vermeye çalışmış. Yeri geldi çok kızdığımız, neden takılıp kalıyor dediğimiz olsa da, çok cefamızı çektiği de aşikâr. Biraz da o yüzden eski bir dosta, güle güle diyeyim istedim. Elvedâ, tekrar gelmemek üzere(*)...

*Neden mi Gandalf? : Yüzüklerin Efendisi serisi sinemaları kasıp kavuruyordu o  zamanlar.
*Neden mi Elbey? : Memleket özlemi yahut öze dönüş :) www.elbeyli.org
*Şimdi Şems'in efsanesini Gelgit(*) (CVS/SVN sunucusu) devam ettiriyor sistem odasında
*Neden mi Gelgit? : Önceden ismi ARGE idi. Yeni sisteme taşınınca kodlar geliyor gidiyordan yola çıktık.


HTML DOM nedir?

Eğer yaptığınız iş internet ile ilgiliyse, mutlaka HTML, HTML DOM ve Javascript terimleri ile çok karşılaşmışsınızdır. Ama çoğu kimse sadece işine yarayacak kodları alır, kopyalar ve çalıştırır. Gerisine hiç karışmaz. Oysa bir teknolojinin yapısını ne kadar iyi bilirseniz ona  okadar hakim olursunuz ve o ölçüde isteklerinizi onunla rahatlıkla yerine getirebilirsiniz. Mesela uçakla bir adaya düştünüz, yanınıza da 3 şey alamadınız :) acil olarak da matematiksel bir hesap yapmanız gerekiyor. Bu durumda eğer iyi bir marangoz iseniz oduna şekil verme teknolojisini kullanarak bir abaküs yapar onunla yetinirsiniz. Mekanikçi iseniz uçakdaki metallerle mekanik bir hesap makinesi yapmanız mümkün. Elektronikçi iseniz uçakdaki devreleri kullanarak dijital bir hesap makinesi yapabilirsiniz. Yok bilgisayarcı iseniz aklınıza gelen ilk şey uçağın bagaj bölümünde bir Laptop aramak olacaktır :) Kısacası uğraştığımız teknolojilerin yapısını bilmek bizim sonuca gidiş şeklimizide değiştirebilir.

Gelgelelim DOM olayına. HTML bir dil değildir, bir arayüzdür. Javascript,VBscript,vs.. ise birer dildir.  Programlama dillerinin object-oriented olarak HTML ile anlaşması için HTML'i nesneler bütününe çevirecek bir ara standart gereklidir. İşte HTML DOM da tam bu noktada ön plana çıkar.DOM, HTML ile programlama dilleri arasında bir standart oluşturarak bu dillerin HTML den bilgi alıp, bilgi vermesine yardımcı olur. DOM, Nesneler ve özelliklerden oluşur. Herhangi bir metod veya işlem içermez.

Sonuç olarak eğer client-side olarak HTML' e daha fazla hükmetmek istiyorsanız, kullandığınız dil jscript,vbscript ne olursa olsun kesinlikle DOM un erişim yöntemlerini çok iyi biliyor olmanız gerekir.Piyasada DOM ile alakalı olarak bilgi bulabileceğiniz birçok döküman var ama işin derinine inmek için DOM'un hiyerarşisini iyi öğrenmek lazım. Benim bu noktada tavsiye edebileceğim en güzel kaynaklar

EN: http://en.wikipedia.org/wiki/DOM_Events

TR: http://www.mynotlar.com/html_dom/default.aspx

İyi Çalışmalar


Neden yazılım uzmanı olmazsınız?

Bir süredir aklımda ve notlarımda olan, "Kodlarken Maestro Olmak" yahut "Koddaki huzur , mutluluk budur :)" başlıklarına yakın bir yazı için kolları sıvamışken, Gürkan Yeniçeri'nin bloğunda "Yazılım Uzmanı Olamayacağınızın 10 Kanıtı" isimli yazıyı gördüm.  Yazının ilk orjinalini yazan Justin James dışında Gürkan Yeniçerinin de çeviriyi yaparken çok güzel yorumları ve eklemeleri olmuş. Aklımdaki yazıyı biraz daha düşünürken, önce 10 kanıtı iyi bir okumak, konuya ısınmak lazım.

Neden yazılım uzmanı olmazsınız?

  1. Kendi kendine öğrenmek yerine kursları tercih ediyorsunuz
  2. Normal çalışma saatlerini seviyorsunuz
  3. Küçük maaş artışlarını kıdem yükselmesine tercih ediyorsunuz
  4. Ekip çalışmasında insan ilişkileriniz pek iyi değil
  5. Kolayca sinirleniyorsunuz
  6. Ekip elemanlarının fikirlerine kapalı iseniz
  7. Detay adamı değilsiniz
  8. Yaptığınız işten onur duymuyorsunuz
  9. Önce ateş edip sonra soru soran tiplerden misiniz?
  10. “Geek” tipini sevmiyorsunuz

Sayfadaki yorumlarda katılımcılar birkaç ekleme daha yapmışlar. Liste elbet daha da uzatılabilir ama  bu haliyle bile tabiri yerinde ise "cuk" diye oturmuş ve en temel tespitleri içinde barındırıyor. Sizce de öyle değil mi?


Yazılım Geliştirmede Olgunluk: CMMI ve XP kullanımı

CMMI ve XP, özellikle yazılım geliştiriciler arasında son zamanlarda sıkça duymaya başladığımız kavramlar arasında yeralıyor. 

Değerli arkadaşım Orhan Kalaycı'yla yaklaşık 7 yıldır tanışıyoruz. Orhan, yaklaşık 4 yıldır Türkiyede CMMI ve yazılım kalitesini geliştirmek için büyük çaba sarfediyor. Yaptığı seminer, yazılar ve firmalara verdiği profesyonel danışmanlık hizmetleri ile Türkiyedeki yazılım sektörünün gelişmesi için sözde değilde özde iş yapanlar arasında yeraldığını düşünüyorum.

Orhan Kalaycı'nın Türkiye Bilişim Derneği tarafından düzenlenen Kurumsal Yazılım 2007 kurultayında verdiği "CMMI ve XP uyumu" konulu seminere katıldım. (sağolsun kendisi davetiyede ayarlamış :) ) Hem bilgilendirici hemde Cem Yılmaz vari esprileriyle çok başarılı bir seminer verdi.

CMMI ve XP ile daha fazla bilgi almak istiyorsanız Orhan Kalaycı'yı bizzat dinlemenizi veya www.nitelik.net adresini takip etmenizi öneririm.