Como você aprendeu a fazer engenharia de requisitos na sua empresa?
36 views
Skip to first unread message
Adriana Selleri
May 8, 2012, 4:48:11 PM5/8/12
to Análise de Negócios . br
Caros amigos Analistas de Negócios:
Faz um tempo que não participo da lista, mas resolvi criar esta thread
porque estou estudando o uso de métodos empíricos em engenharia de
requisitos em meu mestrado e fiquei curiosa sobre como o assunto tem
sido tratado na prática nas empresas.
Logicamente, toda empresa que faz engenharia de requisitos tem algum
processo, tenha sido ele planejado ou criado empiricamente e que,
normalmente, está sempre em evolução. Minha pergunta basicamente é:
quando você entrou no time, como aprendeu o processo de engenharia de
requisitos utilizado pela sua empresa? Você recebeu algum tipo de
treinamento sobre a metodologia, ferramentas utilizadas e artefatos
que deveriam ser produzidos? Ou o conhecimento lhe foi passado de
maneira mais informal, ou seja, aos poucos você foi aprendendo o
processo na prática? Além disso, gostaria de saber sua percepção sobre
quão definido é o processo e o quão fácil foi aprendê-lo.
Isso não é uma pesquisa nem nada, só quero ouvir algumas opiniões para
ter uma idéia de como o mercado está lidando com a transferência do
conhecimento nessa área.
Aguardo seus comentários :)
Faz um tempo que não participo da lista, mas resolvi criar esta thread
porque estou estudando o uso de métodos empíricos em engenharia de
requisitos em meu mestrado e fiquei curiosa sobre como o assunto tem
sido tratado na prática nas empresas.
Logicamente, toda empresa que faz engenharia de requisitos tem algum
processo, tenha sido ele planejado ou criado empiricamente e que,
normalmente, está sempre em evolução. Minha pergunta basicamente é:
quando você entrou no time, como aprendeu o processo de engenharia de
requisitos utilizado pela sua empresa? Você recebeu algum tipo de
treinamento sobre a metodologia, ferramentas utilizadas e artefatos
que deveriam ser produzidos? Ou o conhecimento lhe foi passado de
maneira mais informal, ou seja, aos poucos você foi aprendendo o
processo na prática? Além disso, gostaria de saber sua percepção sobre
quão definido é o processo e o quão fácil foi aprendê-lo.
Isso não é uma pesquisa nem nada, só quero ouvir algumas opiniões para
ter uma idéia de como o mercado está lidando com a transferência do
conhecimento nessa área.
Aguardo seus comentários :)
Anderson Valentim de Bastos
May 8, 2012, 5:19:55 PM5/8/12
to an...@googlegroups.com
Adriana, boa-noite.
Na empresa onde eu trabalhava existia um departamento de análise de negócios com cerca de 200 analistas, este departamento tinha uma estrutura própria e atendia as unidades de negócio em um formato matricial, além disso o departamento tinha processo e metodologia consolidada. Existia uma divisão entre analistas de requisitos e analistas de atendimento, os analistas de requisitos eram responsável pela engenharia de requisitos produzindo a especificação funcional e os analistas de atendimento ficavam em loco nas unidades de negócio prestando um serviço de consultoria de negócio e T.I
Nesta empresa eu tive vários treinamentos formais, sendo de competências comportamentais como técnicas de reunião, liderança e técnicas de negociação, e de competências técnicas incluindo engenharia e elicitação de requisitos (baseado no babok), gerenciamento de projetos, elaboração de especificação funcional, BPMN e SOA.
Anderson Valentim de Bastos
anderso...@yahoo.com.br
anderso...@gmail.com.br
Espero ter ajudado.
Att.
-- Anderson Valentim de Bastos
anderso...@yahoo.com.br
anderso...@gmail.com.br
Camila Franco
May 8, 2012, 5:46:59 PM5/8/12
to an...@googlegroups.com
Ola Adriana,
Eu trabalho em SF e em empresas do Silicon Valley na CA, aqui a maioria das empresas tem formatos de documentacao que esles pedem para o Analista usar, mas na maioria das vezes nao existe uma area que nem o Anderson exemplificou, a Analise de Negocios eh espalhada, ou seja cada departamento tem os seus Analistas e cada Analista traz algo de diferente com ele/ela. Na maioria das Xs eu pergunto peco para ver os templates e tb quais ferramentas eles usam.
Na minha empresa atual e em outra que trabalhei eu mesmo deselvolvi o set de documentacoes e uso a tecnica que aprendi atraves de escola e livors(antes fo BABOK existir), Claro que sempre aprendo algo novo com os meus colegas e levo comigo para o proximo emprego.
Quando trabalhei para um dos bancos aqui, eles tinham um centro de AN que nem o Anderson descreveu, igualzinho, nos, os analistas ajudavamos a manter os templates de documentacao e eramos alocados em projetos por todo o banco. E eu sei que de fato os bancos seguem este principio, desenvolvem uma area que nem um PMO mas para Analistas, mas outras empresas, mesmo grandes, nao seguem a mesma ideia.
Muitas empresas pagam para seus funcionarios irem aprender, entao muita gente usa este incentivo para ter aulas no assunto, no caso do Analista, en AN.
Eu sou a favor de uma area dedicada, por que as Xs eh dificil responder para uma gerencia q nao entende nada de analise de negocios, mas por outro lado eh divertido ensinar sobre o assunto :).
Abracos,
Camila
Eu trabalho em SF e em empresas do Silicon Valley na CA, aqui a maioria das empresas tem formatos de documentacao que esles pedem para o Analista usar, mas na maioria das vezes nao existe uma area que nem o Anderson exemplificou, a Analise de Negocios eh espalhada, ou seja cada departamento tem os seus Analistas e cada Analista traz algo de diferente com ele/ela. Na maioria das Xs eu pergunto peco para ver os templates e tb quais ferramentas eles usam.
Na minha empresa atual e em outra que trabalhei eu mesmo deselvolvi o set de documentacoes e uso a tecnica que aprendi atraves de escola e livors(antes fo BABOK existir), Claro que sempre aprendo algo novo com os meus colegas e levo comigo para o proximo emprego.
Quando trabalhei para um dos bancos aqui, eles tinham um centro de AN que nem o Anderson descreveu, igualzinho, nos, os analistas ajudavamos a manter os templates de documentacao e eramos alocados em projetos por todo o banco. E eu sei que de fato os bancos seguem este principio, desenvolvem uma area que nem um PMO mas para Analistas, mas outras empresas, mesmo grandes, nao seguem a mesma ideia.
Muitas empresas pagam para seus funcionarios irem aprender, entao muita gente usa este incentivo para ter aulas no assunto, no caso do Analista, en AN.
Eu sou a favor de uma area dedicada, por que as Xs eh dificil responder para uma gerencia q nao entende nada de analise de negocios, mas por outro lado eh divertido ensinar sobre o assunto :).
Abracos,
Camila
2012/5/8 Anderson Valentim de Bastos <anderso...@gmail.com>
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
Adriana Selleri
May 8, 2012, 6:30:08 PM5/8/12
to Análise de Negócios . br
Anderson e Camila,
Obrigada pelas respostas de vocês! Um fato interessante é que já com
as respostas de vocês dois veio à tona um fato curioso: no Brasil acho
que a tendência é a criação de áreas específicas com métodos
definidos, procedimentos e ferramentas. Na opinião de vocês isso
aumenta a qualidade do processo de Análise de Requisitos ou limita a
criatividade e evolução?
Minha opinião: Há pouco tempo tive contato com um conceito chamado
"Fábrica de Experiência" (Experience Factory), que utiliza as lições
aprendidas em projetos anteriores para ativamente (e constantemente)
melhorar os processos enquanto constrói um método, mas o início de
tudo é a experimentação - claro que existe um forte componente de
pesquisa também, experimentação nesse caso não é "tentativa e erro"
simplesmente. Quando falo "lições aprendidas", neste caso, não me
refiro às míticas reuniões de fim de projeto para apontar culpados e
criar documentos que nunca serão lidos. Na "Experience Factory" os
modelos/ procedimentos/ templates/ artefatos/ ferramentas/etc que
compõem o processo já existente são efetivamente modificados de acordo
com o que a experiência mostrou funcionar/não funcionar num
determinado contexto, e assim o processo evolui e se adapta.
Acho esse modelo interessante e vi que sendo usado na prática no
instituto de pesquisa em que trabalho, mas no mercado talvez não seja
tão aplicável porque as empresas às vezes não podem (ou não querem) se
dar ao luxo de experimentar e aderem a uma padronização que em alguns
casos engessa e burocratiza. Eu particularmente gosto da idéia de unir
os dois conceitos: padronização do que pode ser reutilizado +
liberdade para experimentação e melhoria. Acho que padrões são
importantes para gestão e acompanhamento dos processos mas, como na
vida, mudar e melhorar sempre é preciso também.
Obrigada pelas respostas de vocês! Um fato interessante é que já com
as respostas de vocês dois veio à tona um fato curioso: no Brasil acho
que a tendência é a criação de áreas específicas com métodos
definidos, procedimentos e ferramentas. Na opinião de vocês isso
aumenta a qualidade do processo de Análise de Requisitos ou limita a
criatividade e evolução?
Minha opinião: Há pouco tempo tive contato com um conceito chamado
"Fábrica de Experiência" (Experience Factory), que utiliza as lições
aprendidas em projetos anteriores para ativamente (e constantemente)
melhorar os processos enquanto constrói um método, mas o início de
tudo é a experimentação - claro que existe um forte componente de
pesquisa também, experimentação nesse caso não é "tentativa e erro"
simplesmente. Quando falo "lições aprendidas", neste caso, não me
refiro às míticas reuniões de fim de projeto para apontar culpados e
criar documentos que nunca serão lidos. Na "Experience Factory" os
modelos/ procedimentos/ templates/ artefatos/ ferramentas/etc que
compõem o processo já existente são efetivamente modificados de acordo
com o que a experiência mostrou funcionar/não funcionar num
determinado contexto, e assim o processo evolui e se adapta.
Acho esse modelo interessante e vi que sendo usado na prática no
instituto de pesquisa em que trabalho, mas no mercado talvez não seja
tão aplicável porque as empresas às vezes não podem (ou não querem) se
dar ao luxo de experimentar e aderem a uma padronização que em alguns
casos engessa e burocratiza. Eu particularmente gosto da idéia de unir
os dois conceitos: padronização do que pode ser reutilizado +
liberdade para experimentação e melhoria. Acho que padrões são
importantes para gestão e acompanhamento dos processos mas, como na
vida, mudar e melhorar sempre é preciso também.
Anderson Valentim de Bastos
May 8, 2012, 7:20:32 PM5/8/12
to an...@googlegroups.com
Adriana... Montar uma área de análise de negócio é sim um tendência, eu acabei de trocar de emprego e o mercado está aquecido para os ANs não só por causa da situação econômica do nosso país, mas também poque as empresas estão começando a enxergar o valor e a nobreza da função do analista de negócios, em um mercado cada vez mais competitivo onde os investimentos em T.I devem estar totalmente aderente com a estratégia das organizações.. Agora respondendo a sua pergunta..
Na opinião de vocês isso
aumenta a qualidade do processo de Análise de Requisitos ou limita a
criatividade e evolução?
aumenta a qualidade do processo de Análise de Requisitos ou limita a
criatividade e evolução?
Acredito que um pouco das duas coisas... eu, assim como muito analista, sou meio avesso a padronizações e templates. Acredito sim que isto limita a criatividade, mas dependendo do modelo de negócio, tamanho e cultura da organização, em um banco como foi citado pela nossa colega Camila, a padronização acaba sendo necessária para que possamos ter um pouco mais de organização, para atendermos algumas normas (Basiléia, SOX, ISO e etc..), para tentar reaproveitar alguma coisa e etc..
Achei muito interessante este processo de "Experience Factory", gostaria até que vc comentasse um pouco mais sobre o assunto, mais detalhes de como funciona e principalmente... de como eu posso vender esta ideia..
Fui..
Adriana Selleri
May 9, 2012, 6:09:39 AM5/9/12
to Análise de Negócios . br
Oi Anderson,
Na verdade estou aprendendo como funciona também, meu professor é um
dos autores do método e estamos estudando isto agora. Este artigo
explica os fundamentos e comenta algumas aplicações:
http://www.google.com.br/url?sa=t&rct=j&q=%22experience%20factory%22&source=web&cd=1&ved=0CFoQFjAA&url=http%3A%2F%2Fagde.informatik.uni-kl.de%2Fteaching%2Fqmss%2Fws2009%2Fmaterial%2Fexcercise%2FexperienceFactory.pdf&ei=rzyqT8_qG-Xa4QSU3MGbAQ&usg=AFQjCNG3MswSJ7Xnltfpsj4GaZuIV22BOQ&cad=rja
Se quiser podemos trocar umas idéias sobre como poderia ser aplicado
(a maioria das aplicações práticas, incluindo a NASA, se deu através
de cooperações com universidades e institutos e pesquisa). Um forte
envolvimento de alguém responsável por qualidade/processos se faz
necessário (que pode não ser necessariamente um departamento separado,
alguém da propria TI poderia assumir este papel), pois esse alguém
precisa comprar a idéia e assumir a responsabilidade por manter a
"fábrica" funcionando.
Até mais,
Adriana
On May 9, 1:20 am, Anderson Valentim de Bastos
> andersonvbas...@yahoo.com.br
> andersonvbas...@gmail.com.br
Na verdade estou aprendendo como funciona também, meu professor é um
dos autores do método e estamos estudando isto agora. Este artigo
explica os fundamentos e comenta algumas aplicações:
http://www.google.com.br/url?sa=t&rct=j&q=%22experience%20factory%22&source=web&cd=1&ved=0CFoQFjAA&url=http%3A%2F%2Fagde.informatik.uni-kl.de%2Fteaching%2Fqmss%2Fws2009%2Fmaterial%2Fexcercise%2FexperienceFactory.pdf&ei=rzyqT8_qG-Xa4QSU3MGbAQ&usg=AFQjCNG3MswSJ7Xnltfpsj4GaZuIV22BOQ&cad=rja
Se quiser podemos trocar umas idéias sobre como poderia ser aplicado
(a maioria das aplicações práticas, incluindo a NASA, se deu através
de cooperações com universidades e institutos e pesquisa). Um forte
envolvimento de alguém responsável por qualidade/processos se faz
necessário (que pode não ser necessariamente um departamento separado,
alguém da propria TI poderia assumir este papel), pois esse alguém
precisa comprar a idéia e assumir a responsabilidade por manter a
"fábrica" funcionando.
Até mais,
Adriana
On May 9, 1:20 am, Anderson Valentim de Bastos
<andersonvbas...@gmail.com> wrote:
> Adriana... Montar uma área de análise de negócio é sim um tendência, eu
> acabei de trocar de emprego e o mercado está aquecido para os ANs não só
> por causa da situação econômica do nosso país, mas também poque as empresas
> estão começando a enxergar o valor e a nobreza da função do analista de
> negócios, em um mercado cada vez mais competitivo onde os investimentos em
> T.I devem estar totalmente aderente com a estratégia das organizações..
> Agora respondendo a sua pergunta..
>
> *Na opinião de vocês isso
> Adriana... Montar uma área de análise de negócio é sim um tendência, eu
> acabei de trocar de emprego e o mercado está aquecido para os ANs não só
> por causa da situação econômica do nosso país, mas também poque as empresas
> estão começando a enxergar o valor e a nobreza da função do analista de
> negócios, em um mercado cada vez mais competitivo onde os investimentos em
> T.I devem estar totalmente aderente com a estratégia das organizações..
> Agora respondendo a sua pergunta..
>
> aumenta a qualidade do processo de Análise de Requisitos ou limita a
> criatividade e evolução? *
>
> Acredito que um pouco das duas coisas... eu, assim como muito analista, sou
> meio avesso a padronizações e templates. Acredito sim que isto limita a
> criatividade, mas dependendo do modelo de negócio, tamanho e cultura da
> organização, em um banco como foi citado pela nossa colega Camila, a
> padronização acaba sendo necessária para que possamos ter um pouco mais de
> organização, para atendermos algumas normas (Basiléia, SOX, ISO e etc..),
> para tentar reaproveitar alguma coisa e etc..
>
> Achei muito interessante este processo de "Experience Factory", gostaria
> até que vc comentasse um pouco mais sobre o assunto, mais detalhes de como
> funciona e principalmente... de como eu posso vender esta ideia..
>
> Fui..
>
> --
> *Anderson Valentim de Bastos*
> Acredito que um pouco das duas coisas... eu, assim como muito analista, sou
> meio avesso a padronizações e templates. Acredito sim que isto limita a
> criatividade, mas dependendo do modelo de negócio, tamanho e cultura da
> organização, em um banco como foi citado pela nossa colega Camila, a
> padronização acaba sendo necessária para que possamos ter um pouco mais de
> organização, para atendermos algumas normas (Basiléia, SOX, ISO e etc..),
> para tentar reaproveitar alguma coisa e etc..
>
> Achei muito interessante este processo de "Experience Factory", gostaria
> até que vc comentasse um pouco mais sobre o assunto, mais detalhes de como
> funciona e principalmente... de como eu posso vender esta ideia..
>
> Fui..
>
> --
> andersonvbas...@yahoo.com.br
> andersonvbas...@gmail.com.br
Claudio Br (Kerber)
May 9, 2012, 9:02:45 AM5/9/12
to an...@googlegroups.com
Eu aprendi a fazer engenharia de requisitos desenvolvendo sistemas de gestão. Era usuário de requisitos e depois passei a fornecedor (de usuário para traficante).
Atenciosamente,
Claudio Br
"Above us only ROI..." http://bit.ly/l3Ua01
........_˜Ô
...._ \ >_
...(_) / (_)
Siga-me no Twitter
Atenciosamente,
Claudio Br
"Above us only ROI..." http://bit.ly/l3Ua01
........_˜Ô
...._ \ >_
...(_) / (_)
Siga-me no Twitter
@oclaudiobr (profissional)
@uclaudiobr (pessoal)
Willem Dijkgraaf
May 9, 2012, 9:28:45 AM5/9/12
to Análise de Negócios . br
Oi grupo,
Em 2007 lançei o livro "Start at the end, with SMART requirements"
sobre "engenharia de requisitos". Nada academica e na verdade não é
sobre "engenharia"... não sou um grande fã dessa palavra em contexto
dos requisitos :-)
Escrevi o livro com o objetivo de ajudar a maioria das empresas com
uma "metodologia" pratica de especificar, quantificar, medir e
gerenciar requisitos. As 24 diretrizes são bem praticas (alinhadas
com BABOK) e cade diretriz tem um exemplo para mostrar como pode ser
aplicado.
Dois meses atras o livro foi publicado online e está disponível ...
gratís! Com um blog bem interessante para os analistas de negócios.
Tudo sobre requisitos de negócios e análise de negócios.
http://www.businessrequirementstips.com
Este livro e metodologia já foi adoptado como o padrão para
especificar requisitos pelo grandes empresas na Europa como Philips,
Bosch, ING e várias outras. Treinei 3000+ analistas e donos de
produtos em "start at the end" = "comece pelo fim".
Espero que é interessante para os Analistas de Negócios desse grupo.
Provavelmente vai ter uma versão em Português em 2012 também!
Desculpa o meu Português ... ainda não está melhorando tão rapido :-)
Abração,
Willem Dijkgraaf, CBAP
http://www.interdual.com.br
Em 2007 lançei o livro "Start at the end, with SMART requirements"
sobre "engenharia de requisitos". Nada academica e na verdade não é
sobre "engenharia"... não sou um grande fã dessa palavra em contexto
dos requisitos :-)
Escrevi o livro com o objetivo de ajudar a maioria das empresas com
uma "metodologia" pratica de especificar, quantificar, medir e
gerenciar requisitos. As 24 diretrizes são bem praticas (alinhadas
com BABOK) e cade diretriz tem um exemplo para mostrar como pode ser
aplicado.
Dois meses atras o livro foi publicado online e está disponível ...
gratís! Com um blog bem interessante para os analistas de negócios.
Tudo sobre requisitos de negócios e análise de negócios.
http://www.businessrequirementstips.com
Este livro e metodologia já foi adoptado como o padrão para
especificar requisitos pelo grandes empresas na Europa como Philips,
Bosch, ING e várias outras. Treinei 3000+ analistas e donos de
produtos em "start at the end" = "comece pelo fim".
Espero que é interessante para os Analistas de Negócios desse grupo.
Provavelmente vai ter uma versão em Português em 2012 também!
Desculpa o meu Português ... ainda não está melhorando tão rapido :-)
Abração,
Willem Dijkgraaf, CBAP
http://www.interdual.com.br
Wylker Barros
May 9, 2012, 9:31:33 AM5/9/12
to an...@googlegroups.com
Adriana,
A primeira vez que iniciei com análise de requisitos foi no meu primeiro projeto, ainda na faculdade, lá pras bandas de 2003. Eu realizava análise de requisitos, desenvolvia e testava.
Em meados de 2009 assumi em uma organização um cargo exclusivamente para tratar de requisitos. Naquele momento, eu era o único analista de requisitos e a organização estava elaborando seu processo de desenvolvimento de software e, em algumas de suas "caixinhas", o analista de requisitos estava como responsável. Ainda lembro o que tinha nessas caixinhas: Identificar os Requisitos Gerais do Sistema; Validar os Requisitos; e Corrigir os requisitos. Observando friamente essas tarefas, não é possível dizer "como é feita a engenharia de requisitos", mas de alguma forma essa fase de análise estava "estabelecida" no processo de desenvolvimento. Não havia atividades, técnicas ou habilidades exigidas, não havia modelos de documentos (templates), NADA. Com isso, fui montando o modelo "My Way" - misturando técnicas, filosofias, artefatos, modelos....
Em síntese, o processo de "engenharia de requisitos" (não entendo por quê se chama engenharia) existia, mas com crise de identidade. Quando entrei na organização meu dever era: Identificar os Requisitos Gerais do Sistema; Validar os Requisitos; e Corrigir os requisitos. Quando saí, estava envolvido com: identificação, especificação, comunicação e validação de requisitos; decomposição e priorização do sprint backlog; apoio a UX e testes; análise de investimento; planejamento e monitoramento de prazos; controle de mudanças.....e principalmente, comunicação entre os envolvidos nos projetos.
Concluo dizendo que, para a minha alegria, entendo que a análise de requisitos deve ser uma fase no processo de qualquer iniciativa, porém, suas atividades não precisão estar definidas, mas em constante evolução. Parafraseando Bob Dylan: "... não posso entender os valores da definição e do confinamento. A definição destrói"
Camila Franco
May 9, 2012, 3:58:55 PM5/9/12
to an...@googlegroups.com
Oi Adriana,
A respeito da sua ultime pergunta:
" Na opinião de vocês isso
aumenta a qualidade do processo de Análise de Requisitos ou limita a
criatividade e evolução?"
Depende, se a ideia de ter uma area de AN eh tambem poder trocar figurinhas entao nao limita, acho q troca de experiencias eh sempre a melhor opcao, claro que no comeco a maioria tem que deixar o ego na porta e entender que talvez haja jeitos diferentes de fazer a mesma coisa, nao significa que o q vc esta fazendo eh errado.
Acho q tb um area como esta ajuda no desenvolvimento de analistas Jrs, coisa q eu nao vejo muito por aqui, a maioria tem que ter 5 anos de experiencia.
Uma area que nem o PMO tambem ajuda a dar um suporte para os Analistas, ajuda a criar documentos que serao usados por toda a empresa.
Agora, ha casos em que a Analise de negocios nao esta associada a um Analista e sim eh parte de um outro papel: por exemplo: Gerente de Produtos, Gerentes de TI,.... Nestes casos uma area para Analise de Negocios, na minha opiniao eh um pouco mais dificil de criar.
Camila
A respeito da sua ultime pergunta:
" Na opinião de vocês isso
aumenta a qualidade do processo de Análise de Requisitos ou limita a
criatividade e evolução?"
Acho q tb um area como esta ajuda no desenvolvimento de analistas Jrs, coisa q eu nao vejo muito por aqui, a maioria tem que ter 5 anos de experiencia.
Uma area que nem o PMO tambem ajuda a dar um suporte para os Analistas, ajuda a criar documentos que serao usados por toda a empresa.
Agora, ha casos em que a Analise de negocios nao esta associada a um Analista e sim eh parte de um outro papel: por exemplo: Gerente de Produtos, Gerentes de TI,.... Nestes casos uma area para Analise de Negocios, na minha opiniao eh um pouco mais dificil de criar.
Camila
2012/5/9 Wylker Barros <wyl...@gmail.com>
--
Adriana Selleri
May 10, 2012, 10:28:05 AM5/10/12
to Análise de Negócios . br
Obrigada pela participação de todos :)
Minha pergunta foi justamente porque, como a Camila mencionou, tenho a
impressão de que ANs iniciando nas empresas podem beneficiar-se da
existência de uma metodologia claramente comunicada.
Vivi uma situação parecida com a que o Wylker relatou: aprendi a fazer
análise de requisitos na faculdade, depois em pequenos projetos
independentes em que, além de AN, eu era também desenvolvedora/
testadora/GP/etc, mas quando comecei a atuar somente como AN, foi em
uma empresa que cresceu rapidamente e não tinha método algum para
análise/engenharia de requisitos. O que existia era apenas um
resultado que precisava ser atingido, mas cada analista trabalhava em
um projeto distinto e criava seus proprios métodos praticamente "on
the run". Esse tipo de cenário gera muito overhead, dificulta o
trabalho do iniciante e gera diferença na qualidade das entregas
porque confia na experiência de cada um e ANs iniciantes nao tem
maturidade profissional (e muitas vezes nem bagagem) para produzir os
mesmos resultados que um AN experiente sem orientação e padronização.
Onde trabalho atualmente , há uma metodologia que foi criada
internamente e é comunicada logo na integração dos novos membros da
equipe de requisitos através de treinamento e análise de documentos
produzidos em projetos anteriores. Mesmo já trabalhando na área há
bastante tempo (quase 10 anos fazendo Análise de Negócios de uma forma
ou de outra), achei a metodologia bastante útil e flexível. Fiquei
pensando em como algo do tipo teria poupado muito trabalho e stress
nos meus primeiros projetos como AN. E não estou falando que é uma
"fórmula milagrosa" porque isso não existe; a empresa apenas
explicitou o conhecimento adquirido através de pesquisa e, mais
importante, da experiência prática obtida ao longo dos anos
desenvolvendo projetos de software.
Tenho a impressão de que essa comunicação clara de um método que sirva
de referência acelera muito o processo de integração e aumenta a
produtividade especiamente de quem está começando. Acho que isso
acontece, em partes, porque na maioria dos cursos de graduação em
computação AN (no sentido mais amplo do termo, não apenas a análise de
requisites) não é abordada. Aliás, mesmo a "Engenharia de Requisitos"
só é vista como um dos processos de Engenharia de Software, estudada
superficialmente e apenas com relação a aspectos técnicos. Mesmo os
cursos livres de formação normalmente abordam frameworks, ferramentas
e técnicas, mas sem experiência prática e sem nunca ter visto nenhum
método, o AN iniciante fica perdido sem saber por onde começar.
Gosto deste tópico porque o AN iniciante, o que esta migrando da area
tecnica ou mesmo de outros domínios não nasce sabendo, então acho que
uma metodologia consistente ajuda muito. Depois, com a experiência, a
própria pessoa pode identificar os prós e contras do método e ajudar a
melhorá-lo.
Adriana
Minha pergunta foi justamente porque, como a Camila mencionou, tenho a
impressão de que ANs iniciando nas empresas podem beneficiar-se da
existência de uma metodologia claramente comunicada.
Vivi uma situação parecida com a que o Wylker relatou: aprendi a fazer
análise de requisitos na faculdade, depois em pequenos projetos
independentes em que, além de AN, eu era também desenvolvedora/
testadora/GP/etc, mas quando comecei a atuar somente como AN, foi em
uma empresa que cresceu rapidamente e não tinha método algum para
análise/engenharia de requisitos. O que existia era apenas um
resultado que precisava ser atingido, mas cada analista trabalhava em
um projeto distinto e criava seus proprios métodos praticamente "on
the run". Esse tipo de cenário gera muito overhead, dificulta o
trabalho do iniciante e gera diferença na qualidade das entregas
porque confia na experiência de cada um e ANs iniciantes nao tem
maturidade profissional (e muitas vezes nem bagagem) para produzir os
mesmos resultados que um AN experiente sem orientação e padronização.
Onde trabalho atualmente , há uma metodologia que foi criada
internamente e é comunicada logo na integração dos novos membros da
equipe de requisitos através de treinamento e análise de documentos
produzidos em projetos anteriores. Mesmo já trabalhando na área há
bastante tempo (quase 10 anos fazendo Análise de Negócios de uma forma
ou de outra), achei a metodologia bastante útil e flexível. Fiquei
pensando em como algo do tipo teria poupado muito trabalho e stress
nos meus primeiros projetos como AN. E não estou falando que é uma
"fórmula milagrosa" porque isso não existe; a empresa apenas
explicitou o conhecimento adquirido através de pesquisa e, mais
importante, da experiência prática obtida ao longo dos anos
desenvolvendo projetos de software.
Tenho a impressão de que essa comunicação clara de um método que sirva
de referência acelera muito o processo de integração e aumenta a
produtividade especiamente de quem está começando. Acho que isso
acontece, em partes, porque na maioria dos cursos de graduação em
computação AN (no sentido mais amplo do termo, não apenas a análise de
requisites) não é abordada. Aliás, mesmo a "Engenharia de Requisitos"
só é vista como um dos processos de Engenharia de Software, estudada
superficialmente e apenas com relação a aspectos técnicos. Mesmo os
cursos livres de formação normalmente abordam frameworks, ferramentas
e técnicas, mas sem experiência prática e sem nunca ter visto nenhum
método, o AN iniciante fica perdido sem saber por onde começar.
Gosto deste tópico porque o AN iniciante, o que esta migrando da area
tecnica ou mesmo de outros domínios não nasce sabendo, então acho que
uma metodologia consistente ajuda muito. Depois, com a experiência, a
própria pessoa pode identificar os prós e contras do método e ajudar a
melhorá-lo.
Adriana
Fabrício Laguna
May 10, 2012, 11:12:33 AM5/10/12
to an...@googlegroups.com
Excelente relato, Adriana.
--
O valor da Metodologia sentido em sua experiência ficou muito claro.
Obrigado por compartilhá-lo conosco.
Fabrício
Adriana
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
| Fabrício Laguna Consultor e Instrutor |
Jean Streleski
May 10, 2012, 6:58:22 PM5/10/12
to an...@googlegroups.com
Aprendi análise de negócios atuando como programador que só tomava porrada nas entregadas de releases para os usuários (Eu era o super analista programador).
Ia estudando de tudo pra ver o que me ajudava (Orientação a objeto, UML, CMMi, ISO, análise de negócio e etc). Ia usando nos projetos (sempre tive liberdade de ousar por trabalhar em empresas pequenas) e vendo que muitas nada resolviam o problema de aderência às necessidades dos clientes e outras atrapalhavam muito mais que ajudavam.
Foi na base da tentativa e erro mesmo. Aprendi AN pela dor, não pelo amor =).
Falei um pouco disto na palestra do IIBA em março.
Silva, Ailton
May 11, 2012, 12:11:17 PM5/11/12
to an...@googlegroups.com
Olá Adriana,
Quando iniciei minha carreira eu entrei em uma empresa pequena e não tínhamos processo de desenvolvimento nem de análise de negócios definidos. Era meio pastelaria. Eu mesmo "especificava" e eu mesmo "desenvolvia". Eu pautava minhas especificações / desenvolvimento para maior rapidez no 5W2H.
No meu emprego atual quando entrei já tínhamos um processo definido, claro e comunicado o qual era pautado no CMMI(bastante documentado). Mas foi descontinuado. Buscamos mais agilidade nas entregas e no momento estamos estudando melhorias. É muito provável (vamos ver) que no evento do IIBA do dia 30/05 mostraremos como trabalhamos com mais detalhes. Mas creio que - de uma maneira geral - fazemos o que mercado pratica: documento de especificação(requisitos ,regras, premissas, restrições, fluxo do processo com bpmn, dfds, use cases, etc...) , plano de projeto, status report, desenvolvimento com prática scrum, etc...)
Abs
Ailton Silva
Análise de Negócios
Tel. 5511 2847-8584
Fax. 5511 2847-9746
Cel. 5511 7227-3488
ailton...@br.experian.com
serasaexperian.com.br
-----Mensagem original-----
De: an...@googlegroups.com [mailto:an...@googlegroups.com] Em nome de Adriana Selleri
Enviada em: quinta-feira, 10 de maio de 2012 11:28
Para: Análise de Negócios . br
Assunto: [an.br :: 8635] Re: Como você aprendeu a fazer engenharia de requisitos na sua empresa?
As informações contidas nesta mensagem e no(s) arquivo(s) anexo(s) são endereçadas exclusivamente à(s) pessoa(s) e/ou instituição(ões) acima indicada(s), e podem conter dados confidenciais. É expressamente proibido a pessoas não autorizadas, sob qualquer forma ou pretexto, utilizá-las, divulgá-las, alterá-las, de forma impressa ou copiada, total ou parcialmente. Caso tenha recebido esta mensagem erroneamente, por favor, notifique o remetente e providencie imediata exclusão da original e de qualquer cópia. O uso impróprio será tratado conforme as normas da empresa e da legislação em vigor. Esta mensagem expressa o posicionamento pessoal do subscritor e não reflete necessariamente a opinião da Serasa Experian.
Quando iniciei minha carreira eu entrei em uma empresa pequena e não tínhamos processo de desenvolvimento nem de análise de negócios definidos. Era meio pastelaria. Eu mesmo "especificava" e eu mesmo "desenvolvia". Eu pautava minhas especificações / desenvolvimento para maior rapidez no 5W2H.
No meu emprego atual quando entrei já tínhamos um processo definido, claro e comunicado o qual era pautado no CMMI(bastante documentado). Mas foi descontinuado. Buscamos mais agilidade nas entregas e no momento estamos estudando melhorias. É muito provável (vamos ver) que no evento do IIBA do dia 30/05 mostraremos como trabalhamos com mais detalhes. Mas creio que - de uma maneira geral - fazemos o que mercado pratica: documento de especificação(requisitos ,regras, premissas, restrições, fluxo do processo com bpmn, dfds, use cases, etc...) , plano de projeto, status report, desenvolvimento com prática scrum, etc...)
Abs
Ailton Silva
Análise de Negócios
Tel. 5511 2847-8584
Fax. 5511 2847-9746
Cel. 5511 7227-3488
ailton...@br.experian.com
serasaexperian.com.br
-----Mensagem original-----
De: an...@googlegroups.com [mailto:an...@googlegroups.com] Em nome de Adriana Selleri
Enviada em: quinta-feira, 10 de maio de 2012 11:28
Para: Análise de Negócios . br
Assunto: [an.br :: 8635] Re: Como você aprendeu a fazer engenharia de requisitos na sua empresa?
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
This email and any attachments are for the exclusive and confidential use of the named intended recipient(s) and may be legally privileged. Any review, re-transmission, dissemination or any other use of its contents, or taking of any action in reliance upon this information by persons and/or entities other than the named intended recipient(s) is strictly prohibited. If you have received this communication in error, please send this communication back to the sender, disregard its contents, and promptly delete the original message and any copy of it from your computer systems. The misuse of this message will be dealt according to company rules and current legislation. This message expresses the sender’s point of view about the topics described and not necessarily expresses Serasa Experian’s opinion about them.
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
As informações contidas nesta mensagem e no(s) arquivo(s) anexo(s) são endereçadas exclusivamente à(s) pessoa(s) e/ou instituição(ões) acima indicada(s), e podem conter dados confidenciais. É expressamente proibido a pessoas não autorizadas, sob qualquer forma ou pretexto, utilizá-las, divulgá-las, alterá-las, de forma impressa ou copiada, total ou parcialmente. Caso tenha recebido esta mensagem erroneamente, por favor, notifique o remetente e providencie imediata exclusão da original e de qualquer cópia. O uso impróprio será tratado conforme as normas da empresa e da legislação em vigor. Esta mensagem expressa o posicionamento pessoal do subscritor e não reflete necessariamente a opinião da Serasa Experian.
Marcelo Neves
May 11, 2012, 12:19:35 PM5/11/12
to an...@googlegroups.com
Oi Adriana,
Marcelo Neves
Aprendi engenharia de requisitos como desenvolvedor de software no início dos anos 90 e consequentemente fui inserido no processo. A empresa já tinha nos seus ativos templates (Argh!!!) que eram utilizados pelo time. Não teve treinamento formal, o que anos mais tarde foi entendido como erro.
Hoje estou dando consultoria em uma empresa na criação de um departamento de análise de negócios. Nesse caso os profissionais estão recebendo treinamento formal e entendem o valor do mesmo.
Grande abraço,
Marcelo Neves
Suzandeise Thomé
May 14, 2012, 7:00:39 AM5/14/12
to an...@googlegroups.com
Oi Dri. Como está a Alemanha?
Vejo que muitos desta lista descreveram situações parecidas, onde aprenderam mais por "tentativa e erro".
Eu vivi uma situação diferente. Tive 3 semanas de treinamento no meu primeiro emprego em uma consultoria, onde entrei como desenvolvedora (não existia o papel de AN). A metodologia da empresa seguia o RAD (Rapid Application Development). Existia um único processo mapeado. Era UM slide de powerpoint que dizia: Escopo ->> Prototipação ->> Design ->> Desenvolvimento.
Existia um template (em Word ou Excel) pra cada fase do processo. E só. Os consultores mais novos aprendiam com os mais experientes na metodologia. Acredito que ter a oportunidade de ver um outro profissional mais experiente que vc em ação é a melhor (na verdade a única) forma de aprender a fazer AN. Isso acompanhado de "um pouco" de treinamento formal.
A grande diferença nessa empresa era que cada fase da metodologia tinha um responsável. E esta pessoa era um consultor experiente que saia de projetos em clientes e assumia o posto de especialista em uma determinada fase somente por 6 meses, no máximo um ano. Depois ele voltada à linha de frente, em clientes. No caso da especialista em Design, por exemplo, ela fazia reunião com cada time no final da fase de Design, para entender o que deu certo e o que não deu. Esta mesma pessoa fazia uma reunião de kick-off com cada time que iria iniciar um Design, pra ter certeza que estavam preparados. Nessa hora ela dava um mini-treinamento, falava das lições aprendidas por outros times, revisava os artefatos de entrada para esta fase, via qual a experiência do time para um Design, e complementava o know-how da equipe. E esta especialista em Design ficava encarregada de incorporar lições aprendidadas à metodologia e fazer atualizações no template. Eu fiz isso durante alguns meses para a fase de Escopo.
Não que eu não tenha aprendido coisas por tentativa e erro em algum momento. Cada situação diferente pede que você arrisque algo novo e com o tempo vc aprende a arriscar com responsabilidade.
O que vejo em muitas empresas, infelizmente, é uma falta de permitir que se pergunte o "porque" das coisas. Quem está encarregado de metodologia e treinamento muitas vezes está longe do dia-a-dia dos ANs/desenvolvedores/GPs. Os ANs, então, recebem templates prontos que não são ideais para a situação em questão, mas que devem ser usados porque "é assim que fazemos". Esta situação é perversa. Ao invés de coibir perguntas, deveríamos instigar ANs a fazer perguntas.
Quando eu comecei a trabalhar, eu não entendia do ambiente da empresa, nem muito de mercado, não sabia fazer um Business Case, etc. Minha área de atuação era a solução técnica. Porém, desde o meu primeiro dia de trabalho me ensinaram a pensar no VALOR que a solução técnica traria para o cliente. Não era a metodologia pela metodologia, nem o software pelo software, mas sim o que o cliente iria fazer com aquele software. Isso moldou meu pensamento. Se alguém não tiver apoio de metodologia nenhuma e nenhum treinamento, mas tiver este tipo de pensamento, fará um trabalho melhor do que quem tem treinamento, sabe como usar templates, mas fica focado no MEIO, e não no FIM.
-Suzandeise
--
Vejo que muitos desta lista descreveram situações parecidas, onde aprenderam mais por "tentativa e erro".
Eu vivi uma situação diferente. Tive 3 semanas de treinamento no meu primeiro emprego em uma consultoria, onde entrei como desenvolvedora (não existia o papel de AN). A metodologia da empresa seguia o RAD (Rapid Application Development). Existia um único processo mapeado. Era UM slide de powerpoint que dizia: Escopo ->> Prototipação ->> Design ->> Desenvolvimento.
Existia um template (em Word ou Excel) pra cada fase do processo. E só. Os consultores mais novos aprendiam com os mais experientes na metodologia. Acredito que ter a oportunidade de ver um outro profissional mais experiente que vc em ação é a melhor (na verdade a única) forma de aprender a fazer AN. Isso acompanhado de "um pouco" de treinamento formal.
A grande diferença nessa empresa era que cada fase da metodologia tinha um responsável. E esta pessoa era um consultor experiente que saia de projetos em clientes e assumia o posto de especialista em uma determinada fase somente por 6 meses, no máximo um ano. Depois ele voltada à linha de frente, em clientes. No caso da especialista em Design, por exemplo, ela fazia reunião com cada time no final da fase de Design, para entender o que deu certo e o que não deu. Esta mesma pessoa fazia uma reunião de kick-off com cada time que iria iniciar um Design, pra ter certeza que estavam preparados. Nessa hora ela dava um mini-treinamento, falava das lições aprendidas por outros times, revisava os artefatos de entrada para esta fase, via qual a experiência do time para um Design, e complementava o know-how da equipe. E esta especialista em Design ficava encarregada de incorporar lições aprendidadas à metodologia e fazer atualizações no template. Eu fiz isso durante alguns meses para a fase de Escopo.
Não que eu não tenha aprendido coisas por tentativa e erro em algum momento. Cada situação diferente pede que você arrisque algo novo e com o tempo vc aprende a arriscar com responsabilidade.
O que vejo em muitas empresas, infelizmente, é uma falta de permitir que se pergunte o "porque" das coisas. Quem está encarregado de metodologia e treinamento muitas vezes está longe do dia-a-dia dos ANs/desenvolvedores/GPs. Os ANs, então, recebem templates prontos que não são ideais para a situação em questão, mas que devem ser usados porque "é assim que fazemos". Esta situação é perversa. Ao invés de coibir perguntas, deveríamos instigar ANs a fazer perguntas.
Quando eu comecei a trabalhar, eu não entendia do ambiente da empresa, nem muito de mercado, não sabia fazer um Business Case, etc. Minha área de atuação era a solução técnica. Porém, desde o meu primeiro dia de trabalho me ensinaram a pensar no VALOR que a solução técnica traria para o cliente. Não era a metodologia pela metodologia, nem o software pelo software, mas sim o que o cliente iria fazer com aquele software. Isso moldou meu pensamento. Se alguém não tiver apoio de metodologia nenhuma e nenhum treinamento, mas tiver este tipo de pensamento, fará um trabalho melhor do que quem tem treinamento, sabe como usar templates, mas fica focado no MEIO, e não no FIM.
-Suzandeise
2012/5/10 Adriana Selleri <adriana...@gmail.com>
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
--
 |
