``Az´´ daha mı iyi?

0
cbc
Web 2.0'da yapılan konuşmalardan birisinin konusu "Az"ın iyiliği. Konuşmacı rakiplerinizle giriştiğiniz yarışı kazanmanın yolunun ondan bir ya da daha fazla işi yapabilmekten ziyade "az"lıktan geçtiğini savunuyor.

Anladığım kadarı ile özetleyeceğim bu maddeler ile ilgili fazlamesai.net ne düşünüyor?
  1. Daha az para. Zaman değişti. Bu zamanda diğer insanların parası sizi borca sokar ve bu birşeylere başlamak için hiç de iyi bir nokta değil. Donanım için paraya ihtiyacınız yok -- donanım ucuz. Yazılım için paraya ihtiyacınız yok -- yazılım özgür. Pazarlama için paraya ihtiyacınız yok -- birşeyleri kitlelere duyurmak için bedavaya yakın yollar var. Para size ne zaman satın alabilir ne de tutku. (İşinizi iyi yapabilmeniz için tutkulu olmalısınız). Para size sadece "maaş satın alır", maaş ise insan.
  2. Daha az insan. Web tabanlı uygulama hazırlamak için 3 kişi ile başlamak yeterli. Bir programcı, bir tasarımcı ve ikisine de yardımcı olabilecek ve pazarlamadan temel düzeyde anlayan birisi. İnsan sayısını istediğiniz özellik ya da bakış açısına göre ayarlamak yerine bunları insan sayısının yetebileceği bir düzeye indirin. Daha az insan varsa zamanının da daha az demektir.
  3. Daha az zaman. Rakiplerinizin haftada 40 saat çalışacak 10 elemanı var (40 x 10 = 400) fakat sizin haftada 40 saat çalışacak 3 elemanınız var (40 x 3 = 120). Bu bir dezavantaj gibi görünüyor değil mi? Aksine bu büyük bir avantaj. Çalışarak harcadığınız zamanın büyük bir kısmı boşa gider. Çok fazla toplantı, çok fazla planlama, çok fazla düşünme, çok fazla kağıt işi. Ne kadar çok zamanınız olursa boşa gidecek zamanınız da o oranda artacaktır -- muhtemelen kullandığınızdan daha fazlasını harcarsınız. Daha az zamanınız olduğunda bu vakti daha doğru kullanırsınız. Zamanın para olduğunu düşünün (cbc: zaten öyle!): Eğer ki bankada 500YTL'niz varsa bunun 400'ünü televizyon almak için harcamazsınız. Paranızı daha dikkatli harcarsınız. Tıpkı 400 yerine 40 saatiniz olduğunda yapacağınız gibi. Daha az zamanınızın saati daha değerli olacaktır.

    Ayrıca insanlar günde daha fazla saat, haftada daha fazla gün ve ayda daha fazla olmasını isterler. Daha fazla zaman yerine daha az zamana ihtiyacınız var. haftada 40, 50 ya da 60 saat çalışmak yerine geliştirme zamanınızı 20 ya da 30 saate indirin. Muhtemelen daha çok "gerçek iş" yaparsınız.
  4. Daha az soyutlama. Daha az kağıt işi, daha az soyut iş yapın. Daha çok gerçek iş yapın. Daha az kutu, daha az ok, daha az grafik çizin. Gerçek işten soyut olan işlerin daha azını yapın -- müşterilerinizin göreceği gerçek ürün.
  5. Daha az yazılım. Tüm bu azlığın bağlandığı ana nokta: Daha az yazılım. Daha az para, daha az insan, daha az zaman ve daha az soyutlama sizi daha az yazılım geliştirmeye itecektir. Bu mükemmel. Daha az yazılım enerjinizi ve zamanınızı daha az özelliğe kanalize etmenizi sağlar. Daha az işe daha fazla dikkat o işlerin daha iyi olmasını sağlar. Zamanınızın %100'ünü 20 işe ayırmak yerine 10 işe ayırırsanız sonuçta daha güçlü 10 iş yapmış olursunuz. Böylece hazırlaması ve kullanması tatmin edici, basit, üzerinde uğraşıldığı belli olan bir yazılımınız olur. Bu günleri kazanmanın yolu budur.
  6. Daha fazla kısıtlama. Bütün bu azlık aslında daha fazla kısıtlama için. Bu yaratıcı olmanızı gerektiren sebep. İşte bu sebepten işgücünüzü daha yaratıcı kullanmalısınız. Bu kısıtlamadan daha iyi, daha tatmin edici ve daha basit çözimler ortaya çıkacak. Asıl gerçek daha karmaşık problemleri çözmenizden önce çözülmesi gereken milyonlarca daha basit problemlerin olduğudur. Daha az yazılım daha basit sorunları çözer. Bırakın rakipleriniz daha karmaşık sorunlarla debelenirken kendini yoketsin. O sorunları çözmek gerçekten zor, pahallı ve kötü sonuçlar doğurabilir. Basit kalın, basit yapın, basit çözün.

Görüşler

