14 dezembro, 2011

Métricas de gerenciamento que deveríamos conhecer

E não é que o LinkedIn sugere leituras muito interessantes? Acabei chegando ao site Forbes (que por sinal tem posts bem legais) e lendo um texto do James Slavet, da Greylock Partners, que investe no Facebook, LinkedIn, Groupon, Pandora, Redfin e One Kings Lane. 

Neste texto, ele fala sobre 5 novas métricas de gerenciamento que deveríamos conhecer, e foca que a maioria das empresas gerencia os outputs, e não os inputs, e com isso não conseguem mensurar como de fato podem melhorar a produtividade de seus funcionários.

Segue um breve resumo sobre essas métricas:

1) Percentual de estado de fluxo:
Trabalhos que exigem muito raciocínio exigem muita concentração. Quando você está profundamente concentrado e focado na sua atividade, você está no "estado de fluxo". Infelizmente, não conseguimos ficar muito tempo neste estado, pois somos interrompidos várias vezes durante o dia, por questões profissionais ou não, e levamos cerca de 15 minutos para retomarmos o foco. Uma das sugestões que ele aborda para contornar esta situação, é a utilização de plaquinhas do tipo "Go away... I’m Cranking" nas mesas, para momentos em que as pessoas não queiram ser perturbadas.

2) Ansiedade e tédio contínuos:
As pessoas podem se entediar facilmente, e muitas vezes trabalham melhor quando são cobradas por grandes desafios, do que por tarefas simples. Mas claro, os grandes desafios também não precisam ser esmagadores, pois a ansiedade prejudica tanto quanto o tédio. A sugestão aqui, é que as empresas estejam sempre de olho em seus funcionários, verificando sinais de desmotivação ou stress, para que consigam tomar as devidas providências.

3) Promover avaliação de reuniões:
na maioria das vezes reuniões em demasia não trazem retorno, e acabam gerando somente prejuízo à empresa. Uma ideia bem bacana que ele traz, é que nos últimos minutos de reunião, se pergunte aos participantes se eles avaliaram a reunião como produtiva, dando notas e sugestões de melhoria.

4) Taxa de aprendizagem semanal:
(Achei este o mais legal!) Pergunte ao seu time como ele conseguiu melhorar a produtividade em 1% durante a semana, se aprenderam algo novo sobre o cliente, ou conseguiram melhorar o produto de alguma maneira. Assim que o time entrar no ritmo de aprendizagem, este time irá melhorar 1% a cada semana.

5) Feedback positivo:
No trabalho, assim como nos relacionamentos, é preciso existir um equilíbrio entre interações positivas e negativas. Se este equilíbrio é perdido, as relações terminam e por isso as vezes passamos anos trabalhando com pessoas que dão tudo de si para nos mostrar todo seu esforço, e com pessoas que não sabem mais lidar com nossas críticas. A solução aqui? Elogiar as coisas boas que as pessoas fazem, por mais que estas coisas pareçam pequenas. Nunca perca a chance de falar alguma coisa agradável, assim, quando você precisar passar um feedback sobre aspectos de melhoria, as pessoas irão realmente escutar. 

O texto completo você pode encontrar no link Five new management metrics you need to know.

Até a próxima!

13 dezembro, 2011

Classificação de Requisitos

O BABOK® Guide classifica de uma maneira muito interessante os tipos de requisitos à que se refere ao longo do livro. Vale a pena dar uma conferida nesta prévia:


  • Requisitos do Negócio são metas de mais alto nível, objetivos ou necessidades da organização. Descrevem as razões pelas quais um projeto foi iniciado, os objetivos que o projeto vai atingir e as métricas que serão utilizadas para medir o seu sucesso.
  • Requisitos das partes interessadas (steakholders) são necessidades e interações de uma parte interessada em particular ou grupo de partes interessadas. 
  • Requisitos da solução descrevem as características de uma solução que atende aos requisitos do negócio e aos requisitos das partes interessadas. São frequentemente divididos em duas subcategorias:
    • Requisitos Funcionais descrevem o comportamento e a informação que a solução irá gerenciar, bem como as capacidades que o sistema será capaz de executar em termos de comportamentos e operações – ações ou respostas especificas de aplicativos de tecnologia da informação.
    • Requisitos Não-Funcionais capturam condições que não se relacionam diretamente ao comportamento ou funcionalidade da solução, mas descrevem condições ambientais sob as quais a solução deve permanecer efetiva, ou qualidades que os sistemas precisam possuir.
  • Requisitos de transição descrevem capacidades que a solução deve possuir com o objetivo de facilitar a transição do estado atual da organização para um estado futuro desejado, mas que não serão mais necessárias uma vez concluída a transição.
