Azure Mobile Services Backend ve iOS Frontend

Uzun bir aradan sonra yazmak biraz zor oluyor, yine de yazmadan da olmuyor arkadaşlar. Bu sefer kısa olarak bahsedeceğim ama ileride bol bol, siz sıkılıncaya kadar anlatacağım Azure Mobile Services konusu ile bir Swift iOS Backend olayına bakacağız. Hiç öyle ahım şahım bir olay değil baştan diyeyim hiç heyecan da yapmayın.

Hazır virtual makinem kendini restart ederken size yeni projemden bahsedeyim. Bir iOS app yazmaya çalışıyorum ama nasıl yazıyorum bir anlatabilsem derdimi. Son zamanlarda merakımdan değil, gerçekten bir girişim olabileceğini düşündüğüm için böyle bir şeye atladım diyebilirim.

1- Proje Kısmısı

Proje nedir, ne değildir? Hayatı insana sorgulatan projenin kendisi midir, yoksa sizin bu konudaki eğiliminiz midir? Bir sürü soru var insanın aklında olan prjeyi ortaya çıkarmak sadece. Olası sorunlardan bir tanesini siz daha başlamadan anlatayım; “Projeye o kadar çok yoğunlaşmak ki, projenin amacını unutmak!”

Maalesef start-up ya da kendi projenizi yaparken yaşayacağınız en büyük sorun bu ve bunun da kolay bir kurtuluşu yok. Her gün kendinize Neden bu projeyi yapmayı istedim? gibi bir soru sormanız ve bunu her gün istisnasız yanıtlamanız gerek. Neyse ki kendi projemin “Amaç noktası” bana kendisini her gün tekrar tekrar hatırlatan bir şey olduğundan kendisine odaklanmam bir şekilde mümkün olabildi diyebilirim.

2- Backend Kısmısı (Back-end)

Şimdi bir fikriniz var, ok bunu anladık. Peki bunu nasıl support edeceksiniz? DB1‘niz var mı? Programınızın arayüzü sizin DB ile nasıl haberleşecek? Genel bir API2 mi çıkacaksınız, yoksa WCF3 koyarım yeter ağa mı diyeceksiniz? Hadi WCF koydunuz bunun REST4 API’ye çevrilmesi var. Onu geçtim hani sizin app Asyncronious5 olarak request gönderdiğinde WCF onu destekleyecek mi? Onu da Web API6 ile yaparım diyeceksiniz ama hadi onun da Authentication7 olayı var, Onu nasıl desteklemeyi planlıyorsunuz?

Hepsini boşverin, bu backend olayını tutup da windows bir host içerisine atıp aylık ne kadar para bayılacağınızı hesapladınız mı? Daha proje başalmadan bir de!!

Vay benim başıma kaynar sular dökülsün, daha hayal aşamasında projeyi çöpe atmaya çalışmanızın sebebi, işte böyle şeylerin hesaplanmasıdır arkadaşlar. Bir gecede Facebook, Instagram çıkmıyor tabii. Hele hele hiç scability olaylarına girmiyorum oraya girdiğimde sizinle ayrıca mesajlaşırız :D.

Kişisel olarak bu sorunları Azure Mobile Services ile (REST, Asyncronios, Authenticated) ile çözmeye çalışıyorum.

3- Frontend Kısmısı (Front-end) (iOS APP)

Hadi bir şekilde arka tarafı kotardınız, peki programınızın arayüzü nasıl olacak? Yo yo tasarım demiyorum, ön yüzün arkasındaki programlama dilinden bahsediyorum. Native yani entegre app mı olacak, yoksa bir web sayfası yapıp onu mu gömeceksiniz programın içerisine? Hadi Native oldu, Objective-C mi olacak Swift mi olacak?

Objective-C ve Swift Farkı

Programatik farkları değil başka bir farkı size anlatmak istiyorum. iOS olacak olan app’ın desteklenme arayüzü nasıl olacak? Yani Objective-C olayı yakında sonlanacak ve Apple buna destek vermemeye başlayacak, bunun için zaten geçen yıl Swift dilini ortaya çıkarttılar. Fakat internette azıcık da olsa araştırma yapınca karşınıza Swift ile bir şey çıkmamakta, ne varsa insanlar objective-c kasmış.

Swift dediğimiz dil de iOS 8’den sonra destekmeye başlanan bir dil bunu da belirtelim. Tabii her makinede iOS 8 yok (Bu yılın analizine göre %85 iOS 8 kurulu makinalarda).

Şahsi görüşüm yine burada Swift dilini kullanmak. Çünkü syntax olarak hem kolay, hem de geleceği olan bir dil.

4- Sonuç

Sonuç olarak öyle “Kanka gel de program yazalım”, “Hadi gel start-up olalım”, “Abilerle Mobile App Keyfi” gibi şeyler kolay olmuyor arkadaşlar. Bir hayaliniz olduğunda o hayali mümkün kılmak için gerekli altyapıyı da öğrenmeniz gerek. Ben bu ölçüde şanslı birisiyim ama bu konuda şanslı olmayanlar ne yapabilir? Tabii ki dünyanın sonu değil. Yazılımcı kiralama, ya da projenizi Angel Investor’lara sunma gibi bir yola gidebilirsiniz. Onlar sizin için düzgün teknik yol çizecek ya da çizecek kişileri sizin karşınıza çıkartacaktır.

Yeni bir şeyler üretmekten korkmayın, aksine üretin ve hayatınızda nadiren yaşayacağınız duyguları doay doya yaşayın.

Devamı gelecektir…


  1. Database: Hani şu dataları sakladığımız zımbırtı. 
  2. Application Programming Interface: Kısaca bizim programla esas kodların iletişim kuracağı arayüz. 
  3. Windows Communication Foundation: Çok popüler olan ve bir çok iletişim formatını destekleyen servis programlama altyapısı. 
  4. Representational State Transfer: Kısaca HTTP üzerinden çalışan servis mantığı. 
  5. Programlamada işlemler syncronious (senkronize) ve asyncronious (sırasız) olarak gönderilirler. Sıralı olaylarda önceki bitmeden sonraki işlem yapılmaz. Sırasızlarda aynı anda işlem gönderilir, en kısa sürede biten tamamlanmış olur. 
  6. Web API: Yeni çıkan REST altyapısı ile MVC teknolojisini birleştiren MS servis altyapısı. 
  7. Yetkilendirme: Öyle her şeyi kabul edip de heckırları sisteme davet mi edeceksiniz? 

Anti-Pattern: Analysis Paralysis

Gün geçmesin ki bir tane daha anti-pattern öğrenelim, işlerimizi düzene sokalım. Belki de alemlerin en çok dile getirilen fakat buna oranla anlamı tam olarak bilinmeyen anti-patternine de bakalım istiyorum. Bu seferki kalıplaşmış bir AP1, ne olduğu da adından belli. Plaza çalışanlarının ağzında sakız olmuş, bunu bileyeni PM2 yapmıyorlar o derece. Nerede bir sorun varsa bu anti-pattern’i belirtmekte ve aslında hayatın anlamı analysis paralysis, o derece. Peki gerçekten bu terimi doğru kullanabiliyor muyuz. Gerçekten bir anti-pattern olarak görebiliyor muyuz? Bunu irdeleyelim istiyorum.

Anti-Pattern nedir?

Her AP anlattığımda bu kısmı yazmadan geçmek istesem de elimde değil. Kavramı defalarca dile getirerek aşina olabiliriz. AP ya da Anti Pattern dediğimiz şey, toplumsal deneyimlerin birleşimidir. Bir yazılım sürecinde, bir hata ya da yanlış uygulama var ise ve insanlar bu hataya sık sık düşüyorsa kalıplaştırılır ve bir anti-pattern oluşur. Anti pattern dediğimiz aslında yaptığımız ve yapmamamız gereken işleri temsil eder. Yanlışlarımızı gösterir, kurtulmanın yollarını belirtir.

Analysis Paralysis Nedir?

Project Management kategorisinde bulunmakta olan bir AP’dir. Kısa tanımını direk vermek istiyorum bu AP’nin.

Projenin verilmiş olduğu akıllı ve iyi donanımlı analist arkadaşların ya da yazılım takımının analiz sürecine başlaması ve bu analiz sürecinin analizinin başlaması ve bunun da analizinin yapılması ile projenin iptal olmasına kadar giden döngüyü tanımlar.

