Dicas para um cliente funcional. Pressione Δ para ler

Às vezes, existem poucas dicas durante a implementação da missão do projeto de TI - "pressione W para avançar" . Para pelo menos ajudar de alguma forma aqueles que estavam no lugar de um cliente funcional (depende muito dele no projeto), reunimos as 10 principais dicas que ajudarão você a concluir com êxito a missão, codinome "implementação de um sistema automatizado".

Por cliente funcional (FZ), entendemos uma pessoa ou grupo de pessoas que traduz os requisitos funcionais básicos de um sistema de TI. Se você se enquadra nessa descrição ou gerencia projetos, o artigo será útil e, espero, interessante.



Este artigo é o "choro da alma" de um dos gerentes de projeto da nossa empresa Digital Design Sasha. Sasha fez muitos projetos bons e muito bons, por isso acreditamos e o ouvimos. Ele sabe exatamente como fechar o projeto com sucesso. Sasha compartilhou o algoritmo conosco e compartilhamos com você.

Anteriormente, o Design Digital tinha mais projetos de automação de escritório; agora o vetor mudou para processos de negócios individuais. É assim que acumulam histórias sobre projetos de automação de auditoria, governança corporativa, processos de RH, fluxos de trabalho contratuais e de compras, atividades relacionadas a reivindicações e até manipulação de suspeitas de fraude em um banco.

Fazemos isso tudo em nossa plataforma nativa de BPM, Docsvision, mas essas recomendações se aplicam à automação de qualquer outro processo usando outras plataformas.

Etapa número 1. Coletar informações

Para estar totalmente equipado e avaliar a escala do projeto, você precisa coletar informações abrangentes e estudá-las:

• contrato
• documentação do concurso
• Termos de Referência
• informações sobre o contratante,
• datas do projeto
• quais unidades / subsidiárias estão envolvidas,
• informações sobre o processo comercial automatizado (como está sendo executado, quais regulamentos estão documentados, qual a relevância deles),
• estado atual da automação (se, por exemplo, você alterar o sistema antigo para um novo).

Ciente - significa armado. Só não precisa se preparar para lutar. Se a guerra, considere o projeto já pode ser enterrado.

Etapa número 2. Identifique as partes interessadas

Se os RPs lerem este artigo (e gostaríamos de acreditar nele), essa frase já estará correta. Como regra, os PRs estão envolvidos na determinação das partes interessadas.
Mas por que aconselhamos um cliente funcional a fazer isso? Sim, porque ele sabe muito melhor como tudo funciona dentro da empresa, onde e como os interesses dos colegas se cruzam.
Nos livros didáticos sobre gerenciamento de projetos, existe uma classificação que ajuda a não perder nenhuma das partes interessadas - deixamos para o PR e a Lei Federal. Para compilar essa lista, é melhor responder a essas perguntas da maneira mais detalhada possível:

1. Quem será afetado pelo projeto durante a implementação? Quem terá que se mudar? Quem terá que dar algo (orçamento, recursos, tempo)?
2. Quem será afetado durante a operação industrial (quando todos usarão o sistema)? De quem trabalho será alterado após a implementação?

Quando o projeto recebe um início oficial (por pedido, por exemplo), é importante não esquecer de notificar todas essas pessoas, declarar os objetivos do projeto, estabelecer prazos e apresentar os participantes.

No decorrer do projeto, é necessário retornar periodicamente a esta lista e planejar suas ações, levando em consideração os interesses das partes listadas. Para cada um deles, você precisa entender como e quando devemos envolvê-los no projeto, em que contexto fazê-lo e sob que molho eles devem receber informações.

Etapa número 3. Encontre RP

O cliente deve ter seu próprio gerente de projeto. Acredite, o PR do contratante não poderá substituí-lo totalmente. Pelo menos, os prazos definitivamente não serão cumpridos se apenas o contratado estiver encarregado de toda a organização do trabalho.