Bacana né? Estou aprendendo muito com este livro.

Até a próxima!

27 outubro, 2011

Ensinamentos de Steve Jobs

Assisti finalmente ao "Stanford Speech" feito por Steve Jobs. Uma oratória emocionante de vida e de motivação que vale  pena ser assistida.

Este é o tipo de vídeo que merece ser compartilhado, pois atinge nossa área pessoal e nossa área profissional, e nos faz pensar em rever conceitos.

"Você não pode conectar os pontos olhando adiante. Você só pode conectar os pontos olhando pra trás."

"Você precisa descobrir o que você ama, e isso é verdadeiro tanto para o seu trabalho quanto para as pessoas que você ama. Seu trabalho vai preencher uma grande parte da sua vida, e a única maneira de ficar realmente satisfeito é fazer o que você acredita ser um ótimo trabalho. E a única maneira de fazer um excelente trabalho é amando o que você faz. Se você ainda não encontrou o que é, continue procurando, e não sossegue."

Segue o vídeo. Have fun!

19 outubro, 2011

Princípios do Manifesto Ágil



Seguindo no tema da agilidade, vamos conversar sobre os princípios do Manifesto Ágil.

1. A maior prioridade é satisfazer o cliente, através de entregas antecipadas e contínuas de software que tenha valor. 
Aqui, o valor significa valor estratégico, valor de negócio, valor emocional, valor que de fato faça a diferença na vida do cliente. 

2. Aceitar as mudanças de requisitos, mesmo tardiamente no desenvolvimento. Processos ágeis aproveitam as mudanças para agregar vantagem competitiva ao cliente. 
Aceitar as mudanças, não quer dizer atropelar tudo que foi acordado para a entrega e criar um monstro. Quer dizer aceitar que o pacote não está fechado, e que o produto final pode ir mudando e sendo construído ao longo do caminho. 

3. Entregar frequentemente software que funcione, a cada duas semanas ou no máximo a cada dois meses, preferindo a menor escala de tempo. 
Claro que existem entregas mais demoradas que outras, mas a ideia é que sejam entregas constantes, onde o software vá evoluindo sob os olhos do cliente, e ele possa, já em um curto espaço de tempo, poder trabalhar com produto. 

4. Área de Negócio e Desenvolvimento precisam trabalhar juntos diariamente ao longo do projeto. 
Aqui fica clara a necessidade de colaboração que já foi comentada no post anterior. Quando o time está interagindo, discutindo soluções e ideias para o projeto, o envolvimento de todos aumenta, bem como o comprometimento. 

5. Construir projetos ao redor de pessoas motivadas, oferecendo o ambiente e o suporte que elas precisam, e confiar que essas pessoas farão seu trabalho. 
Confiança. Se as pessoas confiam no que estão fazendo, se confiam na organização em que trabalham, e também se a organização confia nas pessoas com que trabalha, a motivação vem ao natural, e pessoas motivadas sentem prazer em realizar suas tarefas. 

6. O mais eficiente e eficaz método de transmissão de informação para e dentro de um time de desenvolvimento é a conversa cara-a-cara. 
As vezes não é possível que o time esteja no mesmo local físico, e hoje em dia isso é muito normal, mas a conversa franca e direta sempre foi e sempre será o melhor caminho para se atingir qualquer objetivo. 

