Większe firmy zwykle mają problem z tym, że nie jest możliwe napisanie wszystkich programów, które chcą pracownicy (aby zaoszczędzić czas i zoptymalizować procesy) z powodu braku personelu i pieniędzy.

Następnie ukryte programy będą tworzone przez niektóre osoby mające (przynajmniej trochę) doświadczenie w kodowaniu (lub przez tanich studentów / stażystów ...). W niektórych okolicznościach aplikacje te nabierają znaczenia i rozprzestrzeniają się od jednego użytkownika do całego działu.

Jest jeszcze punkt krytyczny: kto będzie utrzymywał aplikację, dodawał nowe funkcje, ...? Ta aplikacja jest krytyczna. To jest potrzebne. Ale stażysta opuścił firmę. Nikt nie wie jak to działa. Masz tylko kilka źródeł i jakąś dokumentację.

Czy ma sens próba kontrolowania lub zakazywania tworzenia aplikacji wykonywanych ad hoc poza działem IT (z wyjątkiem drobnych rzeczy, takich jak makra Excel)?

Pracowałem dla firmy, w której każda aplikacja, którą im daliśmy, prowadziła do pytania: czy możemy wyeksportować te dane do Excela?

Po chwili zdecydowałem, że muszę wiedzieć, dlaczego mieli obsesję na punkcie eksportu Excela. Okazało się, że wiele działów miało jedną osobę, która była ekspertem w programie Excel i mogła w krótkim czasie napisać przydatną aplikację do analizy danych. Te aplikacje rozprzestrzeniłyby się po całym dziale jak pożar, a my, technicy, nie mieliśmy pojęcia, że ​​w ogóle istnieją.

Dlaczego nie przyszli do nas pierwszy? Ponieważ istniała opinia, że ​​zespół techniczny miał zbyt wiele do zrobienia, a gdyby o to poprosili, mogliby (jeśli mieliby szczęście) ustawić ją w kolejce sześć miesięcy później.

To nie był niesprawiedliwy zarzut i nigdy nie poprosili nas o wsparcie ich aplikacji Excel, więc nikt tak naprawdę nie pomyślał, że to problem. Kiedy ci programiści programu Excel odeszli, zawsze udało im się znaleźć kogoś, kto by go podniósł.

Można argumentować, że oznaczało to, że niepoprawnie ustalaliśmy priorytety, że nie wykonano ważnej pracy. Twierdziłbym jednak, że zwolniło to lepiej zarabiających programistów do trudniejszej pracy. Co może boleć?

Teraz byłoby zabronić oprogramowanie aktualizuje bazę danych zapisywane poza deweloperami. I odmówiłbym wspierania aplikacji napisanych poza zespołem programistów. Ale nie próbowałbym zabronić, aby całe oprogramowanie zostało napisane przez samą firmę, i chętnie napisałbym eksport danych, aby im to umożliwić (o ile nie ujawnia to danych, których nie powinni widzieć, oczywiście ).

Myślę, że ludziom brakuje tutaj ogólnego punktu:

Jeśli nie podoba ci się cały rozwój niestandardowy, który jest w toku, zakazanie mu rozwiązania niewłaściwego problemu - powinieneś zamiast tego zapytać, dlaczego obchodzą IT, a nie tylko powiedzieć im, że nie jest to dozwolone. Pamiętaj, że istniejesz (IT), aby pomóc im lepiej wykonywać swoją pracę i że ludzie nie używają oprogramowania, ponieważ jest fajne, schludne lub nowe, używają go, ponieważ rozwiązuje problem, który mają.

Dlaczego te aplikacje są tworzone w pierwszej kolejności?

We wszystkich przypadkach, które widziałem, istnieje wspólny powód:

Grupy biznesowe traktują priorytetowo własne potrzeby bardziej niż te same potrzeby są traktowane priorytetowo w kontekście całej firmy

