Le aziende più grandi di solito hanno il problema che non è possibile scrivere tutti i programmi desiderati dai dipendenti (per risparmiare tempo e ottimizzare i processi) a causa della mancanza di personale e denaro.

Quindi i programmi nascosti saranno creati da alcune persone che hanno (almeno alcune) esperienze di programmazione (o da studenti / stagisti a basso costo ...). In alcune circostanze queste applicazioni aumenteranno di importanza e si diffonderanno da un utente a un intero reparto.

Quindi c'è il punto critico: chi manterrà l'applicazione, aggiungerà nuove funzionalità, ...? E questa app è fondamentale. È necessario. Ma lo stagista ha lasciato la compagnia. Nessuno sa come funziona. Hai solo un sacco di fonti e una sorta di documentazione.

Ha senso provare a controllare o vietare lo sviluppo di applicazioni fatto ad-hoc al di fuori del dipartimento IT (ad eccezione di elementi minori come le macro di Excel)?

Lavoravo per un'azienda in cui ogni app che fornivamo li portava alla domanda: possiamo esportare questi dati in Excel?

Dopo un po ', ho deciso che dovevo sapere perché erano ossessionati dalle esportazioni di Excel per tutto. Si è scoperto che molti dipartimenti avevano una persona esperta in Excel e in grado di scrivere un'utile app di analisi dei dati in pochissimo tempo. Queste app si sarebbero diffuse in tutto il dipartimento come un incendio e noi, i tecnici, non avevamo idea che esistessero.

Perché non sono venuti prima da noi? Perché c'era una reputazione che il team tecnico aveva troppo da fare e, se lo avessero chiesto, avrebbero potuto (se fossero stati fortunati) essere messi in fila sei mesi dopo.

Non è stata un'accusa ingiusta e non ci hanno mai chiesto di supportare le loro app Excel, quindi nessuno pensava davvero che fosse un problema. Quando questi sviluppatori di Excel se ne andarono, riuscirono sempre a trovare qualcun altro a raccoglierlo.

Si potrebbe sostenere che ciò significava che stavamo assegnando delle priorità in modo errato, che il lavoro importante non veniva svolto. Ma direi che ha liberato gli sviluppatori più pagati a fare lavori più difficili. Cosa può far male?

Ora io vorrei proibire software che aggiorna il database in fase di scrittura al di fuori del team di sviluppo. E rifiuterei di supportare app scritte al di fuori del team di sviluppo. Ma non tenterei di vietare a tutti i software di essere scritti dall'azienda stessa e scriverei felicemente esportazioni di dati per autorizzarli a farlo (purché ciò non esponga dati che non dovrebbero vedere, ovviamente ).

Penso che alla gente manchi il punto generale qui:

Se non ti piace tutto lo sviluppo personalizzato che sta accadendo, proibirlo è risolvere il problema sbagliato - dovresti invece chiederti perché stanno andando in giro per l'IT, non solo dicendo loro che non è permesso. Ricorda che tu (IT) esisti per aiutarli a fare meglio il loro lavoro e che le persone non usano il software perché è bello, pulito o nuovo, lo usano perché risolve un problema che hanno.

Perché queste app vengono create in primo luogo?

In tutti i casi che ho visto, c'è un motivo comune:

I gruppi di imprese danno priorità ai propri bisogni rispetto a quelli che sono prioritari nel contesto dell'intera azienda

Il marketing è responsabile solo del marketing, quindi le iniziative a beneficio dei loro obiettivi sembrano critiche per loro, mentre sono considerate lanugine per altri gruppi e tendono ad avere una priorità inferiore quando si tratta di risorse limitate come l'IT. La definizione delle priorità entra in gioco solo quando desiderano utilizzare una risorsa condivisa: se mantengono il progetto interamente all'interno del proprio reparto, solo il capo dipartimento deve occuparsi del budget e della tempistica.

Non c'è motivo per cui proibire questo tipo di sviluppo, entro limiti ragionevoli: facilita i vincoli sulle risorse condivise (principalmente IT) e consente a ciascun gruppo di autorizzare se stesso a risolvere i propri problemi (poiché le persone esperte in Excel avanzato sono piuttosto comuni, poiché questo è un problema comune, la maggior parte dei dipartimenti ne ha almeno uno).

