Program baskısını anlayabiliyorum. Kullanıcıları memnun etmek istersiniz, çünkü onlar şirketin can damarıdır. Ancak, bazı değişikliklerin yolda her şeyin daha kolay olacağı da doğrudur. Maalesef, kuruluşumdaki yönetim bu tür değişikliklere karşı içgüdüsel bir dirence sahip ve bu direnç o kadar güçlü ki uzun vadeli gelişmelere yol açıyor.

Örneğin, Apple son zamanlarda iOS programları için Otomatik Referans Sayımı uygulamasını başlattı. Bu, daha önce kullanmak zorunda kalınan manuel tutma / bırakma çağrıları üzerinde büyük bir gelişmedir. Kodun yazılması ve bakımı kolaydır. Değişimin kendisinin bazı çökmelere neden olması muhtemel. Ancak bunlar çözüldüğünde, rastgele garip kazaların sayısının düşmesi muhtemel.

Yakın zamanda patronuma, otomatik referans saymaya geçmek istediğimi söyledim. Yanıtı, gözle görülür gelişmelere odaklanmak istediği yönünde oldu. Muhtemelen bu müdahalenin kendisinden yukarıdan aldığı baskıdan kaynaklanıyor olması muhtemeldir - ve muhtemelen doğrudan CEO’dan.

Bir sürü benzer örnek var. Ortak konu, bir şeyin düzeltilmesi gerektiği, ancak düzeltmenin kısa vadeli maliyetlerinin, kısa vadeli faydalara ağır bastığında, “kısa vadeli” nin “önümüzdeki birkaç hafta içinde” olarak tanımlanmasıdır.

Durumu nasıl ele almalıyım?

EDIT: Cevaplar için teşekkürler. Gelmelerini sağla. Durumumla alakalı olduğu için müdürümün ve CEO'mun her iki programcının da olduğunu açıkça belirtmeliyim - ancak CEO artık bunun nasıl bir şey olduğunu unutmuş olabilir. Görünüşe göre programcı tarafları diğer baskılar karşısında şaşkına döndü.

Gerçekten teknik borçlardan bahsediyorsun. Belki bir metafor yöneticilerinize yardımcı olabilir. Genellikle teknik borcun yazılımdaki etkisini kirli bir mutfakta yemekle karşılaştırıyorum. Lavabo, tezgahlar ve ocaklar kirli bulaşıklarla doluysa ve yerde çöp varsa, yemek yapmak daha uzun sürer. Ancak, bir sonraki yemeği hazırlamanın en hızlı yolu karmaşa etrafında çalışmaktır. Mutfağın temizlenmesi ve temiz tutulması bir sonraki yemeği geciktirecek, ancak sonraki tüm öğünlerin teslimatını iyileştirecektir. Ve yemek odasındaki aç kişinin dağınık mutfağı göremediği ve neden pişirmeye başlamadan önce temizlemek istediğinizi anlamayacağınız gibi, yönetiminiz koddaki karışıklığı göremiyor. Onlara karmaşayı göstermeniz veya karmaşadan kaynaklanan kalite sorunlarını ve gecikmeleri göstermeniz gerekir.

Belki de acil işler ve önemli görevler hakkında da konuşabilirsiniz. Önemli görevler yapılmadığında, acil görevler daha uzun sürer ve daha pahalı olur.

Her yerde programcıları kariyerlerinin bir noktasında rahatsız eden bir şeye rastladınız : bu kodun yeniden gözden geçirilmesi gerekiyor, orada mimari meseleler var, bu modül sürdürülemez hale geliyor. Sadece doğrudan görülebilen faydalar sağlayan işe odaklanmaya zorlanıyorsunuz .

Yine klasik Iceberg Sırrı . İşin sırrı, bir buzdağının% 90'ı su altında olduğu gerçeğiyle ilgili olmalı, bu nedenle herhangi bir geliştirme projesinin çoğunluğu : Çalışmanın% 90'ı son kullanıcı tarafından tamamen görünmez olacak. Bu kod son kullanıcı üzerinde bir etkiye sahip olacak, ancak yönetim, aklınızı altı saat boyunca neden Farklı Göremediklerinde ve her şey yolunda mı çalışıyorsa otomatik referans aramalarını reddetmek için harcadığınız zamana çevirme konusunda güçlük çekiyor.

