As competências necessárias para um analista de sistemas – Parte 1

Segundo definição contida em Redação Brasil Profissões,  o analista de sistemas é:  aquele que tem como finalidade realizar estudos de processos computacionais para encontrar o melhor e mais racional caminho para que a informação virtual possa ser processada. Esse profissional estuda os diversos sistemas existentes entre hardwares (equipamento) e softwares (programas) e o usuário final, incluindo seus comportamentos e aplicações. A partir dessa conexão, desenvolve soluções que serão padronizadas e transcritas da forma que o computador possa executar. Os profissionais da área criam programas, que são executados em hardwares operados por usuários, preparados e treinados em procedimentos operacionais padronizados. Assim, cabe ao analista de sistemas, parte da organização, implantação e manutenção de aplicativos e redes de computadores.

Apesar de correta, a definição dada acima  pode ser considerada incompleta e desatualizada. Um analista de sistemas   atualmente nas grandes corporações precisam muito mais do que conhecimento técnico. Para ser completo o analista de sistemas precisar ter, basicamente, as seguintes competências: gerencial, negócio, técnicas – esta dividida em análise de sistemas e domínio sobre a tecnologia envolvida.  Graficamente as competências necessárias para um analista de sistema “completo” pode ser representado como que se segue:

No outro post  falaremos sobre cada uma destas competências.

E vocês, indicam alguma outra competência que um analista de sistemas deve possuir?

Sobre Requisitos…

 

Ao longo de minha vida, sempre comparei sistemas a pessoas. Pessoas nascem, atravessam um período atribulado e difícil (adolescência), amadurecem e um dia morrem. Sistemas também! Eles nascem, atravessam períodos em que apresentam muitos problemas (adolescência), estabilizam (maturidade) e, um dia, são retirados de operação (morrem). Assim como as pessoas, as primeiras fases do ciclo de vida de um sistema são as mais importantes. Elas vão determinar como será e como se comportará um sistema no futuro.

Um sistema “nasce” quando surge uma necessidade. Como todos já sabem, esta necessidade é, então, descrita em forma de requisitos. Recentemente, li uma pesquisa publicada pelo Gartner Consulting, que apontava como principal causa de fracassos e atrasos em projetos de TI, problemas com os requisitos de sistemas.

Em uma época, não muito distante, quando éramos analista-programador-operador-digitador-e-mais-alguma-coisa, tínhamos a oportunidade de sentar ao lado de nossos gestores e discutir/definir, quase que simultaneamente, os requisitos à medida que codificávamos e testávamos os sistemas. (que atire a primeira pedra quem nunca fez isso ou teve vontade de fazer!)

Apesar de vantajoso em algumas situações, este modelo apresentava muito mais desvantagens. Isso sem mencionar que os profissionais de sistema falavam uma linguagem própria, inteligível para o resto da organização. Surgiu, então, a necessidade de um profissional que soubesse interpretar as necessidades dos usuários e convertê-las em especificações para os analistas de sistemas. Este papel coube aos analistas de O&M inicialmente, que evoluíram para analistas de negócio. Este modelo persiste até os dias de hoje.

Ao refletir um pouco sobre a realidade de TI, neste contexto, gostaria de comentar:

1. Escrever requisitos de sistemas não é uma tarefa fácil (tentem definir os requisitos para um sistema que resolva Sudoku, por exemplo). Faz-se necessário um profissional com este tipo de perfil e que possua habilidades específicas para este fim;
2. Não existe uma boa notação (universalmente aceita) para a definição de requisitos. As implicações disso são enormes. Como determinar o nível de detalhamento ideal? Como escrever num só modelo, de tal forma que todos os envolvidos no projeto a compreendam? Como eliminar as ambigüidades dos requisitos? A questão fundamental na especificação resume-se ao “o que” e “como” descrever estes requisitos;
3. Os requisitos devem descrever não só o que o sistema deve fazer, mas também o que ele NÃO deve fazer. O intuito disso é limitar, com mais precisão, o escopo do projeto;
4.  Tão difícil quanto gerenciar um projeto é gerenciar a expectativa que este projeto gera sobre os envolvidos e a empresa. Mudanças nos requisitos quando o projeto já está em andamento, devem ser negadas ou negociadas. Se isso não for feito, corre-se o risco de se ter um projeto ad eternum;
5. Falta uma abordagem estruturada para esta atividade. O ideal seria que sua empresa  possuísse um processo bem definido para a especificação de requisitos, que pudesse ser monitorado, medido e aprimorado;
6. Não existe uma empatia entre os departamentos de sistemas e negócios (e isso não é uma exceção de nenhuma empresa que conheço no mercado). Constantemente reclamamos da qualidade dos requisitos que chegam até nós. Uma das soluções para este problema seria participar da elaboração destes requisitos juntamente com a área gestora e de negócios;
7. A validação dos requisitos, com todos os envolvidos, deve ser uma atividade obrigatória para todo analista de sistemas;
8. Acredito que o sucesso de um projeto está diretamente relacionado à clareza e qualidade de conteúdo da sua documentação inicial. Requisitos “bem escritos” aumentam as chances de um desenvolvimento com sucesso. Não basta ter uma documentação, ela também precisa ser eficaz.

 Os riscos, custos, tempo e qualidade de um sistema são diretamente proporcionais ao seu tamanho e complexidade. Em um trabalho que desenvolvi recentemente para a FIPECAFI/USP, observei que no começo de um projeto não existem muitas alternativas para validações dos requisitos de sistemas. Isso se torna um impasse e um dilema para os desenvolvedores: Como avaliar o sistema antes que os componentes-chaves sejam construídos? Depois de construído, mudanças no projeto são difíceis (se não impossíveis) de serem realizadas. Defendi, então, a utilização de protótipos para a validação desses requisitos.

