IsRetail

Objectivo

Estabelecer uma metodologia com vista à obtenção de conhecimentos que permitam identificar, selecionar, planear, conceber, desenvolver e implementar soluções inovadoras que sejam economicamente produtivas, úteis e de valor acrescentado para os Clientes, para o Mercado e para a IS.RETAIL.

Campo de aplicação

O presente documento aplica-se à conceção de soluções no âmbito das atividades de vocação normalmente desenvolvidas pela IS.RETAIL, em especial as que estão associadas ao processo PC-03 – Conceção de soluções.

Documentos associados

Ficha de processo PC_03 – Conceção de soluções

Definições e abreviaturas

ADM Administração (Gestão de Topo)

WPMS Warehouse Physical Management System

SG Sistema de Gestão

DT Departamento Técnico

Responsabilidades

QUEM?	O QUÊ?
Administração (ADM)	Avaliar, selecionar e aprovar novas soluções a disponibilizar a Clientes/Mercado.
Técnico Programador/Analista Funcional/Equipa de Projeto	Assegurar o desenvolvimento e a implementação das novas soluções que lhes sejam atribuídas.
Departamento Técnico (DT)	Validar as diferentes etapas, atividades e tarefas inerentes ao processo de desenvolvimento e implementação de novas soluções. Assegurar a viabilidade técnico-financeira da nova solução a implementar.
Todos os Colaboradores	Apresentar novas ideias e soluções com potencial valor acrescentado para a IS.RETAIL, Clientes e Mercado.

Procedimento

Fluxograma

Procedimento

Identificação de oportunidades e/ou necessidades de novas soluções/novas ideias

A conceção de novas soluções pode decorrer da identificação de novas oportunidades ou de necessidades expressas pelos Clientes ativos ou potenciais.

A análise da envolvente externa (inputs do Mercado/Clientes) e interna (Ideias internas) tem por objetivo a obtenção de novas ideias que permitam desenvolver o processo de conceção de novas soluções, nomeadamente no que respeita a produtos, funcionalidades, tecnologias emergentes, processos, etc.

As oportunidades identificadas junto do Mercado, dos Clientes ou internamente deverão ser economicamente produtivas e criadoras de soluções inovadoras, úteis e de valor acrescentado para a IS.RETAIL.

O conhecimento pode circular através das seguintes interfaces: “Ideias internas”, “Clientes” e “Mercado”. As interfaces incluem as seguintes vertentes:

Tecnológica: observar de forma sistemática as tecnologias disponíveis no mercado, tecnologias emergentes, novas tecnologias e tendências e avanços tecnológicos, com potencial interesse económico e que possam originar novas versões e funcionalidades da aplicação WPMS;
Novos Clientes/Mercados: identificar potenciais novos Clientes, Mercados e Utilizadores para as soluções desenvolvidas;
Análise da envolvente interna e externa: analisar a envolvente e o posicionamento da IS.RETAIL com o objetivo de se identificarem potenciais oportunidades;
Criatividade interna: desenvolver práticas que visem o aproveitamento e a promoção da criatividade interna. As sugestões e/ou ideias internas podem ser apresentadas via e-mail;
Gestão do conhecimento: recolher, documentar, analisar, tratar, validar, difundir e valorizar o conhecimento residente na IS.RETAIL.

O conhecimento é obtido através das seguintes fontes: consultas de Web sites, jornais e revistas técnicas e científicas da especialidade, feedback de Clientes/Mercado, conferências, workshops, sugestões, resultados do “road map” estratégico, resultados da revisão do SG, etc.

Repositório de novas ideias

Com base nas ideias recolhidas através das interfaces atrás referidas, é criado um repositório de novas ideias ou de projetos inovadores que possam contribuir para a resolução de problemas e/ou para a identificação de novas soluções. O repositório é registado no sistema de “tickets”, com a designação de “ideas box”. Todos os Colaboradores com acesso ao sistema de “tickets” podem registar as suas ideias/sugestões. A triagem das ideias é realizada no próprio sistema de “tickets”.

A abordagem às novas soluções deve contemplar dados relevantes, nomeadamente: descrição sumária da solução proposta e seu impacte, eventual equipa de projecto, necessidades de recursos humanos e outros (ex: materiais, financeiros, etc.), necessidades de equipamento, de hardware ou de software a afetar, nível de exequibilidade técnica, riscos, proposta de prazo de conclusão, entre outros.

Compete à Direção promover um pensamento conjunto (“brainstorming”) que permita analisar e validar, de forma objetiva, as diferentes soluções propostas. Todas as ideias consideradas como não exequíveis ou não oportunas, são descartadas, embora possam continuar a ser consideradas como potenciais (“ideias/projetos em carteira”).

Análise e seleção de novas ideias

