Yöneticiler programlama dilini nasıl seçiyor?

Bu, yöneticilerin bir proje için kullanılacak programlama dilini uygulayabilecekleri ve sık sık uygulayacakları için bir sır değildir.

Kendim bir programcı olarak, bunu asla anlayamadım.

Ama şimdi düşünüyorum: Sanırım Joel Spolsky podcast'te QuickBooks kullanmaları gerektiğini çünkü “dünyadaki her muhasebeci bunu biliyor” demişti. Bu beni "Java'yı seçti çünkü dünyadaki her programcı bunu biliyor" ile çok benzerdi.

Şimdi aynı konuyu başka bir perspektiften gördüm, muhasebe konusunda pek bir şey bilmiyorum ama programlama hakkında bir şeyler biliyorum, bir programcının bir proje için doğru programlama dilinin seçildiğinden emin olmak için nasıl yardımcı olabileceğini merak ediyorum. ?

Pek çok programcının yaptığı hata, sadece teknik esaslara dayanarak, (ya da sadece buna katılıyorum ya da katılmıyorum) konusunu tartışacaklarıdır. Yönetim - ve bir bütün olarak iş - iş vakasını ve önce işin yararlarını, ikincisi de teknik yararları belirtmelisiniz.

Bu, programlama dili seçiminin ötesine geçer ve hemen hemen her teknik karara yayılır.

Size bir örnek vereyim: PC'ler. Joel, geliştiricilerin zamanının pahalı olması nedeniyle geliştiricilerin üst çentik makinelerine sahip olması gerektiğini (doğru) iddia ediyor. Bu tamamen haklı. Ama bunu nasıl tartışıyorsun? Basit:

Örnek: Günde 20 defa bir kod oluşturuyorum. Her seferinde 3 dakika sürer. Hızlı bir bilgisayarım olsaydı 1,5 dakika içinde kurabilirdim. Bu yüzden her iki yılda bir 1000 dolar daha fazla, günde bir yarım saat daha fazla alabilirim, bu da bir programcı için 100 bin dolar kazanıyor (en az% 50 başka bir maliyetle), bu da yıllık ortalama 10,000 dolara denk geliyor.

Ancak diğer tarafta tartışmak, İK'nın bir boyutun politika ve PC'ler söz konusu olduğunda herkese uyduğuna karar vermesi, böylece bir çağrı merkezi çalışanı 25 bin dolar kazanıyor ve dört kez de kazanan bir programcı aynı bilgisayarda olması gerekiyor.

Teknoloji platformu ve diller karar karışımına giren birçok faktöre sahip olacak:

• Belirli satıcılarla stratejik ilişki. Şirketiniz bir Microsoft Gold Ortağıysa (veya şimdi ne denirse), Java veya Python'a girmenizde iyi şanslar;
• Bilişim departmanı belirli bir konfigürasyonu savundu çünkü PC'ler için para bütçeden çıktı;
• Herkesin Windows 2000 çalıştırması gerektiğine karar veren BT, Linux çalıştıran insanlar olmadığından;
• Şirketin halihazırda sahip olduğu diğer sistemler (örneğin, Java'yı her şey için kullanıyorlarsa, bunu kendi başına kullanmak en uygun seçenek olmasa da, bunun için anlam ifade eder);
• Farklı platformlara veya dillere, deneyim eksikliğinden riskten kaçınma;
• Geliştiricileri mutlu etmektense, üst yönetimle risk tartışmaya daha fazla ilgi göstermek;
• Bazı yöneticiler aldıkları kararları basitçe çünkü elleri bağlı;
• Bütçeyle ilgili nedenler, sizin lehinize çalışsa da, PVCS gibi pahalı booster gözlüklerini, Rational tarafından üretilen herhangi bir şey, vb;
• Kaynak lisansları açmak için yasal departmandan kaçınma;
• Teknik personelin planlama ve proje tahminine dahil edilmemesi;
• Yöneticinin belirli bir platforma aşinallığı (teknik insanlar da bundan suçludur, ancak her iki durumda da mutlaka kötü bir şey değil - işi bildiğiniz şeytanı daha iyi yapabilen birçok araçla).
• Teknik personelin tecrübesi. Hepsi bir C # arka planından geliyorsa, neden Java, Python veya Ruby kullanıyorlar?
• Diğer birçok neden

Sebepini anlamak için neye ihtiyacınız varsa (ve sizi temin ederim ki birkaç nedeniniz olacak) ve bu terimlerin haklarını iddia edin. Bazı programcılar bu bölümde oldukça saf ve bu tür kararların neredeyse her zaman birçok faktör oyunda olduğu zaman cehaletten ve hatta hakaretten verildiğini düşünüyor gibi görünüyor.

Şirketimde göründüklerimden: Yöneticiler bir programlama dili seçtiğinde, genellikle bunu çok muhafazakar bir şekilde yaparlar - ekipte şu anda ne tür bir programlama becerisinin mevcut olduğunu göz önünde bulundurarak (ve kolayca başkalarını işe almanın kolay olup olmayacağını dikkate alarak) ), iyi kurulmuş bir dil olup olmadığı, mevcut altyapıya uyacak bir şey seçmeye çalışılması ve halihazırdaki şeye sığdırmak için büyük çabalara neden olmaması. Programcılar bir programlama dilini seçtiklerinde, işler genellikle biraz farklı olma eğilimindedir - genellikle yeni bir meydan okuma almak ister ve en son sıcak trendle karşılaşmak ve yeni şeyler öğrenebilecekleri bir şey seçmek isterler.

İdeal olarak, her şey yöneticiyle dev ekip arasındaki artıları ve eksileri tartışmak ve soruna en iyi uyan çözümü bulmaktan ibarettir. Bu genellikle çok fazla konuşmayı ve ikna etmeyi gerektirir :-)

Geç cevap, ama henüz kabul edilmiş bir cevap olmadığından, bir deneyeceğim. Bunu iki soru olarak alıyorum ve bunları ayrı ayrı cevaplamaya çalışacağım:

Yöneticiler programlama dilini nasıl seçer?

Büyük ölçüde kuruluşun büyüklüğüne ve yöneticinin deneyimine bağlıdır, ancak genel olarak mevcut durum ile gelecekteki senaryoları ve gereksinimleri değerlendirmeyi içerecektir. Bu genellikle PESTLE veya benzer bir analizle yapılır ve sadece her kategoride birkaç örnek vermek için:

• siyasi
  • "Kimse IBM'i satın aldığı için kovulmadı" - güvenli seçim.
  • CEO, Java'nın havalı olduğunu söyledi.
  • Baş mimarı .NET - evcil hayvan projesini çok seviyor.
  • Dil düşmanca bir rakip tarafından kontrol ediliyor - Google neden C # 'a güvenmiyor?
• Ekonomik
  • Lisans maliyetleri.
  • Geliştirici eğitimi maliyeti.
  • Kod bazında geçiş maliyetleri.
• Sosyal
  • Takımdan katılım.
  • Evde beceri mevcudiyeti (eğitim ihtiyaçları, süreklilik).
  • Piyasadaki beceri kullanılabilirliği.
  • Geliştirme ekibindeki mevcut statükoya tehdit.
  • Yeterince geniş uygulama topluluğunun mevcudiyeti.
• Teknolojik
  • Üretimin geliştirilmesi.
  • Kalite iyileştirme.
  • Mevcut kod tabanı ile birlikte çalışabilme.
  • Standartlara bağlılık.
  • Olgunluk.
• Yasal
  • Lisans şartları
  • Teknoloji kontrolü (Teknolojinin sahibi kim ve kontrol ediyor? Gelecekteki lisanslama stratejisi ne olabilir?)
  • Yasal ve yasal uygunluk.
