Onde começa o ciclo de vida de uma aplicação…

Há mais ou menos 2 anos (um pouco mais ou um pouco menos…) eu ‘rompi’ a película que divide os “DEV-MAN” dos “BIZ-MAN”…

Comecei a atuar no “lado negro da força” (segundo os Dev que se acham Jedis! [sic]) … como Arquiteto de soluções focado em “Pré vendas de serviços”.

O maior desafio, no meu caso, foi ampliar a visão puramente técnica, cheia de restrições disso, restrições daquilo e o que é pior: A arrogância técnica de que a solução deve ser a mais “PERFEITA” com todas as novas tecnologias, boas práticas, patterns complicadérrimos… isso sem contar de que o código feito pelos outros é sempre uma “porcaria”… então eu pego e FAÇO TUDO DE NOVO, DO MEU JEITO e PONTO FINAL. [humpf] [sic] (acredite! estou falando de mim mesmo!)

ACONTECE que, por trás de um novo projeto tem sempre um “gerente comercial” cansado!

O ciclo de vendas de uma solução (projeto de software, como é o meu caso) é normalmente muito longo (não é como vender caixinhas, acreditem!)

O que faz um Pré-vendas? Especialmente um Pré Vendas que trabalha essencialmente com “Custom Development” ?

RESP: (de um técnico) …” ah.. fica aí fazendo ppt, usando o Word, usando o Visio pra fazer uns desenhinhos… nem lembra mais como usa o visual stúdio. fica enrrolando por ae, fazendo visitinha em cliente… pararí parará… “

Na verdade, toda essa introdução é para chamar a atenção para um assunto pouco discutido sobre ALM:

Quando começa a ‘vida de uma aplicação’ ?

Para uma empresa que VIVE de desenvolvimento de aplicações, o ciclo de vida começa BEM ANTES do “Deal”.

Na prática, mesmo para empresas que tem um time de desenvolvimento interno (empresas cujo o Core Business não seja desenvolvimento), o ciclo de vida de uma aplicação começa em uma oportunidade (ou demanda) que vira uma proposta que é negociada em termos de esfoço e prazo (custo/preço) em função das capacidades (ou funcionalidades/requisitos).

Isso me remete a algo que ouvi há mais de dois anos (quando estava no programa ‘Green badge’ lá na Microsoft):

    • You can’t propose without a price.
    • You can’t price without an estimate.
    • You can’t estimate without a plan.
    • You can’t plan without a work breakdown structure (WBS).
    • Therefore, you need a WBS to write a Proposal/SOW.

A elaboração de uma proposta é um trabalho de análise, que normalmente é feito com o menor tempo possível e com a melhor qualidade possível) para minimizar o ‘custo da venda’.

Considerando que a análise e o projeto de um sistema de informações devem ser conduzidos de forma sistêmica a fim de produzir uma especificação coerente e adequada às necessidades de negócio em específico na solução de um problema computacional (processo) bem delimitado (escopo) há de se considerar que o início desta tarefa é dado pela objetivação do sistema, ou seja, responder à seguinte questão: Por quê? Qual o motivo de existência do sistema? Qual o seu propósito? Quais são os ganhos em se criar o sistema?

A responsabilidade de obter a resposta para esta primeira indagação é do requisitante (quem precisa do sistema!). Isso normalmente é feito através da figura do “PATROCINADOR”, ou no termo inglês normalmente usado no mercado, SPONSOR.

Seguindo o conceito suscitado pelo termo (objetivo) esta declaração deve ser concisa e capaz de explicar a razão de existência do sistema em um único parágrafo.

O Objetivo do sistema deve nortear as demais fases da análise, projeto, desenvolvimento e estabilização de um sistema de informações.

A prática de mercado mostra que a falta de atenção a este item é o principal motivo de frustrações dos projetos de software posto que, isso provoca desvios enormes entre o que foi solicitado e o que foi entregue (com atraso, diga-se de passagem) ao solicitante.

Com os objetivos definidos, refina-se a análise determinando o seu contexto de aplicabilidade. O contexto deve informar ao analista quais são os macro-fluxos de entrada (input) e saída (output) necessários ao sistema em projeto.

É nesta fase que o analista poderá “sentir o cheiro da confusão”, ou seja, intuir sobre os riscos inerentes ao projeto ao definir as entidades externas (outros sistemas a serem integrados, usuários) que servirão de provedores ou consumidores dos dados desse sistema bem como seus canais de comunicação.

Pode-se , a partir do contexto, refinar a análise dos escopos menores determinando-se os eventos e suas expectativas de resultados mediante um conjunto especificado de entradas.

O conjunto de refinamentos sucessivos a partir da listagem dos eventos do sistema transpassam a fronteira da análise essencial para a análise comportamental do sistema onde devem ser detalhados (sucessivamente) seus componentes (estruturas de dados) e as formas de interação desses componentes (fluxos de processamento).

Para este fim, o analista se vale de técnicas, normalmente diagramais, como a criação dos diagramas de Entidade e Relacionamento (ERD), diagramas de fluxo de dados, Normalização de dados, especificações modulares, diagramas arquiteturais, etc.

Comparativamente, temos que este processo de análise essencial e comportamental, também conhecida como estratégia TOP-DOWN, é similar a um “vôo de águia” em situação de ataque.

Tal abordagem é ainda muito utilizada no mercado de desenvolvimento de software (ainda que de forma oficiosa ou habitual) e é, normalmente, encoberta na execução de análises Orientadas a objetos (com UML).

Normalmente divide-se um grande sistema em pequenas partes  para que os objetivos, ao se compor essas peças do “quebra-cabeças” num sistema completo que atenda aos objetivos propostos.

Esse ciclo todo é o que compreende a “PREPARAÇÂO” da proposta. A Proposta pode então, através de um ‘gerente comercial’ virar finalmente um DEAL, ou um CONTRATO…

E o que é necessário para ‘fazer uma aplicação nascer’ ?

A “Gestação” de uma aplicação, por assim dizer, é uma boa metáfora para o “Processo de venda”

A concepção se dá pelo encontro da “NECESSIDADE” (Business needs) com a “PROPOSTA” (que entre milhões de propostas, somente uma delas vira um DEAL”).

Para que a “Necessidade” encontre a sua “Proposta” ideal há todo um conjunto de condições que têm de ser satisfeitas.

Uma das coisas que tenho percebido nesses últimos anos é que uma proposta tem maiores chances de virar um “deal” se houver a conjunção de 3 fatores (atitudinais) inerentes (ou trabalhados) ao Arquiteto de soluções, a saber:

  • Alinhamento de negócios: basicamente, o arquiteto de soluções deve pensar como o CEO e CFO (orientar a solução para as necessidades do negócio com o menor custo possível)
  • Visão em perspectiva: A mesma “Dor” do cliente pode ser “sentida” de diversas formas diferentes pelos seus pares. Conseguir o máximo de informações possível de como “a falta ou deficiência de um sistema” dói nos diversos envolvidos é um fator decisivo para o  sucesso na conversão de propostas em um “contrato”
  • Comunicação: FALAR A LÍNGUA (ou o mesmo idioma) do cliente (e de todos os envolvidos do lado do cliente). Parece óbvio mas, de tão óbvio, não prestamos atenção (falando como técnico, mesmo!) nesse detalhe. (Hoje mesmo eu cometi esse tipo de gafe durante uma apresentação de proposta num cliente…)

De forma esquemática, a “concepção” de uma solução acontece a partir do cenário ilustrado abaixo:

image

Quando a proposta vira DEAL, ela (a proposta) é o documento formal que deve servir de base para gerar os requisitos, especificações detalhadas, workitens, product backlog, etc… que precisam ser gerenciados para que a solução planejada (e orçada) seja construída como foi proposto, no prazo em que foi proposto e com o custo (preço, na visão do cliente!) que foi proposto.

… o resultado disso é o que dá subsídio para a etapa seguinte  que culmina com o “trabalho de parto”  da aplicação.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s