Este post foi publicado por mim no Blog da Voice Technology.

Antes de começar o post quero deixar claro que não sou contra metodologias ágeis, muito pelo contrario a 6 anos que adotamos vários princípios ágeis para trabalhar na equipe que gerencio (Basix).

No inicio do projeto Basix há 6 anos (Novembro de 2004) decidimos adotar a transparência como pedra fundamental da parceria que estava surgindo para desenvolver o novo produto, a Voice entrou como Desenvolvedor, e nosso parceiro uma operadora de telefonia Japonesa como investidor, uma das discussões que tivemos com o saudoso professor Antonio Mesquita foi sobre como lidaríamos com os bugs do sistema que estávamos começando a desenvolver, havia duas opções:

• A primeira abrir a cozinha e possibilitar o parceiro investidor ver todos os bugs, criticar, priorizar, questionar, etc.

• A segunda abrir a lista de problemas somente com a entrega de uma versão, e deixando o parceiro longe do processo de desenvolvimento.

A nossa foi decisão por abrir a cozinha (o professor Mesquita foi determinante nesta decisão), pois queríamos ser o mais transparente possível nesta nova parceria, havíamos até criado uma conta corrente específica para movimentar todo o dinheiro do projeto, então porque não abrir a cozinha do nosso desenvolvimento.

Naquele momento ainda não tínhamos muito contato com o Scrum (na verdade o próprio Scrum estava começando), mas este principio que adotamos tinha na verdade o intuito de trazer o parceiro para dentro do processo de desenvolvimento uma das bases do Scrum (e de qualquer outra metodologia agil).

Após o projeto ter chegado ao seu final (estamos em fase de operação deste produto), hoje posso olhar para trás e ver que o nosso parceiro não estava preparado para este modelo, a questão da cozinha aberta neste projeto gerou muitos desgaste, a cada novo bug detectado por nós no processo de desenvolvimento, para nós era uma alegria pois sabíamos que detectamos um problema antes de o software está sendo utilizado pelo cliente, já para o nosso parceiro a visão muitas vezes era pô este software não está legal toda hora o pessoal de testes encontra bug.

E para piorar um pouco este processo as pessoas do nosso parceiro são Japoneses e moram no Japão, e o Japonês não tem o costume de questionar, de falar o que pensa, estamos a milhares de quilômetros do Japão, e com uma diferença de fuso horário de 12 horas, por conta disto tudo demoramos muito para detectar este GAP entre as visões dos dois lados.

O projeto de desenvolvimento com este parceiro foi finalizado em Novembro de 2009, no momento continuamos desenvolvendo o Basix por demandas do mercado, e parceiros Brasileiros, mas esta questão dos bugs (product backlog do Scrum) não foi o fator preponderante para a finalização do projeto de desenvolvimento com este parceiro Japonês, mas com certeza foi um gerador de desgaste desnecessário para o processo como um todo.

Por isso que digo Agile não é para todos e em todas as circunstâncias, antes de implementar um método Ágil veja se todos os envolvidos estão preparados, e caso não esteja avalie se é possível criar interfaces para possibilitar a utilização de métodos Ágeis no desenvolvimento, e continuar se relacionando com o cliente de uma forma mais tradicional, neste caso o Product Owner deverá ser o responsável por gerenciar esta interface.

Gostaria de chamar o pessoal que participou do projeto para deixar o seus comentários é muito importante temos outras visões deste processo, para aprendermos e em próximos projetos melhorarmos!

Abraços,

Antonio Anderson Souza

agile · basix · cases · scrum · voice technology

A Brastel está em fase de Beta teste de um novo serviço chamada Call Me (este nome ainda não é o definitivo, é possível que será modificado no momento do lançamento do serviço no mercado), a idéia deste serviço é facilitar a forma de conectar você com os clientes que estão navegando no seu site.

O seu funcionamento é muito simples no seu site ou na sua assinatura do email será adicionado o CallMe widget, este por sua vez tem uma caixa de texto onde o seu cliente vai preencher o número do telefone onde ele quer receber a sua chamada, uma vez que pressionar o botão Call Me, a Brastel vai ligar primeiro para você e no momento que você atender o telefone ela iniciará a chamada para a pessoa que solicitou o Call Me no telefone preenchido no widget. Segue uma ilustração do fluxo de funcionamento na imagem abaixo:

Call Me Flow

Agora vocês já sabem como falar comigo de forma simples, rápida, e a custo zero, esperem a Brastel lançar o novo serviço para vocês aderirem também.

Toda tecnologia por trás do Call Me foi desenvolvida pela Voice Technology empresa que sou sócio.

Call Me!!!

basix · call me · telefonia

Este post faz parte da série que descreve experiencias vividas durante o projeto de desenvolvimento do Basix, neste capitulo falarei sobre como foi a decisão de migrar a plataforma de Windows para Linux.

