Empreendedorismo, Escritório, Exemplos práticos, TI é o negócio, Transformação digital

Como a Netflix atingiu o nirvana do ownership

maio 15, 2018

Netflix não possui CTO (Chief Technical Officer). Ter um CTO seria sintoma de centralização de decisões técnicas. Na Netflix eles possuem apenas o CPO (Chief Product Officer), que é o chefe de produtos. Produtos e TI são a mesma coisa. A Netflix também é um dos times mais inovadores em tecnologia e proposta de valor no mundo. Mas como eles atingiram este patamar? O que os levou até lá?

 

Papéis e responsabilidades

Eles nasceram assim. Era um mindset simples de se manter enquanto eram uma startup em 1997. Mas este pensamento tem sido mantido ao longo dos anos com o crescimento da companhia.

Com uma série de benefícios para seus funcionários, que se traduzem simplesmente em liberdade para tomarem as ações que acharem necessárias, a Netflix compartilha suas práticas de gerenciamento e responsabilidade em seus discursos. A principal obrigação de um gerente é contratar as melhores pessoas do mundo. A principal obrigação de todos os funcionários é tomar as melhores decisões possíveis, tendo todo o contexto da empresa disponível para embasamento. Números de assinantes, faturamento, budgets de todas as áreas fazem parte da rotina de informações que os gerentes distribuem a seus funcionários. Gerentes solicitam que seus funcionários façam entrevistas em concorrentes pelo menos uma vez ao ano para garantir que seus times estão recebendo o valor de salário que merecem. Também não há gestão do conhecimento. Quando um funcionário sai da empresa, seus projetos morrem com ele. Não há níveis de junior, pleno e senior.

 

Nada de regras

A Netflix foge de regras e processos pois acredita que quando se diz às pessoas como devem agir, sua criatividade é restringida, e isto faz com que deixem de pensar em como agregar valor à empresa. Isto tem um custo. É comum vagas tomarem mais de 6 meses para serem preenchidas, pois requerem processos complexos de contratação e altos níveis de subjetividade na seleção.

Tendo alguns exemplos de benefícios como:

  • Tempo de férias indefinido;
  • Tempo de licença maternidade indefinido
  • Orçamento para assuntos técnicos ilimitado;
  • Recursos de hardware e software ilimitados;
  • Não existência de plano de trabalho: uma vez que você é contratado ninguém dirá o que deve fazer. Você inventa seu próprio projeto, trabalha, conclui, testa, e vai para o próximo. Neste ponto seu gerente ajudará a tomar esta decisão caso seja de seu interesse.

Esta liberdade passa por somente uma restrição: aja de acordo com os interesses da Netflix.

Desta forma a empresa, que se orgulha em atestar que contrata somente os melhores funcionários do mundo para as posições que abre, e que já conta com 4000 colaboradores, atingiu um nível de ownership difícil de se comparar. Cada um é responsável pelos seus projetos e possui propriedade para definir se ele é útil à companhia ou não.

 

O que isto gera?

Isto gera um ambiente de liberdade incrível para as pessoas produzirem o que consideram importante. Uma vez que cada funcionário é um dos melhores do mundo em suas áreas, entende-se que ele terá discernimento para tomar as melhores decisões. Isto gera mais de 100 projetos acontecendo em simultâneo vindo de todos os lados da companhia e sendo testados a todo momento. Nenhum projeto que interfira nos sistemas pode tomar mais de 2 meses. A cada 2h uma publicação em ambiente produtivo é feita, e nada é ativado sem passar por testes A/B.

O grande objetivo do ownership também é alcançado pois todas estas condições também têm a intenção de delegar poder. Todo funcionário da Netflix deve ser capaz de tomar decisões sem depender de processos de validação infindáveis ou opiniões desnecessárias. Atrelando liberdade, responsabilidade e poder, é como o Netflix atingiu e mantém seu nível altíssimo de ownership entre seus funcionários e continua sendo uma das empresas mais inovadoras desde o momento em que foi criada.

 

O modelo e como aprender com eles

Comparando outras empresas de diferentes áreas de atuação, entre as mais tradicionais como indústrias, até as mais recentes startups, a Netflix atingiu seu ownership através da soma de algumas coisas: poder quase irrestrito, liberdade quase irrestrita e senioridade/maturidade como premissa.

E este é um modelo único que não deve ser perseguido cegamente, mas sim usado como inspiração pela forma disruptiva que encontraram para gerenciar sua companhia.

Clientes, Exemplos práticos

Um bom exemplo de customer experience em vendas para a área financeira

maio 7, 2018

Este artigo foi escrito por Eduardo Diederichsen, Felipe Lindenmeyer  e eu. Eduardo e eu somos líderes da área de desenvolvimento de software na ilegra, e Felipe é um account manager sênior. Todos estamos conectados diretamente às exigências de clientes.

 

Diariamente negociamos com muitos clientes. A parte mais difícil não é dá-los um preço ou conduzir uma apresentação com slides bonitos e muitas buzz words. A parte mais difícil é identificar se o cliente potencial possui um desafio real e como este desafio pode ser abordado pelo potencial, linguagem e visão de mercado de nossa companhia. Quando descobrimos, o cliente merecerá nosso mais profundo foco para termos um bom entendimento e oferecer algo que se encaixe perfeitamente a suas necessidades, mesmo que ele ainda não entenda isto, e então tentar ajudá-lo a entender.

 

A experiência

Mas o que faz a experiência ser tão perfeita quanto deve ser para que o cliente assine o novo contrato? Impossível dizer pois que compra qualquer coisa são pessoas. Pessoas se baseiam em coisas diferentes para avaliar suas experiências em todos os lugares, dando mais peso a diferentes pontos baseado na sua personalidade e nas influências que receberam durante toda sua vida.

 

O cenário 

Este recente novo cliente executou uma jornada completa, desde o contato mais inicial até a assinatura de contrato toda dirigia por eles junto de vários candidatos. No final do processo eles decidiram comprar de nós. Vou relatar o que foi feito e como as coisas poderiam ter acontecido de forma diferente.

O cenário do cliente

É um cliente da área financeira, então ele sabe que os clientes financeiros no Brasil são muito exigentes com relação a toda a UX e a flexibilidade dos produtos. Na área financeira, o Brasil é o país com a User eXperience mais desenvolvida em todo o mundo, então a competição e os investimentos por aqui são grandes.

Primeiros contatos

O que aconteceu: o primeiro contato aconteceu em uma celebração casual não relacionada a trabalho. O assunto no grupo se dirigiu a trabalho. Exploramos rapidamente alguns exemplos de como temos ajudado alguns importantes parceiros a estarem a frente de seus competidores. O que realmente aconteceu: a atenção foi pega e cartões foram trocados. Poucos dias após uma reunião foi solicitada a nós para falar sobre nosso portfolio e conhecer seus requerimentos e preocupações.

A reunião

O que aconteceu: aconteceu na sede do cliente. O objetivo era, como solicitado, falar um pouco sobre cenários em que temos trabalhado e as oportunidades que temos identificado e previsto como experts no mercado. O que realmente aconteceu: eles entenderam que tínhamos conhecimento para ser um bom parceiro, e que se contassem conosco teriam opiniões de especialistas no mercado. Então o próximo passo é enviar uma proposta e todos comemoram? Sim, mas não tão rápido.

