Tempo de conclusão em uma empresa onde os supervisores não sabem programar [duplicado]

Se os vendedores também são os responsáveis, você pode dizer: "Ok, eu posso ir com a sua agenda. Quais características ou responsabilidades você gostaria que eu sacrificasse para fazer o seu prazo?" Dessa forma você não está dizendo "não" para as pessoas responsáveis, mas você não está se comprometendo com coisas impossíveis. A decisão está nas mãos deles como administrar o negócio. Se eles quiserem atacar outras coisas para ter tempo para as mudanças, deixe-as.

EDITAR: Precisamos respeitar e nos submeter àqueles que estão em autoridade, enquanto ainda fazemos o nosso trabalho com excelência. A única maneira de fazer isso é com humildade. Eu vou trabalhar em qualquer coisa que meu chefe queira que eu trabalhe, mas eu só posso fazer tanto. Quando você diz a ele como é com uma atitude de submissão, ele está em uma posição melhor para tomar decisões melhores e ele vai querer mais funcionários como você.

Certifique-se de que essas coisas também estão documentadas para explicar por que os compromissos não são razoáveis e como a situação foi resolvida. Pode ajudar os colegas de trabalho a lidar com situações semelhantes no futuro.

Na minha experiência, as pessoas de vendas pensam que tudo é uma negociação em que você se encontra em algum lugar no meio. Isso é basicamente como eles funcionam. Eles tentam vender um produto para um cliente e pedir alto, o cliente oferece baixa e, no final, um preço que ambas as partes concordam em se tornar o acordo.

Eles também levam essa mentalidade para o chão de trabalho. Eles assumem que você está pedindo muitas horas para que eles tentem discutir algumas das horas, assim como em uma negociação.

Dar estimativas exactas só me deu dores de cabeça.

O que você pode fazer é seguir em frente: dê uma estimativa maior, onde eles podem reduzir alguns durante a "negociação" e, no final, acabar com as horas que realmente custa para você fazer.

Não mostre a eles sua falta!

Tente argumentar melhor sobre as alterações que você faz, dê a elas estimativas mais detalhadas. Faça uma sugestão como "Podemos fazer isso nas suas X horas, em vez das minhas Y horas, se formos dar testes de software para terceirizar". Ou "Podemos fazer isso mais rapidamente, se excluirmos essa parte da funcionalidade solicitada".

"Depois de dar-lhes a programação, eles começam dizendo OK, você pode fazê-lo no tempo XX, o que difere muito do meu plano." Antes de mais nada, pergunte-lhes como calcularam seu tempo XX.

Sugira a eles que um registro é feito de sua estimativa e sua estimativa. Então você pode comparar o real com as previsões e ver quem é mais preciso.

Diga "aguento minha estimativa". E depois, claro, acertar sua estimativa. Quando isso acontece três vezes, eles provavelmente confiam em você.

"Quando eles me perguntam quanto tempo eu quero para uma mudança"

Nesse ponto, pare-os. Não é quanto tempo você quer . É quanto tempo você precisa . Se eles insistirem, dê a eles o tempo que você quiser e o mínimo que precisar.

Também pode ajudar a manter uma medida muito visível da dívida técnica incorrida devido a todos os atalhos impostos a você pelas Vendas. Nikolay é amplamente otimista de que você pode influenciar as Vendas por conversa, quando seu comportamento atual lhes dá bônus.

Na verdade, se as vendas forem realmente impulsionadas por esses incentivos, você deve levar isso em conta ao formular sua resposta. "Recurso não confirmado pela Engenharia" é um motivo perfeitamente válido para eliminar uma solicitação de vendas.

Para fugir da preocupação com as horas, mude o jogo. Em vez de estimar o tempo, estime a complexidade em relação a algumas informações que formam uma linha de base.

Você menciona que você tem uma abordagem ágil, por que não tentar Scrum?

Em outras palavras, faça Sprints curtos, diga a eles que "sim em uma semana eu poderei desenvolver três dos seus cinco recursos", então certifique-se de entregar esses três recursos. Peça-lhes que priorizem as alterações / características / bugs e trabalhem estritamente nessa ordem. (Claro que há mais.)

Ensine-os sobre o triângulo de ferro do tempo, custo, qualidade e escopo. Você conserta três e o quarto é a área do triângulo e, portanto, uma função dos outros. Eu acho que é provavelmente mais importante no final quando você está entregando, quanto custa e esperamos que você entregue com qualidade do que exatamente o que você está entregando.

Este é um enorme bugbear meu para projetos liderados por vendas / consultoria e é uma situação difícil. Isso geralmente é uma questão de como a empresa opera.

