Handcom - Política da empresa 2013

POLITICA ORGANIZACIONAL DA HANDCOM – REVISÃO 2013 Revisão 2013-‐05-‐29

1. Introdução

• O documento de políticas do grupo HANDCOM serve como guia e referência, com limites, deveres e obrigações para a execução dos processos e relacionamentos entre as todas as partes interessadas.

• As políticas aqui descritas devem ser seguidas por todos os colaboradores e poderão ser revisadas conforme a necessidade da empresa.

• Todos os clientes e funcionários do grupo HANDCOM deverão ser informados sobre a política e suas eventuais alterações.

2. Políticas Nesta seção são apresentadas todas as políticas que foram definidas para a organização de acordo com o tema, processo ou área.

2.1. Sobre a segurança da informação

2.1.1. Diretrizes quanto à utilização da internet

• A internet deve ser utilizada para fins corporativos, o enriquecimento

intelectual de seus colaboradores ou como ferramenta para busca de informações que venham contribuir para o desenvolvimento de seus trabalhos.

• O uso para fins pessoais, mediante o consentimento do responsável pelo setor, fica restrito à consulta de movimento bancário e ao acesso ao e-mail pessoal, estando vedadas práticas abusivas tais como a circulação de correntes, material pornográfico entre outros.

• Não é permitido o envio de qualquer arquivo por e-mail, ferramentas de comunicação, web sites, ftp, p2p, ou qualquer outro meio de transmissão de arquivos, sem a prévia autorização formal da diretoria da empresa.

• Poderá haver uma autorização formal de envio de certos tipos de arquivos, certos protocolos e para determinados destinatários, não sendo necessário, portanto, novas autorizações por cada novo envio.

o O envio só é permitido baseado neste documento que estará armazenado em local definido pela Gerência Administrativa.

2.1.2. E-mail corporativo

• O e-mail corporativo poderá ser usado apenas para comunicação de

assuntos relativos ao trabalho e à boa comunicação empresarial entre as equipes e pessoas da empresa. O envio de e-mail para clientes ou à pessoas de empresas clientes ou fornecedores deverá estar atestada por documento de comunicação dos projetos da empresa,


onde estará atestado quem envia e para quem recebe. • Os e-mails não podem ser usados para motivos pessoais. • Os e-mails da empresa são auditados. • Os colaboradores devem desconfiar de todos os e-mails com assuntos

estranhos ao ambiente de trabalho. Não reenviar e-mails do tipo corrente, aviso de vírus, avisos da Microsoft/AOL/Symantec, criança desaparecida, entre outros.

o Evitar enviar anexos acima de 10 Mbytes

2.1.3. A realização de download

• A realização de downloads deve ser vista com muito cuidado e feita somente em casos de extrema necessidade. Downloads de programas, aplicativos ou códigos de sistemas de terceiros são proibidos, salvo autorização da Gerência Administrativa.

• O download de arquivos necessários ao trabalho deve ser comunicada aos líderes das equipes para consenso sobre o horário.

• É proibido a realização de download de qualquer arquivo que não seja para motivos da execução do trabalho na empresa, como filmes, músicas, arquivos pessoais, ou qualquer outro arquivo que não tenha ligação direta com o aprendizado ou a execução do trabalho.

2.1.4. Execução de jogos e rádios on-line

• É terminantemente proibida a execução de jogos, músicas ou rádios

on-line, visto que esta prática congestiona a banda de internet, dificultando a execução de serviços que necessitam deste recurso.

2.1.5. Senhas de acesso

• Cada setor deverá, através de comunicado oficial, indicar novos

colaboradores e o perfil que devem possuir na rede e nos sistemas da empresa.

• A senha de acesso é pessoal, intransferível, cabendo ao seu titular total responsabilidade quanto seu sigilo.

• O compartilhamento de senhas de acesso é absolutamente proibido e o titular que divulgar sua senha a outrem responderá pelas infrações por esse cometidas, estando passível de advertência. Caso o usuário desconfie que sua senha não seja mais segura, poderá solicitar ao Comitê de TI, ou ao líder de área, a alteração desta.

As senhas de acesso aos servidores de clientes e da empresa, como FTP, servidores, bancos de dados, ou qualquer outra senha necessária a execução do trabalho são sigilosas e de propriedade do cliente ou da empresa, sendo expressamente proibida a divulgação por qualquer meio desta senha sem autorização.