Os desafios
  • Primeiro! O que aconteceu: este cliente é uma empresa brasileira muito conservadora que ainda não tomou iniciativas relacionadas a transformação digital e nem mesmo quer isto. Já nós estamos muito acostumados a trabalhar baseado em metodologias ágeis, abordagens Lean, testar e descartar perdas rapidamente, etc. Eles queriam que tudo fosse previsível com objetivos e passos definidos. O que realmente aconteceu: eles entenderam que seus concorrentes já não trabalham mais neste modelo e que se mantivessem aquela forma, se manteriam atrás no cenário de competição. Então formulamos um misto de práticas que dariam parte dos controles que eles estavam solicitando mas ao mesmo tempo deram partes da liberdade que este tipo de trabalho necessita.
  • Segundo! O que aconteceu: eles nos disseram que gostariam de estar a frente de seus concorrentes sabendo quanto isto custaria e quanto tempo tomaria. Bem… se nós tivéssemos estas respostas, nós seríamos um dos competidores. E é neste ponto em que o mindset Lean e de experimentação recebem atenção. As startups que estão incomodando gigantes da indústria não têm este tipo de respostas. O que realmente aconteceu: decidimos atacar um primeiro entregável (podemos chamar de MVP) e depois disso realizar uma nova avaliação para desenhar próximos passos.
Quando as coisas esfriaram

O que aconteceu: tivemos os passos acima, mas estava tomando muito tempo para uma decisão ser feita e as coisas esfriaram (más notícias). Nossa decisão foi de convidá-los para vir à nossa empresa para que pudessem ver com seus próprios olhos tudo que discutimos. Eles realmente se impressionaram com nosso escritório pois viram que é desenhado da forma que precisa ser para dar liberdade às pessoas pensarem e inovarem. Este foi um passo chave porque puderam falar com pessoas que realmente trabalhariam em seu projeto. O que realmente acontece: a negociação esquentou novamente.

 

O que será encarado de forma diferente por cada pessoa

Há muitas questões subjetivas na explicação das frases acima. Nelas não exploro linguagem corporal. Não estou explorando frases que dissemos uns aos outros e como nos portávamos durante as reuniões. Logo, não estou dizendo como a empatia foi criada aqui. Vamos dar uma olhada mais próxima.

O cenário do cliente

Algumas empresas podem ter receio de inovar. É um cenário completamente novo. Pessoas temem o que não conhecem. Elas não sabem o que está vindo, então ficam com medo e param. Para outras companhias, o desconhecido é entusiasmante e elas sabem que é do desconhecido que a inovação virá. Elas procurarão por isso rotineiramente.

Primeiros contatos

Uma vez que aconteceu em um evento social, o foco não era uma avaliação. A empatia veio facilmente pois falamos de nossos cases brevemente (sem mover o foco de toda a noite para trabalho somente) e humildemente. Se fossemos muito sedentos pelas suas necessidades, poderíamos ter transformado o momento em momento chato e perder a atenção conquistada.

A reunião

O objetivo da reunião foi mostrar nossas capacidades e também flexibilidade para entender as preocupações sobre modelos e o que estávamos propondo. Naquela hora nós investimos tempo explicando e desmistificando práticas de desenvolvimento de software como Dojos, Meetups, modelos de gerenciamento de times, nossas preocupações com relação a qualidade (Testes A/B, testes de caos, etc). E naquela hora um fato muito importante aconteceu: a empatia com um dos participantes foi tão grande, ele viu tanto valor na proposição, que começou a defender algumas das abordagens sugeridas aos sponsors do projeto de forma muito entusiasmada.

Os problemas

Tivemos de usar muito conhecimento para mostrá-los as diferenças entre a forma que estavam tentando abordar o problema e a direção que vemos que o mercado está tomando. Foi um trabalho duro entender como ele estão acostumados a tratar projetos e misturar a uma realidade que pudéssemos trabalhar de forma a ter certeza de que alcançaríamos os resultados que ambos estávamos buscando naquela parceria. Mas o maior passo alcançado foi o uso do mindset de experimentação para abordarmos a primeira fase. Eles optaram por dar um tiro inicial no modelo que foi sugerido. Esta é a chance de manter as coisas andando bem para construirmos ainda mais confiança.

Quando as coisas esfriaram

Esta foi a parte perigosa. Ligar e incomodar a paciência do cliente não teria sido uma abordagem eficiente. Trazê-los a um ambiente conhecido onde poderíamos falar novamente sobre alguns assuntos e remover as dúvidas e objeções restantes foi uma boa iniciativa. As pessoas não entenderão tudo na primeira vez que você falar ou apresentar algo. Você precisará repetir no momento perfeito em que sua explicação fará sentido a eles para ter sua atenção e interesse afetados.

 

Apenas mais alguns exemplos genéricos

Um cliente pode gostar de escutar mais buzz words todas pronunciadas em inglês. Outro cliente, vindo do interior, pode não gostar pois considera que isto só funciona em grandes companhias. Sobre a proposta: um cliente pode preferir um documento repleto de belas imagens explicando de forma mais abstrata o que será alcançado. Outro pode preferir receber um documento de somente uma página indo direto ao assunto com relação aos entregáveis, usando somente texto. É imprevisível.

 

Legal! Como posso aprender com este cenário? 

A boa CX (Customer eXperience) se torna mais desafiadora de atingir quando falamos de ofertas B2B ou B2B2C. Quando você tem um cenário B2C você provavelmente terá pessoas no fim do processo que você deve agradar com sua oferta e vantagens. É mais fácil perguntar: “hey, você gostou desta nova feature?”. Voltando ao B2B ou B2B2C as variáveis são incontáveis, uma vez que você precisará lidar com muitas pessoas desde o início da negociação até alcançar o fim do contrato.

 

Como atacar de forma eficiente?

Resposta rápida: esteja interessado. Resposta longa: Mantenha o conhecimento entre as pessoas envolvidas, use esta experiência, e esteja interessado sobre evoluir o processo e realmente aprender com as lições aprendidas. Tente entender linguagem corporal e psicologia, conheça mesmo quem está comprando de você. Esta pessoa escreve publicamente? Dá discursos? O que ele está falando/escrevendo/lendo/escutando/estudando que você pode levar em consideração para criar um momento para um contato rápido?

Empreendedorismo, Inovação

5 passos para ter um mindset de inovação na sua empresa

abril 23, 2018

Atualmente quando falamos de negócios, empresas, dinheiro, processos, e tudo mais, sempre nos voltamos a inovação. Melhorar processo interno? Inovação. Fazer um novo software para encurtar ou automatizar trabalhos? Inovação. Ganhar mais dinheiro ou gastar menos dinheiro? Inovação.

Todas as áreas de conhecimento falam em inovação. Cientistas procuram inovar sempre para obter novas fórmulas, teorias e avanços. Banqueiros inovam para obter margens maiores de lucro. Arquitetos inovam em construções para encontrar materiais mais baratos e mais resistentes. Desenvolvedores e profissionais de TI inovam para fazer sistemas mais rápidos e que tornem a experiência de seus usuários cada vez mais imersiva.

