İş dünyasına bakıldığı zaman, görünen şeylerden bir tanesi, gücün bilgi ile eşdeğer olarak gitme davranışı mevcut olduğudur.
Bu bilgi yumağı, hangi sektörde olursa olsun, firmaların sadece ileri gitmesi veya başarılı olmasını değil, varoluşlarını da direk etkileyen bir değerdir. Aynı değerlendirmeler belki ülkeler için dahi yapılabilir.
Bilgiden kasıt, çok farklı şeyleri içerebilir. Ticari değeri olan bilgi olarak ilk başta görünebilecek olan direk iş imkanlarıyla ve satışla alakalı olabilecek bilgi veya rakipler ile ilgili bilgi olsa da, aslında daha önemli olan bir takım bilgiler kurum kimliğini oluşturur ve rekabet gücünü belirler.
Bu bilgi, arasında, insan kaynakları politikası, muhasebe ile ilgili yaklaşımlar, proje yönetimi, firma içerisinde tanımlanmış olan süreç davranışları, stratejik kararlar ve yol haritası, bazı kişi ve kurumlara karşı belirlenmiş davranışlar, projeler süresince edinilmiş tecrübeler olabilir.
Bir otomotiv üreticisi için otomotivin nasıl üretildiği, hangi maddelerin kullanıldığı, ideal maaş skalaları vb gibi tüm bilgiler, değeri olan, işletmeyi yürütmek için belirli kriterler dikkate alınarak meydana gelmiş bir karar yumağıdır.
Yazılım sektörü için, bu bilgi bahsedilen konular dışında, ayrıca, yazılım geliştirme metodolojileri, tekrar kullanılabilir kod parçacıkları ve componentlar, kullanılan toollar ile ilgili edinilen tecrübeler, kullanılan teknolojiler olduğu kadar, bu kodlar kullanılarak hayata geçirilen alan bilgisi de çok önem taşımaktadır. Örnek olarak, bir muhasebe yazılımındaki alan bilgisi, sadece muhasebe yazılımı içerisinde kalamayacak kadar değerli bir kaynaktır. Bu bilgiye ihtiyaç olan herhangi bir başka projede erişilmesi gerekecektir.
Bilgi Koruma
Mevcutta genel davranış, bir kişiyi alanla ilgili bilgilendirmek ve bu alanla ilgili işler yapılması gerektiği zaman bu kişiye yaptırmak, imkanlar daha geniş ise bu alanı bilen kişi(ler) i istihdam etmek şeklindedir. Ancak bu davranış, bilginin paylaşılmasını engeller, kurumu kişiye bağımlı hale getirir. Bu kişi bilgiyi kurum içerisinde kazanmış veya kurum içerisine bilgiye sahip halde gelmiş olabilir, ancak gittiği zaman bu bilginin kuruma kazandırılmış olması, kurumların kişilerden bağımsız olmasını sağlayabilir.
Aynı zamanda, tek kişinin sahip olacağı bilgi, kurumun tümünün sahip olacağı bilgi kadar fazla olamayacağından, tek kişi, sadece kendi bilgisi ile kararlar verme ve hareket etme mecburiyetinde iken, kurum içerisinde yoğurulabilen bir bilgi, kurumda yayılarak, farklı fikirlerin birleşmesi ile, daha olgun bir hale gelir.
Firmalar her zaman kendi çıkarlarını kollamalı, yapmış olduğu yatırımları korumalıdır. Bu amaçla müşterilerle ilişki sıkı tutulur, çalışanların memnuniyeti dikkate alınır, kurumun toplumdaki bilinirliği ve güvenilirliğini artırmak için çalışmalar yapılır. Kurumun değerli sayılabilecek her türlü mevcudatı korunmaya çalışılır. Ancak, en önemli rekabet gücünü oluşturacak olan bilgi, unutma kadar olası bir olayın oluşumuna karşı dahi önlem almamış durumdadır.
Bu fikirler ışığında, bilginin kollanması, korunması ve paylaşılması gereksiniminin olduğu net olarak gözükmektedir.
Bilgi Paylaşımı
Özellikle yazılım sektörü için, yeni işe başlayan bir kişinin bilgilendirilmesi ve veriminin artırılması çok önemlidir. Mythical Man Month'da belirtildiği üzere, yazılım yapan kişiler arasındaki fark 1/20 kadar olabilir. Yani, iki farklı kişi için, bir kişi diğerine göre 20 kat daha verimli iş üretiyor olabilir. Bu durumda, 1 birim üretim yapan kişiyi 20 birim üretim yapar hale getirmedikçe, tam kapasite kullanımı olduğu söylenemez. Bu, teknik açıdan bilgi paylaşımıdır.
Yapılan yazılım hangi alanda olursa olsun, bir firmanın daha önceden hakkında bilgi edindiği bir alanda çalışma yapması durumunda, daha önceki bilgilerinden faydalanması, bu firmanın iş becerisini, karlılığını, doğruluğu ve müşteri memnuniyetini artıracaktır. Bu davranış, büyük yabancı yazılım firmalarında net olarak gözlenebilir. Bilgileri ve tecrübelerini farklı ülkelerdeki çalışanlarına dahi aktaran bu firmalar, birikmiş tecrübeleri sayesinde rekabet edilemez bir güç olmayı başarmışlardır. Bu bilginin oluşturulup, herhangi bir alanda yazılım analizi veya geliştirme esnasında elde edilen bir bilgi, paylaşılmalıdır.
Bilgi paylaşımı, sadece bilginin korunması ile sağlanamayacaktır. Bilgi, şu anda zaten mevcuttur. Bu bilgi kitaplarda veya internettedir ancak bu şekilde saklanan bilginin kazanılması, aktarımı, paylaşımı çok zaman alan bir iştir. Paylaşılabilecek bir bilgi, öncelikle kolay bulunabilir olmalıdır. Ayrıca, ihtiyaç olunduğu zaman kolay bulunabilir olmalıdır. İhtiyaç olunduğunda bulunamayacak veya ihtiyaç olunmadığı zamanda bulunacak bilgi kümesi faydalı değildir. Geçmişte yapılan projeye benzer tekrar yapılan bir projedededir ki geçmişte ihtiyaç duyulan bilgiden faydalanılabilsin.
Bu fikirler doğrultusunda, knowledge management alanında çalışma yapmaktayım. Bu çalışma kuşkusuz bir tool veya yazılım olmadan gerçekleştirilemeyecektir. Öncelikle,
- Ortak saklama alanı yaratılmalı
- Ortak paylaşım alanı yaratılmalı
- Kişiler paylaşmaya sevkedilmeli
- Paylaşılacak bilgi belirlenmeli
- Ulaşılması istenen bilgiye ulaşmak için yöntemler bulunmalı
Bunlar doğrultusunda wiki ile çalışmaya başlayacağım. Kurumsal bir wiki kurulumu yapıp, bilginin aktarılmasını bir rutin davranış haline sokmak, sanırım ilk başarı adımı olacak.
Yazılım Yönetimi etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Yazılım Yönetimi etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Pazar, Şubat 25, 2007
Pazartesi, Ekim 02, 2006
Yazılım Sektörü ve İnsan Kaynakları
Diğer üretim sektörlerine bakacak olursak, maliyet düşürme ve hızlı iş yapabilme, akıllı bir yatırımcının ön şart olmasıyla beraber, yatırım miktarındadır. Bu yatırımın çok büyük bir kısmı, üretimde kullanılan sistemlerin alınması, tezgahların makinaların yani otomasyonun kullanımı ile doğru orantılıdır.
Sanayileşme ile beraber gelen bu yaklaşım, işçilerin azaltılması ile üretim maliyetinin düşürülüp hızlı ve ucuz iş yapabilme sonrasında rekabet gücü getirir. (Her ne kadar Çin'de tersi olsa da, bir süre sonra orada da işçi maaşlarının maliyeti artırıcı bir faktör olacağı kanaatindeyim.)
Böyle bir kuruluş sonrasında, artık işletmecinin ihtiyaç duyduğu kaynak bu makinaları düzgün çalıştıracak elemanlardır. Makinalar düzgün çalıştığı takdirde üretim devam eder.
Yazılım sektörü için, her ne kadar ofis yerleşimi, kullanılan yardımcı yazılımlar, bilgisayarlar vb etkili ise de, diğer sektörlerle kıyaslanamaz dahi. Belki yazılım diğer sektörlere göre emekleme aşamasında olduğundandır, sonuçta diğer üretim dalları yüzyıllardan beri gelen bir birikimin sonucundaki bilgileri kullanmaktadır. Yakın gelecekte de bunun değişeceği gözükmediği için, insan kaynaklarına ve iletişime biraz daha önem verip eğilmeliyiz düşüncesindeyim.
Bu konuyu iki kısımda incelemek istiyorum. Birinci kısımda, kişi farklılıklarının performansta sağlayacağı etkiler, ikinci kısımda ise ekip çalışması ve iletişimin önemine değinmeye çalışacağım.
Birinci Bölüm - Yazılımcı Performansı
Yazılım süreçleri, zamanlama ve çalışanlar ile ilgili konuların ele alındığı Mythical Man Month isimli kitapta, yazılımcılar arasındaki farka değinir.
Elde edilen verilerden, deneyimli ve başarılı bir yazılımcının diğerine oranla 20 kat hızlı iş ortaya çıkarabildiği gözlenmiştir.
20 ye 1 korkunç bir rakam aslında, başka hiçbir üretim sektöründe karşılaşılamayacak bir rakam belki de. Bir fabrika için 1 işçinin 20 işçinin çıkardığı işi çıkarabildiği düşünülebilir mi ?
Bunu sektörde olan herkes gözlemlemiştir, iş kişiye çok bağımlıdır. Bu iki sorun ortaya çıkarır, birincisi bu kişinin ayrılması durumunda bilginin kurumda kalma zorluğu, ikincisi bu tür kişilerin az bulunur ve yüksek maaş talep eder kişiler olmasından dolayı diğer çalışanlar üzerinde oluşturacağı huzursuzluk ve işlerin bu kişiye çok bağımlı olması. Bu konulardan bahsetmeyeceğim.
Durum bu şekilde ise, 20 kişilik olmasa bile 5 kişilik iş yapacak bir kişinin 5 kişilik maaş alması da makul gözükmektedir.
Asıl sorun, bu kişilerin nasıl bulunup nasıl işe alınacağıdır. Teknik bilgisi üstün olan kişilerin mülakatlarda çok başarılı olduğu söylenemez, bunun yanısıra insan ilişkileri kuvvetli olan kişilerin bir kısmının da teknik açıdan daha zayıf olabileceği ortadadır.
Ekip Çalışması
Yazılım için şu anda ve yakın gelecekte iş yapacak olan insandır ve daha çok iş yapmak isteyen daha fazla insana başvuracaktır. İnsan faktörü vazgeçilmez olarak gözükmektedir. Ancak, sektörün çoğunluğu ki en başta çalışanlar, işin aslında kod ile veya bilgisayar ile olduğunu düşünmektedir. Bu yaklaşımın doğru yanları olsa da, gözardı edilen en önemli nokta, iletişim ve insan kaynalarının diğer sektörlere göre çok daha önemli olduğudur.
Tabii tek kişilik projeler ile çalışan bir şirketten bahsedecek olursak bu geçerli olmaz, ancak iki kişi bir projeye girdiği andan itibaren bu yapılandırma önem kazanır. Teknik bilgisi çok yüksek olan ancak karşısına derdini anlatamayan veya geçinilemez kişilerin çok olduğu sektörümüzde, tek adamlar çok fazladır, sektördeki herkes bunu yaşamıştır.
Projelerdeki en büyük sıkıntılar iletişim sorunlarından kaynaklanmaktadır, zira bir ekip olarak çalışmasını bilmeyen alışanlar ve ekip olarak çalışılmasının önemini bilmeyen yöneticilerin olduğu sektörde bu konu gözardı edilmektedir.
Teknik temelli kişilerin çoğunluğunda bu tür konuları gözardı etme, iletişimin önemine inanmama veya böyle bir kavram olduğunu bilmeme gibi bir sorun mevcuttur. Eğitimde bunlara değinilmemesi sorunun bir bacağı olabilir.
Nasıl bir iş makinası kürekli ama çok güçlü bir adamın yapacağı işin yüzlerce katı fazla işi daha kolay yapabilirse, ekipler ve iş dağılımı ile aynı şekilde hızlı iş yapılabilir. Yaşanan sıkıntının ilki, özellikle yetkin kişilerin ekip içerisinde çalışmada sıkıntı çektikleri, daha az bilgili olan kişilerden sürekli biat ve itaat istedikleri gözlemlediğim şeylerden birisi, ki geçmişte bu şekilde davrandığım zamanlar çok oldu, sonrasında ekibe zarar verme ve işi ya tek başına yüklenme veya ekibin tamamıyla iş yapamaz hale gelmesi gibi durumlarla karşılaşılır.
Bunu engellemek için ekip çalışması eğitimleri bir araç olabilir, en büyük sorun önce mantığın değişmesi, bir tek adam'ın hiçbir zaman daha az yeteneklerde de olsa birçok adamı yenemeyeceğini kavramak, daha sonra iletişim ile ilgili bir takım bilgilerin alınması sayesinde tek adam olmaktan vazgeçmeye gönüllü ancak başaramayan kişilerin hangi yollarla bunu yapabileceğinin kendilerine gösterilmesidir.
Ancak bu tür disiplinlerden sonra bir ekip olunabilir. Bunlar bittabi bütün sektörlerin konularıdır, ancak yukarıda da belirttiğim gibi, yazılım sektörü en çok insana bağlı sektörlerden biri olduğu için bizim açımızdan elzem konulardır.
Sonuç
Burada belirttiklerim bu konulara ancak bir giriş olabilir, ayrıca detaylı bir çalışma gerektiren bir konudur. Gözardı edildiği müddetçe optimum performans hiçbir zaman yakalanamayacaktır.
İnsan kaynakları ve iletişim yazılım için elzemdir ve bu konu ile ilgili bilgisi olan kişilere ihtiyaç vardır, ancak teknik bilgisi olmayan kişiler özellikle eleman seçimi sırasında manipülasyona açık olduklarından bu bilgiye de sahip olunması çok önemlidir.
Yazılım ekipleri eğitilirken sadece teknik eğitimler verilmesi çok yanlıştır, teknik bilgi yol gösterildiği zaman kitaplardan da alınır, ancak beşeri bilgiler kitaplardan kolay anlaşılacak ve kişinin hayatı boyunca kazandığı yetileri değiştirecek kadar kuvvetli etki yapamaz.
Kurum her kademesinde iletişimi desteklemeli ve herşeyden önce çalışanlarının rahatını ve üretebilirlik performansını gözlemeli, performans düşüşlerini ve moral bozuklularını, aynı zamanda anlaşmazlık ve takım içi çatışmaları çok yakından takip etmelidir. Yöneticilerin asli görevleri arasında diğer sektörlerden daha fazla ihtimam gösterecek şekilde bulunmalı ve yöneticilier bu konuda yetkin kişiler olmalıdır.
Sıkıntı gözlemlendiği anda gözardı edilmeyerek müdahele edilmelidir. Böylece, çalışanların bakımı rutin yapılan ve performansı hep aynı seviyede çalışan üretim tesisleri gibi olmaları sağlanabilir.
Sanayileşme ile beraber gelen bu yaklaşım, işçilerin azaltılması ile üretim maliyetinin düşürülüp hızlı ve ucuz iş yapabilme sonrasında rekabet gücü getirir. (Her ne kadar Çin'de tersi olsa da, bir süre sonra orada da işçi maaşlarının maliyeti artırıcı bir faktör olacağı kanaatindeyim.)
Böyle bir kuruluş sonrasında, artık işletmecinin ihtiyaç duyduğu kaynak bu makinaları düzgün çalıştıracak elemanlardır. Makinalar düzgün çalıştığı takdirde üretim devam eder.
Yazılım sektörü için, her ne kadar ofis yerleşimi, kullanılan yardımcı yazılımlar, bilgisayarlar vb etkili ise de, diğer sektörlerle kıyaslanamaz dahi. Belki yazılım diğer sektörlere göre emekleme aşamasında olduğundandır, sonuçta diğer üretim dalları yüzyıllardan beri gelen bir birikimin sonucundaki bilgileri kullanmaktadır. Yakın gelecekte de bunun değişeceği gözükmediği için, insan kaynaklarına ve iletişime biraz daha önem verip eğilmeliyiz düşüncesindeyim.
Bu konuyu iki kısımda incelemek istiyorum. Birinci kısımda, kişi farklılıklarının performansta sağlayacağı etkiler, ikinci kısımda ise ekip çalışması ve iletişimin önemine değinmeye çalışacağım.
Birinci Bölüm - Yazılımcı Performansı
Yazılım süreçleri, zamanlama ve çalışanlar ile ilgili konuların ele alındığı Mythical Man Month isimli kitapta, yazılımcılar arasındaki farka değinir.
Elde edilen verilerden, deneyimli ve başarılı bir yazılımcının diğerine oranla 20 kat hızlı iş ortaya çıkarabildiği gözlenmiştir.
20 ye 1 korkunç bir rakam aslında, başka hiçbir üretim sektöründe karşılaşılamayacak bir rakam belki de. Bir fabrika için 1 işçinin 20 işçinin çıkardığı işi çıkarabildiği düşünülebilir mi ?
Bunu sektörde olan herkes gözlemlemiştir, iş kişiye çok bağımlıdır. Bu iki sorun ortaya çıkarır, birincisi bu kişinin ayrılması durumunda bilginin kurumda kalma zorluğu, ikincisi bu tür kişilerin az bulunur ve yüksek maaş talep eder kişiler olmasından dolayı diğer çalışanlar üzerinde oluşturacağı huzursuzluk ve işlerin bu kişiye çok bağımlı olması. Bu konulardan bahsetmeyeceğim.
Durum bu şekilde ise, 20 kişilik olmasa bile 5 kişilik iş yapacak bir kişinin 5 kişilik maaş alması da makul gözükmektedir.
Asıl sorun, bu kişilerin nasıl bulunup nasıl işe alınacağıdır. Teknik bilgisi üstün olan kişilerin mülakatlarda çok başarılı olduğu söylenemez, bunun yanısıra insan ilişkileri kuvvetli olan kişilerin bir kısmının da teknik açıdan daha zayıf olabileceği ortadadır.
Ekip Çalışması
Yazılım için şu anda ve yakın gelecekte iş yapacak olan insandır ve daha çok iş yapmak isteyen daha fazla insana başvuracaktır. İnsan faktörü vazgeçilmez olarak gözükmektedir. Ancak, sektörün çoğunluğu ki en başta çalışanlar, işin aslında kod ile veya bilgisayar ile olduğunu düşünmektedir. Bu yaklaşımın doğru yanları olsa da, gözardı edilen en önemli nokta, iletişim ve insan kaynalarının diğer sektörlere göre çok daha önemli olduğudur.
Tabii tek kişilik projeler ile çalışan bir şirketten bahsedecek olursak bu geçerli olmaz, ancak iki kişi bir projeye girdiği andan itibaren bu yapılandırma önem kazanır. Teknik bilgisi çok yüksek olan ancak karşısına derdini anlatamayan veya geçinilemez kişilerin çok olduğu sektörümüzde, tek adamlar çok fazladır, sektördeki herkes bunu yaşamıştır.
Projelerdeki en büyük sıkıntılar iletişim sorunlarından kaynaklanmaktadır, zira bir ekip olarak çalışmasını bilmeyen alışanlar ve ekip olarak çalışılmasının önemini bilmeyen yöneticilerin olduğu sektörde bu konu gözardı edilmektedir.
Teknik temelli kişilerin çoğunluğunda bu tür konuları gözardı etme, iletişimin önemine inanmama veya böyle bir kavram olduğunu bilmeme gibi bir sorun mevcuttur. Eğitimde bunlara değinilmemesi sorunun bir bacağı olabilir.
Nasıl bir iş makinası kürekli ama çok güçlü bir adamın yapacağı işin yüzlerce katı fazla işi daha kolay yapabilirse, ekipler ve iş dağılımı ile aynı şekilde hızlı iş yapılabilir. Yaşanan sıkıntının ilki, özellikle yetkin kişilerin ekip içerisinde çalışmada sıkıntı çektikleri, daha az bilgili olan kişilerden sürekli biat ve itaat istedikleri gözlemlediğim şeylerden birisi, ki geçmişte bu şekilde davrandığım zamanlar çok oldu, sonrasında ekibe zarar verme ve işi ya tek başına yüklenme veya ekibin tamamıyla iş yapamaz hale gelmesi gibi durumlarla karşılaşılır.
Bunu engellemek için ekip çalışması eğitimleri bir araç olabilir, en büyük sorun önce mantığın değişmesi, bir tek adam'ın hiçbir zaman daha az yeteneklerde de olsa birçok adamı yenemeyeceğini kavramak, daha sonra iletişim ile ilgili bir takım bilgilerin alınması sayesinde tek adam olmaktan vazgeçmeye gönüllü ancak başaramayan kişilerin hangi yollarla bunu yapabileceğinin kendilerine gösterilmesidir.
Ancak bu tür disiplinlerden sonra bir ekip olunabilir. Bunlar bittabi bütün sektörlerin konularıdır, ancak yukarıda da belirttiğim gibi, yazılım sektörü en çok insana bağlı sektörlerden biri olduğu için bizim açımızdan elzem konulardır.
Sonuç
Burada belirttiklerim bu konulara ancak bir giriş olabilir, ayrıca detaylı bir çalışma gerektiren bir konudur. Gözardı edildiği müddetçe optimum performans hiçbir zaman yakalanamayacaktır.
İnsan kaynakları ve iletişim yazılım için elzemdir ve bu konu ile ilgili bilgisi olan kişilere ihtiyaç vardır, ancak teknik bilgisi olmayan kişiler özellikle eleman seçimi sırasında manipülasyona açık olduklarından bu bilgiye de sahip olunması çok önemlidir.
Yazılım ekipleri eğitilirken sadece teknik eğitimler verilmesi çok yanlıştır, teknik bilgi yol gösterildiği zaman kitaplardan da alınır, ancak beşeri bilgiler kitaplardan kolay anlaşılacak ve kişinin hayatı boyunca kazandığı yetileri değiştirecek kadar kuvvetli etki yapamaz.
Kurum her kademesinde iletişimi desteklemeli ve herşeyden önce çalışanlarının rahatını ve üretebilirlik performansını gözlemeli, performans düşüşlerini ve moral bozuklularını, aynı zamanda anlaşmazlık ve takım içi çatışmaları çok yakından takip etmelidir. Yöneticilerin asli görevleri arasında diğer sektörlerden daha fazla ihtimam gösterecek şekilde bulunmalı ve yöneticilier bu konuda yetkin kişiler olmalıdır.
Sıkıntı gözlemlendiği anda gözardı edilmeyerek müdahele edilmelidir. Böylece, çalışanların bakımı rutin yapılan ve performansı hep aynı seviyede çalışan üretim tesisleri gibi olmaları sağlanabilir.
Pazar, Ağustos 20, 2006
Yazılımda Modülarite Nedir ?
Modülarite ile ilgili bir kullanım yanlışlığı olduğunu düşünüyorum. Pazarlama stratejilerinin getirdiği bir yanlışlık olabilir, yazılım sektöründe olan aşağı yukarı her firma/kişi yazılımlarının modüler yapısından bahsediyor aslında, gerçekte bir modülarite olmadığı gözlense dahi, belki spec sheetlerde güzel durduğu, belki müşterilerin kafasında güzel bir yere sahip olduğu için, yazılımda modülarite popüler bir deyim olarak kullanılıyor.
Mobilya sektöründe de çok kullanılıyor bu terim, kuru bir tanım yerine oradan bir örnek vermek isterim,
modüler mobilya, çeşitli parçaların biraraya getirilerek yeni modüllerin oluşturulabileceği bir yapıdır. Hem bir koltuk masa ve dolabın bir araya getirilerek takım haline gelebilmesi, ki bu biraraya gelme müşteri seçimine göre olabilir, hemde çeşitli parçaların hazırda bulunarak ihtiyaca göre mobilyanın şekillenebilmesi şeklinde ifade ediliyor.
İhtiyacınız olan ölçülere göre bir mobilyanın değişik parçalardan bir araya gelmesi gibi. Aslında yazılım için bu ikinci işlev daha çok reusability'i canlandırıyor gözümüzde, bizim için modülarite ilki gibi biraz. Birbirleri ile beraber durduğu zaman işlevini yerine getirebilecek parçalar. İhtiyaç duyulduğunda beraber çalışması sağlanabilecek. İstenildiğinde ayna kapılı olabilecek bir dolap belki ihtiyacımız olan.
Bir yazılım içerisinde modülarite olması, kanaatimce, öncelikle o yazılımın değişik modüllerinin birbiri ile ilişkisinin düzenlenmesi esnasında alıncak kararlar sonrasında, öncelikle her bir modülün kendi işlevini yürüterek diğer modülleri minimum etkilemesi, mbu modüllerin olmaması durumunda yazılımın genel yapısına zarar vermeden sadece belirli özelliklerinin daha az olması, biraz da reusability e girersek, değişik yapılarda da kullanılabilmesi demektir.
Yani, bir yazılım içerisinde muhsaebe modülünün olması, o yazılımın aslında muhasebe modülü olmadan çalışabilmesi gerekliliği, olduğu zaman muhasebe ile ilgili özelliklerin ve belki başka modüllerin üzerine muhasebenin getirebileceği katma değerlerdir.
Ancak, modüler yazılım, modüllerin hepsinin hazır olup, sadece bazı lisanslandırma değerleri için bu özelliklerin gösteriminin saklanması değildir. Bu işlem, genelde, yazılımın aslında o modül olmadan çalışamayacağını gösterir. Özellikle veritabanı bazlı tasarımlarda bu gözlenir, kullanıcının ihtiyacı olmadığı modüllerin bazı bilgileri kullandığı modüllerin veritabanı yapısı içerisinde saklanmaktadır.
Modüler yapı, bir plug-in gibi çalışmalı, hatta ideal olarak, runtime da dahi değiştirilebilen bir yapı olmalıdır. Bir iskelet etrafında yerleştirilecek modüller, eğer iskelet düzgün tasarlanmış ise, iskeletin genelini ilgilendirmez. Sadece kendi alanını ilgilendirir. Eğer modülün olmaması, ki sadece önyüzünün değil, varlığının da veya düşüncesinin de olmaması durumunda bu iskelet ayakta durabiliyorsa ve bu statuye yazılım çevirilebiliyorsa, modüler yapıya ulaşılmış demektir.
Bu yapı sayesinde, farklı modüller üzerinde diğerlerini etkilemeden çalışmak mümkün olur. Omurilik üzerine oturan kaburgalar gibi, olmadıklaır zaman işlevsellik eksik olsa da, omurilik ortadadır.
Bu yaklaşım, aynı anda farklı modüllerde geliştirilme işleminin diğerlerini etkilememesi gibi önemli bir özelliği sağlarken, aynı zamanda, reusabilitynin de kapılarını açmaktadır, bu modüller bahsedilen bir özelliğe sahipse, başka omurgalar ve başka kaburgalar ile beraber de kullanılabilir.
Burada modüllere karar verebilmek gerekir. Bir loglama modülü de olabilir bu, yazılıma loglama özelliği ekler, ki nispeten business modüllerine göre modülaritesinin sağlanması daha kolaydır, daha önce bahsedildiği gibi bir muhasebe modülü de olabilir.
Tabii ki, bu modüllerin kendi içerisinde bir bütünlük arzetmesi, kendine göre bir mimarisi olup sonu ve başlangıcının net olması, biraraya gelmiş modüllerin kod karmaşasına dönüşmemesi gibi konular modülün kendi içerisindeki davranışlarını belirleyecektir.
Mobilya sektöründe de çok kullanılıyor bu terim, kuru bir tanım yerine oradan bir örnek vermek isterim,
modüler mobilya, çeşitli parçaların biraraya getirilerek yeni modüllerin oluşturulabileceği bir yapıdır. Hem bir koltuk masa ve dolabın bir araya getirilerek takım haline gelebilmesi, ki bu biraraya gelme müşteri seçimine göre olabilir, hemde çeşitli parçaların hazırda bulunarak ihtiyaca göre mobilyanın şekillenebilmesi şeklinde ifade ediliyor.
İhtiyacınız olan ölçülere göre bir mobilyanın değişik parçalardan bir araya gelmesi gibi. Aslında yazılım için bu ikinci işlev daha çok reusability'i canlandırıyor gözümüzde, bizim için modülarite ilki gibi biraz. Birbirleri ile beraber durduğu zaman işlevini yerine getirebilecek parçalar. İhtiyaç duyulduğunda beraber çalışması sağlanabilecek. İstenildiğinde ayna kapılı olabilecek bir dolap belki ihtiyacımız olan.
Bir yazılım içerisinde modülarite olması, kanaatimce, öncelikle o yazılımın değişik modüllerinin birbiri ile ilişkisinin düzenlenmesi esnasında alıncak kararlar sonrasında, öncelikle her bir modülün kendi işlevini yürüterek diğer modülleri minimum etkilemesi, mbu modüllerin olmaması durumunda yazılımın genel yapısına zarar vermeden sadece belirli özelliklerinin daha az olması, biraz da reusability e girersek, değişik yapılarda da kullanılabilmesi demektir.
Yani, bir yazılım içerisinde muhsaebe modülünün olması, o yazılımın aslında muhasebe modülü olmadan çalışabilmesi gerekliliği, olduğu zaman muhasebe ile ilgili özelliklerin ve belki başka modüllerin üzerine muhasebenin getirebileceği katma değerlerdir.
Ancak, modüler yazılım, modüllerin hepsinin hazır olup, sadece bazı lisanslandırma değerleri için bu özelliklerin gösteriminin saklanması değildir. Bu işlem, genelde, yazılımın aslında o modül olmadan çalışamayacağını gösterir. Özellikle veritabanı bazlı tasarımlarda bu gözlenir, kullanıcının ihtiyacı olmadığı modüllerin bazı bilgileri kullandığı modüllerin veritabanı yapısı içerisinde saklanmaktadır.
Modüler yapı, bir plug-in gibi çalışmalı, hatta ideal olarak, runtime da dahi değiştirilebilen bir yapı olmalıdır. Bir iskelet etrafında yerleştirilecek modüller, eğer iskelet düzgün tasarlanmış ise, iskeletin genelini ilgilendirmez. Sadece kendi alanını ilgilendirir. Eğer modülün olmaması, ki sadece önyüzünün değil, varlığının da veya düşüncesinin de olmaması durumunda bu iskelet ayakta durabiliyorsa ve bu statuye yazılım çevirilebiliyorsa, modüler yapıya ulaşılmış demektir.
Bu yapı sayesinde, farklı modüller üzerinde diğerlerini etkilemeden çalışmak mümkün olur. Omurilik üzerine oturan kaburgalar gibi, olmadıklaır zaman işlevsellik eksik olsa da, omurilik ortadadır.
Bu yaklaşım, aynı anda farklı modüllerde geliştirilme işleminin diğerlerini etkilememesi gibi önemli bir özelliği sağlarken, aynı zamanda, reusabilitynin de kapılarını açmaktadır, bu modüller bahsedilen bir özelliğe sahipse, başka omurgalar ve başka kaburgalar ile beraber de kullanılabilir.
Burada modüllere karar verebilmek gerekir. Bir loglama modülü de olabilir bu, yazılıma loglama özelliği ekler, ki nispeten business modüllerine göre modülaritesinin sağlanması daha kolaydır, daha önce bahsedildiği gibi bir muhasebe modülü de olabilir.
Tabii ki, bu modüllerin kendi içerisinde bir bütünlük arzetmesi, kendine göre bir mimarisi olup sonu ve başlangıcının net olması, biraraya gelmiş modüllerin kod karmaşasına dönüşmemesi gibi konular modülün kendi içerisindeki davranışlarını belirleyecektir.
Salı, Ağustos 15, 2006
Yazılım ve Performans
Yazılım geliştirme safhasında veya tasarım aşamalarında, performans ile ilgili konuların dikkate alındığı durumlar gözlemlendiğinde, genelde performans ile ilgili kaygısı olan yazılımların yazılmasının böyle bir kaygısı olmayan projelere göre daha uzun ve daha maliyetli olduğu gözlemlenir. Bunun böyle olacağı önceden öngörülebilecek bir durumdur, sürpriz değildir.
Sürpriz olabilecek konular, yazılımın performansını artırmak için verilen uğraşların her zaman işe yaramaması, kimi yerde üzerinde uzun zaman uğraşılan performans artırıcı bazı tekniklerin aslında performansı artırmadığının farkına varılmasıdır.
İstisnalar dışında, performans ile ilgili şu yöntemin izlenmesinin katma değer oluşturacağı kanaatindeyim. Bir yazılım projesini ele alacak olursak, günümüzde asıl masraf hardware değil softwaredir. Bir yazılımın geliştirilmesi, onun çalışacağı ortamın maliyetlerine kıyasla çok daha fazla olacağıdır. Bir application server üzerinde çalışacak bir yazılımı ele alırsak, 2000 $ lık bir server bir yazılım için yetersiz kalırken, 5000$ lık bir serverin yeteceği durumunu düşünürsek, 10 kişinin üzerinde 1 yıl çalıştığı bir yazılım projesi için, ortalama 1000$ maaş düşünürsek, aylık 10000$ bir maaş gideri vardır .Eğer performans ile ilgili harca nan zaman, toplamda 1 haftanın üzerindeyse, gider minimizasyonu yapılmamış olur.
Ayrıca, performans uğruna kod üzerinde veya tasarımda yapılan değişiklikler, çoğu zaman, sistemi test edilemez, anlaşılmaz ve değiştirilemez duruma sokar. Özellikle intermediate seviyede yazılımcıların yaptığı bir hata performans yönelimli çalışmaktır. Örnek olarak, business mantığının stored procedurelar ile rdbms üzerinde tutulması, performansı artırabilecek bir etkenken, aynı zamanda kodun kalitesini ciddi anlamda düşürüp mimariye zarar verirken, ileride bir sürü soruna yol açması da mümkündür. (Veritabanı sağlayıcının değiştirilmesi, test edilebilme, değişiklik, tekrar kullanılabilirlik vb.)
Bu risk alınıp performans düşünülmeden yola çıkılıp daha sonra performans sorunları ile yüzleşilirse gene bir çözüm yolu mevcuttur. Eğer kod uygun şekilde yazılmış ise, sistemin tamamı test edilip, performans sıkıntısı olan noktalar yakalanıp performans ile ilgili değişiklikler sadece o noktalarda yapılır. Böylece, faydası olmayacak optimizasyonlara giden zaman da minimuma indirilmiş olur. Çoğu projenin böyle bir çalışmaya ihtiyacı dahi olmaz.
Son olarak, bahsettiklerim, tabii ki kod yazma esnasında performans seçimleri durumunda kötünün yönüne doğru gitmeyi özendirmemelidir, israf her durumda olduğu gibi bunda da zararlı olacaktır, arada bahsettiğim noktalara sıkıntı oluşturmayacak ve kullanımı ile avantajı apaçık ortada olan durumlar olur ise de bunlara dikkat edilmelidir.
Çarşamba, Haziran 07, 2006
Yazılım Maliyeti
Maliyet Azaltma
(Yazılım ve Türkiye makalesine ek olarak yazılmıştır)
Yazılım maliyeti azaltma işlemi kapsamlı bilgi gerektiren ve zor bir işlemdir.
Buradaki kalemler,
1- Üretim maliyeti
2- Değişiklik maliyeti
3- Sorun Çözme (debug) maliyeti
4- Satış maliyeti
5- Destek maliyeti
6- Kullanılan diğer yazılımların maliyeti (Veritabanı vs.)
şeklindedir. Değişiklik ve debug maliyetleri küçük gibi gözükebilir, ancak yapılan araştırmalara göre, yazılımın asıl maliyeti bu kısımlarda ortaya çıkar.
Karşılaştığım çoğu yazılımcının en büyük şikayeti, değişiklik talepleri idi. Kullanıcılarının çok zahmetli olduğu / yazılımın konusunun çok değişken olduğu ve sürekli değişiklik taleplerinin geldiği bunun da yazılımı bozduğu, bugün yazılımın içerisinden çıkılmaz hale geldiği ve fırsat olsa baştan yazacaklarını belirtiyorlar. Bunun sadece o seferlik kendilerine mahsus bir durum olduğuna dair bir yaklaşım olsa da, yazılım dünyasında bu en büyük problemlerin arasındadır. Her yazılım ve her konu değişikliğüe ihtiyaç duyar, değişikliğe ayak uydurmayı sağlayamazsanız da bu değişiklik yazılımı alaşağı eder. Yazılım her değişiklikle biraz daha bozulur ve yönetilmesi imkansız hale gelir. Artık başlangıçta özenle tasarlanan yazılım yerine neresinden ne çıkacağı bilinmeyen bir ucube vardır. Her türlü değişiklik ile bu ucube daha da tuhaflaşır ve en ufak bir işlem yazılımın bin tane yerini etkiler, bunlar kullanıma kadar ortaya çıkmaz, kullanımda ortaya çıkan problemler tekrar yazılımcıya gittiği zaman yazılımcı bu problemleri düzeltirken başka problemler oluşur.
Bu da debug maliyetini getirir. Bunlar bir yazılımcının günlük karşıklaştığı durumlardır, bunun farklı şekilde olabileceğini bilmeyen kimseler ise bu döngü içerisinde çırpınırlar. Bu yüzden de maliyetler sürekli artar.
Eğer maliyet düşürme bir amaç ise, bu husus çok ama çok önemli bir husustur. Yazılımlar değişir, bunu reddeden bir mantık yok olmaya mahkumdur. Maliyetlerin içerisine bu yerleştirilmelidir.
(Yazılım ve Türkiye makalesine ek olarak yazılmıştır)
Yazılım maliyeti azaltma işlemi kapsamlı bilgi gerektiren ve zor bir işlemdir.
Buradaki kalemler,
1- Üretim maliyeti
2- Değişiklik maliyeti
3- Sorun Çözme (debug) maliyeti
4- Satış maliyeti
5- Destek maliyeti
6- Kullanılan diğer yazılımların maliyeti (Veritabanı vs.)
şeklindedir. Değişiklik ve debug maliyetleri küçük gibi gözükebilir, ancak yapılan araştırmalara göre, yazılımın asıl maliyeti bu kısımlarda ortaya çıkar.
Karşılaştığım çoğu yazılımcının en büyük şikayeti, değişiklik talepleri idi. Kullanıcılarının çok zahmetli olduğu / yazılımın konusunun çok değişken olduğu ve sürekli değişiklik taleplerinin geldiği bunun da yazılımı bozduğu, bugün yazılımın içerisinden çıkılmaz hale geldiği ve fırsat olsa baştan yazacaklarını belirtiyorlar. Bunun sadece o seferlik kendilerine mahsus bir durum olduğuna dair bir yaklaşım olsa da, yazılım dünyasında bu en büyük problemlerin arasındadır. Her yazılım ve her konu değişikliğüe ihtiyaç duyar, değişikliğe ayak uydurmayı sağlayamazsanız da bu değişiklik yazılımı alaşağı eder. Yazılım her değişiklikle biraz daha bozulur ve yönetilmesi imkansız hale gelir. Artık başlangıçta özenle tasarlanan yazılım yerine neresinden ne çıkacağı bilinmeyen bir ucube vardır. Her türlü değişiklik ile bu ucube daha da tuhaflaşır ve en ufak bir işlem yazılımın bin tane yerini etkiler, bunlar kullanıma kadar ortaya çıkmaz, kullanımda ortaya çıkan problemler tekrar yazılımcıya gittiği zaman yazılımcı bu problemleri düzeltirken başka problemler oluşur.
Bu da debug maliyetini getirir. Bunlar bir yazılımcının günlük karşıklaştığı durumlardır, bunun farklı şekilde olabileceğini bilmeyen kimseler ise bu döngü içerisinde çırpınırlar. Bu yüzden de maliyetler sürekli artar.
Eğer maliyet düşürme bir amaç ise, bu husus çok ama çok önemli bir husustur. Yazılımlar değişir, bunu reddeden bir mantık yok olmaya mahkumdur. Maliyetlerin içerisine bu yerleştirilmelidir.
Yazılım Mimarisinde Veritabanının Yeri
Orta - Büyük çaplı herhangi bir yazılım belirli bazı kısımları tasarlanmadan hayata geçemez. (Kastettiğim bir yazılım yapılmadan önce mimarisi tamamen hazırlanmış olmalıdır şeklinde algılanmasın, agile modeller için bu geçerli değildir, yazılım geliştirme süresince de mimari ortaya çıkabilir).
Başlangıç seviyesinden daha yukarıda uğraşan her kişi böyle bir çalışmanın veya konseptin gerekliliğine inanmaktadır.
Bir yazılımın yapacağı işlevler, akışı, mekanizmaları belirlenir ve bunlara göre bir mimari oluşturulur. Bu konularda herhangi bir görüş ayrılığı veya problem yok.
Ancak, genel olarak yazılım sektöründe ülkemizde bir problem var, bu problem mimariyi veritabanından ibaret olarak görmektir.
Veritabanı, verinin saklanması ihtiyacı ile ortaya çıkan bir kavram olsa da, zaman içerisinde kendisine daha fazla iş yükler hale gelip, yazılımın çalışma mantığını da içerisine alabilecek bir yapı haline geldi. Oracle in bunda etkisi büyüktür demek yanlış olmaz, oracle forms ile tamamen veritabanı odaklı yazılımlar kolayca geliştirildi. Bu yazılımların hazırlaması ve öğrenmesi kolay, sonuçta data saklanacak ortam üzerinde çalışıyorsunuz, prezentasyon ile ilgili tüm konseptlerde oracle tarafından hazırlanarak kolay kullanımlı bir library haline getirilmiş durumda.
Buradan yola çıkılarak gelinen seviye, prezentasyonu başka bir dille yapmak ancak iş akışını gene veritabanı üzerinde yönetmek şeklinde oluştu.
Bu tür bir yazılım, tamamen veritabanı üzerine oturtulur. Sistemin değişik yerlerindeki değişik kod parçacıkları, veritabanına bazı kayıtlar atıp bazı kayıtlar alırak çalışır, bu data tutarlılığı açısından bir sorun teşkil etmese de, şu konularda sorun oluşturur.
- Değişiklik
- Tekrar Kullanılabilirlik
- Bakım
- Veritabanı Yazılımından bağımsız çalışabilme
- Test edilebilirlik (Software testing)
- Modülarite
- Farklı disiplindeki kişilerin birarada çalışma zorluğu
- Yazılımın tamamen veritabanına bağımlı olmasından ötürü yazılımcının veritabanına veritabanı ile ilgili kişinin yazılıma müdahele etmeden birşey yapamaması
- Veritabanı hazır olmadan yazılıma başlanamama
Tüm sistem mimarisi ve mantığı veritabanı içerisinde olursa, değişiklik külfeti çok büyük olur. En ufak özellik eklemek için en ufak hesaplama yapmak için veritabanını değiştirmek gerekir. Ayrıca, veritabanında gerekecek bazı performans değişiklikleri vb. de yazılımı doğrudan etkiler.
Eğer veritabanından yazılımı soyutlayabilirsek, o zaman istenilen tüm fonksiyonalite yazılım içerisinde olabilir. Sadece saklama işlemleri için veritabanı kullanılır ise, o zaman veritabanı yazılımını (Oracle sql server vb) değiştirmek de çok kolay olur.
Sistem veritabanına göre düzenlenmiş ise, tekrar kullanılabilirlik sıfıra yakın bir seviyede olur. Sistem çok fazla içiçedir ve bazı fonksiyonları çıkarıp bazı yenilerini eklemek, bazı modülleri çıkarmak, sistem tamamına müdahele etmeden imkansız gibidir. Dolayısı ile maliyeti artırır.
Eğer sistem veritabanına çok sıkı bağlı ise test edilebilirlik de mümkün değildir, testten kasıt manuel test değil yazılımsal testtir. Sistemin parça parça çalışıp çalışmadığını kontrol etmek, problemleri ortaya çıkmadan yakalamak için kullanılan yazılım testlerinin veritabanına çok sıkı bağlı sistemlerde oluşturulması çok güç olur.
Modülaritedeki zorluk, tekrar kullanımdaki zorluk gibidir.
Pazartesi, Haziran 05, 2006
Yazılım ve Türkiye
Yazılım sektöründe Türkiye'nin olması gereken pozisyonundan daha aşağıda bir pozisyonda olduğu ve ülkenin geleceği için önemli bir rol oynayabileceği ile ilgili bir fikir birliği var, bu iş ile ilgili biraz bilgi sahibi olan kimseler bu konunun önemine değiniyor.
Öngörüler
Düşük yatırım maliyeti, lojistik sorunu olmaması, diğer sektörlere nispetle daha az maliyetle daha büyük pazarlarda oyuncu olabilme imkanı genel olarak heyecanlandırıcı bir sektör görünümü veriyor. Ancak konu ile ilgili bilgi çok sığ kalıyor ve bu konu ile ilgili politikaların düzenlenmesinde bazı eksiklikler var kanaatindeyim.
Üretim
Öncelikle ülke ve sektör içerisindeki bireyler olarak konuya yaklaşımı yanlış buluyorum, yazılım projeleri ve şirketlerinde genel gidişat başıboş bir atı bırakıp hedefine varmasını beklemek şeklinde oluyor. Amatör bir ruhla profesyonel iş yapmaya çalışıyoruz, her amatör uğraş gibi ortaya çıkan şey çok fazla emek ancak nisbeten daha az değer sağlıyor.
Bu konuda hiçbir zaman bir atölye den ileriye gidemedik ve büyük şirketlerimiz de dahil, henüz bir yazılım fabrikası vücuda getirebilmiş değiliz. Sektörün ülkemizdeki üyeleri ise Fabrika olmak istemediği gibi bir fabrika olabileceğinin dahi farkında değil. Dünyada uzun zaman önce çözülmüş problemlerin varlığının farkına varılması dahi yıllar alıyor. Eğitim eksikliği gibi gözüküyor.
Şimdiye kadar üretim yöntemlerindeki problemlerin çok farkına varılamamasının bir sebebi, ülke içerisine iş yapan şirketlerin yaptıkları işleri yüksek fiyatlardan pazarlayabilme ve bu sayede maliyeti çok önemsememedir. Aynı hata senelerce sanayicilerimiz tarafından yapıldı, çok yüksek maliyetlerle yüksek fiyata satılan mallar ülke içerisinde müşteri bulmasına rağmen ülke dışında müşteri bulamadı. Bir değişiklik geçirmeleri gerekti, geçiremeyenler de bu gün ayakta değil.
Sonuç olarak, hem kalite olarak yazılımlarımız belirli bir seviyenin üstüne çıkamadı, hemde maliyetlerimiz hep yüksek oldu.
Global Oyuncular
Global oyuncu ve rakip olarak karşımıza çıkarılan örnek Hindistan. Gerçekten Hindistan bu konuda çok yol katetmiş ve her taraftan yazılım şirketleri fırlıyor. Büyük bir hızla özellikle Amerika'dan Hindistan'a para akıyor. Bizim için de aynı modeli savunanlar mevcut, ancak gözardı edilen birşey var. Türkiye Hindistan'dan nüfus açısından korkunç farklılık gösteriyor, bunun sonucu olarak da Hindistan Çin gibi ucuz iş gücünün olduğu bir yer. Bu, bizim sanayimizin Çin'in sanayisiyle yarışmaya çalışması veya o modeli uygulamaya çalışması gibi olur.
Ayrıca, yazılımın emek yoğun bir iş olmasından dolayı, yatırım maliyetinin yükselmesi de rekabeti sağlamak için yeterli olamaz, buradakinin 5 de biri maaşla aynı işi yapabilecek kişilerin Hindistan'da mevcut olması bu yönden rekabet veya model kopyalanmasını imkansız kılmaktadır.
Kar Maksimizasyonu
Yazılım için üretim maliyetinin satılan adetle doğru orantılı olduğu aşikardır, eğer yapılan üründen bir tane yerine bin tane satılır ise kar bu kadar artıp maliyet bu kadar azalmış olur. Ayrıca, burada hammadde sıkıntısı olmadığı için, diğer üretim sektörlerine göre adet artışından elde edilen kar çok daha üstlere çıkabilir. Microsoft'un bir anda bu kadar büyüyebilmesinin bir sebebi, 1 kere üretip n kere satabilmesidir.
Ancak, yazılımdaki ekstra bir maliyet, değişiklik ve güncelleme talebidir. Diğer üretim sektörlerinde üretilen bir ürünün üzerinde değişiklik yapma ihtiyacı olmadığından maliyet sadece ilk üretim ve teslim anında, belki bazı sektörler için bakım vb durumunda oluyor. Ancak bakım maliyeti, yazılımdaki değişiklik maliyeti yanında küçük bir maliyet gibi duruyor.
Bir işletmenin karının hesaplanmasını kabaca satış fiyatı - maliyetler şeklinde düşünecek olursak, sektörden daha fazla nemalanabilmek için ya satış fiyatı artırılacak yada maliyetler düşürülecektir. Şimdiye kadar, Türkiye'de (ve bir süre öncesine kadar tüm dünyada) kar maksimizasyonu satış fiyatlarının yüksek tutulması ile sağlandıysa da, artık müşteri bu yaklaşımı kabul etmemekte, bu yüzden rakipler fiyat indirmekte, yüksek fiyatta satış yapanlar ise rekabet edememektedir. Bu durumda, gelinen durum, artık ayakta kalabilmek için dahi yapılacak şey maliyetlerin düşürülmesi ve bu sayede rekabet içerisine dahil olmaktır.
Maliyet ile ilgili kısım için tıklayınız.
Öngörüler
Düşük yatırım maliyeti, lojistik sorunu olmaması, diğer sektörlere nispetle daha az maliyetle daha büyük pazarlarda oyuncu olabilme imkanı genel olarak heyecanlandırıcı bir sektör görünümü veriyor. Ancak konu ile ilgili bilgi çok sığ kalıyor ve bu konu ile ilgili politikaların düzenlenmesinde bazı eksiklikler var kanaatindeyim.
Üretim
Öncelikle ülke ve sektör içerisindeki bireyler olarak konuya yaklaşımı yanlış buluyorum, yazılım projeleri ve şirketlerinde genel gidişat başıboş bir atı bırakıp hedefine varmasını beklemek şeklinde oluyor. Amatör bir ruhla profesyonel iş yapmaya çalışıyoruz, her amatör uğraş gibi ortaya çıkan şey çok fazla emek ancak nisbeten daha az değer sağlıyor.
Bu konuda hiçbir zaman bir atölye den ileriye gidemedik ve büyük şirketlerimiz de dahil, henüz bir yazılım fabrikası vücuda getirebilmiş değiliz. Sektörün ülkemizdeki üyeleri ise Fabrika olmak istemediği gibi bir fabrika olabileceğinin dahi farkında değil. Dünyada uzun zaman önce çözülmüş problemlerin varlığının farkına varılması dahi yıllar alıyor. Eğitim eksikliği gibi gözüküyor.
Şimdiye kadar üretim yöntemlerindeki problemlerin çok farkına varılamamasının bir sebebi, ülke içerisine iş yapan şirketlerin yaptıkları işleri yüksek fiyatlardan pazarlayabilme ve bu sayede maliyeti çok önemsememedir. Aynı hata senelerce sanayicilerimiz tarafından yapıldı, çok yüksek maliyetlerle yüksek fiyata satılan mallar ülke içerisinde müşteri bulmasına rağmen ülke dışında müşteri bulamadı. Bir değişiklik geçirmeleri gerekti, geçiremeyenler de bu gün ayakta değil.
Sonuç olarak, hem kalite olarak yazılımlarımız belirli bir seviyenin üstüne çıkamadı, hemde maliyetlerimiz hep yüksek oldu.
Global Oyuncular
Global oyuncu ve rakip olarak karşımıza çıkarılan örnek Hindistan. Gerçekten Hindistan bu konuda çok yol katetmiş ve her taraftan yazılım şirketleri fırlıyor. Büyük bir hızla özellikle Amerika'dan Hindistan'a para akıyor. Bizim için de aynı modeli savunanlar mevcut, ancak gözardı edilen birşey var. Türkiye Hindistan'dan nüfus açısından korkunç farklılık gösteriyor, bunun sonucu olarak da Hindistan Çin gibi ucuz iş gücünün olduğu bir yer. Bu, bizim sanayimizin Çin'in sanayisiyle yarışmaya çalışması veya o modeli uygulamaya çalışması gibi olur.
Ayrıca, yazılımın emek yoğun bir iş olmasından dolayı, yatırım maliyetinin yükselmesi de rekabeti sağlamak için yeterli olamaz, buradakinin 5 de biri maaşla aynı işi yapabilecek kişilerin Hindistan'da mevcut olması bu yönden rekabet veya model kopyalanmasını imkansız kılmaktadır.
Kar Maksimizasyonu
Yazılım için üretim maliyetinin satılan adetle doğru orantılı olduğu aşikardır, eğer yapılan üründen bir tane yerine bin tane satılır ise kar bu kadar artıp maliyet bu kadar azalmış olur. Ayrıca, burada hammadde sıkıntısı olmadığı için, diğer üretim sektörlerine göre adet artışından elde edilen kar çok daha üstlere çıkabilir. Microsoft'un bir anda bu kadar büyüyebilmesinin bir sebebi, 1 kere üretip n kere satabilmesidir.
Ancak, yazılımdaki ekstra bir maliyet, değişiklik ve güncelleme talebidir. Diğer üretim sektörlerinde üretilen bir ürünün üzerinde değişiklik yapma ihtiyacı olmadığından maliyet sadece ilk üretim ve teslim anında, belki bazı sektörler için bakım vb durumunda oluyor. Ancak bakım maliyeti, yazılımdaki değişiklik maliyeti yanında küçük bir maliyet gibi duruyor.
Bir işletmenin karının hesaplanmasını kabaca satış fiyatı - maliyetler şeklinde düşünecek olursak, sektörden daha fazla nemalanabilmek için ya satış fiyatı artırılacak yada maliyetler düşürülecektir. Şimdiye kadar, Türkiye'de (ve bir süre öncesine kadar tüm dünyada) kar maksimizasyonu satış fiyatlarının yüksek tutulması ile sağlandıysa da, artık müşteri bu yaklaşımı kabul etmemekte, bu yüzden rakipler fiyat indirmekte, yüksek fiyatta satış yapanlar ise rekabet edememektedir. Bu durumda, gelinen durum, artık ayakta kalabilmek için dahi yapılacak şey maliyetlerin düşürülmesi ve bu sayede rekabet içerisine dahil olmaktır.
Maliyet ile ilgili kısım için tıklayınız.
Kaydol:
Kayıtlar (Atom)