2.1.6. Softwares de conversação instantânea


• É permanentemente proibido aos setores o uso de softwares de

conversação instantânea, ou de qualquer mecanismo que venha promover serviço semelhante, existentes ou que venham a existir.

• Pode haver permissão especial a qualquer setor para utilização de Instant Messengers, desde que seja para fins corporativos e comprovadamente utilizados em assuntos comerciais e/ou para suporte. A autorização para uso deve conter o usuário e os destinatários permitidos. Esta autorização estará armazenada em local determinado pelo Gerente Administrativo e o Comitê de TI, cabendo auditorias periódicas.

2.1.7. A instalação de softwares

• Qualquer software que, por necessidade do serviço, necessitar ser

instalado, deverá ser comunicado ao Comitê de TI, que procederá a instalação caso constate a necessidade do mesmo. Fica proibida a instalação de qualquer software sem licença de uso.

• O Comitê de TI poderá utilizar de sua autonomia citada no Item 1 deste instrumento para desinstalar, sem aviso prévio, todo e qualquer software sem licença de uso, em atendimento à lei do software (Lei 9.609/98).

2.1.8. Penalidades

• O usuário que infringir qualquer uma das diretrizes de segurança expostas neste instrumento estará passível das seguintes penalidades (sem prévio aviso):

o Perda da senha de acesso aos sistemas e Internet; - Cancelamento da caixa de e-mail;

o Advertência formal por intermédio do departamento de RH podendo levar inclusive a demissão do colaborador.

o O vazamento de informações protegidas da empresa, como códigos fontes, softwares, senhas, documentos sigilosos, ou qualquer documento ou arquivo de propriedade intelectual da empresa, caracteriza erro grave podendo levar a demissão por justa causa e ação por danos causados.

2.2. Sobre os recursos humanos

• Todos os colaboradores do Grupo HANDCOM devem realizar a

integração inicial, na qual serão apresentadas as suas atividades e rotinas, funcionamento e programas da empresa e será entregue o código de ética.

• Os colaboradores da empresa têm o desempenho avaliado e recebem o feedback da sua avaliação pelo seu superior imediato.

• Todo treinamento deve possuir uma solicitação autorizada e deverá ser registrado e acompanhado pelo processo de treinamentos da empresa.


• A cada novo projeto os colaboradores envolvidos no mesmo devem ter seus conhecimentos analisados e atestados e deverão ser treinados caso não possuam todos os conhecimentos necessários para a execução do projeto.

• O processo de seleção é realizado conforme necessidade do grupo HANDCOM e busca recrutar novos talentos com os conhecimentos técnicos necessários e que tenham os mesmos valores da empresa.

• O grupo HANDCOM respeita a legislação trabalhista e as determinações do sindicato em que é registrado.

2.3. Sobre o processo de desenvolvimento

• Todos os novos projetos de software do grupo HANDCOM deverão

seguir o processo de desenvolvimento de software HUP em sua última versão aprovada, salvo alguma exceção autorizada por escrito pela direção;

• Toda versão de software será considerada como um novo projeto, exceto quando a mesma contemplar um período de trabalho inferior a 1 mês, nesse caso será considerado manutenção, mesmo assim o Documento de Requisitos e os Diagramas do projeto deverão ser atualizados;

• Qualquer membro da equipe que sentir dificuldade em executar alguma atividade do processo deverá solicitar um treinamento ou informações ao SEPG;

• Nos projetos de software, todas as demandas deverão ser passadas para o Gerente de Projetos e ele atribuirá as mesmas ao devido responsável.

• Alterações no Processo de Desenvolvimento de Software são de responsabilidade do Grupo de Processos de Engenharia de Software (SEPG). Qualquer alteração na definição do processo deve ser justificada.

• Qualquer alteração ou não realização da execução das atividades obrigatórias em um projeto previstas no processo padrão deverá ser realizada mediante autorização do SEPG. A aderência a estes processos é avaliada pelo SQA ao longo do processo definido.

• Todos os colaboradores envolvidos no projeto deverão cadastrar as horas relacionadas às tarefas em execução logo após sua conclusão ou interrupção.

• Todos os projetos da empresa deverão ser aprovados e pelo Gerente de Portfólios de acordo com os critérios estabelecidos no Planejamento estratégico.

2.3.1. Prospecção