İşte bu konuda yanınıza alabileceğiniz bazı gerçekler.

• Yönetim, programcılar olmadıkça , Iceberg Sırrı'nı anlamayacaklar.
• Bu cehalet sorunu, kötülük değil. CEO iyi bir ürün istiyor - iyi bir ürüne giden her şeyi anlamıyor.
• CEO (ve doğrudan patronunuz) aptal değil - bu konuda zaman harcamanız için neden bazı gerçekleri ve bazı somut verileri ve diğer Iceberg sorunlarını inceleyin ve hazırlayın .

Unutma, sen bir şirket erkeksin (ya da kadınsın). Bir kodcu değil . Bu ürünü, başarısı veya başarısızlığı ile ilgili belli bir ilgiye sahip bir şirket için geliştiriyorsunuz - projeleriniz ve proje teklifleriniz bunu yansıtmalıdır. Şirkete ve ürüne olan tutkunuzu gösterin, bilginizi gösterin ve patronunuza ve CEO'nuza, onlara geldiğinizde size güvenmeleri gerektiğini ve Bir Şeylerin İhtiyaç Duyması gerektiğini söyleyin. Alt satırda nasıl bir katkı sağlayacağını gösterin - ürüne değer katarak (kopyalarını satın alan daha fazla insan) veya yoldan aşağıya zaman kazandırarak (ürününüz başarısız olduğunda daha az kızgın müşteri).

Sen değil.

Bu soruyu ve bunun gibi tüm soruları çıkmaz bir bit olarak görüyorum. İnsanları hiçbir şeyden ikna edemezsin. Eğer böyle şeylerin farkında değillerse ya da araştıracaklarsa, bir şans vermezler. Ve hiçbir veri başka türlü onları ikna edemez. Değişim içinden gelmelidir. Bir atı suya götürebilirsin ama onu içmesini sağlayamazsın.

Diyelim ki istediğiniz değişiklikleri bir sonraki teknik tahminlerinize ekleyin. Olur gibi, hey, biz Apple tanıtılan bu yeni çerçeveye yükseltme "zorunda". ARC'yi kullanmanın yol haritanızda olmasına izin vermeyin. Seçenek yok; ARC'ye göç etmek tek yoldur.

Burada benzer bir soruyu daha önce de cevapladım, bu nedenle bu bir yinelenen sayılabilir. Temel olarak, bir "yeniden düzenleme çabası" yapmak için imza atmayacaksınız. Kodu daha temiz hale getirmenin yolu, izci kuralını izlemektir: kodu, geldiğiniz zaman bıraktığınızda daima temiz tutar.

Tıpkı gerçek borcunun ödenmesi gibi aşılmaz bir görev gibi görünebilir (veya dağınık bir evi temizlemek). İşin püf noktası, “temizlik adalarını” görmeye başlayana kadar parça parça daha iyi hale getirmektir. Önemli bir ivme kazandığınızda, ekipteki diğer geliştiriciler farkedilmeye ve sonunda işe katkıda bulunmaya başlayacaktır.

Temiz kodlayıcıyı "Amca" Bob Martin tarafından okumanı öneririm . İyi kod yazmak işinizin bir parçasıdır. İşini yapmak için izin istemiyorsun, sadece yap.

Bu nitelikteki diğer sorularda olduğu gibi, yönetimin anlayacağı sayıları sağlamanız gerekir. Bu geliştirmelerin uygulanmasıyla ne kadar zaman kazanılacağını, ne kadar az "rastgele tuhaf kaza" olacağını vb. Gösteren rakamlar Onları, kazaların son kullanıcı tarafından görülebilir olduğuna ve bunların önlenmesi için yapılan her şeyin iş için iyi olduğuna ikna edin.

Ayrıca, bu iyileştirmeleri kendi zamanınıza (örneğin mesai saatleri dışında) uygulamaya başlayabilir ve daha sonra yönetime faydaları gösterebilirsiniz. Bunu ancak yönetimin neyi iletmeye çalıştığınızı anlamadığı ve / veya bunu denemeniz için zaman ayırmak istemedikleri anlaşılıyorsa yapardım.

