<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ekip Archives - mirmirik.net</title>
	<atom:link href="http://mirmirik.net/tag/ekip/feed/" rel="self" type="application/rss+xml" />
	<link>http://mirmirik.net/tag/ekip/</link>
	<description>...bir başka kedi günlüğü</description>
	<lastBuildDate>Tue, 16 Feb 2016 20:35:11 +0000</lastBuildDate>
	<language>tr</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.5</generator>
	<item>
		<title>Kovboyluktan vazgeçip takım oyuncusu olmak</title>
		<link>http://mirmirik.net/2016/kovboyluktan-takim-oyunculuguna-gecis/</link>
					<comments>http://mirmirik.net/2016/kovboyluktan-takim-oyunculuguna-gecis/#respond</comments>
		
		<dc:creator><![CDATA[mirmirik]]></dc:creator>
		<pubDate>Tue, 16 Feb 2016 20:33:40 +0000</pubDate>
				<category><![CDATA[Bilişim Yönetimi]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[bilgi teknolojileri]]></category>
		<category><![CDATA[çevik]]></category>
		<category><![CDATA[ekip]]></category>
		<category><![CDATA[ekip yönetimi]]></category>
		<category><![CDATA[iş yaşamı]]></category>
		<category><![CDATA[proje yönetimi]]></category>
		<category><![CDATA[sdlc]]></category>
		<guid isPermaLink="false">http://mirmirik.com/?p=1417</guid>

					<description><![CDATA[<p>Bir önceki &#8220;Yazılım Ekibindeki Kahraman Kovboy&#8221; yazısında kendime çuvaldızı, şimdiki kovboylara da iğneyi batırmış, yazıyı da, daha somut adımları sonraki ahkam kesmede anlatmaya çalışacağım diyerek bitirmiştim. Kovboy tarzı yazılımcı olmanın ve bu şekilde yazılım geliştirmenin kötü taraflarından üzerine sıklıkla bastırdıklarım özetle şunlar: Tek kişi kalmak, yalnız olmak Ekibe güvenmemek Test ya da dokümantasyona zaman ayırmamak Bilginin [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://mirmirik.net/2016/kovboyluktan-takim-oyunculuguna-gecis/">Kovboyluktan vazgeçip takım oyuncusu olmak</a> appeared first on <a rel="nofollow" href="http://mirmirik.net">mirmirik.net</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p><img fetchpriority="high" decoding="async" class="alignleft wp-image-1429" style="padding-right: 20px;" src="http://mirmirik.com/mirmirFiles/2016/02/RR_cowboy_Y.jpg" alt="Bir zamanlar kovboyluk" width="350" height="446" srcset="http://mirmirik.net/mirmirFiles/2016/02/RR_cowboy_Y.jpg 768w, http://mirmirik.net/mirmirFiles/2016/02/RR_cowboy_Y-235x300.jpg 235w" sizes="(max-width: 350px) 100vw, 350px" />Bir önceki &#8220;<a href="http://mirmirik.com/2016/ekipteki-kahraman-kovboy/">Yazılım Ekibindeki Kahraman Kovboy</a>&#8221; yazısında kendime çuvaldızı, şimdiki kovboylara da iğneyi batırmış, yazıyı da, daha somut adımları sonraki ahkam kesmede anlatmaya çalışacağım diyerek bitirmiştim.</p>
<p>Kovboy tarzı yazılımcı olmanın ve bu şekilde yazılım geliştirmenin kötü taraflarından üzerine sıklıkla bastırdıklarım özetle şunlar:</p>
<ul>
<li>Tek kişi kalmak, yalnız olmak</li>
<li>Ekibe güvenmemek</li>
<li>Test ya da dokümantasyona zaman ayırmamak</li>
<li>Bilginin tek elde toplanması</li>
<li style="text-align: left;">İşlerin gün geçtikçe yığılması</li>
<li>Yığılmadan dolayı işlerde gecikmeler ve bug çıkması</li>
<li>Bug-fix yapacak ya da işleri yetiştirecek kişinin aynı kişi olması</li>
<li>[infinite loop]</li>
</ul>
<p>Tüm bunları bir kovboy yazılımcı ile konuşursanız, size, kendisine zamansız ve eksik dokümante edilmiş istekler geldiğinden, isteklerin bilgisizce hazırlandığından, zaten sistemin ayakta kalmasının tek sorumlusunun kendisi olduğundan, ekipteki daha junior seviyedekilere işin nasıl yapılacağını anlatmaktansa kendisinin yapmasının çok daha hızlı olduğundan bahsedecektir. Kendisinin çevik metodolojiler için yanıp tutuştuğundan, yazılım geliştirme döngüsünde herhangi bir çevik yazılım geliştirme metodolojisi uygulanıyor olsa herşeyin güllük gülistanlık olacağından, ancak süregiden şirket politikası ve işlerin kritikliği sebebiyle bunun uygulanamayacağından da söz edecektir.</p>
<p>Bu durumda kendisine <a href="http://agilemanifesto.org/principles.html">çevik metodolojilerin prensiplerini</a> tekrar hatırlatmakta fayda var:</p>
<ul>
<li>En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak <b>müşterileri memnun etmek</b>tir.</li>
<li>Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.</li>
<li>Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.</li>
<li>İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün <b>birlikte çalışma</b>lıdırlar.</li>
<li>Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, <b>işi başaracakları konusunda güven duyulmalıdır</b>.</li>
<li>Bir <b>yazılım takımı</b>nda <b>bilgi alışverişi</b>nin en verimli ve etkin yöntemi yüzyüze iletişimdir.</li>
<li>Çalışan yazılım ilerlemenin birincil öçüsüdür.</li>
<li>Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.</li>
<li>Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.</li>
<li>Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.</li>
<li>En iyi mimariler, gereksinimler ve tasarımlar <b>kendi kendini örgütleyen takım</b>lardan ortaya çıkar.</li>
<li><b>Takım</b>, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.</li>
</ul>
<p>Prensiplerde önemle tekrarlanan bir nokta var. Takım / ekip / birlikte çalışmak / takım oyuncusu olmak. Takım oyuncusu olmanın şartlarından birisi de aslında bilgi paylaşımının ve şeffaflığın arttırılması. Bilgi paylaşımında bulunmak ve şeffaflığı arttırmak için ise asıl yapılması gerekenin -kişisel deneyimlerden yola çıkarak- &#8220;profesyonel ego&#8221;dan kurtulmak olduğuna inanıyorum.</p>
<p>Egosunu yenebilmiş teknik bir kişinin, ekip ile birlikte daha çok büyüyeceğine ve hep hayalindeki rahat çalışma ortamına kavuşacağına dair inancım yüksek. Ego nasıl yok edilir konusu ise daha çok psikoloji ve sosyoloji alanlarının konusu. Hala kişisel hayatımda yüksek olduğuna inansam da, benim iş konusundaki egomu zayıflatmam şunları sağladı:</p>
<ul>
<li>Şirket içi bilgi paylaşımıma daha fazla zaman ayırdım,</li>
<li>Ekibe yeni katılmış ya da daha önceden ekip içinde varolan arkadaşların teknik bilgilerini yükseltmek için çabalar oldum,</li>
<li>Ekipteki arkadaşlarımın kendilerine güvenleri yükseldi,</li>
<li>Üzerimdeki işleri dağıtabilmeyi başardım,</li>
<li>Üretime aldığımız kodlarda çok daha az hata çıkmaya başladı,</li>
<li>Müşterilerimizde şirketimize ve ekibimize karşı güven yükseldi ve zaman zaman yaptığımız hataların tolere edilmesi kolaylaştı</li>
<li>Mesai sonrası boş zamanım oldu,</li>
<li>Sosyal hayata daha çok zaman ayırabildim,</li>
<li>Geceleri, aklımda o günkü ya da yarınki proje ile ilgili daha az endişe duydum ve daha rahat uyuyabildim.</li>
</ul>
<p>Uzun lafın kısası, kovboy yazılımcı olmanın o iç daraltıcı dünyasından, ilk etapta egonuzu arkanızda bırakarak ve bu sayede takım oyuncusu olma yoluna adım atarak sıyrılabilirsiniz. Emin olun her şeyin en iyisini siz bilmiyorsunuz ve aslında vazgeçilmez değilsiniz.</p>
<p><em><strong>Not:</strong> Yazıdaki fotoğraf, bir zamanlar kovboy filmlerinde oynayan ancak daha sonra ABD başkanlığına soyunan <a href="https://en.wikipedia.org/wiki/Ronald_Reagan">Ronald Reagan</a>&#8216;a ait.</em></p>
<p>The post <a rel="nofollow" href="http://mirmirik.net/2016/kovboyluktan-takim-oyunculuguna-gecis/">Kovboyluktan vazgeçip takım oyuncusu olmak</a> appeared first on <a rel="nofollow" href="http://mirmirik.net">mirmirik.net</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>http://mirmirik.net/2016/kovboyluktan-takim-oyunculuguna-gecis/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Alışkanlıkları değiştirmek</title>
		<link>http://mirmirik.net/2013/aliskanliklari-degistirmek/</link>
					<comments>http://mirmirik.net/2013/aliskanliklari-degistirmek/#respond</comments>
		
		<dc:creator><![CDATA[mirmirik]]></dc:creator>
		<pubDate>Mon, 23 Sep 2013 21:05:03 +0000</pubDate>
				<category><![CDATA[Bilişim Yönetimi]]></category>
		<category><![CDATA[günlük]]></category>
		<category><![CDATA[cto]]></category>
		<category><![CDATA[ekip]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[şirket]]></category>
		<category><![CDATA[yönetim]]></category>
		<guid isPermaLink="false">http://mirmirik.com/?p=1188</guid>

					<description><![CDATA[<p>Bugün okuduğum Scott Berkun yazısı üstüne aklıma gelen bir kaç düşünceyi paylaşma amacı ile başladım yazıya, sonumuz hayrola. Konu da bir önceki yazıya atıfta bulunuyor gibi. Scott Berkun yazısında, yerleşik çalışma ya da iş yapma alışkanlıkları olan bir şirketi nasıl değiştirebileceğinize dair kendi fikirlerini paylaşmış. Açıkçası yazdığı maddeleri neredeyse birebir uygulamış olduğumu farkettim. Bu sayede [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://mirmirik.net/2013/aliskanliklari-degistirmek/">Alışkanlıkları değiştirmek</a> appeared first on <a rel="nofollow" href="http://mirmirik.net">mirmirik.net</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p><img decoding="async" class="alignleft wp-image-1346 size-medium" src="http://mirmirik.com/mirmirFiles/2013/09/iwantToChange-225x300.jpg" alt="Değişim..." width="225" height="300" srcset="http://mirmirik.net/mirmirFiles/2013/09/iwantToChange-225x300.jpg 225w, http://mirmirik.net/mirmirFiles/2013/09/iwantToChange.jpg 480w" sizes="(max-width: 225px) 100vw, 225px" />Bugün okuduğum<a title="Scott Berkun hakkında" href="http://scottberkun.com/about/"> Scott Berkun</a> <a title="How to change a company" href="http://scottberkun.com/2013/how-to-change-a-company/">yazısı </a>üstüne aklıma gelen bir kaç düşünceyi paylaşma amacı ile başladım yazıya, sonumuz hayrola. Konu da <a title="IT Yönetiminde Bebek Adımları – Alışkanlıklar" href="http://mirmirik.com/2013/08/26/it-yonetiminde-bebek-adimlari-aliskanliklar/">bir önceki yazıya</a> atıfta bulunuyor gibi. Scott Berkun yazısında, yerleşik çalışma ya da iş yapma alışkanlıkları olan bir şirketi nasıl değiştirebileceğinize dair kendi fikirlerini paylaşmış. Açıkçası yazdığı maddeleri neredeyse birebir uygulamış olduğumu farkettim. Bu sayede şirketin iş yapışında değişiklik yapmak adına bir kaç adım atabildiğimi düşünüyorum ve bu uygulamadaki deneyimlerimi, Türkiye&#8217;de yazılımdan yönetime geçen birisinin başından geçenler olarak paylaşmak istedim. Yazının ilerleyen bölümlerinde, ilgili yazıdaki maddeler üzerinden gitmeye çalıştım (maddelerde yazanlar değil, sadece madde başlığına atıfta bulundum), umarım yapıcı bir şekilde faydalı olabilirim.</p>
<p>Aşağıdaki görüşlerim ve uygulamalarım büyük bir olasılıkla insan psikolojisi ve bunu anlamak ile de ilişkili. Salt olarak bu kuralları doğru kabul etmek ve uygulamaya çalışmak ya empati yoksunluğunu ya da insan ilişkilerindeki çözülmesi çok zor olan ilişki ağlarını anlamamak ile ilgili olabilir. Burada yazılanları ofisinizde denemenizden sorumlu olmayacağımı tekrar söylemek istedim.</p>
<p><strong>Gücünüzü öğrenin!</strong></p>
<p>Her yeni konuma gelen gibi, ilk yaptığım şey kendi çevremi ve o çevredeki konumumu anlamaya çalışmaktı(bunu sadece iş yeri için sınırlamamak da lazım. Sosyal herhangi bir ortam için bu durum geçerlidir bu içgüdüsel davranış). Yeni çalışma ortamımda ilk önce çalışma arkadaşlarımı oluşturan ekipte kim neyi yapıyor ve kim hangi konulardan sorumlu araştırmasına girdim. Kulaktan dolma ve tahmin yürütme yerine bunu herkes ile birebir görüşerek yapmayı tercih ettim ki bence hem çalışma arkadaşlarınıza saygı duymanız hem de saygı görmeniz açısından en doğrusu bu. Üst yönetimin ekibinizdeki kişiler ile ilgili varsayımlarına tamamen kendinizi kaptırmanız(x şundan sorumlu, y şunu iyi bilir gibi) sizi hem önyargılı yapar hem de oluşan önyargılarınız yüzünden yanlış kaynak seçerek gerekli verimi alamaz ve belki de ileride ihtiyaç duyacağınız değişikliği yapamaz duruma gelirsiniz. Ekibinizin içindeki dinamikleri anlamazsanız, potansiyel dinamiği, sorumlu olduğunuz uygulama yararına yönlendirme şansınız olmaz. Varolan gücünüz, şirkette yöneticiler tarafından size verilen &#8220;title&#8221; ile ilgili olmaktan çok, ekip olarak sizin neyi başarabileceğiniz ile ilgili olduğuna inananlardanım maalesef. Bu yüzden &#8220;varolan güç&#8221; kavramı, benim için &#8220;ekip olarak neyi daha iyi yapabiliriz&#8221; sorusu ile bağlantılı. Bu gücü öğrenmenin en iyi yolu da ekip ile iyi iletişimden geçiyor.</p>
<p><strong>Test edin!</strong></p>
<p>Gücünüzü test etmenin en iyi yolu, güvenilir bulduğunuz bir projede değişim için gerekli gördüğünüz adımlardan bazılarını atmanızdır. Hani hep yürümeden önce emeklemek derler ya, onun gibi bir şey. Daha önce çalışmakta olduğunuz yerde başarıyla uygulanan bir sistem cidden mükemmel olabilir ama bunu şu anki yere &#8220;hemen&#8221; uygulamanız çok da mümkün değil aslında. Bunu kabullenin ve ufak adımlar ile başlayın. Önceki şirketimde projelerdeki planlamalar için uygulanan güzel bir sistem vardı. Bunu öncelikle ekip arkadaşlarım ile paylaştım ve onlara bu sistemin bize olacak faydalarını anlattım. Üst yönetime giderek bir projede kendi iş yapış yöntemimi uygulamak istediğimi ve bunun şirkete faydalı olabileceğini söyledim. Sonrasında da bu sistemi savunabileceğim verileri elde edebilmek için bir dolu soru sordum ekip arkadaşlarıma(x işi için sence kaç saat harcarız? Peki sence bunu da eklersek buna sence bizi ne kadar etkiler? Şöyle bir istek var y departmanından, sence yapmalı mıyız?). Daha sonra elimdeki tüm verileri test edeceğim projeye uyguladım ve projenin takibini de bu veriler doğrultusunda yaptım. Şansıma ilk deneme oldukça başarılı geçti ve hem ekip arkadaşlarım hem de işi isteyen departman ve yönetim sonuçtan memnun kaldı. Acemi şansı belki de ama matematik yalan söylemez.</p>
<p><strong>Daha iyi sonuçlar elde edin!</strong></p>
<p>Yöntem farklılığının başarı ile sonuçlanması sayesinde bazı şeylerin ilk etapta zahmetli olsa da daha iyi olabileceği fikri kabul görmeye başlayınca, yönteminizi tüm projelere yayın. İlk denemeniz sonucunda zaten öngördüğünüz iyileşmeyi gördüyseniz bir sonraki aşamaya geçin ve kendinize daha zorlu bir proje seçin. Yöntem değişikliğinden emin olmak ve bu değişikliğin uygulamanıza/şirketinize getireceği yararların ölçülebilir olduğunu ancak daha fazla veri ile elde edebilirsiniz. Korkmayın! Bir çok kişi yaptığınızın saçma olduğunu, zaman kaybettirdiğini, dün bitmesi gereken bir çok işin biriktiğini söyleyecektir ama yılmayın. İlk test verilerinizi önlerine atın ve bunun gücünüze güç kattığını unutmayın(güvenen ekip=güç). Bırakın bir kaç proje geciksin. Bu gecikmeleri de asla bahaneler arkasına saklamayın. Sorumluluğu mutlaka üstlenin. Yeni yöntemden dolayı gecikmeler/hatalar ortaya çıktığını ama zaman içinde düzeltilebileceğini anlatın. Buradaki &#8220;düzelecek zaman&#8221; konusunda şunu yapmanız da yardımcı olacaktır. Diyelim ki artık baskılara dayanamaz duruma geldiniz. Kolay bir projeye geri dönün ve onu gerçekleştirin. Eliniz hem daha da güçlenecek, hem de &#8220;zaman&#8221; kazanmış olacaksınız.</p>
<p><strong>Elde ettiğiniz sonuçları paylaşın!</strong></p>
<p>Yeni çalışma alışkanlığının sonuçlarının -alışması zor olsa dahi- matematiksel olarak daha iyi olduğuna ikna edebiliyorsanız önünüzdeki bir çok engel ortadan kalkacaktır(ki matematik yalan söylemez). Burada en önemli tutum aslında yöneticilerinizin tutumu. Türk çalışma mantığına alışmış, daha klasik yöntemleri tercih eden, günümüz söylemleri ile statükocu bir yönetim anlayışınız varsa bu adımı aşmanız çok daha zor olacaktır. Bu durumda matematiksel veriler cidden elinizi güçlendirecek ve işinizi hızlandıracaktır. Yaptığınız işlerin &#8220;ölçülebilir&#8221; veriler doğuruyor olması bu sebeple çok önemli. Daha önceden x zamanda yapılan y işi, yeni yöntemle x+4t zamanında gerçekleşiyor ama, bunun bakım maliyetinde ve gelmesi öngörülen işlerin uygulanma sürelerindeki kısalma sayesinde toplam geliştirme maliyeti 2 adam/ay kazandırıyor dediğinizde emin olun bir şeyleri başarabileceğinizi gösterirsiniz.</p>
<p><strong>&#8216;Yandaş&#8217; toplayın(kaynak isteyin)!</strong></p>
<p>Gerçekleştirdiğiniz projelerde, yaptığınız değişiklik sayesinde olumlu dönüşler oldukça, yeni yöntemleriniz daha çok saygı görecek ve kabul edilir olacaktır. Adice gelebilir yazınca ama, kendi tarafınıza çektiğiniz her kişi ile aslında yöntemi uygulamak isteyen &#8220;ekip&#8221; güçlenecek ve değişime bir adım daha yaklaşacaksınız. Yeni yöntemin her projeye uygulanması için üstünlüğünüzü lehinize çevirin. Her isteğe bunu uygulayabilmek için üst yönetime talepte bulunun. Eğer ki bunu elde edebilirseniz, bu durumda #1 numaralı adıma geri dönmeniz ve yeni gücünüzü öğrenmeniz yerinde olacak.</p>
<p>Değişimi gerçekleştirmek yazıldığı ya da anlatıldığı kadar kolay değil hiç bir zaman. &#8220;Bu böyle olmaz&#8221;, &#8220;bunu şöyle yap&#8221;, &#8220;ben bunun şöyle olmasını istiyorum&#8221; ya da &#8220;ben ne dersem o&#8221; tavrı ile karşılaşmanız özellikle Türkiye şartlarında çok olası. Önemli olan değiştirmek istediğiniz alışkanlıkların ne kadar yerleşik olduğunun farkına varmanız ve hangi noktaya müdahalede bulunabileceğinizi bilmeniz. Bu da bence iki temele dayanıyor. Değişimi gerçekleştireceğiniz ekibe ve ne kadar inatçı olduğunuza&#8230;</p>
<p>The post <a rel="nofollow" href="http://mirmirik.net/2013/aliskanliklari-degistirmek/">Alışkanlıkları değiştirmek</a> appeared first on <a rel="nofollow" href="http://mirmirik.net">mirmirik.net</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>http://mirmirik.net/2013/aliskanliklari-degistirmek/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