Tuttavia, non ci si può aspettare di risolvere eventuali problemi derivanti da queste applicazioni o di supportarle dopo che lo sviluppatore originale ha lasciato l'azienda. Come menzionato da un altro postato, ciò non impedisce al grande capo di chiedere di supportarlo, ma se tieni conto dei tipi di applicazioni o processi personalizzati disponibili, puoi avere un'idea di quando qualcosa diventa critico e tu potrebbe essere necessario essere coinvolti per portarlo "in-house". Inoltre, se qualcosa si connette e modifica i sistemi che sono sotto il controllo IT, allora l'IT dovrebbe essere coinvolto, anche solo per garantire la sicurezza e l'integrità dei loro sistemi centrali - tuttavia, se è qualcosa di limitato al desktop di un utente, perché sentirne la necessità vietarlo?

Ma ecco qualcosa da ricordare: ogni applicazione personalizzata che è stata sviluppata al di fuori dell'IT corrisponde a un'esigenza che non viene soddisfatta dall'IT . Potrebbe esserci una buona ragione per cui non vengono rispettati - non una priorità in azienda, un problema molto specializzato, non buono come altre opzioni, un linguaggio personalizzato che il personale IT non conosce, ecc. - e la mancanza di coinvolgimento IT potrebbe essere legittimo, ma queste soluzioni sono state create perché alcuni dipartimenti avevano un'esigenza che l'IT non poteva (o non voleva) soddisfare.

Cerca di aiutarli a risolvere i loro problemi e, se non hai il tempo o le risorse, lasciali risolvere da soli. Mandare un linguaggio che ha una ripida curva di apprendimento, con l'unico scopo di tenere le persone fuori dalla tua attività, serve solo a migliorare l'atteggiamento elitario che la maggior parte degli utenti percepisce l'IT e, alla fine, quel tipo di atteggiamento d'élite porta solo a più dello stesso problema, poiché gli utenti hanno paura di avvicinarsi all'IT e sono convinti che l'IT non capisca le loro esigenze o desideri. Apri la relazione: capire di cosa hanno bisogno è l'unico modo per impedire loro di aggirarti.

Si dovrebbe anche considerare il caso delle aziende in cui il reparto IT contiene persone incompetenti, mentre l'app nascosta verrebbe creata da uno sviluppatore abile che ha un lavoro non da sviluppatore all'interno dell'azienda. Nella mia esperienza, questi casi sono estremamente frequenti.

Immagina di avere un doppio profilo di uno sviluppatore di software e un contabile. Sei assunto come contabile perché questa è stata un'opportunità per te per ottenere un lavoro ben pagato. Capisci subito che i tuoi colleghi (e ora tu) passano ore a fare cose ripetitive che possono essere fatte in pochi secondi da un programma.

Trascorri alcune sere per scrivere l'app che farà tutto il lavoro. Lo mostri sul tuo laptop personale ai tuoi colleghi e lo trovano molto utile. Vuoi installarlo sui PC aziendali, ma dovresti avere l'accordo del dipartimento IT. Lo chiedi, ma lo rifiutano perché non supportano la tua applicazione.

Non sembra stupido?

A parte questo caso particolare, il problema con il supporto non è molto diverso da quello che molte aziende incontrano con tutto  il software, anche uno scritto all'interno del dipartimento IT: se il dipartimento IT non applica le migliori pratiche, il codice sarà male / non documentato, scritto da persone inesperte che non si preoccupano della manutenzione e che se ne sono andate anni fa.

Per concludere, la domanda principale è la redditività . Se tu, il dipartimento IT, ti viene chiesto di mantenere un'app sviluppata da un impiegato che non capisce le regole di base dello sviluppo software, non importa quanto sia divertente questo compito, devi comunque farlo se porta un sacco di soldi per l'azienda . O lo riscrivi da zero se è il modo più economico per fare le cose.

Non puoi controllarlo completamente ...

