Eu costumava trabalhar para uma empresa em que todos os aplicativos que fornecíamos levavam à pergunta: podemos exportar esses dados para o Excel?

Depois de um tempo, decidi que tinha que saber por que eles estavam obcecados com as exportações do Excel para tudo. Descobriu-se que muitos departamentos tinham uma pessoa que era especialista em Excel e poderiam escrever um aplicativo de análise de dados útil em pouco tempo. Esses aplicativos se espalhariam pelo departamento como um incêndio e nós, os técnicos, não fazíamos ideia de que eles existiam.

Por que eles não nos procuram primeiro? Porque havia uma reputação de que a equipe técnica tinha muito a fazer e, se eles pedissem, eles poderiam (se tivessem sorte) colocá-la na fila seis meses depois.

Essa não foi uma acusação injusta e eles nunca nos pediram para dar suporte a seus aplicativos do Excel, então ninguém achou que era um problema. Quando esses desenvolvedores do Excel saíram, eles sempre conseguiram encontrar alguém para buscá-lo.

Você poderia argumentar que isso significava que estávamos priorizando incorretamente, que um trabalho importante não estava sendo realizado. Mas eu diria que isso liberou os desenvolvedores mais bem pagos para fazer um trabalho mais difícil. O que pode doer?

Agora eu proibiria o software que atualiza o banco de dados que está sendo escrito fora da equipe de desenvolvimento. E eu me recusaria a dar suporte a aplicativos escritos fora da equipe de desenvolvimento. Mas eu não tentaria proibir todo o software de ser escrito pelo próprio negócio, e eu ficaria feliz em escrever exportações de dados para capacitá-los a fazê-lo (contanto que isso não exponha dados que eles não deveriam ver, obviamente ).

Acho que as pessoas estão perdendo o ponto geral aqui:

If you don't like all the custom development that's going on, forbidding it is solving the wrong problem - you should instead be asking why they're going around IT, not just telling them it's not allowed. Remember that you (IT) exist to help them do their job better, and that people don't use software because it's cool or neat or new, they use it because it solves a problem they have.

Por que esses aplicativos estão sendo criados em primeiro lugar?

Em todos os casos que vi, há um motivo comum:

Os grupos de negócios priorizam suas necessidades mais do que as mesmas necessidades são priorizadas no contexto de toda a empresa

O marketing é responsável apenas pelo marketing, por isso as iniciativas que beneficiam os seus objetivos parecem críticas para eles, sendo consideradas penugens para outros grupos e tendem a ser menos priorizadas quando se trata de recursos limitados como a TI. A priorização só entra em jogo quando eles querem usar um recurso compartilhado - se eles mantêm o projeto inteiramente dentro de seu próprio departamento, então apenas o chefe do departamento tem que se preocupar com o orçamento e o cronograma.

No entanto, não se pode esperar que você resolva quaisquer problemas que surjam desses aplicativos ou os apóie depois que o desenvolvedor original sair da empresa. Como outro post menciona, isso não impede que o grande chefe exija que você o apoie, mas se você ficar atento aos tipos de aplicativos ou processos personalizados que existem, você pode ter uma ideia de quando algo se torna crítico e você pode precisar se envolver para trazê-lo "in-house". Além disso, se algo estiver se conectando e modificando sistemas que estão sob controle de TI, a TI deve estar envolvida, apenas para garantir a segurança e a integridade de seus sistemas centrais - no entanto, se for algo confinado à área de trabalho de um usuário, por que proibir isso?

Mas aqui está algo para lembrar: Cada aplicativo personalizado desenvolvido fora da TI corresponde a uma necessidade que não é atendida pela TI . Pode haver uma boa razão para eles não serem atendidos - não uma prioridade na empresa, problema muito especializado, não tão bom quanto outras opções, linguagem personalizada que seus profissionais de TI não conhecem, etc - e a falta de envolvimento de TI pode ser legítimo, mas essas soluções foram criadas porque algum departamento tinha uma necessidade que a TI não podia (ou não) satisfazer.

Tente ajudá-los a resolver seus problemas e, se você não tiver tempo nem recursos, resolva-os por conta própria. Mandar uma linguagem que tenha uma curva de aprendizado íngreme, com o único propósito de manter as pessoas fora do seu negócio, serve apenas para melhorar a atitude elitista que a maioria dos usuários de negócios percebe ter, e no final, esse tipo de atitude de elite só leva a mais do mesmo problema, pois os usuários têm medo de abordar a TI e estão convencidos de que a TI não entende suas necessidades ou desejos. Abra o relacionamento - entender o que eles precisam é a única maneira de impedi-los de passar por você.