İyi şanslar!

İş Davası Sunun

Mühendis tavsiyelerinin sıklıkla göz ardı edilmesinin birçok nedeni vardır. Neredeyse tüm nedenlerin üstesinden gelmenin en iyi yolu, neden yapılması gerektiğine dair iş vakasını sunmaktır. Klasik maliyet / fayda analizi. Bu sadece zorlayıcı bir argüman oluşturmakla kalmaz, aynı zamanda patronlarınıza üstlerine çıkmaları için bir şeyler verir.

• Ön ödeme maliyeti nedir?
• Devam eden maliyet nedir?
• Öngörülen para / zaman tasarrufu nedir ve nereden geliyorlar?
• YG'yi görmemiz ne kadar sürer?

Bir iş vakası yaparken argümanınızı her zaman verilerle yedeklemelisiniz.

• Geliştirme şu anda bu sorunla başa çıkacak veya giderecek sorunları çözmek için ne kadar zaman harcıyor?
• Bu sorunun kaldırılması veya azaltılması gereken sorunlar ile ilgili kaç kullanıcı şikayeti alıyorsunuz?
• Başka ne gibi faydaları olacak?

Sayıları sıralayın ve kaba ama basit bir denklem yapın. Yapması X'e mal olacak ve Y şirketine fayda sağlayacak.

Not: Akademik olarak iyi bir fikir uygulamanın çok pahalı olduğu takdirde şaşırmayın.

Bu tür bir değişiklik yeniden düzenleme kategorisine girer. Çevik yaklaşım, AMPLE'ın yeniden yapılanma süresini tahmin ettiğiniz her hikayeye dahil etmeniz gerektiğidir ve bu tam olarak nedeni budur. Mühendisler dışında kimse neden bunu yapmak istediğinizi anlamayacak ve sorun değil, doğru şekilde nasıl kodlanacağını belirlemek onların işi değil, sizindir.

Bir dahaki sefere yapacak bir işin olursa, bu değişikliklerin bunun bir parçası olduğundan emin ol. Tahminler veriyorsanız, yeniden değerlendirme için tahmininize% 30 eklediğinizden emin olun, tahminler yapmıyorsanız, yeniden düzenlemeyi çalışmanızın bir parçası olarak yapın.

Seni yavaşlatabilir - peki hayır, ona bakmanın yolu değil, bakmanın yolu şu anki hızının bir yanılsama olduğudur, esas olarak zincirden geçerken yalan söylüyorsun, aslında Yapmanız gereken bu çalışma nedeniyle biraz daha yavaş.

Temel olarak beton kullanmasaydınız, muhtemelen daha hızlı evler inşa edebilirsiniz - ve müşteriye iyi gelirlerdi - - Peki - Müşteri vakfa ihtiyaç duymasa bile, inşaatçı ihtiyacı olmak. (Bu aslında ilginç bir paraleldir çünkü inşaatçılar her zaman yapmaları gerekeni bilmezler, bu yüzden onları zorlamak için yasaları geçmemiz gerekir - aynı şekilde karşı karşıya kalmamıza rağmen yazılım geliştirmeyi düzenleyen böyle bir yasa yoktur. kararlar alır ve sıklıkla yanlış olanları yapar ...)

Yönetici ve CEO'nuzun her ikisinin de programcı olması için yeterince şanslı olduğunuzu belirtiyorsunuz. O zaman muhtemelen do teknik borcu ne olduğunu anlamak.

Sen gerçek bir olasılık var demektir gerçeklere dayalı durumu çözmek için deneyerek durumu idare etmelidir olmaz (gerçekler can sıkıcı buna neden olabilir) istediğiniz teknik iyileştirmeler yapmak sonunda.

İşiniz, maruz kaldığınız herhangi bir teknik borcu ödemenin maliyetini ve avantajlarını anlamalarını sağlamaktır. Görevleri, kaynakların en iyi şekilde kullanılmasının, ödeme yapmak mı yoksa başka bir şey yapmak mı olduğuna karar vermektir.