Marketing jest odpowiedzialny tylko za marketing, więc inicjatywy, które przynoszą korzyści ich celom, wydają się dla nich kluczowe, a jednocześnie są uważane za kłopotliwe dla innych grup i mają tendencję do priorytetowego traktowania niżej, jeśli chodzi o ograniczone zasoby, takie jak IT. Priorytetyzacja pojawia się tylko wtedy, gdy chcą skorzystać z udostępnionego zasobu - jeśli utrzymają projekt całkowicie w swoim własnym dziale, tylko kierownik działu musi dbać o budżet i harmonogram.

Nie ma powodu, dla którego zabraniałbym tego rodzaju rozwoju, w granicach rozsądku - łagodzi on ograniczenia dotyczące współdzielonych zasobów (głównie IT) i pozwala każdej grupie na samodzielne rozwiązywanie własnych problemów (ponieważ osoby zaznajomione z zaawansowanym programem Excel są dość powszechne, ponieważ jest to powszechny problem, większość działów ma co najmniej jeden).

Jednak nie można oczekiwać, że rozwiąże on jakiekolwiek problemy wynikające z tych aplikacji lub wesprze je po odejściu pierwotnego programisty z firmy. Jak wspomniano w innym poście, nie powstrzymuje to dużego szefa przed żądaniem, abyś go wspierał, ale jeśli wyczuwasz rodzaje niestandardowych aplikacji lub procesów, możesz poczuć, kiedy coś staje się krytyczne, a ty być może trzeba będzie zaangażować się, aby wprowadzić go „wewnętrznie”. Ponadto, jeśli coś łączy się i modyfikuje systemy podlegające kontroli IT, należy zaangażować IT, choćby po to, aby zapewnić bezpieczeństwo i integralność ich systemów centralnych - jeśli jednak jest to coś ograniczonego do pulpitu użytkownika, po co czuć potrzebę zabronić?

Należy jednak pamiętać: każda aplikacja niestandardowa opracowana poza IT odpowiada potrzebie, która nie jest zaspokajana przez IT . Może być dobry powód, dla którego nie zostały spełnione - brak priorytetu w firmie, bardzo wyspecjalizowany problem, nie tak dobry jak inne opcje, niestandardowy język, którego nie znają informatycy itp. - i brak zaangażowania IT może być uzasadnione, ale te rozwiązania zostały stworzone, ponieważ niektóre działy miały potrzeby, których dział IT nie mógł (lub nie chciałby) zaspokoić.

Spróbuj pomóc im rozwiązać ich problemy, a jeśli nie masz czasu ani zasobów, pozwól im rozwiązać je samodzielnie. Ustanowienie jakiegoś języka o silnej krzywej uczenia się, którego jedynym celem jest powstrzymanie ludzi od prowadzenia działalności, służy jedynie wzmocnieniu elitarnego nastawienia większości użytkowników biznesowych postrzegających IT, a ostatecznie takie elitarne podejście prowadzi tylko do więcej tego samego problemu, ponieważ użytkownicy boją się podejść do IT i są przekonani, że IT nie rozumie ich potrzeb lub pragnień. Otwórz relację - zrozumienie, czego potrzebują, to jedyny sposób, aby powstrzymać ich przed obejściem ciebie.

Należy również wziąć pod uwagę przypadek firm, w których dział IT składa się z niekompetentnych osób, podczas gdy ukryta aplikacja zostałaby stworzona przez zręcznego programistę, który nie pracuje w firmie. Z mojego doświadczenia wynika, że ​​przypadki te są niezwykle częste.

Wyobraź sobie, że masz podwójny profil programisty i księgowego. Jesteś zatrudniony jako księgowy, ponieważ była to okazja na znalezienie dobrze płatnej pracy. Szybko widzisz, że twoi koledzy (a teraz ty) spędzają godziny na powtarzaniu rzeczy, które program może zrobić w kilka sekund.

Poświęcasz kilka wieczorów na napisanie aplikacji, która wykona całą pracę. Pokazujesz to na swoim laptopie swoim kolegom, a oni uważają to za bardzo przydatne. Chcesz zainstalować go na komputerach firmowych, ale powinieneś mieć zgodę działu IT. Prosisz o to, ale odrzucają, ponieważ nie będą obsługiwać Twojej aplikacji.