Deve-se também considerar o caso das empresas nas quais o departamento de TI contém pessoas incompetentes, enquanto o aplicativo oculto seria criado por um desenvolvedor habilidoso que tenha um cargo de não desenvolvedor dentro da empresa. Na minha experiência, esses casos são extremamente frequentes.

Imagine que você tenha um perfil duplo de um desenvolvedor de software e um contador. Você é contratado como contador porque essa foi uma oportunidade para você conseguir um emprego bem remunerado. Você vê rapidamente que seus colegas (e agora você) passam horas fazendo coisas repetitivas, o que pode ser feito em poucos segundos por um programa.

Você gasta algumas noites para escrever o aplicativo, que fará todo o trabalho. Você mostra em seu laptop pessoal para seus colegas, e eles o acham muito útil. Você quer instalá-lo nos PCs da empresa, mas deve ter o acordo do departamento de TI. Você pede, mas eles o rejeitam porque não apoiariam sua inscrição.

Não parece estúpido?

Além desse caso específico, o problema com o suporte não é muito diferente do que muitas empresas encontram com todo o software, mesmo um escrito no departamento de TI: se o departamento de TI não impõe as melhores práticas , o código será mal / não documentado, escrito por pessoas inexperientes que não se importam com manutenção e que deixaram anos atrás.

Para concluir, a questão principal é a rentabilidade . Se você, o departamento de TI, for solicitado a manter um aplicativo desenvolvido por um funcionário que não entende as regras mais básicas do desenvolvimento de software, não importa quão agradável seja essa tarefa, você ainda terá que fazer isso se isso trouxer muito dinheiro para a empresa . Ou você reescreve a partir do zero, se é a maneira mais barata de fazer as coisas.

Você não pode totalmente controlá-lo ...

Eu diria que você nunca pode controlá-lo totalmente, já que os funcionários sempre terão meios de produzir códigos maliciosos e espalhá-los por meios alternativos. Então, não há muito uso obcecado muito com isso, uma vez que você tenha elaborado e aplicado algumas regras e processos básicos, e tenha criado algumas ferramentas.

A idéia é que você torne tão atraente quanto possível que as pessoas respeitem essas regras e usem essas ferramentas, em vez de tornar impossível fazer coisas novas que elas não produzam nada.

Mas você pode criar um ambiente amigável ao código

Muitas empresas, muitas vezes muito grandes, fazem isso. Um bom exemplo é o Google, para o qual os representantes disseram que usam um único SCM para toda a empresa, para que todos possam monitorar e analisar outros códigos.

Recomendamos que você faça o seguinte:

• dê acesso público a algumas áreas do seu SCM,
• facilita a solicitação de acesso a integração contínua e a servidores de inspeção contínua,
• incentive as pessoas a criar trabalhos de criação para suas ferramentas.

O problema é, então, a proliferação de tecnologias. Obviamente, alguns preferirão usar o X ao invés do Y e é quando fica mais difícil tê-los em sua arquitetura. No entanto, não é impossível, e se eles quiserem que seu código seja mantido, provavelmente terão uma milha extra se, bem, for apenas uma milha.

Você também pode adotar uma postura mais arbitrária e decidir que apenas o idioma L e o Stack S são permitidos, mas, em seguida, você receberá algumas coisas desonestas aqui e ali, então eu recomendo ampliar um pouco. Alguns sistemas de CI farão maravilhas com alguns plugins, se seus funcionários estiverem dispostos a escrever um pouco de código de cola ou alguns scripts de configuração para que eles se encaixem.

Dê às equipes um pouco de liberdade

É importante dar às equipes alguma liberdade para ir em um capricho e começar alguns pequenos projetos novos com coisas experimentais. Isso os mantém na ponta dos pés, e você obriga a considerar essas tecnologias, em vez de ficar preso em uma pilha para sempre, até causar problemas para você.

Portanto, verifique se eles têm a capacidade de instalar seus próprios sistemas para testar seus projetos favoritos. Mas, certifique-se de que eles adquiram o hábito de conversar com a TI sobre isso.

Fale com a TI, envolva-os