O RP deve ser o gerente do projeto, ou seja, ter experiência em gerenciamento de projetos é uma entidade única que nem mesmo um gabinete de livros didáticos pode substituir. E um contador com boas habilidades organizacionais não funcionará aqui. Se estamos falando de um projeto de TI, é altamente desejável que o RP do cliente seja versado em TI. Se não for assim, deixe-o contratar uma pessoa da equipe do departamento de TI.

Sem esse homem de ouro, você pode aumentar imediatamente o tempo planejado quatro vezes! É melhor gastar sua força, tempo e influência para isolar essa pessoa do escritório do projeto (se houver) ou encontrar, contratar de qualquer outra maneira.

E quando você o encontrar, verifique se ele executa as etapas 1 e 2.

Etapa número 4. Definir um grupo de trabalho

O grupo de trabalho é aquele que formulará os requisitos para o sistema, tanto funcionais quanto técnicos.

É necessário determinar o grupo de trabalho em conjunto com o PR, com base em você e em suas listas de pessoas interessadas (consulte a seção 2).

Ao determinar um grupo de trabalho, deve-se orientar-se pela regra de que um grupo de mais de 10 a 12 pessoas é difícil de gerenciar, e será difícil coordenar os interesses nesse grupo. (Se o KPI deve concluir o projeto antes do final deste ano, 10 é o limite).

O grupo de trabalho deve incluir (exceto a Lei Federal e a República da Polônia):

1. O proprietário do processo (se não for a lei federal) é um fator chave de sucesso. Deve haver uma pessoa que diga inequivocamente o que é necessário e o que não é, que resolva todos os requisitos conflitantes e que pode decidir que o processo será alterado após a implementação do sistema, se necessário. Como regra, esse é o chefe da unidade à qual o processo automatizado pertence: o diretor do departamento de gerenciamento de casos, se estamos falando de trabalho de escritório; diretor de auditoria interna, se estamos falando de auditorias de atividades financeiras e econômicas, etc.
2. Os especialistas do departamento, que usarão o sistema, que trabalham razoavelmente bem na empresa e sabem como o processo de negócios automatizado funciona, sabem onde ele difere dos procedimentos documentados e quais "brechas" existem nele ... É ótimo se houver algum entre eles Já trabalhou em um sistema desse tipo antes ou já participou da formação de requisitos para um sistema automatizado (nem sempre semelhante). Se houver algum - para a equipe!
3. Se o processo automatizado ultrapassar os limites da organização (por exemplo, representantes de subsidiárias funcionarão no sistema futuro), então, de acordo com o princípio descrito nos parágrafos acima, representantes de organizações interessadas de terceiros deverão ser acionados, lembrando a regra de 10 a 12 participantes.
4. Guardas de segurança devem ter! Quanto mais cedo você conectá-los ao projeto, melhor.
5. Um representante de TI será necessário quando se trata da alocação de capacidades para hospedar o sistema, a organização da infraestrutura, a largura de banda da rede etc.

A propósito, uma pessoa pode combinar várias funções.
O grupo de trabalho, como regra, também é fixado por ordem (decreto).

Etapa número 5. Participe de uma reunião introdutória

Em geral, essa é a tarefa de ambos os gerentes de projeto e é, em grande parte, um aperto do documento “Carta do Projeto”, que eles preparam no início do projeto.

E aqui está o que seria bom declarar nesta reunião:

Os objetivos do projeto.
E quais objetivos, de fato, queremos alcançar. E as metas do projeto declaradas na documentação coincidem com a verdadeira dor que eliminamos? Se a documentação indicar bobagens (isso acontece), não tenha vergonha de dizer a verdade ao contratado. Ele entenderá tudo.

Etapas e termos do projeto.
Deixe o contratado nos dizer o que acontecerá em cada etapa do projeto, quando a participação ativa do grupo de trabalho for necessária e, quando não, como certos trabalhos serão organizados (testes, por exemplo).

Os documentos resultantes do projeto.
E, em poucas palavras, o que cada documento implica e por que é necessário.