Nós na Voice Technology já somos adeptos do mundo Open Source há algum tempo, na Business Unit que gerencio 91% dos Desktops e Notebooks rodam Linux, o Ubuntu reina como a maior distro (só nosso amigo Masato-san, e a Daniele que ainda não migraram para o Tux!, mas um dia convenceremos eles…), mas nem sempre foi assim há 5 anos atrás não tinhamos um único produto que roda-se em Linux, ninguém utiliza-va Linux no desktop, nossos produtos todos eram desenvolvidos em plataforma Windows, utilizando Visual Basic, Delphi, C e C++, e rodavam exclusivamente em Windows.

Mas a história começou a mudar durante o Desenvolvimento do Basix (Plataforma de IP-Centrex que desenvolvemos em parceria com a Brastel), no inicio do projeto definimos que o Basix seria escrito em Java, mas até aí não existia nenhuma intenção de roda-lo em Linux, o Java veio porque estávamos em um momento de tentar consolidar todos os novos produtos em uma única linguagem de programação, e a escolhida havia sido o Java (estávamos com certo trauma da salada de linguagens que tínhamos), mas as primeiras versões do Basix rodavam em Windows, e todo o ambiente de desenvolvimento era Windows.

A decisão pela migração de plataforma de Windows para Linux veio quando fomos obrigados a montar uma solução de Cluster para o Basix, neste momento já tínhamos dois profissionais com muita experiência em Linux Ricardo Nohara, e Marcos Hack( os dois ficavam buzinando no meu ouvido trocentas vezes por dia para migrarmos para Linux), mas o desafio era muito grande pois a equipe de desenvolvimento não estava habituada com o Linux, e principalmente o nosso parceiro a Brastel quem iria operar o Basix não tinham nenhuma experiencia com Linux, e para piorar a situação eles estão em Toquio no Japão (há 12 horas de diferença de fuso horario, e a 18.533km de distancia), por conta destas dificuldades decidimos testar a solução de Cluster baseado no “Windows NLB” (Network Load Balance), e a solução baseada em Linux montada com “IPVS“e “Keepalived“, de cara descobrimos que nenhuma das duas soluções davam suporte a Cluster de aplicações SIP, ponto negativo para os dois, indo mais a fundo no NLB não encontramos uma forma fácil de customizá-lo para montar o Cluster para aplicações SIP, já neste ponto a solução baseada em Linux levou muita vantagem, pois o par “IPVS” e “Keepalived” é totalmente customizável, então conseguimos montar o Cluster para o Basix apenas desenvolvendo o módulo de Healthcheck SIP, e configurando o IPVS e Keepalived corretamente.

Este foi a principal razão para comprar a briga da migração do Basix para Linux, para convencer todos desta decisão técnica foi bem complicado gestores querendo analise minuciosa de risco, equipe da Brastel querendo treinamento, etc. já a equipe de desenvolvimento era só sorrisos afinal a garotada não trabalhava com Linux mas adorava aventura, mas tínhamos um álibi muito forte a solução baseada Linux era a melhor, e mais barata também.

Neste momento tivemos que preparar um curso de Linux para dar uma introdução para todas as pessoas que não tinham experiencia com o mesmo, este cursos foi ministrado para os membros da equipe de desenvolvimento que ficava no Brasil, e para a equipe que iria operar o Basix no Japão, o curso para o pessoal do Japão foi dado via conferencia.

A decisão de migrar para Linux foi um passo muito importante para entrarmos para valer na cultura Open Source a partir deste momento toda a equipe foi engajada no modelo de trabalho da comunidade open source sempre pensando em como compartilhar melhor o conhecimento, e não reinventar a roda, hoje podemos olhar para trás e ver o quanto é diferente este jeito de desenvolver conhecimento, produtos, inovações, etc. É muito gostoso olhar para trás e ver que toda esta mudança nasceu de 2 Geeks cabeça dura buzinando em nossos ouvidos, e nós um pouco loucos para comprar a briga da mudança (Graças a Deus que demos ouvidos a eles), e toda uma equipe por trás para apoiar tal mudança.

Muito mais gratificante ainda é ver que o Basix é realmente um produto inovador, e está provando isto em todos os mercados que está sendo comercializado, pois tanto no Brasil quanto no Japão cresce a cada dia, com ótimas avaliações dos clientes, e por trás de toda esta história de tecnologia produto e inovação está basicamente um grupo de colaboradores apaixonados pelo que fazem, trabalhando realmente como um time, e que são encarados como pessoas em sua plenitude, com qualidades, defeitos, que acertam, e erram como todos nós, aliás erramos muito, mas para aprender é necessário errar.

basix · linux · management · opensource · voice technology

Há 5 anos gerencio uma Business Unit da Voice Technology que tem o seu grande foco em desenvolver uma plataforma de IP-Centrex em parceria com a Brastel (uma operadora de telefonia Japonesa, apesar do Nome é uma empresa Japonesa), durante esta jornada vivenciamos muitas experiência interessantes, sejam elas relacionadas ao choque de cultura, a dificuldades técnicas, gerenciais, decisões difíceis, acertos, erros, etc.

