Do Produto ao Projeto 

Jul/12
10

√Č comum ouvirmos falar em Projetos de Software. Isto √© principalmente comum nas chamadas “f√°bricas de software”. Este tipo de empresa se presta a disponibilizar um servi√ßo de cria√ß√£o de software. O conceito √© que o cliente quer um software, mas n√£o sabe, ou n√£o tem os recursos para o criar. Ent√£o, contrata a empresa para o criar. Este tipo de software criado por encomenda √© conhecido como “Software on Demand”.Em ingl√™s “on demand” √© literalmente “sob demanda”, que traduzimos por “sob encomenda”. Outra express√£o usada √© “tailor made” , que literalmente significa “criado por um alfaiate” mas que traduzimos para “sob medida”.¬† Os dois termos s√£o diferentes: “sob encomenda”, significa que apenas quando h√° um interesse do cliente √© que acontece o projeto. “sob medida” significa, n√£o apenas que o projeto √© sob encomenda, mas que o resultado √© √ļnico e apenas v√°lido para aquele cliente.A maior parte daquilo que uma “f√°brica de software” faz √© sob medida e n√£o apenas sob encomenda.

Ao fechar o contrato com o cliente a empresa diz que fechou mais um “projeto de software”. Esta designa√ß√£o √© simultaneamente certa e errada. √Č verdade que o que est√° sendo vendido √© um projeto. Um projeto sob encomenda para a cria√ß√£o de algo. At√© aqui n√£o se distingue de um projeto para criar um m√≥vel sob encomenda, ou um vestido sob medida. √Č verdade que o resultado final do projeto – o entreg√°vel (deliverable, em ingl√™s) √© um software.¬† Mas ser√° um “produto de software” ?

Se o cliente n√£o det√©m nenhum software do mesmo tipo ou fam√≠lia e a empresa ter√° que come√ßar do zero, no final teremos uma vers√£o do software. Uma vers√£o que podermos instalar e usar e ir√° realizar opera√ß√Ķes e ter funcionalidades tal como imaginado pelo cliente.¬† Mas se o cliente j√° tem um software funcionando e ele s√≥ deseja um adendo ou incremento do software que j√° tem, ent√£o o projeto ir√° servir para aumentar as capacidades do software j√° existente.¬† Em ambos os casos o projeto ir√° criar um incremento entreg√°vel do produto de software. Quando o software ainda n√£o existe estaremos incrementando a partir do zero. Depois, estaremos incrementando a partir de uma base. O projeto contratado, portanto, √© um “projeto de incremento de software”. Mas seria isto diferente de “projeto de produto de software ?” . Sim.

O Produto de Software √© simultaneamente um conceito abstrato e de marketing (/comercializa√ß√£o).¬† O que chamamos apenas de “software” √© a realiza√ß√£o desse conceito. √Č o artefacto que realmente pode ser utilizado. Por outro lado este artefato utiliz√°vel √© comercializado ( na realidade a sua licen√ßa o √©) e como tal √© considerado um produto, no sentido de mercado. Quando falamos do pacote Office, do WordPress ou do windows falamos em “produtos de software”, mas realmente queremos dizer “artefacto de software que √© comercializado”, ou simplesmente “bem de software”.¬† “Bem” √© gen√©rico para produto ou servi√ßo que √© comercializado. O artefato de software em si mesmo √© um servi√ßo porque seu uso¬† ( consumo) n√£o o gasta. Dai ser f√°cil prover software como servi√ßo (SaaS)

O Produto de Software √© o conceito por detr√°s destes bens. O pacote office, por exemplo, j√° enfrentou diferentes modifica√ß√Ķes ao logo do tempo, tanto em funcionalidade como em apar√™ncia e facilidade de uso. S√£o mais de uma dezena de vers√Ķes, de artefatos, de bens de consumo, mas apenas um produto. O mesmo poderia ser dito do worpress , por exemplo, ou qualquer outro produto de software. Infelizmente as palavras e a forma como falamos confundem – propositalmente – o conceito de produto de software e bem de software.

