Métodos ágeis e a cobrança de software no Brasil

Desenvolvimento de software é engraçado, é diferente em vários aspectos. Vejo alguma adoção de métodos ágeis no Brasil porém menos do que esperava. Por que isso? Vários fatores influenciam..

Uma das coisas que tenho pensado é sobre a eficiência x lucratividade em software. Penso que se sou um bom desenvolvedor e produzo algo rápido isso gera lucro, será que isso é verdade?

Primeiramente discuto o quanto se deve cobrar para se desenvolver um software? Isso depende da complexidade do software, isto é, quanto tempo se demora para fazê-lo. Muitas empresas aqui cobram por hora de serviço, isto é, quanto mais horas mais lucro, porém quanto mais horas gastas menor foi a eficiência da equipe. Menor eficiência = Maior lucro? Eu acredito que em muitos casos aqui no Brasil isto ocorre de verdade.

Como ninguém sabe o que o software vai se transformar antes dele ser desenvolvido, normalmente se negocia um valor de horas com o cliente e após o software ser desenvolvido (ou durante), o depto. comercial dá um jeito do cliente pagar um maior número de horas com um monte de justificativas como "Isto não estava especificado" ou "Isto não era esperado", etc. Se você estiver usando abordagens aceitas no mercado como o PERT-CPM (usado no MS Project) e possui aquela sensação "enganosa" de controle, é ainda mais fácil justificar que o projeto não foi bem.

Isto é, se a empresa estivesse produzido em um menor tempo e de forma transparente seria mais difícil cobrar uma maior quantidade de horas, portanto não lucraria tanto...

Ainda acredito que é possível cobrar a mesma coisa (ou um pouco a menos) do cliente e produzir proporcionalmente em um tempo menor com métodos ágeis e então aumentar o lucro, porém é difícil provar isto.

Comentem!

Métodos ágeis e o cliente de software

Nossa, faz tempo que não posto aqui né. Bem, estive lendo algumas coisas a respeito de metodos ágeis que me fizeram refletir e gerar pensamentos interessantes para postar, como um certo dia estava pensando a respeito do mercado de software e métodos ágeis.

Metodologias como Extreme Programming existem a mais de 10 anos, essa forma de pensamento está visível no mercado atualmente. Como está o mercado brasileiro visto ao pensamento ágil de desenvolvimento software? Como se portam as consultorias de TI e o desenvolvimento de software no nosso país?

Vejo que ainda é muito baixa a penetração do desenvolvimento ágil no mercado de TI brasileiro, falo do nacional porque não conheço os impactos em nível internacional. O pior não é na minha opinião nem o tempo demorado, é a posição das pessoas perante a essa linha de pensamento. Vejo a maioria das pessoas (inclusive eu mesmo um dia) contra o pensamento ágil. Por que isso? Por que existe essa resistência?

Bem, acredito que existem algumas razões, mas vou citar a que vejo como mais forte, uma certa incompatibilidade com as espectativas do cliente. Métodos ágeis costumam se basear em iterações adaptativas, partem do princípio que o usuário não sabe realmente o que ele precisa e o desenvolvedor não consegue realmente identificar isso no começo. Acredito nisso como verdade pois além de estudos como o CHAOS Report, minha experiência também mostra isso. Sem identificar exatamente o que deve ser feito como fazer um orçamento do desenvolvimento do sistema?

Alguns autores propõe um contrato de escopo negociável, onde o cliente paga por pequenas partes do software enquanto ele vai sendo desenvolvido.

Algumas pessoas ainda não identificaram que isso é um grande impeditivo. O cliente não quer um software porque ele acha legal, ele quer um software porque quer resolver um problema dele. Imagina você levar seu carro pro conserto e o mecânico te responde assim: "Bem, eu vejo alguns problemas aqui no seu carro, não sei direito quanto vai ficar, vou consertando ai a gente vê quanto vai ficando". Você não aceita essa resposta né? Porque seu cliente de software deveria aceitar?