0
darkhunter
8-D ilginçtir biz firmamızda bu standartları uzun zamandır koruyoruz. Bunların bazılarının iyiliğinden pek emin değilim ama... Örneğin, daha az soyutlama kısmı : Tecrubelerime dayanarak, özellikle bir çalışanın zaman zaman bu iş üstüne düşünmesi gerek. Sürekli pratiğe yönelik çalışmak bir süre sonra iş kalitenizi düşürüyor. Çoğunlukla, çalışanların soyutlama başarısıda aynı eksende olmuyor ne yazık ki. O yüzden soyutlama konusunda çalışacak birileri lazım. Çalışanlar bu işe zaman ayıramayacak kadar meşgulse, patronlar soyutlama için biçilmiş kaftan olur, hemde diğer kriterleriniz sarsılmamış olur bu sayede :)
0
cbc
"Hiç" demiyor zaten. "Daha az" diyor. Yazılım hiç okumyacak dokümanlarla vakit harcamayın diyor. Belli bir hacmin üzerindeki firmalara "tasarlanan" işlerde bu kısım ciddi rol oynuyor. 1 paragraflık fikri 30 sayfa doküman ile anlatmanız gerekiyor. bunu bekliyorlar.
0
cbc
dağıtmışım cümleleri. toparlayayım. "Hiç" demiyor zaten. "Daha az" diyor. En azından yazılım geliştirme ve kullanım aşamasında hiç okunmayacak dokümanlarla vakit harcamayın diyor. Belli bir hacmin üzerindeki firmalara "tasarlanan" işlerde bu kısım ciddi rol oynuyor. 1 paragraflık fikri 30 sayfa doküman ile anlatmanız gerekiyor. bunu bekliyorlar. En az bir tane tasarım aşaması için ayrılan süresinin en fazla %50 sinde bitebilecek bir proje biliyorum.
0
darkhunter
Eyvallah ama işin soyutlama kısmını optimize ederken daha az ibaresini kullanmak beni rahatsız ediyor açıkçası.

İşin özellikle soyutlama bölümünde ayarı kaçırırsanız, projeyi tekrar gözden geçirilmesi gereken belgelerle de gereksiz yere uzatmanız mümkün ki genellikle bu işte ayarı kaçırmak böyle sonuçlar doğuruyor.
0
darkhunter
Ek: Yoksa çıkıpta bir allahın kulu : "soyutlamak lazım" demiyor genellikle, "bu işin azı makbül" tümcesi gördüğüm kadarıyla hakim yaklaşım türü bu. Rahatsızlığımın nedeni de bu.
0
azertet
burada yazıdaki konsept azlık üzerine kurulduğu için herhalde soyutlama için de aynısı denmiş, fakat muhtemelen yazıyı yazan kişi de soyutlamanın öneminin farkındadır. abartılmasın demek istiyor olabilir. gerekli olduğu kadar soyutlama daha doğru bir ifade olabilir.
0
neurorebel
Yazı çok güzel bence. Soyutlamanın dozunu iyi ayarlamak gerek eyvallah. Ama genelde zaten yeterli kadar yapılmıyor. Yeteri kadar önemlide görülmüyor zaten... Şöyle bir serzenişim var idi geçenlerde.. :) M.Y.M.
0
anonim
Ozellikle 3. maddenin az dokumantasyon kısmına katılmıyorum. Ozellikle program ve yapısı ile ilgili dokumantasyonun oldukca detaylı bir sekilde yapılması gerekiyor. Yazılım Gelistirme Yasamdongusu(SDLC) nun her adımında ne yapıldıgına dair yeterli hatta detaylı bilgi dokumante edilmeli.

Yazılım gelistirmeyi adımlara ayırırsak

1- Kullanıcı tarafı gelistirme talebi

2- Yazılım tarafı onayı

3- Planlama

4- Gelistirme

5- Testlerve sonucları(ozellikle kullanıcı kabul testleri)

6- Canlı ortama test ortamından aktarılması

7- Kullanıcı egitimi/kullanım dokumantasyonunun aktarılması

Bu asamaların bazıları detaylı dokumantasyon gerektirse bile sadece sozkonusu taraflar tarafından imzalanarak gecilebilecek asamalar da vardır. Ozellikle teknik gereksinimin "business" tarafınca belirlenmesi, bunların gerceklestirilebilirliginin IT tarafınca onaylanması gerekmektedir. Program yazılırken kod yeterice acıklama ile birlike yazılmalıdır. Test asaması en onemli asamadır. Istenmeyen degisikligin sisteme atılmadan onlenmesı eger ayrı bir kalite yonetimi yoksa mumkun degildir. En azından kullanıcı onayları alınmalıdır. Bu imzalar mumkunse formal bir ortamda gerceklestirilmelidir.. Programın canlı ortama atasımasında tasımayı yapan programcı ve yoneticilerinin onayı olmalıdır.

Yazdıklarım sizleri urkutmus olabilir ancak genelde uygulanmayan ideale yakın dongu bu olmalıdır.

0
cbc

Az "kağıt işi"nden kasıt "gerektiğinden fazlasından kaçınmak" olsa gerek. yoksa hiç yapmayın demek değil. kimse "doküman yazmaya gerek yok" demiyor meraklanmayın :)