Suzandeise Thomé, CBAP Analista de Negócios (55) 11 2737-2800 www.interdual.com.br |
|
Interdual profiles:
  |
Marcelo Neves
May 14, 2012, 9:15:44 AM5/14/12
to an...@googlegroups.com
Suzandeise,
Marcelo Neves
Gostei muito desse modelo do cara mais sênior trabalhando com o time menos experiente. Sempre defendi esse comportamento. Pode parecer óbvio, mas em muitas organizações isso não acontece. Diz-se que o tempo desses profissionais é caro demais para "perdendo" tempo com os menos experientes. Do que adianta a organização ter profissionais sênior se os mesmos não compartilham conhecimento tácito com os mais novos? Se o cara sai da organização todo o conhecimento adquirido é perdido.
Grande abraço,
Marcelo Neves
2012/5/14 Suzandeise Thomé <suzan...@interdual.com.br>
Catia Aparecida Lopes
May 14, 2012, 5:31:31 PM5/14/12
to an...@googlegroups.com
Também gostei desse modelo.
Más, infelizmente, prevalece sempre o tempo de entrega, que normalmente é mais rápido por quem tem mais experiência. Entendo que em cada trabalho haverão tarefas simples, médias e complexas e precisamos distribuí-las de forma apropriada e manter o ciclo de profissionais. Normalmente os mais experientes lideram grupos de pessoas menos experientes ao invés de executar, é uma forma de transferirem conhecimento e evita-se desperdícios .
Abraço,
Cátia
Marcelo
May 14, 2012, 7:39:07 PM5/14/12
to an...@googlegroups.com
Olá
Em terça-feira, 8 de maio de 2012 17h48min11s UTC-3, Adriana Selleri escreveu:
Para contribuir. Na empresa onde trabalho existe uma área que coordena toda a metodologia que a empresa adota.
A empresa patrocinou e patrocina cursos nos mais diversos papéis (Analistas de Negócios, Líderes de Projetos e etc).
E esta área é responsável por manter e controlar os artefatos que devem ser produzidos, adequando à Engenharia de Software, apoiando a todos no preenchimento e administração destes artefatos.
O processo é muito bem definido, mas a empresa tem que investir nisso, senão fica como comentado. Cada área cria sua própria metodologia e documentos.
No fundo, vira uma bagunça.
Em terça-feira, 8 de maio de 2012 17h48min11s UTC-3, Adriana Selleri escreveu:
Adriana Selleri
May 15, 2012, 4:08:23 AM5/15/12
to Análise de Negócios . br
Oi Suzan!
Por aqui está tudo bem, mas sempre muito ocupada com o trabalho e o
mestrado :)
Pois é, acho que o modelo que você teve a oportunidade de vivenciar é
o melhor, mesmo. Quando falo de treinamento, não precisa ser
necessariamente um treinamento formal. A transferência do conhecimento
através da atuação conjunta é com certeza mais eficiente que apenas
receber instrução sobre procedimentos, mas acredito que isso é porque
o AN experiente já tem seus próprios métodos, desenvolvidos ao longo
do tempo, e que funcionam comprovadamente.
Q questão é que a realidade em muitas empresas ainda não é esta. Às
vezes ocorre um certo "abandono" do AN novato, com ou sem treinamento,
e aprender a fazer AN SOZINHO é o que leva ao aprendizado por
"tentativa e erro". Acho que muitas empresas ainda não enxergam o
valor de manter um AN iniciante trabalhando por um tempo ao lado de um
mais experiente e, talvez por pressões de prazo e custo, acabam
jogando o AN iniciante aos leões.
Foi exatamente isso que aconteceu comigo: eu fazia análise de
requisitos para mapeamento de processos de negócio e necessidades de
parametrização/customização de um sistema de gestão, e havia apenas UM
analista alocado por projeto. Recebi um treinamento de dois meses e
meio mas este, como normalmente acontece, apenas abordava o sistema de
gestão em si(tecnologia). Eu não tinha idéia de melhores práticas, de
como outros analistas faziam (os projetos eram em cidades/estados
diferentes e até hoje não conheço alguns colegas que trabalhavam
comigo naquela época, pois nunca nos encontrávamos). Aprendi com muita
dor e com certeza "reinventei a roda" várias vezes, um desperdício de
tempo e recursos totalmente desnecessário, que poderia ser evitado se
a experiência que já existia dentro da organização tivesse sido, de
alguma forma, transmitida a mim e aos outros ANs iniciantes.
Se eu tivesse tido a oportunidade de atuar com um AN mais experiente
na época, com certeza o stress e o risco do projeto teriam sido bem
menores; por outro lado, uma vez que a empresa não podia "bancar" dois
ANs por projeto - devido ao número de implantações simultâneas - uma
referência de métodos/procedimentos usados pelos ANs experientes já
teria ajudado bastante.
Adriana
On May 14, 11:31 pm, Catia Aparecida Lopes <calo...@prodam.sp.gov.br>
wrote:
>
> 2012/5/14 Suzandeise Thomé <suzande...@interdual.com.br
> <mailto:suzande...@interdual.com.br> >
> 2012/5/10 Adriana Selleri <adriana.unic...@gmail.com
> <mailto:adriana.unic...@gmail.com> >
> <mailto:an...@googlegroups.com>
> <mailto:an-br-un...@googlegroups.com>
>
> --
>
> <http://www.interdual.com.br/wp-content/uploads/2011/06/logo.png>
>
> Interdual profiles:
> <http://www.linkedin.com/companies/interdual-consultoria> LinkedIn
> <http://twitter.com/interdual> Twitter
>
> <http://s.wisestamp.com/pixel.png?p=mozilla&v=2.0.4&t=1292848472206&u=...
> 7&e=3232>
> <mailto:an-br-un...@googlegroups.com>
>
> read more »
>
> ________________________________________________________________
>
> “Esta mensagem, incluindo seus anexos, é confidencial e seu conteúdo é restrito ao destinatário da mensagem. Caso você a tenha recebido por engano, queira, por favor, retorná-la ao destinatário e apagá-la de seus arquivos. É expressamente proibido o uso não autorizado, replicação ou disseminação da mesma. As opiniões contidas nesta mensagem e seus anexos não necessariamente refletem a opinião do órgão emissor. Grato pela colaboração”.
Por aqui está tudo bem, mas sempre muito ocupada com o trabalho e o
mestrado :)
Pois é, acho que o modelo que você teve a oportunidade de vivenciar é
o melhor, mesmo. Quando falo de treinamento, não precisa ser
necessariamente um treinamento formal. A transferência do conhecimento
através da atuação conjunta é com certeza mais eficiente que apenas
receber instrução sobre procedimentos, mas acredito que isso é porque
o AN experiente já tem seus próprios métodos, desenvolvidos ao longo
do tempo, e que funcionam comprovadamente.
Q questão é que a realidade em muitas empresas ainda não é esta. Às
vezes ocorre um certo "abandono" do AN novato, com ou sem treinamento,
e aprender a fazer AN SOZINHO é o que leva ao aprendizado por
"tentativa e erro". Acho que muitas empresas ainda não enxergam o
valor de manter um AN iniciante trabalhando por um tempo ao lado de um
mais experiente e, talvez por pressões de prazo e custo, acabam
jogando o AN iniciante aos leões.
Foi exatamente isso que aconteceu comigo: eu fazia análise de
requisitos para mapeamento de processos de negócio e necessidades de
parametrização/customização de um sistema de gestão, e havia apenas UM
analista alocado por projeto. Recebi um treinamento de dois meses e
meio mas este, como normalmente acontece, apenas abordava o sistema de
gestão em si(tecnologia). Eu não tinha idéia de melhores práticas, de
como outros analistas faziam (os projetos eram em cidades/estados
diferentes e até hoje não conheço alguns colegas que trabalhavam
comigo naquela época, pois nunca nos encontrávamos). Aprendi com muita
dor e com certeza "reinventei a roda" várias vezes, um desperdício de
tempo e recursos totalmente desnecessário, que poderia ser evitado se
a experiência que já existia dentro da organização tivesse sido, de
alguma forma, transmitida a mim e aos outros ANs iniciantes.
Se eu tivesse tido a oportunidade de atuar com um AN mais experiente
na época, com certeza o stress e o risco do projeto teriam sido bem
menores; por outro lado, uma vez que a empresa não podia "bancar" dois
ANs por projeto - devido ao número de implantações simultâneas - uma
referência de métodos/procedimentos usados pelos ANs experientes já
teria ajudado bastante.
Adriana
On May 14, 11:31 pm, Catia Aparecida Lopes <calo...@prodam.sp.gov.br>
wrote:
> Também gostei desse modelo.
>
> Más, infelizmente, prevalece sempre o tempo de entrega, que normalmente é
> mais rápido por quem tem mais experiência. Entendo que em cada trabalho
> haverão tarefas simples, médias e complexas e precisamos distribuí-las de
> forma apropriada e manter o ciclo de profissionais. Normalmente os mais
> experientes lideram grupos de pessoas menos experientes ao invés de
> executar, é uma forma de transferirem conhecimento e evita-se desperdícios .
>
> Abraço,
>
> Cátia
>
> _____
>
>
> Más, infelizmente, prevalece sempre o tempo de entrega, que normalmente é
> mais rápido por quem tem mais experiência. Entendo que em cada trabalho
> haverão tarefas simples, médias e complexas e precisamos distribuí-las de
> forma apropriada e manter o ciclo de profissionais. Normalmente os mais
> experientes lideram grupos de pessoas menos experientes ao invés de
> executar, é uma forma de transferirem conhecimento e evita-se desperdícios .
>
> Abraço,
>
> Cátia
>
> _____
>
> De: an...@googlegroups.com [mailto:an...@googlegroups.com] Em nome de
> Marcelo Neves
> Enviada em: segunda-feira, 14 de maio de 2012 10:16
> Para: an...@googlegroups.com
> Assunto: Re: [an.br :: 8656] Re: Como você aprendeu a fazer engenharia de
> requisitos na sua empresa?
>
> Suzandeise,
>
> Gostei muito desse modelo do cara mais sênior trabalhando com o time menos
> experiente. Sempre defendi esse comportamento. Pode parecer óbvio, mas em
> muitas organizações isso não acontece. Diz-se que o tempo desses
> profissionais é caro demais para "perdendo" tempo com os menos experientes.
> Do que adianta a organização ter profissionais sênior se os mesmos não
> compartilham conhecimento tácito com os mais novos? Se o cara sai da
> organização todo o conhecimento adquirido é perdido.
>
> Grande abraço,
>
> Marcelo Neves
> Fone: +55 21 9154-0029
>
> www.an202.com<http://www.an202.com>
> Marcelo Neves
> Enviada em: segunda-feira, 14 de maio de 2012 10:16
> Para: an...@googlegroups.com
> Assunto: Re: [an.br :: 8656] Re: Como você aprendeu a fazer engenharia de
> requisitos na sua empresa?
>
> Suzandeise,
>
> Gostei muito desse modelo do cara mais sênior trabalhando com o time menos
> experiente. Sempre defendi esse comportamento. Pode parecer óbvio, mas em
> muitas organizações isso não acontece. Diz-se que o tempo desses
> profissionais é caro demais para "perdendo" tempo com os menos experientes.
> Do que adianta a organização ter profissionais sênior se os mesmos não
> compartilham conhecimento tácito com os mais novos? Se o cara sai da
> organização todo o conhecimento adquirido é perdido.
>
> Grande abraço,
>
> Marcelo Neves
> Fone: +55 21 9154-0029
>
>
> 2012/5/14 Suzandeise Thomé <suzande...@interdual.com.br
> <mailto:suzande...@interdual.com.br> >
> <mailto:adriana.unic...@gmail.com> >
> <mailto:an-br-un...@googlegroups.com>
> Para mais opções, visite a página do grupo:http://groups.google.com/group/an-br?hl=pt-BR
> <http://groups.google.com/group/an-br?hl=pt-BR>
>
> Este grupo é administrado pelo Capítulo SP do IIBA -http://www.theiiba.org.br/<http://www.theiiba.org.br/>
> <http://groups.google.com/group/an-br?hl=pt-BR>
>
>
> --
>
> <http://www.interdual.com.br/wp-content/uploads/2011/06/logo.png>
>
> Suzandeise Thomé, CBAP
> Analista de Negócios
> (55) 11 2737-2800
> <http://www.interdual.com.br/>www.interdual.com.br
> Suzandeise Thomé, CBAP
> Analista de Negócios
> (55) 11 2737-2800
>
> Interdual profiles:
> <http://www.linkedin.com/companies/interdual-consultoria> LinkedIn
> <http://twitter.com/interdual> Twitter
>
> <http://s.wisestamp.com/pixel.png?p=mozilla&v=2.0.4&t=1292848472206&u=...
> 7&e=3232>
>
> --
> Mensagem do grupo AN-BR {Análise de Negócios}.
> Para publicar mensagens, mande um email para: an...@googlegroups.com
> <mailto:an...@googlegroups.com>
> --
> Mensagem do grupo AN-BR {Análise de Negócios}.
> Para publicar mensagens, mande um email para: an...@googlegroups.com
> <mailto:an-br-un...@googlegroups.com>
> Para mais opções, visite a página do grupo:http://groups.google.com/group/an-br?hl=pt-BR
> <http://groups.google.com/group/an-br?hl=pt-BR>
>
> Este grupo é administrado pelo Capítulo SP do IIBA -http://www.theiiba.org.br/<http://www.theiiba.org.br/>
> <http://groups.google.com/group/an-br?hl=pt-BR>
>
>
> --
> Mensagem do grupo AN-BR {Análise de Negócios}.
> Para publicar mensagens, mande um email para: an...@googlegroups.com
> Para cancelar sua participação, mande um email para:
> an-br-un...@googlegroups.com
> Para mais opções, visite a página do grupo:http://groups.google.com/group/an-br?hl=pt-BR
> <http://groups.google.com/group/an-br?hl=pt-BR>...
> --
> Mensagem do grupo AN-BR {Análise de Negócios}.
> Para publicar mensagens, mande um email para: an...@googlegroups.com
> Para cancelar sua participação, mande um email para:
> an-br-un...@googlegroups.com
> Para mais opções, visite a página do grupo:http://groups.google.com/group/an-br?hl=pt-BR
>
> read more »
>
> ________________________________________________________________
>
> “Esta mensagem, incluindo seus anexos, é confidencial e seu conteúdo é restrito ao destinatário da mensagem. Caso você a tenha recebido por engano, queira, por favor, retorná-la ao destinatário e apagá-la de seus arquivos. É expressamente proibido o uso não autorizado, replicação ou disseminação da mesma. As opiniões contidas nesta mensagem e seus anexos não necessariamente refletem a opinião do órgão emissor. Grato pela colaboração”.
Wilkner Anderson
May 15, 2012, 7:16:01 AM5/15/12
to an...@googlegroups.com
Ola, pessoal!
Sou iniciante em analise de negocio (na realidade, ainda nao tive a ctz se o q faco realmente seja, por mais q tenha buscado literatura para tanto) e gostaria de vivenciar uma experiencia semelhante a da Suzan, explico o pq:
Formalmente, sou analista de sistemas. Na empresa q trabalho nao existe a figura do AN. Alem de possuir experiencia com teste de software e analise de requisitos, funcao q estou exercendo.
A empresa nao possui praticas/metodologias de analise, por exemplo. Tento, com as dificuldades e urgencia do negocio, criar os documentos que acredito serem necessarios (visao, bussiness case e prototipacao), mas, a questao do entregar valor eh realmente importante, entao, as vezes acabo optando por atingir o objetivo, atropelando algumas fases. Tambem percebo que eh ruim nao ter nenhuma referencia, interna, de como seguir (seja por nao ter uma metodologia ou um profissional para orientar).
Resumidamente, nao consigo mostrar q o trabalho exercido esta alinhado com o babok, por exemplo (utilizando uma referencia). Para a empresa, a minha familiaridade com o core do negocio, alem da aptidao para detalhar as tarefas e repassa-las a equipe de desenvolvimento agilizam o trabalho do dia a dia, resultando em valores intangiveis e tangiveis.
Todo o conhecimento, acreditem, eh adquirido e mantido empiricamente.
Meu primeiro post no grupo, espero q tenham entendido um pouco do meu mundinho (olhando pela janela, parece q estamos isolados! Rss)!
Qualquer duvida me avisem! ;)
Obs: Pretendo abrir um topico para expor um pouco mais a minha realidade e tambem minhas duvidas, conto com a ajuda de voces.
Obrigado!
Enviado por Samsung Mobile
Reply all
Reply to author
Forward
0 new messages