• çevre
  • Şirket içinde mevcut altyapı.
  • Şirket içi mevcut beceriler.
  • Dış ortaklarla entegrasyon.
  • Daha geniş bir çevre tarafından teknoloji desteği seviyesi.

Ardından kritere uyan bir dizi dil SWOT , maliyet fayda analizi veya benzeri kullanılarak daha fazla değerlendirilebilir .

Tüm süreç oldukça karmaşık olabilir, ancak sonuçta çoğu şirket veya proje ekibi, ihtiyaç duydukları yetenekleri yerine getirebilecek mevcut durumları göz önüne alındığında en güvenli seçeneğe gidecektir. Çoğu zaman mevcut platforma daha uzun süre yapışması anlamına gelebilir.

Bir programcı, bir proje için doğru programlama dilinin seçilmesini sağlamaya nasıl yardımcı olabilir?

Daha önce de belirtildiği gibi, tipik bir programcının normalde karar verme sürecindeki toplam girdilerin yalnızca 1 / 6'sına sahip olacağını göstermiştir. Ve bir kural olarak, çoğunlukla sadece dil yetenekleriyle ilgilenir!

Kararı etkilemenin en iyi yolu, seçim sürecinin daha geniş bir resmine sahip olmak, takımın içinde ve dışında müttefikleri oluşturmak, olayların teknolojik tarafında iyi bir özet oluşturmak ve sadece dil becerilerine odaklanmamaya çalışmak gibi görünüyor.

Ve elbette, bir Proje veya Geliştirme Müdürü (veya başkasının sorumlusu) tüm değerlendirme sürecinden geçmenin faydalarını gördüğünde ve farklı bir kuruluşa geçmenin risklerini ve belirsizliklerini dikkate almaya hazır olduğunda pozisyona girmesi gerekir. ilk etapta dil. Bunun olması için gösterilmesi gereken:

1. Mevcut platform artık yeterli değil.
2. Yeni bir platform, güçlükten daha ağır basan faydalar vaat ediyor.

Ancak, "işte sevdiğim dili kullanabilmenin en iyi yolu nedir" diye sormuş olsaydınız, yanıt muhtemelen "zaten dili kullanan bir şirkete katılmak ya da kendi dilinizi başlatmak" olurdu.

Müdür A, Müdür B ile buluştuğu yaz tatiline gider.

C: Peki şirketinizde hangi dili kullanıyorsunuz? B: Oh, CA Visual Objects kullanıyoruz, bu insansız uçakları COBOL'den çok daha üretken yapıyor.

Ve bu nasıl karar verildi. Gerçek hikayenin sonu.

Her platformun iyi ve kötü tarafları vardır. .NET, serin ve güçlü ama hemen hemen Windows sunucuları ile sıkışmış. Ruby havalı ama yavaş. Haskell için geliştiriciler bulmak zor olurdu.

Mesele şu ki, dil projenin ne kadar hızlı yapıldığını ve ne kadar güzel kodun olacağını değil aynı zamanda yöneticilerin de önem verdiği şeyleri etkiliyor. Bu yüzden, onları etkilemek istiyorsanız, şimdi tercihlerini yapmalı ve perspektiflerinde mümkün olduğunca iyi tarafları bulmalısınız.

Endişeleri ayırarak. İşletme, işletme kararlarından ve teknoloji kararlarından sorumlu olan teknolojiden sorumlu olmalıdır. "Kabul edilmiş sorumluluk" terimini seviyorum. Sorumluluğu kabul edersem, sorun alanımı ilgilendiren seçimler yapmamı da isterim. İş bana ve teknik meslektaşlarımın talep ettiği işlere cevap veriyor ve teslim etme sorumluluğunu nasıl kabul edebileceğimizin bir veya iki alternatifini yanıtlıyoruz. Asla "Python veya C # ile yapacağız" gibi olmamalı. Daha doğrusu;