É muito melhor que seus funcionários desenvolvam o reflexo de enviar uma solicitação de e-mail para a TI e perguntar se eles podem configurar algo para eles e acomodá-los. Eles vão se recusar a maior parte do tempo, mas pelo menos há alguma noção de controle e de quem deve estar no comando e dá à TI alguma visibilidade sobre as demandas de diferentes equipes.

Quando os projetos coletarem uma massa mais crítica, você poderá solicitar novamente e eles reconsiderarão. A comunicação é fundamental e você precisa ter suas equipes de desenvolvedores, consultores, equipe de suporte de TI ou qualquer pessoa que trabalhe com código para trabalhar em conjunto. Nenhum deles quer programas perdidos, por isso é do interesse de todos. É muito mais fácil impor regras se elas estiverem fazendo o backup delas mesmas.

Você não pode parar esses aplicativos "ocultos" porque as pessoas os fazem para resolver problemas comerciais do mundo real. Tudo o que você pode fazer é ajudá-los a fazer o caminho "certo". E por "certo", quero dizer, fazer com que os aplicativos possam ser mantidos depois que a pessoa que os inicia tenha saído. Recomendo usar o idioma sugerido em Up ou Out : < em> Eu preciso que você documente este processo em detalhes para que qualquer yahoo possa entendê-lo daqui a um ano depois que você sair. Ajuda com a configuração do controle de versão (e mostrando como usá-lo), um wiki (para manter notas informais sobre como o trabalho realmente é feito) e um sistema simples de rastreamento de bugs. Se você quiser tornar as coisas realmente boas, configure a integração contínua em um servidor sobressalente (se você tiver um).

Você verá o enorme desejo de integração com o Excel (ou pelo menos importação / exportação) porque todas as escolas de negócios agora ensinam o Excel e é uma ferramenta importante usada em muitos cursos de negócios.

Assim que as informações pessoalmente identificáveis do cliente ou do funcionário (ou quaisquer dados que você não queira divulgar) começarem a circular nessas planilhas, você terá um acidente esperando para acontecer.

Da mesma forma, assim que um desses projetos de TI pega essa planilha do Excel e a usa como dados de um aplicativo da Web voltado para o exterior que é hackeado, seu CIO e CEO invadirão o escritório de quem quer que tenha construído esse aplicativo em um fim de semana chegando para explicar as conseqüências.

Além disso, há a questão de que, quando você olha para esses esforços multiplicados por centenas (ou milhares) de departamentos em uma empresa da Fortune 500, logo descobre que sua empresa tem mais de 100 bancos de dados "mestres" de clientes. Seus clientes começam a reclamar que eles atualizaram suas informações de contato em um só lugar, mas ainda estão desatualizados em outras dez ou que você nem sabe quantos negócios você faz com seus grandes parceiros, porque as informações estão espalhadas por 10 shadow Bancos de dados de TI.

Tudo isso gera processos de auditoria e conformidade onerosos que não são divertidos para ninguém, mas são os fatos concretos da vida da TI em um ambiente corporativo.

Uma boa estratégia é examinar todos os departamentos que estão fazendo isso e fazer um caso para mover seu investimento em TI simples para TI, argumentando que a TI pode alcançar uma economia de escala e fazer isso funcionar de maneira mais eficiente. do que o atual modelo de skunkworks ad-hoc distribuído. Isso pode ser difícil de vender em um ambiente em que as restrições orçamentárias de TI e a velocidade de entrega deram origem aos skunkworks em primeiro lugar, mas combinados com os riscos de auditoria / fiduciários podem dar um bom one-two punch.

A decisão de escrever um novo aplicativo é geralmente baseada em uma análise de custo-benefício da solicitação; bem como o valor global para o negócio. Tudo ao mesmo tempo levando em consideração muitos outros drivers, como recursos de TI disponíveis, o escopo da solicitação, os objetivos e a direção dos negócios, apenas para citar alguns. Muitas vezes, uma solicitação de um departamento específico é negada porque o gerente / diretor do departamento não conseguiu apresentar um ROI razoável ou simplesmente não segue o processo estabelecido.

Apesar disso, você encontrará aplicativos maliciosos em quase todas as organizações de negócios do mundo. Algumas bem escritas e outras bem, contêm código que nunca deveria ter visto a luz do dia.

Embora devamos fazer tudo o que for razoavelmente possível para atender às necessidades de nossos clientes internos, há momentos em que simplesmente não podemos. Quando isso acontece, eles procurarão em outro lugar para resolver o problema.

Se o grupo de TI estiver ativamente envolvido no projeto, poderemos exigir aderência aos nossos padrões, ajudar o consultor a seguir as diretrizes internas de codificação e entender as interações e demandas dos aplicativos em nossos sistemas (banco de dados, rede, firewall,… ). Sem esse envolvimento, seremos surpreendidos e passaremos muito tempo tentando descobrir por que nossos sistemas de produção não estão cumprindo o SLA.

Se o departamento de TI tolera e dá suporte a eles ou não, eles podem e terão um impacto direto em termos de suporte, OLA e compromissos de SLA com os quais qualquer departamento de TI é avaliado.

Eles são proibidos em nossa empresa pelas seguintes razões:

• Macros do Excel protegidas por senha onde a única pessoa que conhece a senha saiu da empresa,
• Sendo responsável por relatórios incorretos escritos por pessoas inexperientes, porque é IT '
• Sendo solicitado a modificar um relatório que nunca vimos ou ouvimos antes.

Eu entendo que pode ser frustrante para os usuários quando a TI está ocupada, e eles podem estar inclinados a "fazer isso sozinhos". Mas a TI não pode ser responsabilizada por coisas que ela ainda não sabe, e se ninguém é responsável pela TI em geral, há grandes problemas pela frente.

Se houver um problema aqui, é com o departamento de TI.

Não há nada de errado em permitir que pessoas com conhecimento especializado em negócios / domínio manipulem e processem seus próprios dados.

O departamento de TI precisa reconhecer isso e apoiá-lo. Fornecendo interfaces reutilizáveis, fornecendo dados em formatos convenientes como EXCEL ou Access DBs e fornecendo ferramentas flexíveis (COGNOS, Jasper Reports, etc.).

O departamento de TI também precisa repensar suas prioridades - está lá para servir o negócio, não para implementar a metodologia mais recente ou instalar o hardware mais sexy.

Uma frustração que muitas empresas, ou departamentos de empresas, têm é que seus departamentos de TI atrapalham e dificultam o trabalho deles ou fazem coisas novas. Isso leva os departamentos, que sentem como se estivessem sendo retidos pelas políticas de TI, a tentar resolver seus próprios problemas. A comunicação é fundamental. Se os departamentos estão trabalhando com TI, o que você realmente tem é um problema de TI. Não pode se dar ao luxo de ser visto como o inimigo. As empresas, e especialmente os departamentos de TI, precisam perceber que precisam trabalhar juntos, em vez de trabalhar uns contra os outros. Se os departamentos se comunicarem com sua equipe de TI (especialmente aqueles que devem ter supervisão) e lhes disserem suas necessidades e como estão trabalhando para resolver seus próprios problemas, a TI terá a opção de ajudar a resolver problemas em vez de descobrir fato quando uma crise acontece. Mantenha a TI no circuito.

Quase sempre existe uma necessidade válida para essas ferramentas especiais, sejam elas aplicativos ou planilhas. Um departamento de TI tem duas opções. Eles podem ser facilitadores ou desabilitadores. Na minha experiência, os desestabilizadores perdem porque atrapalham as necessidades comerciais válidas e se tornam um inimigo comum. Os facilitadores, por outro lado, ajudam genuinamente um negócio.

Isso não significa que o desenvolvimento financiado pelo departamento deva receber o livre reinado. Alguns requisitos devem ser aplicados, como os seguintes:

• Todo o código deve ser regularmente confirmado em um sistema de controle de versão executado pela TI. A TI deve criar contas e diretórios para tornar isso possível. A TI pode até querer fornecer algumas instruções.
• Qualquer coisa envolvendo PII (informações pessoalmente identificáveis), autenticação, autorização, criptografia, dados protegidos por lei ou dados que a empresa considere críticos deve envolver e ser aprovado por um consultor de TI. O departamento de TI / consultor deve fornecer assistência, bibliotecas, etc. para proteger adequadamente os negócios enquanto ativa o desenvolvimento de aplicativos.
• Os bancos de dados primários devem ser protegidos. Dependendo do banco de dados, o acesso de leitura deve ser relativamente fácil de obter e escrever o acesso mais difícil. A TI pode precisar fornecer contas, registro ou auditoria.

A ativação tem muitos benefícios.