É um caso clássico de rabo tentando abanar o cachorro, vendedores fazendo o que podem para fechar a venda, prometendo o mundo em recursos, e garantindo uma escala de tempo ridícula, processo de desenvolvimento de software e tudo o mais. .

Ou eles vão ouvir você ou não, não é necessariamente um fato que eles não entendem, mais provavelmente, eles sabem muito bem, mas tudo o que importa é fechar a venda, conseguir o negócio e se preocupar prazos mais tarde.

Dito isto, os clientes podem ser uma dor na parte de trás, eles querem que as coisas sejam feitas de forma barata, e eles querem saber quando isso será feito. E eles querem um desconto para inicializar.

Uma maneira de mitigar isso é ter um cara de tecnologia envolvido nas reuniões de vendas. Agora, isso não é necessariamente viável em todas as empresas, mas pode ser a única maneira de, pelo menos, tentar controlar os vendedores.

Isso pode ajudar a diferenciar entre quanto tempo uma coisa levará e quanto tempo será cobrado. Quanto tempo uma coisa levará é uma decisão técnica, eles não têm base para discordar de você, sejam teimosos. Quanto os vendedores querem cobrar por esse tempo é sua decisão e sua responsabilidade de vender para o cliente.

Além disso, os incentivos precisam ser resolvidos ou você sempre estará lutando em uma batalha difícil. Se os bônus de vendas não forem pagos com base no valor total da venda, mas na diferença entre o valor da venda e o custo de entrega, eles terão um incentivo para ouvi-lo.

Se eles quiserem reduzir o cronograma, pergunte a eles quais recursos eles querem deixar de fora e qual é a prioridade deles.

Em seguida, trabalhe nos recursos em ordem de prioridade e diga que eles podem ter o produto sempre que quiserem, mas não conterá todos os recursos solicitados até a data de término especificada inicialmente.

Se for um problema persistente, que tal destacar um vendedor para a equipe de desenvolvimento por uma semana ou duas. Dê a eles um livro sobre a linguagem de programação X, e diga-lhes para fazerem isso em sua sua estimativa. 99% do tempo eles falharão miseravelmente, e relutam em questionar suas estimativas novamente. Eles também podem ter uma ideia do que é necessário para fazer o desenvolvimento de software e perceber que não estão ajudando no processo.

Deixe claro que você está estimando o tempo que levará, e não prometendo que você será feito nesse tempo, e que fazer você diminuir o número não é nada mais do que convencê-lo a mentir para eles. Na verdade, isso não fará com que o software seja feito mais rapidamente.

Pergunte a eles o quanto isso seria bom para convencer uma mulher a reduzir sua estimativa de gravidez de nove meses para sete meses.

Melhor ainda, obtenha um gerente de produtos. Vendedores vão amarrar seu produto em nós, perseguindo comissões, porque têm pouco incentivo para se preocuparem com o produto em geral e com todo incentivo para perseguir a venda atual.

Existem dois problemas, que precisam ser desfeitos.

1. Pare de citar a tempo, comece a citar em dólares. Isso permite que eles façam uma análise de custo / benefício e permite que você adicione uma cotação padrão de "tempo para analisar". O tempo é muito difícil, porque não reflete a quantidade real de trabalho realizado (quarenta horas podem ser feitas em um dia, cinco dias ou três semanas), e é fácil demais não empurre o ciclo de liberação orçado de volta para tal solicitação.

2. Forneça à equipe de vendas uma entrada de solicitação no ciclo de desenvolvimento (preferencialmente uma interface não humana, para economizar tempo (medido em dinheiro)).

As pessoas de vendas tendem a pensar em termos de (se eu tiver X, posso fechar essa venda). Seus pedidos muitas vezes não são coerentes com a arquitetura atual do produto, mas são coerentes com a necessidade atual de um cliente.

Indique à força de vendas que tais solicitações são vitais para o seu produto e, como tal, você precisa não perdê-las na "solicitação rápida, levará mais tempo do que o período de interesse, solte o pedido, repita "ciclo. Tais solicitações precisam ser capturadas, analisadas, priorizadas, integradas ao produto, testadas e lançadas no próximo ciclo de lançamento.

Em seguida, faça backup de suas palavras com ações. Encurte o ciclo de lançamento para menos de dois meses, indique quais itens estarão no lançamento e atinja seus prazos. Não instrua a equipe de vendas sobre as razões internas necessárias, basta fazer uma análise do custo mínimo de uma solicitação fora de ciclo (em dólares) e qual pode ser o custo (dólares extras e porcentagem de ocorrência) se um problema exceder a complexidade mínima. Em seguida, pergunte ao vendedor se a venda é grande o suficiente para suportar a solicitação fora do ciclo.