7. Software funcionando é a principal medida de sucesso. 
Essa é bem clara e não tem como ser diferente. 

8. Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. 
É não deixar a peteca cair. E não é só o ritmo de entregas de projetos, é também o ritmo da motivação, o ritmo do humor, o ritmo de horário, enfim, é manter a equipe alinhada com a própria equipe. 

9. Atenção contínua para com a excelência técnica e bom design aumenta a agilidade. 
Claro, melhorando a capacidade técnica da equipe, o produto também melhora, e quanto mais alinhados estiverem equipe técnica e a tecnologia do produto, agilidade e sucesso estarão garantidos. 

10. Simplicidade _ a arte de aumentar a lista de trabalho a não ser realizado _ é essencial. 
Eliminar o que não agrega valor ao negócio, eliminar complexidades desnecessárias, e por aí vai. É um trabalho que exige maturidade do time e do cliente, para conseguir ter o discernimento do que é e do que não é importante para o produto. 

11. As melhores arquiteturas, requisitos e designs vem de times auto-organizáveis. 
Com certeza! Times que já conseguem se organizar sem a necessidade de um líder que delegue tarefas, precisam (além de maturidade) um conhecimento de negócio muito grande. Todos precisam estar à par do projeto como um todo, para que possam tomar decisões e sugerir alternativas. 

12. Entre intervalos regulares o time deve refletir sobre como se tornar mais efetivo, e então sintonizar e ajustar seu comportamento de acordo. 
A questão de revisar as atividades praticadas, o que deu certo, o que não deu, o que pode ser melhorado, o que deve ser eliminado, tudo isso faz parte dessa reflexão. Novamente, a questão da maturidade do time se torna essencial para o processo. 

Bom, estes foram os meus comentários sobre cada um dos doze princípios, mas são coisas que eu acredito. Fique à vontade para dar sua opinião também. =)

O Manifesto Ágil

Muito se fala sobre Metodologias Ágeis, agilidade nos processos, agilidade no desenvolvimento de software... mas mesmo dentro de equipes "ágeis" pouco se conversa sobre o Manifesto Ágil.

Acabou que as pessoas estão esquecendo da essência da agilidade, e focando em entregas rápidas (e cada vez mais rápidas), e que não valorizam de fato a ideia que move o Manifesto.

Traduzindo as palavras do Agile Manifesto:

"Estamos descobrindo melhores formas de desenvolver software fazendo e ajudando outros a fazer isso. Ao longo deste trabalho passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas;
Software funcionando mais que documentação abrangente;
Colaboração com o cliente mais que negociação contratual;
Responder à mudança mais que seguir um plano. "

O que significa, que mesmo que haja valor nos itens da direita, valorizamos ainda mais os itens da esquerda."


E acredito que é aqui, logo no começo da coisa que ela é desvirtuada. Quando o manifesto diz que preza isso "mais que" aquilo, não quer dizer que o "mais que" signifique "ao invés de".

Em diversas palestras e seminários que já fui, e também em muito material que o nobre Google me ajuda a encontrar, esse ponto de discussão sempre aparece.

Agilidade não significa deixar de documentar, abandonar os processos de desenvolvimento e pensar em prazos cada vez menores. Pelo contrário! É ter que rever o que está gerando desperdício, eliminar suas causas, e pensar em melhorar as capacidades técnicas para que se consiga entregar um produto que de fato satisfaça as necessidades do cliente, e somente então realizar entregas que tenham valor de negócio. Basicamente a ideia é colaboração, entre a equipe, entre a organização, e também com o cliente.

São somente 12 os princípios que movem o Manifesto Ágil. Simples, diretos e deveriam ser o foco até de quem não concorda em "ser ágil". No próximo post vou comentar sobre eles.

21 setembro, 2011

Processos de Desenvolvimento

Com prazos cada vez menores para as entregas de projetos, cada vez mais existe menos tempo para adequar os projetos à modelos de processos de desenvolvimento.