Ai você me pergunta, os métodos tradicionais de desenvolvimento de software conseguem fazer uma estimativa razoável? Não! Porém eles dão a ilusão de dar, todo mundo acredita nessas estimativas (o gerente, a equipe, o cliente) e essa ilusão acaba confortando essa situação até o projeto quebrar e precisar de mais investimento. Nesses casos o cliente costuma aceitar em investir mais, visto que muito trabalho já foi feito e seria "desperdício" não continuar com o projeto.

Precisamos encontrar um jeito de reduzir o conflito que existe no acordo de cobrança para algo mais agradável ao cliente sem que isso impacte tanto no desenvolvimento de software.

Pra mim esse é o maior desafio de metodologias ágeis no mercado.

Rotatividade no mercado de TI - Parte 2

Bem, vou continuar meu pensamento sobre a rotatividade no mercado de TI, se você não leu meu post abaixo, sugiro que leia antes de ler este.

Como estava comentando, na visão de uma determinada empresa, ela possui dois tipos de programadores, aqueles que estão a um tempo com ela e aqueles que estão a pouco tempo e possuem alta rotatividade. Também comentei sobre a importância que conhecimento tem para a tarefa de desenvolvimento de software e os tipos diferentes de conhecimento geralmente encontrado nestes dois perfis.

Ando pensando em melhores formas de integrar estes dois perfis, visto a importânica do conhecimento para o desenvolvimento de software os diferentes tipos de conhecimento que estes perfis tem,um programador veterano possui conhecimento de negócio, enquanto o programador novato conhecimento técnico diferente do utilizado na equipe atual (visto que veio de outras experiências de trabalho que desenvolvia de forma diferente).

Vejo alguns pontos na vinda de um programador novato à equipe de desenvolvimento.

1. Por mais competente que o programador seja, tecnicamente falando, ele não terá condições de gerar valor ao usuário rapidamente, visto que o desenvolvimento de funcionalidades valiosas dependem de conhecimento de negócio do programador;
   
2. Este programador possui um ponto de vista técnico diferente do utilizado na equipe de desenvolvimento, e que pontos de vista diferentes são muito valiosos para a arquitetura do sistema, pois trazem reflexão e aprimoramento contínuo desta.
3. Programadores veteranos possuem como rotina gerar valor para este sistema, e as vezes não estão interessados em ensinar todos os detalhes do sistema para um programador novo, afinal, isto é bem chato mesmo.

Tendo estas observações como base, acredito que pode ser criada uma política de integração, onde a equipe se compromete em formar um programador novato para que esta possa agregar valor ao sistema o mais rápido possivel.

Eu vejo uma política de integração de novos programadores, se baseando em um ambiente saudável de desenvolvimento, como algo assim:

1. Um programador novato não faz nada sozinho, apenas em par (isto permite que o programador veterano continue a gerar valor enquanto o programador novato aprende na prática);
2. Um programador novato troca de par constantemente (isso evita que um programador veterano fique de saco cheio de ter que ensinar tudo para o novato, além de fazer com que o novato aprenda muito mais rápido, visto que opiniões distintas geram uma visão geral muito melhor) - Para que isso realmente ocorra, não pode entrar muita gente junta na equipe comparado com o número de veteranos, nunca passando da ordem de 1 programador novato para 3 ou 4 programadores veteranos;
   
3. O programador novato DEVE estar nas reuniões de arquitetura, pois seu ponto de vista técnico é diferente do consenso da equipe, e este pode enriquecer a arquitetura do sistema.

Interessante.. (pelo menos pra mim), não acho que o mercado enxerga a importância da integração de novos programadores à equipe, mas ainda acredito que este pode ser um ponto estudado futuramente.

Flw,
Renan

Rotatividade no mercado de TI

Obviamente vocês já perceberam que o mercado de TI está totalmente promíscuo. Os projetos de TI estão crescendo.. a demanda aumentando e a quantidade de profissionais qualificados para isto não está atendendo estas necessidades.