Tıpkı "gizli" olayları iyileştirmenin faydalarını görmek için kodla ilgisi olmayan insanlar için zor olabileceğinden, programcılar için işletmelerin alanlarına bir miktar tahakkuk ettiklerinde görünür kod değişikliklerinin yararlarını görmek zor olabilir " geliştiricilerden gizlendi.

Eğer yönetiminiz size, görünen özelliklerin neden teknik borcu ödemekten daha değerli olduğunu açıklayabiliyorsa hoş bir şey, ama gerçekten de, bu seçimi yapmak sizin işiniz değil. Bu yüzden size açıklamak, sizi mutlu etmek dışında, iş için pek bir şey yapmaz. Ve bir şekilde, bunu yapmaları konusunda ısrar ediyorlar, işlerini yapmalarına güvenmiyorlar. Sizi mikro-yönetmeleri sırasında sevmiyorsanız, o zaman anlamanız gerekir.

Bu yüzden, onları tüm teknik borçların durumundan ve onu ödemeye karşı görmezden gelmenin maliyet ve faydalarından haberdar ettiğiniz sürece, işinizi yaptınız. Gerçekten de onların yönetimini yapmak için yönetime güvenmiyorsanız, bu durumda ele alınması gereken başka bir soru olacak çok daha büyük bir probleminiz var.

Belki bu bir cevap değil, yaptığım hatalara dayanan bir cevap. Ayrıca burada okuduğum felsefelerin bazılarına katılmıyorum.

• Programcının en iyi bildiği inancına uymayın.
• Dürüst ol. İlerledikçe yeniden düşünün, ancak yalan söyleme ve tahminlerinizi kendi amaçlarınız için desteklemeyin.
• Kodun sen değilsin. Lider tarafından onaylanmayan bir iş yapmayın.
• Bir konuda haklı olabilirsin; Yanılıyor olabilirsin ... ama yapman gereken parayı yapmalısın.

Ama kesinlikle şeyleri geliştirmek için verilen mükemmel tavsiyelere uyun.

Belli ki sivri saçlı bir patron (PHB) için çalışıyorsun. Artık programlamıyor, eğer öyleyse ve eğer yaptıysa, muhtemelen hiç de iyi değildi (her ne kadar "doğruluk" ve "segmentasyon hatası" gibi ifadeler atmak istemesine rağmen, çocuklar kendi çizgilerini kazandıklarını bilsinler. ) - işte bu yüzden yönetim için seçildi.

PHB teslim çünkü (pratikte bir Mohawk vardır) CEO'su PHB sever özellikleri . Gururla yaptığı her sprint, yeni bir onay kutusunu (biraz yanlış hizalanmış, belirsiz bir etiketle), ışıltılı bir ikonu (henüz herhangi bir ortamda çalışmayan ancak Citrix'e göre 8 bit renkte olan) ve bir formda (yarış koşulları nedeniyle rastgele çarpışan) gösteriyor. ısmarlama xml değişkenine dayalı C, yerel ekipleri dev ekipte kimsenin dokunmaya cesaret edemediği yerel veritabanını uyguladı çünkü 10 yıl önce eski gardiyan dev efsanelerinden biri tarafından yazılmıştı ve 5 harfli veya 5 harfe ihtiyaç duyup duymadıklarını her şeyi 5 harfli isimle yazdı. değil).