“Burada iki farklı sorumluluğu kabul edebiliriz: Bu şekilde gidersek, bunu hızlı bir şekilde verebiliriz ve bu iş taleplerini gerçekten çok iyi karşılıyoruz ve bunlar biraz daha zor. Biz de bu şekilde yapabiliriz ve bu da iş kolunu talep ediyor. Alternatif A, bu kaynakları arar ve alternatif B de bunu ve bunu yapmamız gerektiği anlamına gelir ... "

Daha sonra iş seçer, ancak işin teknik meseleler üzerine değil, iş meseleleri üzerindeki etkisine dayanarak seçtiğine dikkat edin. Ve teknolojinin teknoloji kısmının sorumluluğunu kabul etmeye hazır olmadığı alternatifler arasından seçim yapamazlar.

Yönetici ol. (sırıtış)

Cidden, konuyu söz konusu karar vericiyle görüşmeniz ve argümanlarınızı ortaya koymanız yeterlidir. Gerçekten yanlış bir karar vermeyi tercih ediyorlarsa , genel yetenekleri muhtemelen çok sıcak değildir ve yapacak başka bir şey aramaya değebilir.

Sanırım neden bahsettiğinizle Joel’in bahsettiği şey arasındaki fark, programlama değil, muhasebe meselesi değil. Quickbook'ları kullanan nokta, muhtemelen, çünkü siz değilsiniz. bir muhasebeci için ve muhasebeciler bu konuda size yardımcı olabilir. Ancak, eğer programlama sizin temel yetkinliğiniz ise ve muhtemelen bir programcıysanız, o zaman oyunun kuralları biraz farklıdır.

Bu büyük ölçüde yöneticinin kişiliğine bağlıdır:

Buzzwords için gidiyor olanlar var. Sadece hangi buzzwords'leri beğendiğini öğrenin ve kullanmak istediğiniz dile bağlı olarak onunla konuştuğunuzda kullanın.

Diğerleri yalnızca kendileri bildikleri şeylere güvenecektir (örneğin VB 6.0 gibi). Seçim dilinizi onlar için anlaşılması kolay hale getirin ('bilirsin, tıpkı eski VB'de olduğu gibi' - Haskell hakkında konuşsanız bile ...)

Ancak gerçekte, çoğu yönetici merak ettiğimiz kadar meraklı olduğumuz kadar aptal değildir ve gerekçeli olabilir. Burada önemli olan, onların bakış açısını anlamanızdır: Genellikle belirli teknik ayrıntıları önemsemezler, sonuçları önemserler. Bu yüzden onlara .net veya Java veya Delphi'yi veya bu megacool'un müthiş özelliğine sahip olduğunu söyleme. Onlara (buraya dilinizi girin) iyi bir seçim olduğunu söyleyin , çünkü A özelliği , bunun gibi bir projede veya B özelliğinde daha kısa geliştirme süreleri sağlar. daha az hata için yapar ve bu nedenle test için gereken süreyi kısaltır. Sadece argümanının sağlam olduğundan emin ol, ona yalan söyleme.

Başka bir deyişle: Ona zeki bir varlık gibi davran (muhtemelen öyle).

Çok zor kullanmanız istenen dili düşünün. Bunun iş için iyi bir dil olmadığını bildiğinizden emin olun, daha sonra yöneticiye, iş için kullanmak üzere daha iyi bir dil önermek isteyip istemediğinizi sorun. Dilin iş için iyi olmayacağını kanıtlayan herhangi bir bilgi verin ve ne dediğini görün. Acıtamaz. :)