Detaylı anlatıma gelirsek. Kapıdan içeriye elinde proje talep formu ile müdürünüz içeri girdi ve buyurdu ki bu proje yapıla. Hemen ekibinizin analiz tarafı projeyi analiz etmeye başladı ROI’ler belirlendi, toplantılar ayarlandı ama fark ettiler ki, bu projenin bir de cache sistemi olması lazım, hemen bir cache sistemi analizi planlandı, olası programlar belirlendi fakat proje atıyorum bir finans projesi olduğundan back-up sistemlerinin olması ihtiyacı doğdu, daha cache bitmeden back-up sistemi planlanması yapılmaya başlandı ve onun da analiz dosyası çıktı. Bir gün siz gayet her sabah olduğu gibi analiz yaparken fark ettiniz ki müdürünüze projenin iptal edildiği haberi gelmiş. Fakat siz elinizde 200 sayfalık bir analiz kitabı – ki daha yarısı yazılmış – ile müdürünüze bakıyorsunuz. İşte bu durum analysis paralysis’dir. Yani bir analizin gereğinden fazla detaylandırılıp başka analizler ile birleşerek daha da fazla analize ihtiyaç duyması durumuna denir.

Olası sebeplerini ele alırsak; 3

  • Modulleştirme ve birleştirmenin verdiği dayanılmaz cazibe,
  • Dizayna başlamadan önce tüm analizin tamamlanması gerekliliği,
  • Var olan sistemlerin yeniden yazılması ve planlanması için uygun şansın ortaya çıkması,
  • Bir seferde öğrenilmesi gerekilen çok şeyin olması – yeni yetme analist – yeni şeyler öğrendikçe, sürekli bir önceki işi tekrar ele alma.
  • Ara hedeflerin olmaması,
  • Sürekli artan ara hedeflerin olması – genellikle politikal kararlar,
  • Big Project Syndrome yaşanması; bu seferki istediğimiz her şeyi yapacak, en son toolları kullanıp, en son paradigmaları kullanacak, tüm yeni developerlar bunu yazacak, temiz ve düzenli bir sistem başlatacağız, ilk versiyonda daha önceki programlardan bir ya da iki tanesini içine alacak, vb…
  • Riskten kaçınma, hata yapmaktan korkma.

Bu konuda emin olun her yazılımcı ve analist maalesef bir kere bu hataya düşmekte. Bir sistem inşa ederken her zaman; ya şunu da içine alsa, bak burada double yapıyordum teke düşürürüm bunu yaptıktan sonra, ya şurada yeni bir pattern var onu da koyarsam içine, open source bir tool varmış onu da alayım analize gibi cümleler maalesef biz yazılımcıların içinde var, kanımız kaynıyor böyle şeyleri görünce. Fakat maalesef sonumuz projenin iptali olacak bir sürece giriyor. Sadece projenin iptali olsa ne güzel; analiz ve analiste olan güvenin azalması, kullanılacak yeni teknolojilere olan inancın azalması, yazılım biriminin itibarının zarar görmesi de bunların yanında kolay tamir edilemeyecek şeyler.

Burada kalın harflerle belirtmekte faide var, Analiz kötü değildir, aksine çok güzeldir, süper bir şeydir!

Bu Anti-Pattern’den Kurtulma Yöntemleri

Sonuçta ilk sizin başınıza gelmiyor, dünyada binlerce yazılım firması ve yüzbinlerce yazılımcı varken sadece dünyanın sonunu sizin göreceğini sanıyorsanız gerçekten kafanız çok güzel bir durumda demek. Neyse başta ne dedik, bu bir AP ve her AP’nin olduğu gibi bunun da kaçınma yolları bulunmakta.

