O Motorista de Projeto

Cauda grossa, Taleb e risco do Knight. Como o jeito temerário de dirigir no Brasil ilustra a dificuldade da estimativa do custo dos projetos de desenvolvimento de software.

No inicio de cada projeto, existe um risco sobre o custo total do mesmo. Mas para poder razoavelmente definir o preço do projeto, deve-se estimar esse risco.

Primeira dificuldade: poderia falar aqui não de risco mas sim de "incerteza knightiana", no sentido proposto pelo Frank Knight quase um seculo atrás[1]. O Knight distingue o risco, que pode ser observado e medido, da incerteza, que nem pode ser medida de jeito confiavel. E claramente, no incio de um projeto nos encontramos no segundo caso. Dados estatísticos relevantes não existem para estimar as probabilidades, já porque cada projeto é diferente dos precedentes: as tecnologias são diferentes, as equipes, o contexto, os requisitos. Nesse contexto, qualquer previsão é um tiro no escuro. Desde sempre, projetos estoram os orçamentos... e é normal. Está certo que estimativas baseadas na experiência são possiveis, mas esse fica um dos exercicios mais difíceis da profissão.

Bem, não temos um risco mas sim uma incerteza. Qualquer que seja o termo, precisamos avalia-lo de alguma forma para definir o valor do projeto. Ou seja, precisamos assumir uma distribução de probabilidade para a variavel aleatória "custo do projeto". Infelizmente, somos ruins nisso. Temos uma forte tendência a usar a distribuição normal, graças à ajuda fácil do teorema do limite central. Imaginamos naturalmente os valores repartidas simetricamente de parte e de outra de um custo média.

E é aqui que a temeridade do motorista brasileiro entra em jogo como ilustração do nosso problema: a distribução de Taleb[2]. Numa distribuição de Taleb, tem uma probabilidade alta de valores positivos pequenos, mas uma probabilidade pequena de perda muito grande. O motorista que costuma correr vai ganhar alguns minutos na maioria des vezes. Mas ele poderia um dia se matar.

Essa distribuição mostra vários elementos:
* possibilidades de perdas extremas: mesmo que, em geral, os projetos sejam lucrativos, um só projeto fora de controle pode por a empresa toda em risco. É ainda mais verdadeiro para empresas pequenas (como a Sofshore). A literatura se refere a isso com os termos de "cauda grossa" (fat tail), significando que os valores da variavel são mais longe da média do que na distribuição normal;
* eventos não observados: como eventos extremos são raros, é possível que não foram encontrados ainda - e logo, não incluidos nas previsões
* assimetria: a distribuição de Taleb é uma combinação de cauda grossa com uma assimetria: os valores de um lado da media são mais distantes dela.

Tudo isso se aplica perfeitamente aos projetos de desenvolvimento. Já mencionei a incerteza inicial. Claramente, a distribuição de probabilidade do custo é assimétrica, com uma forma ilustrada aqui por uma distribuição Gamma (apenas uma ilustração). Com uma cauda grossa: já vi projetos estorarem de mais de 1000% o orçamento inicial. E visto os elementos acima, não é de se espantar.

Como já expliquei num post precedente, fujo do preço fixo. Agora me resta a descrever soluções alternativas para diminuir a incerteza ou compartilhar o risco. Mas isso é uma outra história que será contada outro dia ...

[1] Frank Knight, "Risk, Uncertainty, and Profit", 1921
[2] Nassim Taleb, "The Black Swan: The Impact of the Highly Improbable", 2007
[3] Wikipedia, "Taleb Distribution"

Formação: ROI negativo ?

Vindo de uma consultoria Belga, imaginava implementar no Brasil a mesma política de gestão dos recursos humanos que eu conhecia la. O principio é de uma parceria a longo prazo entre os funcionários e a empresa.

Quanto à formação, a política é baseada num principio simples: nós vendemos serviços, portanto competência. Logo, no nosso setor tecnológico em evolução constante, a formação tem uma importância crucial. A formação é boa para a empresa, mas também para o desenvolvedor. Primeiro porque mais competências levam cedo ou tarde ao crescimento profissional. E também por varios fatores que fazem o trabalho de desenvolvedor ser interessante, estimulante e desafiador (entre outros).

