| Yazar |
|
clairvoyant
Antalya
Kayıt: 05.05.2006 |
|
Modulün hayata geçirilmesine en az 2 ay var...
Teknik analiz yeni yeni bitiyor...
Sistem dizaynı tam olarak bitmemiş...
İmplementasyona daha yeni yeni başlanmış...
Sonra müşteri projeyi kısmen satar ve yeni ortaklar işleri kurcalamaya başlar.
Ortaklar deadline dışında proje süreci konusunu kendi aralarında halledemez ve iş yine bize kalır.
Eski ortakların "biz anlatamadık, ne olur siz anlatın" şeklindeki ricaları...
Sadece tek bir soru her şeyi özetliyor: "Bana çalışan bir şeyler gösterebilir misiniz?"
Bazı modüllerin tamamına yakını kodlanmadan önce sunulamayacağını anlatsan anlarlar mı?
Haydi otur şimdi, yeni ortaklara bir yazılım projesinin nasıl geliştirildiğini baştan anlat.
Analiz ve dizayna harcanan zamanın boşa gitmediğine inandır.
Ne büyük bir sıkıntıdır, kodlama tamamlanmadan işten anlamayan müşterinin "bana çalışan bir şeyler gösterebilir misin?" şeklindeki sorusuna cevap vermek...
Milyon dolar da verseler bazen bırakıp gidesi geliyor insanın...
Memur olmak vardı şimdi...
Let`s make this world a better place to live !
|
|
|
| Yazar |
|
mperk
Kayıt: 18.11.2008 |
|
DArısı başımıza
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
musteriyle konuşurken baba başta sen ne gormek istiyosun diyeceksin adama
adam da şu şu şu diyecek . onları sıraya dizdirecen. ve muşteriye tarih vereceksin.
şunu gormen için şunlar yapılacak ve şu kadar surecek. eski usul 4 ay sora anca gorursun ekranı yaklaşımı öldü.
N/A
|
|
|
| Yazar |
|
ogencay
Istanbul
banlandı
Kayıt: 02.03.2006 |
|
Valla benim öyle sorunlarım yok fiberi takıp paketi gönderdim mi tamamdır 
There`s No Place Like 127.0.0.1
|
|
|
| Yazar |
|
clairvoyant
Antalya
Kayıt: 05.05.2006 |
|
orhan yazdi | | musteriyle konuşurken baba başta sen ne gormek istiyosun diyeceksin adama
adam da şu şu şu diyecek . onları sıraya dizdirecen. ve muşteriye tarih vereceksin.
şunu gormen için şunlar yapılacak ve şu kadar surecek. eski usul 4 ay sora anca gorursun ekranı yaklaşımı öldü. |
Bunlar zaten aylar önce halledilmiş konular. Projeye başlanmadan önce 2 ay çalışıldı ve sayfalarca functional specification hazrılandı, fizibilite anlaşması yapıldı ve proje takvimi oluşturuldu. Class diagramları, database specifications, prosedürel diagramlar, paralel işlem prosedürleri, karar verme algoritmaları, network protokolleri gibi teknik ıvır zıvır her şey yolunda giderken müşteri projenin bir kısmını satınca bir çok şey çöpe atılmış gibi oluveriyor. Yeni ortaklara sunulmak üzere özenle hazırlanan demo animasyonları da cabası... Fakat 10 aydır süren projeye balıklama atlayan ortaklarda "animasyon yeterli değil, çalışan bir şeyler görmek istiyorum" anlayışı varken; fiilen baştan anlaşma yapılması, hatta sözleşmelerin yenilenmesi gündeme geliyor. İlk ortaklara durumu kabullendirmem 1 ay sürdü; şimdi aynı süreç yeni ortaklar için başlıyor. Konunun aslında benim departmanımı ilgilendirmemesi lazım ama oluyor maalesef.
Bilmem anlatabildim mi? 
Bu anlattığım spesifik bir örnek tabi... Tek sorun yazılım geliştirme konusunda bilgi sahibi olmayan müşterilerin denk gelmesi sanırım. Yenilik isterler ama anlamadıkları bu alanda neyin nasıl işlediğini anlamaları çok uzun zaman alıyor. Örneğin piyasada çok vardır "şu programın/otomasyonun/sitenin aynısından ben de istiyorum" deyip de fizibiliteyi görünce kaçanlar. Hele hele ben gibi birebir örneği olmayan bir projeye girişmişseniz; projeyi geliştirmekten çok müşterilerle uğraşarak harcarsınız zamanınızı.
Firma sahibi veya freelancer arkadaşlara iş sürecini algılayabilecek kapasitede müşteriler diliyorum...
Let`s make this world a better place to live !
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
proje bazli calisiyorsan su senaryo artik gecerli degil.
musteriden tum istekleri al. analiz yap su yap bu yap. sonra dokuman olustur vs.. vs..
su sekilde yurutmenin bir yolunu bulman lazim.
adama istediklarini listesini verirsin ilk asamada ne yapmasi lazim neyi gormek istiyor onu ogrenirsin uygulamani phase lara bolup sunarsin. imzalatirsin. her phase sonunda hem musteriyi diri tutarsin hem de kendi tasarimini gozden gecirme firsatin olur.
cok profosyonel insanlarla calismiyorsan zaten senin senaryo her seferinde batar.
N/A
|
|
|
| Yazar |
|
clairvoyant
Antalya
Kayıt: 05.05.2006 |
|
orhan yazdi | | su sekilde yurutmenin bir yolunu bulman lazim.
adama istediklarini listesini verirsin ilk asamada ne yapmasi lazim neyi gormek istiyor onu ogrenirsin uygulamani phase lara bolup sunarsin. imzalatirsin. her phase sonunda hem musteriyi diri tutarsin hem de kendi tasarimini gozden gecirme firsatin olur. |
Anahtar soru bu işte; neyi görmek istiyor?
Elbette "çalışan bir şeyler" görmek istiyor. Müşteriye kalsa 1 yıllık çalışma 3 ayda bitsin ya da daha ilk aylarda çalışan bir şeyler görmek istemeler falan... O kadar kompleks bir yapı ki bir alt modul bile eksik olduğunda sistemin çalışmasını engelliyor. Biten alt modüllerin çalışıp çalışmadığını müşterinin anlaması mümkün değil çünkü çoğunluk background processlerinden oluşuyor.
Ben bunu çok önceden anlattım ve kabul ettirdim. Ama her şey projenin ortasında yeni ortakların ortaya çıkmasıyla müsvedde oldu. Şimdi dediğin gibi tüm çalışmaları bir kenara koyup yeni ortakların isteklerine göre yeni bir takvim hazırlamak gerekecek. Ama ne yaparsak yapalım ünitenin en az %90'ı implemente edilmeden müşterinin anlayacağı dilde "çalışan" bir şey sunmak mümkün olmayacak. Bu sebeple sistemi simüle eden animasyonlar hazırladık. Zaten bence doğrusu da budur; kompleks sistemler simülasyonlarla tanıtılırlar. Ama şimdi gel de her şeyi projeye sıfırdan başlanıyormuş gibi baştan anlat...
Let`s make this world a better place to live !
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
o zaman tasariminda bi sakatlik var. 1 yillik projede 4-5 ayda ortaya gozle gorulur bisey cikmaya baslamasi lazim.
background processlerini interfacelere cevirip ordan dummy implementasyonlar kullanabilirsin. zaman ilerledikce gercek implementasyonunu eklersin.
N/A
|
|
|
| Yazar |
|
clairvoyant
Antalya
Kayıt: 05.05.2006 |
|
orhan yazdi | | o zaman tasariminda bi sakatlik var. 1 yillik projede 4-5 ayda ortaya gozle gorulur bisey cikmaya baslamasi lazim.
background processlerini interfacelere cevirip ordan dummy implementasyonlar kullanabilirsin. zaman ilerledikce gercek implementasyonunu eklersin. |
Tasarımda bir sakatlık yok; en zor ve büyük kısımlar olan background processlere öncelik tanımıştım ki, piyasada örneği olmayan alt moduller içerdiğinden dolayı 1-2 ay kadar ar-ge işlerine harcandı. İlk 4 ay part-time takvim kullandım ve müşteriden kaynaklanan aksaklıklardan dolayı toplamda 2,5 ay kadar projeye ara verilmişti. GUI ve işlenecek nesne örneklerini hazırlayacak teami de müşteri ayarladığı (daha doğrusu ayarlayamadığı) için de hatrı sayılır bir zaman kaybı oldu. Ben de takvimin biraz gerisindeyim ama buna rağmen dummy coding yapmadan 1 ay içinde ortaya sunulabilecek düzeyde bir şeyler çıkarabilirim. Ama yok illa şimdi bekleniyor; çalışacak düzeye geldikten sonra projeyi ben de satarım, daha fazlasını vereni de bulurum.
Ya eski ortaklarla organize olup benim takvimi yeni ortaklara kabul ettireceğim ya da dummy code için harcayacağım zamanı deadline'a ekleyeceğim.
Let`s make this world a better place to live !
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
dummy coding demiyorum. interfacelerini (ui dan bahsetmiyorum) yazip onun default implementasyonunu yazacan.
N/A
|
|
|
| Yazar |
|
hllgnc
afyon
Kayıt: 02.04.2007 |
|
İmzalanmış sözleşme var mı?
Sözleşmede şartları yerine getirdiysen senin tarafında sorun yok :)
Bu işlerde yazılımdan anlamayan kişiler için laf anlatmak çok zor :(
Bu da bize örnek olur, bundan sonra dummy bir UI yapmadan işe başlamayız.
|
|
|
| Yazar |
|
clairvoyant
Antalya
Kayıt: 05.05.2006 |
|
orhan yazdi | | proje bazli calisiyorsan su senaryo artik gecerli degil.
musteriden tum istekleri al. analiz yap su yap bu yap. sonra dokuman olustur vs.. vs.. |
Ben bu kısmı atlamışım; proje (gerek karmaşıklığı, gerek bütçesi, gerekse binlerce kullanıcıya hizmet etmesi açısından) büyük olduğu için; gerek geliştirme sürecinde, gerek bakım ve onarım sürecinde, gerekse hizmetin devredilmesinde çıkabilecek sorunları minimize etmek için dökümantasyona önem veriyorum. Software arhitect olarak 30 küsür modulün tüm detaylarını aklımda tutabilmem mükün değil. En azından benim hafızam o kadar güçlü değil.
hllgnc yazdi | | İmzalanmış sözleşme var mı?
Sözleşmede şartları yerine getirdiysen senin tarafında sorun yok :)
Bu işlerde yazılımdan anlamayan kişiler için laf anlatmak çok zor :(
Bu da bize örnek olur, bundan sonra dummy bir UI yapmadan işe başlamayız. |
Sözleşme proje satılmadan önceydi, şimdi yeni bir düzenleme yapılıyor.
Projenin core modüllerinin %90'ı background processlerden oluşsa bile ilk yapılması gereken şey GUI tasarımı ve bir takım dummy olarak çalışan interaktif özellikler (Orhan'ın dediği gibi default implementasyonlar yapılmalı). Ama ne yaparsanız yapın, müşteri sorun çıkarmak isterse bir yolunu buluyor; mantık aramaya gerek yok.
Let`s make this world a better place to live !
|
|
|
| Yazar |
|
orhan
istanbul
admin
Kayıt: 17.11.2005 |
|
clairvoyant yazdi | | ... Software arhitect olarak 30 küsür modulün tüm detaylarını aklımda tutabilmem mükün değil. En azından benim hafızam o kadar güçlü değil.
|
sadece lazim olan kadarini dokumant et digerleri generic kalsin. sonra implementasyonunu degistirirsen dokumantasyonu muhtemelen guncellemeyeceksin 
N/A
|
|
|
| Yazar |
|
clairvoyant
Antalya
Kayıt: 05.05.2006 |
|
orhan yazdi | | clairvoyant yazdi | | ... Software arhitect olarak 30 küsür modulün tüm detaylarını aklımda tutabilmem mükün değil. En azından benim hafızam o kadar güçlü değil.
|
sadece lazim olan kadarini dokumant et digerleri generic kalsin. sonra implementasyonunu degistirirsen dokumantasyonu muhtemelen guncellemeyeceksin |
Zaten öyle yapıyorum, yoksa kodlama için zaman kalmıyor :)
Let`s make this world a better place to live !
|
|
|
|
|
-
 Del.icio.us
-
 Digg
-
 Facebook
-
 Furl
-
 Google
-
 Blink
-
 Simpy
-
 Spurl
-
 Y! MyWeb
|
|
| | | | | | | | | | |