Uma vez que todas as áreas precisam inovar, o que as empresas novas e tradicionais fazem para que isto seja possível? Como estimular um ambiente inovador? Que resultados esperar de quais tipos de inovação?

 

Quebrar hierarquia

A hierarquia mata a inovação. Encare isto. A pessoa que está propondo a inovação não pode depender do julgamento de outras 4 ou 5 acima de seu nível hierarquico até que a ideia chegue a quem realmente a entenderá.

As inovações incrementais mais bem sucedidas e mais rápidas são aquelas que pesquisam o hábito do consumidor. É uma inovação rápida, está na boca de todos os usuários que usam sua ferramenta. É só perguntar. Ela não pode esperar pela hierarquia.

As pessoas têm medo de levar suas ideias adiante por acharem que serão julgadas. Têm medo de se sentirem diminuídas caso sua ideia não seja boa. Quando há muitas etapas a serem vencidas, a ideia morrerá sem chegar aos ouvidos de quem realmente importa. Com isso, vamos ao próximo ponto…

 

Tenha muitos ouvidos

Vejo muitos clientes se orgulharem e dizerem: “criamos uma área de inovação!”, com orçamentos volumosos! Já vi a “Área de inovação” ser o novo nome do R&D (ou P&D – Pesquisa e Desenvolvimento). Reconheço que a inovação precisa começar de alguma forma, mas restringir os ouvidos somente às vozes vindas da área de inovação é perigoso. É um passo sim, mas somente isso. Se esta é a forma de iniciar, comece por aqui!

Mas lembre que empresas pequenas e com poucos funcionários não possuem áreas de inovação:

  • O Nubank tem um departamento que se chama “fator Wow!”. Como o nome sugere, a responsabilidade do time é criar experiências que impressionem seu cliente. Mas a inovação deles não surge somente no departamento “fator Wow!”.
  • Seu cenário é de empresa grande? Pense no Google. Com milhares de funcionários, 20% do tempo de cada funcionário é livre para trabalharem em suas próprias ideias.
  • O modelo de negócios da Google permite este tempo ocioso pois sua fábrica de dinheiro está automatizada? Legal, vamos olhar para a Apple. Ela vende hardware, é uma fábrica. É uma das empresas mais inovadoras do mundo.

 

Estimule o intra empreendedorismo

O objetivo final é inovar sim, mas a inovação só vai surgir quando as pessoas pensarem fora da caixa. Para pensar fora da caixa precisam se sentir à vontade, e entenderem que têm liberdade para propor ideias e que elas não serão cortadas.

 

Foque no “Como”, e não no “O Que”

Uma idéia cujo idealizador julgar genial, mas após avaliação detalhada for descartada, exige muito cuidado:

  • Caso o idealizador não receba feedback em tempo justo, ele desmotivará. Não o deixe no limbo;
  • Caso o idealizador não seja convencido dos motivos pelos quais sua ideia não será levada adiante, ele desmotivará. Não o deixe sem explicações.
  • Ajude o idealizador a identificar a ideia central. Caso não sejam explorados mais cenários em que a ideia é aplicável, o idealizador pode se desmotivar. Ajude-o a entender que criar um novo cartão de crédito já é um meio, mas a inovação pode estar em focar no meio de pagamento.

 

Comece

Não há cartilha pronta. Só depende de você. Grandes empresas de consultoria proporão modelos prontos, custando milhões de dólares sobre como “implementar a transformação digital”, por exemplo. Não vai funcionar. Sua cultura não deixará. A inovação é incremental. Não terá prazo e custo definidos. Nada é inventado e evoluído ao mesmo tempo (frase de impacto cuja autoria não é minha).

Pense por você mesmo como começar. Estabeleça planos, estude teorias de inovação e como a inovação acontece. Uma vez entendido como a inovação acontece, você saberá por onde começar. Sugestões: Lean, jornadas de design, metodologia ágil de desenvolvimento de software.

Empreendedorismo, Evitando problemas

Adaptando o mindset Lean com a boa índole para empreendedores

abril 17, 2018

A disciplina para aplicar o mindset Lean precisa estar em todo lugar. Neste último sábado, participei de uma aula em que estávamos discutindo ferramentas e preocupações sobre gestão de projetos, focando em riscos.

O cenário Lean

Vamos usar o mesmo cenário de construção civil como exemplo. A maioria das pessoas estava concordando que o projeto seria considerado de sucesso se o entregássemos dentro do escopo, cronograma, custo e qualidade planejado (como o PMI atesta por anos). Isto é muito subjetivo porque irá se basear no entendimento que cada um tem sobre sucesso. Se seu objetivo é somente fazer um check na sua checklist, mantenha o dito acima. Mas vamos explorar uma exceção.

Considere que você é o gerente de projetos. O ponto aqui é: se durante a construção um cano for quebrado e seu projeto derramar rejeitos tóxicos em um rio próximo? Isto causaria um dano ambiental no mínimo. Naturalmente, consertar o cano se torna parte do escopo do seu projeto. Porém não é verdade para todo o restante. Não é sua responsabilidade criar um plano de contorno para a questão ambiental (plantar árvores, limpar o rio, etc), nem se importar com a imagem da sua companhia na mídia e sociedade (campanhas de marketing, levar água para as comunidades afetadas, etc).

Para explorar este ponto, começamos a discutir se você, como gerente de projetos, deveria levar a informação aos donos da sua organização sobre o que aconteceu e o assunto se voltou para a ferramenta MCSW para ajudar nesta avaliação.

Ferramenta MSCW

Fazendo uma pausa, argumentamos sobre a ferramenta MSCW quando estávamos mapeando riscos. É uma ferramenta para classificar a importância do item que está sendo tratado. M é MUST (DEVE constar), S é SHOULD (DEVERIA constar), C é COULD (PODERIA constar), e W é WOULD (“seria legal” constar). Claramente não há um mindset Lean aplicado a esta ferramenta. Deveria ser somente DEVE ou NÂO DEVE constar. É sim ou não. Você precisa ou não precisa fazer algo sobre o requerimento, ou o risco, ou a situação. Discutir os itens do meio será perda de tempo.

A boa índole

Voltando ao cano estourado. DEVERIA ser sua preocupação, como um bom gerente de projetos, alertar e, sugestão minha, ajudar no planejamento de algo para reparar o dano ambiental e a imagem da marca de sua companhia. A bíblia do gerenciamento de projetos diz que você não deve se envolver a não ser que isso se torne parte do seu escopo. E aqui nós temos uma diferença entre empreendedorese pessoas que somente trabalham.

Mas por muitas vezes, o suporte completo às necessidades da organização podem conflitar com o Mindset Lean. Neste caso, alertar sobre o problema é Lean. Porém se envolver na solução não é, a não ser que ela seja adicionada ao escopo. Esta é a hora em que o empreendedor deverá ter maturidade para deixar o problema ser tratado por outras pessoas e se distanciar para focar nos seus desafios reais. Caso contrário, se envolver nas atividades não previstas, será encarado como micro gerenciamento.