Depois que eles tiverem um processo para uma solicitação durante o ciclo, e tiverem uma ideia de quanto custa processar uma solicitação fora do ciclo, provavelmente você pode converter a solicitação fora do ciclo em uma solicitação fora de ciclo. uma solicitação durante o ciclo, ou determinar que a solicitação fora do ciclo é lucrativa o suficiente para justificar a despesa.

Bem, espero que, para se comprometer com um trabalho, entenda que você e as Vendas precisam concordar em cumprir os requisitos que valem a pena.

Enfatize que, a menos que você e vendas possam concordar, eles não podem realizar a venda e o trabalho não acontece; portanto, você precisa concordar com uma contraproposta para o cliente (especificações menores, prazo mais longo, etc.) ou então eles precisam encontrar outro cliente.

Não adianta assinar um contrato com um cliente que você sabe que não pode cumprir, ele acabará ocupando o tempo de todos e você se arrisca a perder o cliente e os outros, e pode nem conseguir o dinheiro para o trabalho.

Se você acha que suas estimativas são precisas e o histórico reflete isso, use isso.

Quando eles disserem que você tem tempo XX, reveja sua estimativa tirando recursos até que seja reduzido para esse tempo. Não faça testes.

Então, é uma negociação sobre recursos e tempo, não apenas o tempo, que a história diz que você não pode mudar. Se eles insistirem em negar com o passar do tempo, comece a negar bônus por acertar o tempo (se a equipe estiver disposta a trabalhar as horas extras para chegar lá). Digamos que podemos fazer o tempo que você quiser, mas vai custar-lhe um bônus de $ 1000 para chegar lá

Lembre-os de que o desenvolvimento de software é como uma fábrica e a fábrica é capaz de produzir X em Y quantidade de tempo. Vai para o bônus novamente, você pode trabalhar horas extras, mas vai custar. Não chame isso de hora extra, ou eles só vão trabalhar para você até a morte. Precisa ser escrito também. X produto por data Y para o bônus Z. Você também pode insistir em um dia de folga depois que a equipe será queimada depois disso. Também tem no contrato que adicionar recursos ou correções de bugs acima de X% do tempo normal adicionará tempo para agendar.

Você não pode alterar a hora, apenas tire recursos.

Eu vi muito dessa divisão negativa e posicional na minha carreira e acho que a melhor maneira de trabalhar com ela é ser o mais honesta e transparente possível. (Frases negativas como "comportamento é estúpido", "não tem idéia", "não pode ser feito" devem ser evitadas. Procure soluções / causas raiz.)

Primeiro, parece que todo mundo está empregando negociações posicionais (book ). Eles querem o que querem e você quer o que você quer. Mas o que é realmente isso? Veja o que impulsiona a posição deles e segmente isso. Por exemplo. as vendas só querem tirar o produto o mais rápido possível para fazer mais vendas e ajudar os lucros da empresa. O que há de errado com isso? E do seu lado você simplesmente quer fazer o melhor software de qualidade que puder. Então você só precisa encontrar um meio termo . Eu acho que a melhor maneira de fazer isso é educação, honestidade e transparência. Trate-os como parte de sua equipe e não "nós contra eles".

Os métodos Agile e Scrum tentam incorporar isso em todo o processo. Certos aspectos do Scrum cuidam disso bem:

1. Um product owner que prioriza os recursos e escolhe o que acontece em cada sprint. Essa pessoa é parte da equipe . Esta deve ser uma pessoa que tenha em mente as melhores intenções dos clientes. por exemplo. isso poderia ser uma pessoa de vendas ou supervisor. Eles estão envolvidos em uma base regular para decidir o que entra no produto, então há uma grande motivação e responsabilidade (eles aprenderão a NÃO insistir em tempo versus qualidade / recursos)
2. Todas as partes interessadas também são membros da equipe, elas simplesmente não obtêm controle no backlog / sprints / cronograma. Trate-os como tal e eles podem aprender como as estimativas são calculadas e a complexidade inerente por trás do desenvolvimento de software.
3. Um scrum master trabalha na melhoria do processo ao longo do tempo. Não se espera que seja instantaneamente scrum, pois isso é irracional em qualquer situação. Eles trabalham na remoção de bloqueios de estradas para todos os membros da equipe (e para a empresa).

Em resumo, apenas seja honesto, positivo e tente educar - ele acabará melhorando. Mesmo que você não siga oficialmente o agile / scrum, leia alguma literatura para entender melhor esses conceitos e motivações.

Outra abordagem seria impossibilitar que eles não vejam POR QUE / COMO você está dando as estimativas.

Como você é responsável pelo processo de desenvolvimento, por que você não acompanha a velocidade da equipe e os mostra, com base em suas iterações passadas, por que você não cumprirá o prazo? Eu acho que é simples: "nossa velocidade atual é X, e nós temos Y pontos de história para essa iteração".