Na prática, esta política se traduz por varios incentivos à formação: definição de um plano, subsidiação de cursos ou certificações, tempo dedicado para a aprendizagem (como se faz na Google ou na Ferrari). Enfim, vários investimentos da empresa, que podem representar no total um custo substencial. E é esta mesma politica que implementamos na Sofshore - mesmo que de jeito ao meu ver insuficiente.

Porém, quando cheguei no Brasil, me espantei com a pequena proporção das empresas de TI que pagam as certificações. Me espantei, de modo geral, com a relutância das empresas em investir diretamente em formação.

Talvez eu tenha conseguido uma resposta a este aparente mistério. Um detalhe cultural brasileiro atropela a politica descrita acima. Na minha experiência no Brasil, os desenvolvedores juniores e plenos ficam em torno de 1,5 ano numa mesma empresa. Contando que o tempo para um desenvolvedor aprender e integrar completamente uma tecnologia é de um ano, o ROI da formação intensiva é difícilmente positivo.

Sendo assim, a estratégia mais lógica é de recrutar um desenvolvedor já formado (em geral, de outra empresa). Fenômeno acentuado pela relativa importância do fator financeiro nas preferências dos empregados.

Do ponto de vista macro-economico, vejo nisso um "desincentivo" muito forte à capacitação de novos desenvolvedores - contribuindo para a falta de mão da obra qualificada.

Scrup

Process, process... the holy grail of software development. I would like to share here another experience we made at Sofshore: adopt the best of two worlds, IBM's Unified Process (RUP) and Scrum. Pretty contradictory at first sight - i even read somewhere that the RUP violates various agile principles.

Scrum

I am personally an agile enthusiast (even if the definition of "being agile" does not have a common acception). Scrum is great because it brings in itself all the agile principles (of course), and because of its focus on productivity and project management. On the other hand, Scrum falls short on many aspects, requirements management for example.

RUP

On its turn, RUP has three interesting characteristics.

First, it is a framework more than a process: it is highly customizable, picking only what is needed. At this respect RUP is far from being a "bureaucratic heavywheight" process.

Second, a focus on preliminary and progressive architecture definition (the elaboration phase). This is interesting because software engineering is research process: it makes sens to work first on the most critical technical issues.

Third, a structure that is iterative in the small but sequencial in the large (the phases). This is important because most projects follow a life cycle that is sequencial, from the expression of a need until the deployment. In this, RUP fits well the workflow used at the business side.

Scrup

So, our processes integration has the following noticeable characteristics:

Phases
- We use the RUP phases, in which we integrate one or more Scrum's sprints (sprints are used as RUP iterations).
- For most of the development, we function the scrum way, using sprint planning, daily scrum meeting and retrospective.

- We use the RUP artifacts for requirements and project managements: Use Cases and Supplementary Specifications, Software Architecture Document, Project Plan, etc. Always taking care not to fall in heavy bureaucracy (having a plan does not mean it should be 200 pages long).
- We also use the Scrum artifacts: the Product Backlog (composed by a prioritized list of use cases), which is actually the most important part of the project plan; the iteration backlog and of course the burndown chart;
- We use Use case instead of User Stories

- About velocity: we use it, its value is of course roughly known during the elaboration but its value should be reasonably known by the end of this phase. At least enough to have a reliable project plan for the construction phase.
- Using a project plan does not mean that this project plan is immutable - this would effectively violate the agile basis. The project plan is adapted when necessary - as the product owner makes decision during the project.
- We also used short iterations (2 weeks), but this is not very important here - we might have used longer ones.

Scranything

As mentionad above, the RUP sequential structure fits well the IT administrative process. Wanting it or not, companies need realistic plans on the mid-term in order to allocate resources and follow results.

Actually, many similar sequential corporate processes exist, always following the steps of demand, acceptation, construction and delivery. Hence, Scrum can be integrated with almost any other linear administrative and validation process. We already did this twice.

Is velocity agile ?

Too much time since my last post... too much to do during the last weeks. Between other we started consulting services in Adobe Flex and we created a Flex user group in Florianópolis.