Mantendo conhecimento e boa índole perto de você

Um ponto importante de ser exploraado após este fato ter ocorrido são as lições aprendidas no cenário. Esqueça sobre criar um documento escrevendo várias páginas com análises FCA (fato, causa e ação), e colocá-lo num respositório. A parte mais importante é ter certeza de que as pessoas corretas entenderam o que o cenário causou. Por causa do cano estourado, nossas ações despencaram 20% em seus meses, e isto afeta diretamente os empregados na ponta pois perderemos muitos projetos para nossos concorrentes devido a incerteza gerada sobre a qualidade de nosso serviço. Isto pode causar a saída de pessoasda companhia e perda de conhecimento.

A coisa mais importante após os acontecimentos é manter este conhecimento. Certamente você, como gerente de projetos, nunca mais será disciplicente sobre a análise do solo e pesquisas pois estará preocupado com o impacto ambiental. Tudo está ligado. Desde o impacto ambiental até a força de trabalho trabalhando lá.

Exemplos práticos, TI é o negócio, Transformação digital

Usando Machine Learning na vida real parte 2/2

abril 5, 2018

Agora que entendemos a diferença entre as três abordagens que podemos ter com relação a IA com o último artigo, é hora de olhar para a abordagem intermediária, sempre mantendo em mente os limites existentes. Dada a explicação das diferenças entre abordagens para Machine Learning: a) APIs prontas para uso, b) treinando um modelo, e c) criando um modelo, vamos falar sobre treinando (usando) um modelo.

Treinando um modelo

Esta é a abordagem meio termo para problemas com IA (ou Machine Learning). Uma vez que você conclui que seu problema não pode ser resolvido com APIs prontas para uso, tente esta abordagem. Só porque não há uma API pronta para uso, não significa que ninguém nunca tentou resolver o seu problema, falando de forma mais ampla e genérica. Existe uma probabilidade altíssima de que o seu problema já possa ser resolvido através de um modelo existente. Usando esta abordagem, você deverá olhar para três coisas. Isto não significa dependência, uma vez que o terceiro passo (abaixo) pode ser deixado de lado em alguns casos (também exemplificado abaixo), mas eles são uma sequência.

Encontrando o melhor modelo

Esta é a parte onde você precisará de alguém com experiência no assunto. Há vários modelos para serem utilizados e abordar/resolver o mesmo problema, por exemplo. E também há vários problemas sem modelos que os cubram. Você precisará encontrar o melhor modelo que se encaixa da melhor forma à sua necessidade. Você precisará também checar os percentuais de confiabilidade que o modelo em questão provê, se ele usa as informações de que você dispõe, e ainda se você precisará adaptar alguma informação que você já tenha para usar aquele modelo;

Podemos dividir os modelos em três grupos:

  • Modelos para treinamento supervisionado

    Você poderá usar um modelo de treinamento supervisionado quando você sabe que o algoritmo precisa chegar à conclusão X (objetivo) depois de avaliar as informações A (info 1), B (info 2) e C (info 3). Exemplo: você sabe que espirros (info 1), temperatura corporal elevada (info 2), e dor por todo o corpo (info 3) significa que você está gripado (objetivo). Abaixo apresento genericamente alguns modelos muito conhecidos:

o Regressão linear  https://docs.aws.amazon.com/machine-learning/latest/dg/types-of-ml-models.html – É um bom modelo para trabalhar com números. Predição de números principalmente. Exemplos: qual será a temperatura para amanhã? Por quanto esta casa será comprada?

o Árvore de decisão – https://www.ibm.com/support/knowledgecenter/en/SS3RA7_15.0.0/com.ibm.spss.modeler.help/nodes_treebuilding.htm – Encontre a doença: os sintomas A, B e C são verdadeiros no paciente? Então doença X; Os sintomas A, B e D são verdadeiros? Então doença Y;

o Redes Bayesianas – https://pt.slideshare.net/GiladBarkan/bayesian-belief-networks-for-dummies – Quando temos uma evidência e queremos chegar a sua causa. Propagação de crença – O mesmo cenário da saúde acima pode ser aplicado, porém de forma inversa. Tenho gripe. Preciso identificar se neste paciente, temos todos os sintomas, ou se ele não apresenta corisa mas mesmo assim tem gripe.

  • Modelos para treinamento não supervisionado

    Você poderá usar quando não possui a conclusão a que aquele algoritmo precisa chegar. Você precisará checar todas as vezes que ele for executado. Exemplo: se o cliente comprou o produto X e Y, ele pode estar interessado no produto Z. Você não sabe se de fato ele está interessado no produto Z, porque ele PODE estar interessado, mas mesmo assim não comprar o produto (o que concluiria sua predição). Apresento também alguns modelos:

Associação – https://en.wikipedia.org/wiki/Association_rule_learning – Exemplo acima de varejo sugerindo compras para seus usuários;

o Detecção de anomalias – Qualquer controle gráfico ou de informações em que anomalias precisam ser alertadas. Bolsa de valores ou controles de temperatura de uma caldeira, por exemplo;

  • Modelos para treinamento semi-supervisionado

É aplicável quando você sabe algumas vezes o que você quer descobrir, mas não sempre. Modelos podem ser encontrados em https://en.wikipedia.org/wiki/Outline_of_machine_learning#Machine_learning_algorithms

Configurando um modelo

Chegaremos neste passo quando tivermos um modelo conhecido que precisaremos configurar. É possível que você não precise treinar o modelo.

Um exemplo para regressão linear, que surgiu de um cliente: eles queriam combinar diferentes informações de muitas fontes diferentes e descobrir como isto afetaria a precificação de seu produto. Para cada um dos produtos, você configuraria o algoritmo de forma a entender que o suprimento A afeta 10% do preço final do produto, suprimento B afeta 50% e etc. Sabendo disso, o algoritmo seria capaz de “predizer” mudanças nos seus preços e avisá-los sobre comprar mais ou menos de cada suprimento. Desta forma eles estariam a frente de seus concorrentes, e economizando dinheiro ao mesmo tempo;

E então… Treinando um modelo

Uma vez que você possui um problema que requer um modelo que seja treinado para identificar seu algo, você precisará guardar dados para treinar seu modelo. A análise de imagem que os grandes provedores de cloud possuem é um excelente exemplo. Uma vez que você envia uma foto que possua a Torre Eiffel, o algoritmo já sabe que há uma Torre Eiffel na sua imagem. Mas como eles fazem isto? Eles já treinaram um modelo para entender os padrões na imagem e então classificá-la. É a mesma coisa que o Facebook faz todas as vezes em que faces nas fotos que você envia. Para o exemplo do Facebook, a técnica se torna ainda mais impressionante porque o Facebook treina seu algoritmo com as faces de todas as pessoas. Desta forma o algoritmo consegue entender que a sua imagem tem uma foto de um amigo em específico, e sugerir a você que o marque! Não é somente um reconhecimento genérico de pessoas como outros modelos fazem.

 

Como fazer isto tudo?