Direi che non puoi mai controllarlo COMPLETAMENTE, poiché i dipendenti avranno sempre i mezzi per produrre codice canaglia e diffonderlo con mezzi alternativi. Quindi non è molto utile ossessionarsi troppo su di esso, dopo aver redatto e applicato alcune regole e processi di base e impostato alcuni strumenti.

L'idea è che tu renda il più attraente possibile per le persone rispettare queste regole e usare questi strumenti, piuttosto che rendere così impossibile fare cose nuove da non produrre nulla.

Ma puoi creare un ambiente favorevole al codice

Molte aziende, spesso molto grandi, lo fanno. Un buon esempio è Google, per il quale i rappresentanti hanno dichiarato di utilizzare un unico SCM per l'intera azienda, affinché tutti possano monitorare e guardare il codice degli altri.

Ti consiglierei di fare quanto segue:

• dare accesso pubblico ad alcune aree del tuo SCM,
• semplificare la richiesta di accesso a server di integrazione continua e ispezione continua
• incoraggiare le persone a creare posti di lavoro per i loro strumenti.

Il problema è quindi la proliferazione di tecnologie. Ovviamente, alcuni preferiranno usare X su Y ed è allora che diventa più difficile inserirli nella tua architettura. Tuttavia, non è impossibile, e se vogliono che il loro codice venga mantenuto, probabilmente avranno il miglio in più se, beh, è ​​solo un miglio.

Potresti anche prendere una posizione più arbitraria e decidere che sono consentite solo la lingua L e Stack S, ma poi otterrai alcune cose canaglia qua e là, quindi ti consiglio di ampliarlo un po '. Alcuni sistemi CI faranno miracoli con alcuni plugin, se i tuoi dipendenti sono disposti a scrivere un po 'di codice colla o alcuni script di configurazione per farli rientrare.

Dai alle squadre un po 'di libertà

È importante dare ai team la libertà di andare per capriccio e iniziare alcuni piccoli nuovi progetti con cose sperimentali. Li tiene in guardia e tu e anche te ti costringe a considerare queste tecnologie piuttosto che rimanere bloccate in una pila per sempre fino a quando non ti causano problemi.

Quindi assicurati di avere la possibilità di installare i propri sistemi per testare i loro progetti di animali domestici. Assicurati però che abbiano l'abitudine di parlarne con l'IT.

Parla con l'IT, coinvolgi

È molto meglio se i tuoi dipendenti sviluppano il riflesso di inviare una richiesta via e-mail all'IT e chiedono loro se possono impostare qualcosa per loro e adattarsi. Saranno rifiutati per la maggior parte del tempo, ma almeno c'è qualche nozione di controllo e di chi dovrebbe essere responsabile e dà all'IT una certa visibilità sulle richieste dei diversi team.

Una volta che i progetti raccolgono una massa più critica, puoi richiedere di nuovo e riconsidereranno. La comunicazione è fondamentale ed è necessario che i team di sviluppatori, consulenti, personale di supporto IT o chiunque abbia a che fare con il codice lavorino insieme. Nessuno di loro vuole programmi randagi, quindi è nel miglior interesse di tutti. È molto più semplice far rispettare le regole se le supportano da sole.

Non puoi fermare queste applicazioni "nascoste" perché le persone le fanno per risolvere i problemi del mondo reale. Tutto quello che puoi fare è aiutarli a farlo nel modo "giusto". E per "giusto" intendo far sì che le app possano essere mantenute dopo che la persona che le ha avviate ha lasciato. Ti consiglio di usare la lingua suggerita in Up o Out : ho bisogno che tu documenti dettagliatamente questo processo in modo che ogni Yahoo possa capirlo tra un anno da quando te ne sei andato. Aiuta a impostare il controllo della versione (e mostrare loro come usarlo), un wiki (per tenere note informali su come il lavoro viene effettivamente svolto) e un semplice sistema di tracciamento dei bug. Se vuoi rendere le cose davvero perfette, imposta l'integrazione continua su un server di riserva (se ne hai uno).

Vedrai l'enorme desiderio di integrazione di Excel (o almeno importazione / esportazione) perché tutte le scuole di business ora insegnano Excel ed è uno strumento importante utilizzato in molti corsi di business.

