Nesta fase das minhas memórias não vou tentar ser cronológico, nem muito específico ao trabalho na Seal; vou tentar falar de algumas coisas mais genéricas sobre trabalhar com software em empresas cuja atividade principal é vender hardware.
Devo destacar que a Seal sempre teve a visão de que a capacidade de desenvolver software para os seus equipamentos era uma vantagem competitiva e investiu bastante nisso. Muitas empresas estão longe disso, algumas preferem deixar o desenvolvimento de software para "parceiros" ou contratar "estagiários milagrosos" (true story). Mesmo assim, o software ficava em segundo plano, às vezes caindo para o nível do "mal inevitável", algo que só era encarado porque sem ele não sairia a venda dos equipamentos.
Um dos meu primeiros projetos de software na Seal (logo que entrei nos anos 90) foi um exemplo: não existia nenhum escopo bem definido ou orçamento. O software não estava sendo cobrado, era um verdadeiro brinde com os custos (desconhecidos) sendo cobertos pela margem de uma boa venda de equipamentos. Algo certamente compreensível para o início da atuação com coletores e o resultado final foi bastante bom tanto para a Seal como para o cliente.
Eu acompanhei o início da montagem do grupo de software (mas depois passei a me dedicar a outra coisas). Algumas linhas básicas de atuação foram definidas nesta época (mas nem sempre seguidas). Durante a negociação comercial era definido um escopo e uma estimativa de esforço, que eram a base para uma "proposta técnica". Fechado o negócio, era feito um detalhamento (a "Especificação Funcional Detalhada" ou EF). Somente após a aprovação da EF é que a codificação começava (para ser mais preciso, antes da codificação em si tem uma etapa implícita ou explícita de definição da arquitetura, estrutura de dados, etc - o chamado anteprojeto).
Aqui cabe um breve comentário sobre metodologias de desenvolvimento, principalmente para os apaixonados por "desenvolvimento ágil". Sim, o descrito acima é o hoje tão criticado "modelo cascata" (assim chamado por supor que as etapas se seguirão na ordem acima e onde movimentos em sentido contrário são custosos). Os principais problemas com esta metodologia estão relacionados às dificuldades em gerar uma EF correta e à falta de interação com o cliente durante a codificação; metodologias iterativas (onde são realizados vários ciclos de desenvolvimento até chegar no resultado final) resolvem estes problemas. Entretanto, no caso de projetos de escopo bem conhecido e curtos estes problemas são menores e o método cascata reduz as surpresas quanto ao esforço total e o prazo de desenvolvimento. A EF é também a vase para a validação final do software.
Portanto a etapa de detalhamento é vital para garantir que o que está sendo feito é o que o cliente deseja e evitar conflitos na hora da entrega. Infelizmente muitos clientes enxergam esta atividade como mera burocracia, lembro de pelos um que confessou que "assinou" o documento sem ler para garantir o início mais rápido da codificação.
E, de vez em quando, tinha os casos fora da curva. Uma vez, quando não estava mais no grupo de software, fui arrastado para uma reunião entre um dos analistas e um cliente para discutir um projeto que vinha cuja aceitação vinha se arrastando bastante tempo após a primeira de várias entregas. Alguns comentários do cliente, sobre a forma de operação, eram pertinentes, mas grande parte dos problemas se referiam a coisas que tinham sido omitidas durante o detalhamento. Após momentos tensos, chegou-se a um consenso sobre uma nova especificação. Quando finalmente parecia que estava encerrado, o cliente falou: "uma última coisinha, precisa incluir mais uma opção no menu...". Resumindo, ele queria colocar todo um segundo sistema dentro da aplicação! E conseguiu, pois o vendedor não aguentava mais as reclamações do cliente, que estava usando isso para segurar os pagamentos. E, feliz ou infelizmente, os custos do sistema todo (com todas as alterações posteriores) ainda era bem menor que o lucro com o hardware.
Nenhum comentário:
Postar um comentário