At the same time, the offshore project we are working on is continuing with pretty good results. This interesting experience of agile offshore is bringing thoughts that are worth sharing here.

The Context

A Belgian start-up outsourced to us the development of part of its product. The component we are developing for the moment can be considered a mid-size project, around 36 man/month work. And we have the happiness to use an agile process, Scrum - which contributes without doubt to our good results.

After 6 two-weeks sprints, we are reaching the second half of the project.

Velocity Measurement and Causes

Following the Scrum practices, we evaluate the velocity of the team in points. I will not repeat here the theory about velocity, i will rather share some purely empirical observations.

Here is an history of the first 6 sprints:

1,2) For the first two sprints, during what would be the elaboration phase in RUP (technical and architectural investigations), the velocity has been pretty low: nothing has been delivered during the first sprint, 7 points for the second. Normal with a new team on a new project with a new technology in a new environment.

3) Then we had an iteration for which the work have been underestimated and in addition a great pressure of the client to speed up the development. The team strived to reach the sprint objectives and achieved a pretty high velocity (42). But at the expense of less testing, hence creating of a technical debt.

4) During the fourth sprint we faced tough environment problems, with a far lower velocity (23).

5,6) Heavy re-orientation of part of the team has occured during the last 2 sprints. One member has been dedicated to specifications redaction (documentation demanded by the client). One other to the resolution of the environment issues. Two developers have worked on a technical POC. And one senior developer had to be assigned part-time to an other project.

We should recognize that after 3 months development the velocity isn't accurately measured yet due to a complete instability in the work to be done and in the team structure.

The Question