Muitas pessoas consideram a implantação de processos desnecessária, ou ainda uma atividade de peso morto, que só faz perder o precioso tempo para "de fato" efetuar tarefas que tragam resultados para o projeto. Mas a implantação de um processo não ajudaria em nada?

Uma vez que exista um processo pré-definido na empresa, e todos devam segui-lo, ou pelo menos seguir as fases que se adequem ao projeto em questão, isso traz segurança para a empresa, segurança aos colaboradores, organização, indicadores de performance e, o mais importante, identidade para a empresa.

Vamos avaliar cada um destes itens;

- Segurança para a empresa
Com a institucionalização de um processo na empresa, esta passa a garantir um controle maior sobre os projetos que possui, descentralizando o conhecimento da cabeça dos colaboradores e fazendo com que as informações de cada projeto estejam à disposição de todas as pessoas envolvidas nos mesmo, e principalmente, da própria empresa.

- Segurança para os colaboradores
Uma vez que exista um processo definido, tanto os colaboradores novos como os antigos, saberão exatamente as atividades que deverão executar, e terão a garantia que todos deverão fazer sua parte no projeto, evitando assim sobrecarga de tarefas, ou ainda a tal centralização de conhecimento, que é um problema há muito conhecido e que tanto preocupa colaboradores e empresas.

- Organização
A organização mais padronizada que um processo exige, faz com que se tenha fácil acesso as informações dos projetos, e também se garanta que não se está sendo exigido nada além do que foi negociado. Muitas vezes, a falta de organização nos projetos, faz com que informações importantes como detalhes do escopo sejam perdidas, ou se mantenha somente no e-mail de um colaborador, por exemplo, e a empresa acabe arcando com prejuízos desnecessários.

- Indicadores de performance
Se um processo bem definido for seguido da maneira correta, é possível extrair indicadores de suas fases, de seus projetos e de seus colaboradores, por exemplo. Com base em indicadores, é muito mais simples saber se estimativas estão sendo feitas coerentemente, se existem pessoas que trabalham superando as expectativas, se os prazos estão sendo cumpridos, e uma série de outras informações que contribuem não somente para o crescimento da empresa (que passa a ter um histórico e aprender seu ritmo) como para o colaboradores (que podem até mesmo ganhar uma promoção, se seu desempenho estiver acima do esperado, ou ainda para que estes justifiquem um pedido de aumento de salário).

- Identidade para a empresa
E o mais importante: a empresa passa a ter sua identidade carimbada na maneira de trabalhar de seus funcionários. "A empresa X trabalha desta forma enquanto a empresa Y trabalha desta outra". Quando não há um processo, cada um trabalha à sua maneira, e muitas vezes, quando uma empresa perde um funcionário, perde também boa parte de um projeto, ou ainda o projeto passa a não dar mais o resultado que dava, e a empresa nem saberá o que esperar daquele momento em diante.

Como disse no início do post, para muitas pessoas, a implantação de um processo é desnecessária (ou inconveniente). Obviamente existam as excessões mas um processo é sempre a garantia de que existirá uma qualidade mínima aceitável nos padrões de qualidade de uma empresa.

13 julho, 2011

Conhece o The IIBA?

O The IIBA (International Institute of Business Analysis) é uma instituição sem fins lucrativos, destinada à disseminação do conhecimento na área de Análise de Negócios.

É possível você se tornar um membro desta instituição pagando uma taxa anual, e nós que moramos no Brasil, ainda ganhamos um descontinho e pagamos um valor diferenciado do normal em função de o Brasil estar na lista de países "with lower Purchasing Power Parity" (Global Membership Program) .

O interessante, é que tornando-se membro do The IIBA, além de você entrar em contato com Analistas de Negócios de diversas partes do mundo e participar de várias comunidades, você tem acesso à uma biblioteca virtual com mais de 300 e-books relacionados ao assunto, incluindo a última versão do BABOK (2.0).
Legal também é que você pode obter suas certificações como Business Analyst. O The IIBA oferece duas: 
  • CCBA (para Analistas de Negócio em nível Pleno)
  • CBAP (para Analistas de Negócio em nível Sênior)