Aslında "iş bitini" yapan programcılar (beyaz tahtalar üzerine daireler çizme, bağırarak ve minyatür Battenburg'lar yeme gibi tüm gerçek işlerden sonra uygunsuz bir durum olduğunu biliyorsunuz) aklı başında bir sistemde yeni yapılan işleri biliyorlar Zahmetsizce ormandan ayrılmadan 10 gün geçiren 10 adam, test de dahil olmak üzere muhtemelen bir veya iki adam günü tutar. Ancak sistemi aklı başında tutmak için 6 ay boyunca gerçekten çok ağır bir çalışma gerekebilir, bunun dışında bariz bir dış ödülün olması çok az.

PHB, 6 ay içinde, kanca ya da sahtekar tarafından, otuz ya da kırk yeni özelliğe sahip olduğunu, satışçıların (sattıkları ürüne verilen büyücüler olması gereken), yeni alımları ve yükseltmeleri özendirmek için kullanılabileceğini biliyor. .

Bununla birlikte, PHB'ye aidatlarını vermek için: bu onay kutuları ve satışlar olmadan satışlar durgunlaşabilir veya düşebilir, bir rakip pazar payı kazanabilir ve bu alternatiften daha kötü olabilir.

Çıktığım sonuç, bataklıktan çıkmanın tek yolunun, yeni bir başlangıçta çalışmak, yazılımın nasıl yapılması gerektiği konusundaki görüşünüzü paylaşan ve daha sonra bu felsefeye sıkı sıkıya bağlı kaldığım birkaç kişiyle birlikte olmak. hala oraya ulaşmak için çalışıyorum!)

Başka cevaplarda belirtilmeyen başka bir gizli maliyet var. Yani, iyi mühendisler tarif edilen ortam türünden ayrılma eğilimindedir. Sonunda refactor tutkusu veya yeteneği olan herkes şirketi terk etti ve sonra işler muhtemelen kötü bir şekilde, muhtemelen düzeltilemez olacak. Maalesef yöneticinize bunu kibirli ("En iyi programcılarından biriyim") ve zorlayıcı bir pislikle karşılaşmadan ("İstediğimi yapmazsanız gideceğim") olmadan söyleyemezsiniz. Bununla birlikte, yeniden işe alma statüsü almadığınızdan emin olmak için çıkış görüşmenizde belirtmeyi unutmayın.

Hem haklısın, hem de yanlışsın, bu yüzden uzun zamandır bu sorunlar birbirine karışıyor ve sert duygular yaratıyor.

Yukarıda açıkça belirtilme nedenleri: yönetim parayı düşünüyor; veya daha özel olarak: gelir. Onlara maliyeti olan ancak doğrudan müşteriye görünmeyen bir şey gelir getirmez, bu yüzden kötü bir plandır.

Vizyonunuz da doğru: müşteriler için ancak uzun vadede iyi olacak. İşlemleriniz, kısa vadeli planlara kıyasla gelecekte daha da büyük bir gelir yaratabilir.

Yönetici değilsiniz, doğrudan gelirden sorumlu olan siz değilsiniz (elbette sanırım). Demek sorunlarınla ​​karsıştın (yönetimi böyle hissettiriyor) ve işine odaklanmıyorsun: yazılımı daha da genişletmek.

Tüm zor, net kelimeler ama iletişim hatalarından en çok çıkan sorun budur. İkiniz de aynı şeyi istiyorsunuz, ancak kısa vadeli kararlarınız farklı bir şekilde veriliyor. Çünkü geliştirici yöneticiye kıyasla farklı bir görünüme sahip.

Bu sorunu nasıl çözersiniz? Bir dizi konuda birbirleriyle iyi iletişim kurar ve anlarsınız. Bu, büyük olasılıkla müşteri katılımı ve memnuniyetine odaklanacaktır.

Bu konuyu kararlı ve gelecekteki bir kanıtlama yönteminde çözmek için bir konuda anlaşın: eski kodda hata düzeltme maliyetini ölçün. Eski yazılımla çalışmak için ek süreleri ve yeni kod tabanında bunun nasıl olacağını ölçün.

Bunu kanıtlamak için, örneğin, bu oldukça basit bir şey yapabilir: yazılımı sürümünüze dallayın. İlk önce yönetimin istediğini yapın, bu yüzden bu özelliği oluşturun. Bunu yapıyorsun ama anlaşma farklı yolu gösterme zamanı. Sonra aynı şeyi yeni branşta da yapın, ancak önce kurtulmak istediğiniz sorunları düzeltin. Sonra da çözümü geliştirin.

Artık aynı çözüme sahipsiniz ancak tamamen farklı şekilde geliştirildi. Ondan bir vaka oluşturun, kararlılık, gereken kod miktarı ve kodun kendisi gibi bazı yönetim bilgileri de dahil olmak üzere çözümleri yan yana yerleştirin.