Czy to nie brzmi głupio?

Poza tym szczególnym przypadkiem problem ze wsparciem nie różni się zbytnio od tego, że wiele firm napotyka całe  oprogramowanie, nawet jedno napisane w dziale IT: jeśli dział IT nie egzekwuje najlepszych praktyk, kod będzie źle / nieudokumentowany, napisane przez niedoświadczonych ludzi, którzy nie dbają o utrzymanie i którzy opuścili lata temu.

Podsumowując, głównym pytaniem jest rentowność . Jeśli ty, dział IT, zostaniesz poproszony o utrzymanie aplikacji opracowanej przez urzędnika, który nie rozumie najbardziej podstawowych zasad tworzenia oprogramowania, nie ma znaczenia, jak przyjemne jest to zadanie, nadal musisz to zrobić, jeśli przynosi dużo pieniędzy dla firmy . Lub przepisujesz go od zera, jeśli jest to najtańszy sposób na załatwienie sprawy.

Nie możesz tego w pełni kontrolować ...

Powiedziałbym, że nigdy nie możesz W PEŁNI kontrolować tego, ponieważ pracownicy zawsze będą mieli środki do tworzenia fałszywego kodu i rozpowszechniania go w alternatywny sposób. Nie ma więc zbyt wiele pożytku z obsesji na punkcie tego, gdy opracujesz i egzekwujesz kilka podstawowych zasad i procesów oraz skonfigurujesz kilka narzędzi.

Chodzi o to, aby uczynić to tak atrakcyjnym, jak to możliwe, aby ludzie przestrzegali tych zasad i korzystali z tych narzędzi, a nie uniemożliwiali robienie nowych rzeczy, że nic nie produkują.

Ale możesz stworzyć środowisko przyjazne dla kodu

Robi to wiele firm, często bardzo dużych. Dobrym przykładem jest Google, dla którego przedstawiciele stwierdzili, że używają jednego SCM dla całej firmy, aby każdy mógł monitorować i patrzeć na kod innych użytkowników.

Polecam wykonać następujące czynności:

• dać publiczny dostęp do niektórych obszarów twojego SCM,
• ułatwić dostęp do serwerów ciągłej integracji i ciągłej kontroli,
• zachęcać ludzi do tworzenia miejsc pracy dla swoich narzędzi.

Problemem jest zatem rozprzestrzenianie się technologii. Oczywiście niektórzy wolą używać X zamiast Y i wtedy trudniej jest dopasować je do architektury. Jednak nie jest to niemożliwe, a jeśli chcą, aby ich kod został utrzymany, prawdopodobnie dostaną dodatkową milę, jeśli, cóż, to tylko jedna mila.

Możesz również zająć bardziej arbitralne stanowisko i zdecydować, że dozwolony jest tylko język L i Stack S, ale wtedy dostaniesz jakieś nieuczciwe rzeczy tu i tam, więc polecam je trochę rozszerzyć. Niektóre systemy CI dokonują cudów za pomocą kilku wtyczek, jeśli Twoi pracownicy są gotowi napisać trochę kodu kleju lub skryptów konfiguracyjnych, aby dopasować je.

Daj drużynom trochę swobody

Ważne jest, aby dać zespołom trochę swobody w zachowaniu kaprysu i rozpocząć nowe małe projekty z eksperymentalnymi rzeczami. Trzyma je na palcach, a ty, podobnie jak zmuszasz do rozważenia tych technologii, a raczej do pozostania w stosie na zawsze, dopóki nie spowoduje to problemów.

Upewnij się więc, że mają możliwość zainstalowania własnych systemów do testowania swoich domowych projektów. Ale upewnij się, że mają w zwyczaju rozmawiać o tym z IT.

Porozmawiaj z IT, zaangażuj ich