This scenario is pretty common in software development. Actually this volatility is one of the main reasons behind the emergency of agile (if everything could be planned up-front, agile wouldn't have any reason to exist).

On the other hand, it is this exact volatility that impeaches an accurate use of the velocity.

In other words: the main reason for agile is also an obstacle to the principal agile metric.

Hence the question: is velocity really agile ?

Thanks to share your thoughts, comments and advices on this...

(Note I do not mean that velocity is fundamentally flawed. Even imperfect, i think velocity is worth measuring. But we shouldn't give this measure more value that it really has)

See also:
An explanatory page about velocity by Version One
jan blog, "Velocity (not so) simple value"
The Puf Principle, "Scrum: utilization vs. velocity"

Não sou cobra

Curiosamente, ainda não dediquei nenhum post à questão da confiabilidade nas relações de negócios.

Minha (ainda curta) experiência no Brasil é infelizmente contrastada. Poderia resumir dizendo que depois dos "paises do golfo" temos o "país do golpe". Como se fala por aqui: é cobra engolindo cobra. Tem muita gente que é pronta a pisar no pescoço dos outros pelo benefício próprio.

Apenas como exemplo, já vi um grupo de desenvolvedores terceirizados montarem sua própria empresa e tentarem prestar serviços diretamente para o cliente final. E eu não ficaria muito espantado de ver histórias semelhantes acontecerem de novo.

Esta situação tem um custo considerável. Como para qualquer risco, a proteção gera um custo. Precisa avaliar quais são as hipoteses, quais são as probabilidades de ocorrência e quais são os danos que estas ocorrências poderiam causar. Precisa ainda implementar estratégias de proteção. Sem nem falar do custo de ser vítima de uma desonestidade qualquer.

Além disso, fica dificil para quem não é safado prever de onde virá a próxima pancada. E assim, difícil montar parcerias e colaborações saudaveis.

A Confraria Empresarial

A Confraria Empresarial nasceu deste ambiente, no objetivo de criar uma rede de empresas ou pessoas honestas e confiáveis.

A idéia é simples: a entrada e a permanência de membros da confraria é submetido a uma condição: uma ética sem manchas. Isso, garantido pelo "comitê de ética" da confraria que tem o poder de "convidar" associados a se retirarem.

Como dito pelo site: "O principal critério a ser considerado para a aprovação de uma Empresa ou Talento, como membro da Confraria Empresarial, é que o desempenho da Empresa ou Talento deve ser fruto de sua capacidade empreendedora e criatividade, e não de ações que possam acarretar prejuízos para outros [..]"

Obviamente, a Sofshore faz parte da confraria. Pretendemos ser éticos e queremos que isso seja de notoriedade pública. Acredito, talvez de jeito ingênuo, que meu próprio interesse seja melhor servido sendo honesto.

Mas nitidamente, nem todo mundo pensa assim...

Concerto de idéias: é agora

O concerto de idéias da Softex esta acontecendo agora mesmo - e só vai ficar ativo por mais 48 horas mais ou menos.

Claro, já deixei a idéia quanto ao monitoramento da posição competitiva do Brasil no mercado internacional.

E no mais, o que apareceu de interessante ? Na verdade, as idéias que vi até agora são muito mais de evolução do que de revolução. Ela visam a resolver várias dificuldades do mercado: falta de profissionais qualificados, falta de conhecimento do inglês,

E se eu tiver que eleger a melhor idéia ? Difícil, vários critérios devem ser tomados em conta: originalidade, eficácia, simplicidade de implementação. Além disso, minha avaliação é ligada à minha própria situação. Mas vamos la.

Uma primeira, muito simples, é a seguinte: "Buscar incentivos fiscais para investimento em melhoria de qualidade em processos e produtos de software.". Bom,diz pouco a respeito dos detalhes operacionais. Porém, o alto custo de projetos de melhoria de processo é sem dúvida uma barreira para empresas pequenas.

Outra proposta interessante é a seguinte: "O próprio governo disponibiliza recursos através de inúmeros outros orgãos, entidades e fundos setoriais a exemplo do Finep, BNDES, SLTI, MCT, MDIC, CNI, ABDI, etc; porém não existe uma coordenação delegada à Softex para liderar esta internacionalização do eco-sistema de software, incluindo o software público brasileiro. A proposta é a Softex inserir este objetivo em seu planejamento estratégico, provendo o setor de um "one-stop-shop" para assuntos voltados à internacionalização."

Concerto de idéias

A Softex, que da apoio à indústria de software brasileira, esta promovendo um evento original: o "concerto de idéias".

Segundo o site: "processo interativo [..] que permitirá a interação virtual da comunidade brasileira de software e serviços de TI na busca de idéias que possam enriquecer o Planejamento Estratégico 2009/2010 sendo elaborado pela SOFTEX [.. que] permanecerá no ar por 72 horas, entre os dias 04, 05 e 06 de novembro de 2008"

Ou seja, pelo que entendo, um "brainstorming" gigante. Vou participar, e não faltarei em voltar a falar dos resultados.

As inscrições são abertas a partir de 27 de outubro.

Contra o Preço Fixo

Como já defendi num post precedente, engenharia de software é um processo de criação. O desenvolvimento do código faz parte desta criação e não é o processo de construção.

Os riscos

Por natureza, este processo de criação é incerto e comporta três tipos de riscos: risco funcional, técnico e de gerenciamento.

O risco funcional é que em geral, as funcionalidade a serem desenvolvidas não são totalmente conhecidas na hora de começar a escrever o código. Por mais detalhado que seja, um documento de especificações (ou um conjunto de documentos) não diz tudo. Software e funcionalidades são coisas muito abstratas e o usuário nunca pensa em todas as possibilidades na hora da análise. Isso se aplica também para as regras de negócio(quem pode fazer o que, dentro de quais limites, em que casos, ...). Em geral, é só usando o sistema que o usuario vai se dar conta que faltam coisas, ou que certas regras imaginadas são inaplicaveis.

O risco técnico ocorre porque um sistema de software é feito de inumeros componentes, desde o hardware em que vai rodar até os frameworks usados pela aplicação. E todos estes componentes evoluem no tempo. Plataformas mudam, sistemas operacionais mudam, etc. A consequencia disso é que, na maioria dos casos, a solução técnica que será implementada não é perfeitamente conhecida antes de começar o desenvolvimento. Bugs existem, incompatibilidades aparecem e podem causar sérios atrasos.

O risco de gerenciamento acontece porque, mesmo sabendo o que vai ser feito e como vai ser feito, a estimativa do esforço total é difícil. E o erro é no minimo proporcional à duração do projeto - quanto mais longo o projeto, maior o erro. Pior ainda: existe uma forte tendência para a subestimação do esforço. É natural e vi isso em quase todos os projetos dos quais participei.

Caricaturando: no inicio do desenvolvimento, não sabemos (exatamente) qual vai ser o esforço necessário para desenvolver não sabemos o que.


O ponto de vista do cliente

O cliente, por sua parte, quer saber e é perfeitamente legítimo QUANDO o sistema estará funcionando e QUANTO ele vai custar. Pra ele, o importante é o objetivo economico. Pouco importa a técnica.

Para isso, é comum fechar contratos "com preço fixo" que determinam exatamente o que vai ser desenvolvido (na base de uma especificação), até quando e a que preço. Isso significa que o cliente transfere os riscos do projeto para o desenvolvedor. O desenvolvedor, por sua vez, vai se cobrir contra os riscos incluindo um prêmio no preço.


Consequências

No papel preço fixo da segurança. Só no papel.

Primeiro porque o fornecedor não é uma seguradora. O contrato com preço fixo pode ser decomposto em dois contratos. O primeiro para o desenvolvimento do sistema. O segundo é um contrato de seguro, o fornecedor assumindo o risco do projeto em troca do pagamento de um prémio incluso no preço total. Mas software houses não têm competência nem porte para avaliar e mutualisar os riscos. No melhor dos casos incluem um premio de risco muito alto (de 50% a 100%), no pior dos casos quebram se tiverem que indenizar o cliente se o risco se produzir.

Segundo porque o risco de não ter o sistema funcionando (ou, até pior, funcionando imperfeitamente) vai muito além do custo do desenvolvimento: é o custo operacional e comercial. Um caso extraordinário disso é a Ariane 5 que explodiu por causa de um bug (custo: varios milhões de dólares). O "seguro" contratado não cobre (ou muito parcialmente) este risco.

A terceira razão é que o preço fixo é propicio a conflitos para determinar se os objetivos do projeto (de acordo com as especificações) foram atingidos ou não. O fornecedor tem interesse em ter as especificações as mais exatas e completas possíveis (minimizando o risco "funcional"). Por sua vez, o cliente vai ter interesse em deixar as especificações imprecisas para ter mais liberdade de interpretação. E acaba necessariamente em tensões se não conflitos para definir quem vai suportar o custo das correções dos bugs.

Enfim, o respeito das especificações (que são a base do preço fixo) não quer dizer respeito da necessidade funcional real. Como dito acima, a especificação como imaginada no inicio pode ser incorreta - e acontece bastante.


Conclusão

Por todas estas razões sou convencido de que preço fixo da apenas uma ilusão de segurança para o cliente. Na hora de assinar o contrato, é mais confortavel. Os problemas aparecem na hora da entrega do sistema.

Na Sofshore propomos uma alternativa da qual falarei no meu próximo post.

As joias do recrutamento

Já vi muitas coisas engraçadas - e trágicas - no decorrer do recrutamento da nossa equipe.

Se dão muitos conselhos na net sobre como se dar bem num processo seletivo. Mas o que se acha pouco na net são conselhos sobre como ter certeza absoluta que você não será contratado. Gostaria de preencher este vazio com dois conselhos vindos de fatos reais:


Diz que prefere tirar férias do que trabalhar

Um candidato saiu do processo seletivo para um cargo numa tecnologia promissora e começando com um treinamento intensivo de três meses pago pela empresa.

"Infelizmente não vou prosseguir no processo seletivo desta oportunidade. Atualmente estou em período de aquisição de férias."

Devo dizer, este jeito é legal. Educado, tranquilo, fim para sempre da sua carreira na empresa em duas linhas e sem atritos.


Insulte o recrutador

O segundo jeito pode ser usado quando sua candidatura já foi recusada pela empresa. É muito mais agressivo e, por isso, mais radical do que o primeiro. Garante uma vaga de honra na lista negra dos candidatos com quais toda forma de colaboração esta fora de questão.

Aconteceu assim com um candidato cuja qualificação era superior ao que procurávamos.
Enviamos o email:

"Recebemos seu curriculo e agradecemos seu interesse. Infelizmente suas competências não se enquadram nas atuais necessidades da empresa.
Caso haja uma nova vaga com o seu perfil não hesitaremos a entrar em contato.
Desejamos sucesso em seu futuro profissional, [..]"

Resposta do candidato:

"Eu trabalho na [..], uma das lideres de mercado mundial de TI [..].
Meu cargo aqui é Arquiteto de Sistemas Senior.
Tenho 15 anos de experiência em TI.
9 Anos com JAVA/J2EE
[..]
Realmente minhas competências, meu perfil e meu valor hora [..] são muito superiores as atuais necessidades de sua empresa."

E como se esta afirmção não bastasse, num email posterior ainda insistiu:

"E o seu email, me fez ver que que eu errei muito em enviar meu CV para uma "emprezinha de pequeno porte do interior do país"....
Foi um erro, favor desconsiderar o email e envio do CV.
Vocês ai do interior do país não conseguem pagar nem metade do meu salario..."

Ou como demonstrar em pouco tempo falta de profissionalismo, ego inchado, pouca educação, agressividade e outros. Radical. Pra este tipo, não pagamos nem um centavo.

Engenharia ? Pode até ser

A minha palestra sobre uma desmistificação da engenharia de software foi feita ontem. Não me sai tão bem como eu gostaria, mas não tão mal como eu temia.

Gostaria agora de consagrar uns posts aos assuntos tratados. Em primeiro lugar a questão do termo "engenharia" de software, que foi no final das contas o tema central da palestra.

Na profissão, esse assunto não é novo, longe disso. Um debate existe há décadas sobre o fato do desenvolvimento ser "arte" ou "engenharia". Paralelamente, existe muito debate sobre as qualificações necessárias para poder atuar como "engenheiro" de software. Há quem defende que desenvolvimento de software é criação, outros que dizem que uma formação en ciência da computação é imprescindível e que o problema hoje na profissão é a mediocridade (falta de formação formal).

Os slides da presentação estão disponíveis online

Meu ponto é um pouco diferente. Esta discussão de especialistas é bastante interessante e na verdade fundamental para a profissão. Mas quando quero desmistificar o termo "engenharia" de software, não é para dizer que desenvolvimento não é engenharia. Meu objetivo é de desmentir certas idéias ligadas a este termo e que levam a estratégias erradas.

Principalmente, a idéia segundo a qual a construção do software se faz na programação, na base de uma planta baixa que são os diagramas UML feitos durante a análise e o desenho. Chama arte, chama engenharia, chama como quiser. O código É a planta baixa.

Portanto, o processo de desenvolvimento não deve ser considerado um processo industrializado de construção, mas sim um processo de criação do plano que servirá à construção. Com toda a incerteza ligada a esta descoberta de um espaço desconhecido.

E o processo de desenvolvimento (que define quem faz o que e quando) deve gerenciar esta incerteza da melhor forma. E o melhor jeito que temos hoje é usar um processo iterativo e adaptativo, que vai permitir acompanhar o trabalho de perto e responder rapidamente às dificuldades encontradas no caminho.

Uma opinião defende que, se este processo de criação é tão incerto, é por falta de maturidade dos nossos conhecimentos na área (o que chamam de "body of knowledge"). A engenharia de software seria hoje na mesma situação do que era a da engenharia elétrica uns dois seculos atrás. Seria bom se a ciência da computação pudesse trazer mais métodos formais de verificação da correção (correctness) de um sistema.

De novo, a questão é interessante para o profissional mas este não é o problema do cliente. No estado atual dos nossos conhecimentos as idéias que denfendi na palestra são as que melhor permitem atingir o nosso objetivo: traduzir uma necessidade funcional em software.


Referências

Jim Waldo, "Software Engineering and the Art of Design"
http://www.artima.com/weblogs/viewpost.jsp?thread=7600
(os comentários são particularmente interessantes)

Steve McConnell, "Software Engineering is not Computer Science"
http://www.stevemcconnell.com/psd/04-senotcs.htm

Jack W. Reeves, "What is Software Design"
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Richard P. Gabriel, "The Road not Taken"
http://dreamsongs.com/NewFiles/RoadNotTaken.pdf

Cees de Groot, "Art, Science, Engineering, Craft - Approaches to Building Software"
http://www.cdegroot.com/articles/2000-art-science-engineering-craft/