Em Busca do Produto de Sucesso - Parte 7 - Case ATM Adattis (1)
- Fabio Sant'Ana
- 16 de mar. de 2018
- 6 min de leitura
Nos posts anteriores expus o que seria, para mim, um Produto de Sucesso. Começo, agora, a contar sobre um produto real o qual desenvolvi e como essa metodologia de trabalho foi aplicada.
Apesar de usar o desenvolvimento do ATM Adattis como exemplo, este case não é da história do produto, mas sim como a metodologia foi aplicada em seu desenvolvimento de design.
Um case contando sobre o ATM Adattis será apresentado neste blog, posteriormente.

É importante dizer que, a visão que será apresentada é a do designer sendo funcionário da empresa. E, no case seguinte, onde será apresentada a Catraca Retrofit da Smart Fit, a visão será do designer como proprietário de um escritório de design e contratado para este desenvolvimento específico.
Para começar a falar do produto, é importante lembrarmos quais são as etapas as quais precisamos passar para facilitar o desenvolvimento correto do produto.
1. Designers. Quem são, o que fazem, suas consequências e responsabilidades.
Se não começarmos olhando para isso, os demais itens não terão importância.
Não leu este Post (Produto de Sucesso - Parte 2)? clique AQUI e confira.
2. Integração, cocriação, humildade e troca. Lembre-se que isso será fundamental!
Não leu este Post (Produto de Sucesso - Parte 3)? clique AQUI e confira.
3. Conseguir todas as informações relevantes ao projeto e entender e planejar como cama uma delas deve ser incorporada no projeto.
Não leu este Post(Produto de Sucesso - Parte 4)? clique AQUI e confira.
4. Identificar os atores (stakeholders) envolvidos e se aproximar deles.
Não leu este Post (Produto de Sucesso - Parte 5)? clique AQUI e confira.
5. Organizar as informações coletadas e forma a que possa entender de forma abrangente e clara todos os aspectos do projeto.
Não leu este Post (Produto de Sucesso - Parte 6)? clique AQUI e confira.
A EMPRESA / O PROJETO
Na época deste projeto, 2007, a Itautec era uma empresa que possuía aproximadamente 5 mil funcionários e atuava nas áreas de automação bancária, automação comercial, autoatendimento e computação.
Em automação bancária, seu principal cliente era o Banco Itaú, porém ela atendia também outros bancos nacionais, e empresas do mercado interno e da América Latina, África e Estados Unidos.
Clientes de perfis e necessidades totalmente diferentes uns dos outros, o que demandava um desenvolvimento muito mais complexo, pois não seria possível ter um produto exclusivo para cada cliente.
Diante na necessidade de atender seus principais clientes, mas sem a possibilidade de fazer um desenvolvimento para cada um deles, decidiu-se que deveríamos criar um produto modular. Assim, o novo caixa eletrônico teria um grande aproveitamento de peças, independente da necessidade do cliente.
Então, o escopo geral do projeto era: Criar um novo caixa eletrônico que fosse modular, deveria para atender mais de 40 configurações e, aproximadamente, 16 clientes.
INTEGRAÇÃO, COCRIAÇÃO e HUMILDADE/TROCA
Em um projeto desses, de um produto com tanta complexidade, a equipe de trabalho é gigante. Contando apenas as áreas que atuam na elaboração da ideia e execução do projeto (sem contar com fornecedores, assistência técnica e montagem do produto), deviam estar envolvidas umas 40 pessoas, pelo menos.
Pessoas de diferentes áreas; área comercial, área de produto, diretoria de P&D, gerência de P&D, gerência de projetos, engenharia (elétrica e mecânica), área de mecanismos, software, firmware, documentação, compras e design!
Muita gente, muitos mundos, interesses e objetivos distintos e uma coisa em comum: o projeto do novo ATM.
Como fazer então para trabalhar em equipe de uma forma produtiva? Ao meu modo de ver, a primeira coisa a fazer é, através da integração, reunir o máximo de informações relevantes ao projeto.
Isso quer dizer, entrar em contato, de preferência, presencialmente com as pessoas detentoras das informações e, com muita humildade, ouvi-las. Entender quais são as questões do projeto, quais são as "dores" do consumidor, do cliente, do pessoal da assistência técnica etc. Ninguém sabe mais sobre essas coisas do que as pessoas que estão em contato diariamente com isso.
Com as informações em mãos o designer pode iniciar seu trabalho. Porém, vale muito, durante o desenvolvimento, conversar com profissionais de outras áreas para validação de alguns pontos do projeto. Por exemplo, conversar com os projetistas do projeto, falar com fornecedores que irão executar o protótipo e/ou irão produzir o produto. Esse processo de trabalhar o design em parceria de outros profissionais é muito rica para o projeto. Tanto pelo fato de poder enriquecer o que está sendo feito, como ajudar o designer a quebrar barreiras futuras. Quanto mais outros profissionais se sentem parte do processo, mais eles "compram" sua ideia, porque, na verdade, eles sentem que o projeto também é deles e, por isso, farão um pouco a mais para tudo dar certo.
Essas atitudes são estratégicas, pois para o designer obter sucesso no que criou, ele precisa de aprovações de diferentes áreas. Tanto daquelas que lhe nutrem de informação, quanto aquelas que darão sequência ao que foi criado.
Então, trazer para perto de você as pessoas envolvidas no projeto, não é apenas legal, é estratégico para o designer. Assim ele terá um projeto mais rico e um ambiente favorável para aprovação do seu trabalho.
IDENTIFICANDO OS STAKEHOLDERS e COLETANDO INFORMAÇÕES
No caso do ATM Adattis, as informações vinham diferentes fontes.
A área de produto enviava o briefing que continha o escopo geral do projeto, alguns números e metas de vendas, imagens de referência (sempre tinha um iphone no meio - e não porquê! parece que não existe qualquer outra coisa no mundo. Independente do que irá ser desenhado) ... enfim, passou kkkkk. Ah, imagens de referência, as normas de acessibilidade que deveriam ser consideradas e dizia que deveria atender os principais clientes.
Ficaram perguntas
Esse briefing dizia algumas coisas, mas, de longe, não eram suficientes. Ficavam, então, várias perguntas:
- Quais seriam esses clientes?
- Quais as configurações desse atm?
- Qual o peso (grau de importância) de cada cliente/configuração para definição da modularidade?
- Excluindo o iphone, qual a referência de ATM concorrente eles tem? Será que eles tem?
- Quais módulos serão usados (partes internas que fazem o produto funcionar).
- Etc
Diante disso, minha primeira ação foi reunir as informações existentes e tabula-las. Eu precisava ter a noção do que eu realmente sabia sobre o projeto, para, aí, fazer as perguntas.
Ok. Feito isso, entrei em contato com a área de produto, a qual escreveu o briefing. Com eles consegui informações valiosas, as quais não foram escritas. Informações que eles não achavam relevante escrever (mas que eu achava) ou que não sabiam como descrever no documento.
Como na época não tinha contato com ninguém da área de vendas, solicitei ao pessoal de produto que falassem com eles para conseguir outras informações que só eles teriam.
Na sequência fui até algumas pessoas da diretoria de P&D (a minha diretoria). Falei com gerentes de projeto, engenheiros mecânicos e eletrônicos e o pessoal de integração (que também recebe o briefing e vai buscar os módulos no mercado).
ORGANIZANDO AS INFORMAÇÕES
Pronto. Depois de todas essas etapas eu já tinha informação. Ops, na verdade neste caso eu tinha muitos dados. Todos picados. Minha tarefa, então, era transforma-los em informação de verdade.
Respostas
Assim, peguei todos aqueles dados, os organizei e vi que tinha tudo para iniciar o projeto:
- Quantos clientes? Agora sabia, mais de 15 (aqui usarei números de referência, pois é o que posso expor)
- Quantas configurações? Opa, mais de 40!
- Existem clientes e configurações mais importantes que outras? SIM! Medido pela expectativa e histórico de vendas.
Sempre achei esse número de configurações e clientes a serem atendidos grande demais. Poderia ter sido reduzido, focado em metade deles (os principais).
Obs:
Quando montei e apresentei o primeiro quadro de configurações à diretoria, ele devia ter uns 10 clientes e umas 30 configurações listadas. Me parecia um número bastante exagerado, mas, para minha surpresa, ao invés de ser feita uma redução, foram adicionados novos clientes e, consequentemente, novas configurações.
Decisões que fugiam à mim, mas com as quais eu tinha que lidar.
Seguindo ...
- Outras referencias? sim, eles tinham.
- Quais módulos seriam usados? Consegui a maior parte deles. Ou as peças físicas, ou datasheet ou arquivo 3D.
Enquanto ia modelando os módulos que não tinha vindo em 3D, outros chegavam. Ao final, tinha basicamente tudo para começar o estudo.
Até aqui vimos de forma concreta a importância a de identificar os stakeholders, agir junto à eles para conseguir informações relevantes e, em seguida, organiza-las para, assim, entender o projeto de forma ampla e garantir que o desenvolvimento fosse iniciado de forma correta.
No próximo post falarei das relações com os outros stakeholders, aqueles que fizeram parte do processo após a aprovação do design.
Gostou do post? Assine nossa newsletter e fique atualizado com todas as novidades!











































Comentários