JEFFMOR Blog's

A maioria das crianças sonham em ser médico, piloto de avião, bombeiro, policial, e etc, são várias as opções, mas sinceramente nunca vi nenhuma criança dizendo que queria ser um hacker, nerd, computeiro, micreiro ou o nome que estão querendo dar a tudo isso, ANALISTA! Eu não fui diferente desse pensamento, eu queria ser um Médico, mas quis o destino que eu me envolvesse com TI.

Eu sempre me perguntei: O que é ser um “Analista”(meio fora de moda esse nome)?

Eu sinceramente não tenho uma resposta concreta para isso. As pessoas geralmente escolhem essa profissão por acharem que isso “tem futuro” ou por simplesmente notarem que os analistas são quase onipresentes. Fui convidado para apresentar uma palestra na UNIDERP e intitulei “Um dia eu vou ser um analista”, logo abaixo tem a palestra e os tópicos.

• Sonho (pq escolhi essa profissão?)
• O que não é?
• O que é?
• Como trabalha?
• Mercado em CG, MS, Brasil, Planeta e Universo
• O CAOS do desenvolvimento
• Posso pensar em aposentadoria?
• Dicas para sobreviver nessa perigosa floresta

O Fábio Akita colocou o vídeo abaixo com o conselho  do “doidão” Uncle Bob  para os desenvolvedores brasileiros.

Alguns trechos que me chamaram a atenção:

• “… o que precisam lembrar é que não é bom o suficiente apenas fazer o código funcionar…”
• “… Seu código precisar ser algo que você ame trabalhar”

Um outros post bem legal que li esses dias foi o Diego Plentz onde ele viaja sobre uma tal dieta do programador.

Fonte: http://www.akitaonrails.com/2009/05/07/railsconf-09-uncle-bob-martin

Algum tempo atrás li este artigo no meio-bit, e em alguns pontos ele “apela” um pouco, mas quem já trabalhou em um projeto que muda muito o escopo vai se identificar.

Uma das características principais para se alcançar a maturidade em uma disciplina de engenharia é o uso de soluções já existentes no desenvolvimento de novos sistemas. Seguindo essa idéia de não reinventarmos a roda, enfatiza-se a importância do reuso centrado na arquitetura, objetivando o desenvolvimento de sistemas de software. Dentro disso, a arquitetura de software serve como uma organização, permitindo seu entendimento em termos de componentes, interrelacionamentos e propriedades.

Últimamente fala-se demais em “sucesso de projetos”, para ilustrar um pouco melhor isso imagimenos ou lembremos a seguinte situação:

… indo trabalhar notamos um outdoor enorme(referente a projetos) do lado daquele outro com uma bela morena, de olhos azuis, calça apertada… , no início até olhamos para a morena, mas depois aquele outro outdoor fica martelando no inconsciente de nossas cabecinhas: “Será que esse meu atual projeto vai ter sucesso, tá meio obscuro aquilo! nao sei… pq de acordo com PMI, é assim q tinha q ser bla, bla, bla… mas pensando melhor seria assim bla, bla, bla “. Passa-se alguns minutos e já esquecemos e finalmente chegamos ao trabalho, começamos a ver aqueles e-mails de cursos e palestras ao melhor estilo: Planejamento Estratégico, Gerenciamento de Projetos com Joselito Sem Noção (formado em Administração) ou aquele outro SEJA REVENDEDOR HERBALIFE e ganhe muito, mas muito mesmo!

E o que é que nós fazemos? Se a resposta for: Joguei tudo fora!

Você está de parabéns! É isso mesmo

Andam pregando mentiras por todos os cantos, com se bastasse apenas um planejamento estratégico e não precisasse mais de habilidade para entender o mercado. Quando falo em SUCESSO DE PROJETO, estou me referindo a entrega no prazo, dentro do orçamento e com qualidade. Agora quando me refiro a SUCESSO DE PRODUTO associo isso a dois pontos muito importantes que são os requisitos fucionais e não-funcionais. Muitas das vezes notamos gerentes não se importando se aquele produto vai atender ou não ao cliente, ou seja não se importam com os requisitos. Isso jamais poderia acontecer, o negócio é o carro chefe de todo sistema, é evidente que se o desenvolvimento do projeto for uma completa negação, o negócio também será.

Então ao meu ver para se obter sucesso em um projeto, precisamos atender as metas (lógico né!), mas quais seriam elas?

1. Se atendeu ao negócio (funcionais e não-funcionais) – Quantos aos requisitos funcionais, parece até bobo, mas nota-se no mercados vários sistemas desenvolvidos que nao tem nada haver com o negócio. E o atendimento aos requisitos não-funcionais, é cada vez pior, parece até que as empresas contratam um monte de vendedores (não é Analista de Negócio/Requisitos, devia ser mas não é!) sem conhecimento nenhum e que são excelentes no “gogó”.
2. Executou o escopo como previsto – Escopo geralmente muda um pouco, mas se mudar demais, está errado.
3. Cliente satisfeito.
4. Atendeu a expectativa dos principais stakeholders.
5. Equipe com moral alta.