Com base na listagem de ideias e/ou soluções, procede-se à análise e seleção de soluções/projetos que sejam (potencialmente) economicamente produtivos, inovadores, úteis e de valor acrescentado para a IS.RETAIL.

De acordo com a Política da Qualidade estabelecida, o projeto selecionado deve apresentar-se como uma oportunidade de inovação para a Organização.

Deverão ser identificados os benefícios e resultados finais esperados, pela implementação da nova solução. Quando aplicável, poderá ser realizado um estudo da viabilidade técnico-económica com vista a garantir que estão reunidas as condições (disponibilidade) para desenvolver a solução e/ou projeto.

Aprovação da solução/projeto

Após avaliar a informação resultante da análise ou do estudo da viabilidade da ideia ou projeto selecionado, compete ao Grupo de Desenvolvimento validar essa nova ideia ou projeto. A aprovação é da responsabilidade da Administração (ADM).

Desenvolvimento da solução/projeto

Fase 1:

Abertura de “ticket”

O processo de desenvolvimento inicia-se com a criação de um “ticket” no respetivo Sistema de Tickets.

O “ticket” permite assegurar o planeamento para o desenvolvimento e implementação da solução/projeto. O “ticket” pode estar associado a um Cliente (ativo ou potencial) ou à própria organização (IS.RETAIL).

No “ticket” são registados dados claros e concisos sobre o que se pretende com o desenvolvimento em questão, assim como outra informação considerada relevante para alcançar o objetivo.

Fase 2:

Definição do âmbito

Nesta fase, o Departamento Funcional analisa o desenvolvimento em questão para assegurar que os dados e a informação são suficientes e consistentes com a estrutura e aplicação já existente.

Caso se verifique que a informação disponibilizada não é suficiente deve ser solicitado ao Cliente informação mais detalhada (no caso de um desenvolvimento externo). Depois de recebida, a mesma deve ser novamente analisada e o processo deve ser repetido, até que os dados disponíveis sejam suficientes para uma perfeita compreensão dos objetivos do desenvolvimento em questão.

A informação recolhida deverá ser analisada pelo responsável do Departamento Técnico para se avaliar os custos associados ao desenvolvimento (caso existam).

Fase 3:

Desenho da solução e definição dos cenários de teste

Depois de estabelecido o âmbito do desenvolvimento/projeto, são definidas as tabelas e os programas. São igualmente expressas as explicações necessárias para a análise técnica e definidos os cenários de teste.

O tempo estimado para a realização do desenvolvimento da solução (t) vai determinar a necessidade de eventual análise técnica e a fase em que se procede à elaboração do orçamento.

Fase 4:

Análise técnica (quando aplicável)

Se o tempo (t) estimado para o projeto de desenvolvimento da solução for inferior a 2 dias úteis de trabalho, não há lugar a análise técnica.

Se o tempo (t) estimado para o projeto de desenvolvimento da solução for superior a 5 dias úteis de trabalho, há lugar a análise técnica e está será realizada antes da apresentação do orçamento, para sustentação do mesmo.

Nesta fase, o Departamento Funcional analisa toda a informação consolidada para assegurar que os dados e a informação são suficientes e consistentes com a estrutura e aplicação já existente.

É necessário assegurar que os dados disponíveis são suficientes para uma perfeita compreensão dos objetivos do desenvolvimento em questão.

O Técnico Programador deverá começar por analisar em profundidade toda a informação constante no “ticket” para que dessa forma possa compreender claramente o objetivo do desenvolvimento, encontrar pontos sobre os quais surjam questões e detetar possíveis situações de conflito com as funcionalidades já existentes.

No decurso deste processo de análise, o Técnico Programador deve, conjuntamente com um Analista Funcional, acompanhar todo o processo já existente e verificar todas as variantes e variáveis que possam contribuir para a existência de eventuais cenários, nomeadamente:

Identificar quais os reports envolvidos em todo o processo;
Compreender as parametrizações necessárias no processo e a suas respetivas implicações;
Compreender a dinâmica do processo para o operador final;
Verificar a dinâmica do novo processo tendo em linha de conta a já existente;
Analisar as consequências inerentes ao desenvolvimento do novo processamento nos procedimentos já existentes.

Após a abordagem com o Analista Funcional, compete ao Técnico Programador efetuar uma abordagem mais técnica e abrangente por forma a identificar todos os métodos, variáveis globais que “interferem” no processo de modo a que na fase seguinte seja possível analisar cada um deles e compreender os comportamentos dos mesmos mediantes as configurações possíveis. Desta forma será possível (já com os conhecimentos adquiridos na fase anterior) compreender a dinâmica do processo inerente ao desenvolvimento ou à alteração solicitada, nomeadamente quanto a:

Identificar os métodos envolvidos no processo;
Identificar a necessidade de criação de novos métodos, ações, tabelas, vistas, etc.