Çözümleri ele alırsak;3

  • Modellerinizi küçük tutun. Onları birleştirmeyin. Büyük bir model oluşturmak size bilgi katmaz, aksine bilgiyi yokeder!
  • Baştan sona gitmenize gerek yok, fakat test yapılabilecek kadar analiz yapmanıza gerek var. Bu nasıl olacak? Gereksinimleri belirleyerek.
  • Bir “analist” işe almayın. Yazılımcı işe alın. Eğer bir yazılımcı bir gereksinimi nasıl analiz edeceğini bilmiyorsa, yakında öğrenecektir. Eğer bir analist nasıl sistemin inşa edeceğini bilmiyorsa onun “analizi” işe yaramazdır.
  • Eğer yönetimdeyseniz, teknik dokümantasyonu gözden geçirmeyi reddedin. Çalışan işlevselliği gözden geçirin. Eğer her döngüde yeni bir özellik görmüyorsanız, görene kadar milletin başına çökün.
  • Profesyonel yazılım mimarı işe alın – kiralayın. Sadece bir tane sizin işinizi görecektir, bir taneden fazla olmamalı! Mimarın takım lideri olmasına gerek yok – aslında eğer değilse daha güzel. Mimar yazılımın gereksinimlerinin analizini çıkartmakla da sorumlu olmamalı. O sadece kullanılan araçları ayarlamalı, takımı koordine etmeli ve diğer yazılımcıları desteklemeli. Temelin çılartılmasında mimardan başka kimse söz konusu olmamalı – bu sizi de içeriyor. Ve toplantılarda kimse ne toplu olarak ne de öneri olarak yapı hakkında bir şeyi önermemeli – bu Analysis Paralysis için zemin hazırlar.
  • Projenizi başlangıçta bir hedefle ve prototipi hazırlanmış biçinde ortaya çıkartın. Bir aydan fazla kod yazılmasın ve evet kötü algılanabilir ama elinizde kod olduğunda ve çalıştığında kimse size karşı gelemez. Sonrasında değiştirmeye ve güncellemeye başlayabilirsiniz. Prototipi olmayan bir proje ipsiz bir muma benzer ve bu durumda gerçekten Analysis Paralysis ortaya çıkar.

Bu konuda ilgili detaylı tartışmayı ve çeşitli deneyimleri okumak isterseniz, yazının çoğu kısmının araklandığı http://c2.com/cgi/wiki?AnalysisParalysis adresine girip bakabilirsiniz.

Kişisel Durumlarda Analysis Paralysis

Geçenlerde Scott Hanselman‘ın “Knowing too much code” adında bir makalesini okurken kendisi de Analysis Paralysis’e değindi. Fakat bu konuya değinmesi biraz daha farklıydı. Bir kişinin, gelişen bilgisi neticesinde, yeni projelerde, yeni teknolojileri ve bunların arasında oluşacak yeni sistemleri oturtmaya çalışması üzerine, içine girdiği karmaşayı tanımlarken kullandı. Ve aslında evet, maalesef öyle oluyor. gün geçtikçe şu gelmiş, bu varmış dediğimizde entegre etmeye çalışarak, aslında eskiden 3 günde olan işi 7 günde yapmaya başlıyoruz. İçimiz rahat oluyor ama proje gecikmiş oluyor. Geleceği düşünüp atomik işlemleri hesap etmeye çalışsak da gerçekten çok da gerek var mı? YAGNI You aren’t gonna need it! tam da burada işimize yarıyor. Tabii ki YAGNI hakkında daha detaylı bir makale de gelecek, hepsini yazacağım…

Sonuç

Her koşulda bu konuda tam bir fikriniz olduğunu düşünmekteyim. Artık Analysis Paralysis nedir biliyoruz, ortamlarda birisi dediğinde “hmm, evet haklısın, hmmm” diyebilecek bilgi düzeyine eriştiğimize göre. Bir Anti Pattern’i daha burada kapatmış oluyoruz.


  1. Anti-Pattern’in bu yazıda kısaltılmış hali. 
  2. Project Manager – prone yöneticisi 
  3. Peter Merel’in konuyla ilgili yazısından alınmış ve çevrilmiştir. 

Facilitation / Kolaylaştırma

Geçen gün takip ettiğim Project Management bloglarından bir tanesinde bir yazıyı yıldıza aldığımı fark ettim. Bu yazıyı burada çevirip sizinle de paylaşmam lazım, bugün yarın ihtiyacınız olabilir. Benim gibi boş vakti bol olanların bir görevi de bu tabii ki.1

Zayıf PM’ler2 takımlarını ve kullandıkları yöntemleri kontrol etmeye çalışır. Fakat bunu yaparken işleyişin doğal düzenine müdahale edip daha kaotik bir ortamın ortaya çıkmasını sağlarla. Ekibin işleyişi kendi kendine evrimleşip olgunlık kazanmalıdır. Eğer PM sürece müdahale eder ya da onu kontrol etmeye çalışırlarsa, proje genelde başarısız olacaktır.