Sarbanes-Oxley e una legislazione simile al di fuori degli Stati Uniti, combinata con le leggi sulla privacy e le procedure e le politiche interne auto-imposte sulla privacy e sulla sicurezza sono il "martello" che può e spesso viene utilizzato per reprimere il fenomeno dell'ombra-IT.

Non appena le informazioni identificative personali del cliente o del dipendente (o qualsiasi dato che non si desidera divulgare) iniziano a circolare in questi fogli di calcolo, si verifica un incidente in attesa di verificarsi.

Allo stesso modo, non appena uno di questi progetti IT di skunkworks prende quel foglio di calcolo Excel e lo utilizza come i dati dietro un'app Web rivolta verso l'esterno che viene hackerato, avrai il tuo CIO e CEO che si precipitano nell'ufficio di chiunque abbia costruito quell'app in un fine settimana che viene a spiegare le conseguenze.

E poi c'è il problema che quando si guardano a questi sforzi moltiplicati per le centinaia (o migliaia) di dipartimenti in un'azienda Fortune 500, si scopre presto che la propria impresa ha oltre 100 database "master" di clienti. I tuoi clienti iniziano a lamentarsi di aver aggiornato le loro informazioni di contatto in un unico posto, ma è ancora obsoleto in altri 10, o che non sai nemmeno quanta attività fai con i tuoi grandi partner perché le informazioni sono distribuite su 10 ombra Database IT.

Tutto ciò dà origine a processi di conformità e audit onerosi che non sono divertenti per nessuno ma sono i fatti concreti della vita dell'IT in un ambiente aziendale.

Una buona strategia è quella di esaminare tutti i reparti che lo stanno facendo e fare in modo di spostare i loro investimenti nell'IT ombra in IT adeguati, argomentando che l'IT può raggiungere un'economia di scala e fare questo lavoro in modo più efficiente rispetto all'attuale modello skunkworks distribuito ad hoc. Questo può essere un duro lavoro in un ambiente in cui i vincoli del budget IT e la velocità di consegna hanno dato origine agli skunkworks in primo luogo, ma combinati con i rischi di audit / fiduciari possono fare un buon pugno di due.

La decisione di scrivere una nuova domanda si basa spesso su un'analisi costi-benefici della richiesta; così come il valore complessivo per l'azienda. Il tutto tenendo conto di molti altri driver come risorse IT disponibili, ambito della richiesta, obiettivi aziendali e direzione solo per citarne alcuni. Spesso una richiesta di un reparto specifico viene negata perché il direttore / direttore del dipartimento non ha mostrato un ROI ragionevole o semplicemente non segue il processo stabilito.

Indipendentemente dal motivo, il "dipartimento IT" è spesso il capro espiatorio, anche se la decisione era al di fuori del loro controllo. Pertanto, anche se la negazione della richiesta potrebbe non riflettere male sul reparto IT, la percezione è spesso completamente diversa.

Nonostante ciò, troverai applicazioni disoneste in quasi tutte le organizzazioni aziendali del mondo. Alcuni ben scritti e altri così bene, contengono codice che non avrebbe mai dovuto vedere la luce del giorno.

Mentre dovremmo fare tutto il possibile per soddisfare le esigenze dei nostri clienti interni, ci sono volte che semplicemente non possiamo. Quando ciò accade, cercheranno altrove per risolvere il loro problema.

Se il gruppo IT è attivamente coinvolto nel progetto, allora possiamo richiedere l'adesione ai nostri standard, aiutare il consulente a seguire le linee guida di codifica interne e comprendere le interazioni delle applicazioni con i nostri sistemi (database, rete, firewall, ...). Senza questo coinvolgimento saremo colti di sorpresa e passeremo molto tempo a cercare di capire perché i nostri sistemi di produzione non rispettano lo SLA.

Indipendentemente dal fatto che il dipartimento IT li perdoni e li supporti, può e avrà un impatto diretto in termini di supporto, impegni OLA e SLA su cui viene misurato qualsiasi reparto IT.

Sono vietati nella nostra azienda per questi motivi:

• Macro Excel protette da password in cui l'unica persona che conosce la password ha lasciato l'azienda,
• Essere ritenuto responsabile di segnalazioni errate scritte da persone inesperte perché è IT
• Ci viene chiesto di modificare un rapporto di cui non abbiamo mai visto o sentito parlare prima.

Capisco che può essere frustrante per gli utenti quando l'IT è occupato e potrebbero essere inclini a "farlo da soli". Ma l'IT non può essere ritenuto responsabile di cose che non sa nemmeno che esistono, e se nessuno è responsabile dell'IT generale, allora ci sono grandi problemi a venire.

Se c'è un problema qui è con il dipartimento IT.

Non c'è nulla di sbagliato nel consentire alle persone con conoscenze specializzate in ambito aziendale / di dominio di manipolare ed elaborare i propri dati.

Il dipartimento IT deve riconoscerlo e supportarlo. Fornendo interfacce riutilizzabili, fornendo dati in formati convenienti come EXCEL o Access DB e fornendo strumenti flessibili (COGNOS, Jasper Reports ecc.).

Il reparto IT deve anche ripensare le sue priorità: è lì per servire l'azienda, non per implementare la metodologia più recente, o per installare l'hardware più sexy.

Una frustrazione che molte aziende o reparti nelle aziende hanno è che i loro dipartimenti IT si mettono in mezzo e rendono difficile per loro svolgere il loro lavoro o fare nuove cose. Questo porta i dipartimenti, che si sentono come trattenuti dai criteri IT, a tentare di risolvere i propri problemi. La comunicazione è la chiave. Se i dipartimenti lavorano attorno all'IT, quello che hai davvero è un problema IT. L'IT non può permettersi di essere visto come un nemico. Le aziende, e in particolare i dipartimenti IT, devono rendersi conto che devono lavorare insieme invece che uno contro l'altro. Se i dipartimenti comunicano con il proprio personale IT (in particolare quelli che dovrebbero avere una supervisione) e dicono loro le loro esigenze e come stanno lavorando per risolvere i propri problemi, Almeno l'IT avrà la possibilità di aiutare a risolvere i problemi invece di scoprire dopo il fatto che si verifica una crisi. Mantieni l'IT nel giro.

C'è quasi sempre una valida necessità di questi strumenti speciali, siano essi applicazioni o fogli di calcolo. Un dipartimento IT ha due scelte. Possono essere abilitanti o disabilitanti. Nella mia esperienza, i disabilità perdono perché ostacolano le valide esigenze aziendali e diventano nemici comuni. Gli attivatori d'altro canto aiutano veramente un'azienda.

Ciò non significa che lo sviluppo finanziato dai dipartimenti dovrebbe avere un regno libero. Alcuni requisiti devono essere applicati, come i seguenti:

• Tutto il codice deve essere regolarmente impegnato in un sistema di controllo della versione gestito dall'IT. L'IT dovrebbe creare liberamente account e directory per renderlo possibile. L'IT potrebbe anche voler fornire alcune istruzioni.
• Tutto ciò che coinvolge PII (informazioni di identificazione personale), autenticazione, autorizzazione, crittografia, dati protetti dalla legge o dati che l'azienda ritiene critici deve coinvolgere ed essere approvato da un consulente IT. L'IT / il consulente dovrebbe fornire assistenza, biblioteche, ecc. Per proteggere adeguatamente l'azienda, consentendo allo stesso tempo lo sviluppo di app.
• I database primari dovrebbero essere protetti. A seconda del database, l'accesso in lettura dovrebbe essere relativamente facile da ottenere e l'accesso in scrittura più difficile. Potrebbe essere necessario che l'IT fornisca account, registrazione o controllo.

L'abilitazione ha molti vantaggi.

• L'IT impara di più su come soddisfare le esigenze dei propri clienti. Ciò porta a una migliore definizione delle priorità e condivisione.
• L'IT è visto come un amico e un vantaggio, piuttosto che un problema.
• Vengono soddisfatte le reali esigenze aziendali.
• I dati aziendali sono adeguatamente protetti perché è stato coinvolto l'IT, evitando la necessità di backdoor.
• Gli strumenti di deposito non vanno persi a causa del turnover e possono essere più facilmente trasferiti nell'IT, se necessario.

