Proibindo ou controlando “TI oculta…” Quem deve escrever e manter aplicativos de software ad-hoc?


61

As empresas maiores geralmente têm o problema: não é possível gravar todos os programas que os funcionários desejam (para economizar tempo e otimizar processos) devido à falta de pessoal e dinheiro.

Em seguida, os programas ocultos serão criados por algumas pessoas com (pelo menos uma) experiência em codificação (ou por estudantes / estagiários baratos ...). Sob algumas circunstâncias, esses aplicativos aumentarão em importância e se espalharão de um usuário para um departamento inteiro.

Depois, há o ponto crítico: quem manterá o aplicativo, adicionará novos recursos, ...? E este aplicativo é crítico. É necessário. Mas o estagiário deixou a empresa. Ninguém sabe como isso funciona. Você só tem um monte de fontes e algum tipo de documentação.

Faz sentido tentar controlar ou proibir o desenvolvimento de aplicativos ad-hoc fora do departamento de TI (com exceção de coisas menores, como macros do Excel)?


3
Dependeria do meio ambiente. Você pode configurar o sistema operacional do local de trabalho de forma que apenas os administradores possam instalar um novo software. Você pode impedir o acesso a recursos relevantes no servidor (bancos de dados, sistema de arquivos) que esse software teria que acessar. Você pode fazer isso de maneira técnica, para que seja impossível, evite fornecer senhas, endereços IP e informações similares necessárias ou simplesmente torne a política da empresa e demitir todos os que não cumprirem. Eu já vi mais ou menos tudo isso.
224126 Thorsten

40
Mas se esses "programas ocultos" são realmente críticos e não podem ser implementados pelo departamento de TI real, o que você ganha ao proibi-los? Eles são críticos, afinal, então você simplesmente não pode se dar ao luxo de não tê-los. Talvez reestruture seu departamento de TI? Ou re-priorizar? Parece compreensível para mim que as pessoas hábeis são fazer as coisas fora do fluxo de trabalho normal, se disse fluxo de trabalho não responde ...
Andres F.

13
@ thorstenmüller Nesse momento, você acaba implementando programas ocultos como Fórmulas do Excel para uma ordem de magnitude de manutenção mais baixa do que o Excel VBA. Como a criação de planilhas do Excel é uma habilidade que muitos funcionários de escritório precisam, você não pode bani-la como qualquer plataforma de desenvolvimento mais adequada.
9119 Dan Neely

5
@ thorstenmüller O que quero dizer é que, não importa o que você tente fazer, quando as opções passam pelos canais, esperam vários dias (se não meses devido à burrocrazy), passam várias horas fazendo isso manualmente ou acabam com as políticas que as pessoas estão adotando. fazer o último. Supondo que você possa pará-lo é ilusório. O melhor que você pode esperar é ter um processo eficaz para encontrar e adotar essas ferramentas após o fato.
9119 Dan Neely

16
O que há de errado com 'pessoas comuns' automatizando seus processos de negócios? Contanto que esteja economizando tempo, o que provavelmente é, considero uma coisa boa . Se uma ferramenta de automação 'bagunçada' 'ad-hoc' em particular se tornar altamente dependente, pode valer a pena que os desenvolvedores escrevam uma versão sustentável. Na pior das hipóteses, eles precisam começar a fazer as coisas manualmente novamente quando os requisitos mudam, mas pelo menos já economizavam muito tempo!
Philip Philip

Respostas:


79

Eu trabalhava 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. Aconteceu que muitos departamentos tinham uma pessoa que era especialista em Excel e poderia escrever um aplicativo útil de análise de dados em pouco tempo. Esses aplicativos se espalhariam pelo departamento como um incêndio e nós, os técnicos, nem imaginávamos que eles existissem.

Por que eles não vieram até nós primeiro? Como havia uma reputação que a equipe técnica tinha demais para fazer e, se pedissem, poderiam (se tivessem sorte) colocá-la na fila seis meses depois.

Isso não foi uma acusação injusta e eles nunca nos pediram suporte aos aplicativos do Excel; portanto, ninguém realmente achou que era um problema. Quando esses desenvolvedores do Excel saíam, eles sempre conseguiam 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 argumentaria que isso liberou os desenvolvedores mais bem pagos para fazer um trabalho mais difícil. O que isso pode doer?

Agora eu iria proibir software que atualiza o banco de dados a ser 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 que todo software fosse gravado pela própria empresa, e alegremente escreveria exportações de dados para capacitá-los a fazê-lo (desde que isso não exponha dados que eles não deveriam ver, obviamente )