Şimdi birlikte bir kahve alın ve bir göz atmaya başlayın, kimin doğru olduğunu tartışarak değil, her iki yönün de şirket için etkisi ne olacaktır. Bu, gerçekten yararlı olan ve daha da kötüsü olmayan bir tartışma yaratacak, çünkü ikinizin de ihtiyaç duyduğu atmosferi oluşturmayacak. Bu, ürününüzü daha iyi hale getirmez.

Bir kod incelemeniz varsa, ARC kullanılarak kodun iyileştirilmesi gerektiğini belirten bir teknik bilet oluşturun ve yöneticiye atayın.

Onu ikna et. Yaptığınız benzer teknik geliştirmelerin bazı küçük örneklerini ve projelere faydalarını açıklayın.

Bu değişiklikleri, yönetimin satın almaya istekli olduğu şekilde satmak zorundasınız:

Kullanıcıya yönelik bir özellik bulun, böylece yönetimin sadece sahip olması gereken, ancak kodda bazı alt düzey iyileştirmeler yapmadan yapmak imkansız olurdu.

Müşterilerin katma değer olarak algıladıklarını sağlamaya odaklandığından emin olmak şirketin patronu. Bu algıyı değiştirebilecek iki faktör var:

1. Bir müşteri isteğinde bulunmak ne kadar sürer?
2. Ne zaman söyleyeceğini söyler misin?

Birçoğu, 6 hafta alacağını ve 5’te teslim edeceğini, 3’te teslim edeceğinizi ancak 4 alacağınızı söylemenizi tercih eder.

Yönetilmesi ve geliştirilmesi kolay bir güncel kod tabanına sahip olmak, daha hızlı teslimat yapmanızı ve öngörülebilirliği artırmanızı sağlar. Hata düzeltmeleri için çok fazla zaman harcıyorsanız, yeni özellikler eklemek için daha az kaynağınız var. Kodu düzeltmek için harcanan kaynakların miktarını ve özellik vaatlerinde ne kadar doğru olduğunuzu değerlendirin. Şu anki kodunuzun (patronunuzun felsefesi uyarınca) çok pahalı olup olmadığını belirlemenin bu yolu.

Size yönetim ataletinden dolayı neredeyse elimizden geçen 2 milyar dolarlık bir fırsattan bahsedeyim.

Bazılarımızın, müşterinin sesini dinleme, istediğini anlama anlamına gelen bir anlamı var. Her zaman istediği şey değil, ancak müşterinizle konuşacak bir konumdaysanız, sonunda ne istediğini karşılıklı olarak anlayacaksınız. (O zaman açıkça sormaya başlayabilir.)

Olduğu söyleniyor, müşteri ile bu konuşmayı kimin yapması gerektiğini anlamak önemlidir. Genelde iş geliştirme uzmanlarınızla birlikte bunu yapan bazı tasarımcıların yanındasınız. Herhangi bir rekabetiniz varsa, müşterinin onlarla bu sohbeti yapmasını bekleyebilirsiniz.

Aynı zamanda, geliştiricilerin kendi alanlarında güncel tutmaları önemlidir, çünkü değilseniz, sizi yenecek bir rekabet olacaktır.

Bizim durumumuzda eski bir teknolojiye dayanan mevcut bir müşterimiz ve biraz da etkili bir ürünümüz vardı ve müşterinin hızlı bir şekilde iyileştirilmesi gerekiyordu. Gerçekte ihtiyaç duydukları şey tam bir ikame üründü, ancak şirketimizdeki zihniyet, bunun bizi hemen rekabet edebilir bir pozisyona getirmesiydi; oysa mevcut ürünü değiştirmek, müşterinin yasal olarak rekabet edebilmek zorunda kalmadan bizimle devam etmesini sağladı. Yönetimimiz bu pazarın sahibi olduklarını düşünüyordu. Sorun, mevcut ürün yapısının yükseltme yapmak için yeterince esnek olmadığından yükseltme taleplerine yetişememesiydi.

