Daha büyük şirketler genellikle sorun yaşar, personel ve para eksikliğinden dolayı çalışanların istediği tüm programları (zamandan tasarruf etmek ve süreçleri optimize etmek) yazmak mümkün değildir.

Daha sonra (en azından bazıları) kodlama tecrübesi olan (ya da ucuz öğrenciler / stajyerler ...) bazı insanlar tarafından gizli programlar yaratılacaktır. Bazı şartlar altında, bu uygulamalar önem kazanacak ve bir kullanıcıdan bütün birime yayılacaktır.

Öyleyse kritik nokta var: Uygulamayı kim sürdürecek, yeni özellikler ekleyecek, ...? Ve bu uygulama kritik. Bu gerekli. Fakat stajyer şirketten ayrıldı. Kimse nasıl çalıştığını bilmiyor. Sadece bir sürü kaynağa ve bir tür dokümantasyona sahipsiniz.

BT departmanı dışında geçici olarak yapılan uygulama geliştirmeyi denemek veya kontrol etmek ya da yasaklamak mantıklı mıdır (Excel makroları gibi küçük şeyler hariç)?

Onlara verdiğimiz her uygulamanın şu soruyu yönlendirdiği bir şirkette çalışıyordum: Bu verileri Excel'e aktarabilir miyiz?

Bir süre sonra, neden her şey için Excel ihracatına takıntılı olduklarını bilmem gerektiğine karar verdim. Birçok bölümün Excel'de uzman olan ve kısa sürede yararlı bir veri analizi uygulaması yazabilecek bir kişisinin olduğu ortaya çıktı. Bu uygulamalar orman yangını gibi etrafa yayılırdı ve biz teknisyenler bile var olduklarını bilmiyorduk.

Neden önce bize gelmediler? Çünkü teknik ekibin yapacak çok fazla bir ünü vardı ve eğer isterlerse (şanslılarsa) altı ay sonra sıraya girmelerini sağlayabilirlerdi.

Bu haksız bir suçlama değildi ve bizden Excel uygulamalarını desteklememizi asla istemediler, bu yüzden kimse bunun bir sorun olduğunu düşünmedi. Bu Excel geliştiricileri ayrıldığında, onu almak için daima başka birini bulmayı başardılar.

Yanlış öncelik verdiğimizi, önemli işlerin yapılmadığını söyleyebiliriz. Ancak, daha fazla ücret alan geliştiricilerin daha zor çalışmalar yapmasını sağladığını savunuyorum. Ne acıtabilir?

Şimdi ederim veritabanı geliştirme ekibinin dışında yazılıyor günceller yazılımı korusun. Geliştirme ekibinin dışında yazılı uygulamaları desteklemeyi reddederdim. Ancak, tüm yazılımların işletmenin kendisi tarafından yazılmasını yasaklamaya çalışmıyorum ve bunları yapmak için onları güçlendirmek için mutlu bir şekilde veri ihracatı yazacağım. ).

Bence insanlar buradaki genel noktayı kaçırıyorlar:

Devam eden tüm özel gelişmeleri beğenmiyorsanız, bunun yasaklanması, yanlış bir sorunu çözmektir - bunun yerine neden BT'ye girdiklerini sormalısınız, yalnızca onlara izin verilmediğini söylemelisiniz. Unutmayın ki siz (IT) işlerini daha iyi yapmalarına yardımcı olmak için varsınız ve insanların yazılımı kullanmıyorlar çünkü serin, temiz ya da yeni, kullandıkları bir sorunu çözdüğü için kullanıyorlar.

Neden bu uygulamalar ilk etapta oluşturuluyor?

Gördüğüm tüm durumlarda, ortak bir sebep var:

İş grupları, kendi ihtiyaçlarını öncelikli olarak belirlediler, aynı ihtiyaçlar şirket genelinde önceliklendirildi.

Pazarlama sadece pazarlamadan sorumludur, bu nedenle diğer gruplara nazaran kabiliyeti düşünüldüğünde hedeflerine fayda sağlayan girişimler onlar için kritik görünmektedir ve BT gibi sınırlı kaynaklar söz konusu olduğunda daha düşük öncelikli olma eğilimindedir. Önceliklendirme yalnızca paylaşılan bir kaynak kullanmak istediklerinde devreye girer - projeyi tamamen kendi bölümlerinin içinde tutuyorlarsa, yalnızca bölüm başkanının bütçe ve zaman çizelgesi ile ilgilenmesi gerekir.