Depois desta análise técnica e de forma a garantir a eficácia do desenvolvimento, o Técnico Programador deve apresentar ao responsável do Departamento Técnico os resultados do seu estudo já com um conhecimento mais sólido e profundo de todo o processo que irá implementar/alterar/corrigir. Pretende-se desta forma garantir que a “discussão” seja já mais robusta e direcionada.

Nesta fase do processo, o Técnico Programador responsável deve centrar o seu esforço e empenho na leitura e compreensão o código dos métodos acima identificados, bem como encontrar outros métodos que possam ser invocados e que na fase anterior não tenha sido possível detetar. Assim cabe ao Técnico Programador desenvolver as seguintes atividades:

Analisar a dinâmica inerente ao processo e detetar mais métodos que possam ser invocados;
Identificar vistas utilizadas e valores que as mesmas podem devolver;
Identificar tabelas utilizadas e como estas se invocam no código (ex: leitura, update, modify, etc.);
Detetar valores de variáveis globais e influência que as mesmas têm nos diferentes comportamentos do processo.

Com o objetivo de:

Consolidar todos os conhecimentos adquiridos durante os momentos anteriores;
Organizar todas as tarefas que serão necessárias efetuar;
Minimizar a ocorrência de eventuais questões de incompatibilidade e/ou falha de design do desenvolvimento pretendido;

O Técnico Programador deverá criar (de acordo com o formato pré-existente) um manual que incida sobre a vertente técnica e funcional do desenvolvimento. O manual deve apresentar o máximo de exemplos possível para que a sua interpretação possa ser fácil, rápida e intuitiva, por parte de futuros leitores/utilizadores.

Toda a informação recolhida deverá ser analisada pelo responsável do Departamento Técnico para se avaliar os custos associados ao desenvolvimento (caso existam).

Fase 5:

Elaboração de orçamento

Caso existam custos imputáveis ao desenvolvimento, deverá ser elaborado um orçamento. O orçamento deve detalhar as tarefas a executar, tempos de execução e respetivos custos. Os orçamentos serão elaborados na fase 3 ou 4, consoante o definido no conteúdo das mesmas.

O orçamento deve ser enviado ao Cliente, ficando-se a aguardar feedback. No caso da resposta do Cliente ser no sentido da não adjudicação do orçamento (e mediante os argumentos apresentados pelo mesmo para tal decisão), o responsável do Departamento Técnico deverá reavaliar a situação. Da reavaliação pode resultar um orçamento revisto para apresentar ao Cliente. Este processo repete-se até que haja adjudicação por parte do Cliente ou o responsável do Departamento Técnico decida no sentido de não se reavaliar o orçamento apresentado.

No caso deste último cenário, o “ticket” inicialmente criado deve ser fechado com a informação ao Cliente de que o desenvolvimento não será efetuado, ficando-se a aguardar que o fecho do “ticket” seja confirmado pelo Cliente.

Caso o orçamento seja aprovado, procede-se ao agendamento do desenvolvimento e atribuição do mesmo a um Técnico Programador, iniciando-se assim a produção efetiva do desenvolvimento pretendido.

Fase 6:

Planeamento

Caso não existam custos associados ao desenvolvimento ou se o mesmo for despoletado internamente (como forma de implementar uma nova funcionalidade ou um upgrade a uma já existente), o desenvolvimento é agendado e atribuído a um Técnico sem que para isso seja necessário o envolvimento do Cliente e/ou apresentação de orçamento.

Deverá ser sempre passada a seguinte informação ao Técnico Programador responsável pelo desenvolvimento:

Objetivo e/ou alterações pretendidas;
Cenários de teste;
Indicações úteis (elementos a considerar; Vistas, tabelas, reports, métodos, etc).

Fase 7:

Formação (quando aplicável)

Caso o técnico programador a quem foi atribuída o desenvolvimento da solução não conheça bem a zona da aplicação em questão, este terá que receber formação específica por forma garantir a sua competência para a execução do mesmo.

Fase 8:

Desenvolvimento (Produção)

Nesta fase o Técnico Programador está em condições de iniciar o desenvolvimento da funcionalidade ou upgrade solicitado.

No decurso do processo de produção de código, o Técnico Programador deverá dar uma atenção muito especial quanto à performance do mesmo, atendendo a que um dos pontos-chave da aplicação se prende com o tempo que a mesma leva a devolver informação para o utilizador e/ou leva a executar determinada ação. Nesse sentido o Técnico Programador deve otimizar ao máximo a execução do seu código.

Com vista a melhorar a eficácia de intervenções futuras e a facilitar a interpretação do código implementado, o Técnico deve comentar o código seguindo criteriosamente as regras internas estabelecidas para a escrita dos mesmos.

