``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

FM Linux - Bölüm 2

SHiBuMi

Geçen haftaki hararetli FM Linux tartışmasında ortaya saçılanları derleyip toparlamak ve bir düzene sokmak için aşağıdaki listeyi oluşturdum. Gelen yorumları derledim ve objektif kalmaya çalıştım. İşte son durum:

fazlamesai.net taşınıyor

cbc

fazlamesai.net, 6 senelik evinden IBM ve Parkyeri sponsorluğundaki yeni yerine taşınıyor. Haberin devamında bu taşınma esnasında karşılaşabileceğiniz olası değişiklikleri okuyabilirsiniz.

Google Çekleri

butch

IBM'in Linux Reklamı - izlemeyen kalmasın

numb

Biraz eski de olsa [1] IBM'in bu muhteşem reklamını izlemediyseniz izlemenizi tavsiye ediyorum.

[1] Reklam Eylül 2003'te yayınlanmış.

Kaynak: chir.ag

İsmi lazım Değil

butch

Herkesin haberi vardır. Mart ayı başında İstanbul Bilgi Üniversitesi tarafından düzenlenen Özgür Yazılım ve Açık Kaynak Günleri etkinliğinin konuklarından biri de Miguel Icaza idi. Özgür yazılım dünyasının bu önemli simasıyla tanışmak için herkes sıradaydı. Bu ortam sağlandı da. Çeşitli gazeteler, televizyonlar , web siteleri söyleşiler gerçekleştirdiler.