Seu projeto de código aberto não é um produto! Confira o artigo de um diretor da Dell!

O artigo abaixo foi escrito por John Mark Walker, diretor de produtos da Dell EMC, ele mora nos EUA, em Boston. Em seu texto, ele explana as mais variadas situações em torno das opiniões sobre projeto e produto, eu particularmente gostei da opinião.



John diz que tem passado muito tempo explicando os prós e contras de produtos de código aberto, o que são, como ganhar dinheiro com eles, e o que eles não são. 

“Produtos são produtos, não importa a licença de código fonte que são publicados.”

Seu projeto de código aberto não é um produto! Confira o artigo de um diretor da Dell!

google_ad_client = “ca-pub-5822666425104102”; google_ad_slot = “7651670077”; google_ad_width = 728; google_ad_height = 90;

Com base em seu texto, ele compara os tramites do desenvolvimento como uma viagem, e classifica o desenvolvimento comunitário como uma viagem a céu aberto, sem limites, aonde cada caminho percorrido o fonte vai sendo abastecido de pedaço em pedaço, e as vezes é preciso por um pouco de molho especial, que em alguns casos tem marca registrada. 
E então, ele ainda questiona das limitações sobre oferecer suporte e serviço para um projeto de software, disse que seria mais simples se assim o pudesse fazer. O produto é o resultado final de um projeto, seja ele qual for, de software ou não. E cada um tem sua trajetória, e que não é ortogonal como muitos pensam.  
Existem várias razões pelas quais o projeto de software não é um produto, veja uma lista das diferenças entre os dois, e o que essas diferenças significam para os fornecedores de software e serviços, bem como usuários finais. Confira abaixo na íntegra, as informações e esclarecimentos dadas por John.

Os objetivos de um projeto são fundamentalmente diferentes de um produto

Um projeto não é um lugar para colocar muitas restrições. Seu projeto foi concebido para um ser um hub de inovação, e você nunca saberá aonde ou quando as idéias que dirigem sua receita futura vai parar. Poderia vir de sua equipe de engenharia. Pode vir na forma de uma colaboração entre a sua equipe de engenharia e outros fora da empresa. Ou poderia resultar de sua equipe colaborando com outra equipe na mesma empresa. Ou poderia sair completamente do campo da esquerda, porque João que é um desenvolvedor aleatório começou uma linha de discussão intitulado: “Ei, não seria legal se …”

google_ad_client = “ca-pub-5822666425104102”; google_ad_slot = “7651670077”; google_ad_width = 728; google_ad_height = 90;

Não só é o seu projeto onde a inovação acontece, e você não pode prever com precisão o tempo e local da inovação, é também o lugar onde as pessoas vão utilizar o software. Talvez o seu caso de uso não se encaixe perfeitamente em seus modelos mentais, ou talvez eles viram uma dimensão única para o software que você nunca considerou. É por isso que você pode criar uma comunidade de código aberto e espaço de projeto: fazer um lugar seguro para a inovação acontecer. Restringindo esse espaço com os requisitos do produto é precisamente como se mata uma comunidade ou impede-o de sempre realmente acontecer.

Produtos são projetados para reduzir o risco

Quando os projetos são acerca de inovação e expansão de horizontes, os produtos são projetados exatamente,  em torno de um caso de uso do cliente, e aí ele poderá ser suportado ou não. Você não quer que a sua visão do produto se expanda como o nosso universo, infinitamente em todas as direções. Você precisa restringir-lo se você quer dar suporte aos seus clientes e expandir as suas operações. Isto significa reduzir o seu risco, bem como a de seus clientes, mesmo que isso signifique dizer não para o desenvolvimento de novos recursos no momento.
Depois de ter visto muitos produtos acidentalmente acabarem, poucos realmente tiveram sucesso, eu deduzo que há uma linha mágica onde os produtos são apenas inovador o suficiente para ser muito valioso para os clientes, mas limitado o suficiente para ser rentável para os vendedores ou outros prestadores de serviços. 

Produto e Projeto são povos diferentes

De acordo com os temas acima, com seus objetivos distintos, também significam que as pessoas terão diferentes habilidades. Você não quer que a gestão de produtos se envolva em um projeto de upstream, e seus engenheiros de projeto que contam com a visão de futuro são, muitas vezes (muitas vezes?) mal orientados para fazer o projeto. 

Convidar os gestores de produto para participar num projeto como este, é como convidar os banqueiros de investimento para uma oficina de artistas.

Obviamente, diretrizes e requisitos de engenharia tem que vir de algum lugar e não gera espontaneamente a partir do éter. E muitas vezes os engenheiros terão informações valiosas para girar a manivela do produto, mas é uma questão de definição de quem dirige e o quê. Deixe que as pessoas criativas fazem o que fazem melhor, e que aqueles que sabem como afinar software ser o mais produtivo com o seu tempo limitado.

Há vários elementos de risco em relação à tecnologia, mas quero me concentrar em duas que parecem surgir com bastante frequência no mundo do software:
O risco de falha de software, causando uma falha, ou de outra forma, resultando em tempo e/ou dinheiro perdido. 

“Eu vou chamar isso de “risco de infra-estrutura.”

O risco de ficar preso a um determinado produto e fornecedor. 

“Vamos chamar isso de “risco de lock-in”.

Se você pensar bem e traçar as curvas de risco de cada um, você verá que eles estão inversamente relacionados. Como assim? Um projeto de código aberto funciona assim: um monte de novo código com verificações regular, com muitos desenvolvedores de várias fontes. O resultado deste é duplo: Porque nenhuma empresa domina este projeto em sua totalidade, e o risco de ser preso a um fornecedor em particular é muito baixo. Por outro lado, o risco para a sua infra-estrutura é extremamente elevado. Um teria que fazer muito mais do processo de depuração e, em muitos casos, a modificação do software antes de implantar na produção em comparação com a maioria das soluções de fornecedores.

google_ad_client = “ca-pub-5822666425104102”; google_ad_slot = “7651670077”; google_ad_width = 728; google_ad_height = 90;

Agora pegue um produto derivado com base nesse código e veja como ele funciona: Vai ser uma versão mais antiga, tendo recursos QE acionando a gestão de produtos, para aprimorar o produto final em algo útil e confiável. Assim, o risco de infra-estrutura será muito menor, porque você está usando uma solução a partir de um provedor de tecnologia, o risco de lock-in é bastante elevado. Talvez não tão elevado como com um produto proprietário, mas ainda muito elevado, no entanto. Vejo que a trama desta curva de risco logo abaixo, com uma linha pontilhada indicando o ponto ideal para a rentabilidade para o prestador e o valor para o usuário final:

Conclusão

Nesta análise, espero ter prestativamente explicado a diferença entre um projeto e produto, porque eles são ambos úteis, e por isso nunca se deve tentar encaixar os objetivos de um para no outro. Eles são diferentes espaços projetados para coisas diferentes. Cada um é útil em seu próprio direito, mas para muito diferentes fins. Um provedor de tecnologia inteligente terá uma visão diferenciada de cada um e vai saber como utilizá-los de forma eficaz.


você pode gostar também Mais do autor

Comentários