Por fim, há muitas ferramentas como Google AutoML, Amazon Machine Learning, Watson tools, and Tensorflow (open source tool). Os provedores de soluções permitem que você envie um determinado modelo e então usem sua infraestrutura para executar, treinar e consumir sua inteligência.

Exemplos práticos, TI é o negócio, Transformação digital

Usando Machine Learning na vida real parte 1/2

março 30, 2018

Todos têm falado sobre Machine Learning e todos querem obter os benefícios da IA (Inteligência Artificial). É uma novidade que gerentes de TI peguem aquele velho problema do fundo da gaveta e pensem: “hey! Talvez o novo Watson possa resolver isto para mim!”. Mas em todas as vezes que escuto alguém perguntando sobre como resolver um problema com IA, parece que o problema é inédito. Se todos os dias uma nova vontade vem, como podemos identificar as fronteiras de IA? Uma vez que IA é “Inteligência Artificial” qual é o limite da “inteligência”? O que pode e o que não pode ser resolvido com o que temos hoje?

Como identificar quão difícil será encontrar uma IA para seu cenário

Ferramentas para Machine Learning podem se dividir em três grupos:

 

  1. Usar APIs prontas para uso (este primeiro artigo focará aqui somente)
    • O que é? É a abordagem mais rápida. Há muitas APIs prontas para serem acessadas e adicionadas à sua solução. Há vários benefícios e você só precisa pagar e usar. Há uma tabela com detalhes abaixo;
    • Quanto tempo para ter resultados? Você pode ter resultados de testes em um dia;
    • Alguns benefícios:
      • a) Ela estão prontas para uso! Você só deve plugar à sua aplicação. Qualquer um pode fazê-lo;
      • b) Os fornecedores estarão sempre treinando o modelo enquanto você usa! Então nunca estarão desatualizados;
      • c) A competição entre os fornecedores garantirá sempre modelos bem treinados, melhorias e atualizações;
      • Os benefícios acima serão muito caros de atingir fora desta abordagem;
    • Algumas restrições:
      • a) A API não pertence a você. Isto significa que você não poderá mudar nada sobre como elas funcionam. Será somente você perguntando: “hey, por favor classifique esta imagem!”. Então a resposta será “legal! Sua imagem tem uma mulher nela”. Mas você não poderá perguntar de volta “qual é a cor do cabelo dela?”;
    • Conclusões?
      • Se as APIs abertas resolvem suas necessidades, não pense de novo e comece a usá-las já! Não se preocupe sobre os fornecedores obtendo suas informações, segurança, ou coisas do tipo. Uma vez que você paga pela ferramenta, você possui um contrato que diz que eles não usarão seus dados. É a mesma questão da cloud;
      • Se não resolve suas necessidades, tente entender quão importante é ter aquele 1% a mais de confiabilidade no julgamento da IA. Se você realmente precisa de algo mais preciso, pule para “treinando um modelo”;

 

  1. Treinando um modelo
    • Abordagem meio-termo. Há muitos modelos prontos para serem adicionados a projetos, configurados, treinados e então usados. Falarei sobre esta abordagem no próximo artigo;
  2. Construindo um modelo
    • Tenha em mente que este não será um projeto de TI por algum tempo. Você deverá ter pessoas de física, matemática, bons especialistas no seu negócios e muitas informações boas para adicionar ao seu projeto desde o início. Uma vez que eles finalizarem o model (o que potencialmente pode tomar 2 anos. Talvez mais), então se tornará um projeto de TI começando do passo “treinando um modelo”. Estes dois projetos (construindo e treinando) tomarão mais do que dois anos de pesquisa e testes. Se este é um processo estratégico na sua companhia, não perca mais tempo e comece o projeto. Quanto antes começar, mais cedo os benefícios virão;

 

Legal! Quais são as APIs prontas para uso?

Minhas sugestões estão dentro desta tabela abaixo. Mas as opções não são limitadas a ela. Você pode encontrar muitas outras. Estas são mantidas pelos maiores provedores de cloud e IA. Isto significa que você pode confiar nelas e provavelmente dentro do seu foco, serão as melhores existentes.

Funcionalidade Google IBM Microsoft Amazon
Chatbot DialogFlow Watson Assistant and Virtual Agent Bot Lex
Análise de vídeo Video Intelligence Intelligent Video Analytics Video Indexer Rekognition
Análise de imagem Vision Visual Recognition Computer Vision API Rekognition
Fala para texto Speech Speech to Text Bing Speech Transcribe
Texto para fala Text to Speech Bing Speech Text to Speech
Classificador de linguagem natural Natural Language Natural Language ClassifierNatural Language UnderstandingPersonality Insights and Tone Analyzer Language Understanding Comprehend
Tradução Translate Translator Translator Translate
Busca de tendências e análises Trends Discovery and IBM’s Discovery News
Encontrar padrões em texto não estruturado Knowledge Studio
Moderador de conteúdo* Anomaly Detection
Descoberta de empregos Job discovery**

* Google, IBM e Amazon possuem moderador de conteúdo dentro das suas soluções. A Microsoft possui este produto específico procurando por anomalias somente.

** Job Discovery é uma ferramenta proprietária ainda disponível somente para alguns parceiros.

 

Dois exemplos para falar sobre os limites novamente
Reconhecimento de imagem

Assim como o exemplo acima: um cliente veio até mim perguntando sobre uma solução para identificar imagens em pessoas. Legal! Vamos usar o Google Vision! O Vision identifica pessoas nas fotos e dá muitas outras informações sobre as cores daquela imagem, lugares que a imagem contém e etc. Mas então o cliente me perguntou: quero identificar se a pessoa na imagem é uma mulher. Eu disso OK! E então: quero reconhecer a cor do cabelo da mulher. Ok, todas as APIs abertas estão fora do jogo. Vamos encontrar um modelo, treinar e então obter a cor do cabelo. Para você ser capaz de responder a este tipo de pergunta não há atalho. Precisará ler as documentações de cada uma das APIs abertas que encontrar e também executar alguns testes.

Reconhecimento de vícios de linguagem

Outro cliente veio até mim questionando se eles poderiam dar um microfone aos seus funcionários para que eles pudessem operar um sistema inteiro somente através de comandos de voz. Ok, isto não é novo. Poderíamos usar uma combinação de APIs de “fala para texto” e análise de linguagem natural. Vamos em frente! Mas então o cliente disse que o sistema deveria reconhecer termos internos da companhia, como acrônimos e palavras que eles inventaram para se comunicar de forma otimizada. Erm… isto não é possível. Não podemos treinar APIs prontas para uso para entender termos específicos. O caminho mais fácil foi sugerir que os operadores mudassem as palavras que usam para se comunicar e o sistema entenderia. Se não, eles precisariam procurar por modelos, configurar e treinar para que ele entenda as novas palavras.

 

Então, porque você não começa seus testes de AI avaliando as APIs prontas para uso? Quanto antes você começar, mais cedo você entenderá como abordar aquele antigo problema.

Exemplos práticos, TI é o negócio, Transformação digital

A nuvem é o novo básico

março 15, 2018

