Planejamento e Construção

De tempos em tempos, eu acho que confundo "falta de planejamento" com "metodologia ágil"...

Por várias vezes, me peguei pensando:

"Para que planejar/explicar/escrever estas coisas no quadro, vamos é trabalhar!" (neste caso, o sinônimo de trabalhar é "programar")

"Para que criar uma arquitetura? O sistema é simples!" (seria simples, se o sistema não fosse distribuído, não tivesse que manter as informações no mainframe e que um dos requisitos não funcionais seria a performance...)

"O escopo desta história esta fechado." (na verdade, deu o maior sono na reunião de planejamento...)

"Hum... Acho que poderiamos fazer isso um pouco diferente..." (uma pequena observação nesta frase: em 90% dos casos, vá por mim: é melhor não fazer "diferente")

"Acho que o cliente vai gostar dessa modificação!" (nesta, pelo menos uns 80% dos clientes não vão gostar das modificações que você faz, principalmente por não consulta-los antes...)

"Poderiamos discutir isso mais tarde..." (no final, não discutimos nada :( )

"Para que planejar testes (unitários/regressivos/funcionais/exploratórios), eu sempre faço as coisas direito!" (essa é pura prepotência minha, afinal sou humano e como umano, herro -- pelo menos, um humano normal erra :) )

"Vamos cortar os testes para dar mais tempo de implementar" (tá, e a qualidade, ó!)

"Vou deixar esse prá lá, que este é fácil de alterar" (é, se não tivesse que alterar o pedaço em 1000 linhas de código que você copiou e colou por toda parte...)

"Vou deixar esse prá lá, que este vai tomar tempo" (acabei de perceber que frases que começam com "Vou deixar..." são bem perigosas... :P )

Preciso parar de pensar que um projeto de informática é só codificação. Ele é muito mais do que código: é um conjunto de conhecimentos e idéias (e de sonhos, talvez :) ) de várias pessoas que participam direta ou indiretamente de minha equipe.

Só uma observação ao meus "leitores":  Também não menospreze a codificação, pois esta ainda é a "realização" de tal "sonho/idéia/conhecimento". :P

Continuo errando e aprendendo...

Até mais!

A Árvore e o Balanço no Desenvolvimento de Software

Alguém já viu a imagem acima?

Pois é, faz uns 10 anos atrás que vi esta imagem e parece que a gente nunca aprende...

Quando me falam de um projeto novo, já fico pensando em customizações do sistema, em efeitos visuais (ter drag n'drop, menu rotativo, fade in, fade out, etc.) ou em tecnologias novas... Mas, que se formos pensar,  são coisas que, no final, não são prioritárias ou agregam pouco ou nenhum valor para a aplicação ou o usuário final.

Acho que, algumas vezes, precisamos focar no que é realmente necessário para o nosso cliente. Esta certo que fazer algo realmente bonito é muito legal, mas o importante, na minha singela opinião, é que a aplicação que construimos tem que ser algo mais que bonito, tem que ser algo útil para ele.

De que me adianta um sistema que faz relatórios 3D na tela, se no final o que a pessoa precisa é de uma simples listagem dos produtos mais vendidos?

"Quanto mais simples, melhor..." -- já me dizia um professor meu na faculdade.

É, errando e aprendendo... ;)

Até mais!

Analista (de Sistemas?)

Uma vez, uma pessoa (que era analista de sistemas em uma empresa), me disse:

"Um bom analista de sistemas não deve saber programar!"

Na época, achei estranho a afirmação, principalmente por que eu estava fazendo o curso de "Analise de Sistemas" para aprender programação! (falando nisso, eu acho que eu menti no outro post, dizendo que não fiz um jogo descente - bem, tenho que dizer adeus a carreira de Diretor de TI... :P)

Achei que o que ela estava falando era uma loucura (ou algo parecido), que ela estava revoltada por repetir em Estrutura de Dados pela segunda vez. (humm..., talvez este seja o real motivo, mas vamos dizer que não é...)

Mas, pensando agora, depois de me formar e de longos anos de trabalho, não é que ela pode ter um pouco de razão?

Não vou dizer que um bom analista de sistemas não deva ter conhecimento em programação, mas acho que isso não é o mais importante.

Penso que o mais importante para a (nossa) profissão é ter lógica, bom senso e, principalmente, saber quem é a sua equipe e o que você faz por ela.

Lógica, por que cabe ao analista decidir quais coisas são importantes ao seu cliente e tentar enxergar um sistema que possa ser informatizado através das dificuldades que este possue.

Bom senso, para definir o que pode ou não ser aplicado no sistema, ou seja, definir um escopo factível sem coisas mirabolantes que não agregam valor e nem caibam no prazo.

Saber sobre sua equipe, do conhecimento que ela possue, suas dificuldades e suas "facilidades" para tomada de decisões sobre qualidade, prazo e entrega.

E, finalmente, de como você a trata (quando eu falo de equipe, eu falo das pessoas que você trabalha, incluindo seu cliente...), pois, no final das contas, você depende de todos para realizar o (que não é "seu"...) projeto (poxa, agora pensei naquela frase batida: "Se você não cuidar bem..." :P).

Acho que para estas coisas não é preciso saber "programar"... (mas, se souber, facilita muito a vida de todo mundo... :P)

Obs.: Já disse que isso expressa somente minha opinião e que nada que eu escrever neste blog é uma verdade absoluta? Bem, agora esta dito! :D

Até mais!