Son on yılda   liderlik ederek birçok yetenekli yazılım geliştiriciyle çalıştım ve görev sürelerinin başlarında genellikle aynı şeyi söylüyorum: daha küçük yazılım birimleri gönderin ve yerel ana bilgisayar şubelerinizin boyutunu sınırlayın. Neden? İşte iki temel neden ve büyük bir sorun: HackerNoon'a  1. Siz projeyi tamamlamak için çalışmaya devam ederken kullanıcılar çalışmanızdan daha fazla fayda elde eder ve çalışmanıza geri bildirimde bulunur.  6 ay sürecek bir projeniz varsa ve 6 ay boyunca yayına girmezse, bu, kullanıcıların işinizden sıfır fayda elde ettiği 5 ay 30'a yakın gün anlamına gelir. Yalnızca canlı yayındayken internetin geri kalanının gönderdiklerinizden faydalanma şansı olabilir. Ve o zaman bile, evlat edinme için zorlu mücadele tam da o zaman başlıyor. Bunun yerine projenin bir kısmını her hafta gönderirseniz kullanıcılar projenin yaşam döngüsü boyunca değer kazanmaya başlar.  Eski meslektaşım   bir keresinde bana şunu söylemişti: "Atom değer birimleri eklemeye devam etmeli ve ne kadar çok sürüm gerekiyorsa yayınlamalıyız. Memnun kalıp yola devam etmeye hazır olmadan önce [işlevsellik] konusunda kolayca 10 sürüm yayınlayabiliriz." Dane Lyons  CEO olarak, yeni işe alınanları genellikle kârlı katkıda bulunanlar haline gelmelerinin ne kadar zaman aldığına göre değerlendiririm. Satışlarda bu daha kesik ve kuru, satışları tazminatlarını aştı mı? Pazarlama, altyapı vb. marjinal maliyetler gibi elbette dikkate alınması gereken başka şeyler de vardır, ancak bunu nasıl dilimlerseniz bölün, bir yazılım geliştiricisinin kârı nasıl etkilediğini ölçmek bir satış elemanından daha zordur. Bir yazılım geliştiricisi olarak yeni bir rol üstleniyorsanız, sayı koşularına çıkmadan önce bekarları başarılı bir şekilde bir araya getirmeyi denemenizi öneririm.  Yazılım geliştirme oyununda puanın ne olduğuna ilişkin evrensel kurallar yoktur. Elbette bazı insanlar puan sistemleri atar ve diğerleri KPI'ları tanımlar, ancak günün sonunda, değer yaratıp yaratmadığınızı ve nasıl değer yaratıp yaratmadığınızı belirleyen, ürününüzü kullanan insanlardır. Daha erken gönderdiğinizde geri bildirimi daha çabuk alırsınız. Yazılımınızı kullanan kişiler, projenin bir sonraki atom ünitesinin nasıl inşa edileceğini ve inşa edilmeyeceğini daha net bir şekilde ortaya koyacaktır.  2. Şubeniz üretim gerçekliğinden ne kadar saparsa, ekip arkadaşlarınızın projenize katkıda bulunması ve bitişik projeleri ilerletmesi o kadar zor olur.  En güncel sürümün gönderilmemesinden kaynaklanan dışsallıkları ilk başta görmek daha zor olabilir. Her şey birbirine bağlı. Örneğin HackerNoon gibi bir üründe profil sayfası ve hikaye sayfası boşlukta mevcut değildir; tek bir üründe birbirine bağlı sayfalar olarak bulunurlar. Bir sayfanın işleyişinde değişiklik olması, ona bağlı tüm sayfaların işleyişini etkiler.  Yerel şubeniz çok büyükse, ona bağlı sayfalarda veya işlevlerde meydana gelen diğer değişiklikler, obez şubeniz nihayet üretime geçtiğinde genellikle işe yaramayacaktır. Bu işleri bozar. Bu hatalara neden olur. Bu, işi yeniden yapma ihtiyacını zorlar. Bu, ekip arkadaşlarınızın sizinle çalışmamak istemesine neden olur. Bu, yerel şubenizde yaptığınız tüm çalışmalardan önce sahip olduğunuzdan daha kötü bir ürün deneyimi bile yaratabilir.  Daha düzenli olarak küçük değişiklikler yaparak başkalarının katkıda bulunmasını sağlarsınız. Gönderdikleri şeyin de işe yarayacağını düşünüyorlar çünkü ikiniz de zaten üretim temel çizgisinin ne olduğu konusunda hemfikirsiniz. Artımlı senin arkadaşındır. Sizi gerçekliğe bağlar. Artan değişiklikler ürünü olumsuz etkiliyorsa, aynı yöndeki daha büyük değişikliklerin ürün deneyimini olumlu yönde etkileyeceğini size düşündüren nedir?  Ve büyük eski ama şu: Çok büyük dallara dönüşebilecek cesur projelerden korkmayın çünkü siz bu lanet şeyin insanlar için nasıl işlediği konusunda bir fark yaratabilecek kötü bir mofosunuz.  Bazı projelerin büyük dallar olması gerekir. Örneğin, yeni veritabanları gibi büyük bağımlılıklara sahip şeyler mevcut kullanıma o kadar yerleşmiş olabilir ki, zamanı geri alıp projeye yıllık şirket içi 2.0 sürümü gibi yaklaşmak en iyisi olacaktır. Ve ChatGPT gibi diğer çığır açan teknolojilerin oluşturulması o kadar uzun sürdü ki, yeni teknolojinin eğitimsiz, tamamlanmamış, boktan bir UX sürümünü yayınlamanın benimsenmesi mantıklı olmayacaktı. Büyük salınımlar yapın. Piste sahip olduğunuzda. Ekip gemiye bindiğinde. Ama kendinizi büyük göstermeyin. Çoğu zaman yazılım geliştirme tekerleği yeniden icat etmek anlamına gelmez. Sadece bir sonraki atom ünitesini gönderiyor.

Meet a HackerNoon Human About Business Blogging

smooke.eth

Ethereum Name Service

Founder & CEO of HackerNoon

Bu ses hikayenin orijinal dilinde üretilmiştir!

Daha Küçük Yazılım Birimleri Gönderin ve Yerel Ana Bilgisayar Şubelerinizin Boyutlarını Sınırlandırın

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Başarılı Buluta Geçiş İçin Tam Kılavuz: Stratejiler ve En İyi Uygulamalar

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Floki'den Valhalla Hindistan'ın Sri Lanka Turuna Yardımcı Sponsor Olarak Katıldı

Başarılı Buluta Geçiş İçin Tam Kılavuz: Stratejiler ve En İyi Uygulamalar

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Floki'den Valhalla Hindistan'ın Sri Lanka Turuna Yardımcı Sponsor Olarak Katıldı

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps