O novo projeto Hub2b

Este post eu considero como um dos mais importantes deste blog. É sobre oportunidades e futuro.

A primeira oportunidade que aproveitei depois de formado foi me tornar membro da AIESEC, aprender sobre liderança, desenvolvimento pessoal, fazer amigos, e realizar um intercâmbio.

Quando vim para a Índia para realizar o intercâmbio, tracei como objetivos melhorar o meu inglês, trabalhar com padrões de projeto em projetos reais, conhecer a visão de mundo do pessoal daqui, conhecer a cultura, trabalhar com novas tecnologias, e conhecer outros intercambistas de outras partes do mundo.

Atingir os objetivos (ainda quero mais disso), e algo mais (desenvolvimento web, pesquisas, viagens). Em uma conversa com o dono da empresa (Mr. Ajay), expus que gostaria de abrir uma empresa no Brasil, e nesta mesma conversa, ele falou que gostaria de vender o produto no mercado Brasileiro. Além da experiência com os intercambistas brasileiros estar sendo boa, o comportamento como empresário do Mr. Ajay é de disseminar o software EDI em outros países, pois as indústrias indianas ainda não assimilaram a necessidade e benefícios de uso de um sistema deste tipo.

Foi então que a oportunidade se concretizou: formar uma empresa para revender os produtos da EDISPHERE Software, além de estar aberto a desenvolver softwares próprios, na área de B2B (business to business, comércio entre empresas).

Em sociedade com o Ricardo Sponchiado, entramos nessa idéia e já estamos no mercado. Já nos colocamos na web, e já começamos a trabalhar na divulgação do produto e da empresa.

O nome do empreendimento é Hub2b, uma alusão ao conceito de Hub (Conector) descrito nos livros sobre o Steve Jobs (A cabeça do Steve Jobs, e A Biografia) – e que me chamou a atenção, e o B2B (Business to Business). Isto também considerando que o principal produto é um middleware (software conector) que conecta sistemas de várias empresas parceiras comerciais.

O site já está no ar, bem como a página do facebook e o twitter. Visite todos! E ao trabalho!

Visite o site e entenda a solução: www.hub2b.com.br
Curta a página do facebook: www.facebook.com.br/hub2b
Siga-nos no twitter: www.twitter.com/#!/hub2business

Projeto ERP – Automação Comercial

No meu último post sobre o projeto ERP em que eu trabalho/trabalhava, eu comentava que estávamos em um segundo ciclo do projeto, após homologações de TEF e PAF-ECF, e lidando com alguns problemas como documentação, gerenciamento de tarefas, análise, testes, controle de impacto de alterações, relação entre módulos e funcionalidades, e etc.

Pois bem, hoje venho aqui fazer uma análise do que fizemos e não fizemos enquanto eu participei deste projeto, tendo em vista que estou o deixando, para buscar novos rumos.

Então, analisando produtividade, o que fizemos desde o último post:
- Implantamos um controle de tarefas (alterações e bugs), integrando os setores de suporte, desenvolvimento e teste. Funcionamento: ok. Definição de sprints e priorização de tarefas.
- Liberação regular de versões para teste. Funcionamento: 75%. Infelizmente várias pessoas da empresa cedem facilmente à pressão dos clientes e disponibilizam as versões de teste aos mesmos, para uso em ambiente de produção apenas com teste de programador. Não fosse isto, seria a realização.
- Controle de versão de fontes de sprint. A cada início de versão de sprint, os fontes da sprint anterior são “congelados” (são copiados e é criado um versionamento em outra pasta), onde é possível alterar aquela versão sem disponibilizar novas funcionalidades em andamento. Funcionamento: 50%. Com isso, dois fontes são controlados, e os bugs devem ser corrigidos nas duas versões, dobrando o trabalho do programador, e facilitando a geração de problemas na migração de versões. Além disso, os bugs são lançados na sprint anterior (que não foi fechada, só é fechada quando é criada a próxima sprint além da atual), o que permite que o bug seja corrigido na versão anterior e na nova volte a ocorrer (isto raramente acontece, mas é possível).
- (desde o início do projeto): Desenvolvimento orientado a objetos, facilitando modularização. Preparação de componente web facilitando uma futura migração do sistema para a Internet. Sistema multi-tier, facilitando a escalabilidade do mesmo.

Pouquíssima coisa em todo este tempo, em relação ao que pode ser feito, sabendo que a reestruturação do sistema tem apenas 3 anos, mas que a empresa já passou por momentos de organização em relação à processos de desenvolvimento, o que não foi aproveitado neste projeto.

Deixo este projeto que trabalhei por cerca de 3 anos, aqui por estes dias, e espero que quem continuará mantenha as boas práticas e faça acontecer as melhorias necessárias.

Inovação começa com pequenas coisas

Como já escrevi aqui alguma vez, participo do desenvolvimento de um software de automação comercial para plataforma Desktop, na linguagem Pascal/Delphi.
Estávamos com alguns problemas relacionados a quantidade excessiva de itens de menu no nosso sistema, quando resolvi pesquisar e encontrar uma solução.
Infelizmente, a grande maioria de aplicações desktop utiliza um esquema de menus antigo, baseado nos primeiros esquemas de janelas de sistemas operacionais mais primários. vasculhando a internet, não consegui encontrar um componente de menu aceitável tanto na parte prática como na parte estética, o que me causou uma talvez frustração quanto a isto. Olha só como é a maioria dos sistemas:

Nosso sistema, cuja nova versão o desenvolvimento foi iniciado em 2008, já tomou para si o problema destes menus e incorporou uma idéia da Microsoft denominada Ribbon Bar. O Ribbon Bar é o mesmo das aplicações do pacote Office, e vem sendo largamente utilizado pelo mercado. Assim é o menu com Ribbon Bar:

Nós tivemos problemas, pois nosso sistema atingiu o limite de abas, e o componente disponível no Delphi não faz tratamentos interessantes, como abrir o menu para a esquerda por exemplo, o que nos causou problemas como o sumiço de alguns itens do menu.
Porém, lembrei-me que os melhores menus que vejo são os menus web, um conceito diferente do existente em aplicações desktop, por utilizar-se de parte gráfica avançada e focado em maior usabilidade.

Aí veio o estalo: vou colocar menus web num sistema desenvolvido em Delphi!

Algumas semanas de desenvolvimento, pesquisa, estudo, busca de templates, e terminamos desenvolvendo um menu web (sim, usando html, jquery, javascript!) integrado com uma aplicação Delphi pura (não é utilizada aquela versão de Delphi para apps de internet).
O HTML usado no menu é gerado dinamicamente pelo sistema (por causa das permissões de usuários), e ficou assim:

Isto é apenas um pequeno exemplo de inovação em uma empresa de software. Gera a possibilidade de futura migração para a web, uma vez que tudo está convergindo para a Internet.

C’ya!

Projeto Atual – ERP

Já escrevi um post a respeito do sistema ERP com o qual estou envolvido desde o fim de 2008/início de 2009.

Bom, já relatei num post anterior que não havia documentação nem análise detalhada, o manual estava sendo iniciado, etc, etc.. O controle de versão de saída de executáveis era um problema, bem como um gerenciamento de tarefas consistente (que estava iniciando).

Acredito que tenhamos resolvido grande parte destes problemas, como o controle de versão de saída de executável, o manual, o gerenciamento das tarefas, os testes pela parte do setor de Testes, e como o sistema já está sendo comercializado, o suporte também resolveu dar as caras.

Como desenvolvedor, NÃO estou plenamente satisfeito. Os erros de CONTROLE de desenvolvimento não resolvidos que vêm desde o início do projeto agora começam a surgir: a análise e a documentação falha de código começa a fazer falta agora, quando há a necessidade de fazer alterações e incrementos no sistema, até mesmo para novas funcionalidades.

Outro grande problema que surge agora é o controle de testes de código (que não foi utilizado) – o teste automatizado para o desenvolvedor, que agiliza o re-teste das funcionalidades já existentes, a fim de controlar o impacto de uma alteração no resto do sistema.

Alterações de nível considerável obrigam que testes sejam feitos sobre todo o sistema, tomando um tempo considerável em cada alteração, e facilitando a liberação de versões com erros ao usuário final.

OK:

Hoje a equipe possui dois (em determinados casos três) desenvolvedores/analistas. Um responsável pelo suporte. E um responsável pelos testes (quase sempre dois, pois o suporte auxilia nos testes). Sem considerar canais de suporte externos e comercial, que se mantém em contato direto com o usuário final e também de uma forma ou outra auxilia nos testes.

Controle de versão de fontes, controle de versão de saída do executável (release), reuniões para definição das alterações para cada release, manual operacional, controle de tarefas consistente, padrões de código e operações estão verdes! OK!

Futuro:

A documentação do código fonte, bem como da estrutura do sistema (relação entre módulos, relação entre operações e funcionalidades, etc), a análise, e o teste automatizado devem ser implantadas.

Hoje a documentação de código fonte e as análises estão sendo feitas, porém deixam a desejar em muitos casos. A necessidade de se obter uma consistência nestes tópicos é extrema.

A documentação da estrutura do sistema (relações entre módulos, relação entre operaçoes e funcionalidades), e também os testes automatizados para agilizar testes de alterações e diminuir erros de impacto, também são pontos que devem ser estudados. É necessidade para manter qualidade.

Existe um tópico muito interessante que nos acontece muito e que num próximo post talvez deverei comentar: como lidar com a mudança de prioridades e alteração de funcionalidades com o usuário final.
##
O sistema está aceitável no mercado. Sempre pode ser melhor.

while True do LetsGo;

Até a próxima!

Projeto Atual

Este ano de 2009 estive (e ainda estou, aqui em 2010) infiltrado no (re)desenvolvimento de um sistema ERP.

Este projeto foi contra todas as leis da física e todas as boas práticas de projetos que a gente lê e deve utilizar em um projeto como este. Foi um ano bem trabalhoso para uma equipe de 2 programadores (em alguns momentos 3), perdendo os cabelos por não ter análise, documentação e nem gerenciamento consistente de tarefas (pelo menos escrita em algum lugar) (as tarefas começaram a ser controladas há cerca de dois meses). Mas enfim terminamos a primeira fase homologando o TEF e o PAF/ECF. Quanto à testes, foram deslocadas algumas pessoas de outros setores da empresa para o que chamamos de testes de usuário leigo de uso do sistema. Há cerca de mais ou menos dois meses uma pessoa foi alocada para efetuar os testes no sistema, e continua.

Até esta primeira fase apenas o básico funcional do sistema foi desenvolvido, ou seja, a parte básica do sistema Retaguarda (cadastros e relatórios para o funcionamento básico), e o Frente de Caixa, para as vendas do sistema.

Agora as questões:

Por que a primeira fase demorou cerca de um ano para ser desenvolvida?

R.: Grande parte do atraso se deu por conta de retrabalho.  Sem um objetivo e uma visão de futuro definido, muita coisa teve de ser re-desenvolvida, durante o próprio desenvolvimento do sistema. Mas não foi apenas esse o problema. O módulo PAF/ECF sofreu alterações consideráveis também por causa das mudanças e alterações ocorridas no próprio Ato Cotepe 06/08, que nos pegou uma vez de surpresa. Fora isso, a obrigação de que havíamos de  homologar algum TEF para posteriormente homologar o PAF atrasou mais um pouco.

Por que não há documentação nem requisitos do sistema?

O sistema é uma nova versão de um sistema consistente que já está rodando nos clientes da empresa. Muito do que foi re-desenvolvido nesta nova versão já existia na versão anterior. Porém, o que foi re-desenvolvido foi TOTALMENTE re-desenvolvido, sem reaproveitamento algum de código do sistema anterior. A “falta de tempo” para escrever os requisitos do novo sistema não é justificável, uma vez que nos apoiaria e pegaríamos muito mais detalhes antes de começar o desenvolvimento de determinadas tarefas. A documentação do sistema foi falha da parte de todos no projeto, uma por não ter requisitos, outra por fazer planejamentos de rascunho e após terminar o desenvolvimento jogar o rascunho fora.

O controle de tarefas foi feito constantemente “na conversa”, e em sua grande parte mantido na cabeça de apenas uma pessoa. Há cerca de dois meses um sistema começou a ser utilizado para gerenciar as tarefas existentes.

O controle de versão foi utilizado desde a criação do primeiro arquivo do projeto. Outra coisa que foi definida no início do projeto foi a padronização de código fonte (pelo menos isso, hein).

Futuro:

O controle de versão de saída de executável começa a ser implantado agora, uma vez que o software não podia ser comercializado antes da homologação do PAF/ECF, e havia controle interno de versão disponibilizada para teste apenas.

A definição das alterações que farão parte de cada nova versão levada ao cliente será feita através de reunião com a equipe, e desta vez com prazo definido.

A documentação e análise de novos módulos deverá ser feita neste momento. Bem como o manual de utilização do sistema.

O sistema funciona e está consistente. Acredito que poderia ser melhor se tivéssemos seguido as boas práticas de projetos de sistema e desenvolvimento. Atualmente, grande parte do sistema está centralizado na cabeça de apenas uma pessoa da equipe (risco infinito). O sistema é feito em Delphi 2010, e não foi construído arrastando componentes na tela, é tudo via linha de código.

Ainda há um longo caminho a seguir, e não queremos repetir o que fizemos até agora. Ao leitor: faça diferente do que fizemos neste projeto, e poupará alguma dor de cabeça.

while True do LetsGo;

Este momento é de divisão de águas: primeira fase do projeto toda desorganizada, segunda fase do projeto aplicando boas práticas. E prá mim, é agora que começa o ano, depois do carnaval.