Produtos, projetos e outros animais

Produto ou projeto? As disputas sobre a definição desses conceitos não desaparecem, e esse não é um debate ocioso. Os métodos de gestão dependem das características de cada disciplina e as expectativas das partes interessadas dependem. Quero apresentar minhas definições dos conceitos de "produto" e "projeto". Quero enfatizar imediatamente - essas serão exatamente minhas definições com base em muitos anos de prática. É improvável que você encontre a palavra por palavra na literatura certificada, mas tentarei mostrar todos os cálculos que levam exatamente a essas definições. Terei prazer em discutir nos comentários se o seu ponto de vista difere do meu.

Um projeto é uma atividade. Um produto também é uma atividade. Após a conclusão, um resultado tangível pode aparecer na forma de um produto de TI, mas o software nunca é o fim em si mesmo de um produto. Ao contrário do projeto, onde o fato de criar uma solução de TI em funcionamento será um resultado significativo. O objetivo da atividade de criação de produtos é resolver um problema específico de um grupo específico de pessoas. A qualidade de uma solução para um problema pode ser medida em dinheiro, gostos, número de vidas salvas, número de acidentes ou simplesmente o conceito subjetivo de "qualidade de vida". Sim, como somos especialistas em TI, usamos ferramentas de TI para resolver problemas. No entanto, o resultado do produto como um todo não pode ser avaliado pela conformidade dos termos de referência e do produto de TI desenvolvido. Mas no projeto, é assim que avaliamos o resultado.

O objetivo da atividade do projeto é cumprir a tarefa em um prazo e orçamento claramente definidos, com uma determinada qualidade. Mesmo que a atribuição do projeto seja gravada na primeira fase do projeto, o projeto sempre tem um cliente em cujos interesses essa atribuição é gravada. O projeto é o cliente, o produto é o problema.Esta é uma diferença muito importante! Mesmo se o cliente do projeto formular o objetivo como "resolver o problema para mim", ele não será equivalente ao produto por um simples motivo: responsabilidade. Assim que a equipe do projeto cria a tarefa e a entrega ao cliente para assinatura, a responsabilidade pelo fato de o método proposto resolver o problema é transferida para o cliente. Sim, em alguns casos, você pode reduzir o risco de soluções perdidas usando abordagens ágeis (para não iniciar outro holivar, vamos assumir que, neste contexto, o Agile é “uma abordagem que reduz o risco de falhas como resultado de ciclos curtos de desenvolvimento, constantes análise do resultado e a capacidade de alterar a direção do movimento em qualquer iteração ”). Mas um projeto sempre tem limitações. Pelo menos a tempo. Então, a responsabilidade porque, no final do projeto, o resultado não será alcançado, ele ainda permanecerá com o cliente (especialmente, apenas com a abordagem Agile, onde o cliente está envolvido no trabalho com bastante força).

O produto não tem cliente. Existem usuários cujo produto resolve o problema. Mas eles não são clientes. Henry Ford é creditado com a frase "Se eu perguntasse aos meus usuários o que fazer, ainda assim anexaria a quinta perna ao cavalo". Não é tão importante quem surgiu com a frase, mas ilustra perfeitamente a diferença. Ford resolveu o problema do movimento rápido e independente das pessoas da classe média. O táxi da Yandex resolve o problema da entrega rápida de carros, independentemente de pertencer a uma frota de táxis, e o uso de um smartphone e um sistema de TI em vez de um único centro de expedição permite superar o último em preço e qualidade. O clube de entrega resolve o problema da diversidade alimentar. Etc.

