Ivens Rocha - Business Analyst, Webjump falou sobre Comprando um e-commerce ou marketplace Magento: do primeiro dia ao primeiro dia! durante o Marketplace Conference 2019
4. O processo de compras atual funciona da
mesma forma que sempre funcionou
5. Algumas coisas parecem não fazer sentido, mesmo
que tenham sido daquela forma desde sempre
6. Quem sou
Ivens Rocha
● Bacharel em Ciência da Computação - UNINCOR
● Pós-graduação em Engenharia de Software -
Universidade Federal de Lavras
● MBA em Engenharia de Software - FIAP
● Desenvolvedor
● Líder de times de desenvolvimento de E-
commerce
● Magento 2 Certified Solution Specialist
● Analista de Negócios / Especialista de Solução
na Webjump
7. ● Para quem decide a compra.
● Para quem influencia na compra.
● Para curiosos sobre o processo de
compras.
Para quem é essa apresentação?
13. O lançamento de uma
Request For Proposal é o
caminho mais comum de
buscar parceiros
RFP
14. Requisito Resposta da Agência
Permite ter um sistema de tickets dentro da plataforma Permite, mas você quer isso?
Requisitos de capacidade e não de desejabilidade
Tipos comuns de requisitos em RFPs lançadas no mercado
15. Requisito Resposta da Agência
E-mail transacional Atende, a plataforma possui, mas quais e-mails você
espera?
Permite cadastro de usuário com validações Permite cadastro e possui validações de campos, mas
quais campos espera-se que sejam validados?
Requisitos que podem ser atendidos de forma 100% nativa, dependendo da definição do cliente
Tipos comuns de requisitos em RFPs lançadas no mercado
16. Requisito Resposta da Agência
[Comercial] Integração com Google AdWords Atende
[Marketing] Google AdWords Atende
[TI] Integração com sistema de publicidade do Google Atende
Requisitos duplicados
Tipos comuns de requisitos em RFPs lançadas no mercado
17. Cuidado ao comparar “maçãs e laranjas”
Plataforma
SaaS
API
SAP
Atende nativamente
Magento
API
SAP
Atende por integração
18. Falta de visão de
produto cria
marketplaces
Frankensteins
25. Exemplificação • Contrato por Entrega Incremental
Cenário
O valor do serviço de intermediação do marketplace deve ser calculado pela plataforma e
repassado diretamente para a conta do seller. A comissão deve ser configurada a nível de seller.
RFP do Cliente
REQUISITOS
Seller preenche seu merchant ID para identificação de sua conta no gateway de pagamentos
Configuração de comissão por seller
Split de pagamento no checkout para valor de intermediação (marketplace) e venda (seller)
27. MAIOR
CERTEZA
Fase 1
Comissão fixa
para todos os
sellers.
Identificação do
seller no gateway
feita pelo
backoffice do
Marketplace.
Fase 2
Comissão por
seller.
MENOR
CERTEZA
28. MAIOR
CERTEZA
Fase 1
Comissão fixa
para todos os
sellers.
Identificação do
seller no gateway
feita pelo
backoffice do
Marketplace.
Fase 2
Comissão por
seller.
Fase 3
Identificação do
seller no gateway
feita pelo próprio
seller.
MENOR
CERTEZA
29. Divide et impera
Capacidade
Requisito Resposta
Capacidade para customizar e-mails transacionais Atende
Desejo
Requisito Resposta
Deve enviar um e-mail transacional para pedido Concluído,
exclusivo para clientes que fizeram a compra por boleto.
Atende
33. O “segundo primeiro dia”:
o início do desenvolvimento
Processo de compras colaborativo,
com RFPs bem descritas e com
abertura para faseamento tende a
resultar em propostas razoáveis,
em times mais bem informados
e em produtos coerentes.
39. Por conta da mentalidade de
venda de balcão, a maior
parte dos stakeholders com
baixa maturidade digital
querem tudo, na primeira
fase, sem exceção.
Vocês ouviram falar deste caso que ficou bem popular no LinkedIn no começo do ano?
A segunda maior empresa de aluguel de carros dos Estados Unidos decidiu melhorar sua presença online. Para isso estabeleceu uma lista de requisitos, buscou no mercado a maior consultoria de TI do mundo, fechou contrato e iniciaram o projeto. A expectativa de entrega era Dezembro de 2017. Mas ocorreu um atraso e o prazo foi adiado para Janeiro de 2018 e depois para Abril de 2018, que também foi um prazo perdido. Além disso, o cliente havia solicitado um site responsivo que não foi entregue. As demais funcionalidades vieram todas quebradas. O resultado disso é que o cliente agora processa a consultoria no valor equivalente 128 milhões de reais.
Não há de fato uma pesquisa, um estudo científico que indique o que o comprador de e-commerce mais tem receios.
Mas é possível trazer nossa experiência como compradores diários, seja de pão a carros, para assumir que um dos principais medos são:
Será que estou escolhendo o parceiro confiável?
Será que a tecnologia selecionada é adequada?
E, na minha opinião, o principal medo: será que a agência vai entregar o que esperamos, no prazo e sem solicitar orçamento extra?
Para quem já lidou com processo de compras sabe como pode ser demorado: para e-commerce pode levar 2, 4, 6 meses entre idas e vindas.
O processo de compras, quando estruturado, passa por diversas etapas:
https://blog.procurify.com/2013/04/03/the-complete-procure-to-pay-cycle/
Identificação dos requisitos
Solicitação de autorização de Compra
Aprovação da autorização da compra
Compras
Identificação dos Fornecedores
Questionamentos
Recebimento da Cotação
Negociação
Seleção do fornecedor
Recebimento da Ordem de Compra
Fatura entra no sistema de compras
Validação da consistência da OC, o que foi recebido, etc
Pagamento
É muita coisa! Muita etapa e muita gente opinando no que deveria ou não ser feito. Será que ainda faz sentido este processo, especialmente para projetos complicados e, grande parte das vezes, complexos como um e-commerce?
E não sei para vocês, mas me parece que fazemos as coisas porque elas sempre foram daquela forma.
É necessário questionar se realmente faz sentido.
Em 2015 perdi as notas fiscais em papel da minha antiga empresa. A Secretaria da Fazenda do Distrito Federal normatizava que eu teria que anunciar em um jornal de grande alcance regional informando que as notas foram extraviadas.
Para vocês parece fazer sentido, mesmo que outras pessoas façam desta forma?
Bom, mas antes de entrar no conteúdo, preciso falar quem sou eu… Fui rude por começar a apresentação sem me apresentar, não é mesmo?
Fui desenvolvedor de software por 10 anos, quando então iniciei minha jornada de líder de times de desenvolvimentos de e-commerce. Em relação a academia sou graduado em Ciência da Computação, com pós-graduação e um MBA em Engenharia de Software. Já fui desenvolvedor Magento, líder de time de alguns projetos nacionais e globais e desde o começo deste ano venho trabalhando como Analista de Negócios / Consultor de Soluções na Webjump. Também sou um dos 5 profissionais certificados como Especialista de Solução pela Magento, no Brasil.
Para quem já comprou ou está em vias de comprar um e-commerce Magento.
Para quem tem curiosidade da perspectiva de uma agência sobre o processo de compras, seja a pessoa desenvolvedora, designer ou compradora, etc.
Para profissionais que influenciam em compras de e-commerce dentro de empresas de médio a grande porte, mas com sugestões que podem ser aplicadas integralmente a pequenas empresas.
Vocês ouviram falar deste caso que ficou bem popular no LinkedIn no começo do ano?
A segunda maior empresa de aluguel de carros dos Estados Unidos decidiu melhorar sua presença online. Para isso estabeleceu uma lista de requisitos, buscou no mercado a maior consultoria de TI do mundo, fechou contrato e iniciaram o projeto. A expectativa de entrega era Dezembro de 2017. Mas ocorreu um atraso e o prazo foi adiado para Janeiro de 2018 e depois para Abril de 2018, que também foi um prazo perdido. Além disso, o cliente havia solicitado um site responsivo que não foi entregue. As demais funcionalidades vieram todas quebradas. O resultado disso é que o cliente agora processa a consultoria no valor equivalente 128 milhões de reais.
Não há de fato uma pesquisa, um estudo científico que indique o que o comprador de e-commerce mais tem receios.
Mas é possível trazer nossa experiência como compradores diários, seja de pão a carros, para assumir que um dos principais medos são:
Será que estou escolhendo o parceiro confiável?
Será que a tecnologia selecionada é adequada?
E, na minha opinião, o principal medo: será que a agência vai entregar o que esperamos, no prazo e sem solicitar orçamento extra?
O medo do cliente faz sentido.
Apesar disso, é importante ficar atento para o conselho do Mestre Yoda: o medo é o caminho para o lado negro da força. E este lado, no contexto de compra de e-commerce, em geral resulta nos extremos:
No primeiro extremo o comprador que acredita que precisa adicionar requisitos cada vez mais complexos e detalhados para reduzir o risco. Isso ocasiona em custo elevado, pois a agência também precisa garantir que o risco dela está mitigado para tantos requisitos, afinal, muito embora o processo é de compra, a agência também pode recusar trabalhar em um projeto dependendo do seu risco. Além disso, não dá margem para ajustes em tempo de projeto, pois uma funcionalidade que pode ser útil agora pode não ser mais útil no quarto mês de desenvolvimento.
No outro extremo o comprador que tem medo de adicionar todos os requisitos ou deixá-los extremamente vagos com receio do custo que a agência pode fornecer. Isso faz com que a agência subestime o esforço e você tenha surpresas com custo durante o desenvolvimento.
O Cone da Incerteza é utilizado desde os anos 80 como uma forma gráfica de demonstrar como a certeza sobre um projeto ou suas funcionalidades aumenta conforme o tempo passa.
Agora, imagine este cenário: queremos comprar um e-commerce sem riscos, de forma que tudo comprado seja entregue. Se há incerteza quando o projeto começa mais do que durante o projeto, imagine durante a fase de compras, quando nem mesmo projeto há.
O Mike Cohn, que é uma referência no ecossistema ágil diz que não importa a incerteza que a organização enfrenta, esta incerteza também é dos competidores… Quero dizer, os competidores também estão com as mesmas preocupações e receios. Portanto, para derrotar a competição você não precisa de certeza, você precisa lidar com a incerteza de uma forma melhor que eles.
Como vamos ver durante a apresentação, software carrega incertezas inerentes de produtos que trabalham no limiar entre o que é complicado e o que é complexo.
Ou seja, e-commerce além de ser uma casa a ser construída, todos os envolvidos na construção estão descobrindo a melhor combinação de ferramentas, práticas e estruturas para construir cada andar à medida que a construção avança.
E às vezes o proprietário da casa precisa alterar o posicionamento de uma escada, de uma janela, de uma porta com base nas informações que os construtores trazem à cada dia. Ou até mesmo, o proprietário só vai descobrir como espera que a casa fique depois que a fundação já foi concluída.
Muito bem. Agora trazendo o título da palestra e falando sobre o primeiro dia, depois da escolha do Magento como plataforma, inicia-se o primeiro dia da busca por parceiros para o desenvolvimento das customizações.
Magento é algo enorme, que dependendo das configurações pode se transformar e retransformar e se transformar de novo.
Além de ser uma plataforma aberta, onde tudo é possível ser feito. É possível transformar o Magento em desde uma plataforma B2B complexa a um simples B2C com foco em pontos de loyalty & rewards.
De um lado o cliente precisa de escopo e valores fechados e do outro a agência precisa entender o negócio do cliente em prazos desafiadores e com máxima precisão.
Eis que surge a RFP…
A RFP é a sigla para Request for Proposal. Uma solicitação de proposta (RFP) é um documento que solicita uma proposta, muitas vezes feita por meio de um processo de licitação, por uma empresa interessada na aquisição de um produto ou serviço a possíveis fornecedores para enviar propostas comerciais.
Imagine aqui uma lista de requisitos: algumas empresas liberam um conjunto de arquivos, outras apenas uma planilha e outras um PDF contendo o que ela espera que a plataforma contemple.
Quem são, em média, as pessoas que lideram a elaboração de uma RFP? Você tem uma ideia, se dentro da sua empresa hoje teria alguém com capacidade para elaborar uma RFP?
Não importa quem ficará responsável por liderar a elaboração da RFP, desde que essa pessoa tenha uma visão de produto, aliando o negócio, com capacidade de orçamento e prazos, coloque as pessoas envolvidas na discussão, evitando inconsistências entre as diversas áreas que compõem o negócio.
O livro Software Requirements descreve uma função chamada de Product Champion, que é muito similar a uma parte do trabalho que o Product Owner já desempenha em um time ágil, de recolher, detalhar e ordenar requisitos. Esse nome é meio estranho, Product Champion, por isso prefiro chamar de Facilitador.
Os melhores facilitadores tem uma visão clara do ecommerce. Eles são entusiastas das soluções que busca, pois entende como isso vai beneficiar todos internamente e é claro, o cliente.
Esse approach de Facilitador funciona melhor se for um profissional com poder de tomar decisões por conta própria em algumas situações. Se as decisões do facilitador são rotineiramente desautorizadas por outros, o tempo e a boa-vontade dele está sendo desperdiçado.
A agência precisa fornecer uma proposta com custo e escopo fechados, sendo que o escopo ainda precisa ser detalhado, dado as limitações do próprio processo de compra. O cliente espera receber uma proposta com a certeza de que 100% dos itens que pediu serão atendidos exatamente como pediu, muito embora nenhum requisito de RFP é detalhado o suficiente para sabermos o que precisará ser feito.
Sabendo-se que o cliente vai ter que ajudar a diminuir a incerteza, com vimos no cone da incerteza, sabendo-se que contratos ágeis ainda não são uma realidade no mercado brasileiro e diria global, como equilibrar a balança?
Tempo e Material
O contrato ideal, onde o cliente paga a agência pelo tempo de desenvolvimento de cada profissional, ajustando o time de desenvolvimento conforme a necessidade do cliente naquele momento. Para dar previsibilidade de custo, fornecedor e cliente podem combinar um custo teto, onde então o desenvolvimento é interrompido. Normalmente é o contrato utilizado Custo Alvo
Agência define um custo alvo. Caso o fornecedor entregue o produto desejado antes do tempo esperado, o valor economizado é dividido entre cliente e agência. Caso a agência não consiga entregar no prazo e precise de orçamento adicional, o custo adicional é dividido entre agência e cliente. Este tipo de contrato é flexível enquanto premia colaboração entre cliente e fornecedor.
Entrega Incremental
Um projeto é dividido em pequenos mini projetos ou fases. A cada fase, cliente e fornecedor podem encerrar o contrato das fases seguintes ou renegociar a base do contrato. Baseado em nossa experiência, dado o contexto que temos do mercado atualmente, esta talvez seja a opção mais realista, conforme veremos nos próximos slides.
Tempo e Material
O contrato ideal, onde o cliente paga a agência pelo tempo de desenvolvimento de cada profissional, ajustando o time de desenvolvimento conforme a necessidade do cliente naquele momento. Para dar previsibilidade de custo, fornecedor e cliente podem combinar um custo teto, onde então o desenvolvimento é interrompido. Normalmente é o contrato utilizado Custo Alvo
Agência define um custo alvo. Caso o fornecedor entregue o produto desejado antes do tempo esperado, o valor economizado é dividido entre cliente e agência. Caso a agência não consiga entregar no prazo e precise de orçamento adicional, o custo adicional é dividido entre agência e cliente. Este tipo de contrato é flexível enquanto premia colaboração entre cliente e fornecedor.
Entrega Incremental
Um projeto é dividido em pequenos mini projetos ou fases. A cada fase, cliente e fornecedor podem encerrar o contrato das fases seguintes ou renegociar a base do contrato. Baseado em nossa experiência, dado o contexto que temos do mercado atualmente, esta talvez seja a opção mais realista, conforme veremos nos próximos slides.
Tempo e Material
O contrato ideal, onde o cliente paga a agência pelo tempo de desenvolvimento de cada profissional, ajustando o time de desenvolvimento conforme a necessidade do cliente naquele momento. Para dar previsibilidade de custo, fornecedor e cliente podem combinar um custo teto, onde então o desenvolvimento é interrompido. Normalmente é o contrato utilizado Custo Alvo
Agência define um custo alvo. Caso o fornecedor entregue o produto desejado antes do tempo esperado, o valor economizado é dividido entre cliente e agência. Caso a agência não consiga entregar no prazo e precise de orçamento adicional, o custo adicional é dividido entre agência e cliente. Este tipo de contrato é flexível enquanto premia colaboração entre cliente e fornecedor.
Entrega Incremental
Um projeto é dividido em pequenos mini projetos ou fases. A cada fase, cliente e fornecedor podem encerrar o contrato das fases seguintes ou renegociar a base do contrato. Baseado em nossa experiência, dado o contexto que temos do mercado atualmente, esta talvez seja a opção mais realista, conforme veremos nos próximos slides.
Time to market should be improved dramatically (days instead of months), so that delivering business outcome starts earlier
No additional translation step via Legal, lean procurement canvas is an agile contract
Dividindo seus requisitos em etapas, a agência conseguirá criar propostas separadas, dando a previsão de custo que seu negócio espera, com maior grau de certeza nas primeiras fases e menor grau nas últimas fases, que naturalmente não são o foco do cliente no momento (dado que foram categorizados como fase 3).
Com essa separação em fases, ficará mais fácil até mesmo para seu negócio avaliar os custos de cada fases, alterar a ordem de desenvolvimento, remover funcionalidades ou até mesmo criar novas fases. Na negociação comercial é possível fechar todas as fases ou apenas as fases 1 e 2, por exemplo. Assim, o time já começa a trabalhar no desenvolvimento, trazendo o lançamento do e-commerce para mais cedo e atendendo uma demanda comum de time-to-market. A primeira entrega será com menos funcionalidades, sim, mas ao mesmo tempo criará espaço para aprendizado - até mesmo para seu negócio chegar a conclusão que a fase 3 não faz mais sentido e alterar as funcionalidades que ela compõem.
Dividindo seus requisitos em etapas, a agência conseguirá criar propostas separadas, dando a previsão de custo que seu negócio espera, com maior grau de certeza nas primeiras fases e menor grau nas últimas fases, que naturalmente não são o foco do cliente no momento (dado que foram categorizados como fase 3).
Com essa separação em fases, ficará mais fácil até mesmo para seu negócio avaliar os custos de cada fases, alterar a ordem de desenvolvimento, remover funcionalidades ou até mesmo criar novas fases. Na negociação comercial é possível fechar todas as fases ou apenas as fases 1 e 2, por exemplo. Assim, o time já começa a trabalhar no desenvolvimento, trazendo o lançamento do e-commerce para mais cedo e atendendo uma demanda comum de time-to-market. A primeira entrega será com menos funcionalidades, sim, mas ao mesmo tempo criará espaço para aprendizado - até mesmo para seu negócio chegar a conclusão que a fase 3 não faz mais sentido e alterar as funcionalidades que ela compõem.
Dividindo seus requisitos em etapas, a agência conseguirá criar propostas separadas, dando a previsão de custo que seu negócio espera, com maior grau de certeza nas primeiras fases e menor grau nas últimas fases, que naturalmente não são o foco do cliente no momento (dado que foram categorizados como fase 3).
Com essa separação em fases, ficará mais fácil até mesmo para seu negócio avaliar os custos de cada fases, alterar a ordem de desenvolvimento, remover funcionalidades ou até mesmo criar novas fases. Na negociação comercial é possível fechar todas as fases ou apenas as fases 1 e 2, por exemplo. Assim, o time já começa a trabalhar no desenvolvimento, trazendo o lançamento do e-commerce para mais cedo e atendendo uma demanda comum de time-to-market. A primeira entrega será com menos funcionalidades, sim, mas ao mesmo tempo criará espaço para aprendizado - até mesmo para seu negócio chegar a conclusão que a fase 3 não faz mais sentido e alterar as funcionalidades que ela compõem.
No caso da RFP de plataforma, podemos esclarecer pontos de dúvidas sobre a plataforma em si, trabalhando com possibilidades e capacidades, características e benefícios. Até mesmo uma estimativa de custo pode ser passada, mas apenas para dar embasamento da faixa de orçamento da agência, mas não necessariamente garantindo que aquele valor se manterá após a RFP.
Na RFP da agência, então, o cliente esclarece o que de fato ele espera para o e-commerce dele, não do que espera que a plataforma tenha. Não necessariamente precisam vir dois arquivos separados em momentos distintos. A separação aqui se refere a conceito.
A fase de perguntas da RFP deverá ser utilizada, idealmente, para solucionar questionamentos mais complexos, onde uma descrição textual não seja suficiente.
Esta frase foi utilizada pela primeira vez no livro O Mítico Homem-Mês, de 1975. É utilizada para descrever o salto de um sistema simples para sistemas complexos. É a tendência de sistemas pequenos, elegantes e bem-sucedidos serem seguidos de sistemas com complexidade exagerada e inchados, devido a expectativas e autoconfiança inflada. Quando cunhada, a frase mirava em desenvolvedores de sistemas, mas da minha perspectiva se adequa também ao racional por trás da decisão do que deve entrar em novos e-commerces.
A tendência geral é fazer um desgin grande demais no segundo sistema. Na imagem, o segundo sistema é ilustrado pela Torre de Babel.
O cuidado que as pessoas colocam em desenvolver as features gradativamente no primeiro sistema é perdido no segundo sistema, quando quer entregar TUDO. Isso é muito comum em e-commerces que serão migrados.
Um caso famoso que aconteceu nos Estados Unidos foi o lançamento de um produto que pretendia revolucionar a forma de fazer suco. Como uma máquina de café, bastaria colocar um sachê, apertar um botão e o suco sairia. O problema é que o suco já estava no sachê.
Bastava apertar para o suco sair, sem necessidade da máquina, que custava 700 dólares e só funcionava conectada à internet.
Isso é um exemplo. Será que quando pensamos num e-commerce não estamos querendo adicionar capacidades que não fazem sentido?
É necessário ter o entendimento de que nunca será alcançado uma lista de requisitos perfeita.
Isso quer dizer que algumas vezes alguns requisitos poderão ter incerteza: e tudo bem, os times de projeto terão que trabalhar desta forma, reduzindo o gap quando necessário.
Mas uma lista de requisitos bem definidos, com humildade para reconhecer que às vezes, nas primeiras iterações não é necessário ter tudo, colaboração com cliente, o processo de compra tende a satisfazer as necessidades das pessoas que estão dentro da empresa além de encontrar parceiros para o desenvolvimento que iniciarão o desenvolvimento com insumos suficientes para desenvolver e fazer as primeiras entregas.