Termos de aprovação da documentação do projeto.
É importante que todos os membros do grupo de trabalho compreendam quantos dias eles têm para formular comentários e quanto tempo o contratado deve processá-los.

Informação sobre o projeto.
Com que frequência e em que formato serão realizadas as reuniões de relatórios e os relatórios de progresso? Quem deve ser informado: apenas um grupo de trabalho ou todos os funcionários da empresa, se o projeto, por exemplo, afetar toda a organização. Nesse caso, você pode publicar notícias sobre o projeto na mídia corporativa.

Procedimento para fazer alterações.
Qual é o procedimento para informar os participantes sobre solicitações de alterações que possam afetar o tempo, o custo ou o conteúdo do projeto e quais ações devem ser tomadas após a informação?

Nas demais seções da apresentação da instalação - adicione sal, pimenta a gosto (horário de trabalho no projeto, canais de comunicação, etc.)

Etapa número 6. Entrevista com responsabilidade

Ao formar requisitos, recomendamos que todos os participantes do grupo de trabalho cumpram as seguintes regras:

Etapa número 7. Coordene os documentos com cuidado

Pensamento longo, se é necessário declarar axiomas ....

É necessário.

Os documentos do projeto devem ser estudados! Estude com cuidado e em detalhes. E também verifique se todos os membros do grupo de trabalho fazem isso com cuidado e em detalhes. E o ponto não é que o contratado seja tão ruim e possa não escrever o que foi discutido (embora também valha a pena verificar com certeza), será simplesmente muito pior se o processo não for descrito corretamente.

Etapa número 8. Realizar testes reais

Testar com dados de teste não é ruim. Mas todas as inconsistências mais desagradáveis ​​surgem quando elas trabalham com um caso real no sistema. Sim, isso é trabalhoso e nunca há recursos disponíveis para isso, mas aumenta muito o sucesso da implementação.

Permita que os funcionários realizem a tarefa real e, juntamente com o contratado, passem pelo PIMI (procedimento de programa e teste) com um cenário real.

Etapa número 9. Não tenha medo de entrar em produção piloto

Você já ouviu falar sobre a excelente síndrome dos alunos? Eles devem ficar doentes se você automatizar o processo de agendamento de decolagens e pousos no aeroporto ou algo assim. Em outros casos, considere que o sistema não estará 100% pronto no momento em que iniciar a operação.

Sim, é triste. Sim, os integradores precisam ser jogados com tomates podres e disseram que isso não deveria acontecer e, em geral, "você está testando seu sistema lá ou como ..." (c) . Mas a realidade é que você provavelmente terá que entrar em operação-piloto. Para a objeção de que os usuários não gostarão disso, direi que isso acontecerá com um sistema 100% pronto. Para evitar isso, é necessário preparar gradualmente os usuários para uma nova vida e para o estresse, falando sobre o projeto na mídia corporativa, boletins, etc.

Portanto, você só precisa ter coragem e começar.

Etapa número 10. Termine o projeto lindamente

Ao implementar um projeto, lembre-se de que não é possível cobrir tudo de uma vez. Faça agora o que você pode fazer agora. Deixe o resto para o desenvolvimento do sistema.

Aqui a idéia de contratos futuros pode surgir, plantando uma “agulha financeira”, etc. Mas isso não é verdade. Tentar entender o imenso tem um risco muito alto de se tornar uma construção a longo prazo, que pode não apenas perder os prazos, como pode não terminar.

Após o término do projeto, é importante realizar uma reunião final, fazer um balanço do projeto, avaliar o nível de alcance das metas e discutir planos futuros.

PS

Acima

1. Aplicável a empresas modernas, grandes e pequenas.
2. É aplicável (por incrível que pareça) para a implementação de projetos de acordo com GOST 34 e documentação de acordo com RD 50.
3. Pode ser combinado com metodologias flexíveis, não há contradições.
4. É sofrido por experiência pessoal, não é de pleno direito, mas certamente será complementado.
5. É chamado para ajudar o cliente a entender melhor o contratado e aumentar as chances de sucesso mutuamente benéfico.