Escutei “a nuvem é o novo básico” (cloud is the new black) durante uma seção de treinamento dentro de um escritório da Google. Mas porque eles disseram isso? A Google não criou esta frase bonita. Foi o Gartner.

O que o Gartner quis dizer com “a nuvem é o novo básico”? Em termos rápidos, o Gartner diz que o mercado cloud tem potencial de US$ 1 trilhão. Atualmente é somente US$ 56 bilhões.

A Google repete isto por objetivos comerciais evidentemente. As razões são as mesmas de Microsoft, AWS e de qualquer outro cloud provider: escalabilidade, estabilidade, abstração de infraestrutura e o mesmo bla bla bla de sempre. E eu concordo totalmente com estas razões. Mas deixando de lado estas questões técnicas, para os resultados $$$ do negócio final, porque a nuvem é tão básica?

 

Mas como isto se encaixa no nosso negócio?

Sim, há muitas empresas migrando para cloud e já começando suas aplicações na cloud. Mas consigo encontrar facilmente muitas empresas ainda nem sequer considerando mover-se para cloud. Dentro da minha realidade isto é algo difícil de entender. Como eles podem não ver os benefícios da cloud? Como eles podem usar máquinas normais e gastar milhões de dólares comprando mais e mais storage a cada 6 meses? Para mim é perda de tempo. Vou explicar o porque.

Physical space

As salas em que as máquinas estão localizadas. Elas custam dinheiro. Em algumas empresas, já vi quadras de ruas em áreas nobres da cidade de São Paulo sendo usadas para hospedar… máquinas. As empresas não precisam que o datacenter esteja tão próximo dos escritórios. Não precisam de latência tão baixa. Tenho 100% de certeza. Certamente se eles removessem tudo e alugassem o espaço, o aluguel pagaria uma bela fatia do custo mensal da cloud. E se elas vendessem este espaço? Significaria mais investimentos para departamentos que precisam do dinheiro para inovar e se manter a frente de seus competidores. Por causa desta falta de dinheiro, as áreas estão perdendo tempo. É perda de tempo.

Retrabalho

Recentemente um datacenter próximo da empresa em que trabalho sofreu um incêndio. Muitas aplicações core e não-core de empresas governamentais e privadas foram afetadas. E onde estavam os backups? Dentro do mesmo prédio. Por causa do incêndio, os bombeiros e a polícia não deixaram o time técnico entrar e mover a informação para outro datacenter. A replicação também não estava automatizada. Isto causou mais de 12h de sistemas indisponíveis. Você consegue imaginar alguma empresa dentro de qualquer indústria sem receber transações por 12? Imagine a área financeira. Difícil. Agora imagine uma fábrica sem sistemas por 12h. Eles não vão vender durante um dia todo? Você pode responder “sim, mas neste caso nós podemos anotar e transcrever para o sistema depois”. Os funcionários nem lembram mais como segurar uma caneta. A empresa também não saberá quanto produziram do que eles produzem. Não saberão quanto gastaram produzindo. Mas a questão principal aqui é o excesso de trabalho que será criado dentro destas companhias para colocar tudo de volta aos sistemas. Falando sobre o Brasil, a empresa pode inclusive ser multada pelo governo por não controlar transações de um dia. O que isto significa? Perda de tempo.

Porque não cloud?

Tenho um cliente que executa uma solução de varejo na cloud. A solução está em execução há mais de dois anos sem downtime. É uma solução core para o negócio deles? Não é. Mas o fato dela não trazer dores de cabeça os salva tempo para pensar em outras coisas. Reduz a quantidade de tickets no time de infraestrutura. Melhora inclusive sua saúde mental com menos stress. É claro que a nuvem somente não é a resposta mágica para a estabilidade da aplicação. Eles realmente se importam  com a qualidade do processo de desenvolvimento. Então todos estes benefícios vêm facilmente. Isto NÃO é perda de tempo.

 

Quando as empresas decidirão migrar para a cloud?

Tudo isto me faz pensar que usar cloud é relacionado a maturidade. Agora um link rápido com startups relacionadas a internet: empresas que crescem percentuais inacreditáveis todo ano em todo o mundo. A maior parte delas tem a nuvem em comum. Muitos de seus modelos de negócios não seriam possíveis sem a nuvem.

As empresas tradicionais, que já sentiram as startups “incomodando” suas fatias de mercado, estão se movimentando, ou já se moveram para a cloud.

Porque isto acontece? Porque a nuvem dá a elas a velocidade de que precisam. Coisas que tenho visto sobre ambientes on-premise VS cloud:

  • Um novo ambiente para desenvolver uma nova aplicação pode tomar até um mês para ser disponibilizado, pelo time de infraestrutura, para o time de desenvolvimento iniciar o trabalho. Isto significa um mês a menos no projeto. Dentro da cloud, isto pode ser resolvido em meia hora.
  • Informações de Analytics sendo geradas somente com os dados de “D-1” (somente com informações do dia anterior). Na nuvem podemos ter os dados na hora para tomar decisões.
  • Analizar petabytes de informações sem ter que esperar o final de semana para fazê-lo, que é quando não haverá concorrência com outras aplicações em execução. Na nuvem pode-se fazer quando quiser, sem precisar planejar a compra de milhões de reais em infraestrutura antecipadamente.

Todos estes exemplos querem dizer a mesma coisa: quando as companhias começarem a sentir que estão sendo deixadas para trás porque são mais lentas que seus competidores (sejam eles startups ou não), elas migrarão.

 

Então, porque a cloud é básica?

Então… voltando, porque a cloud é básica? Porque ela significa velocidade. Porque se este artigo fez você lembrar de algum problema que está tendo, ou pode ter dentro de seu time, significa que você irá correr atrás dele para resolver! Mas não será rápido encontrar todos os responsáveis pelos sistemas e pedi-los que mudem para suas novas concepções. Tomará semanas. Meses ao menos. Estas semanas ou meses gastas pelo time procurando como consertar ou prevenir algo de acontecer, significa que serão semanas ou meses sem olhar para a melhoria do negócio, sem olhar para estar a frente de seus competidores. A área de TI não é mais suporte. Não pode SOMENTE estar preparada para o que as  outras áreas exigirão. Ela PRECISA ser uma das áreas de negócio líderes. E porque isto é verdade? O time da TI sabe o que a tecnologia pode fazer. As outras áreas não.

TI é o negócio, Transformação digital

É hora de olhar para Machine Learning

março 1, 2018

Machine Learning (ML) é a nova palavra do momento. Assim como SOA já foi, assim como DevOps já foi. Agora todos falam sobre ML. Todos querem obter seus benefícios miraculosos, mas apenas poucos sabem realmente o que é, suas possibilidades e os caminhos mais rápidos para começar a obter resultados.

O que é ML?

Wikipedia (em inglês) diz que “Machine learning é um campo da ciência da computação que dá a sistemas computacionais a habilidade de “aprender””.

Ok, entendido. Mas o que é Machine Learning? O que pode atingir? Vamos a alguns exemplos:

Recomendações do Netflix