36
Eu trabalhei em um ambiente semelhante, e a reação do nosso departamento a esses 'aplicativos' sempre foi frustrante. Muitas das minhas faculdades no departamento de TI se sentiram ameaçadas por esses aplicativos por algum motivo, mas eu os vi como maravilhosos. Isso permitiu que os usuários do departamento detalhassem o que realmente PRECISAM, e quando esse único banco de dados do Access não estava funcionando para eles, eles poderiam apenas entregá-lo para nós e criaríamos uma solução SQL 'real' para suportar a mesma funcionalidade. Eu mataria por esse projeto novamente. Todos os requisitos eram conhecidos no primeiro dia em que começamos.
Graham

8
+1 Bem afirmado. Capacitar os usuários do nosso software deve ser uma das nossas maiores prioridades.
Steven Evers

Eu teria que concordar na maior parte com a sua resposta. Mas o ponto principal é que consultas mal escritas podem derrubar um servidor de banco de dados; mesmo se escrito em Excel ou Access. Uma vez, é necessário equilibrar os compromissos de SLA da TI com as necessidades dos negócios.
6113 Steve

@ Stephen: Sim. E é por isso que é melhor capacitar os usuários a fazer suas próprias coisas, em vez de permitir que eles produzam dados. Seja uma cópia diária dos dados somente leitura, ou as exportações do Excel ou uma DSL, depende muito das suas necessidades de segurança / SLA e dos requisitos de dados.
Pdr7

11
@mattnz: Eu recomendaria fortemente contra isso. Isso oferece às pessoas uma maneira de fazer com que a equipe técnica priorize seus problemas no restante dos negócios, apenas juntando algo e dizendo "Você pode ver por que isso não funciona?" Você já conheceu um desenvolvedor que poderia resistir a um desafio como esse?
Pdr7 Nov12

50

Eu acho que as pessoas estão perdendo o ponto geral aqui:

Se você não gosta de todo o desenvolvimento personalizado que está acontecendo, proibi-lo de resolver o problema errado - você deve perguntar por que eles estão pesquisando a TI, não apenas dizendo a eles que não é permitido. Lembre-se de que você (TI) existe para ajudá-los a fazer seu trabalho melhor, e que as pessoas não usam software porque é legal ou elegante ou novo, elas o usam porque resolve um problema que elas têm.

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

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

Grupos de negócios priorizam suas próprias necessidades mais altas do que essas mesmas necessidades são priorizadas no contexto de toda a empresa

O marketing é responsável apenas pelo marketing; portanto, as iniciativas que beneficiam seus objetivos parecem críticas para eles, embora sejam consideradas fluff para outros grupos, e tendem a ser priorizadas com menos recursos quando se trata de recursos limitados, como TI. A priorização só entra em ação quando eles querem usar um recurso compartilhado - se eles mantiverem o projeto inteiramente dentro de seu próprio departamento, somente o chefe do departamento precisará se preocupar com o orçamento e o cronograma.

Não há motivo para eu proibir esse tipo de desenvolvimento, dentro do razoável - ele diminui as restrições de recursos compartilhados (principalmente TI) e permite que cada grupo se capacite para resolver seus próprios problemas (como as pessoas versadas no Excel avançado são bastante comuns, como esse é um problema comum, a maioria dos departamentos possui pelo menos um).

No entanto, não é de se esperar que você resolva quaisquer problemas que surjam desses aplicativos ou dê suporte a eles após o desenvolvedor original deixar a empresa. Como outro postado menciona, isso não impede que o grande chefe exija que você o suporte, mas se você ficar de olho nos tipos de aplicativos ou processos personalizados disponíveis no mercado, poderá sentir quando algo se torna crítico e você pode ser necessário se envolver para trazê-lo "internamente". Além disso, se algo está se conectando e modificando sistemas que estão sob controle de TI, então a TI deve estar envolvida, apenas para garantir a segurança e a integridade de seus sistemas centrais - no entanto, se é algo confinado à área de trabalho do usuário, por que sentir a necessidade proibi-lo?

Mas lembre-se aqui: todo 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 seu pessoal de TI não conhece etc. - e a falta de envolvimento com a TI legítimas, mas essas soluções foram criadas porque algum departamento tinha uma necessidade que a TI não podia (ou não iria) satisfazer.