Erdemli PM, proje takımı içinde ne olduğuna güvenmeyi öğrenir. Eğer bir suskunlık var ise onun büyümesini ve ortaya çıkmasını sağlar. Eğer bir fırtına var ise, onun köpürmesini ve böylece kendi kendine sönmesini sağlar. Eğer takım bir şeylerden mutsuzluk duyuyorsa bunun çözümünü bulur. Erdemli PM, dağılan iş sürecini rahatlatır, kolaylaştırır. O, olaylar derinlemesine etki bırakmadan nasıl işlerin düzeltileceğini bilir.

Maalesef erdemli PM, Türkiye şartları içerisinde pırlanta değerinde ve bir o kadar da bulunması zor bir nesne. Yetişmesi için bulunması gereken ortam da maalesef burada yok. Belki öncesinde bir kaç defa fail olması lazım ki öyle Erdemli PM olabilsinler.


  1. Kaynak (http://thetaoofpm.blogspot.com.tr/2014/03/58-facilitation.html) 
  2. Project Manager (Proje Yöneticisi) 

Anti-Pattern: Big Project Syndrome

Uzundur anti-pattern kavramlarından bahsetmeyi planlıyordum ama malumunuz, öyle design-pattern gibi kolayca ele alınabilecek kadar kısa değiller. Bu yüzden seçip seçip yayınlamak gerek. Hatta bunun için not defterimde bir liste bile oluşturudum. Gerçi anlatmak istediğim AP bu değildi; analysis paralysis fakat ona gelmeden önce küçük bir AP’yi size anlatmam gerek.

Unutanlar için Anti-Pattern (AP) tanımı

Anti-Pattern ya da antipattern dediğimiz kalıplar aslında çoğumuzun çalışırken yaptığı, fakat işimizi kolaylaştırmaktan çok işimizi zorlaştıran işlerin kalıplaşmış halidir. Bir nevi toplumsal ortak deneyim denilebilir. Eğer bir AP’yi okuduğunuzda, “aa evet ben de bunu yapıyorum” diyorsanız, siz de muhtemelen yanlış yapıyorsunuz. AP’nin tam bir çözümü yok fakat korunmanın yolları da illa ki var :).

Tanım

Basit bir anti-pattern. Henüz tam olarak resmi bir kategorisi olmasa da ben bunu “Project Management” ile “Project Architecture” arasında bir yerde kategorize ediyorum. Tanımı ise;

Kimi zaman yönetimin baskısı, kimi zaman da kendi kararı – egosu – neticesinde programı dizayn eden kişinin, tüm dünyanın sorunlarını çözecek bir programı inşa etmeye, projelendirilmeye çalışması.

Detaylıca anlatmaya çalışırsak; şirketinizde finans, kalite ve satın alma departmanları var. Bu departmanların hepsinin ayrı ihtiyaçları var tabii ki. Biri muhabsebe programı, diğeri dokümantasyon, bir diğeri ise sipariş takip sistemi istiyor. Şirketinizdekiler de öyle bir sistemden bahsediyorlar ki, bu kudretli program her departmanın ihtiyacını yaptığı gibi ek olarak üç dört departmana daha hizmet veriyormuş. İşte bu program sizde yapılmaya çalışıyorsa ya da en azından planlanıyorsa bu Big Project Syndrome anti-pattern’inin sizde olduğunu göstermektedir.

Önlem

Önlem için önce müdürün ya da sistemi dizayn eden kişinin kafa yapısının değişmesi gerek ama maalesef bu pek ihtimal dahilinde olmadığı için, elimizden azı gelmekte. Muhtemel kurtulma yöntemi ise; Do The Simplest Thing That Could Possibly Work ki bunu bir makalede detaylıca anlatacağım. Şimdilik kısaca özetlemek gerekirse, isminden de anlaşılacağı gibi. Çalışacak en basit şeyi direk yapmak. Yani sizden üç programı da istiyorlarsa, önce hangisi basit ise onun yapılması ve sonrasında diğer işlere geçilmesi.