• Todo projeto deve ter suas estimativas de esforço e prazo calculados a partir de técnicas de Estimativa de Software, com base no escopo definido e na elicitação inicial de requisitos. Qualquer informação sobre prazo e viabilidade do projeto somente poder ser fornecida ao cliente após essa estimativa e após a aprovação do Gerente de Portfólio.

• O planejamento dos Recursos Humanos em um projeto deve ser feito levando em consideração a formação e as habilidades necessárias para


o projeto. Caso pertinente, treinamentos devem ser solicitados/realizados. • Antes do envio de qualquer proposta, o projeto deve ser analisado quanto

a sua viabilidade. A viabilidade deve ser atestada para o envio da proposta. Para avaliar a viabilidade deverá ser considerada a disponibilidade de recursos e a capacitação dos mesmos, bem como a quantidade mínima de horas do projeto.

Toda proposta deve ter um prazo de validade, sempre que o cliente sinalizar com a assinatura do contrato, o mesmo deve ser reavaliado quanto a sua viabilidade.

2.3.2. Planejamento

• O gerente de projetos deverá alocar os recursos para esta fase e salvar o planejamento detalhado da Fase de Planejamento, assim como o cronograma geral primário.

• As atividades do Planejamento deverão ser detalhadas e estimadas de acordo com dados históricos da empresa e os requisitos aprovados em contrato.

• Todo projeto deve ser planejado. O plano do projeto e suas alterações devem ser comunicados ao cliente e à equipe técnica formalmente, e o comprometimento desses com o plano devem ser mantidos.

• O plano do projeto estabelece os recursos humanos e de apoio necessários, a forma de comunicação entre os envolvidos, os artefatos a serem gerenciados, os riscos a serem monitorados, o cronograma e os marcos do projeto.

• O projeto deverá ter sua viabilidade analisada pelo Gerente de Portfólio. • O plano do projeto deve ser baseado nas estimativas, requisitos,

restrições e ser monitorado em marcos estabelecidos.

2.3.3. Construção

• Nas reuniões de Marco do projeto toda a equipe envolvida deverá estar presente, e deve ser elaborada uma Ata de Reunião confirmando a presença e o seu comprometimento com os objetivos descritos na mesma.

• Para garantir a qualidade dos artefatos e verificar se o processo de gerência de projeto está sendo seguido corretamente, conforme definido no processo da empresa, em todas as reuniões de marcos será feita a Verificação dos Artefatos pelo responsável da Qualidade do Projeto e relatados em ata, se houver problemas são registrados plano de ação e prazo para comprimento. Os problemas relatados na ata serão verificados na próxima reunião de marco.

• Todo testador deverá ler o documento de requisitos ou a parte do mesmo que trata da versão antes de realizar o teste no software.

• Para fins de configuração, só deverão ser enviados para a transição códigos já testados e corrigidos.


2.3.4. Transição

• Caso a equipe de projetos receba uma demanda de um projeto que já está sob a responsabilidade da equipe de suporte, deve imediatamente encaminhar a mesma para a equipe de suporte e comunicar ao originador que a partir daquele momento a equipe de suporte estará prosseguindo com o atendimento.

• Antes de realizar a transição o líder técnico, o gerente de projetos e o gerente de configuração deveram criar ou atualizar o documento de configuração do projeto, o qual deve conter a versão e localização de todos os códigos utilizados, de todos os scripts de banco de dados e informações sobre a integração com outros sistemas, estrutura computacional e de rede, bibliotecas de terceiros com versão e um check list com todos os passos necessários na transição.

• Todos os requisitos entregues deverão ser validados formalmente com o cliente durante a entrega.

2.3.5. Sobre a implantação de software

• O número da versão do software seguirá o padrão de 4 dígitos, seguindo

o padrão da Apache Software Foundation, por exemplo 1.0.0.000, definido da seguinte forma:

Esquema Nome Características X.x.x.xxx Versão Uma nova versão do software com muitas alterações. x.X.x.xxx Maior

Release Uma nova versão do software com melhorias e evoluções.

x.x.X.xxx Menor Release

Cada versão nova disponibilizada para o cliente.

x.x.x.XXX Build A cada correção realizada na “Menor Release”.

• O Gerente de Projetos deve iniciar a elaboração dos planos de implantação do software para todos os clientes assim que a versão for terminada e enviá-los para o repositório do SVN;

• O suporte deve atualizar os planos de implantação com os dados da implantação e enviar de volta para o repositório quando as mesmas ocorrerem.