• A TI aprende mais sobre como atender às necessidades de seus clientes. Isso leva a uma melhor priorização e compartilhamento.
• A TI é vista como um amigo e um benefício, e não como um problema.
• As reais necessidades de negócios são atendidas.
• Os dados corporativos são protegidos adequadamente porque a TI estava envolvida, evitando a necessidade de portas dos fundos.
• As ferramentas de depósito não são perdidas devido ao volume de negócios e podem ser movidas com mais facilidade para a TI, se necessário.

Eu não pude deixar de me identificar com você. O problema que você descreve parece ser universal, abrangendo culturas, idiomas e continentes.

As coisas que você pode fazer:

• Restrinja a criação de contas de banco de dados , solicitando a aprovação de um supervisor. Forçá-los a usar uma máquina local como um servidor de banco de dados ou a escrever os aplicativos como independentes, diminui muito sua utilidade.

• Faça com que todos os estagiários de carreiras relacionadas à TI sejam contratados apenas por TI .

• Restringindo por meio da política do sistema operacional a instalação do software . Toda instalação de software deve ser canalizada através do help desk de TI, exigindo a aprovação de um supervisor. Dessa forma, a instalação de algo como o MS Access, PHP, Visual Basic, etc., será mais difícil de passar despercebida.

• Emita uma política afirmando que todo novo desenvolvimento, para receber suporte, deve ser escrito, digamos, Java, C #, C ++ ou qualquer outra linguagem que exigiria uma curva de aprendizagem íngreme . Dessa forma, você reduz o universo de pessoas com "um certo conhecimento de programação" para mexer.

• As pessoas requisitos devem dar uma olhada nas "soluções do Excel" em toda a empresa, porque isso reflete as necessidades de TI da corporação.

• Implementando um data warehouse e uma data mining amigável ao usuário final e ferramenta de relatórios . Dessa forma, você reduz a necessidade de pequenos aplicativos feitos internamente e personalizados.

Mas: nem uma única coisa que você faz vai superar um telefonema de um Big Chief , ligando para o Gerente de TI e pedindo que você suporte o aplicativo que um estagiário fez.

Uma maneira que minha empresa ajuda nesse tipo de situação é não ser agnóstico em termos de idioma. Se você quer que um aplicativo / programa seja considerado, ele precisa estar em um idioma de nossa escolha (java). Podemos esticar um pouco as regras para alguns JQuery ou js, mas seria necessário um aplicativo bem composto que atendesse a uma necessidade crítica. Não venha e diga "Eu tenho este aplicativo PHP que eu preciso que você hospede para mim", porque você provavelmente receberá uma folha de política.

É importante cortar as coisas antes que elas fiquem muito grandes, porque uma vez que você é melhor, tenha alguém que possa dedicar para aprendê-la ou reescrevê-la. Porque uma vez que aquela grande peruca no andar de cima decide que ele gosta, você provavelmente nunca vai se livrar disso na minha experiência.

A arrogância dos geeks!

Em muitos casos, os usuários de negócios podem usar as ferramentas para fazer coisas que as pessoas de TI não entendem. Isso não é porque eles são inerentemente ruins, mas porque eles conhecem o negócio, como ele funciona e como eles gostariam que funcionasse.

Por exemplo, uma empresa de software desenvolveu um aplicativo para otimizar (para o custo) o acesso a feeds de dados de mercado. Como uma reflexão tardia, eles forneceram um plug-in do Excel para que os usuários pudessem acessar o preço mais recente da ação por meio de uma planilha. Avanço rápido de um ano e quase todos os traders da empresa em que trabalhei tinham uma ou mais planilhas incrivelmente complexas para dar suporte à sua estratégia de negociação. De vez em quando eles teriam um problema com a macro e pediam ajuda a um dos técnicos de TI, a maioria recusava (e eles se perguntam por que a empresa nos odeia!). No entanto, tive um tempo e, embora pudesse resolver problemas técnicos com vários parâmetros de função e referências circulares, posso dizer honestamente que não tinha a menor idéia do que toda a planilha realmente fazia. Não porque eles estavam mal juntos ou mal programados, mas porque eu não tinha o conhecimento ou experiência para apreciar a sutileza do que os comerciantes estavam tentando alcançar. Além disso, eu estimaria um projeto de TI de 5 anos e mais para replicar a funcionalidade de uma dessas planilhas em uma linguagem de programação "adequada" como um projeto de TI padrão.