Como que uma empresa de TI deve se posicionar quanto a esta situação? O que ela influencia nos negócios, na contratação e etc?

Em primeiro lugar.. acredito que o desenvolvimento de software é uma área baseada em conhecimento, por isso também somos atrelados aos "trabalhadores do conhecimento". Por isto, conhecimento com certeza importa, e não apenas conhecimento técnico, mas principalmente conhecimento de negócio. Note que o perfil de rotatividade de um programador influencia diretamente no valor do conhecimento dele na empresa.


------------------
Perfil 1 - Programador com alta rotatividade

Um programador que passou por diversas empresas em um prazo não muito longo costuma possuir melhor conhecimento técnico.
Ao encontrar com diversas situações completamente diferentes, com situações tecnológicas diferentes, um programador com alta rotatividade se vê na necessidade de trabalhar em ambientes diferentes, aumentando então a diversidade de suas experiências de programação, acrescentando rapidamente conhecimento técnico e de negócio à sua bagagem.

Porém, ao trocar de empresa o conhecimento de negócio deste profissional é em grande parte descartado, ao contrário do conhecimento técnico, que possuirá outras possibilidade de aplicá-lo em sua carreira como desenvolvedor.


Perfil 2 - Programador com baixa rotatividade

Um programador que está a muito tempo na empresa quase sempre possui um conhecimento de negócio com valor para a organização. Porém, a aplicação deste conhecimento em tecnologia algumas vezes pode ser de forma ineficiente, visto que este programador está longe de ter vivenciado as mudanças tecnológicas que ocorreram em outras empresas.

Este tipo de profissional também se mostra muito útil em momentos de aperto, como inconsistências de dados, bugs, etc, seu perfil se mostra ávido à resolução de problemas de manutenção.
----------

Acredito que o mais saudável é uma mistura entre estes dois tipos de profissionais em sua equipe, a questão que fica no ar é.. qual a melhor forma de integrá-los?

A resposta fica no próximo post.
Comentem!

Abs
Renan

Back to the basics..

Os negócios giram em torno de dinheiro, isto é fato.

Tecnologia da informação aplicada à negócios também devem gerar dinheiro. Como a informática gera dinheiro? Criando soluções viáveis de forma computacional. É isso que somos, geradores de soluções computacionais. Como você se vê? Por que você trabalha? Pelo dinheiro ou pela solução? Se você conseguir escolher somente um ou você está na profissão errada ou é um fanático por computação.

Quando você planeja aprender uma nova linguagem, faz isto para melhorar sua geração de soluções? Você realmente acredita que isso lhe fará desenvolver melhores soluções? Afinal de contas, o que é uma solução? Uma solução sempre pretende acabar com um problema. E então qual é o problema que estamos solucionando? Muitas vezes estamos tratando com sistemas que serão realmente úteis, mas as vezes (incluindo no meu caso) desenvolvemos coisas inúteis.

A computação é um meio, não deve ser o fim, não desenvolva por desenvolver, porém desenvolva para solucionar.

Obs: Post meio filosófico, rs
Abs
Renan

Linha de montagem para desenvolvimento de software

Em várias empresas, o desenvolvimento de software passa pela mão de pessoas com vários papéis.
Esse mercado de forma geral está corrompido pela administração de projetos de software baseado em processos, como o PMI e CMM, etc..
Faz sentido para uma pessoa com função administrativa, como um gerente de projetos por exemplo, a utilização de metodologias baseadas em processo, pois este formato de processo fixoo dá a ilusão de controle, visto que é bonita a idéia que uma pessoa levanta requisitos, outra pessoa projeta o sistema e outra codifica. Este gerente pensa assim porque nunca foi programador nesta situação ou porque não é programador a um tempo considerável.

