Arşiv

‘Yazılım’ kategorisi için arşiv

Yazılım Çalışanlarının Fazla Mesai Bildirisi

Pazar, 04 Eyl 2016 Yorum yapılmamış

1.Yazılım geliştirme süreçlerinin doğasında mevcut olan bir fazla mesai yoktur.

2.Yazılım geliştirme süreçlerinde istinaî olarak var olması mâkul ve meşru planlı fazla mesailer; sürüm geçişleri(version updgrade) ve aktarım(migration) gibi öngörülebilir operasyonlar ile canlı uygulamayı ve kullanıcılarını etkileyen, ortadan kaldırılmasında acilîyet olan hataların düzeltilmesi(bugfix) işlemleridir. Bu durumlar haricindeki bir durumu istisna olmanın ötesine taşıyacak hiç bir süreç, yöntem ve yönelim kabul edilemez.

3.İkinci maddede bahsi geçen fazla mesai durumları hiç bir şart ve koşul altında ücretsiz çalışmayı gerektirmez. Yasal fazla mesai ücreti hiç bir şart ve koşul altında ikram, prim veya jest gibi sunulamaz.

4.İkinci maddede bahsi geçen durumlar söz konusu olduğunda yazılım yöneticilerinin, çalışanlarının hayatlarına doğrudan etkisi olan bir fazla mesai kararını onlardan bağımsız ve onlara aldırış etmeden alması veya dayatması yasal mevzuata uydurulabilirse de herhangi bir nezâket kuralı ile bağdaştırılamaz, herhangi bir edep dairesine dahil edilemez.

5.Ücretsiz, tamamen gönüllülük esasına dayalı(!) fazla mesai yapmayı kabul etmeyen yazılım çalışanının bu ahlakî ve de yasal olan tavrı onun aleyhinde bir çeşit yıldırma veyahut da bir çeşit suçluluk duygusu oluşturma aracına dönüştürülemez, özveri eksikliği olarak telâkki edilemez.

6.Yazılım geliştirme süreçlerinde, plana uyulmadığı veya işlerin son tarihe yetiştirilemeyeceği anlaşıldığında başvurulan ilk çıkış yolunun fazla mesai olarak görülmesi kabul edilemez.
Fazla mesai bir sonuçtur. Nedenler;

-İşlerin ve mevcut iş gücünün hakkı ile öngörülememesi, tartılamaması ve planlanamaması,
-Hızlı geliştirme temposunda kalitesinden ödün vermekte beis görülmeyen işlerin sorun yumağı olarak geri dönmesi,
-Müşteriye olmadık vaatler verilmesi,
-Müşteriye birtakım sözler verilirken, işler planlanırken ve takvimlendirilirken fazla mesai fikrinin hep yedekte tutulması,
-Üründe varolmayanın pazarlanması, satılması
-Hem haddin hem de istiap haddinin bilinmemesi,

veya tüm bunları özetleyecek bir diğer ifadeyle “sınırlı kaynaklar ile sınırsız isteklerin karşılanma çabası”dır.

7.Yazılım çalışanları -söylemeye hâcet olmayacak bir şekilde- elbette ki x saat çalıştığında k birim verim alınıyorsa 2x saat çalıştığında 2ķ verim alınan mekanik varlıklar değildirler. Onların da tıpkı diğer insanlar gibi duygusallıkları, acıları, can sıkıntıları, sevinçleri, aşkları, özledikleri eşleri dostları vardır. Onlar da memleketteki veya dünyadaki herhangi elem verici bir hadiseden etkilenebilirler, akşama doğru üzerlerine bir hüzün çökebilir, bahar geldiğinde onlara da bahar gelebilir, hatta bulutlu güneşsiz bir günde verimden epey düşebilirler.

8.Yazılım çalışanlarının toplam iş gücü bir havuzu dolduran musluklar gibi değerlendirilemez. Bir havuzu 2 musluk 10 saatte dolduruyorsa 4 musluk 5 saatte doldurabilir. Zîra muslukların tecrübesinden, teknik kabiliyetinden, iş bilgisinden, özverisinden, motivasyonundan ve insanî bir takım vasıflarından söz edilemez. Aynı zamanda bu muslukların birbirleri ile uyumundan, doğru iletişiminden, yardımlaşmasından ve birbirine destek olmasından da bahsedilemez. Onlar musluktur. Yazılım çalışanları değil.

9.Altıncı, yedinci ve sekizinci maddede kabaca belirtilen hususların dikkate alınmadığı her plan aksamak, her takvim gecikmek ve fazla mesai sarmalını yeniden üretmek durumundadır. Aynı zamanda ve çok daha önemli olarak, bu durumun yılgın, huzursuz ve elinden geleni yapma niyeti ile gayreti sekteye uğramış çalışanlarla neticelenmesi kaçınılmazdır.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Refactoring

Pazar, 23 Şub 2014 3 yorum

Büyük oranda Martin Fowler’ın “Refactoring – Improving The Design of Existin Code” kitabından faydalandığım Refactoring eğitiminin sunumunu paylaşayım dedim, bir faydası dokunması umuduyla.

Martin Fowler‘ın tanımıyla Refactoring yazılımın gözlemlenen davranışlarını değiştirmeyen, fakat iç yapısını değiştiren bir dizi küçük iyileştirmedir.

Sunum kabaca şu başlıklardan oluşuyor;

  • Refactoring Nedir ?
  • Neden Refactor Etmek Gerek ?
  • Ne Zaman Refactor Etmek Gerek ?
  • Nasıl Refactor Etmek Gerek ?
  • Refactoring Kataloğu

Not : “Refactoring”, “refactor etmek” gibi tabir ve terimlere Türkçe’de getireceğim karşılıklar kulak tırmayalayabileceği için oldukları gibi kullanmak durumunda kaldım.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail