Büyük ölçüde doğru, ama bence satış veya finans çalışanlarının da öyle çok satın alma yetkisi yok. Bu yüzden herkes şirketin izin verdiği araçları ya da ücretsiz planları kullanıyor ve sonunda bunu yöneticisine satmak zorunda kalıyor.
Zaman kazandıracağını, projeleri daha şeffaf hâle getireceğini ve özgürlüğü azaltacağını anlatarak ikna etmek gerekiyor.
Excel’in bu kadar yaygın kullanılmasının nedeni de büyük olasılıkla bu. Şirket BT’sinin izin verdiği en güçlü araçlardan biri de Excel.
Satış ya da finans departmanında çalışırken PC’ye WSL kurma izni almaya çalışırsanız anlarsınız. Web uygulamalarının popüler olmasının nedeni de şirket BT’sinin ancak bildiği şeyi engelleyebilmesi.
Bir pazarlama yöneticisi kendi kartıyla Basecamp ödeyebilir; ama kendi barındırdığı bir aracı içeri almak isterse, “bilgisayarları biz yönetiriz, çalışma biçimine de biz karar veririz” diyen BT politikasından geçmesi gerektiği için iş büyür.
Excel’in yaygın kullanılmasının nedeni, kelimenin tam anlamıyla herkesin kullanabilmesi. Veritabanlarının aksine, oluşturduğunuz şey doğrudan görülebilen görsel bir biçimde ortaya çıkar.
Tüm m365 lisanslarına dahildir ve kalıcı lisansları da uzun süre görece ucuzdu.
Satış ekibine WSL izni verilmesi fikri, insanın “gerçek satışçılarla hiç çalıştınız mı?” diye sormasına yol açıyor. Şirketlerin %99’unda teknolojiye yatkın satışçılar bile yardım almadan e-postaya ek dosya göndermeyi ancak başarır; WSL ile ne yapacaklarını bilmiyorum.
Genel olarak doğru. Şirketler tek tek bir kitap satın almayı onaylamaz, ama öğrenme platformu aboneliğini onaylar.
Bu tür küçük satın almaların hepsini onaylamak çok fazla iş çıkarır; incelenmezse de kullanılmayan abonelikler her yerde birikir ya da şirkete pek faydası olmayan birçok şey satın alınır.
Benim deneyimime göre satış departmanı departman düzeyinde iyi araçlara sahip olabiliyordu ama satın alma yetkisi pek büyük değildi.
Buna karşılık pazarlama tarafının satın alma yetkisi epey geniş görünüyordu; sanırım işin doğası her türlü şeyi satın almakla ilgili olduğu için.
Yönetici olsanız bile bir araç satın alımını onaylatmak için daha üst kademelere satmanız gerekebilir, bu da zahmetli olabilir. Kullanıcı başına aylık 80 dolar, iş gücü maliyetine kıyasla aslında bedava sayılır ama yine de her zaman bir engel olur.
Kendi barındırılan bir uygulamayı satın almanın zor olmasının nedeni, BT’nin sunucu, ağ, depolama maliyetleri; kurulum, yükseltme, operasyon, destek; AD tabanlı tek oturum açma, e-posta, Slack, yedekleme ve kurtarma, veri dışa aktarma ve taşıma, ayrıca siber güvenlik gibi konulardan sorumlu olmasıdır.
Tek bir uygulamanın ele geçirilmesi bile tüm şirket BT’sini riske atabilir; izolasyon ya da zero trust uygulansa bile saldırı yüzeyi ve güvenlik maliyeti artar.
Aslında kendi barındırılan bir uygulamayı satın almak işin kolay kısmıdır; zor olan, işin ihtiyaç duyduğu süre boyunca her gün güvenilir şekilde çalıştırmaktır. Verilerin uzun süre saklanmasını gerektiren yasal durumlar da olabilir.
Sahadaki BT ekibinin talep ettiği bir araç olsa bile, bazı teknik yönetimleri yapabilirler; ancak çoğu zaman zamanları yoktur ya da sadece geliştiricidirler, sistem/ağ yöneticisi değildirler.
Sonuçta şirket BT’sinden ayrılmış bir sandbox kullanmak, yedekleme ve AD gibi kolaylıklardan vazgeçmek ya da shadow IT olarak bunu kendiniz uygulayıp sürdürmek gerekir.
Bu yüzden SaaS ve bulutun büyümesinin nedenlerinden birinin de bu maliyetleri dışsallaştırmak olduğunu düşünüyorum.
50 dolarlık bir kitap almak için mücadele etmeniz gerekiyorsa muhtemelen yanlış şirketi seçmişsinizdir.
Öte yandan bazı geliştiriciler Notion’ı içeride test etmek için kartla gayriresmî bir hesap açtı; önemli özet dokümanlarını orada oluşturup bağlantısını dolaştırdılar.
Bunu görmek isteyen şirketin yarısı zımnen hesap oluşturdu ve ertesi ay CFO’ya 10 bin dolarlık fatura geldi.
Geliştiricilere satın alma yetkisi verilmemesi gerektiğine dair hikâyeler genelde böyle başlar.
Bu sadece yağmacı fiyatlandırma modeli ve dark pattern örneği.
Birçok SaaS şirketinin peşin ödeme ya da sabit maliyet tavanı seçeneğini doğru düzgün sunmamasının bir nedeni var. Dolandırıcılığa yakın.
Sadece bir bağlantıya tıklamakla ücret yazılabilen bir sistemi kimin iyi fikir sandığını bilmiyorum. Kartta makul bir aylık limit de yoksa tüm düzenek fazlasıyla saçma.
Bunun “geliştiricilerin satın alma yetkisinin olmamasına yol açan hikâyenin başlangıcı” olduğuna inanmak zor.
Geliştirici olsun olmasın, araçları doğrudan satın almak çoğu zaman tüm organizasyon pahasına yapılan yerel optimizasyon olabilir.
Örneğin araçlar parçalanır ve tek bir aramayla bilgi bulunamaz ya da her ekip farklı araçlara ayrı ayrı giriş yapmak zorunda kalır.
Ekipler şirket fikrî mülkiyetini barındıran araçları kafalarına göre yönetirse, SOC uyumluluğu hedeflendiğinde bu bir compliance kâbusuna dönüşür.
Kitap ya da öğrenme materyali satın almayı ise iyi buluyorum.
Çeyrek başına 100 milyon doların üzerinde mühendislik donanımı, yazılımı ve hizmet harcamasına karar vermiş biri olarak, geliştirici aracı yapıyorsanız önce mevcut geliştiricilerin onu çok yararlı bulmasını ve güçlü biçimde savunmasını sağlamalısınız.
Şeffaf olmayan sözleşmeler, lock-in, veri güvenliği ve gizlilik, tek oturum açma ve kimlik doğrulama entegrasyonu gibi veto kalemlerine dokunmamalısınız.
Fiyat da makul olmalı. Herhangi bir değişkene doğrusal olarak bağlı fiyatlandırma, finans tablolarında mantıksız görünebilir. Geliştirici başına aylık ücretlendirme anlaşılması kolaydır; şirket çapında floating lisans daha iyidir, şirket genelinde sınırsız toplu ücretin daha uygun olduğu durumlar da vardır.
Son yöntemde bile bulut işlem ve depolama gibi tüketim maliyetlerini aynen yansıtabilirsiniz. Müşterinin bulut hesabına doğrudan dağıtım yapabiliyorsanız veri güvenliği ve gizlilik sorunları da çözülür.
Fatura üst sınırı, kullanım üst sınırı, pahalı kullanım ücretlerine yol açan ayarların sınırlandırılması ve yeterli kullanım raporlaması gibi maliyet kontrolleri sunmalısınız.
İyi yaparsanız taahhütlü harcama içeren çok yıllı sözleşmeler de mümkün olur. Hizmet güvenilirliğini korumalı, büyük müşterilerle çeyrek dönemlik değerlendirmeler yaparak memnuniyeti ve karşılanmamış ihtiyaçları anlamalısınız.
Özel mühendis ve destek gibi üst düzey profesyonel hizmetler de sunup ücretlendirebilirsiniz. Bunlar yüksek kârlıdır ve belirli bir müşteriyi kazanmak ya da elde tutmak için kritik olabilir.
Ürün müşteri şirketi içinde tartışmalı hâle gelebilir ve karşı çıkan biri ürünün benimsenmesini başarısızlığa uğratabilir; bu nedenle profesyonel hizmetlerin ilk entegrasyon ve uygulamayı üstlenmesi, BT kapı bekçilerinin müdahalesini azaltıp gerçek kullanıcılara ulaşmayı sağlayabilir.
Müşterinin kendi yapabileceğine güçlü biçimde inandığı bir ürünü satmaya çalışmamak daha iyidir. Bu kanaat yanlış olsa bile başta kazansanız da sonunda kaybetme ihtimaliniz yüksektir.
Yapmak mı satın almak mı sorusundaki 7. madde genelde bu kadar siyah-beyaz değildir. En zor durum, zaten şirket içinde bir ürünün olması ve sizin onu değiştirmeye ya da yeni özellik eklemeye çalışmanızdır.
Sorun, build vs. buy yatırım getirisinin ne zaman değerlendirileceğidir.
Entegrasyon maliyeti çok yüksek bir ürünü satın almak da fiilen onu yapmakla aynı şeydir. Entegrasyon geliştirici zamanı gerektirir; o zaman başka işlere ya da ürünün kendisine harcanabilirdi.
Bunun kavram kanıtı entegrasyonu sırasında ortaya çıkması iyi olurdu, ama o aşamada bile işi yürütecek geliştirici zamanı gerekir.
Şirkete göre değişir. Eskiden çalıştığım şirketin politikası şuydu: “İşinizi kolaylaştıracak kitap, lisans, hatta donanım gibi ne gerekiyorsa alın. Karar vermek için harcanan yönetim maliyeti daha pahalı, bu yüzden varsayılan anında onay.”
Geliştiriciler satın almaya hücum etti mi? Hayır; politika öncesiyle aynı düzeyde satın aldılar. Gerçekten de hayat daha rahat hale geldi.
Kitapları, lisansları ve donanımı kalem ya da kâğıt gibi sarf malzemesi olarak görmüşlerdi. IDE gibi küçük yerel yazılımlar için bu genel olarak doğru olabilir.
Geliştiricilere yönetici yetkisi verileceğine güvenmek ya da şirket BT’sinin kuruluma izin verebilmesi ön koşul.
Herkese küçük bir bütçe verilebilir ya da ekip/departman düzeyinde yönetilebilir; ama iş şirket BT entegrasyonu gerektirdiği ana geldiğinde pek iyi işlemez.
Bu yaklaşım iyi ve kesinlikle olmaz demek istemiyorum; ancak ani satın alma patlaması tek başarısızlık biçimi değil.
10, 20 yıl bırakırsanız çok farklı görünebilir. Yavaş ve görünmez maliyet artışları birikir; biraz daha az harcayan insanların başkalarını müsrif göstermemek için bir şeyler satın almak zorunda kaldığı bir kültüre de dönüşebilir.
Maliyet artışını teşvik eden çok sayıda incelikli mekanizma var; bu yüzden ters yönde iten düzenekler gerekli. Bence bu hâlâ çözülmemiş bir sorun.
Cömert bir bütçe sınırı koyup bunun tamamının harcanması gerektiği anlamına gelmediğini açıkça söylemek ve yıl sonunda kalan tutarın belirli bir yüzdesini herkesin kabul edebileceği iyi bir yere bağışlama kuralı da mümkün görünüyor.
“Kitap alabilirsiniz. Ama o kitap yüzünden midilli bağışının 5 dolar azalacağını unutmayın” gibi. Deniz ineği olursa benim Chromebook’la çalışmak zorunda kalma riskim var.
Sorun, yöneticinin her karara dahil olmasında. İnsanlar yöneticinin yardımcı olmak için orada olduğunu düşünüyor, ama çözdüğünden daha fazla sorun yaratıyor.
Çoğu zaman en iyi ihtimalle beceriksiz oluyorlar; birkaç yöneticiyi azaltıp maaşlarını takdir bütçesi olarak kullanmak daha iyi. Herkes kazanır.
Mevcut şirkette bu tür satın almalarla ilgilenen, HR benzeri birkaç görevli var. Gerekli donanım ya da yazılımın bağlantısını e-postayla gönderince eve kadar teslim ediyorlar.
Şirketin sipariş ve teslimat süreçlerini bilmem gerekmiyor; şimdiye kadar gördüğüm en iyi yöntem buydu.
Benzer bir deneyimim var. Herkese kurumsal kart verdiler ve kullanmaya teşvik ettiler.
Çalışanken bu sorunu bir kez yaşadım. ThinkPad istiyordum ama yönetim berbat bir Dell’de ısrar ediyordu; sonunda ThinkPad aldım.
Onun dışında kitap ya da araç istediğimde doğrudan veriliyordu; pahalı ayrık klavye bile mümkündü.
Artık serbest çalıştığım için ihtiyacım olanı doğrudan alıyorum. Aslında çok fazla şeye ihtiyacım olmuyor.
Para harcamaya değecek kadar faydalı “geliştirici aracı” çok değil; iş akışıma entegre etmeye değecek olanlar daha da az. Zaman geçtikçe bu son kısım daha önemli hale geldi.
Şirket hayatı böyledir.
Berbat bir Dell aldım, bozuldu; yine berbat bir Dell aldım, yine bozuldu; sonra yine Dell aldım.
“Yalnızca Dell ile sözleşmemiz var” diyorlar; “başta Dell ile sözleşme yapmamanız gerekmez miydi?” deyince sessizlik oluyor ve ancak o zaman kafalar çalışmaya başlıyor.
Dell’in bozulduğu anın hayattaki en iyi an olduğunu fark ediyorsunuz. Yeni cihaz göndermeleri için satın alma siparişi ve sipariş politikası katmanlarından geçmek 5 gün sürüyor; o 5 gün boyunca da acımasız şirket güvenlik politikaları yüzünden hiçbir şey yapamıyorsunuz.
Böylece 5 gün uyuyor, arkadaşlarla iletişime geçiyor ve yeniden insan oluyorsunuz.
Dell’i seviyorum. ThinkPad istemiyorum.
Kişisel kullanım için MacBook kullanıyorum.
Sormak zorundaysanız yetkiniz yok demektir.
Eskiden bir mühendislik şirketinin satış odaklı yan kuruluşunda çalıştım.
İlk zamanlarda 100 dolarlık öğle yemeği ısmarlamak sorunsuzdu ama bilgisayarım için 30 dolarlık kart alamıyordum.
Buna karşılık ana şirkette 5 bin dolarlık test ekipmanı kolayca alınabiliyordu; ama birini fast food restoranına götürmek için üç ayrı form doldurmak gerekiyordu.
Görev süremin sonlarına doğru iki tarafta da o formlar olmadan fiilen hiçbir şey yapılamaz hale gelmişti.
Başarılı birçok geliştirici aracı şirketi, geliştiriciye değil patrona pazarlama yaparak para kazandı. Bu yalnızca teknolojide değil, pek çok alanda böyle.
Gerçekten katılıyorum. Büyük teknoloji şirketlerinden birinde bir iş için sabit diske ihtiyacımız vardı; tek bir HDD için 200 doları masraf göstermektense 5 bin dolarlık bir disk dizisi satın alıp içinden diski çıkarmak daha kolaydı.
Kendi alanınızın dışındaki bir şeyi almaya çalışmak saçma derecede karmaşıktı.
Son zamanlarda şirket “kurumsal kartınız var, kullanın” dedi ve etkinliklerle ilgili masrafları EVP’ler onayladı. Alışılmış bir şey değildi, ama bazen bürokratik süreçleri kesmek gerektiğini bilmeleri etkileyiciydi.
Bir sonraki sıradan masraf beyanımda, 20 dolarlık taksi fişinde başlangıç ve varış noktası yok diye muhasebeyle kavga edecekmişim gibi geliyor.
Yazılım lisanslarını kendim satın alıp vergiden düşüyorum. Bu, sahte tasarruftan kaçınmanın yolu.
Uygun ve ucuz araçları bulup kendim satın aldığım için iş yerinde ödül de aldım, belirli bir projede vazgeçilmez hale geldim, maaş artışı aldım ve istediğim işleri seçebilir oldum.
Benim Jetbrains lisansım bunun tipik örneği. Onsuz kod refactoring yapmayı hayal etmek zor.
Şirketin maliyet kısması durursa iş yerindeki rakiplerim artar.
Teorik olarak Birleşik Krallık vergi sisteminde de mümkün. Self Assessment formunda, işverenin geri ödemediği işle ilgili giderleri talep etmek için bir bölüm var.
Eski işverenim düşük kilometre ücreti ödediği için aradaki farkı vergi beyanında talep ederdim.
Yazılım için izin verilen gider sayılıp sayılmayacağı konusunda kriterlerin nasıl uygulanacağından emin değilim.
Ben de yıllardır aynı şekilde yapıyorum.
Çoğu şirket işe uygun doğru yazılımı satın almadığı için ekipte en etkili çalışan kişi haline geldim. Çünkü diğerlerinden farklı olarak işleri hızlı ve verimli şekilde halledebiliyorum.
Birçok şirkette bunu yaparken yakalanırsanız büyük sıkıntı yaşarsınız.
ABD’de W2 statüsündeki vergiden muaf çalışanların bunu “vergiden düşme” işini nasıl yaptığını merak ediyorum.
Başka ne gibi örnekler olduğunu merak ediyorum.
Azure, AWS veya Google Cloud’a koyabiliyorsanız iş değişir
Tek bir kalemi bile onay almadan satın alamazsınız, ama şirketin bulut ortamında sormadan binlerce dolar harcayabilirsiniz
Amazon Marketplace’in sihri de burada. AWS dışı hizmetleri de satın alabilirsiniz; yine de AWS faturasına yansır ve şirketin harcama taahhüdüne katkıda bulunur
Doğru. Bir geliştiriciden bir FTP sunucusu kurmasını istemiştim. İyi bir Linux yöneticisiydi ve 10 sterlinlik VPS’lerde bu işi birçok kez yapmış biriydi
Ama bu kez ayda 1.000 sterlinden fazla tutan bir AWS hizmeti seçti. Kart ekstresi geldiğinde büyük bir baş ağrısına dönüştü; üstelik bir sonraki ayın ücreti de epey işlemişti
Ondan sonra daha sıkı kontrol etmek zorunda kaldık
Bende de benzer. Doğru kişilere localstack’i değerlendirtmek büyük ve zorlu bir mücadele olacak gibi görünüyor
Ama kurumsal lisans alınırsa yalnızca tasarrufla maliyeti hemen çıkarabileceği için, asıl işim olmasa da denemem gerektiğine dair baskı hissediyorum
Adil olmak gerekirse, bunun nedeni henüz kimsenin terraform apply komutunu SAP onay akışı ile entegre etmenin yolunu bulamamış olması
Mühendisin karar verici olduğu bir iş modeli gayet mümkün. Ancak bu, mühendisin kapsam dışına doğrudan etkisi olmadan yerel optimizasyon yapabildiği araçlarla sınırlı
IDE bunun en iyi örneği. Şirketin mühendislerinin her birinin kendi verimliliklerini artıracak kişisel IDE kararları almasına izin verilse bile, bu kararların toplam küresel etkisi kabul edilebilir olabilir. Jetbrains bunu gösteriyor
Ama her araç böyle değil. Orijinal yazı Redis, Terraform ve AWS gibi ikinci kategoriye giren örnekleri ele alıyor
IDE’den farklı olarak veritabanı, altyapı yönetimi ve bulut altyapısında bireysel kararların yayılması sorun yaratır. Şirket heterojen bir stack’i sürdürmek zorunda kalır; satıcı da bir ekibin Redis’i seçmiş olmasına dayanarak anlamlı bir kurumsal sözleşme çıkaramaz
Bu yüzden bir ölçüde standartlaşma gerekir. O noktada seçimin etkisi ve lisans ölçeği büyüdüğü için, yalnızca mühendislik liderleri değil finans da söz sahibi olmak ister. Bunun haklı nedenleri vardır
Ve finans devreye girdiği anda, seçimi çoğu mühendis için zor olan bir dille gerekçelendirmeniz gerekir
Benim satın alma yetkim şöyle işliyor. Yöneticime “Bu geliştirici aracını alırsak X saat geliştirici zamanı tasarruf ederiz” diyorum
Burada X’in aracın fiyatına kıyasla yeterince büyük olması gerekiyor. Bu yöntem epey iyi çalıştığı ve sık kullandığım için yöneticim artık buna şüpheyle bakıyor
Şüpheyle bakması doğru. İster araç ister yeniden tasarım olsun, faydaları abartmak, efor tahminlerini düşük tutmak kadar yaygındır; ikisi muhtemelen güçlü biçimde ilişkilidir
Bu, değerli araç olmadığı anlamına gelmez. Var, ama çok nadir
Yöneticinin “Son 3 ayda önerdiğin araçların toplamda 1 geliştirici-yılı tasarruf sağlayacağını söyledin; o halde ekipten 1 geliştiriciyi azaltıp işleri ve takvimi aynı tutacağım” demesi ne kadar sürer acaba
“Geliştirici zamanı bir KPI değil; ayda 160 saat de çalışsanız 180 ya da 200 saat de çalışsanız maaş aynı” şeklinde bir yanıt gelebilir
1 yorum
Hacker News görüşleri
Büyük ölçüde doğru, ama bence satış veya finans çalışanlarının da öyle çok satın alma yetkisi yok. Bu yüzden herkes şirketin izin verdiği araçları ya da ücretsiz planları kullanıyor ve sonunda bunu yöneticisine satmak zorunda kalıyor.
Zaman kazandıracağını, projeleri daha şeffaf hâle getireceğini ve özgürlüğü azaltacağını anlatarak ikna etmek gerekiyor.
Excel’in bu kadar yaygın kullanılmasının nedeni de büyük olasılıkla bu. Şirket BT’sinin izin verdiği en güçlü araçlardan biri de Excel.
Satış ya da finans departmanında çalışırken PC’ye WSL kurma izni almaya çalışırsanız anlarsınız. Web uygulamalarının popüler olmasının nedeni de şirket BT’sinin ancak bildiği şeyi engelleyebilmesi.
Bir pazarlama yöneticisi kendi kartıyla Basecamp ödeyebilir; ama kendi barındırdığı bir aracı içeri almak isterse, “bilgisayarları biz yönetiriz, çalışma biçimine de biz karar veririz” diyen BT politikasından geçmesi gerektiği için iş büyür.
Tüm m365 lisanslarına dahildir ve kalıcı lisansları da uzun süre görece ucuzdu.
Satış ekibine WSL izni verilmesi fikri, insanın “gerçek satışçılarla hiç çalıştınız mı?” diye sormasına yol açıyor. Şirketlerin %99’unda teknolojiye yatkın satışçılar bile yardım almadan e-postaya ek dosya göndermeyi ancak başarır; WSL ile ne yapacaklarını bilmiyorum.
Bu tür küçük satın almaların hepsini onaylamak çok fazla iş çıkarır; incelenmezse de kullanılmayan abonelikler her yerde birikir ya da şirkete pek faydası olmayan birçok şey satın alınır.
Buna karşılık pazarlama tarafının satın alma yetkisi epey geniş görünüyordu; sanırım işin doğası her türlü şeyi satın almakla ilgili olduğu için.
Tek bir uygulamanın ele geçirilmesi bile tüm şirket BT’sini riske atabilir; izolasyon ya da zero trust uygulansa bile saldırı yüzeyi ve güvenlik maliyeti artar.
Aslında kendi barındırılan bir uygulamayı satın almak işin kolay kısmıdır; zor olan, işin ihtiyaç duyduğu süre boyunca her gün güvenilir şekilde çalıştırmaktır. Verilerin uzun süre saklanmasını gerektiren yasal durumlar da olabilir.
Sahadaki BT ekibinin talep ettiği bir araç olsa bile, bazı teknik yönetimleri yapabilirler; ancak çoğu zaman zamanları yoktur ya da sadece geliştiricidirler, sistem/ağ yöneticisi değildirler.
Sonuçta şirket BT’sinden ayrılmış bir sandbox kullanmak, yedekleme ve AD gibi kolaylıklardan vazgeçmek ya da shadow IT olarak bunu kendiniz uygulayıp sürdürmek gerekir.
Bu yüzden SaaS ve bulutun büyümesinin nedenlerinden birinin de bu maliyetleri dışsallaştırmak olduğunu düşünüyorum.
50 dolarlık bir kitap almak için mücadele etmeniz gerekiyorsa muhtemelen yanlış şirketi seçmişsinizdir.
Öte yandan bazı geliştiriciler Notion’ı içeride test etmek için kartla gayriresmî bir hesap açtı; önemli özet dokümanlarını orada oluşturup bağlantısını dolaştırdılar.
Bunu görmek isteyen şirketin yarısı zımnen hesap oluşturdu ve ertesi ay CFO’ya 10 bin dolarlık fatura geldi.
Geliştiricilere satın alma yetkisi verilmemesi gerektiğine dair hikâyeler genelde böyle başlar.
Birçok SaaS şirketinin peşin ödeme ya da sabit maliyet tavanı seçeneğini doğru düzgün sunmamasının bir nedeni var. Dolandırıcılığa yakın.
Bunun “geliştiricilerin satın alma yetkisinin olmamasına yol açan hikâyenin başlangıcı” olduğuna inanmak zor.
Örneğin araçlar parçalanır ve tek bir aramayla bilgi bulunamaz ya da her ekip farklı araçlara ayrı ayrı giriş yapmak zorunda kalır.
Ekipler şirket fikrî mülkiyetini barındıran araçları kafalarına göre yönetirse, SOC uyumluluğu hedeflendiğinde bu bir compliance kâbusuna dönüşür.
Kitap ya da öğrenme materyali satın almayı ise iyi buluyorum.
Çeyrek başına 100 milyon doların üzerinde mühendislik donanımı, yazılımı ve hizmet harcamasına karar vermiş biri olarak, geliştirici aracı yapıyorsanız önce mevcut geliştiricilerin onu çok yararlı bulmasını ve güçlü biçimde savunmasını sağlamalısınız.
Şeffaf olmayan sözleşmeler, lock-in, veri güvenliği ve gizlilik, tek oturum açma ve kimlik doğrulama entegrasyonu gibi veto kalemlerine dokunmamalısınız.
Fiyat da makul olmalı. Herhangi bir değişkene doğrusal olarak bağlı fiyatlandırma, finans tablolarında mantıksız görünebilir. Geliştirici başına aylık ücretlendirme anlaşılması kolaydır; şirket çapında floating lisans daha iyidir, şirket genelinde sınırsız toplu ücretin daha uygun olduğu durumlar da vardır.
Son yöntemde bile bulut işlem ve depolama gibi tüketim maliyetlerini aynen yansıtabilirsiniz. Müşterinin bulut hesabına doğrudan dağıtım yapabiliyorsanız veri güvenliği ve gizlilik sorunları da çözülür.
Fatura üst sınırı, kullanım üst sınırı, pahalı kullanım ücretlerine yol açan ayarların sınırlandırılması ve yeterli kullanım raporlaması gibi maliyet kontrolleri sunmalısınız.
İyi yaparsanız taahhütlü harcama içeren çok yıllı sözleşmeler de mümkün olur. Hizmet güvenilirliğini korumalı, büyük müşterilerle çeyrek dönemlik değerlendirmeler yaparak memnuniyeti ve karşılanmamış ihtiyaçları anlamalısınız.
Özel mühendis ve destek gibi üst düzey profesyonel hizmetler de sunup ücretlendirebilirsiniz. Bunlar yüksek kârlıdır ve belirli bir müşteriyi kazanmak ya da elde tutmak için kritik olabilir.
Ürün müşteri şirketi içinde tartışmalı hâle gelebilir ve karşı çıkan biri ürünün benimsenmesini başarısızlığa uğratabilir; bu nedenle profesyonel hizmetlerin ilk entegrasyon ve uygulamayı üstlenmesi, BT kapı bekçilerinin müdahalesini azaltıp gerçek kullanıcılara ulaşmayı sağlayabilir.
Müşterinin kendi yapabileceğine güçlü biçimde inandığı bir ürünü satmaya çalışmamak daha iyidir. Bu kanaat yanlış olsa bile başta kazansanız da sonunda kaybetme ihtimaliniz yüksektir.
Sorun, build vs. buy yatırım getirisinin ne zaman değerlendirileceğidir.
Entegrasyon maliyeti çok yüksek bir ürünü satın almak da fiilen onu yapmakla aynı şeydir. Entegrasyon geliştirici zamanı gerektirir; o zaman başka işlere ya da ürünün kendisine harcanabilirdi.
Bunun kavram kanıtı entegrasyonu sırasında ortaya çıkması iyi olurdu, ama o aşamada bile işi yürütecek geliştirici zamanı gerekir.
Şirkete göre değişir. Eskiden çalıştığım şirketin politikası şuydu: “İşinizi kolaylaştıracak kitap, lisans, hatta donanım gibi ne gerekiyorsa alın. Karar vermek için harcanan yönetim maliyeti daha pahalı, bu yüzden varsayılan anında onay.”
Geliştiriciler satın almaya hücum etti mi? Hayır; politika öncesiyle aynı düzeyde satın aldılar. Gerçekten de hayat daha rahat hale geldi.
Geliştiricilere yönetici yetkisi verileceğine güvenmek ya da şirket BT’sinin kuruluma izin verebilmesi ön koşul.
Herkese küçük bir bütçe verilebilir ya da ekip/departman düzeyinde yönetilebilir; ama iş şirket BT entegrasyonu gerektirdiği ana geldiğinde pek iyi işlemez.
10, 20 yıl bırakırsanız çok farklı görünebilir. Yavaş ve görünmez maliyet artışları birikir; biraz daha az harcayan insanların başkalarını müsrif göstermemek için bir şeyler satın almak zorunda kaldığı bir kültüre de dönüşebilir.
Maliyet artışını teşvik eden çok sayıda incelikli mekanizma var; bu yüzden ters yönde iten düzenekler gerekli. Bence bu hâlâ çözülmemiş bir sorun.
Cömert bir bütçe sınırı koyup bunun tamamının harcanması gerektiği anlamına gelmediğini açıkça söylemek ve yıl sonunda kalan tutarın belirli bir yüzdesini herkesin kabul edebileceği iyi bir yere bağışlama kuralı da mümkün görünüyor.
“Kitap alabilirsiniz. Ama o kitap yüzünden midilli bağışının 5 dolar azalacağını unutmayın” gibi. Deniz ineği olursa benim Chromebook’la çalışmak zorunda kalma riskim var.
Çoğu zaman en iyi ihtimalle beceriksiz oluyorlar; birkaç yöneticiyi azaltıp maaşlarını takdir bütçesi olarak kullanmak daha iyi. Herkes kazanır.
Şirketin sipariş ve teslimat süreçlerini bilmem gerekmiyor; şimdiye kadar gördüğüm en iyi yöntem buydu.
Çalışanken bu sorunu bir kez yaşadım. ThinkPad istiyordum ama yönetim berbat bir Dell’de ısrar ediyordu; sonunda ThinkPad aldım.
Onun dışında kitap ya da araç istediğimde doğrudan veriliyordu; pahalı ayrık klavye bile mümkündü.
Artık serbest çalıştığım için ihtiyacım olanı doğrudan alıyorum. Aslında çok fazla şeye ihtiyacım olmuyor.
Para harcamaya değecek kadar faydalı “geliştirici aracı” çok değil; iş akışıma entegre etmeye değecek olanlar daha da az. Zaman geçtikçe bu son kısım daha önemli hale geldi.
Berbat bir Dell aldım, bozuldu; yine berbat bir Dell aldım, yine bozuldu; sonra yine Dell aldım.
“Yalnızca Dell ile sözleşmemiz var” diyorlar; “başta Dell ile sözleşme yapmamanız gerekmez miydi?” deyince sessizlik oluyor ve ancak o zaman kafalar çalışmaya başlıyor.
Dell’in bozulduğu anın hayattaki en iyi an olduğunu fark ediyorsunuz. Yeni cihaz göndermeleri için satın alma siparişi ve sipariş politikası katmanlarından geçmek 5 gün sürüyor; o 5 gün boyunca da acımasız şirket güvenlik politikaları yüzünden hiçbir şey yapamıyorsunuz.
Böylece 5 gün uyuyor, arkadaşlarla iletişime geçiyor ve yeniden insan oluyorsunuz.
Dell’i seviyorum. ThinkPad istemiyorum.
Kişisel kullanım için MacBook kullanıyorum.
Eskiden bir mühendislik şirketinin satış odaklı yan kuruluşunda çalıştım.
İlk zamanlarda 100 dolarlık öğle yemeği ısmarlamak sorunsuzdu ama bilgisayarım için 30 dolarlık kart alamıyordum.
Buna karşılık ana şirkette 5 bin dolarlık test ekipmanı kolayca alınabiliyordu; ama birini fast food restoranına götürmek için üç ayrı form doldurmak gerekiyordu.
Görev süremin sonlarına doğru iki tarafta da o formlar olmadan fiilen hiçbir şey yapılamaz hale gelmişti.
Başarılı birçok geliştirici aracı şirketi, geliştiriciye değil patrona pazarlama yaparak para kazandı. Bu yalnızca teknolojide değil, pek çok alanda böyle.
Kendi alanınızın dışındaki bir şeyi almaya çalışmak saçma derecede karmaşıktı.
Son zamanlarda şirket “kurumsal kartınız var, kullanın” dedi ve etkinliklerle ilgili masrafları EVP’ler onayladı. Alışılmış bir şey değildi, ama bazen bürokratik süreçleri kesmek gerektiğini bilmeleri etkileyiciydi.
Bir sonraki sıradan masraf beyanımda, 20 dolarlık taksi fişinde başlangıç ve varış noktası yok diye muhasebeyle kavga edecekmişim gibi geliyor.
Yazılım lisanslarını kendim satın alıp vergiden düşüyorum. Bu, sahte tasarruftan kaçınmanın yolu.
Uygun ve ucuz araçları bulup kendim satın aldığım için iş yerinde ödül de aldım, belirli bir projede vazgeçilmez hale geldim, maaş artışı aldım ve istediğim işleri seçebilir oldum.
Benim Jetbrains lisansım bunun tipik örneği. Onsuz kod refactoring yapmayı hayal etmek zor.
Şirketin maliyet kısması durursa iş yerindeki rakiplerim artar.
Eski işverenim düşük kilometre ücreti ödediği için aradaki farkı vergi beyanında talep ederdim.
Yazılım için izin verilen gider sayılıp sayılmayacağı konusunda kriterlerin nasıl uygulanacağından emin değilim.
Çoğu şirket işe uygun doğru yazılımı satın almadığı için ekipte en etkili çalışan kişi haline geldim. Çünkü diğerlerinden farklı olarak işleri hızlı ve verimli şekilde halledebiliyorum.
Azure, AWS veya Google Cloud’a koyabiliyorsanız iş değişir
Tek bir kalemi bile onay almadan satın alamazsınız, ama şirketin bulut ortamında sormadan binlerce dolar harcayabilirsiniz
Ama bu kez ayda 1.000 sterlinden fazla tutan bir AWS hizmeti seçti. Kart ekstresi geldiğinde büyük bir baş ağrısına dönüştü; üstelik bir sonraki ayın ücreti de epey işlemişti
Ondan sonra daha sıkı kontrol etmek zorunda kaldık
Ama kurumsal lisans alınırsa yalnızca tasarrufla maliyeti hemen çıkarabileceği için, asıl işim olmasa da denemem gerektiğine dair baskı hissediyorum
terraform applykomutunu SAP onay akışı ile entegre etmenin yolunu bulamamış olmasıMühendisin karar verici olduğu bir iş modeli gayet mümkün. Ancak bu, mühendisin kapsam dışına doğrudan etkisi olmadan yerel optimizasyon yapabildiği araçlarla sınırlı
IDE bunun en iyi örneği. Şirketin mühendislerinin her birinin kendi verimliliklerini artıracak kişisel IDE kararları almasına izin verilse bile, bu kararların toplam küresel etkisi kabul edilebilir olabilir. Jetbrains bunu gösteriyor
Ama her araç böyle değil. Orijinal yazı Redis, Terraform ve AWS gibi ikinci kategoriye giren örnekleri ele alıyor
IDE’den farklı olarak veritabanı, altyapı yönetimi ve bulut altyapısında bireysel kararların yayılması sorun yaratır. Şirket heterojen bir stack’i sürdürmek zorunda kalır; satıcı da bir ekibin Redis’i seçmiş olmasına dayanarak anlamlı bir kurumsal sözleşme çıkaramaz
Bu yüzden bir ölçüde standartlaşma gerekir. O noktada seçimin etkisi ve lisans ölçeği büyüdüğü için, yalnızca mühendislik liderleri değil finans da söz sahibi olmak ister. Bunun haklı nedenleri vardır
Ve finans devreye girdiği anda, seçimi çoğu mühendis için zor olan bir dille gerekçelendirmeniz gerekir
Benim satın alma yetkim şöyle işliyor. Yöneticime “Bu geliştirici aracını alırsak X saat geliştirici zamanı tasarruf ederiz” diyorum
Burada X’in aracın fiyatına kıyasla yeterince büyük olması gerekiyor. Bu yöntem epey iyi çalıştığı ve sık kullandığım için yöneticim artık buna şüpheyle bakıyor
Bu, değerli araç olmadığı anlamına gelmez. Var, ama çok nadir