O wiele lepiej, jeśli twoi pracownicy rozwiną odruch strzelania do wiadomości e-mail do IT i zapytają ich, czy mogą coś dla nich skonfigurować i pomieścić. Przez większość czasu będą odrzucani, ale przynajmniej istnieje pojęcie kontroli i kto powinien być odpowiedzialny, i daje IT pewien wgląd w wymagania różnych zespołów.

Gdy projekty osiągną masę krytyczną, możesz poprosić ponownie, a one ponownie rozważą. Komunikacja jest kluczowa i musisz mieć zespoły programistów, konsultantów, personelu wsparcia IT lub kogokolwiek, kto zajmuje się kodem do współpracy. Żaden z nich nie chce bezpańskich programów, więc leży to w interesie wszystkich. O wiele łatwiej jest egzekwować reguły, jeśli same je wykonują.

Nie można zatrzymać tych „ukrytych” aplikacji, ponieważ ludzie zmuszają je do rozwiązywania rzeczywistych problemów biznesowych. Wszystko, co możesz zrobić, to pomóc im to zrobić „we właściwy” sposób. Mówiąc „w prawo” mam na myśli tworzenie aplikacji, aby aplikacje mogły być utrzymywane po odejściu osoby, która je uruchomiła. Zalecam używanie języka sugerowanego w Up lub Out : Potrzebuję, abyś szczegółowo opisał ten proces, aby każdy Yahoo mógł go zrozumieć po roku od odejścia. Pomoc w konfigurowaniu kontroli wersji (i pokazaniu, jak z niej korzystać), wiki (do przechowywania nieformalnych notatek o tym, jak praca faktycznie się wykonuje) i prosty system śledzenia błędów. Jeśli chcesz sprawić, by wszystko było naprawdę gładkie, ustaw ciągłą integrację na zapasowym serwerze (jeśli taki masz).

Zobaczysz ogromne pragnienie integracji Excela (a przynajmniej importu / eksportu), ponieważ wszystkie szkoły biznesu uczą teraz Excela i jest to główne narzędzie używane na wielu kursach biznesowych.

Sarbanes-Oxley i podobne ustawodawstwo poza USA, w połączeniu z przepisami dotyczącymi prywatności oraz wewnętrznie narzuconym przez siebie procesem i polityką prywatności i bezpieczeństwa to „młotek”, który może i często jest wykorzystywany do ograniczania zjawiska IT-shadow.

Gdy tylko informacje umożliwiające identyfikację klienta lub pracownika (lub dowolne dane, których nie chcesz wydostać) zaczną krążyć w tych arkuszach kalkulacyjnych, czeka Cię wypadek.

Podobnie, gdy tylko jeden z tych projektów informatycznych skunkworks weźmie arkusz kalkulacyjny Excel i użyje go jako danych za zewnętrzną aplikacją internetową, która została zhakowana, Twój CIO i CEO szturmują biuro każdego, kto stworzył tę aplikację nadchodzi weekend, aby wyjaśnić konsekwencje.

Następnie pojawia się problem polegający na tym, że kiedy spojrzymy na te wysiłki pomnożone przez setki (lub tysiące) działów w przedsiębiorstwie z listy Fortune 500, wkrótce okaże się, że nasze przedsiębiorstwo ma ponad 100 „głównych” baz danych klientów. Twoi klienci zaczynają narzekać, że zaktualizowali swoje dane kontaktowe w jednym miejscu, ale nadal są nieaktualne w 10 innych lub że nawet nie wiesz, jak wiele robisz z dużymi partnerami, ponieważ informacje są rozłożone na 10 cieni Bazy danych IT.

Wszystko to powoduje uciążliwe procesy zgodności i audytu, które nie są zabawne dla nikogo, ale są twardymi faktami z życia IT w środowisku przedsiębiorstwa.