Porém Schwaber, um dos cabeças do SCRUM, critica a utilização de uma metodologia definida/repetitível como o CMM, afirmando que estas metodologias se baseiam em uma realidade não caótica, que não se aplica à realidade do desenvolvimento de software.
Isso me lembra quando meu amigo Giuseppe Proment me disse que o desenvolvimento possui natureza artesanal, o que faz todo o sentido pensando na criação de uma escuntura, onde você mexe um pouco em um lugar, dá uma olhada, percebe que precisa mexer em outro lugar, etc. Isto está associado com a idéia de Schwaber, pois invalida a aplicação de linha de montagem para o desenvolvimento, o que ocorre frequentemente no mercado.
Pensando bem é meio óbvio que uma linha de montagem para software é idiotice, pois uma linha de montagem se baseia no fato que cada pessoa faz exatamente a mesma coisa para cada produto, um cara aperta o mesmo parafuso no mesmo lugar. Essa idéia é ridícula para software pois primeiramente nunca se desenvolve um software igual, sempre se desenvolve algo diferente, senão não haveria necessidade de desenvolvê-lo, e em segundo, você (e em muitas vezes nem seu usuário) não sabe o que precisa ser feito, até desenvolver e verificar se ficou bom mesmo, sempre sofrendo alterações.

Acho que este mercado ainda tem muito que mudar, me apropriarei das palavras de Kent Beck ao dizer que as pessoas poderiam estar desenvolvendo muito mais software do que está sendo desenvolvido atualmente.

Comentem!

Flw,
Renan

Por que valorizar o programador? Por que ele deve ser o foco do desenvolvimento?
Resposta: Porque é ele quem gera valor para o usuário, o resto gira em torno disso.

Tecnologia de ponta.. até que ponto?

Muitas pessoas afirmam a necessidade de desenvolver em tecnologia de ponta.. algumas metodologias também afirmam que é uma boa prática o desenvolvimento com este tipo de tecnologia. Mas até que ponto isto é verdade, até que ponto compensa?

Primeiramente, qual é a origem destas afirmações? Espera-se que uma tecnologia de ponta possua recursos suficientes para acelerar desenvolvimento, melhorar qualidade do código, ou até diminuir dependencias internas do sistema.

Porém, qual impacto da adoção de tecnologia de ponta?

Com a evolução das tecnologias, sua utilização se torna cada vez mais complexa.. é fácil observar, compare a necessidade de conhecimento de um programador que desenvolve um sistema somente com servlets e outro que programa com JSF+Hibernate+Spring+Sei lá o que.

Isso leva a outra questão, qual é o nível de conhecimento suficiente para um programador em uma nova tecnologia não fazer cagada com seu código? O ideal é que ele já tenha trabalhado com isso, para observar como "contornar" esta tecnologia em casos não triviais. Eu sempre digo para os outros: "Se você acha que alguma tecnologia é muuuuito boa.. você ainda não trabalhou de verdade com ela". Tudo tem seu mico.

Outra coisa importante a se pensar é o mercado.. Sua empresa não está sozinha no mercado de desenvolvimento, programadores vem e vão dela e seu conhecimento está baseada no que o mercado utiliza. Houve uma época que vi vários programadores dizendo a superioridade de frameworks como o Mentawai e VRaptor, sugerindo sua adoção em larga escala. Mas imagine uma empresa utilizando o Mentawai, qualquer programador que esta empresa adquirir precisará aprender estas ferramentas na própria empresa, porque raramente terá trabalhado com ela anteriormente.

As dificuldades do dia-a-dia aparecem, isto é fato, principalmente aprendendo uma nova tecnologia. Qualquer tecnologia de ponta não possui muitos programadores suficientemente maduros e disponíveis para auxiliar nas comunidades on-line de desenvolvimento. Imagine você aprendendo java sem o guj nem artigos na internet? Demoraria muito mais.


Portanto, eu penso que não é boa a adoção imediata de tecnologias de ponta, quando o mercado estiver maduro com estas tecnologias, talvez fosse uma boa idéia adotá-las.

Não estou falando que você não terá vantagens em adotar uma tecnologia de ponta, mas acho que a curto prazo as desvantagens são um pouco maiores.

Sugestão: Nunca seja o primeiro nem o último a adotar uma tecnologia.

Flw,
Renan