Competitividade através de Ciclos Menores de Desenvolvimento

Nas últimas décadas, percebemos um aumento significativo na complexidade de produtos e serviços, motivado pelo amadurecimento das empresas e pelo crescente nível de exigência de seus clientes.  Simultaneamente, algumas tecnologias evoluíram para dar suporte a estas demandas. Outras, no entanto, acabaram por criar novas possibilidades, realimentando o ciclo de dificuldades, mudanças e oportunidades.

Neste mesmo período, embora ainda seja importante, a área da Tecnologia da Informação mudou seu papel e foi reposicionada no contexto de negócio das organizações.  Hoje, possuir alto grau de informatização, interno ou externo, não é mais um diferencial competitivo, e sim, um fator de sobrevivência da empresa.  Ser capaz de produzir e implementar sistemas no menor espaço de tempo, a custos reduzidos e com a menor margem de erros e de retrabalhos, é fundamental para fornecer o suporte necessário aos produtos e processos da organização. Tudo isso em um mercado altamente competitivo e globalizado. As empresas que perceberem e aceitarem essa nova realidade, certamente se posicionarão um passo à frente da sua concorrência.

Portanto, é fundamental procurar entender a contribuição da área de TI para a organização e para os seus clientes, assim como é fundamental para os executivos entenderem como a TI pode apoiar ou alavancar suas operações.

Comparada a outras áreas do conhecimento humano, a área da Tecnologia da Informação é relativamente nova. Começou como todas as outras, através de tentativas, eliminação de erros e manutenção dos acertos; mas numa velocidade muito maior.  A evolução no processo de desenvolvimento de sistemas permitiu que equipes de especialistas em software se dividissem em partes da tecnologia necessárias para produzir uma aplicação complexa. À medida que os projetos foram crescendo em tamanho e complexidade, o acúmulo de conhecimento e melhores práticas permitiu que as dificuldades técnicas fossem sendo superadas com relativa facilidade.  Entretanto, somente em anos recentes, percebeu-se que um dos maiores problemas da área de TI é o gerenciamento inadequado de projetos. A falta de metodologias, processos formais e sistemáticos, tem contribuído de forma significativa para a má qualidade do produto final e “estouros” nos tempos e custos de desenvolvimento.

A atenção para a gestão de projetos e utilização de metodologias formais ultrapassou os limites tradicionais somente em anos recentes. Já foram sugeridas várias abordagens para especificar, projetar e testar a construção de softwares para computador. Acredito que estamos atravessando um período de grandes transformações na nossa área, comparável à “crise do software” da década de 70, mas com foco na gestão de processos e projetos.

Em minha opinião, muitas metodologias fracassaram devido à complexidade das atividades; excesso de etapas e documentações geradas; e abordagens inadequadas para o problema. A decisão estratégica de algumas empresas em terceirizar atividades de apoio sem critérios e procedimentos bem estabelecidos também contribuiu para aumentar o índice de desacertos.

Num mundo onde a competitividade se mede em segundos, a agilidade exigida para a construção de sistemas deve ser suportada por uma metodologia coerente com a velocidade determinada pelo mercado. Assim como aconteceu com as indústrias automobilística e cinematográfica, as organizações deverão fazer uso da informática através de elevados graus de terceirização, com indicadores de qualidade, controles, monitoração e performance adequados, metodologias formais e com foco nos resultados e redução dos ciclos produtivos em seus processos.