O The IIBA também tem uma chapter aqui em Porto Alegre (IIBA Porto Alegre Chapter) que está iniciando suas atividades aqui no sul, e espero que em breve tenhamos eventos por aqui.

Por hoje é só...  Até breve!

29 junho, 2011

Trabalhando com Engenharia de Software

Bom, estava faltando um post para falar sobre Engenharia de Software. =) 

Segundo a Wikipédia, "Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade."



Resumidamente, é atuar em qualquer especialidade dentro de um projeto de desenvolvimento de software (corrijam-me se discordarem). Então, uma vez que você esteja interessado em atuar como Engenheiro de Software, você deve ter em mente "o que você quer ser quando crescer", e trabalhar para melhorar suas qualificações. Eis alguns exemplos de profissões ligadas à esta área:

Desenvolvedor de Software (Programador), Analista de Sistemas, Analista de Negócios, Analista de Testes, Testador, Arquiteto de Software, DBA (Database Administrator), Gerente de Projetos, Suporte, e por ai vai. 

E ainda, dentro de cada uma destas profissões, existem diversos seguimentos a se tomar, e que cada vez mais exigem especialização, por exemplo:

Um desenvolvedor pode ser especialista em uma ou mais linguagens de programação (Java, .Net, PHP, etc), um Analista de Sistemas também pode se especializar em uma determinada linguagem, um Testador deve conhecer diversas técnicas de Testes de software, desde a manual até a automatizada, tendo domínio sobre diversas ferramentas que o auxiliem. Enfim, os caminhos são diversos, e ainda trataremos de cada um deles com mais calma no blog.

O bacana, é que se você resolver trocar de área, você não perde seu conhecimento, pelo contrário!! Tudo o que se aprende em uma determinada área de conhecimento é perfeitamente aplicável nas demais, seja teoricamente, seja auxiliando em uma resolução de problema, ou em uma identificação de bug.

Sem falar que a Engenharia de Software está em constante expansão, e ainda faltam profissionais qualificados no mercado. Ah! E não basta ser bom somente em tecnologia não... sem inglês hoje, muitas portas acabam se fechando. O mercado internacional está de olho nos profissionais do Brasil, então aproveite! #ficaadica

27 junho, 2011

O que nos motiva?

Há algum tempo assisti à este vídeo que fala "que o que de fato nos motiva é o que nos leva à ter sucesso nos empreendimentos em que trabalhamos", e percebi que esta regra é válida tanto para a vida profissional quanto para a vida pessoal. O autor Simon Sinek, escreveu um livro sobre o assunto, e não vejo a hora de começar a leitura. Assista ao vídeo e pense no assunto.

21 junho, 2011

Harry Potter e o CHA

Dia desses, estava lendo "Harry Potter e o Cálice de Fogo", e hoje, após ler este artigo (que a propósito me inspirou a ler este outro) sobre o CHA (Conhecimento, Habilidade e Atitude), percebi como o bruxinho o aplicou para executar uma tarefa no Campeonato Tribuxo.
Basicamente, a tarefa era enfrentar um dragão e conseguir capturar um ovo de ouro que estava em seu ninho, saindo vivo da batalha. Para isso, Harry contou com a ajuda de seus amigos, que lhe mostraram como ele poderia utilizar estas três características para garantir a vitória. Mas a prova era um mistério para os participantes do torneio.

Primeiramente, com a ajuda de um de seus amigos, ele descobriu que a prova seria com dragões, então pode estudar seu comportamento, e aumentar seu Conhecimento sobre o assunto, para descobrir como enfrentá-los.

"Explore seus pontos fortes", foi a segunda ajuda que ele recebeu. Seu professor o estimulou a descobrir quais eram suas Habilidades mais fortes, para que estas fossem usadas a seu favor no momento certo.