Müşteri sabırsızlandı ve rakip kaynaklarla konuşmaya başladı. O pazarın "sahipliğini" ve birkaç milyar dolarlık geliri kaybettik. Bununla birlikte, piyasa bizi rekabetçi bir pozisyona zorladığında, yönetimin işsiz kalmaktan veya rekabet etmekten başka seçeneği yoktu. (Sonunda barikat olanların çoğu kovuldu.) Rekabet ettik ve en ince iş parçacığıyla işi yeniden ele geçirdik.

Başta bu fırsatın neredeyse elimizden geçtiğini söyledim. Bahsettiğim gelir için işi geri aldık. Müşterinin kaygılarına başlangıçta daha fazla adapte olmak için daha hazırlıklı olsaydık, gerçek bir rekabet olmazdı.

Sunduğum paket servis şudur: Her zaman kişisel yeteneklerinde üstünlük sağlamaya çalış. Her zaman esnek ve müşterinizin ihtiyaç duyduğu şeye hızla adapte olabilen bir ürün geliştirin. Böyle düşünmeyen bir şirket için çok uzun süre çalışırsanız, kalkarsınız ve kişisel motivasyonunuz düşer. Bunun olduğunu gördüm.

Herhangi bir nedenle ürününüzü geliştirme fikriniz olduğunda, kendinize şu soruları sorun: - Müşterinin istediği şey bu mu? Ürün geliştirme hakkındaki düşüncelerimi müşterinin sesine karşı doğrulayabilir miyim? Şirketim müşteri ihtiyaçlarını karşılayacak konumda mı? Öyleyse nasıl? - O zaman ürün geliştirme tekliflerinizle ilgili ikna edici bir durum yaratacak durumda olmalısınız.

Tüm alanlarda ve sektörlerde ortak iş dili paradır. Tarif ettiğiniz problem bir programlama problemi değil: bir iş problemi. Bir iş teklifine uygun bir yanıt almak istiyorsanız, bunu iş dilinde çerçevelemeniz gerekir. Bu, tüm maliyet ve faydaları içeren alternatif bir proje planı sunabilmeniz gerektiği anlamına gelir.

Fırsat maliyetleri, yatırım getirisi (yatırım getirisi) ve NPV (net bugünkü değer) gibi şeyleri öğrenmeniz gerekir. Bunu yapmak için bir MBA'e ihtiyacınız yok, ancak işgücü maliyetleri, genel giderler ve gelir potansiyeli gibi sizin için mevcut olmayabilecek verilere erişmeniz gerekiyor. Bir yolun sabit sayıları kullanarak diğerinden daha fazla değer sağlayacağı konusunda net bir argüman yapabilirseniz, yönetimden tüm dikkatinizi alacaksınız.

Çok küçük bir ekipte yeni bir geliştiriciyken, boş zamanlarımda bu tür iyileştirmeler yaptım. Ben zevk aldım; Geceleri karımla birlikte oturma odasında otururken oturum açıp ilginç yeni teknikler denerdim. Daha üst düzey bir geliştirici ve daha büyük bir ekibin yöneticisi olacağım için boş zamanlarım kayboldu. Sadece özellikleri ve kritik düzeltmeleri yapmak için ekstra saatler çalışıyorduk. Ne kadar önemli olduğunu bilmemize rağmen, birinin zamanını bu düzenli temizlik işine harcamak gerekçelendirmek gerçekten zor oldu.

Patronlarınızın bakım maliyetlerini düşürmek, gelecekteki büyümenin maliyetini düşürmek, yetenekli bir geliştirme ekibini meşgul etmek, vb. İçin ne kadar önemli olduğunu açıklamalarına gerek yok. Varsa, büyük sorunlarınız var. Ancak ihtiyaç duyabilecekleri bir plan. Çünkü şu an, geliştirici ekibinden sadece arzulu düşüncelere ve açık uçlu taleplere karşı mücadele eden "işlevsellik ekle" tarafında her türlü plan, program, yol haritası, vaat ve baskıya sahip olduklarını tahmin ediyorum.

