Lean TI - Analista negocios

211 visualizações

Publicada em

Lean TI Analista de Negócios de TI

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
211
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Lean TI - Analista negocios

  1. 1. 1 Lean TI ALS Lean TI Analista de Negócios Atuação Ativa e Não Reativa Ademar Leal da Silva Novembro 2015vida www.ademarlealsilva @blogspot.com.br
  2. 2. 2 Lean TI ALS O Analista de Negócios Motivação para elaborar este documento Durante os últimos anos refleti muito sobre os erros de sistemas, fracassos dos projetos e penso que grande parte deste caos é devido principalmente aos sistemas mal concebidos em seu inicio. O sistema que nasce errado dificilmente tem conserto. Constatei em observações que são muito poucos os analistas de sistemas que conseguem fazer uma concepção de projetos consistente de inicio ao fim. A maioria dos profissionais de TI tem pouca visão geral do todo e concebem sistemas que depois de implantado passa-se o resto da vida agregando funcionalidades para que o sistema cumpra com seus objetivos. Quando o sistema está completo com as funcionalidades operacionais já é uma colcha de retalhos com um sem numero de interfaces, que inviabiliza sua execução. Com este tipo de abordagem de TI, criamos a figura do Analista que com anos ou décadas de trabalho só desenvolveram um único sistema e ainda assim não ficou bem feito.
  3. 3. 3 Lean TI ALS O Analista de Negócios Motivação para elaborar este documento Com as novas tecnologias ganhamos muito em engenharia de software e hardware, mas perdemos muito em concepção. A maioria dos profissionais de TI , que estão na ativa são especialistas de manutenção ou de sistemas periféricos, e lhes falta experiência para conceber um sistema com todos os seus processos agregados. Temos que resgatar o Analista de Concepção, o verdadeiro Analista Sênior, aquele que sabe desenhar e projetar um sistema completo ,mesmo que seja desenvolvido em fases, mas que sabe exatamente o que o sistema vai fazer e ocmo vai fazer. Os próximos slides mostram a importância do Analista de Negócios na área de TI para conseguir conceber um sistema com menos risco de criar um problema para os outros
  4. 4. 4 Lean TI ALS O Analista de Negócios Papel que o Analista de Negocios desempenha no desenvolvimiento de Sistemas Sua principal função é prover solução funcional a um problema de negocio. Seu primeiro objetivo é entender o que o negocio quer e desenhar a a solução que satisfaça os requerimentos solicitados. No decorrer do projeto deve ser capaz de saber se o que está sendo desenvolvido irá satisfazer a expectativa do Negocio. A solução funcional Deve ser executada dentro dos prazos combinados. Deve ser executada dentro dos custos contratados. Deve ser cumprido o escopo e os objetivos acordados.
  5. 5. 5 Lean TI ALS O sistema e sua finalidade Um sistema somente tem sentido se agrega valor ao negocio, ou seja, se produz algo de valor para o cliente, se ajuda a vender mais, se ajuda reduzir custos, ou atenda a algum disposto lega. Um sistema que não se enquadra em nenhuma destas características, deve ser categoricamente descartado. Averiguar os Objetivos básicos do sistema O primeiro passo fundamental e imprescindível será determinar o que que o sistema irá produzir e para quem: Questões : Base de dados, usabilidades, Informação de Gestão, etc las salidas se Solución. Qual o valor que o sistema aporta, qual o ROI? O Analista deve saber que funcionalidades o Negocio necessita que seja atendida pelo Sistema farmacia Anatomía Patológica UTI Aplicações departamentais … Radiología Imagen digital Enfermaria Laboratorio Historia Clínica Solicitações Gestão Pacientes Sistema de Gestão Hospitalar
  6. 6. 6 Lean TI ALS Que informação alimentará o sistema Quando já se sabe quais são as saídas do sistema, o próximo passo será: saber onde estão as fontes de dados que vão alimentar o sistema para produzir as saídas desejadas: Integração com outros sistemas … Determinar os meios para a captura e integração com outros sistemas como e com que meios se produzirá a captura e Integração desses dados? Papel do Analista (Saber o que o negocio necesita)
  7. 7. 7 Lean TI ALS Transformar a informação de entrada em informação útil de saída Sabendo o que sai e que entra, a sequencia natural e saber como se processa a metamorfoses, ou seja o que fazer para que os dados de entrada (inputs) se transformem em informação de saída. Descrever todos os passos da transformação de entrada em informação de saída. Descrever todos os programas. Descrever todos los modelos. Muita Tecnología e complexidade mas tudo se resume em Papel do Analista (Saber o que o negocio necesita) Desenvolver a Analise Funcional Entrada Processamento Saída
  8. 8. 8 Lean TI ALS Cenário de uma área de Desenvolvimento que não utiliza uma Metodologia A cadeia de desenvolvimento é muito extensa, temos que interagir com muitas pessoas e muitos departamentos : Gerentes de projetos Analistas Funcionais Programadores Fornecedores Arquitetura Testes Produção Em cada um desses grupos existem pessoas com diferentes níveis de conhecimento e experiência. Uso de uma Metodologia? Funções e Cargos Idiomas Torre de Babel Torre de Babel
  9. 9. 9 Lean TI ALS Cenário de uma área de Desenvolvimento que sim utiliza uma Metodologia Porque? O uso de uma metodologia seja qual for não deve ser encarada como um capricho ou una exigência burocrática. Sem uma metodologia a homogeneização da documentação a comunicaçao entre os diferentes grupos que intervém no desenvolvimento de sistemas seria una torre de babel. Cada grupo faria a sua maneira e seria impossível o entendimento entre todos os envolvidos. Vantagens de usar una metodologia A metodologia unifica e normaliza a comunicação. Agiliza métodos de trabalho. Unifica os termos utilizados. Ajuda a estandardizar as soluções aplicadas. RESULTADOS Redução de custos. Redução de tempos. Melhores resultados. Delimita o escopo do projeto. Uso de uma Metodologia?
  10. 10. 10 Lean TI ALS Qualquer projeto de TI necessita una fase de: Levantamento de Requisitos Análise Funcional Desenho de Integração Construção Testes Implantação Existem vários modelos de trabalho: Somente uma pessoa faz todo o Projeto Uma equipe exclusiva faz todos os trabalhos do Projeto Um estrutura especializada que industrializa o software Vários equipes cada uma com uma responsabilidade Papel do Analista (Não confundir metodologia con técnicas de desenvolvimento) SCRUM, JAD, Método Iterativo, Análise Estruturada, Análise Modular etc, Técnicas para abordar um projeto Metodologia de Desenvolvimento Uma técnica de Desenvolvimento não é uma Metodologia Todas as fases são comuns para todos os tipos de projetos (seja para desenvolver um produto industrial, construir um avião, uma casa, ou um projeto de TI).
  11. 11. 11 Lean TI ALS ¿Qual é o melhor modelo de trabalho? Parece que depende de muitos fatores... O melhor modelo de trabalho é o que produz melhores resultados para a Empresa É necessário alguns cuidados: Não escrever muito, pois os usuários e nem ninguém entende especificações escritas com folhas e mais folhas de papel, o sistema para apresentação ao usuário deve ser prototipado para que o efeito visual ajude o usuário a validar o sistema. Com um protótipo o usuário saberá se o que vai ser desenvolvido é correto ou não. Todo o projeto grande dever ser dividido em projetos pequenos Papel do Analista (Não confundir metodologia con técnicas de desenvolvimento) Dividir o sistema em módulos que produzam algo tangivel para o usuario , no máximo a cada 4 meses, se for um mês muito melhor, e para cada módulo fazer: Requisitos Análise Funcional Desenho de Integração Construção Testes Implantação . Seja Scrum, Iterativo, Cascata, mas em hipótese alguma pode tardar Mais que 4 meses para implantar módulos reais que produzam resultados
  12. 12. 12 Lean TI ALS Capacidades do Analista Dominar a metodología: Todos os analistas devem dominar perfeitamente todas as tarefas de uma metodologia relativas a Elaboração de Requisitos, Analise Funcional, Desenho de Integração, Testes e implantação. Dominar os estándares de Arquitetura: Devem conhecer e dominar os estándares de arquitetura (formulários, desenho de telas, impressão, interfaces, usabilidade) e e representar as soluções estandarizadas. Dominar os servicios: Devem conhecer e dominar todos os serviços catalogados (tecnológicos, arquitetura e negócios) para reutiliza-los e devem criar novos serviços para futura reutilização. A produtividade está na reutilização e na estandardização assim de simples não existe nada mágico Papel do Analista (Uso de servicos estandarizados)
  13. 13. 13 Lean TI ALS A qualidade como solução A qualidade deve estar presente em todas as soluções de TI. Não se pode pensar em qualidade somente como o resultado dos testes finais. A qualidade deve ser preocupação em toda a cadeia de desenvolvimento desde o seu inicio. Relevancia das fases iniciáis do desenvolvimiento Seguramente o problema da qualidade dos projetos não está somente na construção mas também nas fases iniciais, levantamento de Requisitos e Analise Funcional. Quando o erro está na construção é mais fácil de consertar, mas quando o erro é de concepção fica muito difícil salvar o sistema. Papel do Analista (A qualidade da solução)
  14. 14. 14 Lean TI ALS Existem um conjunto de ferramentas e técnicas na fase de Fase de Requisitos que nos ajudam a aumentar a qualidade na hora de especificar uma boa solução para negócios. Papel do Analista (A qualidade da solução) Observação Tabelas de Decisão Fluxogramas Histogramas Diagrama de Espinha de Peixe Diagramas de Pareto 5W1H (What, Why, When, Who, Where,How) Es imprescindível que o Analista conheça estas ferramentais e técnicas Técnicas e ferramentas para o levantamento de Requisitos Análise de Valor Poka-yoke Custos e Benefícios da Solução Escrever e Comunicar UML
  15. 15. 15 Lean TI ALS A Analise Funcional é peça chave para o éxito de qualquer projecto informático. Com um bom desenho funcional tudo funcionará, tudo se implantará. Com um mal desenho funcional não se cobrirá as expectativas do usuários em prazos, nem em custos, e nem em funcionalidade. Papel do Analista (A qualidade da solução)
  16. 16. 16 Lean TI ALS Não complique a construção Papel do Analista (A qualidade da solução) Faça Programas Simples com somente uma função CRUD (Create, Retrieve, Update,Delete) Nunca use tecnologia desconhecida por sua equipe Re-utilize Rotinas e Serviços Telas Padronizadas Rotinas de Exceção Padronizadas Serviços Estandarizados Tudo Simples, se ficar complexo divida em partes Simples, fuja da complexidade Somente isto , a simplicidade é a chave
  17. 17. 17 Lean TI ALS Os testes são o meio de avaliação da qualidade do sistema Os teses funcionais são a fase final da qualidade. É na fase de testes onde se poderá ver a qualidade do sistema. Se deve pensar nas provas com antecedência , ou melhor dito , assim que começar o desenvolvimento já devemos fazer o plano de testes. Não devemos de esquecer os procedimentos e instrução para passar para a produção para que se executem conforme instruções. Outro fator importante a considerar é o ciclo de vida do sistema e dos dados, identificando períodos de retenção, políticas de expurgo, políticas de Backup, etc. Papel do Analista (A qualidade da solução) Marco de Proyecto Toma de Requisitos Proceso de Calidad
  18. 18. 18 Lean TI ALS Caso Pratico da Atuação do Analista Papel do Analista (A qualidade da solução)
  19. 19. 19 Lean TI ALS Imagine que somos um Seguradora e um usuário nos solicite uma solução como a que descrevemos em seguida: A solicitação: - Necessitamos desenvolver um sistema para suportar uma campanha comercial para oferecer a nossos segurados, que possuem uma apólice de automóvel e não possuem uma apólice residencial , condições especiais para que contratem conosco uma apólice de seguro residencial. - Iremos enviar-lhes uma carta comunicando a oferta com boas condições de contratação para o novo seguro de residencial. - O segurado poderá devolver-nos a carta assinada , ou aceitar as condições de contratação a través de Internet. - Para todos os segurados que aceitarem a oferta, se emitirá una apólice de residencial de acordo com as condições oferecidas. Caso práctico (Exemplo Fictício) “O analista deve projetar soluções completas considerando o sistema e os processos”
  20. 20. 20 Lean TI ALS Caso de Uso 1 - Preparar_Envio_Cartas Caso práctico (Solución habitual) Extrair Apólices de Residencial Extrair Apólices de Autos Selecionar Autos (sem Residencial Gerar Carta Internet Gerar Carta para Impressão Canal
  21. 21. 21 Lean TI ALS CU-2 Preparar_Nova_Apólice Caso prático (Solução habitual) Introduzir Dados no Sistema Canal Atualizar Datos Realizar Emissão Carta Aceitação Internet Aceitação Área de Digitação Sistema Área de Emissão Se o segurado aceitou a proposta por carta, damos entrada no sistema,se ele aceitou por internet, tb damos entrada no sistema Processamos as aceitações e emitimos as apólices
  22. 22. 22 Lean TI ALS O Analista deve fazer mais que a solução habitual Caso prático (Solução habitual) Embora a solução apresentada esteja perfeita já que foi exatamente o que o o usuário pediu....... Ela não é uma boa solução Porque ……. não está completa. O Analista deve oferecer mais. Sendo um técnico ele tem que identificar o que está faltando no sistema, que o usuário não pediu expressamente , mas são funcionalidades importantes que deverá fazer parte do sistema. Existem questões que o usuário não expressa mas que o Analista deve detectar, oferecendo um valor agregado a solução convencional.
  23. 23. 23 Lean TI ALS Completar o sistema O sistema deve contemplar o que o usuário não pediu e que é importante para a funcionalidade. Somente assim o sistema será completo, um bom analista não culpa o usuário dizendo que ele não sabe o que quer, mas ajuda-o a encontrar as falhas de sua solicitação . Un novo caso de uso de nosso exemplo. Sabemos que muitos dos segurados que receberam a carta não a responderão. Deveríamos propor que se realize uma nova execução recordando as condições da oferta para aqueles que não responderam a carta. Este processo poderá ser repetido quantas vezes for necessário Portanto, aparece um novo caso de uso que chamaremos de Caso de Uso 3 - Recordatorio Proatividade: Mesmo que o usuário não peça, devemos propor CU003_Recordatorio Caso prático (Valor Agregado da Solução )
  24. 24. 24 Lean TI ALS CU3_Recordatorio Selecionar Autos (sem residencial) y que não responderam Caso pratico (Valor Agregado ) CU001_ Enviar_ Carta Atentar que esta funcionalidade não requereu desenvolvimento Reaproveitou os módulos anteriores agregando uma seleção
  25. 25. 25 Lean TI ALS Está bem…..Mas .... Ainda falta funcionalidades importantes que o usuário não pediu… E que o Analista deve oferecer. Caso prático (Valor agregado )
  26. 26. 26 Lean TI ALS O que o usuário não ha pediu mas que deve ser feito… Para que o sistema não fique “incompleto” desde o ponto de vista funcional Situação não pedida pelo usuário : Sabemos que muitas cartas não chegam aos destinatários por diferentes motivos: Endereço errado ou incompleto Clientee mudou de endereço, etc. Então … Teremos que desenvolver um processo para fazer uma analise de todas as cartas devolvidas com o objetivo de atualizar o endereço. Faremos esta tarefa consultando outras fontes de dados ou chamando diretamente o segurado via telefone. Os endereços que não seja possível atualizar se marcará como endereço invalido com o objetivo de não voltar a enviar novas ofertas a este mesmo endereço. Posteriormente se destruirá as cartas devolvidas. Despois de atualizar os dados devemos a repetir os processos CU-01 y el CU-02. Caso prático (Valor agregado )
  27. 27. 27 Lean TI ALS Corrigir dados Introduzir Dados Sistemas Terceiros CU-04_Gestionar_Devolucão _Cartas Marcar cliente para envío CU001_Enviar_Carta Caso prático (Valor Agregado )
  28. 28. 28 Lean TI ALS Mas….. A solução ainda não está completa... O Analista deve oferecer as funcionalidades operacionais que o usuário não costuma pedir. Caso prático (Valor Agregado )
  29. 29. 29 Lean TI ALS Temos que pensar e oferecer as funcionalidades y facilidades operativas do sistema: Emissão de segunda via de uma carta-oferta especifica. Consultas sobre a situação das cartas ofertas enviadas. Eliminação de una oferta a pedido do segurado. Ajustes de uma oferta. Etc. Caso pratico (Valor agregado – funcionalidades operativas) Proatividade: Mesmo que usuário não peça, devemos propor Funcionalidades operativas
  30. 30. 30 Lean TI ALS Mas….. Mesmo assim, a solução não está completa… O Analista deve pensar y oferecer as funcionalidades de gestão que o usuário não costuma pedir. Caso prático (Valor agregado )
  31. 31. 31 Lean TI ALS Possivelmente: Quantidade de ofertas geradas Quantidade de ofertas aceitas Quantidade de ofertas recusadas Região • Territorial • Sucursal Averiguar que informação de gestão será necessária e quando deveremos ter-la: on-line Diario Semanal Mensal Como será o informe: Papel Cubo Tela Caso prático (Valor Agregado – funcionalidades de gestão) Proatividade: Mesmo que o usuário não peça devemos propor Funcionalidades de gestão
  32. 32. 32 Lean TI ALS Recapitulemos Mesmo concordando que o que temos até agora é suficiente para desenvolver o sistema e além disso foi o que o usuário nos solicitou, é importante saber que , para tomar una decisão adequada é necessário realizar um estudo de viabilidade técnica e económica que ajude a tomar a decisão. Sabemos que o custo total somente podemos obter depois da Analise Funcional Completa. Mas com um marco de projeto como o que foi apresentado , já se pode estimar com relativa segurança o esforço necessário para construir um sistema com estas características. Podemos deduzir que para cada uma das funções teremos pelo menos 4 operações (além das funcionalidades de gestão): Inclusão Alteração Eliminação Consultas Com estes dados se pode estimar os Pontos de Função para um estudo de viabilidade económica. É importante que se aprofunde sobre a viabilidade técnica do projeto, que inclui, entre outros, a volumetria, integração, rendimento y segurança, as quais também geram custos que afetam a viabilidade económica. Estes dados se obtém a partir da Analise Funcional. Caso prático (reflexões)
  33. 33. 33 Lean TI ALS Y mulitas coisas mais… Como é impossível saber tudo devemos : desenvolver a capacidade de saber quem sabe de cada coisa e buscar sua ajuda Mais Reflexões Capacidades do Analista de Negocios A função dol Analista é muito complexa : Deve saber de negócios de Informática de Gestão de Informática de Sistemas de Gestão de Pessoas de Matemática Financeira, Estatistica Saber redatar saber falar saber vender saber convencer saber negociar
  34. 34. 34 Lean TI ALS Objetivo Perguntamos : Com toda esta complexidade , Como podemos fazer bons sistemas ?... A resposta é muito simples , fazendo tudo mais simples. “o que quer o usuário é que se cumpra o orçamento de custos, prazos e alcance” ¿Como conseguir esto? Não é tão fácil , mas tampouco é tão difícil”. Como conseguir?: Utilizar soluções estándares (telas, interfaces, programas pequenos (CRUD) •Utilizar uma Metodología Utilizar os Poka-Yoke para evitar erros Reutilizar serviços catalogados Gerar Serviços para que sejam reutilizados, pense SOA Pensar, Lean – “Fazer certo da primeira vez.” fluxo continuo Soluções Simples Mais Reflexões ainda…
  35. 35. 35 Lean TI ALS O Analista não deve ser reativo Se ele fizer somente o que o usuário pediu o sistema ficará incompleto. O Analista deve conduzir o usuário para a melhor solução, não se deve restringir somente ao processo da Empresa, deve investigar soluções alternativas e inovações ser um agente inovador nos processos da companhia em que trabalha. Fazendo somente o que se pede, não mudará nada, tudo continuará na mesma com pequenas melhorias, as vezes é preciso romper com a situação atual e ter coragem de fazer tudo de novo em relação aos processos. Portanto é fundamental ser proativo e agente de mudança para construir sistemas admirados por outros Conclusões finais
  36. 36. 36 Lean TI ALS “É certo que nunca temos tempo de fazer corretamente as coisas corretamente, mas também é certo que sempre temos que buscar tempo para conserta-las depois” “Devemos mudar para fazer certo as coisas bem e completas na primeira vez para fazer uma coisa somente uma vez” Como dizia Einstein: “louco é aquele que fazendo as coisas iguais uma e outra vez espera resultados diferentes” “Temos que ser Analista de Negocio, Consultores de Negócios, temos que projetar soluções sempre completas, para poder fazer outras coisas, senão passamos a vida toda consertando coisas que fizemos errado .” Conclusão
  37. 37. 37 Lean TI ALS Obrigado pela Atenção Ademar Leal da Silva ademarleal197@gmail.com www.ademarlealsilva@blogspot.com As imagens foram Copiadas do google Desculpe pelos erros de português

×