• Toda fase de transição (implantação do software), deverá ter seu escopo com prazo e esforço, definidos na proposta e plano de projeto.

• Ao final do projeto deverá ser realizado um documento com os aprendizados técnicos, gerenciais e de processos, os mesmos deverão ser apresentados para toda a equipe e para a equipe de suporte.

2.3.6. Sobre as medições

• Os objetivos de medição devem ser revisados semestralmente pelo


Gerente de Portfólio. • Na fase de planejamento é obrigatório a criação do plano de medição

para gerar os indicadores do projeto. • As medições deverão fazer parte do cronograma do projeto e

acompanhadas quanto ao esforço e prazo. • Os resultados das medições deverão ser analisados pelo Gerente do

Projeto e as devidas ações deverão ser tomadas em caso de resultados fora do intervalo ideal.

2.3.7. Sobre o controle de mudanças

• Toda solicitação de mudanças, seja sugestão da equipe ou do cliente,

deve ser cadastrada como demanda no “AtTask” para o projeto e deve ser informada como categoria “Solicitação de Mudanças” no momento do cadastro;

• Qualquer necessidade de alteração no processo deverá ser cadastrada na ferramenta “AtTask” para o projeto “Processo do MPS.Br nível F”;

• Todas as mudanças só poderão ser efetuadas após sua avaliação de viabilidade e aprovação pelo cliente.

2.3.8. Sobre a Gerência de Projetos

• O Gerente de Projetos é o responsável pelo projeto desde a fase de planejamento até a fase de transição.

• O Gerente é responsável por organizar as atividades a serem realizadas no projeto, bem como a equipe participante e fazer a comunicação com o Cliente e níveis hierárquicos superiores da organização para tomar decisões no projeto.

• Todo projeto deve ser monitorado pelo gerente de projetos e as revisões em marco, previstas no cronograma, e o monitoramento semanal/quinzenal devem estar registrados em documento apropriado.

• Nos acompanhamentos o Gerente de Projeto faz o monitoramento dos riscos, verifica implementação dos requisitos e os testes para saber se eles estão sendo implementados dentro do planejado para o controle do projeto do início ao fim.

• Todo problema encontrado durante o monitoramento deve ser registrado e uma ação corretiva para a resolução do problema deverá ser definida, bem como o responsável por essa execução que será indicado pelo Gerente.

• A comunicação entre os envolvidos no projeto deve ser gerenciada. • O tempo de planejamento, acompanhamento e execução das atividades

operacionais não deverá ser superior a 20% da duração total do projeto evolutivo desenvolvido no mês.

2.3.9. Sobre a Gerência de Requisitos

• Os Fornecedores de Requisitos para o projeto devem ser identificados no Plano de Projeto e/ou nas Solicitações de Manutenção ou Serviço.


• Os requisitos identificados para o projeto devem ser avaliados objetivamente a partir da lista de critérios indicada e disponibilizada no Processo de Desenvolvimento de Software. Os clientes e/ou fornecedores de requisitos devem aprovar os requisitos para que o projeto tenha andamento. A aprovação pode ocorrer através de assinatura no documento, em reunião (com registro de ata) ou através de mensagem eletrônica. Sendo esse material armazenado para futuras consultas.

• Os requisitos devem ser gerenciados através do registro da rastreabilidade entre os mesmos e com os produtos de trabalho.

• Toda mudança nos requisitos deve ser gerenciada. O impacto da mudança deve ser calculado e registrado para conhecimento do cliente. Caso a mudança seja aprovada, o comprometimento da equipe e dos clientes com a mudança deve ser obtido. Além disso, o plano de projeto e outros documentos pertinentes devem ser revisados para manter a consistência com os requisitos.

• A aceitação dos requisitos pelos programadores é feita na primeira reunião de marco do projeto.

• Revisões entre requisitos e produtos de trabalho serão feitas para garantir a qualidade dos artefatos e verificar se o processo de gerência de requisitos está sendo seguidos corretamente. Conforme definido no processo da empresa, em todas as reuniões de marcos será feita a Verificação dos Artefatos pelo responsável da Qualidade do Projeto e relatados em ata, se houver problemas são registrados plano de ação e prazo para comprimento. Os problemas relatados na ata serão verificados na próxima reunião de marco.

