Up next in 10
Auzef Bilgi Sistemleri Proje Yönetimi 2023-2024 Final Soruları
https://lolonolo.com/2026/05/08/bilgi-sistemleri-proje-yonetimi-2023-2024-final-sorulari/
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Selamlar. Bilgi Sistemleri proje
0:02
yönetimi hayatta kalma kılavuzumuza hoş
0:04
geldiniz. Bugün o kalın kitaplardaki
0:07
karmaşık akademik teorileri alıp sahada
0:09
yani gerçek dünyada birebir işinize
0:11
yarayacak çok pratik bir formata
0:14
dönüştürüyoruz. Sadece sınavları geçmek
0:16
için değil projelerinizi hayatta tutmak
0:19
için buradayız. Hazırsanız hiç vakit
0:21
kaybetmeden başlayalım. Tamam. Hemen
0:23
konuya dalalım. Bu devasa materyali
0:26
çözmek için işimizi beş temel sütuna
0:28
ayırdık. Sırasıyla projenin temel yaşam
0:30
döngüsü kapsam ve yapılabilirlik, zaman,
0:33
maliyet ve tedarik, risk, kalite ve
0:36
iletişim ve finalde sistem entegrasyonu
0:39
ve ürün konularına bakacağız. Birinci
0:41
bölümümüz projenin temel yaşam döngüsü.
0:44
İşin o büyük resmi. Bakın bunu sadece
0:47
ezberlenecek bir teori gibi düşünmeyin.
0:50
Bu aslında başarılı her bilişim
0:52
projesinin tıkır tıkır atan kalbidir.
0:54
Temeli en başından sağlam atmazsak
0:57
üzerine hiçbir şey inşa edemeyiz. Peki
0:59
bu süreç nasıl işliyor? Pmiı
1:01
standartlarına göre aslında her başarılı
1:04
projenin doğal olarak içinden geçtiği
1:06
beş temel aşama var. Bunlar başlatma,
1:09
planlama, yürütme, izleme ve kontrol
1:11
etme ve nihayetinde kapanış. Silikon
1:14
Vadisinden tutun da dünyadaki her büyük
1:16
şirkete kadar işlerin nabzı tam olarak
1:19
bu sırayla atıyor. Şimdi burada
1:22
sınavların ve gerçek hayatın o meşhur
1:24
tuzağına düşmeyelim. Süreç grupları ile
1:27
geri bildirim tamamen farklı şeylerdir.
1:29
Şunu netleştirelim. Geri bildirim
1:32
projenin içinde muazzam öneme sahip bir
1:34
iletişim aracıdır. Kesinlikle ama az
1:37
önce saydığımız o beş ana süreç
1:39
grubundan biri falan değildir. İş
1:41
dünyasında bu ayrımı iyi yapmak inanın
1:43
hayat kurtarır. Benzer bir kafa
1:46
karışıklığı da sarmal yani helezonik
1:49
modelde yaşanıyor. Bir iş akışını ortama
1:52
taşıyorsanız bu artık projenizin
1:54
onaylanmış resmi bir işidir. Buna kalkıp
1:57
sadece basit bir alternatif demek. Yani
2:00
muhtemelen bu projeyi baştan batırmak
2:02
isteyen birinin yapacağı türden bir
2:04
şakadır herhalde. Geldik ikinci bölüme.
2:07
Kapsam ve yapılabilirlik. Sınırları
2:10
belirlemek. Herhangi bir donanım
2:13
kurmadan veya tek satır kod yazmadan
2:15
önce tam olarak ne inşa ettiğimizi ve en
2:18
önemlisi bunun gerçekten mümkün olup
2:21
olmadığını kusursuzca tanımlamamız
2:23
gerekiyor. Buradaki en ama en kritik
2:26
nokta şu: Kapsam ve zamanı birbirine
2:29
karıştırmak çok sık yapılan bir hata.
2:32
Kapsam sizin gereksinimlerinizdir,
2:35
kısıtlarınız ve o işin sınırlarıdır.
2:37
Lütfen görevlerin sürelerini bu kapsama
2:40
dahil etmeye çalışmayın. Çünkü süreler
2:43
ve takvimler zaman yönetimi dediğimiz o
2:45
bambaşka canavarın alanına giriyor. Ve
2:48
işte hepimizin bildiği o acı tatlı
2:50
gerçeklik kontrolü. Fizibilite bu
2:53
aslında bir vizyonerin uçuk kaçık
2:54
hayallerini, bir proje yöneticisinin
2:56
ayakları yere basan gerçekliğinden
2:58
ayıran çizgidir. Elinizdeki mevcut
3:00
bütçe, zaman ve insan kaynağıyla o
3:02
harika fikri gerçeğe dönüştürebilir
3:04
misiniz? Eğer cevabınız evetse
3:07
tebrikler. Projeniz fizi bildir. 3üncü
3:09
bölümümüz zaman, maliyet ve tedarik.
3:13
Üçlü kısıtı yönetmek. İşte burası o
3:16
mükemmel teorik projenizin nakit akışı
3:19
ve sıkı takvimlerle tam cepheden
3:21
çarpıştığı yerdir. Gerçek dünyaya hoş
3:23
geldiniz. Bazen bir proje yöneticisi
3:26
olarak süre tahminlerinde kendi
3:28
deneyiminizin yetersiz kaldığını fark
3:30
edebilirsiniz ve bu çok normaldir. İşte
3:32
o an üç nokta tahmini imdadımıza
3:35
yetişiyor. Uzmanlara danışırsınız,
3:37
iyimser, kötümser ve en olası
3:39
senaryoları bir güzel harmanlarsınız.
3:41
Böylece tek bir tahmine bel
3:43
bağlamaktansa çok daha sağlam ve
3:45
güvenilir bir dayanak elde edersiniz.
3:48
Şimdi size harika ve bir o kadar da kafa
3:50
karıştıran bir detay vereyim. Projenizin
3:52
zaman çizergesini yaparken kağıt
3:54
üzerindeki kaynak gereksinimlerini
3:56
elbette güncellersiniz ama kaynakların
3:59
kendisini güncelleyemezsiniz. Yani
4:01
fiziksel bir insana veya bir makineye
4:03
güncelleme atamayız. Değil mi? İnsanlar
4:05
yazılım güncellemesi almaz. Siz sadece
4:08
sistemdeki belgenizi güncellersiniz. O
4:10
kadar. Peki bütçeyi tam olarak ne
4:13
şekillendirir? Ekibinizin ne kadar
4:15
deneyimli olduğu projenin uzunluğu ve
4:17
fizibilitesi doğrudan maliyete vurur.
4:19
Ama kurumun organizasyonel politikaları
4:22
doğrudan spesifik bir bütçe tahmin
4:24
faktörü değildir. Bu efsaneyi bir kenara
4:26
bırakalım. Ve unutmayın bütçeyi
4:28
belirleyen kişi dışarıdan tavsiye veren
4:31
bir danışman falan değil. Tüm bu
4:32
verileri toplayıp son sözü söyleyen
4:35
proje yöneticisinin ta kendisidir. Hiç
4:38
düşündünüz mü neden bazen piyasadaki en
4:41
ucuz yazılımı alan şirketler günün
4:43
sonunda en çok zarar eder? Çünkü sadece
4:46
o ilk etiketteki fiyata bakmışlardır.
4:49
Gerçek maliyet aslında buzdağının
4:52
görünmeyen kısmıdır. Doğru bir tedarik
4:54
yönetimi yaşam döngüsü maliyetine bakar.
4:57
Yani satın alma, işletme, yıllarca süren
5:00
bakım ve en sonunda elden çıkarma
5:03
masraflarının tümünü baştan hesaplar.
5:06
Tedarik yaparken dış dünya ile iç
5:08
dünyanızı kesinlikle ayırmanız lazım.
5:10
Pazarın genel durumu veya ülkenin yerel
5:12
yasaları çevresel işletme faktörleridir.
5:15
Yani tamamen sizin dışınızdaki güçler.
5:18
Ama kaynak seçim kriterleri dediğimiz
5:20
şey pazarın size bir dayatması değildir.
5:23
O ekibinizin kendi projesi için tamamen
5:25
hür iradesiyle belirlediği iç
5:28
dokümanlardır.
5:29
4. bölüme geçiyoruz. Risk, kalite ve
5:32
iletişim. Yani projeyi güvenceye almak.
5:36
Kabul ederim işler her zaman o harika
5:38
planlandığı gibi gitmez. Bu bölüm o
5:40
kaçınılmaz kaos anlarında projenizi
5:43
nasıl koruyacağınızla ilgili. Bu koruma
5:45
kalkanının tam kaybinde risk yönetim
5:48
planı yatıyor. Bu plan sizin sıradan bir
5:50
belgeniz değil. Projedeki
5:52
belirsizliklere karşı nasıl organize
5:54
olacağınızı, rolleri ve bütçeyi
5:56
detaylandıran nihai yol haritasıdır. İlk
5:59
toplantıdan ürünün canlıya alındığı o
6:01
son güne kadar en büyük rehberinizdir.
6:04
Şimdi risk yönetiminin amacının sadece
6:06
prosedür uydurup üretimi yavaşlatmak
6:09
olduğunu söyleyenler olabilir. İnanın bu
6:11
çok komik bir tuzak. Aksine risk
6:14
yönetiminin amacı sizi yavaşlatmak
6:16
değil, o beklenmedik kayıpları önlemek,
6:19
ekibe güvence sağlamak ve önünüzdeki sis
6:21
bulutunu dağıtmaktır. Yani o sizin fren
6:24
pedalınız değil, yoldaki akıllı kaza
6:26
önleme sisteminizdir. Peki iletişim bir
6:30
projede kimin kiminle konuşacağına nasıl
6:32
karar veriyoruz? Bunu kurumun
6:34
organizasyon şemaları, bilgi akış
6:36
ihtiyaçları ve ilgili departmanlar
6:39
belirler. Projenin süresi bunu
6:41
belirlemez. Yani proje 6 ay sürecek diye
6:44
yepyeni bir iletişim kanalı yaratılmaz.
6:46
İletişim ağı tamamen o kurumun
6:48
hiyerarşik yapısına dayanır. Takvime
6:50
değil. İşin kalite kısmındaysa
6:53
süreçlerin raydan çıkmasını engellemek
6:55
zorundayız. Kontrol grafikleri bu işi
6:58
tek kelimeyle harika yapar. Önceden
7:01
anlaşılmış o alt ve üst tolerans
7:03
sınırları sayesinde süreci saniye saniye
7:05
izleriz. O iki çizginin içindeyseniz
7:08
güvenlisiniz ama dışına çıkıyorsanız
7:11
işte o zaman acil müdahale vakti gelmiş
7:13
demektir. Ve son durağımız 5. bölüm.
7:17
Sistem entegrasyonu ve ürün. Gerçek
7:19
dünya değeri sunmak. Burası tüm o
7:22
uykusuz gecelerin ve planlamaların
7:24
insanların gerçekten kullanıp para
7:26
ödeyeceği canlı bir ürüne dönüştüğü
7:28
aşamadır. Projeyi kapatmadan yani o son
7:31
noktayı koymadan hemen önce ne
7:33
yapıyoruz? Tabii ki izleme ve kontrol
7:36
etme. Her şeyi toparladığımız, o son
7:38
hataların ayıklandığı, ufak sapmaların
7:40
düzeltildiği ve evet her şey tam da
7:43
planladığımız gibi çalışıyor dediğimiz o
7:45
kritik duraktır burası. Biliyorsunuz
7:48
bilişim dünyasında hiçbir sistem tek
7:51
başına bir ada değildir. ERP
7:53
sisteminizin müşteri ilişkileri
7:55
modülüyle veya yepyeni bir yazılımın
7:57
eskisiyle konuşması gerekir. İşte
8:00
sistemlerarası entegrasyon planı bu
8:02
farklı diller konuşan sistemlerin
8:04
birbiriyle nasıl sorunsuz iletişim kurup
8:07
veri akışı sağlayacağını anlatan o
8:09
mükemmel çevirmendir. İşin ticari ve
8:12
pazar gerçeklerine gelirsek burada ürün
8:14
yöneticisi devreye giriyor. O ürünün
8:17
pazara uyumunu ve fiyatlandırmasını
8:19
yönetir. Unutmayın doğru bir fayda bölüm
8:22
maliyet analizi yapmak israfı önler ve
8:24
israfın önlendiği bir yerde paydaş
8:26
memnuniyetinin azalması söz konusu bile
8:28
olamaz. Son olarak enerji krizinde yakıp
8:31
tasarruflu araç üretmek gibi büyük
8:33
adımlar birilerinin anlık hevesi değil.
8:36
Tamamen genel makroektör taleplerinin
8:38
bir sonucudur. Pazar ne derse biz onu
8:40
inşa ederiz. Bu incelememizin sonunda
8:43
sizi şu kışkırtıcı kritik soruyla başa
8:45
bırakmak istiyorum. Siz şu anda sadece
8:48
bir onay kutuları listesini mi
8:50
dolduruyorsunuz yoksa dışarıdaki pazarın
8:52
gerçekten ihtiyaç duyduğu, yaşayan,
8:54
nefes alan bir ürün mü teslim
8:55
ediyorsunuz? İşte bilgi sistemleri proje
8:58
yönetiminin gerçek özü bu farkta
9:00
yatıyor. Araçları bilin, kuralları
9:02
anlayın ama en önemlisi gerçek bir değer
9:05
yaratın. Bir sonraki kılavuzumuzda
9:07
görüşmek üzere.
#Jobs & Education