Bu tür bir gelişmeyi yasaklamam için hiçbir neden yok, sebep dahilinde - paylaşılan kaynaklar (çoğunlukla BT) üzerindeki kısıtlamaları hafifletiyor ve her grubun kendi sorunlarını çözme konusunda kendilerini güçlendirmelerine izin veriyor (ileri Excel'de tecrübeli kişiler oldukça yaygın, bu yaygın bir problem olduğundan, çoğu bölüm en az bir tanesine sahiptir.

Ancak, bu uygulamalardan kaynaklanan sorunları çözmeniz veya orijinal geliştirici firmadan ayrıldıktan sonra bunları desteklemeniz beklenemez. Bir diğerinde de belirtildiği gibi, bu büyük patronun onu desteklemenizi istemesini engellemiyor; ancak, özel uygulamalar veya süreçler konusunda bir fikir edinmeye devam ederseniz, bir şeyin ne zaman kritik hale geldiği konusunda bir fikir edinebilirsiniz. onu "şirket içinde" getirmek için dahil olmak gerekebilir. Ayrıca, BT kontrolü altındaki sistemlere bir şeyler bağlıysa ve bunları değiştiriyorsa, yalnızca merkezi sistemlerinin güvenliğini ve bütünlüğünü sağlamak için, ancak bir kullanıcının masaüstüyle sınırlı bir şeyse, neden ihtiyaç duyulduğunu hissetmek için BT'nin dahil olması gerekir. yasaklamak için?

Ancak hatırlanması gereken bir şey var: BT dışında geliştirilen her özel uygulama, BT tarafından karşılanmayan bir ihtiyaca karşılık geliyor . Karşılanmamalarının iyi bir nedeni olabilir - şirkette bir öncelik değil, çok özel bir sorun, diğer seçenekler kadar iyi değil, BT çalışanlarının bilmediği özel bir dil, vb. - ve BT katılımının olmaması meşru, ancak bu çözümler yaratıldı çünkü bazı departmanlar BT’nin karşılayamadığı (ya da karşılayamayacağı) bir ihtiyaç duyuyordu.

Sorunlarını çözmelerine yardımcı olmaya çalışın ve zamanınız veya kaynaklarınız yoksa bunları kendi başlarına çözmelerine izin verin. Dik bir öğrenme eğrisi olan bazı dilleri zorunlu kılmak, yalnızca insanları işinizden uzak tutmak amacıyla, çoğu işletme kullanıcısının BT'nin sahip olduğunu algıladığı seçkin tutumunu artırmaya hizmet eder ve sonunda bu tür seçkin tutum Kullanıcılar, BT'ye yaklaşmaktan korktukları ve BT'nin ihtiyaçlarını veya isteklerini anlamadıklarına ikna olduklarından, aynı problemin daha fazlası. İlişkiyi açın - neye ihtiyaç duyduklarını anlamak, etrafta dolaşmalarını engellemenin tek yoludur.

Ayrıca, BT departmanının beceriksiz insanlar içerdiği şirketler de dikkate alınmalıdır; gizli uygulama ise, şirket içinde geliştirici olmayan bir işi olan yetenekli bir geliştirici tarafından oluşturulacaktır. Tecrübelerime göre bu vakalar oldukça sık.

Bir yazılım geliştiricisinin ve bir muhasebecinin çift profilli olduğunu hayal edin. Bir muhasebeci olarak işe alındınız, çünkü bu iyi bir iş bulmanız için bir fırsattı. İş arkadaşlarınızın (ve şimdi sizlerin) saatlerce bir program tarafından birkaç saniye içinde yapılabilecek tekrarlanan şeyleri yapmak için harcadıklarını çabucak görürsünüz.

Tüm işi yapacak olan uygulamayı yazmak için birkaç akşam geçirirsiniz. Kişisel dizüstü bilgisayarınızda meslektaşlarınıza gösterin ve çok yararlı buluyorlar. Şirket PC'lerine yüklemek istiyorsunuz, ancak BT departmanının sözleşmesini almalısınız. Sizden isteyin, ancak başvurunuzu desteklemedikleri için reddediyorlar.

Kulağa aptalca gelmiyor mu?

Bu özel durumun yanı sıra, desteğe sahip olan sorun, tüm  yazılımlarla karşılaşan bir çok firmadan , hatta bir BT departmanında yazıldığından bile farklı değildir : IT departmanı en iyi uygulamaları zorlamazsa, kod kötü şekilde / belgelenmemiş olacaktır. bakımı önemsemeyen ve yıllar önce terk etmiş tecrübesiz kişilerce yazılmış.

Sonuç olarak, asıl soru karlılıktır . Sizden, BT departmanından, yazılım geliştirmenin en temel kurallarını anlamayan bir tezgahtar tarafından geliştirilen bir uygulamayı sürdürmeniz istenirse, bu işin ne kadar eğlenceli olduğu önemli değildir, yine de getiriyorsanız yapmanız gerekir. şirkete çok para . Veya işleri halletmenin en ucuz yolu ise, sıfırdan yeniden yazarsınız.

Tam olarak kontrol edemezsin ...

Çalışanların her zaman hileli kod üretmek ve alternatif yollarla yaymak için araçları olacaklarından, TAMAMEN hiçbir zaman kontrol edemeyeceğinizi söyleyebilirim. Bu yüzden, birkaç temel kural ve süreci hazırladıktan ve uyguladıktan ve birkaç araç hazırladıktan sonra, bunun üzerinde çok fazla takıntı kullanmanın pek bir yolu yoktur.

Fikir, insanların hiçbir şey üretmeyen yeni şeyler yapmayı imkansız kılmak yerine, bu kurallara saygı duymaları ve bu araçları kullanmaları için mümkün olduğunca çekici hale getirilmesidir.

Ancak kod dostu bir ortam oluşturabilirsiniz

Çoğu şirket, genellikle çok büyük, bunu yapar. Temsilcilerin tüm şirket için tek bir SCM kullandığını belirttikleri Google’ın iyi bir örneği, herkesin başkalarını izleyebilmesi ve kodlarına bakabilmesi için.

Aşağıdakileri yapmanızı öneririm:

• SCM'nizin bazı alanlarına halka erişim sağlamak,
• Sürekli entegrasyon ve sürekli denetim sunucularına erişimde bulunma talebinde bulunmak,
• İnsanları araçları için inşaat işleri yaratmaya teşvik edin.

Sorun o zaman teknolojilerin yayılması. Açıkçası, bazıları X üzerinde Y'yi kullanmayı tercih edeceklerdir ve o zaman mimarinize uyması zorlaşır. Ancak, imkansız değildir ve eğer kodlarının korunmasını istiyorlarsa, muhtemelen sadece bir mil varsa, ekstra mil alırlar.

Ayrıca daha keyfi bir duruş sergileyebilir ve yalnızca L ve Yığın S diline izin verildiğine karar verebilirsiniz, ancak o zaman burada ve orada bazı haydut şeyler alırsınız, bu yüzden biraz genişletmenizi tavsiye ederim. Bazı CI sistemleri birkaç eklenti ile harikalar yaratacaktır, eğer çalışanlarınız bir miktar yapıştırıcı kod veya bazı yapılandırma komut dosyaları yazmak için istekliyse isteklidir.

Ekiplere biraz özgürlük verin

Bir hevesle ilerlemek ve deneysel şeylerle küçük yeni projeler başlatmak için ekiplere biraz özgürlük vermek önemlidir. Onları ayak parmaklarında tutuyor ve sizler de sizin için sorun çıkana kadar sizi sonsuza kadar bir yığında sıkışmış kalmaya devam etmek yerine bu teknolojileri göz önünde bulundurmaya zorluyor.

Bu nedenle, evcil hayvan projelerini test etmek için kendi sistemlerini kurma becerisine sahip olduklarından emin olun. Ancak, BT ile bu konuda konuşma alışkanlığı edinmelerini sağlayın.

BT ile konuşun, onları dahil edin

Çalışanlarınız BT'ye bir e-posta isteği gönderme refleksini geliştirip, kendileri için bir şeyler ayarlayıp barındırmadıklarını sormalarında daha iyidir. Çoğu zaman geri dönecekler, ancak en azından bir miktar kontrol kavramı var ve kimin sorumlu olması gerekiyor ve BT'ye farklı ekiplerin talepleri hakkında biraz görünürlük sağlıyor.

Projeler daha kritik bir kütle topladığında, tekrar talepte bulunabilirsiniz ve yeniden değerlendirilecektir. İletişim çok önemlidir ve geliştirici ekiplerinden, danışmanlardan, BT destek ekibinden veya birlikte çalışmak için kodla uğraşan herhangi birine sahip olmanız gerekir. Hiçbiri başıboş programlar istemiyor, bu yüzden herkesin ilgisini çekiyor. Kendilerini yedekledikleri takdirde kuralları uygulamak çok daha kolaydır.

Bu "gizli" uygulamaları durduramazsınız çünkü insanlar onları gerçek dünyadaki iş problemlerini çözmelerini sağlar. Yapabileceğiniz tek şey, onları "doğru" şekilde yapmalarına yardımcı olmak. Ve "sağ" derken, uygulamaları başlatan kişi gittikten sonra da sürdürülebilecek şekilde yapmak istedim. Yukarı veya Dışarıda önerilen dili kullanmanızı öneririm : Herhangi bir yahoo ayrıldıktan bir yıl sonra bunu anlayabilmesi için bu işlemi ayrıntılı bir şekilde belgelendirmenizi istiyorum. Sürüm kontrolünün ayarlanması (ve nasıl kullanılacağının gösterilmesi), bir wiki (işin gerçekte nasıl yapıldığına ilişkin gayrı resmi notlar tutmak için) ve basit bir hata takip sistemi ile yardım edin. İşleri gerçekten kayganlaştırmak istiyorsanız, (varsa) yedek bir sunucuya sürekli entegrasyon kurun.

Excel entegrasyonu (veya en azından ithalat / ihracat) için büyük bir arzu göreceksiniz, çünkü tüm işletme okulları şimdi Excel'i öğretiyor ve birçok işletme kursunda kullanılan önemli bir araçtır.

Sarbanes-Oxley ve ABD dışındaki benzer yasalar, gizlilik yasaları ve dahili olarak kendi kendine empoze edilen gizlilik ve güvenlik süreci ve politikaları ile birlikte, gölge-BT fenomenini kısmak için kullanılabilecek ve sık sık kullanılan “çekiç” tir.

Müşteri veya çalışan kişisel olarak tanımlanabilir bilgiler (veya çıkmak istemediğiniz veriler) bu elektronik tablolarda yayınlanmaya başladığında, olmasını bekleyen bir kaza yaşarsınız.

Benzer şekilde, bu skunkworks BT projelerinden biri BT tablolarını alır almaz ve onu saldırıya uğrayan, dışarıdan bakan bir web uygulamasının arkasındaki veriler olarak kullanır, CIO'nuzu ve CEO'nuzu bu uygulamayı kuranın ofisine yerleştirirsiniz. sonuçlarını açıklamaya gelen bir hafta sonu.

Daha sonra, bu çabalara baktığınızda, Fortune 500'deki bir kuruluştaki yüzlerce (veya binlerce) bölümle çarptığınızda, kuruluşunuzun yakında 100'den fazla müşteri "ana" veritabanına sahip olduğunu göreceksiniz. Müşterileriniz iletişim bilgilerini bir yerde güncellediklerinden şikayet etmeye başlıyorlar ancak 10 kişide hala güncel değiller veya büyük ortaklarınızla ne kadar iş yaptığınızı bile bilmiyorsunuz, çünkü bilgiler 10 gölge arasında yayılıyor BT veritabanları.

Tüm bunlar, hiç kimse için eğlenceli olmayan, bir BT ortamında yaşamın zor gerçekleri olan sıkı uyum ve denetim süreçlerine yol açar.

İyi bir strateji, bunu yapan tüm departmanlara bakmak ve gölge IT yatırımlarını IT'ye uygun hale getirmek için bir dava açmak, BT'nin ölçek ekonomisine ulaşabileceği ve mevcut işi daha verimli yapabileceği argümanını ortaya koymaktır. geçici dağıtılmış skunkworks modeli. Bu, BT bütçesi kısıtlamalarının ve teslimat hızının ilk başta skunkworks'lere neden olduğu bir ortamda zor bir satış olabilir, ancak denetim / güvene bağlı risklerle birlikte bir-iki vuruşta iyi sonuç verebilir.

Yeni bir başvuru yazma kararı genellikle talebin bir fayda maliyet analizine dayanır; yanı sıra iş için genel değeri. Bunların hepsi, mevcut BT kaynakları, isteğin kapsamı, iş hedefleri ve yönlendirme gibi birçok başka sürücüyü göz önünde bulundurarak sadece birkaçı. Çoğu zaman, belirli bir departman isteği reddedilir, çünkü departman yöneticisi / müdürü makul bir yatırım getirisi gösteremediğinden veya basitçe belirlenmiş süreci takip etmediğinden.

Sebep ne olursa olsun, 'BT Departmanı', kararın kontrolü dışında olsa bile, genellikle günah keçisidir. Dolayısıyla, talebin reddedilmesi BT departmanına kötü yansımasa da, algı genellikle tamamen farklıdır.

Buna rağmen, dünyadaki hemen hemen her işletme organizasyonunda sahte uygulamalar bulacaksınız. Bazıları iyi yazılmış, bazıları ise iyi gün ışığı görmemiş olması gereken kodları içeriyor.

İç müşterilerimizin ihtiyaçlarını karşılamak için makul bir şekilde yapabileceğimiz her şeyi yapmamız gerekirken, yapamayacağımız zamanlar vardır. Bu olduğunda, onların sorunlarını ele almak için başka yerlere bakacaklar.

Eğer IT grubu projeye aktif olarak dahil olmuşsa, standartlarımıza uyma talebinde bulunabilir, danışanın dahili kodlama kurallarını izlemesine yardımcı olabilir ve sistemlerimizle (veritabanı, ağ, güvenlik duvarı,…) ilgili uygulama etkileşimlerini ve taleplerini anlayabiliriz. Bu katılım olmadan kısa süre içinde yakalanacağız ve neden üretim sistemlerimizin SLA ile buluşmadığını anlamaya çalışırken çok fazla zaman harcayacağız.

IT departmanının onları destekliyor ve destekleyip desteklememesi, destek açısından doğrudan bir etkiye sahip olup olmayacağını ve desteklemeyeceğini, herhangi bir IT departmanının ölçtüğü OLA ve SLA taahhütlerini içerir.

Bu nedenlerle şirketimizde yasaktır:

• Şifreyi bilen tek kişinin şirketten ayrıldığı şifre korumalı Excel Makroları,
• Tecrübesiz kişilerin yazdığı yanlış raporlardan sorumlu tutulmak, çünkü bu IT '
• Daha önce hiç görmediğimiz veya duymadığımız bir raporda değişiklik yapmanız isteniyor.

BT meşgul olduğunda kullanıcılar için sinir bozucu olabileceğini ve 'sadece kendileri yapmaya' eğilimli olabileceğini biliyorum. Ancak, var bile olmadığını bilmediği şeylerden BT sorumlu tutulamaz ve genel BT'den kimse sorumlu değilse, ileride büyük sorunlar vardır.

Burada bir sorun varsa, BT departmanı ile.

Uzman işletme / etki alanı bilgisine sahip kişilerin orada kendi verilerinde değişiklik yapma ve işlem yapmalarına izin vermede yanlış bir şey yoktur.

BT departmanının bunu kabul etmesi ve desteklemesi gerekiyor. Yeniden kullanılabilir arayüzler sunarak, EXCEL veya Access DB'leri gibi uygun formatlarda veri ileterek ve esnek takımlar (COGNOS, Jasper Raporları vb.) Sağlayarak.

BT departmanının önceliklerini de düşünmesi gerekiyor - işe en son metodolojiyi uygulamak için değil, en seksi donanımı kurmak için de hizmet etmek için orada.

Birçok şirket veya şirketteki bölümlerin sahip olduğu bir hayal kırıklığı, BT bölümlerinin önüne geçip işlerini yapmalarını veya yeni şeyler yapmalarını zorlaştırmalarıdır. Bu, kendi sorunlarını çözme girişiminde bulunmak için BT politikaları tarafından tutulduğunu düşünen departmanlara yol açar. İletişim anahtarıdır. Departmanlar BT etrafında çalışıyorsa, gerçekten sahip olduğunuz bir BT problemidir. BT düşman olarak görülmeyi göze alamaz. Şirketler ve özellikle de BT departmanları, birbirlerine karşı çalışmak yerine birlikte çalışması gerektiğini anlamalıdır. Bölümler BT personeli ile iletişim kuruyorsa (özellikle gözetimi gerekenler) ve onlara ihtiyaçlarını ve kendi sorunlarını çözmek için nasıl çalıştıklarını söylerlerse, En azından bilişim krizinin ne zaman gerçekleştiğini anlamaktan ziyade sorunları çözme konusunda yardım etme seçeneğine sahip olacak. IT'yi döngüde tutun.

Neredeyse uzağa bu uygulamalar için özel bir ihtiyaç, uygulamalar veya elektronik tablolar olabilir. Bir BT departmanının iki seçeneği vardır. Etkinleştirici veya engelleyici olabilirler. Tecrübelerime göre, engelliler geçerli iş gereksinimlerinin önüne geçip ortak bir düşman haline geldikleri için kaybediyorlar. Diğer yandan, etkinleştiriciler, bir işletmeye gerçekten yardım eder.

Bu, departman tarafından finanse edilen kalkınmaya ücretsiz hüküm sürülmesi gerektiği anlamına gelmez. Aşağıdakiler gibi bazı gereksinimler uygulanmalıdır:

• Tüm kodların düzenli olarak IT tarafından işletilen bir sürüm kontrol sistemine bağlı olması gerekir. BT bunu mümkün kılmak için serbestçe hesaplar ve rehberler oluşturmalıdır. BT bazı talimatlar vermek bile isteyebilir.
• PII (Kişisel Olarak Tanımlanabilir Bilgiler), kimlik doğrulama, yetkilendirme, şifreleme, yasalarla korunan veriler veya kritik olarak kabul ettiği verileri içeren her şey, IT'den bir danışman tarafından yapılmalı ve onaylanmalıdır. BT / danışman, uygulamanın geliştirilmesini sağlarken işi düzgün bir şekilde korumak için yardım, kütüphaneler vb. Sağlamalıdır.
• Birincil veritabanları korunmalıdır. Veritabanına bağlı olarak, okuma erişimini zorlaştırmak ve erişimi zorlaştırmak nispeten kolay olmalıdır. BT hesaplarını sağlaması, kaydetmesi veya denetlemesi gerekebilir.

Etkinleştirmenin birçok faydası vardır.

• BT, müşterilerinin ihtiyaçlarını karşılama konusunda daha fazla şey öğrenir. Bu, daha iyi önceliklendirme ve paylaşım sağlar.
• BT, problem değil, arkadaş ve fayda olarak görülür.
• Gerçek iş ihtiyaçları karşılanmaktadır.
• İş verileri, BT'nin dahil olması nedeniyle arka kapılara olan ihtiyacı önleyen için yeterince korunmaktadır.
• Taşınma araçları ciro nedeniyle kaybolmaz ve gerekirse BT'ye daha kolay taşınabilir.

Yardım edemedim ama seninle tanıştım. Tarif ettiğiniz problem, kültürleri, dilleri ve kıtaları kapsayan evrensel bir problem gibi görünüyor.

Yapabileceğiniz şeyler:

• Gözetmen onayını isteyerek , veritabanı hesaplarının oluşturulmasını sınırlayın . Onları yerel bir makineyi veritabanı sunucusu olarak kullanmaya zorlamak veya uygulamaları tek başına yazmaları, kullanışlılığını büyük oranda azaltır.

• BT ile ilgili kariyer alanların tüm stajyerlerini sadece BT ile sözleşme yapacak şekilde yapın .

• İşletim sistemi politikasını kısıtlamak , yazılımın yüklenmesini sağlar . Her yazılım kurulumu, bir denetimcinin onayını gerektiren BT yardım masası aracılığıyla yönlendirilmelidir. Bu şekilde MS Access, PHP, Visual Basic, vb. Gibi bir şeylerin yüklenmesi fark edilmeden geçmek daha zor olacaktır.

• Java, C #, C ++ veya dik bir öğrenme eğrisi gerektiren herhangi bir dilin her yeni gelişimin desteklenmesi için yazılması gerektiğini belirten bir politika yayınlayın . Bu sayede etrafta dolaşmak için “belli bir programlama bilgisine sahip” insan evrenini azaltırsınız.

• Gereksinim o bir şirketin BT ihtiyaçlarının yansıtmak olduğu için insanlar, şirketin etrafında "Excel çözümler" bakmak gerekir.

• Bir veri ambarı ve son kullanıcı dostu bir veri madenciliği ve raporlama aracı uygulanması . Bu şekilde, özel yapım stajyer yazılı küçük uygulamalar için gereksinimi azaltır.

Ancak: Yapacağınız tek bir şey , bir Büyük Şefin telefonundan daha fazla güçlenmeyecek , BT Yöneticisini arayacak ve sizden bir stajyerin yaptığı uygulamayı desteklemesini isteyecektir.

Şirketimin bu gibi durumlarda yardımcı olmasının bir yolu, dilde agnostik olmamaktır. Bir uygulamanın / programın bile değerlendirilmesini istiyorsanız, bizim tercih ettiğimiz bir dilde (java) olması gerekir. Bazı JQuery veya js için kuralları biraz uzatabiliriz, ancak kritik bir ihtiyaç için iyi oluşturulmuş bir uygulama olması gerekir. Sakın gelme ve "benim için ev sahipliği yapmana ihtiyacım olan bu PHP uygulamasını aldım" deme çünkü muhtemelen sadece bir politika belgesi alacaksın.

Şeyleri çok büyüymeden önce kesmek önemlidir, çünkü bir kez onlar daha iyi öğrenmeye ya da yeniden yazmaya adayabileceğiniz birine sahipseniz daha iyidir. Çünkü bir keresinde üstteki büyük peruk, benim deneyimimden ondan asla kurtulmayacağınıza karar vermesinden hoşlanıyor.

Geeks'in kibiri!

Pek çok durumda, işletme kullanıcıları araçları BT çalışanlarının anlamadığı şeyleri yapmak için kullanabilir. Bu, doğası gereği kötü oldukları için değil, işi, işlerin nasıl yürüdüğünü ve nasıl çalışmak istediklerini bildikleri için değil.

Örneğin, bir yazılım şirketi, pazar veri yayınlarına erişimi optimize etmek (maliyet için) için bir uygulama geliştirdi. Daha sonra bir Excel eklentisi sağladılar, böylece kullanıcılar bir elektronik tablo aracılığıyla en son hisse fiyatına erişebildiler. Bir yıl ve hızlı bir şekilde çalıştığım şirketteki tüm yatırımcıların işlem stratejilerini desteklemek için bir veya daha fazla inanılmaz karmaşık elektronik tabloları vardı. Her zaman ve sonra makroyla bir problemi olur ve BT görevlilerinden birinden yardım isterdi, çoğu reddetti (ve işin bizden neden nefret ettiğini merak ediyorlar!). Ancak bir sorunum vardı ve çeşitli fonksiyon parametreleri ve dairesel referanslarla teknik sorunları çözebilirken, tüm elektronik tablonun gerçekte ne yaptığı ile ilgili en ufak bir ipucuna sahip olmadığımı söyleyebilirim. Kötü bir şekilde bir araya getirildikleri veya programlanmadıkları için değil, tüccarların başarmaya çalıştığı şeylerin inceliklerini takdir edecek bilgi veya deneyime sahip olmadığım için değil. Ayrıca, bu elektronik tablolardan birinin işlevselliğini standart bir BT projesi olarak "uygun" bir programlama dilinde çoğaltmak için 5 yıllık bir yılı artı BT projesini tahmin ediyorum.