Programlama dilini seçmek genellikle bir iş kararıdır. Müşteriler / Kullanıcılar umursamıyor. İşte kısa alıntı ( http://www.ericsink.com/bos/Geeks_Rule.html adresinden ):

Programlama dilleri esas olarak ticari nedenlerden dolayı seçilir. Zamanımın çoğunu, gerçekten sevmediğim dillerle çalışarak geçiriyorum çünkü birlikte çalışmak istediğim diller teknik özelliklerinden daha ağır basan dezavantajları taşıyor. Oyunun doğası budur. Durumu (seçimim) kabul edebilir veya yeni bir işveren bulabilirim. Java ya da Python'u nasıl kullanamayacağımı ya da işte ne olursa olsun bir seçenek değil.

Her şeyden önce, programlama başka bir sanat şeklidir. Çok mantıklı bir sanat eseri. Yöneticiniz olağanüstü yazılım projeleri konusunda istekliyse, başyapıtlara ait eserleri genişletmek istiyorsa, o keskin yöneticiden aşağıdakileri isteyin:

Kadar enerji ve zaman o Rembrandt mal olacağını nasıl ekstra değil sevdiği fırça ile boyamak, ancak yönetim ekibinin titizlikle incelenmesinden sonra, kendisine teslim edilir, bu bir fırça, 400 yıl önce ve önceki eserlerinin ünlü olma. Resmini düşündüğünüze az çok değecek mi?

Benzer şekilde, bir programcıya hangi dilin kullanılması gerektiğini söylerseniz, tutarlı olun ve bir ressama hangi fırça boyutlarının kullanılması gerektiğini söyleyin! VEYA alternatif olarak, bu seçimi sadece her gün ve (çoğu şaheser gibi) gecede birlikte çalışması gereken insanlara bırakın!

Bunlar farklı kavramlar.

Muhasebe yaparken, sonuçlarınızı paylaşıyorsunuz: vergiler, hukuk, yatırımcılar vb. İşçinizin sonucunu görmek için bir araca ihtiyaçları var ve bu aracın iyi bilinmesi gerekiyor.

Programlama yaparken .exe, Windows'ta çalıştırabileceğiniz bir dosya çıktığı sürece istediğiniz herhangi bir aracı kullanırsınız . Bu, muhasebe olması durumunda, Hızlı Kitaplar tarafından okunabilir bir belge ile aynıdır.

Eğer bir ekmek kızartma makinesi geliştirirseniz, dahili belgelerinizi Çince olarak saklamakta özgürsünüz, ancak İngilizce el kitabını daha iyi sağlarsınız.

Bir şey daha var: Şirketinizin kuralları, kodunuzun sonucunun bir ürün değil, bunun için bir kaynak kodu olduğunu varsayarsa, o zaman kesin olarak nasıl görüneceklerine karar verebileceklerini söyleyebilirler (istedikleri dili seçerek).

Seçtikleri şey hedeflerine bağlıdır: Kolayca değiştirilebilen programcılar istiyorlarsa Java'yı seçtiler; eğer başka bir bölüme gönderirlerse o bölümün ihtiyacı vb.

Tecrübelerime göre daima buna bağlı

1. Dili kullanmak için kaynaklarımız var mı?
2. Dili korumak için kaynaklarımız var mı?
3. Eğer dili kullanmak ve sürdürmek için gerekli kaynaklara sahip değilsek, bu kaynakları edinmek ne kadar zor / maliyetlidir?
4. Dilin “geleceği” nedir (Etrafta ve bir süre kullanımda olacak mı?)

Proje, yalnızca belirli bir dil / platform / teknoloji / çerçevenin, bildiğimiz ve kullandığımız şeylere dayanarak sağladığı bir şeye ihtiyaç duymadığı sürece. Hem yeni insanlar işe almak hem de mevcut programcıları eğitmek çoğu şirket için oldukça maliyetlidir. İşe alırken dili daima göz önünde bulundurur ve adayların muhtemelen hangi dilleri kullanacaklarını bildiklerinden emin oluruz.

Umarım aynı zamanda yönetici olan ve programcıları bu tür kararlarda temsil edebilecek bir programcınız vardır. Olmazsa, bu tehlikeli bir durumdur ve böyle bir karar verildiğini biliyorsanız yöneticinizle konuşmalısınız.