Posso afirmar que foi, e está sendo uma jornada muito gratificante, desde o inicio eu sempre pensei em escrever um livro para compartilhar as experiências vividas, pois não é um projeto comum de software, os desafios foram e são enormes, interagir com uma empresa do outro lado do mundo, com fuso horário de 12 horas, onde uma boa parte da empresa não fala Inglês e muito menos Português (isto mesmo boa parte dos Stakeholders deste projeto só falam Japonês), além de todos estes desafios referente a interação com a Brastel, ainda tem todos os outros desafios de uma empresa de tecnologia nos momentos atuais, liderar, desenvolver, motivar, e manter uma equipe de jovens profissionais focados em um projeto de longo prazo, não bastando os desafios gerenciais, agregamos a esta jornada a faceta técnica que engloba tecnologias como: Linux, SIP, VoIP, Asterisk, Openser, Java, Jboss, Hibernate, Oracle, etc.

O projeto de desenvolvimento do Basix já nos propiciou implantar sistemas no Brasil, Japão, Estados Unidos, Filipinas, e Hong Kong, e já viajamos para todos estes paises, além de outros do leste Asiático.

Por conta do livro ainda ser algo muito distante resolvi começar a escrever pequenos posts descrevendo importantes capítulos desta jornada, não desisti do livro, quem sabe o livro não será apenas uma compilação dos posts…

O primeiro post desta série já foi publicado em 29 de julho de 2009 (Oque vale mais conhecimento técnico, ou características pessoais?), não vou me comprometer com uma periodicidade específica sobre os posts, mas na medida do possível vou postando, me acompanhem no Twitter para saber das publicações, ou assinem o meu feed.

Até a próxima…

basix · gestão · japão · management · ti · voice technology

Resolvi escrever sobre esta questão pois gerencio equipes de TI à 5 anos, e desde o começo adotei uma abordagem um pouco diferente dos padrões nos processos seletivos que fazemos, na momento de avaliar as pessoas avaliamos muito mais os aspectos humanos que o currículo, pois nós acreditamos muito na capacidade de adaptação do ser humano, e temos certeza que uma pessoa com auto-estima elevada, e vontade de aprender, ela é capaz de desenvolver conhecimento técnico, é claro que o ambiente de trabalho tem propiciar as condições para tal desenvolvimento.

Por conta desta crença posso afirmar que após 5 anos valorizando mais os aspectos humanos, que o currículo, colhemos ótimos frutos, temos uma equipe de pessoas entrosada, e bem dinâmica, e em pleno desenvolvimento, pois todos estão crescendo, e o crescimento de um, induz o crescimento do outro.

Claro que nem tudo é maravilha, não acertamos em todas, tem pessoas que não se encaixam, neste modelo, e um dos maiores desafio desta abordagem é detectar o quanto antes, e agir, pois dificilmente os aspectos humanos mudam, diferentemente do currículo, que qualquer um consegue melhorar, é só ter um pouco de dinheiro para fazer cursos, estudar para passar em provas de certificação, mas mudar a auto-estima, vontade, forma de encarar a vida (que está diretamente relacionada como a pessoa lida com as dificuldades), isto é muito difícil de mudar.

Não menosprezamos o conhecimento técnico, pelo contrario o valorizamos muito, nós só acreditamos que é mais fácil desenvolver conhecimento técnico, que mudar aspectos humanos.

Para ter uma idéia do nível desta crença, à 4 anos atrás decidimos contratar um Arquiteto de Software para me ajudar em um projeto que estávamos começando, entrevistamos várias pessoas e fizemos um short list com 5 pessoas todos tinham currículos invejáveis, mas teve uma pessoa que tinha o currículo menos condizente com a nossa necessidade, nosso projeto era uma plataforma VoIP totalmente desenvolvida em Java, um dos 5 era um Arquiteto de Software Dot Net que nunca tinha visto a frente de um sistema de telefonia, também não tinha experiencia nenhuma com Java, nós o contratamos, fizemos isto pois era a pessoa com as características humanas que se encaixavam perfeitamente em nossa equipe, além de ser uma pessoa altamente motivada, com boa auto-estima, e com muita vontade de aprender. No momento podia parecer uma decisão questionável, mas ao longo do tempo se comprovou como correta pois o nosso amigo Fernando Fontes foi uma pessoa primordial para a formação de nossa equipe, e o desenvolvimento do Basix(plataforma IPCentrex), hoje em dia ele conhece muito bem a plataforma Java, e é um entusiasta do mundo Open. Infelizmente ele não trabalha mais conosco, mas continua sendo um membro da família Voice Technology.

E você oque valoriza mais? deixe o seu comentário, é legal refletir sobre este tipo de questão…

basix · carreira · comportamento · conhecimento · currículo · gestão · management · profissionalismo · ti · voice technology