Türk StartUp’ları Öldüren 12 Sebep

Uzaktan bakınca bizim girişimcilik mahallesi çok çekici gözüküyor. Son beş yılda sürekli artan bir basın ilgisi, melek yatırımcılar, milyon dolarlık raundlar, ürün ve yeni şirket lansmanları, konferanslar, partiler, yurtiçi ve yurtdışı ödüller sayesinde bitmek bilmeyen başarı hikayeleriyle bezeli bir dünyadaymışız gibi bir hava var… Hele arada patlatılan bomba satınalmalar, “exit”ler, girişimciliğe ve startup’lara olan iştahı her geçen gün daha da kabartıyor. Ancak gerçekler yukarıdaki reklam panosundan çok daha farklı, girişimciler için ekmek, değil aslanın ağzında hatta midesinde… Kurulan her 10 startup’tan dokuz tanesi ilk 18 ay içerisinde kapanıyor. Yani startup ölüm oranı yüzde 90 civarında… Ben de aktif bir girişimci ve yatırımcı olarak çok başarılı girişimlerin yanı sıra başarısız girişimlere de yakından tanıklık ediyorum. Bugüne kadar kuruluşunda parçası olduğum veya yatırım yaptığım firma sayısı 15'in üzerinde, bu şirketlerden beş tanesi gözlerimin önünde can çekişerek yok oldular. Bazıları faturası çok yüksek dersler olsa da, bu sayede startup’ları öldüren ve hayatta tutan sebepleri çok daha yakından görme şansına eriştim. Aşağıda Türk startup’ların başarısızlık sebeplerini, biraz da alaturka olanları ön planda tutarak mercek altına aldım:

(1) Güven Sorunu

 Türkiye’de maalesef iş hayatında en büyük ihtiyaç duyduğumuz unsur güven. Ödemesini zamanında yapmayan firmalar, sözleşmesine sadık kalmayan girişimciler, çekleri karşılıksız çıkan tedarikçiler bu coğrafyada genel bir güvensizlik atmosferinin ortaya çıkmasına sebep oluyor. İş veya sosyal hayat fark etmiyor, güvenin olmadığı yerde müşterek herhangi bir başarıdan bahsedilemez. Aynı şey girişimler için de geçerli… Karşılıklı güven tüm paydaşlar arasında sağlanamazsa o girişim ölü doğar.

(2) Cahil Cesareti

 Türkiye’de çoğu girişimci ezbere iş yapıyor, sektörüne tam olarak hakim değil. Teknik ya da değil, hiçbir dokümanı başından sonuna kadar dikkatli okumuyor ve kendisini geliştiremiyor. Türk girişimcisi yine de nereden geldiği belli olmayan bir cesaret ile altyapısı olmadan çok riskli işlere girişebiliyor. Risk almak ile cahil cesareti arasında ince bir çizgi varsa, sanırım bunu göremiyor.

(3) Yanlış Ortaklıklar

 Bu kısmı uzun uzun yazmaya lüzum yok. Vizyonunuzu paylaşmayan, azminize ayak uyduramayan, icraat yerine siyaset yapan ortaklarla kesinlikle yola çıkmayın. Türkiye’deki temel yanlışlardan bir tanesi ortaklıkların yukarıdaki temeller yerine fazlasıyla farazi ve duygusal temeller üzerine inşa edilmesi. Diğer problem ise çok konuşup az iş yapan sözde ortaklar…

(4) “Öz” Girişim Trendi

 Mahallede yeni açılan Kardeşler kuruyemişçisinin yanına hemen bir kuruyemişçi daha açıp “Öz Kardeşler Kuruyemiş” diyoruz. “Bizim taksi”nin yan sokağına “Öz Bizim Taksi”, Urfa kebabçısının karşısına “Öz Urfa”… Türkiye’ye özgü klasik bir start up hatası “Öz Startup” zihniyetinden kurtulamamaktır. Her şeyin kayıtsız şartsız kopyasını yaparak daha olgunlaşmamış bir pazarı gereğinden fazla kalabalıklaştırıyoruz. Sonuç olarak da kimsenin kâr edemediği ve katma değerin ortaya çıkmadığı bir ekosistem oluşuyor. Bu “öz” mantığından kurtulup “özgün”e doğru gitmemiz gerek. Özgün fikirler ve uygulama yöntemleriyle yola çıkmayan start up’lar, ya ölüme mahkum olacaklar ya da fazlasıyla kalabalıklaştırdıkları pazardaki diğer oyuncuları da yarattıkları girdapta boğacaklar.

(5) Hesap Kitap Sıkıntısı

Bugüne kadar yatırım yaptığım Türk startup’larından neredeyse hiçbirisi düzenli bir finansal raporlama sistemi kuramadı. Aylık, çeyreklik gelir tablosu, nakit akışı ve bilançolarını paylaşmaları için özel olarak markaja almamız, hatta başlarında durmamız gerekiyor. Bir çok Türk girişimcisi ürününe aşık olmasına, pazarını da çok iyi bilmesine rağmen, finans ve muhasebe konusunda sınıfta kaldığı için şirketlerini sürdürülebilir bir yapıya oturtamıyor. Yatırımcılar da doğal olarak hesap kitap bilmeyen girişimciye yatırım yapmaya yanaşmıyor.

(6) Sözleşme veya Mevzuat Korkusu

 Hukuki metinler bir girişimcinin hayatının merkezindedir. Şirketi kurarken, yatırımcı alırken, satarken, müşteri ile anlaşırken, çalışanları işe alırken, kısaca bir çok kritik dönemeç kontratlarla bezeli. Bazı kontratlar işinizi az bilen, dışardan destek veren avukatlara emanet edilmeyecek kadar önemlidir. Sözleşmelerden, hukuki metinlerden korkmayın. Faaliyet gösterdiğiniz alandaki tüm mevzuatı avucunuzun içi gibi bilin.

(7) Yatırımcıyı Kaz gibi Yolmak

 Bir girişimin tohum veya melek yatırım almasını dünya turuna çıkan bir motosiklet sürücüsünün sadece ilk 500 kilometre için deposunu doldurması olarak özetleyebiliriz. Oysa bizim coğrafyada ilk tur yatırımı adeta bir “exit” gibi değerlendiren girişimciler var, ilk kaynaklarını çar çur ettikleri için daha sonra gerçekten ihtiyaçları olacak sermayeye ulaşamıyorlar. Yanlış harcamalarla yatırımcılarını hayal kırıklığına uğratırken, bazen de finansal gerçekleri onlardan saklayarak yatırım parasını kişisel harcamalarında kullanıyorlar. Bu hareketler hem girişimlerin ölmesine neden oluyor, hem de tüm ekosisteme zarar veriyor.

(8) İcraat’ın Dışında Kalmak

 80'li yıllarda Turgut Özal’in “İcraatin İçinden” programını çok karikatürize etmiştik ama bugün o vizyonu takdir ediyorum. Bir girişimi kurmak veya hayata geçirmek kolay değil, ancak o girişimin işleyen ve icra eden bir kurum haline gelmesi kuruluş aşamasından belki de beş kat daha zor. İngilizcede “Execution” olarak ifade edilen ve Türkçe’ye en güzel “icraat” olarak çevirebileceğimiz kavram, herhangi bir girişimin başarısının temelini oluşturuyor. Biz Pozitron çatısı altında mobil teknoloji alanına girerken, rakip olarak adlandırabileceğimiz en az beş tane firma vardı. Benzer teknolojilere sahip olmamıza ve aynı alanda faaliyet göstermemize rağmen kısa zamanda pazar lideri olmamızı “icraat” odaklı yönetime borçluyuz.

(9) Yanlış Ürün Israrı

 Girişimcilik serüvenimde çok değerli, çok potansiyeli olan rakipler gördüm, ancak yanlış ürün ve platformda ısrar ettikleri için o potansiyellerine ulaşamadan silinip gittiler. Esnek yapılar darbelere daha dayanıklı olur, Türkiye gibi darbenin nereden ve ne zaman geleceği belli olmayan pazarlarda esnek bir ürün ve esnek bir yapı kurmazsanız orta şiddetteki ilk depremde yerle bir olursunuz.

(10) Hızlı Büyümeyi Yönetememek

 Doğru zamanda, doğru pazarı yakalayıp, rüzgarı arkasına almışken kapasitesi sınırlı bir ürün çıkartarak yükselen talebe karşılık kaliteyi, tedariği ve beklentileri yönetememek ölümlerin en acıklısı olabilir. Global örnek: 15 yıl öncesinin en popüler sosyal ağı olan Friendster’ın çöküşü… Friendster, Facebook’tan çok daha önce piyasaya çıkıp kitlelere ulaşmaya başlasa da sunucu, tasarım ve kapasite kaynaklı sorunlar dolayısıyla kendi kendini imha ederek hiçbir zaman arzu edilen noktaya gelememiştir. Dijital tüketici nankördür, bir kere sizden soğudu mu tekrar gönlünü almak çok zordur.

(11) Tutkunun Ötesine Geçememek

 Türkiye’de bir start-up kurucusu olmak beklentinin aksine bütün gün boyunca en sevdiginiz işi yapmak anlamına gelmiyor. Eğer bir işe girişiyorsanız yukarıda saydığım gibi muhasebe ve finanstan tutun, insan kaynaklarından operasyona, satın almadan tedarik zincirine kadar her şeyde az da olsa bilgi sahibi olmanız gerekiyor. Ortaklarınızla birlikte şirketinizin tüm süreçlerine hakim olmazsanız, daha fırtına bile çıkmadan ilk dalgada alabora olabilirsiniz. Başarı ancak, tutku ile icra edebilme yeteneğinin bir araya gelmesiyle ortaya çıkıyor.

(12) Şeffaflık Sorunu

 Herkeste gördüğümüz “confidential” hastalığı sanırım 90'lı yıllardan kalma bir gelenek. Merak etmeyin, insanlar sizin o parlak fikrinizi çalmak için sıraya girmiyor. Türkiye’de start up geçmişi olmayan çaylak girişimcilerin başarılı olabilmek için şeffaf olmaları, yurt dışındaki literatürü takip ederek girişimlerinde yaşadıkları sıkıntıları mentor olarak gördüğü insanlarla paylaşmaları gerekiyor. Confidential tuzağına düşmeyin. Fikrinizi paylaşın ve geri bildirimleri değerlendirin. — Kıssadan hisse: Türkiye hayal etmesi kolay fakat icra etmesi zor bir ülkedir. Kendimiz kandırmayalım, hiçbir StartUp yukarıda saydığımız yanlışlardan en az bir tanesini yapmadan finiş çizgisine gelemez. Bu nedenle girişimciler yanlış yapmaktan korkmasınlar, ama yanlışlardan ders almazlarsa o zaman hurda girişim mezarlığında yerleri şimdiden hazır olur.

Fırat İşbecer
Co-founder of Pozitron


Kaynak: https://medium.com/@firatisbecer/t%C3%BCrk-startup-lar%C4%B1n%C4%B1-%C3%B6ld%C3%BCren-12-sebep-d96888ba956d#.36psw6ssm

.NET - Hangi Specific Version Değerini Seçmeliyim ?

Aynı dll'in birkaç farklı versiyonunu kullandığınızı varsayarak cevaplayacağız. Visual Studio'da Referans olarak eklediğiniz bir dll'in özelliklerinde SpecificVersion'ı (varsayılan halinde de olduğu gibi) true yaparsanız, projeniz o dll'in özellikle o versiyonuna referans verecektir.

İlerleyen zamanlarda size o dll'in aynı isimli ama farklı bir versiyonu verilirse ; yenisini projede kullanabilmek için önceden referans gösterdiğiniz dll'i silmeli ve yeni dll'i Add Reference yaparak referans olarak eklemelisiniz.

Diğer seçeneğiniz ise Visual Studio'da projenize referans olarak eklediğiniz dll'in özelliklerinde SpecificVersion'ı false olarak seçmek. Böylece projenize birkaç aynı isimde dll atsanız bile, proje en güncel versiyon olan dll'i bulup kullanacaktır. Tabi unutmamak lazım ki bu build sürenizi arttırabilir, çünkü artık projeniz siz pathini vermiş olsanız bile , o dll'in en son versiyonunu bulmak için farklı yerlerde dll'inizi avlama :D arayışına girecek.
-----------------------------------------------------------------------------------------------------------

This answer is going to be based on the assumption that you are versioning your dlls. If you set SpecificVersion to true (which is the default when adding a reference), then the project will reference to that dll with a particular version (say for instance 1.0.0.0).

If, at a later time, you're given a new dll (say 1.0.1.0), then you will have to remove the old dll reference and add the new reference. This is because the project is specifically looking for 1.0.0.0 when you have a new version 1.0.1.0.

The alternative to this is to set the SpecificVersion to false, which tells the project to find the latest available dll and use that one. The problem with this is that the project is now required to "hunt" in various places for the dll you've referenced, which can increase your build time. It will do this even though it knows the path of the dll you've referenced. I'm not sure if this is a bug or if this is done by design. It might be checking to see if there are any newer dlls besides the one you've referenced (perhaps in the GAC or elsewhere). 
----------------------------------------------------------------------------------------------------------

It's a compile-time property!

 One of the most important things to know is that "Specific Version" is a property that takes effect at compile-time and not at runtime.

What is it all about?

 When a project is built, the project's assembly references need to be resolved in order to find the physical assemblies that the build system should use. If the "Specific Version" check is performed (see section "When is "Specific Version" checked?"), it affects the outcome of the assembly resolution process:
 * The build system locates a physical assembly that it can potentially use
 * The build system compares the physical assembly's version to the assembly version stored in the .csproj file for the assembly reference
 * If the two assembly versions are exactly the same, the resolution process succeeds and the physical assembly found is used for the build
 * If the two assembly versions do not match, the physical assembly is discarded and the resolution process continues by locating the next potential assembly
 * If no more potential physical assemblies can be located, the resolution process fails. This results in a compiler warning (warning MSB3245) that tells you that the reference could not be resolved.
 * Interestingly enough, the build then continues! If the code has no actual references to the assembly, the build succeeds (with the previously mentioned warning). If the code has references, the build fails with an error that looks as if the code were using unknown types or namespaces. The only indication why the build really failed is the warning MSB3245. Order in which assemblies are resolved

The order in which the assembly resolution process locates potential assemblies: 

1. The assembly referenced by the element in the .csproj file 
2. The project output path 
3. The GAC 

 Note that if several versions of the assembly exist in the GAC, the resolution process first attempts to resolve to the assembly with the highest version. This is important only if the "Specific Version" check is not made. 

When is "Specific Version" checked? 

 Visual Studio bases its decision whether to perform the "Specific Version" check on two pieces of information found in the .csproj file: 
 The presence or absence of the element, and its value (if it is present) 
The presence or absence of version information in the assembly reference. 
This is how a typical assembly reference with version information looks like (line break added by me for better readability): 

<Reference Include="Foo, Version=1.2.3.4, Culture=neutral,
                         processorArchitecture=MSIL">
  <SpecificVersion>True</SpecificVersion>
  <HintPath>..\..\Bar\Foo.dll</HintPath>
</Reference>

And this is how the assembly reference looks like without version information: 

<Reference Include="Foo">
[...]

The following table shows when the "Specific Version" check is performed, and when it is not: 

                            |     Version information
                            |  Present       Not present
----------------------------+------------------------------
<SpecificVersion>           |
- Present, has value True   |    Yes (1)        Yes (check always fails) (2)
- Present, has value False  |    No  (3)        No (4) 
- Not present               |    Yes (5)        No (6)

    
 The surprising thing here is that no check is performed if both and version information are absent (case 6). I would have expected the check to be performed and to always fail (same as case 2) because in my understanding the absence of implies the default value "True". This may be a quirk of Visual Studio 2010 where I did my tests. 

 When you examine the properties of an assembly reference in the Visual Studio UI (select the reference and hit F4), the value you see for the "Specific Version" property tells you whether or not Visual Studio is going to perform the "Specific Version" check. In case 6 the UI will show "True", although the element is not present in the .csproj file. 

Side-effects on "Copy local" 

 If the "Copy Local" property is set to "True" but the assembly resolution process fails because of the "Specific Version" check, no assembly is copied. 

Reference material 

 What you need to know about referenced assemblies in VS2005 (blogs.msdn.com article) What's New in .NET 2.0 for Assemblies and Versioning? (codemag.com article which reproduces the above MSDN article, down to the wording, but contains a few screenshots and additional information about assembly versioning)