Non ho potuto fare a meno di identificarmi con te. Il problema che descrivi sembra essere universale, che abbraccia culture, lingue e continenti.

Le cose che puoi fare:

• Limitare la creazione di account di database , chiedendo l'approvazione di un supervisore. Costringerli a utilizzare un computer locale come server di database o scrivere le app in modo indipendente, ne riduce notevolmente l'utilità.

• Fai in modo che tutti gli stagisti delle carriere legate all'IT siano contratti solo attraverso l'IT .

• Limitare tramite la politica del sistema operativo l' installazione del software . Ogni installazione di software deve essere canalizzata attraverso l'help desk IT, che richiede l'approvazione di un supervisore. In questo modo l'installazione di qualcosa come MS Access, PHP, Visual Basic, ecc., Sarà più difficile passare inosservata.

• Emettere una politica in cui si afferma che ogni nuovo sviluppo, per ricevere supporto, deve essere scritto, diciamo Java, C #, C ++ o qualsiasi altro linguaggio che richiederebbe una ripida curva di apprendimento . In questo modo riduci l'universo delle persone con "una certa conoscenza della programmazione" per scherzare.

• I requisiti che le persone devono dare un'occhiata alle "soluzioni Excel" all'interno dell'azienda, poiché ciò riflette le esigenze IT dell'azienda.

• Implementazione di un data warehouse e di uno strumento di data mining e reporting intuitivo per l'utente finale . In questo modo riduci la necessità di piccole app personalizzate create internamente.

Ma: non una sola cosa che farai supererà una telefonata di un grande capo , chiamando il responsabile IT e chiedendogli di supportare l'app che ha fatto uno stagista.

Un modo in cui la mia azienda aiuta in questo tipo di situazioni è di non essere agnostico sulla lingua. Se vuoi che un'app / programma venga presa in considerazione, deve essere in una lingua a nostra scelta (java). Potremmo allungare un po 'le regole per alcuni JQuery o js, ​​ma dovrebbe essere un'applicazione ben composta che soddisfacesse un'esigenza critica. Non venire e dire "Ho questa app PHP che ho bisogno che tu ospiti per me" perché probabilmente ti verrà consegnato solo un foglio delle politiche.

È importante stroncare le cose prima che diventino troppo grandi, perché una volta che sei meglio avere qualcuno che puoi dedicare all'apprendimento o alla riscrittura. Perché una volta che quella grande parrucca di sopra decide che gli piace, probabilmente non ti libererai mai della mia esperienza.

L'arroganza di Geeks!

In molti casi gli utenti aziendali possono utilizzare gli strumenti per fare cose che le persone IT non comprendono. Questo non è perché sono intrinsecamente cattivi, ma perché conoscono il business, come funziona e come vorrebbero che funzionasse.

Ad esempio, una società di software ha sviluppato un'applicazione per ottimizzare (a costi) l'accesso ai feed di dati di mercato. Come ripensamento hanno fornito un plug-in Excel in modo che gli utenti potessero accedere all'ultimo prezzo delle azioni tramite un foglio di calcolo. Avanti veloce di un anno e quasi tutti i trader della società per cui ho lavorato avevano uno o più fogli di calcolo incredibilmente complessi a supporto della loro strategia di trading. Di tanto in tanto avrebbero avuto un problema con le macro e chiedevano aiuto a uno dei ragazzi IT, i più rifiutati (e si chiedono perché l'azienda ci odia!). Tuttavia, ho provato e mentre potevo risolvere problemi tecnici con vari parametri di funzione e riferimenti circolari, posso onestamente dire che non avevo il minimo indizio su cosa facesse effettivamente l'intero foglio di calcolo. Non perché fossero mal messi insieme o mal programmati, ma perché non avevo le conoscenze o l'esperienza per apprezzare la sottigliezza di ciò che i trader stavano cercando di ottenere. Inoltre, stimerei un progetto IT di oltre 5 anni per replicare la funzionalità di uno di questi fogli di calcolo in un linguaggio di programmazione "adeguato" come progetto IT standard.