Dobrą strategią jest przeanalizowanie wszystkich działów, które to robią, i uzasadnienie przeniesienia inwestycji w cień IT do IT, co uzasadnia argument, że IT może osiągnąć ekonomię skali i wykonać tę pracę bardziej efektywnie niż obecnie rozproszony model skunkworks ad hoc. Może to być trudne do sprzedania w środowisku, w którym ograniczenia budżetu IT i szybkość dostarczania spowodowały przede wszystkim skunkworks, ale w połączeniu z ryzykiem audytu / powiernictwa może dać dobry wynik dwa do dwóch.

Decyzja o napisaniu nowego wniosku często opiera się na analizie kosztów i korzyści wniosku; a także ogólną wartość dla firmy. Wszystko to przy uwzględnieniu wielu innych czynników, takich jak dostępne zasoby IT, zakres zapytania, cele biznesowe i kierunek, żeby wymienić tylko kilka. Często odrzucane jest żądanie konkretnego działu, ponieważ kierownik / dyrektor działu nie wykazał rozsądnego zwrotu z inwestycji lub po prostu nie przestrzega ustalonego procesu.

Niezależnie od powodu „dział IT” często jest kozłem ofiarnym, nawet jeśli decyzja była poza ich kontrolą. Dlatego nawet jeśli odrzucenie wniosku może nie odzwierciedlać źle działu IT, postrzeganie jest często zupełnie inne.

Mimo to znajdziesz fałszywe aplikacje w prawie każdej organizacji biznesowej na świecie. Niektóre dobrze napisane, a inne dobrze, zawierają kod, który nigdy nie powinien ujrzeć światła dziennego.

Chociaż powinniśmy robić wszystko, co w naszej mocy, aby zaspokoić potrzeby naszych wewnętrznych klientów, są chwile, których po prostu nie możemy. Kiedy tak się stanie, będą szukać gdzie indziej, aby rozwiązać swój problem.

Jeśli grupa IT jest aktywnie zaangażowana w projekt, możemy wymagać przestrzegania naszych standardów, pomóc konsultantowi w przestrzeganiu wewnętrznych wytycznych dotyczących kodowania oraz zrozumieć interakcje aplikacji z naszymi systemami (wymagania dotyczące bazy danych, sieci, zapory ogniowej itp.). Bez tego zaangażowania zostaniemy przyłapani i spędzimy dużo czasu próbując dowiedzieć się, dlaczego nasze systemy produkcyjne nie spełniają warunków SLA.

Niezależnie od tego, czy dział IT akceptuje je i wspiera, czy nie, mogą i będą miały bezpośredni wpływ pod względem wsparcia, zobowiązań OLA i SLA, na podstawie których ocenia się każdy dział IT.

Są one zabronione w naszej firmie z następujących powodów:

• Makra Excel chronione hasłem, w których jedyna osoba znająca hasło opuściła firmę,
• Odpowiedzialność za nieprawidłowe raporty napisane przez niedoświadczone osoby, ponieważ to IT ”
• Prośba o zmodyfikowanie raportu, o którym nigdy wcześniej nie słyszeliśmy ani nie słyszeliśmy.

Rozumiem, że może to być frustrujące dla użytkowników, gdy dział IT jest zajęty i mogą mieć skłonność do „po prostu robienia tego sami”. Ale IT nie może być pociągnięte do odpowiedzialności za rzeczy, o których nie wie, że w ogóle istnieją, a jeśli nikt nie jest odpowiedzialny za całość IT, to przed nami wielkie problemy.

Jeśli występuje tutaj problem, dotyczy to działu IT.

Nie ma nic złego w pozwalaniu osobom o specjalistycznej wiedzy biznesowej / domenowej na manipulowanie i przetwarzanie własnych danych.

Dział IT musi to potwierdzić i wesprzeć. Zapewniając interfejsy wielokrotnego użytku, dostarczając dane w wygodnych formatach, takich jak EXCEL lub Access DB, oraz zapewniając elastyczne narzędzia (COGNOS, Raporty Jaspera itp.).

Dział IT musi również przemyśleć swoje priorytety - ma służyć biznesowi, nie wdrażać najnowszej metodologii lub instalować najseksowniejszy sprzęt.

Frustracja wielu firm lub działów w firmach polega na tym, że ich działy IT przeszkadzają im w wykonywaniu pracy lub wykonywaniu nowych zadań. To powoduje, że działy, które wydają się być powstrzymywane przez zasady IT, próbują rozwiązać własne problemy. Komunikacja jest kluczem. Jeśli działy pracują nad IT, to tak naprawdę masz problem z IT. IT nie może być postrzegane jako wróg. Firmy, a zwłaszcza działy IT, muszą zdać sobie sprawę, że muszą ze sobą współpracować zamiast ze sobą. Jeśli departamenty komunikują się ze swoimi pracownikami IT (zwłaszcza tymi, którzy powinni mieć nadzór) i mówią im o swoich potrzebach oraz o tym, jak pracują nad rozwiązaniem własnych problemów, Dział IT będzie miał przynajmniej możliwość pomocy w rozwiązywaniu problemów, zamiast dowiedzieć się, kiedy nastąpi kryzys. Informuj na bieżąco.

Prawie nie ma potrzeby używania tych specjalnych narzędzi, czy to aplikacji, czy arkuszy kalkulacyjnych. Dział IT ma dwie możliwości. Mogą to być czynniki włączające lub wyłączające. Z mojego doświadczenia wynika, że ​​osoby niepełnosprawne przegrywają, ponieważ stają na przeszkodzie uzasadnionym potrzebom biznesowym i stają się wspólnym wrogiem. Z drugiej strony czynniki wspomagające rzeczywiście pomagają przedsiębiorstwom.

Nie oznacza to, że rozwój finansowany przez departament powinien mieć swobodę. Należy egzekwować niektóre wymagania, takie jak:

• Cały kod musi być regularnie przypisywany do systemu kontroli wersji obsługiwanego przez dział IT. Aby to umożliwić, dział IT powinien swobodnie tworzyć konta i katalogi. IT może nawet chcieć przekazać jakieś instrukcje.
• Wszystko, co wiąże się z PII (dane osobowe), uwierzytelnianiem, autoryzacją, kryptografią, danymi chronionymi przez prawo lub danymi, które firma uważa za kluczowe, musi obejmować i musi zostać zatwierdzone przez konsultanta z działu IT. IT / konsultant powinien zapewnić pomoc, biblioteki itp., Aby odpowiednio chronić firmę, jednocześnie umożliwiając tworzenie aplikacji.
• Podstawowe bazy danych powinny być chronione. W zależności od bazy danych dostęp do odczytu powinien być stosunkowo łatwy do uzyskania, a dostęp do zapisu trudniejszy. IT może potrzebować zapewnić konta, logowanie lub audyt.

Włączanie ma wiele zalet.

• IT uczy się więcej o zaspokajaniu potrzeb swoich klientów. Prowadzi to do lepszego ustalania priorytetów i udostępniania.
• IT jest postrzegane raczej jako przyjaciel i korzyść niż problem.
• Rzeczywiste potrzeby biznesowe są spełnione.
• Dane biznesowe są odpowiednio chronione, ponieważ zaangażowano IT, co zapobiega potrzebie tylnych drzwi.
• Narzędzia oddziału nie są tracone z powodu obrotu i w razie potrzeby można je łatwiej przenieść do działu IT.

Nie mogłem się powstrzymać od utożsamienia się z tobą. Problem, który opisujesz, wydaje się być uniwersalny, obejmujący kultury, języki i kontynenty.

Rzeczy, które możesz zrobić:

• Ogranicz tworzenie kont bazy danych , prosząc o zgodę przełożonego. Zmuszenie ich do używania lokalnego komputera jako serwera bazy danych lub pisanie aplikacji jako samodzielnych znacznie zmniejsza jego użyteczność.

• Spraw, aby wszyscy stażyści w karierach związanych z IT byli zatrudniani wyłącznie przez IT .