Tente ajudá-los a resolver seus problemas e, se você não tiver tempo ou recursos, deixe-os resolvê-los por conta própria. A obrigatoriedade de um idioma com uma curva de aprendizado acentuada, com o único objetivo de manter as pessoas fora do seu negócio, serve apenas para aprimorar a atitude elitista que a maioria dos usuários de negócios percebe que a TI possui e, no final, esse tipo de atitude de elite leva apenas 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 andar à sua volta.


2
Marcado com +1. Não vejo ninguém aqui mencionando o que tende a ser um grande problema com essas práticas que já vi em várias empresas. O que funciona para uma ou duas pessoas no curto prazo, rapidamente se transforma em uma enorme bagunça problemática de software de 30 aplicativos pequenos que cresceram ao longo dos anos, metade trabalhando e mantê-los é dez vezes o custo de se o departamento de TI contratasse pessoas para faça todos eles para que sejam consistentes e possuam uma base de propriedade central de TI.
Jimmy Hoffa

4
Como pessoa que trabalha como programador de "operações negativas", posso dizer-lhe que muitas vezes a TI não tem o conjunto de habilidades para entender as necessidades de um departamento técnico específico. Alguns de nossos programas mais críticos e inovadores começaram como programas "black ops". A TI não é um lugar onde a inovação é recompensada; inovação e experimentação geralmente significam muitos projetos com falha para cada um bem-sucedido. Depois que um programa de "operações negras" é bem adotado, geralmente é transferido para a TI para manutenção.
Bill

+1 Meus pensamentos exatamente, mas redigiram muito melhor.
Phil

16

Deve-se considerar também 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 possui um trabalho de não desenvolvedor na empresa. Na minha experiência, esses casos são extremamente frequentes.

Imagine que você tem um perfil duplo de desenvolvedor de software e 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 que podem ser feitas em poucos segundos por um programa.

Você passa algumas noites escrevendo o aplicativo, que fará todo o trabalho. Você mostra no seu laptop pessoal para seus colegas, e eles acham muito útil. Você deseja instalá-lo nos PCs da empresa, mas deve ter o acordo do departamento de TI. Você solicita, mas eles a rejeitam porque não suportam seu aplicativo.

Não parece estúpido?

Além desse caso em particular, o problema com o suporte não é muito diferente do que muitas empresas encontram com todo  o software, mesmo um escrito dentro do departamento de TI: se o departamento de TI não aplicar as práticas recomendadas, o código será mal / não documentado, escrito por pessoas inexperientes que não se preocupam com manutenção e que saíram anos atrás.

Para concluir, a questão principal é a lucratividade . Se você, 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 o quão agradável é essa tarefa, você ainda precisará fazê-lo, se houver. muito dinheiro para a empresa . Ou você o reescreve do zero, se for a maneira mais barata de fazer as coisas.


2
"Na minha experiência, esses casos são extremamente frequentes". - Então, sua empresa faz um trabalho incrível de contratar grandes programadores em trabalhos não programadores e, em seguida, programadores ruins em trabalhos de programação? Eu acho que é mais provável que alguém que não entende as práticas e os sistemas subjacentes pense que está escrevendo um software melhor. Apenas meus 2 centavos.
ominus

2
@ Minus: se houver uma vaga para um advogado, a empresa procurará um advogado; se o candidato também é um desenvolvedor habilidoso, o entrevistador pode nem saber disso. Portanto, não, a empresa não está "contratando grandes programadores em empregos que não são programadores": eles estão contratando uma pessoa qualificada para um trabalho, sem estar ciente de que essa pessoa também é um grande desenvolvedor.
Arseni Mourzenko #

@ Minus: note que quando você é contratado como, por exemplo, funcionário, não diz durante a entrevista que é um ótimo programador. Para muitas pessoas sem formação técnica, programador = hacker = cara que passará seu tempo quebrando os PCs da empresa = muitos problemas.
Arseni Mourzenko #

11
@Ominus - A empresa não precisa ser ruim em contratar pessoas de TI para ter um departamento de TI incompetente. Os departamentos de TI ruins podem ocorrer porque a TI é considerada "indireta" por alguém e reduzida na medida do possível. Isso os expande além de suas capacidades reais e eles se tornam incompetentes como organização - alternando constantemente entre tarefas, modo de pânico constante, sem se comunicar com ninguém, sem cumprir promessas.
22660 Michael Jackson

2
@Ominus: O que é mais provável aqui é que a empresa faça um trabalho igualmente bom de contratar ambos os tipos de funções, mas o grupo de TI está sobrecarregado com beurocracia, prioridades conflitantes e um sistema de gerenciamento de projetos que não funciona bem, sufocando inovação em vez de alimentá-la. Os técnicos nos trabalhos que não são de TI, uma vez notada sua habilidade, podem realmente se concentrar em uma tarefa, já que apenas o chefe de departamento está controlando seu tempo. As pessoas que realizam o trabalho real têm uma aceitação automática da inovação, enquanto o grupo de TI não tem a mesma perspectiva sobre as necessidades.
precisa saber é o seguinte

6

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

Eu diria que você nunca pode controlá-lo TOTALMENTE, pois os funcionários sempre terão meios para produzir código nocivo e espalhá-lo por meios alternativos. Portanto, não adianta muito ficar obcecado com isso, depois de elaborar e aplicar algumas regras e processos básicos e configurar algumas ferramentas.

A idéia é torná-lo o mais atraente possível para as pessoas respeitarem essas regras e usar essas ferramentas, em vez de tornar tão impossível fazer coisas novas que não produzam nada.

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

Muitas empresas, geralmente 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 o código de outros.

Eu recomendo que você faça o seguinte:

  • conceda acesso público a algumas áreas do seu SCM,
  • facilite solicitar acesso a servidores de integração contínua e inspeção contínua,
  • incentivar as pessoas a criar empregos para suas ferramentas.

O problema é então a proliferação de tecnologias. Obviamente, alguns preferem usar X em vez de Y e é aí que fica mais difícil ajustá-los à 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 os idiomas L e Stack S são permitidos, mas então você encontrará algumas coisas desonestos aqui e ali, por isso recomendo ampliá-lo um pouco. Alguns sistemas de CI farão maravilhas com alguns plug-ins, 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 alguma liberdade

É importante dar às equipes alguma liberdade para dar um capricho e iniciar alguns pequenos projetos novos com coisas experimentais. Ele os mantém alerta e você o força a considerar essas tecnologias, em vez de permanecer preso na pilha para sempre, até que isso cause problemas para você.

Portanto, verifique se eles têm a capacidade de instalar seus próprios sistemas para testar seus projetos de estimação. 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 se seus funcionários desenvolverem o reflexo de enviar uma solicitação de e-mail para a TI e perguntar se eles podem configurar algo para eles e acomodar. Eles ficam inativos na maioria das vezes, 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.

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


3