Voltando √† nossa “f√°brica de software”. O nome “f√°brica” vem desde conceito de que o software √© um bem que √© constru√≠do. Em particular constru√≠do em serie. Ora, um artefato de software s√≥¬† √© constru√≠do uma vez (pelo compilador).¬† Ele pode ser copiado v√°rias vezes e distribu√≠do em diferentes m√≠dias.¬† O que n√£o ha √© uma fabrica√ß√£o em¬† s√©rie de um software, apenas distribui√ß√£o em s√©rie.A express√£o “f√°brica de software” √© t√£o errada quanto “f√°brica de casas” ou , “f√°brica de navios”, ou “f√°brica de pontes”. Embora estas coisas sejam constru√≠das, elas s√£o constru√≠das n√£o apenas sob encomenda ( on demand) mas tamb√©m sob medida. Uma ponta s√≥ existe para ligar dois pontos espec√≠ficos no mundo. N√£o existem dois navios iguais, mesmo que constru√≠dos com base no mesmo modelo. E o mesmo √© verdade para casas. Os locais onde estes artefatos s√£o constru√≠dos chama-se normalmente estaleiros ( ou canteiro de obras), n√£o f√°bricas. A diferen√ßa √© que n√£o se trata de um processo em s√©rie, e cada artefato √© √ļnico e diferente dos outros, mesmo que seguindo um mesmo modelo base. A express√£o “estaleiro de software” seria mais apropriada. Contudo, a express√£o aceite contemporaneamente √© “oficina de software”.

Do outro lado da moeda temos empresas que desenvolvem produtos de software com base do seu negócio. Os e-comerce e os sites de bancos são exemplos. Estes produtos não apenas estabelecem um canal para o negócio, eles fazem ou quebram o negócio.  Nesta categoria temos ainda aquelas empresas cujos produtos de software são o seu negócio. O uso dos bens de software produzidos são licenciados e a renda é utilizada para incrementar e evoluir o mesmo produto e/ou original novos produtos que se relacionem ao primeiro. O exemplo clássico é o, já mencionado, pacote Office da Microsoft.

O que √© ent√£o o Produto de Software ? √Č um conjunto de ideias , diretivas e rela√ß√Ķes que ajudam o utilizador em alguma tarefa, s√£o realizadas como um artefato de software e comercializadas como um bem de software. A principal caracter√≠stica de um produto √© o conjunto de funcionalidades e capacidades que j√° est√£o integradas no bem de software e nas funcionalidades e capacidades ainda a serem integradas. Os bens de software que s√£o gerados s√£o apenas incrementos – vers√Ķes – do produto. Isto √© f√°cil de notar numa nomenclatura cl√°ssica para vers√Ķes de [artefatos] de¬† software de tr√™s algarismos. Por exemplo, sabemos que a vers√£o 3.0.1 do software cont√©m mais funcionalidades ou capacidades que a vers√£o 2.9.0 e que os incrementos da vers√£o 3.0.1 para 3.0.2 aconteceram apenas para corrigir falhas ou erros e n√£o existiram altera√ß√Ķes na funcionalidade.

O incremento do software não necessariamente resulta em uma nova versão. Vários incrementos podem ser agrupados para montar uma versão; ou mais propriamente uma Publicação (em inglês, release).

O incremento do software √© uma atividade que transforma ideias, diretivas e outros conceitos abstratos em um artefato de software concreto, real, e funcional. Normalmente cada incremento √© feito por uma raz√£o (comercial, t√©cnica, ou de outro tipo) e portanto cont√©m um objetivo. Guiar um conjunto de pessoas a alcan√ßarem esse objetivo sob determinadas condi√ß√Ķes e restri√ß√Ķes √© que forma um Projeto.

Um produto de software é transformado em um bem de software através da execução continuada de projetos que transformam conceitos abstratos em artefatos de software.

No meu ultimo post falei sobre o Gerente de Produto e o Gerente de Projeto. Mas acho que o assunto não fica completo sem falar o que é um Produto, o que é um Projeto e a diferença,  e a relação, entre eles.

√Č comum as empresas focarem no aspeto ‘projeto” e esquecerem o aspeto “produto” e chegarem no fim do projeto com um artefato de software que simplesmente n√£o √© o que haviam concebido.

√Č necess√°rio entender que existe esta dualidade e que um excelente bem de software s√≥ se alcan√ßa se o produto de software for excelente e o processo de realiza√ß√£o dos incrementos for excelente. Se um falhar, tudo falha.

 

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos