[OFF TOPIC] DE VOLTA
Aos amigos, aos colegas, aos colaboradores, aos visitantes, ao Webmaster:
Tenho andado em uma fase bastante agitada, desenvolvendo alguns projetos, voltando para casa (finalmente), terminando o quarto capÃtulo de meu livro e ainda participando de reuniões com certa regularidade. Dessa forma, não tem sobrado tempo suficiente para ao menos escrever umas linhas por aqui.
Mas não esqueci o site, não há como.
Para deixar uma "pontinha" de curiosidade em vocês, estou postando o prólogo do livro, ou o que couber dele, e o Ãndice.
"Depois de quase sete anos de lançada (1998), a tecnologia abrangida pela biblioteca Microsoft ActiveX Data Objects, ou simplesmente ADO, tornou-se unanimidade na preferência do desenvolvedor de sistemas que lidam com bases de dados. é bem verdade que essa preferência deu-se mais graças ao turbilhão que a Microsoft sempre gera ao lançar e impà 'r novos produtos ao mercado, mas a ADO possui, de fato, caracterÃsticas que a tornam muito superior ás bibliotecas DAO, apesar de não ser tão especializada quanto esta última.
O fator principal dessa superioridade é, talvêz, a capacidade de “abraçar†modelos de dados bastante variados, exigindo pouca ou até nenhuma alteração do código-fonte. Mas há outros fatores, pouco explorados até o momento, que tornam a ADO uma ferramenta Ãmpar ao desenvolvedor VB. Dentre esses fatores, podemos citar a facilidade no encapsulamento, o que possibilita a geração de objetos de negócio complexos e bem estruturados. O modelo DCOM também é um ponto de grande impacto, permitindo a transferência de dados de forma padronizada, sem perda na segurança das informações. E não se pode esquecer da capacidade de acesso desvinculado, que permite a criação de Recordsets totalmente desconectados, até mesmo de Recordsets totalmente virtuais, sem quaisquer vÃnculos com fontes de dados "fÃsicas". Com estes três pontos, o “poder de fogo†dos desenvolvedores VB se tornou muito maior, capacitando qualquer aplicação ao uso de metodologias antes só utilizadas por sistemas de grande porte, como o trabalho em três camadas, a geração de serviços de dados, módulos dinà ¢micos de pré-validação, bibliotecas de criptografia, aplicações de gerenciamento e administração remotos e tudo isso, com um único pré-requisito: Cuidados adequados na codificação.
E o quê, especificamente, isto significa? Imagine, por exemplo, sua aplicação ultrapassar as limitações do MS-Access®, que "teima" em transferir a base de dados inteira, sempre, seja com o uso do DAO ou do ADO, criando apenas um componente DCOM de serviços, sem acesso á disco, senão os feitos diretamente á base de dados, com quatro ou cinco nÃveis de proteção, integradas ou não ao sistema operacional, ocultando totalmente o acesso direto, mesmo com o uso do próprio MS-Access®, com capacidade de armazenamento acima dos 2GBytes e todos os trà ¢mites de RollBack e geração de logs de utilização por seção. Seria impossÃvel? Não! Aliás, com o ADO, tudo isso torna-se viável. Trabalhoso, mas viável e confiável.
E quais cuidados tão especiais são estes? Devemos tem em mente, sempre, que todo e qualquer projeto de sistema, pequeno ou grande, deve obrigatoriamente partir de um estudo de caso, passar por um processo de modularização intensivo, gerar seus gabaritos de dados, proceder á estudos de portabilidade e, apenas após esse trabalho haver sido terminado, de forma documental, é que se inicia a definição do projeto de codificação. Com base nas necessidades do conjunto de módulos, nos protótipos de dados gerados pelos gabaritos e na interface final desejada, define-se o conjunto de componentes e bibliotecas estritamente necessárias ao projeto de codificação, tomando-se atenção especial em gerar de forma prioritária todo o conjunto de funções de usuário.
Como você deve ter percebido, há todo um conjunto de procedimentos para que um produto, mesmo o mais simples, possa ser desenvolvido com a qualidade e confiabilidade que todos desejamos. E é só isso? Seguir apenas esses passos é a "chave do sucesso"? A resposta, como muitos já devem saber é: Não! Se houvesse um roteiro infalÃvel, com certeza ele jamais seria publicado. Se apenas um roteiro fosse garantia de sucesso, ninguém da área enfrentaria dificuldades, senão as comuns dúvidas técnicas.
Mas há ainda alguns outros pontos que são fundamentais para que um produto possa ser considerado uma boa ferramenta por um grande número de usuários. Vamos trabalhar com um único e simples sistema durante essa publicação, de forma que possamos explorar ao máximo em um tempo relativamente curto. Nosso “produto†será um cadastro de parceiros multi-função, que iremos batizar de CCM.
Mas voltemos aos passos necessários. Vejamos o quê, em linhas gerais, seriam as regras para um produto estável:
1 – Estudo de potencialidade: Encontrar, por meio de análise de mercado, um vácuo, uma lacuna, em têrmos de produto, que possa ser bem aproveitada por um bom número de pessoas e/ou empresas;
2 – Teorização indireta: Estudar esse mercado potencial, buscando abranger a maior quantidade de funções possÃvel, preferencialmente lidando com as necessidades de informação de forma direta, porém distanciada da visão de desenvolvimento. Assim, por exemplo, em se detectando no passo anterior, a necessidade de um cadastro de parceiros multi-função, precisamos saber com precisão o quê ele é, para quê ele serve, quem ele poderá ajudar (e de quais formas), como ele pode ser mais útil e rápido. Para obter essas informações, não basta apenas “entrevistar†usuários potenciais, mas preferencialmente, tornar-se um, “esquecendo†por alguns dias que se pretende criar a aplicação, mas vivenciando as necessidades.
3 – Análise de Parcerias: Após o passo 2, devemos partir para a fase de levantamento de parcerias. Mesmo que o produto seja pequeno, sempre haverá alguma empresa interessada em ser divulgada por seu produto, ou lhe fornecer suporte técnico para que o seu produto possa “casar†ou alavancar as vendas do produto do parceiro. Assim, por exemplo, desenvolver uma aplicação simples de cadastro de parceitos multi-função pode ser útil á vários setores, entre empresas de pequeno porte. Esse produto pode ter uma função especial de mensagens SMS, de forma que uma parceria com alguma operadora poderá ser importante ao produto CCM, mas também a distribuição do nosso CCM pode ser uma interessante “arma†de vendas para uma linha especÃfica de celulares da operadora, ou ainda, pode haver uma outra função para a gravação de imagens digitais, o que torna a parceria com uma empresa distribuidora de WebCams de baixo custo interessante, e da mesma forma, viabiliza a venda de uma quantidade maior de equipamentos da parceira. E mais: Apenas com essas duas funções “diferenciaisâ€ÂÂÂ, já teremos dois parceiros para o produto final, tanto para a divulgação quanto para a consolidação.
4 – Estratégia de Marketting: Já conhecemos o que será nosso produto. Já temos uma relação de parceiros. Já conhecemos o mercado potencial. O mÃnimo que podemos fazer com esse conhecimento é unÃ-lo em um portfólio rápido, agradável e moderadamente chamativo, o suficiente para que o produto seja vendável. As estratégias mais comuns demonstram as qualidades do produto e sua funcionalidade. Vamos um pouco além, se quizermos ser mais arrojados em nosso primeiro produto: Devemos mostrar e deixar claro aos futuros usuários que, sem nosso produto, eles estarão em desvantagem com relação aos demais. Uma vêz que a estratégia tenha sido definida, não se encarregue pessoalmente da tarefa de divulgação, de publicidade. Guarde essa base para que, mais tarde e com o produto já prototipado, você possa buscar seus parceiros comerciais e encarregar uma empresa especializada para essa tarefa. Mas mantenha-se firme em sua idéia de estratégia, exija e cobre essa idéia até conseguÃ-la. Isto também o ajudará inspirando maior confiabilidade de seus parceiros nos seus propósitos e objetivos.
5 – Desenvolvimento do Produto: Inicie os passos de desenvolvimento do produto, conforme já dissemos anteriormente, e que vamos ver em maiores detalhes mais adiante.
6 – Contatos Iniciais: Implemente as parcerias
7 – Estruturação de Atendimento: Crie uma estrutura de vendas e atendimento. é péssimo, até fatal, para a imagem de uma empresa receber pedidos de orçamento, ordens de serviço, pedidos de suporte etc e só os responder um ou dois dias depois. Mesmo que você esteja agindo sozinho, apenas com seu endereço comercial e um endereço eletrà 'nico, programe respostas automáticas em seu cliente de e-mail, em sua secretária eletrà 'nica, programe a transferência de chamadas ao seu celular pessoal, enfim, procure estar atento á toda e qualquer comunicação, respondendo-as da forma mais técnica, sucinta, rápida e precisa possÃvel. Atenção: Nunca se antecipe ás dúvidas do cliente, nunca responda nada além do que lhe fà 'r perguntado, nunca explique ou detalhe nada além do estritamente necessário. Isto, por alguns motivos: Apesar de parecer uma atitude de maior atenção ao cliente, na verdade ela toma tempo desnecessário, que nem sempre o cliente está disposto, ou pode perder. Informações técnicas dificilmente serão interpretadas pelo cliente da forma como você espera, e podem causar mais dúvidas ainda. Da mesma forma, detalhar tópicos não levantados pode expà 'r sua metodologia de trabalho, seu produto e mesmo encorajar concorrentes. Estes são alguns dos motivos pelos quais deve-se manter as respostas em um nÃvel total e estritamente profissional.
8 – Estruturação LogÃstica: Crie uma estrutura para distribuição de seu produto. Com os avanços recentes nas comunicações e a constante queda nos preços das tecnologias relacionadas, a distribuição On-Line não é uma alternativa cara, nem mesmo insegura. Muitos produtos, hoje, só podem ser adquiridos por meio da mÃdia de rede. Ainda assim, o produto deverá ser “empacotado†com o cuidado de possibilitar transferência rápida, preferencialmente em pequenos “pacotes†separados, possuir uma documentação de usuário robusta, uma segunda documentação, técnica, bem estruturada e ainda, uma terceira documentação, esta última relacionada ao produto como objeto de negociação (ou seja, contrato de direitos de uso, relação de funcionalidades elegiveis do produto, descritivo do ambiente mÃnimo necessário ao funcionamento do produto, formas de contato com você e/ou sua empresa, e até mesmo a documentação de instalação, contando ou não com o número serial do cliente para aquele download). Da mesma forma, além da distribuição, esta mesma estrutura deverá abranger o controle das vendas, de forma á manter todos os clientes efetivos, pagamentos, pendências, metas etc.
9 – Divulgação Principal: Implemente a estratégia de marketing. Preferencialmente deixe ao encargo das parcerias essa incumbência, mas fazendo questão, sempre, de acompanhar, supervisionar e cobrar os resultados, como já foi comentado.
10 – Divulgação Participativa: Incentive a adoção do produto. Contate alguns poucos clientes potenciais, escolhidos á dedo e com o cuidado de que sejam bem relacionados e estejam comprometidos em divulgar o produto, isentando-os total ou parcialmente dos valores de licença e/ou de manutenção/customização, por prazo fixo ou tempo indeterminado. Estes clientes serão, na verdade, seus Parceiros de Divulgação. Essa estratégia, se bem implementada, gera um retorno muito maior do que se pensa! O custo disto, sempre nosso, costuma trazer dividendos bastante interessantes. Bons parceiros de divulgação costumam render apresentação á novos clientes potenciais, participação em reuniões onde, apesar de não haver quaisquer necessidades de nossa presença, passamos á representar uma opinião neutra e balizadora sobre assuntos variados. Isto sempre representa custo para nós, posto que não haverá retorno em serviços imediatos destes encontros e apresentações. Porém, estaremos em uma posição privilegiada desde nossa introdução á novos clientes, de forma que seremos lembrados de forma quase automática, no momento oportuno.
Com esses “dez mandamentos†em mente, podemos facilmente deduzir que, além do desenvolvimento, uma área comercial e outra, financeira e de logÃstica, são sempre necessárias. Para uma empresa estabelecida, isto é comum. Para nós, mesmo que tenhamos um CNPJ, é mais complicado, por geralmente trabalharmos sozinhos e “independentesâ€ÂÂÂ. Mas esta também é uma situação contornável, como ficou claro, com a adoção desses procedimentos simples.
A intenção dessa explanação foi a de demonstrar que, apesar de ser o objeto que gera todo o processo, o nosso produto está longe de ser a peça central. Até mesmo a existência de bugs é secundária, quando uma boa metodologia de desenvolvimento é aplicada e as demais regras são seguidas. E isso tem sua lógica: Seu produto é útilizável, tem boa funcionalidade, bom desempenho e pode ser visto como uma boa ferramenta. Se você está visivelmente comprometido com seu produto, não importa realmente que ele tenha falhas, pois você os irá corrigir. Este fato deve estar sempre nÃtido e cristalino, tanto aos seus clientes quanto aos seus parceiros e até concorrentes. Não é á toa que o MS-Windowsâ„¢ é o produto, em software, mais utilizado no mundo. Enquanto outras empresas lançavam sistemas mais sólidos, mais robustos, mas sem quaisquer comprometimentos, a Microsoft nunca descontinuou definitivamente qualquer de seus produtos. Ainda hoje é possÃvel obter suporte para desenvolvimento em QuickBasic, MS-Visual Basic 1.0 e outras ferramentas, aplicativos e utilitários da gigante de Bill Gates. Isto gera confiança, que gera vendas, que gera divulgação, que gera nome, que gera confiança, que gera vendas etc etc etc...
Bem, como iremos começar nossa “jornadaâ€ÂÂÂ? Por se tratar apenas de uma publicação simples e com a pretensão de ser quase genérica, vamos pular alguns passos, como os de detectar o nicho de mercado e todos os demais passos que não sejam diretamente ligados ao desenvolvimento. Assim, vamos aos procedimentos da regra nº 5, Desenvolvimento do Produto. Serão, á partir de agora, pouco mais de quarenta partes, até chegarmos á conclusão do nosso projeto de exemplo. Para esse produto, estarei usando um produto meu, já devidamente registrado, o IO Systemsâ„¢ CCM.
Vale á pena lembrar que estaremos lidando com uma aplicação simples, sem grandes mistérios nem grandes aprofundamentos técnicos em modelagem DCOM, CORBA, Three Tiers etc, apenas lidando com a aplicação prática de alguns conceitos relacionados. Desta forma, apesar de abranger uma variedade razoável de assuntos, estaremos passando, na verdade, apenas as linhas gerais de todo o processo. Isto equivale á dizer que, apesar de utilizarmos o MS-Visual Basicâ„¢ como linguagem de desenvolvimento básica, os mesmos processos podem e devem ser repetidos com quaisquer outras linguagems de desenvolvimento orientadas á objetos ou com suporte á objetos que se possa utilizar, como o CA-Clipper, o MS-Visual Basic Dot Net, o Borland Delphi ou o Microsoft Delphi (até o momento ainda não “re-batizadoâ€ÂÂÂ), o MS-Visual Fox Pro, quaisquer Borland C e outras. Claro, as decorrências “naturais†para os desenvolvedores VB são o próprio VB.NET e/ou o C# e/ou o ASP.NET, mas para quaisquer outras que se tenha escolhido devemos seguir os mesmos critérios no desenvolvimento."
Aqui, segue o Ãndice, para quem tiver a curiosidade de saber o que está sendo colocado no livro.
1. Estudo de Caso
a. Conhecendo as Necessidades
b. Conhecendo os Problemas
c. Acrescentando Problemas
d. Acrescentando Funcionalidades
2. Modularização Intensiva
a. Análise de Modularização de NÃvel Grupo
b. Análise de Modularização de NÃvel Módulo
c. Análise de Modularização de NÃvel Função
3. Gabaritos de Dados
a. Estruturação dos Dados
b. Normatização
i. Definição de Dados
ii. Definição de Restrições
iii. Tabelas de Dados e de Suporte
iv. Definição de Relacionamentos
v. Definição de à Ândices
c. Comparação de Engines
d. Estudos de Portabilidade
e. Definição da Competência
f. Geração dos Módulos DBA
g. Geração dos Módulos DBS
h. Geração dos Módulos DBM
i. Componentes de Serviço(*)
4. Definição de componentes e bibliotecas
a. Definições de Trabalho
i. Ambiente de Desenvolvimento
ii. Ambiente de Testes
iii. Desenvolvimento Corpartilhado ou Comunitário
1. Usando Ferramentas de Desenv. Compartilhado
2. Usando o Bom Senso
b. Projeto de Codificação
i. Interface ( Parte 1 )
ii. Componentização – Controles de Usuário
iii. Interface ( Parte 2 )
iv. Funções Básicas
v. Funções Comuns
vi. Funções de Usuário
1. Componentização – Bibliotecas de Processos
2. Componentização – Bibliotecas de Funções
3. Componentização – Bibliotecas de Diálogos
4. Geração dos Componentes de Serviço(*)
vii. Codificação de Interação do Aplicativo
1. Módulos
2. Formulários
c. Documentação
i. Definição de MÃdia
ii. MÃdia com RAV
iii. Documentação de Funcionalidades
iv. Documentação de Operação
v. Ajuda de Contexto
vi. Documentação Técnica
vii. Documentação de Instalação
viii. Documentação de Garantias e Restrições
ix. Documentação de Direitos e Obrigações Contratuais
x. Documentação de Contatos e Suporte
d. Embalagem
i. Pacotes de Instalação
ii. Pacotes Complementares
iii. Pacotes de Aditivos de Suporte
iv. Pacotes de Atualização
v. Pacotes de Desinstalação
vi. Pacotes de Validação de Licença
vii. Embalando a Embalagem
viii. MÃdia de Distribuição
Na verdade, estou finalizando o 4.b.i, Interface Parte I, o que, para mim, já é bastante coisa, uma vez que venho escrevendo esse livro aos "picadinhos", no tempo livre, há dois anos e meio. Ano passado foi o que rendeu mais.
Assim que eu começar a recuperar o fà 'lego, estarei de volta com vocês. E, na medida do possÃvel, colaborando.
Tenho andado em uma fase bastante agitada, desenvolvendo alguns projetos, voltando para casa (finalmente), terminando o quarto capÃtulo de meu livro e ainda participando de reuniões com certa regularidade. Dessa forma, não tem sobrado tempo suficiente para ao menos escrever umas linhas por aqui.
Mas não esqueci o site, não há como.
Para deixar uma "pontinha" de curiosidade em vocês, estou postando o prólogo do livro, ou o que couber dele, e o Ãndice.
"Depois de quase sete anos de lançada (1998), a tecnologia abrangida pela biblioteca Microsoft ActiveX Data Objects, ou simplesmente ADO, tornou-se unanimidade na preferência do desenvolvedor de sistemas que lidam com bases de dados. é bem verdade que essa preferência deu-se mais graças ao turbilhão que a Microsoft sempre gera ao lançar e impà 'r novos produtos ao mercado, mas a ADO possui, de fato, caracterÃsticas que a tornam muito superior ás bibliotecas DAO, apesar de não ser tão especializada quanto esta última.
O fator principal dessa superioridade é, talvêz, a capacidade de “abraçar†modelos de dados bastante variados, exigindo pouca ou até nenhuma alteração do código-fonte. Mas há outros fatores, pouco explorados até o momento, que tornam a ADO uma ferramenta Ãmpar ao desenvolvedor VB. Dentre esses fatores, podemos citar a facilidade no encapsulamento, o que possibilita a geração de objetos de negócio complexos e bem estruturados. O modelo DCOM também é um ponto de grande impacto, permitindo a transferência de dados de forma padronizada, sem perda na segurança das informações. E não se pode esquecer da capacidade de acesso desvinculado, que permite a criação de Recordsets totalmente desconectados, até mesmo de Recordsets totalmente virtuais, sem quaisquer vÃnculos com fontes de dados "fÃsicas". Com estes três pontos, o “poder de fogo†dos desenvolvedores VB se tornou muito maior, capacitando qualquer aplicação ao uso de metodologias antes só utilizadas por sistemas de grande porte, como o trabalho em três camadas, a geração de serviços de dados, módulos dinà ¢micos de pré-validação, bibliotecas de criptografia, aplicações de gerenciamento e administração remotos e tudo isso, com um único pré-requisito: Cuidados adequados na codificação.
E o quê, especificamente, isto significa? Imagine, por exemplo, sua aplicação ultrapassar as limitações do MS-Access®, que "teima" em transferir a base de dados inteira, sempre, seja com o uso do DAO ou do ADO, criando apenas um componente DCOM de serviços, sem acesso á disco, senão os feitos diretamente á base de dados, com quatro ou cinco nÃveis de proteção, integradas ou não ao sistema operacional, ocultando totalmente o acesso direto, mesmo com o uso do próprio MS-Access®, com capacidade de armazenamento acima dos 2GBytes e todos os trà ¢mites de RollBack e geração de logs de utilização por seção. Seria impossÃvel? Não! Aliás, com o ADO, tudo isso torna-se viável. Trabalhoso, mas viável e confiável.
E quais cuidados tão especiais são estes? Devemos tem em mente, sempre, que todo e qualquer projeto de sistema, pequeno ou grande, deve obrigatoriamente partir de um estudo de caso, passar por um processo de modularização intensivo, gerar seus gabaritos de dados, proceder á estudos de portabilidade e, apenas após esse trabalho haver sido terminado, de forma documental, é que se inicia a definição do projeto de codificação. Com base nas necessidades do conjunto de módulos, nos protótipos de dados gerados pelos gabaritos e na interface final desejada, define-se o conjunto de componentes e bibliotecas estritamente necessárias ao projeto de codificação, tomando-se atenção especial em gerar de forma prioritária todo o conjunto de funções de usuário.
Como você deve ter percebido, há todo um conjunto de procedimentos para que um produto, mesmo o mais simples, possa ser desenvolvido com a qualidade e confiabilidade que todos desejamos. E é só isso? Seguir apenas esses passos é a "chave do sucesso"? A resposta, como muitos já devem saber é: Não! Se houvesse um roteiro infalÃvel, com certeza ele jamais seria publicado. Se apenas um roteiro fosse garantia de sucesso, ninguém da área enfrentaria dificuldades, senão as comuns dúvidas técnicas.
Mas há ainda alguns outros pontos que são fundamentais para que um produto possa ser considerado uma boa ferramenta por um grande número de usuários. Vamos trabalhar com um único e simples sistema durante essa publicação, de forma que possamos explorar ao máximo em um tempo relativamente curto. Nosso “produto†será um cadastro de parceiros multi-função, que iremos batizar de CCM.
Mas voltemos aos passos necessários. Vejamos o quê, em linhas gerais, seriam as regras para um produto estável:
1 – Estudo de potencialidade: Encontrar, por meio de análise de mercado, um vácuo, uma lacuna, em têrmos de produto, que possa ser bem aproveitada por um bom número de pessoas e/ou empresas;
2 – Teorização indireta: Estudar esse mercado potencial, buscando abranger a maior quantidade de funções possÃvel, preferencialmente lidando com as necessidades de informação de forma direta, porém distanciada da visão de desenvolvimento. Assim, por exemplo, em se detectando no passo anterior, a necessidade de um cadastro de parceiros multi-função, precisamos saber com precisão o quê ele é, para quê ele serve, quem ele poderá ajudar (e de quais formas), como ele pode ser mais útil e rápido. Para obter essas informações, não basta apenas “entrevistar†usuários potenciais, mas preferencialmente, tornar-se um, “esquecendo†por alguns dias que se pretende criar a aplicação, mas vivenciando as necessidades.
3 – Análise de Parcerias: Após o passo 2, devemos partir para a fase de levantamento de parcerias. Mesmo que o produto seja pequeno, sempre haverá alguma empresa interessada em ser divulgada por seu produto, ou lhe fornecer suporte técnico para que o seu produto possa “casar†ou alavancar as vendas do produto do parceiro. Assim, por exemplo, desenvolver uma aplicação simples de cadastro de parceitos multi-função pode ser útil á vários setores, entre empresas de pequeno porte. Esse produto pode ter uma função especial de mensagens SMS, de forma que uma parceria com alguma operadora poderá ser importante ao produto CCM, mas também a distribuição do nosso CCM pode ser uma interessante “arma†de vendas para uma linha especÃfica de celulares da operadora, ou ainda, pode haver uma outra função para a gravação de imagens digitais, o que torna a parceria com uma empresa distribuidora de WebCams de baixo custo interessante, e da mesma forma, viabiliza a venda de uma quantidade maior de equipamentos da parceira. E mais: Apenas com essas duas funções “diferenciaisâ€ÂÂÂ, já teremos dois parceiros para o produto final, tanto para a divulgação quanto para a consolidação.
4 – Estratégia de Marketting: Já conhecemos o que será nosso produto. Já temos uma relação de parceiros. Já conhecemos o mercado potencial. O mÃnimo que podemos fazer com esse conhecimento é unÃ-lo em um portfólio rápido, agradável e moderadamente chamativo, o suficiente para que o produto seja vendável. As estratégias mais comuns demonstram as qualidades do produto e sua funcionalidade. Vamos um pouco além, se quizermos ser mais arrojados em nosso primeiro produto: Devemos mostrar e deixar claro aos futuros usuários que, sem nosso produto, eles estarão em desvantagem com relação aos demais. Uma vêz que a estratégia tenha sido definida, não se encarregue pessoalmente da tarefa de divulgação, de publicidade. Guarde essa base para que, mais tarde e com o produto já prototipado, você possa buscar seus parceiros comerciais e encarregar uma empresa especializada para essa tarefa. Mas mantenha-se firme em sua idéia de estratégia, exija e cobre essa idéia até conseguÃ-la. Isto também o ajudará inspirando maior confiabilidade de seus parceiros nos seus propósitos e objetivos.
5 – Desenvolvimento do Produto: Inicie os passos de desenvolvimento do produto, conforme já dissemos anteriormente, e que vamos ver em maiores detalhes mais adiante.
6 – Contatos Iniciais: Implemente as parcerias
7 – Estruturação de Atendimento: Crie uma estrutura de vendas e atendimento. é péssimo, até fatal, para a imagem de uma empresa receber pedidos de orçamento, ordens de serviço, pedidos de suporte etc e só os responder um ou dois dias depois. Mesmo que você esteja agindo sozinho, apenas com seu endereço comercial e um endereço eletrà 'nico, programe respostas automáticas em seu cliente de e-mail, em sua secretária eletrà 'nica, programe a transferência de chamadas ao seu celular pessoal, enfim, procure estar atento á toda e qualquer comunicação, respondendo-as da forma mais técnica, sucinta, rápida e precisa possÃvel. Atenção: Nunca se antecipe ás dúvidas do cliente, nunca responda nada além do que lhe fà 'r perguntado, nunca explique ou detalhe nada além do estritamente necessário. Isto, por alguns motivos: Apesar de parecer uma atitude de maior atenção ao cliente, na verdade ela toma tempo desnecessário, que nem sempre o cliente está disposto, ou pode perder. Informações técnicas dificilmente serão interpretadas pelo cliente da forma como você espera, e podem causar mais dúvidas ainda. Da mesma forma, detalhar tópicos não levantados pode expà 'r sua metodologia de trabalho, seu produto e mesmo encorajar concorrentes. Estes são alguns dos motivos pelos quais deve-se manter as respostas em um nÃvel total e estritamente profissional.
8 – Estruturação LogÃstica: Crie uma estrutura para distribuição de seu produto. Com os avanços recentes nas comunicações e a constante queda nos preços das tecnologias relacionadas, a distribuição On-Line não é uma alternativa cara, nem mesmo insegura. Muitos produtos, hoje, só podem ser adquiridos por meio da mÃdia de rede. Ainda assim, o produto deverá ser “empacotado†com o cuidado de possibilitar transferência rápida, preferencialmente em pequenos “pacotes†separados, possuir uma documentação de usuário robusta, uma segunda documentação, técnica, bem estruturada e ainda, uma terceira documentação, esta última relacionada ao produto como objeto de negociação (ou seja, contrato de direitos de uso, relação de funcionalidades elegiveis do produto, descritivo do ambiente mÃnimo necessário ao funcionamento do produto, formas de contato com você e/ou sua empresa, e até mesmo a documentação de instalação, contando ou não com o número serial do cliente para aquele download). Da mesma forma, além da distribuição, esta mesma estrutura deverá abranger o controle das vendas, de forma á manter todos os clientes efetivos, pagamentos, pendências, metas etc.
9 – Divulgação Principal: Implemente a estratégia de marketing. Preferencialmente deixe ao encargo das parcerias essa incumbência, mas fazendo questão, sempre, de acompanhar, supervisionar e cobrar os resultados, como já foi comentado.
10 – Divulgação Participativa: Incentive a adoção do produto. Contate alguns poucos clientes potenciais, escolhidos á dedo e com o cuidado de que sejam bem relacionados e estejam comprometidos em divulgar o produto, isentando-os total ou parcialmente dos valores de licença e/ou de manutenção/customização, por prazo fixo ou tempo indeterminado. Estes clientes serão, na verdade, seus Parceiros de Divulgação. Essa estratégia, se bem implementada, gera um retorno muito maior do que se pensa! O custo disto, sempre nosso, costuma trazer dividendos bastante interessantes. Bons parceiros de divulgação costumam render apresentação á novos clientes potenciais, participação em reuniões onde, apesar de não haver quaisquer necessidades de nossa presença, passamos á representar uma opinião neutra e balizadora sobre assuntos variados. Isto sempre representa custo para nós, posto que não haverá retorno em serviços imediatos destes encontros e apresentações. Porém, estaremos em uma posição privilegiada desde nossa introdução á novos clientes, de forma que seremos lembrados de forma quase automática, no momento oportuno.
Com esses “dez mandamentos†em mente, podemos facilmente deduzir que, além do desenvolvimento, uma área comercial e outra, financeira e de logÃstica, são sempre necessárias. Para uma empresa estabelecida, isto é comum. Para nós, mesmo que tenhamos um CNPJ, é mais complicado, por geralmente trabalharmos sozinhos e “independentesâ€ÂÂÂ. Mas esta também é uma situação contornável, como ficou claro, com a adoção desses procedimentos simples.
A intenção dessa explanação foi a de demonstrar que, apesar de ser o objeto que gera todo o processo, o nosso produto está longe de ser a peça central. Até mesmo a existência de bugs é secundária, quando uma boa metodologia de desenvolvimento é aplicada e as demais regras são seguidas. E isso tem sua lógica: Seu produto é útilizável, tem boa funcionalidade, bom desempenho e pode ser visto como uma boa ferramenta. Se você está visivelmente comprometido com seu produto, não importa realmente que ele tenha falhas, pois você os irá corrigir. Este fato deve estar sempre nÃtido e cristalino, tanto aos seus clientes quanto aos seus parceiros e até concorrentes. Não é á toa que o MS-Windowsâ„¢ é o produto, em software, mais utilizado no mundo. Enquanto outras empresas lançavam sistemas mais sólidos, mais robustos, mas sem quaisquer comprometimentos, a Microsoft nunca descontinuou definitivamente qualquer de seus produtos. Ainda hoje é possÃvel obter suporte para desenvolvimento em QuickBasic, MS-Visual Basic 1.0 e outras ferramentas, aplicativos e utilitários da gigante de Bill Gates. Isto gera confiança, que gera vendas, que gera divulgação, que gera nome, que gera confiança, que gera vendas etc etc etc...
Bem, como iremos começar nossa “jornadaâ€ÂÂÂ? Por se tratar apenas de uma publicação simples e com a pretensão de ser quase genérica, vamos pular alguns passos, como os de detectar o nicho de mercado e todos os demais passos que não sejam diretamente ligados ao desenvolvimento. Assim, vamos aos procedimentos da regra nº 5, Desenvolvimento do Produto. Serão, á partir de agora, pouco mais de quarenta partes, até chegarmos á conclusão do nosso projeto de exemplo. Para esse produto, estarei usando um produto meu, já devidamente registrado, o IO Systemsâ„¢ CCM.
Vale á pena lembrar que estaremos lidando com uma aplicação simples, sem grandes mistérios nem grandes aprofundamentos técnicos em modelagem DCOM, CORBA, Three Tiers etc, apenas lidando com a aplicação prática de alguns conceitos relacionados. Desta forma, apesar de abranger uma variedade razoável de assuntos, estaremos passando, na verdade, apenas as linhas gerais de todo o processo. Isto equivale á dizer que, apesar de utilizarmos o MS-Visual Basicâ„¢ como linguagem de desenvolvimento básica, os mesmos processos podem e devem ser repetidos com quaisquer outras linguagems de desenvolvimento orientadas á objetos ou com suporte á objetos que se possa utilizar, como o CA-Clipper, o MS-Visual Basic Dot Net, o Borland Delphi ou o Microsoft Delphi (até o momento ainda não “re-batizadoâ€ÂÂÂ), o MS-Visual Fox Pro, quaisquer Borland C e outras. Claro, as decorrências “naturais†para os desenvolvedores VB são o próprio VB.NET e/ou o C# e/ou o ASP.NET, mas para quaisquer outras que se tenha escolhido devemos seguir os mesmos critérios no desenvolvimento."
Aqui, segue o Ãndice, para quem tiver a curiosidade de saber o que está sendo colocado no livro.
1. Estudo de Caso
a. Conhecendo as Necessidades
b. Conhecendo os Problemas
c. Acrescentando Problemas
d. Acrescentando Funcionalidades
2. Modularização Intensiva
a. Análise de Modularização de NÃvel Grupo
b. Análise de Modularização de NÃvel Módulo
c. Análise de Modularização de NÃvel Função
3. Gabaritos de Dados
a. Estruturação dos Dados
b. Normatização
i. Definição de Dados
ii. Definição de Restrições
iii. Tabelas de Dados e de Suporte
iv. Definição de Relacionamentos
v. Definição de à Ândices
c. Comparação de Engines
d. Estudos de Portabilidade
e. Definição da Competência
f. Geração dos Módulos DBA
g. Geração dos Módulos DBS
h. Geração dos Módulos DBM
i. Componentes de Serviço(*)
4. Definição de componentes e bibliotecas
a. Definições de Trabalho
i. Ambiente de Desenvolvimento
ii. Ambiente de Testes
iii. Desenvolvimento Corpartilhado ou Comunitário
1. Usando Ferramentas de Desenv. Compartilhado
2. Usando o Bom Senso
b. Projeto de Codificação
i. Interface ( Parte 1 )
ii. Componentização – Controles de Usuário
iii. Interface ( Parte 2 )
iv. Funções Básicas
v. Funções Comuns
vi. Funções de Usuário
1. Componentização – Bibliotecas de Processos
2. Componentização – Bibliotecas de Funções
3. Componentização – Bibliotecas de Diálogos
4. Geração dos Componentes de Serviço(*)
vii. Codificação de Interação do Aplicativo
1. Módulos
2. Formulários
c. Documentação
i. Definição de MÃdia
ii. MÃdia com RAV
iii. Documentação de Funcionalidades
iv. Documentação de Operação
v. Ajuda de Contexto
vi. Documentação Técnica
vii. Documentação de Instalação
viii. Documentação de Garantias e Restrições
ix. Documentação de Direitos e Obrigações Contratuais
x. Documentação de Contatos e Suporte
d. Embalagem
i. Pacotes de Instalação
ii. Pacotes Complementares
iii. Pacotes de Aditivos de Suporte
iv. Pacotes de Atualização
v. Pacotes de Desinstalação
vi. Pacotes de Validação de Licença
vii. Embalando a Embalagem
viii. MÃdia de Distribuição
Na verdade, estou finalizando o 4.b.i, Interface Parte I, o que, para mim, já é bastante coisa, uma vez que venho escrevendo esse livro aos "picadinhos", no tempo livre, há dois anos e meio. Ano passado foi o que rendeu mais.
Assim que eu começar a recuperar o fà 'lego, estarei de volta com vocês. E, na medida do possÃvel, colaborando.
Professor
Só tenho a dizer Parabéns pelo Projeto Biblio acima!
[s79]
Já tem alguma Editora interessada?
[s71]
Será em formato Digital ou Papiro?
[s95]
Com "Cerveja" mais uma grande idéia, conte conosco para pretigiar e apreciar esta publicação!
[s41] [s25]
Só tenho a dizer Parabéns pelo Projeto Biblio acima!
[s79]
Já tem alguma Editora interessada?
[s71]
Será em formato Digital ou Papiro?
[s95]
Com "Cerveja" mais uma grande idéia, conte conosco para pretigiar e apreciar esta publicação!
[s41] [s25]
Tópico encerrado , respostas não são mais permitidas