bu bahsettiğiniz maddelerin önemi proje büyüdükçe artıyor ve uygulanması gerekiyor. büyüdükçe de uygulanıyor zaten.

Yazılım geliştirme modelleri

0
FZ
6 ila 10 maddelik listelerle size bir şeyleri hap usülü aktarmaya çalışan yazılara daha az önem verin. O'Reilly'den gelmiş olsa dahi. (buzzword'lere ve "hype"lara karşı da daima tetikte olun, 1 milyon dolarlık şirketlerde çalışan yazılım ekipleri ile kendi küçük ekibinizi kıyaslarken çok çok çok dikkatli olun [kaç madde oldu? :)])
0
cbc
küçük projenizde maddeleri umursamadan çalışın. oldukça başarılı çalışmalara imza attıktan sonra milyon dolarlık firmaların size iyi bir teklifte bulunmasını bekleyin. ardından zaten o maddelere boğulacaksınız. zamanınız varken boğulmayın! :)
0
darkhunter
Otomatiğe bağlamayın... Bu maddeler milyon dolarlık yazılım geliştirme guruplarını hedeflemiyor. Dikkat edin. İş kalitesi ve ekonomi için küçük gurupların incelemesi gereken bir özet bence.
0
cbc
evet. "3 kişi" kesinlikle küçük br grup. ama küçük grupla büyük bir iş başlatmak zor olmasa gerek :)
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Amerika Gezi Rehberi - 1

sundance

Çalışmakta olduğunuz şirket bir yazılımın eğitimini almak için sizi yurtdışına mı gönderiyor? Ya da LinuxExpo, Compex veya EEE gibi bir fuara gideceksiniz, ama daha önce hiç yurtdışına çıkmamışsınız, neler yapılması lazım, ne gibi ince noktalar var bilmiyorsunuz.

Malum, bilgisayar sektöründe yurtdışına gidip gelmeler çok oluyor, belki son onbeş günde edindiğim tecrübeler birilerinin işine yarar diye aldığım notları alt alta yazayım dedim.
Bu yazı genel olarak yurt dışına çıkmayla, özel olarak da Amerika'ya gitmeyle ilgili. Verilecek ipuçlarının çoğu genel, ama Amerika ve NewYork'a özgü bir iki küçük detay da var, umarım birilerinin gezisi benimkinden daha kolay olur bu sayede :)

''Televizyonlarındaki İlk GNU/Linux Reklamı'', Senaryo Önerileri

butch

Geçtiğimiz hafta fm'e konu olan Türk Televizyonlarındaki İlk GNU/Linux Reklamıönerisi hakkındaki gelişmelerden bu haftaki FM TV'de bahsetmiştik.

Özetle, Teknoloji Televizyonu Fazlamesai.net ile işbirliği içerisinde böyle bir reklam çalışması yapabileceğini ve bunu başlangıç olarak kendi kanallarında yayınlayabileceğini belirtti.

istanbul - ankara - izmir... Ya peki diğerleri???

parsifal

Kendi sanal mekanlarımızda yaşıyoruz hayatımızı. Büyük şehirlerde oturuyoruz. Bağlantılarımız çok hızlı çalışıyor. Gelişiyoruz, hızlanıyoruz. Peki ya diğer şehirler de durum nedir acaba? Biz "iletişim çağını" oluşturan bir avuç kullanıcıyız esasında...

Pazar Günü Haberleri

anonim

Siz de bir pazar günü bilgisayarınızın başına geçip FM'yi açtıysanız ve tam da "Ben yokken neler olmuş acaba dünyada " diye düşünüyorsanız, buyurun haber turumuza katılın...

Yazılım mühendisliği mühendislik midir? Hacker mantalitesi nerede patlar?

FZ

Geçenlerde (en altta linkini verdiğim) bir sunum izledim. Tanıdığım pek çok yazılımcıyı ve yöneticiyi sandalyeye zincirleyip o sunumdaki her sayfayı, her sözcüğü onlara tane tane okutturmak, birkaç kez yüksek sesle tekrar ettirmek istiyorum.

Yazılım mühendisliği mühendislik midir?

Yazılım, çok akıllı bir ya da birkaç adamın odaya kapanıp harala gürele kod yazıp sonra da “bakın süper program çıktı ortaya, acayip sofistike işler yapıyor” dediği türden sanat, zanaat ve teknik bilgi karışımı gizemli bir üretim alanı mıdır? (Olası tepki: E ama DOOM öyle yazılmadı mı? Bak süper oyun yaptı o zeki ve bilgili adam. Yalan mı? Bak filanca da kapandı odaya süper derleyici, işletim sistemi filan yaptı. Efendim? Her şeyi tek başına yapmadı mı? Yaptı yaptı. Kapandı odaya. Tek başına. Canım birkaç kişi destek vermiştir. Onlar da odaya kapanıp yazan çok zeki ve çalışkan adamlardı. Keşke herkes böyle olsa. Hem tek bir kişinin ya da iki kafadarın geliştirdiği ürünler peşinden fanatiklerini yaratmadı mı ve sevilmedi mi?)