Todos possuem pontos fortes, mas nem todos sabem como utilizá-los. Foi aí que Harry teve que ter Atitude e, com o apoio de sua amiga, descobrir como unir o CHA no momento do torneio.

O resultado foi a vitória, usando magia, montado em sua vassoura, voando como se estivesse em um jogo de Quadribol, aproveitando sua excelente habilidade de pilotar, para conseguir pegar o ovo de ouro.

Diariamente, nos deparamos com situações em que temos que usar de diversas habilidades para resolver problemas, e muitas vezes esquecemos de "sair da caixa" para procurar uma solução na qual tenhamos pleno domínio. E assim como Harry, podemos precisar da ajuda de nossos amigos e colegas de trabalho para conseguir enxergar a saída.

No CHA, o C é o conhecimento que a pessoa tem sobre determinado assunto, podem ser os conhecimentos adquiridos no decorrer da nossa vida, em qualquer área, é o saber; O H é a habilidade de se produzir resultados com o conhecimento que se tem, é o saber fazer (Know-How); E o A é a atitude, a pró-atividade, o querer fazer.

O uso do CHA, parece bastante óbvio, mas é impressionante como estas três características utilizadas juntas nos fazem enxergar um conjunto de soluções muito maiores na hora de solucionar problemas, e isoladas não chegam a lugar algum.

Um primeiro passo, para desenvolver o CHA, é disseminar o que se sabe entre as pessoas que estão próximas. Imagine, em seu time de desenvolvimento, se você tem conhecimento em um determinado assunto, e não sabe como resolver um problema, mas exterioriza esta situação, provavelmente alguém próximo já poderá ter passado por uma situação parecida e poderá lhe dar dicas ou ainda lhe ensinar como resolver. 

O ambiente colaborativo estimula cada vez mais o desenvolvimento do CHA nos profissionais, afinal, ninguém nasce sabendo tudo e compartilhar informações hoje em dia está em alta.


18 junho, 2011

O que é Business Analysis?

Hoje em dia muito se fala sobre Análise de Negócios (Business Analysis) e as empresas cada vez mais buscam Analistas de Negócios, pois antes de promover qualquer tipo de produto no mercado, é preciso conhecimento sobre o mesmo. Você precisa conhecer o que está vendendo, o motivo que o leva a vender e como irá realizar a venda, para que seu produto não seja um fracasso.


Achei muito boa a definição sobre as atividades do Analista de Negócios apresentada na Wikipédia:
Analista de Negócios busca as melhores oportunidades de negócio, analisa tendências, cria novos produtos, recria produtos existentes, está sempre preocupado em encontrar novos caminhos para a empresa. Ele está em permanente contato com o cliente e os donos do negócio.
O analista de negócios (...), vem de maneira a complementar o analista de processos e o analista de sistemas. Os três tipos de analistas diferentes não devem ser confundidos entre si, não são mutuamente exclusivos e eles podem se complementar naquilo que têm de melhor. Fundamentalmente, esta função está atrelada ao conhecimento e facilidade em lidar com negócios, assim como descrita acima, mas muito focada nos recursos de TI e de Sistemas (em toda sua extensão) para poder prover soluções exequíveis para um atingir um determinado objetivo.”
Basicamente, o Analista de Negócios é a pessoa que irá identificar e propor soluções para as necessidades de negócio de um determinado seguimento. Então, se sua empresa precisa de um novo software, o analista de negócios irá realizar entrevistas, para entender o que você faz, como você faz o seu trabalho, e como  você espera que o software possa lhe ajudar, para que juntos, o Analista e o Cliente, cheguem a um acordo sobre a melhor solução possível.

Mas não é uma tarefa exclusiva do Analista de Negócios conhecer e identificar estas melhorias.
Se você trabalha em um time de desenvolvimento de software, e aqui vamos imaginar um Analista de Negócios, um Analista de Sistemas, um Desenvolvedor e um Analista de Testes, quem você acha de deve reter o conhecimento de negócio? A resposta é simples; o time todo!
Ok, nem sempre é possível levar o time completo para uma entrevista, e muitas vezes não é necessário que isso ocorra. Mas é imprescindível que o conhecimento de negócio seja disseminado de forma clara ao time inteiro, seja por meio de reuniões, lista de regras, ou qualquer outra forma que se julgue adequada para que todos estejam alinhados em relação ao assunto, e o desenvolvimento do projeto ocorra com sucesso.

