Qualquer produto digital é distribuído para os seus utilizadores em canais como smartphones, computadores e outros. A experiência do utilizador é crucial para o seu sucesso, e não existe uma boa UX sem um bom processo de engenharia.

Esta ligação indissociável pede uma implementação do software development lifecycle (SDLC) estendida para que a engenharia tenha a melhor informação possível no momento da implementação, e conseguir concretizar a ideia do produto como este foi imaginado.

No caso de desenvolvimento de um produto, o processo começa antes da fase de levantamento de requisitos, em momentos de trabalho colaborativo de pessoas ligadas ao negócio e profissionais de UX research e facilitadores de ideação. Entre estudos de mercado, entrevistas com potenciais utilizadores e sessões com especialistas do negócio que alimentam workshops de Design Thinking e de Ideation, gera-se uma imensa quantidade de informação acerca de regras de negócio, necessidades funcionais e não funcionais, que é valiosa para a engenharia no momento da implementação. Ao estender o processo de desenvolvimento de software para incluir este momento, estaríamos a entrar naquilo que é o processo de desenvolvimento de produto (PDLC).

Mas os intervenientes desta fase do processo, que são ligados mais à área de negócio, têm formas próprias de levantar e escrever requisitos. É comum vermos uma distância grande entre a equipa de produto e a equipa de engenharia na forma como a informação é levantada e organizada, o que pode originar uma perda desnecessária de informação valiosa. Para este desafio, uma framework de alinhamento de requisitos que assegure a sintonia entre todas as equipas envolvidas é imprescindível para o sucesso e previsibilidade do projeto de implementação.

É com esta informação disponível que a engenharia consegue tomar decisões mais adequadas no desenho do sistema e da infraestrutura que o suporta. Qualquer canal terá uma interface, e a criação de interfaces em qualquer linguagem nativa, híbrida ou low-code, precisa de ser muito claramente mapeada para os desenhos de layouts e componentes. Mais uma vez, a organização desta informação deve ser alinhada para que se partilhem nomes, hierarquias e associações entre a equipa de produto, design e engenharia. A fluidez desta parte do processo é novamente crucial para que não haja perda de informação valiosa.

Não é apenas no lado da interface que deve existir alinhamento inter-equipas. No lado do servidor, que assegura tipicamente os dados e as regras de negócio, também deve estar garantido que as decisões são tomadas tendo em conta a experiência do utilizador. As escolhas na modelação dos dados e dos desenhos arquiteturais devem considerar o que é melhor para o utilizador na sua interacção com o produto. As decisões devem ser em função das necessidades da interface porque é a parte do sistema mais próxima do utilizador e da sua experiência.

Invariavelmente existirá uma infraestrutura que suporta os serviços que servem a interface. Esta, que pode ser mais ou menos distribuída e descentralizada, tem de ser pensada no sentido da resiliência, segurança e disponibilidade, porque é aqui que estão as maiores ameaças à experiência do utilizador. Um produto que não funciona bem e de forma segura terá um problema inevitável com os seus utilizadores.

A entrega de um produto é algo contínuo no tempo e o processo de desenvolvimento continua, depois da entrega inicial, com manutenções corretivas e evolutivas. Todos os produtos de sucesso atingem-no com evolução a nível funcional e/ou visual, e esta deve ser tratada com o mesmo rigor e foco naquilo que é a experiência do utilizador. As alterações devem ser devidamente testadas em ambientes semelhantes, ou iguais, aos da realidade que estará disponível para o utilizador final. Todo este processo deve assentar em fluxos automáticos de deploy desenhados de forma a minimizar ao máximo o downtime do sistema, evitando a frustração no utilizador.

Por fim, a monitorização do sistema na perspectiva daquilo que é a sua utilização por parte do utilizador final é de onde as equipas de engenharia e produto se podem alimentar de mais informação valiosa. Um trabalho colaborativo e de reflexão sobre a informação gerada pelo sistema em bases de dados, logs e outros, pode trazer alterações naquilo que são as prioridades de trabalho e deve ser parte integrante do processo de criação de valor para a experiência do utilizador final.

É a emoção numa boa experiência final para o utilizador que deve reger a racionalidade da engenharia. Todos estes princípios são mais do que diretrizes, são a essência da nossa abordagem diária. Comprometidos com a satisfação e produtividade das equipas de engenharia, promovemos uma conexão e sinergia entre todas as áreas envolvidas no processo de concepção. A nossa metodologia, alinhada à implementação eficaz do SDLC estendido, garante não apenas a excelência técnica, mas também uma entrega contínua de produtos digitais que refletem de forma precisa e inovadora as necessidades e experiências dos utilizadores finais.

Artigo de opinião de Diogo Cunha, CTO na Bliss Applications, originalmente publicado na ITinsights.