Você não pode parar esses aplicativos "ocultos" porque as pessoas os fazem resolver problemas de negócios do mundo real. Tudo o que você pode fazer é ajudá-los a fazê-lo da maneira "certa". Por "certo", quero dizer fazer com que os aplicativos possam ser mantidos após a partida da pessoa que os iniciou. Eu recomendo o uso da linguagem sugerida em Para cima ou Para fora : preciso que você documente esse processo em detalhes para que qualquer yahoo possa entendê-lo daqui a um ano depois de sair. Ajuda para configurar o controle de versão (e mostrar a eles 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 lisas, configure a integração contínua em um servidor sobressalente (se você tiver um).

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


3

Sarbanes-Oxley e legislação similar fora dos EUA, combinadas com leis de privacidade e processos e políticas de privacidade e segurança autoimposta internamente, são o "martelo" que pode e costuma ser usado para reprimir o fenômeno da TI sombria.

Assim que as informações de identificação pessoal do cliente ou funcionário (ou quaisquer dados que você não deseja divulgar) começam a circular nessas planilhas, você tem um acidente esperando para acontecer.

Da mesma forma, assim que um desses projetos de TI da skunkworks pegar essa planilha do Excel e usá-la como dados por trás de um aplicativo da Web voltado para o exterior, invadido por hackers, seu CIO e CEO entrará no escritório de quem criou o aplicativo. um fim de semana chegando para explicar as consequências.

E há o problema de que, ao analisar esses esforços multiplicados pelas centenas (ou milhares) de departamentos em uma empresa da Fortune 500, você logo descobre que sua empresa possui mais de 100 bancos de dados "principais" de clientes. Seus clientes começam a reclamar que eles atualizaram suas informações de contato em um local, mas ainda estão desatualizadas em outras 10, ou que você nem sabe quantos negócios faz com seus grandes parceiros, porque as informações estão espalhadas por 10 sombras. Bancos de dados de TI.

Tudo isso gera processos onerosos de conformidade e auditoria 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 defender os investimentos em TI de sombra na TI adequada, argumentando que a TI pode alcançar uma economia de escala e fazer esse trabalho com mais eficiência do que o atual modelo skunkworks distribuído ad-hoc. 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 fiduciários e de auditoria podem dar um bom golpe.


2

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 geral para os negócios. Ao mesmo tempo, levamos em consideração muitos outros fatores, como recursos de TI disponíveis, escopo da solicitação, objetivos de negócios e orientação, entre outros. Muitas vezes, uma solicitação de departamento específica é negada, porque o gerente / diretor de departamento falha em mostrar um ROI razoável ou simplesmente não segue o processo estabelecido.

Independentemente do motivo, o 'Departamento de TI' costuma ser o bode expiatório, mesmo que a decisão esteja fora de seu controle. Portanto, mesmo que a negação da solicitação possa não refletir mal no departamento de TI, a percepção geralmente é totalmente diferente.

Apesar disso, você encontrará aplicativos não autorizados em quase todas as organizações comerciais do mundo. Alguns bem escritos e outros bem contêm códigos que nunca deveriam ter visto a luz do dia.

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

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

Se o departamento de TI os tolera ou apoia, eles podem ou não ter um impacto direto em termos de suporte, compromissos de OLA e SLA pelos quais qualquer departamento de TI é medido.


1

Eles são proibidos em nossa empresa por estes motivos:

  • Macros do Excel protegidas por senha, onde a única pessoa que conhece a senha deixou a empresa,
  • Ser responsabilizado por relatórios incorretos escritos por pessoas inexperientes, porque é TI
  • Ser solicitado a modificar um relatório que nunca vimos ou ouvimos antes.

Entendo que pode ser frustrante para os usuários quando a TI está ocupada e eles podem estar inclinados a "apenas fazerem eles mesmos". Mas a TI não pode ser responsabilizada por coisas que ela nem sabe que existem, e se ninguém é responsável pela TI em geral, então existem grandes problemas pela frente.


5
Pelo que entendi, a TI existe para apoiar os negócios; não é o objetivo de ter um departamento de TI para ajudar as pessoas a fazerem seu trabalho? Como eles podem fazer seu trabalho bem, se você está proibindo-os de criar as ferramentas de que precisam? Não há nada de errado em dizer "Não nos responsabilize por esse relatório incorreto - alguém nas vendas o criou".
Phil

@ Phil - Concordou. A TI está lá para ajudar o negócio a funcionar, não para desempenhar nenhuma função por si só - ela não existiria se não permitisse que a empresa fizesse seu trabalho melhor, e tudo o que a TI realiza deve ser visto através das lentes de como o os negócios estão funcionando melhor por causa de seus esforços. Todo processo criado fora da TI corresponde a uma necessidade que a TI não está atendendo e bani-los cheira mais a insegurança. Não se pode esperar que você apoie processos que você não desenvolveu, e eu seria firme, mas recusar-se a reconhecer que essas soluções "desonestas" correspondem a necessidades reais é apenas teimoso.
SQlRyan #

11
Devo acrescentar que foram tomadas medidas para expandir o departamento de TI para atender a essas necessidades.
Paul T Davies

Embora a TI suporte os negócios, muitas vezes os negócios não suportam a TI. As empresas geralmente não respondem pelo tempo que a TI levaria para assumir ou aconselhar sobre planilhas ou aplicativos complexos desenvolvidos pelo usuário final. O efeito líquido é um departamento de TI com falta de pessoal. E todos sabemos como isso funciona.
Mike Sherrill 'Cat Recall'

1

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

Não há nada 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 - ele está lá para servir os negócios, não para implementar a metodologia mais recente ou instalar o hardware mais sexy.


1

Uma frustração que muitas empresas, ou departamentos de empresas, têm é que seus departamentos de TI atrapalham e dificultam o trabalho ou a realização de coisas novas. Isso leva os departamentos, que parecem estar 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. A TI não pode se dar ao luxo de ser vista como inimiga. As empresas e, especialmente, os departamentos de TI, precisam perceber que precisam trabalhar juntos em vez de se oporem. Se os departamentos se comunicarem com sua equipe de TI (especialmente aqueles que deveriam supervisionar) e informarem suas necessidades e como estão trabalhando para resolver seus próprios problemas, A TI pelo menos terá a opção de ajudar a resolver problemas, em vez de descobrir depois que uma crise ocorrerá. Mantenha a TI informada.


1

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 desativadores. Na minha experiência, os incapacitantes perdem porque atrapalham as necessidades comerciais válidas e se tornam um inimigo comum. Os facilitadores, por outro lado, ajudam genuinamente uma empresa.

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

  • Todo o código deve ser confirmado regularmente em um sistema de controle de versão executado pela TI. A TI deve criar livremente contas e diretórios para tornar isso possível. A TI pode até querer fornecer algumas instruções.
  • Qualquer coisa que envolva informações de identificação pessoal (IIP), autenticação, autorização, criptografia, dados protegidos por lei ou dados que os negócios considerem críticos deve envolver e ser aprovada por um consultor de TI. A TI / consultor deve fornecer assistência, bibliotecas, etc. para proteger adequadamente os negócios e, ao mesmo tempo, permitir 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 acessar com mais facilidade. A TI pode precisar fornecer contas, registro em log 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 um problema.
  • Necessidades reais de negócios são atendidas.
  • Os dados corporativos estão adequadamente protegidos porque a TI estava envolvida, evitando a necessidade de portas traseiras.
  • As ferramentas de departamento não são perdidas devido à rotatividade e podem ser movidas mais facilmente para a TI, se necessário.

0

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

O 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 servidor de banco de dados ou escrever os aplicativos para serem independentes, diminui bastante sua utilidade.

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

  • Restringindo via política do SO a instalação do software . Toda instalação de software deve ser canalizada pelo suporte técnico de TI, exigindo a aprovação de um supervisor. Dessa forma, a instalação de algo como 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, por exemplo , Java, C #, C ++ ou qualquer outra linguagem que exija uma curva de aprendizado acentuada . Dessa forma, você reduz o universo de pessoas com "um certo conhecimento de programação" para mexer.

  • O pessoal de requisitos deve dar uma olhada nas "soluções Excel" da empresa, porque isso reflete as necessidades de TI da corporação.

  • Implementando um data warehouse e uma ferramenta de mineração e relatório de dados amigável ao usuário final . Dessa forma, você reduz a necessidade de pequenos aplicativos personalizados, escritos por estagiários.

Porém: nem uma única coisa que você faz superará uma ligação telefônica de um Big Chief , ligando para o Gerente de TI e pedindo que ele ofereça suporte ao aplicativo que um estagiário fez.


sobre o ponto 1, aplicativos independentes podem ser uma grande ajuda no processamento de dados, mesmo sem um banco de dados; sobre o ponto 4, uma íngreme curva de aprendizado nunca impede alguém de escrever coisas quando está na base dele, cujo resultado será ainda pior para suporte, ou mesmo soemone dizendo "meh Eu não precisa deste aplicativo suportado"
catraca aberração

O ponto 3 sobre Restrição do SO não funciona. Muitas empresas já mudaram para o modelo "traga seu próprio laptop".
Sulthan

5
Concordo com o ponto 4 (esteja ciente de que ferramentas personalizadas podem refletir uma falta de resposta da TI), mas não com o restante. Medidas orientadas para restrições cheiram a burocracia. Na minha experiência, o resultado final é que as coisas não estão sendo feitas e, raramente, a TI se envolve de maneira eficaz. Por exemplo, "não, você não pode executar o X. Peça a um gerente e faça a aprovação". (resultado: X nunca é feito, aumenta nível de frustração)
Andres F.

0

Uma maneira pela qual minha empresa ajuda nesse tipo de situação é não ser independente da linguagem. Se você deseja que um aplicativo / programa seja considerado, ele precisa estar no idioma de nossa escolha (java). Podemos estender 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 esse aplicativo PHP que preciso que você hospede para mim" porque provavelmente você receberá apenas uma folha de políticas.

É importante beliscar as coisas antes que elas fiquem grandes demais, pois uma vez que é melhor você ter alguém que possa dedicar a aprendê-las ou reescrevê-las. Porque uma vez que a grande peruca lá em cima decide que ele gosta, você provavelmente nunca vai se livrar dela na minha experiência.


0

A arrogância dos geeks!

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

Por exemplo, uma empresa de software desenvolveu um aplicativo para otimizar (por custo) o acesso aos feeds de dados do 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 das ações 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 apoiar sua estratégia de negociação. De vez em quando, eles tinham um problema com a macro e pediam ajuda a um dos funcionários de TI, a maioria recusava (e se perguntam por que a empresa nos odeia!). No entanto, eu tentei 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 foram mal montados ou mal programados, mas porque eu não tinha conhecimento ou experiência para apreciar a sutileza do que os comerciantes estavam tentando alcançar. Além disso, eu estimaria um projeto de cinco anos, mais TI, para replicar a funcionalidade de uma dessas planilhas em uma linguagem de programação "adequada" como um projeto de TI padrão.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.