• A diretoria de alto nível irá verificar se houve as reuniões de marcos e se os objetivos descritos foram cumpridos e irá rubricar a Ata de Reunião.

2.3.10. Sobre a Gerência de Portfólio

• O Gerente de Portifólios deve avaliar e acompanhar a viabilidade dos

projetos da empresa de acordo com os critérios estabelecidos nas datas previstas na agenda da empresa. Os projetos deverão ter ações associadas ao seu andamento.

• Os critérios de seleção deverão ser revistos nas reuniões de conselho e acompanhamento do GPP.

• As ações no portifólio de projetos deverão ser registradas com parecer baseado nos critérios estabelecidos.

• As ações de início e conclusão dos projetos devem ser comunicadas ao Gerente de Portifólio da empresa.

2.3.11. Sobre a Gerência de Configuração

• Os Itens de Configuração de cada projeto deverão ser selecionados

conforme os critérios estabelecidos no plano de configuração.


• Todos os itens de configuração devem estar versionados no SVN e devem compor a baseline.

• As baselines deverão ser geradas após cada marco do projeto e a cada release.

• Qualquer modificação dos Itens de Configuração em baseline deve passar pelo processo de mudança.

• Todas as mudanças nos itens que estiverem sobre gerência de configuração necessitará de uma aprovação formal do Comitê de Qualidade (SEPG/SGQ) antes que a mudança ocorra;

• As auditorias de configuração do processo de desenvolvimento de software devem ser feitas após a conclusão de cada marco do projeto.

• Deverá ser feito um acompanhamento periódico, de acordo com o plano de configuração, dos Itens de Configuração do projeto e a verificação de sua conformidade.

2.3.12. Sobre a Garantia da Qualidade

• O Analista da Qualidade (QA) terá total liberdade para executar seu trabalho com independência e autoridade com todos os membros da organização independente do nível hierárquico;

• As auditorias de qualidade do processo de desenvolvimento de software devem ser feitas após a conclusão de cada marco do projeto.

• Todos os membros da organização assumem que uma não conformidade atribuída a eles deverá ser solucionada no tempo de prioridade definido no Plano de Garantia da Qualidade;

• O Diretor da organização assume o compromisso com o programa de melhoria da qualidade se tornando responsável por dar andamento às não conformidades atribuídas a ele por escalonamento;

• As não conformidades identificadas pelo SQA responsável deverão ser solucionadas dentro do MARCO, de acordo com o planejamento do projeto, em que foi identificada. Os casos não resolvidos deverão ser escalados às instâncias superiores, conforme definido na estrutura organizacional da empresa, até que a não conformidade seja resolvida.

• As Não Conformidades não resolvidas dentro do prazo estabelecido deverão ser tratadas pelo Gerente de Portifólios e comunicadas na reunião de conselho para o conhecimento dos sócios e conselheiros e definição de um Plano de Ação para a mesma.

2.3.13. Considerações finais

• A política da Handcom deverá ser mantida e aprovada pela direção. As condições mínimas para que a política seja revisada são:

o Quando o nível de maturidade do grupo HANDCOM for alterado para incluir novos processos e capacidades;

o Quando o código de ética do grupo HANDCOM for alterado; o Quando algum dos itens que compõem a Política

Organizacional do grupo HANDCOM for alterado.


• Todos os colaboradores deverão ter conhecimento da política que será disponibilizada no site do Processo da Empresa hup.handcom.com.br.

• Os casos que não se enquadrarem na política descrita acima deverão ser analisados pelo Coordenador da área e caso necessário pela Direção ou pelo Conselho do grupo HANDCOM para que seja tomada a devida resolução.

• É garantida aos fornecedores, clientes, colaboradores e outras partes interessadas a possibilidade de assinalar eventuais violações dos princípios e padrões de ética e conduta acima reportados. O órgão competente para a recepção de tais indicações é o Canal de Denúncia ([email protected]). As comunicações, que serão tratadas com o devido sigilo, devem ser verificadas mediante descrição dos fatos e das pessoas envolvidas ou apresentação de documentos que evidenciem a violação.

3. LISTA DE ABREVIATURAS E SIGLAS

MPS.Br – Melhoria de Processo de Software Brasileiro QA – Analista de Qualidade SEPG – Software Enginering Process Group (Grupo de Processo de Engenharia de Software) SVN – Subversion (Sistema de Controle de Versão)

Documents

Handcom - Política da empresa 2013