O desenvolvimento da solução é acompanhado de revisões e verificações intermédias (seguimento) com vista a assegurar o cumprimento dos objetivos estabelecidos, isto é a eficácia da solução/resultados esperados. O acompanhamento (seguimento) do projeto é conduzido de acordo com os princípios do ciclo P-D-C-A (Plan-Do-Check-Act).

O sistema de “tickets” garante a identificação e o registo de eventuais desvios nos resultados esperados. São mantidos registos das ações de seguimento e de controlo.

Nesta fase deverá ser avaliado o impacto dos resultados (nova solução/projeto) na Organização e no Sistema de Gestão (SG).

Fase 9:

Testes de conformidade – Área Técnica e Área Funcional

Terminada a fase de implementação propriamente dita, o Técnico Programador deve efetuar os testes de conformidade ao desenvolvimento em questão. Utilizando os conhecimentos adquiridos durante a fase de análise conjunta com o Analista Funcional, deve reproduzir o processo em todos os cenários possíveis, mesmo os anteriores às alterações/desenvolvimentos que efetuou.

Caso se verifique a falha de um teste, que obrigue à reescrita de alguma porção de código, os testes devem recomeçar do primeiro cenário testado. Este procedimento garante que as alterações efetuadas não afetam os cenários previamente testados, confirmando-se assim a estabilidade de todo o processo.

No caso de terem sido entregues pelo Cliente ou pelo responsável do Departamento Técnico, cenários de teste, estes devem ser considerados desde logo como forma de despistar possíveis falhas no desenvolvimento.

Após a validação por parte do Técnico Programador o desenvolvimento deverá ser passado para o Analista Funcional que acompanhou inicialmente o processo, com vista a se identificarem eventuais pontos de fragilidade no desenvolvimento efetuado. Os testes a efetuar nesta fase (e ao contrário dos anteriores) são do tipo “destrutivo”, isto é, provocam situações à partida inesperadas, mas que podem surgir devido à diversidade de parametrizações que podem ser estabelecidas.

No caso de serem detetadas anomalias (quer a nível funcional quer no que respeita os objetivos estabelecidos), o Analista Funcional deverá reproduzir detalhadamente no “ticket” respetivo, o(s) cenário(s) que testou e as parametrizações que utilizou. Deverá ainda registar as falhas detetadas, permitindo assim uma resolução mais fácil das questões detetadas, por parte do Técnico Programador responsável.

Este processo deverá repetir-se até que o Analista Funcional responsável pela avaliação do desenvolvimento declare que o mesmo está de acordo com o objetivo estabelecido e que não foram encontradas falhas nos testes que realizou.

Após a conclusão dos testes é publicada a modificação referente ao desenvolvimento e produzido o patch a enviar ao Cliente. De seguida o desenvolvimento é fechado, ficando-se a aguardar a confirmação por parte do Cliente de que a funcionalidade ou upgrade estão de acordo com o objetivo inicial. No caso de desenvolvimento interno a informação de sobre a conformidade do desenvolvido é dada pelo responsável do Departamento Técnico.

Fase 10:

Encerramento do “ticket”

Se o processo for considerado conforme (pelo Cliente ou pelo DT), o “ticket” é fechado. Caso sejam reportadas falhas por parte do Cliente, há necessidade de avaliar a natureza das mesmas. Em qualquer das situações (conforme ou não conforme devido a falha), o desenvolvimento original permanecerá fechado sendo sempre necessário abrir um novo “ticket”.

No caso de se tratar de uma disfuncionalidade (não conforme) deverá ser aberto um novo “ticket”, indicando o bug (falha) detetado. O “ticket” deverá conter o máximo de informação possível sobre o cenário que estava a ser testado.

Se a natureza da falha for no sentido de adicionar novas funcionalidades, deverá ser criado um “ticket” de desenvolvimento, que informe sobre a alteração/upgrade a ser desenvolvida, voltando-se ao início do processo.

Registos

Registos no sistema de “Tickets”

Registo de alterações

EDIÇÃO	CRIADO POR	APROVADO POR	OBJECTO DA REVISÃO
Nome	Data	Rubrica ()*
1	Fernanda Dourado	Leopoldo Donati	2011-10-20	Versão original.
2	Fernanda Dourado	Leopoldo Donati	2012-03-20	Inclusão do FORM-26 – Repositório de ideias.
3	Fernanda Dourado	Leopoldo Donati	2012-05-11	Revisão e alteração do fluxograma e do parágrafo 6.2.5 – Desenvolvimento da solução/projecto.
4	Fernanda Dourado	Leopoldo Donati	2016-09-20	Descontinuação do formulário FORM-26 – Repositório de ideias. O registo passa a ser assegurado no sistema de “tickets”.
5	Fernanda Dourado	Leopoldo Donati	2018-05-01	Revisão geral do documento no âmbito do processo de transição para a norma ISO9001:2015.

(*) Apresentada apenas no documento original (suporte papel).