Deneyebileceğiniz bir şey belgelenmiş bir plan yapmak. Yeni işlevler için sürümlere bağlayabilir veya kriterlerden çıkıp çıkamayacağınıza bakın. "Referans sayımını yeniden yapmak için biraz zaman harcamak" isteği, patronunuzun onaylaması zor olabilir, ancak bundan 4 hafta sonra 5 günlük bir zaman çizelgesi planlamak daha kolay olabilir. Temel olarak, yeni özelliklerin planlandığını ve planlandığını, taklit etmeye çalıştığını veya içine “başlık altı” kısmını enjekte etmeye çalıştığını görüyorsunuz.

Bu tür şeylere ayrılan% 5 zaman isteyerek küçükten başlayın ve ardından yavaş yavaş kendi teknoloji yol haritası önceliklerini oluşturun ve her biri için iş vakasını, yatırım getirisini, risk düzeylerini vb. Haklı göstermekten çekinmeyin. Yakında, patronların zorluklarının tadına bile bakacaksın, çünkü vaktinden çok daha fazla harika fikir bulacaksın.

İyi şanslar!

İşte bu yüzden otomatik referans sayma isteğiniz reddedildi:

1. Bu bir gelişme değil . Merhaba dünyadan daha büyük bir şeyiniz olduğunda, herhangi bir değişiklik yanlış yöne gidecektir. Yeniden yapılanma miktarının hiçbiri, değişiklik yapmanız gerekirse, her zaman yanlış yöne gideceği gerçeğini değiştirmez. İşin püf noktası, yaptığınız değişikliklerin yeterince önemli olduğunu bilmek, bunun hala yeni sorunlara neden olma riskine değdiğini bilmek. Yönetiminiz, son kullanıcılar göremezse riske değmeyeceğini açıkça belirtti.
2. Referans sayımı tamamen çılgın bir özelliktir. Bazı büyük ünlü firmaların bazı özellikler uyguladığını gördünüz ve hemen aynı özelliğe ihtiyacınız olduğunu düşündünüz. Pekala, büyük olasılıkla kod tabanınız, elmanın kullandıklarından tamamen farklı. Muhtemelen referans sayımı işe yaramayacak ya da sadece zaman kaybı. Kodunuzun her yerine referans sayma ilkellerinin yayılmasını gerektirmeyen farklı bir yol bulmalısınız. Muhtemelen tazminat planınız kod tabanında binlerce değişiklik gerektiriyor, bu değişikliklerin çoğu gerekli değil. Sadece zaman ve para kaybı.
3. Yanlış sorunu çözüyorsun. Yönetim genellikle sistemde ne tür problemler olduğunu bilir. Bazı ilgisiz bellek sızıntısı sorunu yeniden hesaplama çözümünün çözdüğü sorunlardan biri değil. Bilgisayarların belleği kullanma biçimiyle ilgili bazı hayali sorunlara değil, gerçek sorunlara odaklanın.
4. Uygulaması çok uzun sürüyor Apple, az sayıda programcı ve bazı yöneticileri olan önemsiz ekibinizden biraz daha büyük bir şirkettir. Sadece bedel ödeyerek büyük değişiklikler yapabilirler. Bir şeyi uygulamak birkaç milyon alırsa, yerfıstığı olur. Küçük şirketler aynı şeyi yapmaya çalışırsa, hızlı para tükenecek. Yazılım geliştirme zaten çok pahalı; gereksiz maliyetler eklemek bir bit yardımcı olmayacak. Bellek yönetimi gibi alakasız bir özellik, taşkın kapılarını açacak: onayladıktan sonra programcılarınızın yarısı kendi "iyileştirmelerinin" uygulanmasını istiyor. Bu bitmeyen bir hikaye ve şirket bunun yerine yararlı bir şeyler yapıyor olabilir.

Sorunu ele almak için kullanabileceğiniz bazı adımlar:

1. Özelliği bırak
2. Asıl sorunun ne olduğunu bulun
3. Yararlı bir şeyler yapmaya başla
4. Vaktinizi nasıl kullanacağınızı dikkatlice planlayın
5. Gelişmelerinizin nasıl para kazandırdığını öğrenin
6. Yalnızca en çok para getiren özellikleri seçin
7. Yazılım geliştirmenin programlama yönünün tüm sistemin sadece küçük bir parçası olduğunun farkına varın - geliştirmeler zamana değmeyecek