Um produto sempre tem um investidor. Pode ser um fundador que investe seu tempo e dinheiro acumulado ou uma empresa separada que investe dinheiro ou conexões. Um investidor difere do cliente por não aceitar a responsabilidade pelo resultado da equipe. A equipe é responsável pelo resultado do produto. Para entender se um produto está se movendo na direção certa, são geradas métricas do produto. Com relação às alterações, essas ou aquelas alterações feitas no produto por um determinado período são avaliadas. O projeto também possui métricas, mas elas se relacionam principalmente ao desenvolvimento de tempo ou orçamento. Para entender a diferença, vejamos um exemplo simples: a métrica "execução orçamentária" do período mostrou um excesso do fato em relação ao plano. A análise mostrou que pegamos o segmento no qual não esperávamos publicidade contextual.A conversão do segmento na ação de destino mostrou que há potencial. Se fabricarmos um produto, analisaremos e fortaleceremos as vantagens competitivas do produto no novo segmento, aumentando o orçamento. Se estamos realizando um projeto, esse é um passo claro além dos limites do projeto e precisamos ajustar os anúncios para remover o tráfego desnecessário.

Cada produto possui pelo menos um concorrente - uma maneira familiar de resolver um problema. Para Henry Ford, estes eram passeios a cavalo ou carruagens. Para o táxi Yandex, ligue para empresas de táxi ou ligue para um único serviço de despacho. O Delivery Club luta, em primeiro lugar, com "cozinhe você mesmo". E a eficácia de cada um não é a conveniência das interfaces de suas aplicações, mas a qualidade da solução para o problema original. Se o Yandex-taxi sempre chegar muito mais rápido do que pelo despachante, não importa o quão inconveniente seja o aplicativo, ele o usará. Mas em Tolyatti, por exemplo, ainda um táxi, encomendado por telefone de um único serviço de expedição, chega mais rápido e em mais lugares. Portanto, no Tolyatti Yandex, o táxi não é bem-sucedido, apesar da aplicação super bacana.

Os projetos podem não ter concorrentes, uma vez que o objetivo do projeto pode ser otimizar algum processo ou apenas coletar dados, reconhecimento em batalha. O projeto termina assim que seu objetivo é alcançado ou o prazo para sua implementação. O produto está vivo enquanto o problema está vivo. As alterações do produto são uma maneira de sobreviver em um ambiente competitivo. A cada iteração, a equipe do produto deve responder às perguntas “o que podemos mudar para que fique ainda mais fácil / rápido / mais confortável para nossos usuários resolverem seus problemas”. A equipe do projeto resolve o problema inverso - como impedir o crescimento do volume do projeto.

Agora, com base nas características acima, vamos derivar as definições do projeto e do produto.

• — , , , . ( ) , .
• — , . , , , , — , . — — .

Antes de tirar conclusões, quero responder a uma pergunta silenciosa dos leitores: "O que a figura no título tem sobre o tópico em discussão"? O mais direto. Jacob Jordaens descreveu o segundo encontro de um sátiro com um camponês da fábula de Esopo “O Homem e o Sátiro”. Na primeira reunião, o sátiro perguntou ao camponês, soprando as próprias mãos no inverno: "

O que você está fazendo?" Por que você está soprando em suas mãos?
"Eu os aqueço com minha respiração."
Na segunda reunião, que está na foto, o sátiro pergunta ao camponês: "
Por que você está soprando na sopa, tentando aquecê-la?" Ele é tão gostoso?
"Não, sopro a sopa para esfriar!"

A partir desse diálogo, o sátiro conclui que os humanos são criaturas suspeitas de duas faces que devem ser evitadas.

São necessárias definições dos conceitos de "produto" e "projeto" para não cair na mesma situação que um sátiro. Eles são necessários para aplicar as ferramentas certas no momento certo, escolhendo o sistema de controle certo. Para não tentar avaliar as atividades do projeto com métricas de produto ou vice-versa. Para não tentar formular um orçamento de produto com base nas especificações técnicas de um sistema de TI. Focar claramente a equipe em uma estratégia de trabalho específica. Por exemplo, ao projetar sistemas de TI em um projeto, faz sentido escolher as soluções menos arriscadas. E no produto estão aqueles que atendem ao conceito de ganha-ganha. A escolha de uma cascata iterativa para o desenvolvimento do projeto é uma etapa completamente natural, pois permite controlar com mais precisão o orçamento e o cronograma. O uso de abordagens flexíveis nos produtos é mais conveniente, pois eles cometem erros com mais frequência e rapidez.Use abordagens de acordo com a realidade, não se engane - e haverá menos frustrações na vida.