DirectTalk Os primeiros 10 meses Trabalho de formatura - Mac499 - Francisco Jose Gatto Junior A minha proposta para o projeto de formatura é mostrar, em detalhes como foi todo o processo de criação do DirectTalk, desde sua concepção até o início da comercialização do produto pronto. O processo inteiro pode ser dividido em 7 etapas principais: - Concepção da idéia; - Maturação da idéia e modelagem do sistema; - Análise do mercado; - Implementação e testes; - Transformação do sistema em um produto comercializável; - Captação de capital; - Entrada do produto no mercado. Pretendo compartilhar não só a minha visão como desenvolvedor do sistema, mas também a minha experiência como empreendedor e empresário, um lado que a meu ver pode acrescentar muito a este trabalho pois é um ponto de vista não muito comum em formandos do IME. Outro fato interessante é ter trabalhado no projeto durante toda a sua vida, enquanto existiu como um projeto da Ox Tech, desde sua concepção em outubro de 1999 até o início da sua comercialização, em junho de 2000, participando da implementação e da captação de capital de risco para alavancar a entrada do produto no mercado. Para conhecer melhor o produto, basta acessar o site www.directtalk.com.br. Para pegar a versão .doc deste documento,clique aqui. A Ox Tech Concepção do DT Modelagem e 1ª equipe Análise do Mercado Detalhes de implementação Andamento do projeto e Testes Acabamento Investimento e Spin-off O BCC e o DT Conclusão Ox Tech Meu trabalho é sobre o projeto que desenvolvi na empresa Ox Tech, que deu origem a empresa DirectTalk. A Ox Tech é uma empresa de tecnologia, focada na prestação de serviços e desenvolvimento de soluções Intranet e Internet. Foi fundada em julho de 1997 por mim, Julio Zaiantchick e Alexandre Bernardoni, na época todos estudantes do terceiro ano do IME-USP. O meu papel na Ox sempre foi dividido em duas partes. Alem de planejar e implementar os sistemas e gerenciar os projetos, eu tomo decisões estratégicas e administrativas da empresa. Com pouco tempo disponível e menos ainda experiência, a Ox foi caminhando devagar no início, mas logo os projetos começaram a aumentar e a nossa experiência e visão do mercado também. Assim, à medida que íamos desenvolvendo projetos que além de um site puramente institucional, se propunham a prestar serviços e transações comerciais, percebemos a necessidade de infra-estrutura para estes sites. Um aspecto desta infra-estrutura que percebemos ser importante, mas ao mesmo tempo deixado de lado pelas várias iniciativas de Internet existentes na época foi o atendimento ao consumidor. Concepção do DT Nós tínhamos percebido que os grandes sites na Internet, não só no Brasil como no mundo todo, tinham uma necessidade grande de melhorar o atendimento a seus consumidores, mas não tinham uma idéia de como faze-lo. Navegando pela Internet, conhecemos uma boa idéia sobre este tema de uma empresa americana chamada LivePerson. A empresa propunha uma ferramenta que possibilitava um chat entre os usuários de um site e um operador. Além de reduzir significativamente os custos com atendimento ao consumidor, o produto aumenta a satisfação do cliente com o site e consequentemente o número de vendas/page views , que eram a principal origem da receita dos sites, no modelo comercial da época. Uma pesquisa junto aos clientes da Ox Tech mostrou que o mercado brasileiro estava não só carente, mas procurando uma solução para seus problemas de atendimento ao consumidor, e que seria extremamente receptivo a um sistema similar ao americano. Decidir investir no desenvolvimento do sistema não foi uma decisão fácil. A Ox Tech tinha na época muitos contratos que precisavam ser honrados. Alem disso, não tínhamos recursos para aumentar o número de funcionários da Ox. Conversamos muito e concordamos que a equipe de desenvolvimento da Ox, na época eu e o Alexandre, teria pela frente alguns meses de jornadas de 16-18 horas diárias de programação, divididas entre os projetos da Ox e o desenvolvimento do projeto de Chat ( como era chamado o DT antes de ser batizado). Assim começou a surgir a DirectTalk, com pretensões de representar a excelência em atendimento ao consumidor pela Internet. Seu primeiro produto/serviço foi o software desenvolvido pela Ox Tech, e que acabou batizando a nova empresa. Modelagem e equipe A equipe inicial de desenvolvimento do DirectTalk era e o Alexandre, assim todas as tarefas foram divididas entre os dois, ou realizadas em conjunto. Uma das atividades que resolvemos em conjunto foi levantar os requisitos iniciais do sistema. No início tínhamos em mente 3 necessidades básicas: - O usuário deveria utilizar o sistema usando apenas o browser; - O consumo de banda deveria ser mínimos; - O operador teria uma série de recursos a sua disposição, para melhorar a produtividade; - O sistema deveria ser seguro. Para atender a essas necessidades e ainda manter tudo o mais simples possível, decidimos que a comunicação entre os usuários e os operadores seria feita através de um servidor. Além disso, decidimos que teríamos um melhor custo/benefício se, ao invés de desenvolver um serviço e um protocolo específicos para a aplicação, utilizássemos a tecnologia ISAPI, valendo-nos dos recursos do IIS da Microsoft para responder a pedidos HTTP, mas processando efetivamente o pedido. Usar um servidor (ao invés de conectar diretamente o usuário ao operador) é necessário para centralizar a manutenção de vários operadores (como em um call center) e simplifica muito operações como back-ups e controle de versões. Além disso, possibilita o acompanhamento das diversas chamadas de um usuário. Deixar a comunicação propriamente dita com IIS, utilizando HTTP nos permite concentrar em processar o pedido, de acordo com as necessidades do sistema. Como o cliente deveria utilizar somente o navegador, todo o processamento seria de responsabilidade do servidor ou do operador, deixando assim o cliente limitado a documentos html, com o suporte oferecido pelos navegadores padrão, como html dinâmico e javascript. Para o operador, decidimos que a melhor solução seria desenvolver um programa local, utilizando o Delphi. A opção por desenvolver um programa cliente específico, ao invés de também utilizar um navegador (como era o sistema da livePerson) foi principalmente devido a possibilidade de implementar recursos diferentes à solução, sem relação direta com a comunicação com o cliente. Desenhamos um programa que além de conectar-se ao servidor, garantindo a comunicação entre os operadores e os clientes, ofereceria aos operadores uma interface onde eles pudessem acompanhar até 6 usuários simultaneamente. Montamos então uma arquitetura onde tanto o usuário (por meio do navegador) quanto o operador (usando o programa em local, desenvolvido em Delphi) se comunicam com o servidor (IIS + ISAPI desenvolvida em Delphi) através de requests HTTP, que são distinguidos uns dos outros pelo que chamamos de 'Sinais'. Nada além do que variáveis passadas pela querystring dos pedidos. Funcionando junto ao servidor, montamos um banco de dados, que além de armazenar o conteúdo das conversas, contém informações importantes para o funcionamento do sistema, mantendo o 'estado' das conversas, já que estamos trabalhando sobre o HTTP, que é stateless. Com as idéias iniciais do sistema na mão, dividimos o desenvolvimento em 4 frentes principais de trabalho: - Modelagem do banco de dados; - Programa do operador; - Lado do servidor que conversa com o operador; - Lado do servidor que conversa com o navegador do cliente. Eu fiquei responsável por implementar o programa do operador e a parte do servidor que faria a comunicação com o programa. O Alexandre ficou com a parte do servidor que conversa com os clientes. O banco de dados nós modelamos em conjunto. Alias, este é um ponto interessante sobre a equipe de desenvolvimento deste projeto: Eu e o Alexandre fizemos juntos quase todos os EPs do IME, bem como os trabalhos da Ox. Assim, já estávamos bem acostumados a trabalhar em conjunto. Conhecer como o outro trabalha e até como comenta o código realmente ajudou no desenvolvimento. Levando em conta todos os projetos em que a Ox estava trabalhando e que tínhamos desenhado para o sistema, estimamos que em cerca de 4 meses estaríamos com o sistema funcionando e pronto para ser comercializado. (como éramos tolos!) Análise de mercado Ao mesmo tempo em que pensávamos sobre o sistema, começamos a estudar a viabilidade comercial do produto. Um dos primeiros passos foi fazer um levantamento de quem seriam os nossos clientes em potencial. Além dos clientes da Ox Tech que já haviam sido sondados, concluímos que qualquer site interessado em prover um atendimento imediato e de qualidade para seus consumidores é um possível cliente para o DirectTalk. O sistema estava desenhado de modo que um operador pudesse atender, simultaneamente a até 6 clientes. Estimando que um atendimento durasse 6 minutos, em uma hora um operador poderia atender a 60 clientes. Assim durante um dia, um operador teria condições de resolver em torno de 300 atendimentos, mas em horários de pico, sites com 2000 usuários simultâneos precisariam de vários operadores atendendo. Após estudarmos algumas alternativas, decidimos comercializar o DT pelo modelo ASP (Application Service Provider) onde os clientes pagam uma taxa inicial e uma licença mensal por operador. Tomando como base os preços praticados pela livePerson e outras empresas do gênero no mundo, chegamos a um valor de R$ 2000,00 de tarifa inicial e um custo mensal por licença de R$ 300,00. Sem tempo nem recursos para fazer uma pesquisa de mercado completa, nos baseamos no que conhecíamos de Internet e do mercado, e em muito otimismo estimamos que poderíamos chegar facilmente em 500 licenças. Ou seja, chegaríamos em 6 meses a um faturamento mensal de R$ 150.000,00. A idéia era (ou parecia ser) realmente muito boa, mas além de programar, o que precisaríamos fazer para que o DirectTalk se tornasse um bom produto para o mercado, e conseguir atingir aquela meta no faturamento? A qualidade técnica era apenas uma parte. Precisávamos de uma equipe comercial forte e competente, para poder vender todas as licenças que esperávamos. Pessoal para atendimento a todos esses clientes e alguém para tomar conta da contabilidade, que de repente era muito mais complicada que a da Ox. Logo concluímos que seria necessária a criação de uma a empresa independente da Ox Tech, já que o DT era muito grande para a Ox levar. Além disso, vimos que se realmente quiséssemos crescer com esta nova empresa, seria necessário montar uma estrutura de pessoal e equipamentos que nós não tínhamos como bancar. Precisaríamos então de um investidor que acreditasse na idéia tanto quanto nós Detalhes da implementação A minha parte do desenvolvimento foi implementar o programa do operador e a metade do servidor que se comunicava com o operador. O DTOperador é um programa windows, desenvolvido em Delphi, com espaço para a visualização simultânea de 6 diálogos e uma área para o operador escrever mensagens. (ou pelo menos era assim na época da primeira versão) Utilizando uma biblioteca de comunicação básica HTTP, eu desenvolvi um gerenciador de conexões HTTP, que controlava a criação de várias conexões simultâneas e suas respostas de erro ou sucesso, e num nível mais alto a conexão do DTOperador com o servidor. Como toda esta comunicação é feita sobre o protocolo HTTP (não-persistente), regularmente o programa contata o servidor para ver se há 'eventos' de interesse do operador, como novas mensagens de clientes ou clientes iniciando e terminando diálogos. Note que existem dois conceitos de conexão: uma conexão HTTP e a conexão do programa, que é considerada ativa enquanto o servidor responde os sinais do operador (será melhor explicado adiante). Além das rotinas de comunicação, criei uma estrutura de classes para controlar o uso simultâneo de vários diálogos e apenas uma entrada de dados para todos. Também desenvolvi toda a parte de configuração do programa, tanto para os dados de conexão como a lista de FAQ, uma série de frases prontas, para economizar digitação do operador. Para agilizar e simplificar a troca de versões das DLLs do servidor e permitir um controle de carga mais eficiente, desenvolvemos um 'redirecionador', que é uma ISAPI que é acessada a primeira vez que o operador se conecta, e redireciona o resto das conexões para a URL correta do servidor. Assim, o DTOperador sempre inicia a conexão no mesmo endereço, sendo então redirecionado para a URL real do melhor servidor para atende-lo no momento. O DTOperador envia sinais para o servidor, indicando o tipo de mensagem, e depois o conteúdo da mensagem. Os seguintes tipos foram implementados: InitLogin Inicio do login, combina a chave simétrica para o resto da conexão do operador Login Loga o operador, envia o login e a senha Reload Verifica se há eventos de interesse para o operador; Mantém sua conexão ativa Msg Envia uma mensagem do operador para um usuário Kick Termina um diálogo com um cliente Logout Desloga o operador Para cada sinal enviado, há um conjunto de respostas esperadas. Foi tomada uma série de cuidados para garantir a robustez e consistência da comunicação, mesmo em casos de quebra do link, e sua segurança e eficiência em condições de concorrência. A parte do servidor, como falado, é uma DLL ISAPI, que recebe o request HTTP, processa e devolve uma resposta, tambem HTTP. Para cada sinal recebido, a DLL faz as operações necessárias junto ao Banco de dados, monta a resposta, no formato esperado pelo DTOperador e o IIS devolve a saída. Ao contrário do usual, quem está esperando essa resposta não é um navegador, e sim o DTOperador. Resumindo, a comunicação entre o operador e o navegador do usuário depende do servidor, que usa pedidos HTTP para receber e enviar não só o conteúdo das mensagens, mas também sinais de controle que garantem o funcionamento do sistema. Andamento do projeto e testes Desde o início do desenvolvimento do sistema, eu o Alexandre adotamos um esquema de longas jornadas de trabalho, e essa estratégia se mostrou eficiente, já que em pouco tempo o sistema começava a tomar forma e conseguimos com sucesso fazer todas as partes do sistema se comunicarem. Assim, estávamos realmente confiantes com as primeiras estimativas de prazo. Porém, à medida que começamos a implementar os 'detalhes' do sistema, vimos que a parte mais demorada estava apenas começando. Os quatro meses que estimamos não seriam nem de perto suficientes. Durante a fase de testes, nossa preocupação maior foi verificar, além do correto funcionamento do sistema, como ele se comportaria em situações de uso concorrente extremo, com vários usuários conversando com vários operadores ao mesmo tempo. Testes exaustivos foram feitos em todas as partes do sistema, e os bugs anotados e corrigidos e novos testes foram feitos ate termos um numero bem reduzido de 'known bugs'. (quando eu deixei o projeto, eles ainda existiam). Montamos uma estrutura para testes, que poderia simular o uso do sistema por centenas de usuários simultâneos, e com dezenas de operadores logados. Esse tipo de teste foi importante não só para detectar e corrigir erros de concorrência, mas também para resolver problemas de performance, que inevitavelmente apareceram. Além disso, monitoramos toda a comunicação com sniffers. Saber o que estava acontecendo na rede foi, em várias situações, o único meio de diagnosticar problemas e garantir o funcionamento adequando da comunicação do DT. Analisar o tráfego foi crucial para testar cada um dos sinais que compõem o protocolo de comunicação desenvolvido para o DT. O sistema nunca foi previsto para servir como uma forma segura de comunicação, mas precisávamos garantir a segurança de toda a comunicação entre o operador e o servidor, para impedir que terceiros pudessem enviar mensagens e/ou atrapalhar os usuários de um site. Toda essa segurança foi conseguida implementando um túnel de comunicação, onde utilizando um sistema de chave publica, o DTOperador e a ISAPI combinam uma chave simétrica para criptografar o resto da comunicação durante aquela conexão do operador. Acabamento O sistema já tinha sido concebido e modelado, e estava em pleno desenvolvimento. Precisávamos agora tomar as ações necessárias para transforma-lo em um produto. A esta altura ainda não tínhamos nem um nome e ainda chamávamos o DT de 'project chat'. Precisávamos de um nome, e precisávamos rápido. Assim, listamos uma série de prefixos e sufixos e fomos verificando os domínios que ainda estavam livres. Logo chegamos a DirectTalk e registramos o domínio directtalk.com.br. Mais ou menos da mesma maneira criamos um logo para o DT e a primeira versão do site para por no ar. Além disso, a interface do DTOperador precisava de melhorias para ficar mais amigável e simples. Um grande esforço foi gasto aperfeiçoando o programa para simplificar a vida dos operadores. Não só no sistema, mas também na confecção do manual do usuário, que explica todas as funções do DTOperador. Um complexo sistema de templates para as telas do chat, junto ao usuário também foi feito. Assim, cada empresa poderia facilmente colocar seu próprio 'look and feel' para seus usuários. Desenvolvemos também um site de administração, onde através de uma senha, cada cliente do DT pode cadastrar operadores, requisitar mais licenças, gerar relatórios e estatísticas de uso do sistema pelos operadores e até mesmo acompanhar a transcrição de diálogos correntes ou concluídos. O último passo (que eu participei) da transformação do sistema em um produto foi a criação do programa de instalação do DTOperador, e disponibiliza-lo para download na área de administração de cada site. Investimento e Spin-off Como eu já falei, desde cedo no projeto nós vimos que seria necessário um capital que nós não tínhamos para o projeto dar certo. Assim, ainda no meio do desenvolvimento começamos a procurar meios de levantar capital. As alternativas eram um empréstimo junto ao BNDES ou um investidor interessado em start ups de Internet. Estávamos no fim do boom dos investimentos na Internet, no início do ano e decidimos que seria mais interessante procurar um investidor. Assim, montamos um Business Plan e apresentamos a idéia a alguns bancos que por acaso nós tínhamos alguns contatos. Os primeiros foram o GP Investimentos e o Oportunity. A proposta final do Oportunity, não foi nem de perto atrativa e, apesar de ser um dinheiro que nos ajudaria bastante, preferimos recusa-la. O GP enrolou,enrolou e no fim, nunca chegou a fazer uma contra oferta, porque antes disso fomos apresentados ao pessoal da e-platform. Logo de cara eles ficaram muito interessados no projeto e uma semana após o encontro inicial, nós fechamos um contrato de investimento com eles. Definimos o budget mensal que a DirectTalk receberia pelo período de incubação ( 6 meses ) e onde esse budget seria gasto. Além do budget, a e-platform, como incubadora, se comprometia a fornecer toda a acessoria jurídica, financeira, de imprensa e de gestão para nós. Esses serviços se mostraram essenciais, principalmente o de gestão, já que a nossa falta de experiência em muitos aspectos de uma empresa grande foi suprida. A incubadora também abriu vários contatos, que possibilitaram fecharmos com clientes grandes logo de início, o que foi vital para o domínio do mercado no Brasil. Após o período de 6 meses de incubação, a e-platform tem a opção de ficar com uma porcentagem da DirectTalk, pelo multo fornecido como investimento. Depois que o capital estava garantido, precisávamos montar a equipe da empresa. Eu tinha decidido ficar na Ox Tech, junto com o Julio. Assim o Alexandre e o Gustavo seriam os dois sócios que estaria trabalhando na DirectTalk. Mas ainda era preciso montar uma equipe, não só técnica, mas principalmente comercial, marketing e administrativa. Assim, fomos literalmente a caça das melhores pessoas que conhecíamos para ocupar as vagas abertas no DT. Roubamos toda a nossa equipe inicial de empresas como AMEX, AMCHAM, OX Tech, Oracle e outras. A qualidade da equipe foi um dos principais responsáveis pelo sucesso da empresa. Com um pessoal comercial e de marketing de ponta, o DT logo conseguiu aumentar sua base de clientes, e com grandes empresas de segmentos importantes como bancos e os grandes sites de comercio eletrônico do Brasil. O BCC e o DT Quando começamos a modelar o DirectTalk, uma coisa que tínhamos em mente era: Vamos fazer direito! Fazer direito, para nós, significava fazer de acordo com as "regras" aprendidas no IME. Desde MAC-110 até Engenharia de Software. Alias, engenharia de software foi uma das disciplinas do IME que foi muito útil no desenvolvimento do sistema. Apesar de não utilizarmos explicitamente nenhum dos métodos de modelagem vistos em aula, os conceitos aprendidos foram imprecindiveis no planejamento do DT. Além de MAC-332, banco de dados, programação concorrente e redes foram disciplinas que diretamente ajudaram muito no desenvolvimento. Nem podia ser de outra forma, já que estamos falando de um sistema feito para comunicação sobre a Internet, e trabalhando em cima de uma base de dados. Programação concorrente foi especialmente importante, porque o DT é um sistema multi-usuário, e não teria sido fácil (já não foi) garantir o funcionamento sem os conceitos e métodos aprendidos nesta disciplina. De uma maneira menos direta, Compiladores ajudou bastante. Ter feito um projeto grande e complicado como um compilador de Pascal nos deu muita noção de como funciona o desenvolvimento de um sistema mais complexo. Além disso, apesar de não saber avaliar direito, acredito que todas as disciplinas do BCC, mesmo as matérias da matemática e estatística são importantes, pois no mínimo nos aprendemos a raciocinar de uma maneira diferente. Algumas coisas que eu gostaria de ter visto no BCC, mas infelizmente não temos são disciplinas que ensinem a transformar um EP em um produto, ou a fazer uma documentação decente de um software, desde a especificação até o manual de uso. Ou ainda um apoio maior para alunos mais interessados no mercado e menos o meio acadêmico. Por exemplo, a disciplina de portugês (ainda é obrigatória ?) poderia ter uma visão mais "Como escrever a documentação do software" e nunca ( como foi no meu caso ) para aulas de gramática e sintaxe. No geral, não só para o meu "estágio" no DirectTalk, mas desde que comecei com a Ox Tech, o BCC teve um papel muito importante, tanto para a formação estritamente técnica quanto para a "habilidade de resolver problemas", não importando a natureza deles. Estou no IME já a vários anos, e com isso consegui fazer parte do mercado de trabalho,sem deixar de fazer parte do mundo acadêmico, e sem me desinteressar por estudar e aprender. E isso eu acho realmente importante para a minha carreira. Conclusão Essa é uma breve história do DirectTalk, da concepção até mais ou menos o ponto em que eu deixei de estar diretamente envolvido com o projeto.Mais ou menos porque não há um ponto claro quando isso aconteceu, se é que ja aconteceu. Como não poderia deixar de ser, meu maior envolvimento no projeto foi na parte técnica, isto é, na modelagem e implementação do sistema. Especialmente toda a parte do operador ( tanto o servidor quanto o cliente) foi no que eu mais participei, desde o início desenhando o sistema e seus sinais, até a implementação do DTOperador ( o programinha do operador ) Apesar de muito cansativo ( afinal foi feito quase todo nas madrugadas ) o DT foi um projeto extremamente gratificante de se desenvolver. Não só porque poderia ser um produto de muito sucesso e consequentemente financeiramente bom, mas porque sempre foi um projeto muito 'legal'. Além disso, a simplicidade do seu funcionamento, e por isso sua eficiencia sempre me entusiasmaram bastante. Meu parceiro de desenvolvimento foi o Madruga, com quem eu tenho programado a quase seis anos. Com todo esse tempo, cada um já estava acostumado com o estilo de programação do outro, e até mesmo com seus erros 'tradicionais'. Isso agiliza bastante o processo, e o torna muito mais agradável. Do BCC, todas as matérias básicas foram muito importantes para o projeto. realmente todas. Além delas, banco de dados, programação concorrente, engenharia de software e redes de computadores desempenharam um papel muito importante para o desenvolvimento do sistema. O DT é um projeto muito grande, e que se estende por diversas áreas. Espero ter conseguido resumir o meu papel no DT durante o tempo que estive realmente ativo nele. []'s Gatto Ox Tech Internet 55 11 3812-8100 gatto@oxtech.com.br