• Ograniczanie za pomocą zasad systemu operacyjnego instalacji oprogramowania . Każda instalacja oprogramowania musi być prowadzona za pośrednictwem działu pomocy IT, wymagając zgody przełożonego. W ten sposób instalacja czegoś takiego jak MS Access, PHP, Visual Basic itp. Będzie trudniejsza do przejścia niezauważona.

• Należy wydać zasadę, zgodnie z którą każdy nowy program, aby uzyskać wsparcie, musi być napisany w języku Java, C #, C ++ lub innym języku wymagającym intensywnej nauki . W ten sposób redukujesz wszechświat ludzi z „pewną wiedzą na temat programowania”, aby się bawić.

• Te wymagania ludzie muszą spojrzeć na „rozwiązań Excel” wokół firmy, ponieważ jest to odzwierciedlenia potrzeb informatycznych korporacji.

• Wdrożenie hurtowni danych oraz przyjaznego dla użytkownika narzędzia do eksploracji i raportowania danych . W ten sposób zmniejszasz potrzebę tworzenia niestandardowych, napisanych przez małe aplikacje aplikacji wewnętrznych.

Ale: nic, co zrobisz, nie przebije połączenia telefonicznego od Wielkiego Szefa , dzwoniąc do IT Managera i prosząc go o wsparcie aplikacji stworzonej przez stażystę.

Jednym ze sposobów, w jaki moja firma pomaga w takich sytuacjach, jest brak agnostyki językowej. Jeśli chcesz, aby aplikacja / program był nawet brany pod uwagę, musi być w wybranym przez nas języku (java). Możemy nieco rozszerzyć reguły dla niektórych JQuery lub js, ale musiałaby to być dobrze skomponowana aplikacja, która zaspokoiłaby krytyczną potrzebę. Nie przychodź i nie mów: „Mam tę aplikację PHP, którą musisz dla mnie hostować”, ponieważ prawdopodobnie dostaniesz po prostu arkusz polis.

Ważne jest, aby skubać rzeczy, zanim staną się zbyt duże, ponieważ kiedy już się pojawią, lepiej mieć kogoś, kogo możesz poświęcić na naukę lub przepisywanie. Ponieważ kiedy ta duża peruka na górze zdecyduje, że mu się podoba, prawdopodobnie nigdy nie pozbędziesz się jej z mojego doświadczenia.

Arogancja maniaków!

W wielu przypadkach użytkownicy biznesowi mogą używać narzędzi do robienia rzeczy, których ludzie IT nie rozumieją. Nie dlatego, że są z natury źli, ale dlatego, że znają biznes, jak to działa i jak chcieliby, aby działał.

Na przykład firma programistyczna opracowała aplikację do optymalizacji (pod względem kosztów) dostępu do danych rynkowych. W zamian udostępnili wtyczkę Excel, aby użytkownicy mogli uzyskać dostęp do najnowszej ceny akcji za pomocą arkusza kalkulacyjnego. Jeden rok do przodu i prawie każdy handlowiec w firmie, w której pracowałem, miał jeden lub więcej niezwykle złożonych arkuszy kalkulacyjnych wspierających ich strategię handlową. Od czasu do czasu mieli problem z makrami i prosili jednego z informatyków o pomoc, większość odmówiła (i zastanawiają się, dlaczego firma nas nienawidzi!). Miałem jednak okazję i chociaż mogłem naprawić problemy techniczne z różnymi parametrami funkcji i referencjami cyklicznymi, mogę szczerze powiedzieć, że nie miałem najmniejszego pojęcia, co właściwie zrobił cały arkusz kalkulacyjny. Nie dlatego, że były źle połączone lub źle zaprogramowane, ale dlatego, że nie miałem wiedzy ani doświadczenia, aby docenić subtelność tego, co inwestorzy starali się osiągnąć. Ponadto oszacowałbym, że projekt informatyczny dla 5 osób na rok plus powiela funkcjonalność jednego z tych arkuszy kalkulacyjnych w „właściwym” języku programowania jako standardowy projekt informatyczny.