O Netflix disse, durante o Cassandra Summit de 2016, que tudo o que mostram é recomendações. Os slides estão disponíveis aqui (também há um vídeo no Youtube ao final) (inglês apenas). E as pessoas adoram! 80% do que assistimos é recomendado. Não procuramos ativamente. Está a um clique de distância.

Eles adquiriram 5.2 milhões de novos usuários entre maio e junho de 2017. Se você foi um deles, você certamente não preencheu um grande questionário dando informações sobre que gêneros você mais gosta, nem mesmo os que não gosta. Além disso, eles não possuem o maior número de estagiários do mundo para ler 5.2 milhões de questionários dos novos usuários e humanamente sugerir filmes para que assistam. Estas recomendações foram feitas e continuam sendo feitas e atualizadas dentro de poucos minutos logo após você demonstrar qualquer tipo de sinal de que você gosta ou não de algo. Assistiu algo? Marcou como “assistir depois”? Marcou como “like” ou “dislike”? Tudo conta. Tudo isto atualiza seu perfil e novas sugestões podem vir.

Google Maps

Agora veja este segundo exemplo mais complexo. Esta imagem do Google Street View mostra um estacionamento na Rua Primeiro de Março em São Leopoldo (pequena cidade no sul do Brasil):

Tenho 100% de certeza de que o Estacionamento Beto não enviou dados para o time do Google Maps. Eles não preencheram um formulário dizendo que estão em São Leopoldo. Seu dono provavelmente possui um celular com internet. Mas provavelmente ele nem sabe que isto é possível, e talvez ele talvez nem saiba o que é o Google Maps. Mas ele está lá:

O Machine Learning aqui é algo já tangível usando uma API do Google para analisar imagens. Eles analisaram a imagem do Street View, e a máquina soube que era algo com intenções comerciais. Então o algoritmo automaticamente registrou como algo a ser mostrado no mapa. Se você olhar na rua real do Street View, você provavelmente verá que aquela quadra é quase completamente residencial. O algoritmo da Google sabia a diferença entre uma construção comercial e residencial.

Alguns outros
  • Facebook sugere que você marque seus amigos em suas faces, quando você envia uma nova foto. Isto é Machine Learning. O Facebook não possui uma foto de cada pessoa no mundo para comparar quando eles recebem novas fotos;
  • Quase todos os e-commerces que conhecemos atualmente o fazem, mas a Amazon foi quem começou: sugestão de produtos baseado nas últimas compras que você fez;
  • Obter informações sobre sua conta diretamente no chat do Facebook. Já é possível reconhecer muitas diferentes formas de questionar “qual é meu saldo?”;

 

Como se beneficiar?

É muito fácil pensar em novos cenários, mais ou menos complexos. Automatizar predições ou algo que atualmente requer a mente de uma pessoa já é, ou será, possível.

Exemplo! Sabemos que o mercado de ações possui padrões em seus comportamentos e é afetado por muitas coisas. Atualmente muitas pessoas gastam seu dia inteiro (ou sua vida inteira) analisando dados e dando predições aos outros sobre o que fazer com suas ações (ordens de compra/venda).

Os pontos vermelhos (meus) nos dados acima (do tradingeconomics.com) mostram momentos quando o mercado começou ciclos de perda durante os últimos 10 anos. Entre todos estes exemplos, nós já tínhamos um arsenal de técnicas de análise que ajudou a identificar quando é mais ou menos provável que algo assim aconteça novamente. Mas (ainda) requer muitas pessoas distribuídas entre diferentes empresas para TALVEZ encontrar algo significante. Ter um bom modelo de Machine Learning pode mudar todo este mercado. Pode tornar algo injusto de se investir o dinheiro, uma vez que partes da análise podem ser tornar previsíveis.

Mas como começar?

Um bom novo modelo de Machine Learning passa, invariavelmente, por uma enorme quantidade de dados estruturados. Os dados são necessários para treinar o modelo para só então atingir o objetivo real de negócios. Um bom ponto de partida é definir uma base estruturada de dados para ser usada. Você também precisará de um cientista de dados. Não se preocupe pois ele não é um alien. São potencialmente fáceis de se encontrar. Mas isto é assunto para outro post.

Evitando problemas, Exemplos práticos, TI é o negócio

5 grandes erros de empresas que foram para cloud sem um bom plano

fevereiro 21, 2018

Muito se discutiu, e ainda se discute, sobre a jornada para nuvem. As grandes empresas do mundo já possuem suas estratégias voltadas para a nuvem desde quando as aplicações são idealizadas. Potenciais de segurança, escalabilidade, autonomia e outros assuntos relacionados já não são mais abordados na hora de discutir projetos. A nuvem já não gera mais dúvidas ou desconfianças há algum tempo. Uma vez que a ida para cloud já é assunto vencido, além dos pontos de atenção já levantados, trago alguns erros que presenciei serem cometidos, como forma de apoiar estratégias de movimentação ou outras:

 

Encarar nuvem como suporte

A nuvem é protagonista nas aplicações. É muito comum que empresas comecem suas jornadas com rotinas simples de backup ou storage na nuvem para desonerarem seus datacenters próprios. Isto é um passo importante, muitas vezes necessário para passar segurança a um board cético sobre a mudança. Porém as rotinas de rollback, backup, disaster recovery, e outras muito complexas para os times de OPS já são triviais para os grandes players de nuvem. Usá-las com este fim é como subestimar o potencial da nuvem.

Serviços auto-gerenciados possuem nível de automação dos aspectos mencionados acima altíssimo. O time de operações se beneficia de automações de processos que antigamente lhe consumia enorme tempo e dinheiro em planejamento e execução de projetos. Os serviços que não são auto-gerenciados também possuem muita automação embarcada. Backup, rollback e DR são básicos.

 

Negligência ao executar a matriz de decisão

A opção por um ou outro cloud provider é algo de importância muitas vezes subestimada. Escolher um provedor de nuvem é um casamento que pode trazer relações conturbadas! Tenho visto empresas querendo fugir de seus contratos traumáticos de 10 ou 20 anos com players gigantes como Oracle ou IBM, negligenciando matrizes de decisão de cloud, e assinando outros contratos que os levarão a mais 10 ou 20 anos com X ou Y provider.

Grandes players como Google, SAP, Azure, IBM e SAP permitem um nível de customização altíssimo, que deve ser avaliado na decisão. Estas permitirão configurar todos os aspectos necessários a uma grande aplicação que possua dependências, integrações, relações com outros sistemas e que exigirão práticas customizadas de engenharia. É muito comum também que aplicações complexas possam agregar benefícios de operações em multi-cloud.  Por exemplo: infraestruturas que possuam custo mais atrativo no provider X podem se beneficiar de recursos FaaS de Bigdata do provider Y que é mais veloz ao tratar grandes volumes de dados. Desta forma uma única aplicação pode estar distribuída em mais de um provedor de nuvem, também em mais de uma região geográfica, viabilizando objetivos de negócio como economia, redução de delay e acesso a features exclusivas de players de nicho.

Em paralelo aos grande players, há diversos provedores de nicho de PaaS, FaaS. Digital Ocean, Heroku, Umbler e Elastichosts, por exemplo, são úteis para aplicações que não precisam de tanta robustez. O nível de abstração destas plataformas é altíssimo, o que permite uma curva de aprendizado do time de desenvolvimento e/ou operações muito pequena.

 