31 maio, 2011

Getting Started!!

Bom, para este primeiro post, pensei em apresentar o principal assunto que este blog irá tratar: troca de experiências na área de Engenharia de Software. Para isso, achei que apresentar minha caminhada até aqui daria uma boa perspectiva do assunto. Então, lá vai! 

Entrei na área de TI, meio que por acaso, sendo uma auxiliar no conserto de computadores, e resolvi cursar Sistemas de Informação, achando que já sabia muita coisa sobre o assunto. Foi aí que descobri que não sabia quase nada. Bom motivo para desistir, não? NÃO!!! Um bom motivo para correr atrás de mais conhecimento. Estudei, tive dificuldades, como a maioria do pessoal que entra para essa área, pois afinal, o curso é um curso difícil e que exige empenho. Me formei em quatro anos e meio, e quando me formei já estava atuando no mercado de trabalho há mais de dois anos.

Iniciei na área de Desenvolvimento de Software como estagiária, atuando como Testadora, onde executava os cenários de testes e procurava os bugs dos sistemas. Oito meses depois, já era Analista de Testes em uma empresa multinacional, e com a carteira assinada \o/. Passei então a não só testar os softwares, mas criar os cenários de teste, buscando problemas, imaginando mil formas de encontrar os tais bugs, para que quando o produto final chegasse ao cliente, chegasse o mais próximo da perfeição possível. Esta é a tarefa que o "pessoal do teste" se empenha tanto em fazer.

Alguns meses depois, tive a oportunidade de iniciar um novo caminho na minha carreira, como Analista de Sistemas. Um desafio e tanto!! É muito interessante como as atividades de Teste e Análise de Sistemas são tão próximas, e ao mesmo tempo tão distantes. Nas duas, é preciso pensar em todas as possibilidades possíveis de o software atender as expectativas do cliente. Porém, na Análise de Sistemas, além de pensar nos problemas, deve-se pensar em soluções. "Como é que que eu vou conseguir transformar a necessidade do cliente em um programa de computador?". Bom, isso o Desenvolvedor vai fazer... mas para que ele faça com maestria sua atividade, ele precisa que alguém identifique, especifique e explique o que de fato deve ser feito.

Então, descobri que um bom Analista de Sistemas, deve ser um ótimo Analista de Negócios. É preciso conhecer o dia-a-dia do seu cliente, trocar ideias, saber "pescar" o que ele precisa, e se ele realmente precisa do que está pedindo. Sim, pois um Analista não é só um "garçon" que anota pedidos, ele tem que aprender a conhecer o negócio, para que consiga imaginar a melhor solução, e isso tudo precisa ser muito rápido.

Trabalhar na área de Desenvolvimento de Software, é um desafio constante! Você PRECISA saber trabalhar em um time, entender as diferenças entre as pessoas, saber muito bem o que precisa ser feito, e ter autonomia para concordar ou não com as atividades, lembrando sempre que o objetivo do time, é o mesmo: o gol. Aqui, o gol (no sentido futebolístico mesmo, hein?) é a entrega do projeto com sucesso!! E isso exige que cada um faça sua parte, e ajude o seu time como for necessário. Comprometimento é fundamental, e não se fala mais nisso. 

Às vezes é estressante, às vezes é muito engraçado, às vezes a gente erra, às vezes a gente ajuda a consertar, às vezes a gente briga, às vezes a gente comemora junto. Mas sempre, o objetivo é o gol.

E isso é o que hoje me motiva. Buscar mais e mais gols. E o que te motiva??

Então, sejam bem vindos e espero que possamos compartilhar muito conhecimento e experiências por aqui.

Até mais! 
=)