Maalesef bu karar sizin elinizde değil, siz basit bir yazılımcısınız. Bunun kararı maalesef sistemi dizayn eden kişide – muhtemelen müdür. Bu yüzden projenizin “Death March” adı verilen, hiç bitmeyen ve sürekli over budget olan bir projeye dönüşmesi ise an meselesi.

Her gün bir AP yazsam yine de elimdeki liste bitmez ama yazmadan da olmayacak. Eğer sizin de böyle 007 James Bond tarzı bir programınız şirketinizde yapılıyorsa yorumlarda bana katılmanızı bekleyeceğim. Bir sonraki AP’de görüşmek üzere.

Not: Bu arada ekleyecektim ama unutmuşum, sonradan aklıma geldi. Bu tip seçimler yapan kişilere Occam’ın Usturası1 ile saldırabilirsiniz;

Şeyler gerektirmedikçe çoğaltılmamalıdır! Başka bir deyişle, bir problem var ise her zaman en mantıklı ve basit olan açıklama “esas açıklama” olarak kabul edilmelidir.


  1. Occam’ın Usturası: (http://tr.wikipedia.org/wiki/Ockham’ın_Usturası) 

Proje Yönetiminde Ego Faktörü

Bugün ilginç bir konu ile karşınızdayım, “Proje yönetiminde ego faktörü”. Bu kısa makale aslında sadece yazılımcı olanlar için değil, analist olmak isteyenler için de açıklayıcı olacaktır. Zira boş işler konusunda kafa yormakta üstüme olmayan şahsımın, bu konuda bir çok fikri bulunmakta.

Proje Yönetimi

Bu konuda detaylı bir makale yazacağım. Özellikle o makalede ele alacağım konuları aşağıda özetleyebilirim.

  • Proje Yönetimi nasıl olmalıdır?
  • Proje Yönetimi esasen hangi faktörlere dayanır?
  • Proje Yönetimi adı altında yerel yazılım sektöründe ne gibi sorunlar var.
  • ve daha nicesi…

Şimdilik bu konulara fazla dalmayalım, vakti geldiğinde bu yazı da zaten o yazı dizisinin bir parçası olacak ve detaylıca bir sonuç ortaya çıkartacağız. Şimdilik konuya hakim olduğunuzu ve şirketinizde bir Proje Yönetimi olduğunu varsayalım. Muhtemelen yok ama yine de olduğunu düşünelim. Haliyle yazılımcı da olsanız, analist de olsanız verilen görev neticesinde sizden bir Analiz Dokümanı çıkarmanız istenmekte, buna müteakip projeyi yapacağınız birim ile bir toplantı ayarlamanız lazım. Siz de tabii tüm saflığınız ve isteğinizle gidip, paşa paşa toplantı yapacağınızı düşünerek karşınızdaki kişi ile masaya oturdunuz. İşte tüm hayalleriniz birazdan o masada yıkılacak, daha önce yıkılmadıysa bir sonraki masada yıkılacak. Korkmayın hemen bu aslında çok güzel bir şey, çünkü gerçek hayatı deneyimliyorsunuz.

Toplantı Masası

Masaya oturdunuz, özenle aldığınız defterinizi ve şirketin size aslında dokuz liralık gösterdiği iki liralık kalemi elinize alarak karşınızdaki kişiden bir PROJE çıkartacağınızı düşünüyorsunuz. O kadar iyimsersiniz ki, poliyanna yanınızda otursa size bakıp ağlardı. O masanın karşısında oturan şahıs ya da şahıslar, sizin gibi kaç tane kişinin leşini bıraktı o masada farkında mısınız? Hayalleriniz, planlarınız toz bulutu olup kaybolmadan önce karşınızdakine bakın. Telefonunu nereye koyuyor? Gözünüzün içine bakıyor mu? Soru sormanıza izin veriyor mu?

Size hiç hayatın sırrını ya da toplantıda x hareketini yaparsanız karşınızdaki daha rahat hissedecek falan demeyeceğim, zira böyle şeylere inanan birisi de değilim. Fakat her toplantım sonrasında elimdeki notları dolduran birisiyim. Zira önemli olan da odur. Toplantı masası savaş meydanıdır, orada yapacağınız en ufak hata sizin savaşı kaybetmenize sebep verebilir.

Projenin hayat döngüsünü özetlersek;
– Proje Talebi: “Kaşık istiyorum, çorba içeceğim”
– Analiz Toplantısı: “Çatal lazım, batırıp yiyemiyorum”
– Proje Sunumu: “Alın size bıçak, artık kesip küçük lokmalar yapabilirsiniz”

Toplantının Ön Analizinin Toplantısı

Bodoslama toplantıya dalan bir tip olmayın! Gidin önce, toplantı yapacağınız kişi hakkında bir ön bilgi edinin, şirketteki iş arkadaşlarınızla ya da daha önce o müşteriye gitmiş kişilerle biraz muhabbet edin. Nasıl bir insandır önce öğrenin; ”Düşmanı Tanımak” ya da “Egoyu Ölçeklemek” dediğimiz bu işlem size kişinin nasıl bir ego haritasına sahip olduğu hakkında fikir verecektir. Gözünüzü korkutmayın, baştan korkarsanız hiç bir projeyi tam olarak çıkartamazsınız, müşterinin kölesi durumuna gelir ve saçma sapan, sonu gelmeyen isteklerin kölesi olursunuz.

Kişinin olabileceği tipleri burada ele almaya çalışırsak kendi başına büyük bir makale olur. Zira onu da başka bir yerde inceleyeceğim. Ego bakımından tehlike derecesine göre üç ana kategoriye ayrılır bu insanlar.

  • Egosu olmayan müşteri; kısaca projeye muhtaç müşteri.
  • Egosu orta seviye olan müşteri; kısaca sizi küçümseyen ama dile getiremeyen müşteri.
  • Egosu tavan yapmış müşteri; onunla ancak CEO irtibata geçebilir, siz kimsiniz ki karşısına çıktınız onun?

Toplantının Hazırlığı

Toplantı yapacağınız mekana gitmeden önce yapmanız gereken işleri gözden geçirmeniz gereken aşama burası. Önce dokümanlarınızı hazırlayın, asla orada eksik belgenizin olmasını istemezsiniz. Toplantı daha önceden ayarlanmışsa, bir iki gün öncesinden kız isteme mesajı atın; ”Yarın yapacağımız toplantı için uygun musunuz?” gibi kibarlıktan öleceğiniz bir mesaj. Toplantı günü için ayarlanmış kaliteli kıyafetler. Falan filan, bunları her yerde bulabilirsiniz. Esas önemli olan o kişiye karşı uygulayacağınız stratejinin nasıl olacağıdır.

Kişinin ego seviyesini, yeterli kişi ile görüştükten sonra çıkarttıysanız bu kişilere karşı uygulayacağınız stratejik planı da çıkartmanız gerekmektedir. Ayrıca bu bilgileri toplarken, Proje Yöneticinizden projenin anlam ve önemi hakkında bir bilgi de isteyiniz, eğer bu konuda bilgi sahibi değilse maalesef bir bacağınız topal olacak ama yine de sağ çıkacaksınız, korkmayın!

Toplantının yapılacağı yere erken gelmeniz değil, toplantı odasına toplantı vakti girmeniz önemlidir! Egosu ne olursa olsun, insan sonuçta saygı görmek ister.

Toplantı Masası

Toplantıyı eğer birden fazla kişi ile yapacaksanız, masanın asla başına oturmayın, yan taraflara oturun ki masayı geniş bir şekilde görebilir, kişilere eşit ilgi gösterebilirsiniz. Toplantı masası yukarıda da dediğim gibi sizin savaş alanıdır ya da daha kibar hali ise satranç tahtanız. Burada soracağınız her soru, proje için diyeceğiniz her laf ilerde sizin aleyhinize delil olarak kullanılabilir. O yüzden bu masanın heyecanına kapılıp asla olmayacak şeyler için söz vermeyin. Karşınızdaki kişi mantar değil sonuçta, o da çalıştı ve buralara kadar geldi.

Strateji!

Karşınıza müşteri geldiğinde, kişiyle ilgili edindiğiniz önyargıları hemen masanın kenarına itin. Önce karşınızdaki kişiyi anlamaya çalışın. Adettendir bir beş dakika ya da on dakika bir geyik yapın. Hem onun stresini alırsınız, hem de kendi gerginliğiniz yatışır. Eğer acelesi varsa standart “naber”, “naaptın reyiz” cümlelerini kullanabilirsiniz. Tabii ana fikri anladığınızı düşünüyorum.

Ego derecesine göre strateji yönelimlerini ele alalım.

Düşük Ego

Yukarıda özetlediğim gibi, bu kişiler esasında sizin projenize muhtaç olan kişilerdir. Yine de bu insanlara, onların sizin projenize olan ihtiyaçlarını belli etmemek büyük bir özen ister. Zira köşesine sıkışmış bir kediyle asla uğraşmak istemezsiniz! Bu kişiye var olan projenizi dilediğiniz gibi anlatabilir, diğer müşterilerinizle ne kadar mutlu mesut yaşadığınızı belirtebilirsiniz. Hatta eğer karşıdaki ile kanka moduna girmeye yaklaşırsanız, müşterileriniz ile yaşadığınız sorunları esprili bir dille anlatabilirsiniz.

Orta Ego

Bu arkadaş aslında daha önceden bir ajansta falan çalışmıştır ya da içten içe kıl olduğu bir akrabası ya da arkadaşı yazılımla ilgilenmektedir ve bunu dile getirmek için fırsat kollamaktadır. Asla ama asla o kişiye karşı tepki vermeyin, haklısınız deyin geçin. Zira amacınız orada laf dalaşına girmek değil, proje hakkında bilgisini almaktadır. Kısaca biraz okşayın arkadaşı – fiziksel değil, laflarınızla. Bu arkadaşın o zamanlardan kalan sinirini ya da bilgisini kullanın; o zamanlardan laf açın, projede eksik gördüğü kısımları belirtmesini isteyin, onun gibi zamanında bizim sektörümüzde çalışmış kişilerin bilgisinin programa çok fazla yarar sağlayacağını, bunun sayesinde hem onun hem de şirketin kazanacağını belirtin. Kısaca biraz yağlayın arkadaşı. O zaten sizin böyle davrandığınızı gördüğü anda bayrakları indirecektir. Çok vermeyin yağı ama egosu makul ölçülerde seyretsin.

Bu tip kişilere ayrıca toplantı sonrasında doküman paylaşımı, istedikleri güncellemeleri gönderebilecekleri bir e-posta adresini ve iyi niyetlerinizi verin. Kapıdan çıkınca hepsini unutacaksınız zaten.

Yüksek Ego

İşte şimdi ayvayı yediniz. Bu arkadaşa yapabileceğiniz tek şey onun egosunun altında ezildiğiniz hissiyatını vermektir. Genel kanının aksine yönlendirilmesi en kolay insanlar da bu insanlardır. Nasıl diye soracaksanız az önce dedim ya, ona hiç görmediği kadar ilgi gösterin. Onun engin bilgisinden ve deneyimlerinden elde edeceğiniz güzellikleri anlatın, projeyi daha önce profesörlerle ve nice PMP’ler ile tasarlamış olsanız bile, onunla konuştuktan sonra yeniden tasarlayacağınızı hatta ve hatta sırf bunun için geldiğinizi anlatın. Size baştan sona kadar projenin nasıl olması gerektiğini anlatsın dursun.

Toplantı içerisinde zaten projede olan şeyleri size hiç yokmuşçasına anlatacaktır çünkü o kategorinin ya da butonun ismi farklıdır. Siz yine de notunuzu alın, ilgiyle, canla, başla dinleyin kendisini. Hatta toplantıyı uzatmayın. Daha sonra tekrar görüşmek için kendisinden bir tane daha toplantı koparın. Bu insanla iki taneden az toplantı yapmayın, süreç hakkında sürekli saçma sapan e-postalar atın ki ilgilendiğinizi falan sansın.

En sonunda da zaten var olan modülleri sanki o anlatmış da siz development ekibine yeniden yaptırmış gibi pazarlayın.

Sonuç

Her şeyden önce toplantı öncesinde görüşeceğiniz kişiyi tanıyın, o kişi hakkında ne kadar fazla kişi ile görüşürseniz, hedefinizi tanımanız o kadar kolay olacaktır. Sinirlenme ya da savunma asla size bir satır daha fazla not aldırmayacaktır. Uyumlu olun, anlayışlı olun, gerekirse projeyi yapmış olan ekibi satın ama o bilgiyi o insandan söküp alın. Çetin ceviz olmak önemli bir noktadır fakat bilgiyi almak daha farklı bir nokta.