Desconhecer o potencial da nuvem escolhida

A economia que pode ser atingida aproveitando recursos da nuvem, como rollback, DR, backup (citados acima), monitoramento, alertas e ações automatizadas, é altíssima e deve entrar na conta das organizações ao conduzirem seus projetos de migração.

Serviços de PaaS para executar aplicações, ou FaaS para automação de tarefas de redes, Machine Learning, deploy, testes, e outros precisam ser avaliados. Como exemplo cito que toda empresa que possuía software sendo executado em infraestrutura on premise, acabou em algum momento desenvolvendo softwares para amadurecer suas práticas de testes ou deploy. Isto significa que, caso 10 empresas tivessem desenvolvido softwares similares, ao custo de 500h cada, teríamos 5000h duplicadas sendo investidas. Com serviços como CodeDeploy, Device Farm, Fastlane e Firebase, este tipo de desenvolvimento não é mais necessário. Com contratações rápidas, muitas horas de desenvolvimento são economizadas, dando velocidade às empresas, e significando que conseguirão responder às necessidades de seus clientes mais rapidamente.

 

Falta de rastreio sobre o investimento

Ainda é comum que o orçamento para cloud seja uma caixa preta. O rastreamento detalhado deste investimento deve ser mantido por pessoas capazes e ser separado por aplicação/negócio/o que fizer sentido naquela realidade. Desta forma decisões assertivas poderão ser tomadas, como a contratação ou descontinuação de determinado serviço contratado. Isto é mais uma prática que evita que o “casamento” com o cloud provider possa se assemelhar aos contratos de muitos anos com Oracle, IBM e etc, dos quais toda grande empresa tenta fugir hoje. Já cometemos erros no passado. Vamos aprender com eles!

 

Falta de atualização do time responsável

Como exemplo, ainda é comum empresas investirem grandes quantias de dinheiro comprando muitos diferentes aparelhos móveis para testar seus aplicativos. O desconhecimento dos serviços que permitem testes automatizados nestes dispositivos fará com que este dinheiro continue sendo desperdiçado e benefícios da automação disponível não cheguem até o processo de desenvolvimento.

Com cada vez mais competidores qualificados de nicho surgindo, a falta de atualização pode ser um grande problema. Desconhecer boas alternativas a serviços já existentes e consumidos pelas empresas, fará com que elas nunca sejam descobertas e seus benefícios não sejam utilizados.

Clientes, Exemplos práticos, TI é o negócio, Transformação digital

Processo de compra de software na evolução da TI

fevereiro 14, 2018

Quanto mais diferentes visões você possui sobre o mesmo assunto, mais informações você terá para tirar suas conclusões e tomar decisões se necessário. Este primeiro artigo sobre a evolução da TI teve uma visão de desenvolvedor e muito superficial de negócios. Este novo artigo procura olhar pela perspectiva de clientes comprando software e como estas visões são diferentes dentro de uma mesma indústria.

 

Como software costumava ser comprado

Nos últimos anos, empresas costumavam comprar software como qualquer outro produto: quero 5 carros com 4 rodas cada, transmissão manual e de cor branca. Elas não se importavam em como o software é produzido, ou qualquer tipo de boa prática para aplicar ao processo. Sim, dentro de documentos de requerimento de software havia sessões sobre segurança, protocolos e coisas como estas, mas no final de tudo, o menor preço venceria.

 

Velha (não tão velha) matriz de decisão

A matriz de decisão (exemplo abaixo usando o processo de compra de um carro) era muito simples de se ter critérios levantados. Eles também eram superficiais. O critérios em alto nível eram facilmente elencados como: níveis de segurança, performance, cronograma proposto, preço, cobertura do escopo, cases de sucesso, conhecimento na tecnologia selecionada, etc. Com esta matriz de decisão, os pesos eram dados de acordo com cada projeto. Mas o preço e o cronograma, depois de todas as avaliações de critérios ainda determinariam quem ganha.

No exemplo acima: o que exatamente é conforto e estilo para este comprador? Segurança pode ser avaliada usando dados públicos do governo. Este é o paralelo para mostrar como nenhum dos critérios está detalhado.

Qualquer um dizendo que poderia cobrir todo o escopo, dentro do cronograma solicitado, tendo uma quantia de dinheiro fixa, poderia vencer a batalha pelos projetos. Se eles não possuíam o conhecimento suficiente, não faria grande diferença. Depois de tudo, software era tratado como qualquer outro produto. Não importava como era feito. Só importava que funcionasse.

 

Matrizes de decisão recentes

Deixando de lado a indústria governamental, e poucas outras não afetadas nem um pouco pela transformação digital, a realidade tem mudado.

O que tenho visto ultimamente é um investimento maior de tempo no detalhamento dos critérios. Para cada um dos critérios, os compradores querem saber o que os fornecedores já fizeram, como eles planejam conduzir a solução e também avaliar alternativas para tudo.

  • Segurança: garantir que a troca de informações acontecerá dentro de um ambiente controlado? Táticas para obfuscação de código. Preocupações com segurança natural das plataformas. Certificações dos cloud providers, etc;
  • Cronograma: de “um cronograma detalhado” (que nunca era atingido) para “uma visão macro de tempo e um mix de metodologias ágeis para serem seguidas”;
  • Casos de sucesso: mostrar onde/quando soluções similares foram criadas;
  • UX: de “o sistema precisa ter boa usabilidade” (completamente subjetivo) para “precisa seguir guidelines de UX da Google e ser conduzida por um profissional adequado, e não pelos desenvolvedores”;
  • Performance: de “o sistema precisa carregar dentro de 10 segundos” para “cada endpoint precisa responder dentro de 2 segundos”;
  • Escopo: de “tudo deve ser contemplado” para “vamos fazer o máximo que pudermos dentro do cronograma”;

As companhias querem saber como seus projetos serão conduzidos em detalhes, e elas também querem colocar suas opiniões sobre tal. Uma vez que a transformação digital está fazendo as companhias entenderem que a TI é o core, a TI deixa de ser suporte. Então agora elas são capazes de fazer sugestões e falar no mesmo nível das consultorias.

Com esta comparação e cenário de evolução, o mindset de MVP fica muito claro. Também os objetivos de atingir time-to-market e receitas mais velozes.

 

Requisições diferentes dentro da mesma indústria

O relato acima é correto para 100% das companhias nas indústrias mais maduras do Brasil. Porém para o resto delas, usando varejo como exemplo, ainda não:

Há lojas que já estão evoluingo seus ecommerces para segurança, performance, escalabilidade, estabilidade e o mais importante: experiência do usuário. Mas também há aquelas que tratam suas lojas online como algo necessário somente. É comum a cópia de práticas de layout dos concorrentes. Também, segurança é algo caro. Algumas empresas possuem budget para perder devido a invasões de hackers, em vez de investir em segurança naquele momento.

A boa notícia é que o mercado está evoluindo cada vez mais rápido. Em breve nenhuma indústria estará para trás.