Existe uma maneira de combater o comprometimento excessivo das vendas? [fechadas]


120

Pareço estar repetidamente preso em uma situação em que as datas de lançamento são definidas não com base em nada técnico, mas porque alguém em Vendas se comprometeu com um cliente até então. Com base em discussões com amigos em desenvolvimento em outras empresas, a mesma coisa parece acontecer.

"Aqui está o conjunto de recursos comprometidos e a data de lançamento comprometida", e é difícil argumentar, porque neste momento há dinheiro nele, e isso supera tudo.

Em geral, existe uma maneira de adiar isso? Se não for para esta versão, o que dizer no futuro? O problema que tenho é que a única maneira que vejo de fazê-lo é fazer o melhor que posso, mas lance o software "como está", por assim dizer.

Eu não quero lançar software cheio de erros, já que é meu nome anexado, mas fazer 80 horas por semana durante meses justifica a data de lançamento arbitrariamente definida.

edit: para o registro, eu não estou fazendo 80 horas por semana agora, apenas isso me vem à mente como o que seria necessário para cobrir o recurso esperado definido até a data de lançamento.


49
Por que seu nome está associado ao produto quando você não está assumindo os compromissos? Se a empresa deseja lançar software inacabado de má qualidade, esse é o direito deles, mas não há razão para você assumir responsabilidade pessoal por uma decisão que você nem tomou.

4
@Giorgio haha ​​good one :)
ell

3
@ShawnD. Para a Horda!
Kalamane

3
@ell: Obrigado. Bem, acho que é uma má gestão tentar extrair mais trabalho dos desenvolvedores do que eles realmente podem oferecer. Existe uma complexidade inerente a cada projeto e, se você alocar poucos recursos, acaba com um software ruim ou não entrega a tempo. É tarefa de uma boa administração reconhecer isso e planejar consequentemente. O melhor é que o gerente também seja um bom desenvolvedor.
Giorgio

3
Compre o codificador limpo. Leia (eu o devorei em um fim de semana) e aplique as idéias vigorosamente à sua carreira. Seu trabalho é dar um "Não" honesto se o trabalho não puder ser feito. Se você não fizer isso, não terá ninguém para culpar além de si mesmo. Eu sei que o risco de perder o emprego pode pesar em ser corajoso o suficiente para ser honesto. Mas o outro lado está sendo forçado a 80 horas por semana para cumprir um compromisso totalmente infundado.
Michael Brown

Respostas:


147

Pare de fazer as 80 horas semanais. Este é um reforço positivo . Como eles estão recebendo o produto no prazo e com os custos esperados, continuarão a fazê-lo, independentemente do que isso faça com você.

Se eles não conseguem orçar o tempo adequadamente, isso é culpa da gerência. Não é teu.

Deixe-os perder alguns prazos.


60
+1 por se defender. Os desenvolvedores que se deixam levar por toda parte é exatamente o que permite que essas culturas de lojas de roupas persistam.

31
Acrescentarei que, enquanto isso funciona, você deseja minimizar os danos que isso pode causar à relação com o cliente. Assim que você tiver um prazo não razoável, precisará ser franco e avisar o vendedor que isso simplesmente não vai acontecer, para que eles possam lidar com o cliente de acordo.
GSto

40
Infelizmente, em muitos lugares, isso fará com que o desenvolvedor que trabalha apenas horas "razoáveis" pareça não ser um "jogador da equipe" que não ajuda a atingir as metas. É provável que sejam os primeiros contra a parede quando os tamanhos das equipes forem cortados. Poderia muito bem procurar emprego para um empregador mais razoável. Essa tática de "cumprir regras" funcionará se todos os desenvolvedores estiverem a bordo.
FrustratedWithFormsDesigner

20
@FrustratedWithFormsDesigner Quem se importa se o vêem como não um jogador da equipe? Se eles não gostam de você, podem libertá-lo daquele lugar horrível e você pode procurar outra coisa enquanto coleciona o desemprego por um tempo. Além disso, não é como se as vendas e a gerência estivessem preocupadas com o bem da "equipe", esperando horas extras obrigatórias. Surpreende-me que desenvolvedores com habilidades comercializáveis ​​e desejadas se sujeitem a esse tipo de bullying gerencial. Se você pode ser demitido ou demitido e ter outro trabalho alinhado em menos de 3 meses, VOCÊ exerce toda a força.
Maple_shaft

6
@FrustratedWithFormsDesigner: Tendo lidado pessoalmente com o alto risco de falha do comprometimento excessivo, recomendo procurar um novo emprego assim que souber que as coisas começam a ficar instáveis. Porque se você é marcado como um péssimo jogador de equipe, sente-se quase esgotado com o tempo todo, as chances são altas de que você será ferido pelo chamado "time" e acabará sendo demitido, mesmo se você se esforçar ao máximo. Procurar emprego como você ainda tem um é uma situação muito melhor para você do que procurar emprego enquanto estiver fora daquele que não lhe dará boas referências.
Spoike 1/11/11

96

Em geral, existe uma maneira de adiar isso? Se não for para esta versão, o que dizer no futuro?

Obviamente, existe: deixe que falhem mal com essa abordagem. Nada ensina, além de falhar.

Faça uma estimativa antes de começar e mostre a eles. Em seguida, faça o seu melhor, escreva um bom código, pare de compensar a estupidez deles com o seu tempo livre e, quando eles reclamarem depois, lembre-os da estimativa de tempo que você os mostrou, com base nos princípios de engenharia.

E é melhor você começar a fazer isso com o projeto atual .

Se eles continuarem culpando você pelo problema, é melhor começar a procurar um novo emprego, já que nada os convencerá de que eles são o problema.

Como uma reflexão tardia, acho que essa pergunta realmente merece um link para a famosa história da EA, como apresentada em um dos livros de Joel: EA: The Human Story .


1
Certifique-se de aprender a diferença entre uma estimativa e um compromisso: blog.mountaingoatsoftware.com/… Parece que eles também não se importam, mas depois que sabem a diferença é útil.
StuperUser

26
+1 para mostrar a estimativa para eles. Além disso, um ponto que eu gostaria de ressaltar neste post: mesmo nos ambientes da empresa em marcha mortal, fornecer trabalho de graça aos clientes (ou seja, todas as horas extras não remuneradas) é altamente desencorajado, porque a empresa poderia estar fazendo isso muito mais dinheiro com o mesmo trabalho se eles estivessem cobrando do cliente por isso. Assinalar que o comprometimento excessivo das vendas está perdendo o dinheiro da empresa pode fazer toda a diferença.

5
Um projeto que falha não ensina nada à gerência em uma cultura como a descrita. Como os vendedores ganham dinheiro e os desenvolvedores são apenas uma despesa necessária , os desenvolvedores sempre serão culpados por não trabalharem o suficiente se os vendedores venderem em excesso.
Mark Booth

2
Sim. Portanto, quando as vendas chegarem a você sem uma especificação, insista em uma antes de concordar em estimar ou forneça a elas uma faixa de estimativa apropriada com base no nível de detalhe que elas fornecem. Isso geralmente será algo como "entre uma e trinta semanas".
PeterAllenWebb

2
@ Mark Booth: É por isso que você precisa monetizar os custos de desenvolvimento. Claro, o desenvolvimento é uma despesa necessária, mas não é a única. E, em geral, a gestão não compreender que o trabalho de vendas é vender acima do custo; qualquer idiota pode vender abaixo do custo.
MSalters

52

Isso geralmente ocorre por causa de um incentivo perverso - os vendedores estão sendo pagos em comissão, enquanto a equipe de produção é paga em salário. Os vendedores têm várias alavancas para trabalhar: recursos, custo e data de entrega. Eles têm um forte desincentivo em reduzir o custo, porque isso geralmente diminui sua comissão, de modo que tendem a aumentar os recursos e a data de entrega (em termos de antecipação). Eles vão empurrar os mais altos que puderem para fechar o negócio.

Tente vê-lo do ponto de vista deles, apenas por um momento. Eles também têm uma família para alimentar - e se a diferença entre fechar uma venda em que venho trabalhando há meses apenas diminuir algumas semanas do cronograma, é uma tentação incrível, especialmente se não o fizer. realmente entender o que isso significa.

A tentação é dizer "sempre foi assim, e sempre será assim". Mas um local em que trabalhei tinha pelo menos uma solução PROPOSTA, se não implementada ... um gerente finalmente levantou as mãos e disse: "se a hora extra dos programadores estiver sendo usada para fechar uma venda, eles receberão uma parte do a Comissão." Não foi implementado, mas teria alinhado os incentivos de todos mais de perto ... os programadores teriam ficado emocionados ao saber sobre um novo recurso que precisava ser lançado em pouco tempo, porque antecipariam a comissão e os os vendedores estariam MENOS aptos a criar essas circunstâncias, porque seriam menos propensos a trabalhar a seu favor.


46
+1 se a hora extra dos programadores estiver sendo usada para fechar uma venda, eles deverão receber uma parte da comissão.
Gilbert Le Blanc

12
Isso incentivaria os desenvolvedores a liberar porcaria não testada.
Quant_dev 1/11/11

5
Certa vez, comprei o almoço comprado por um gerente de vendas que recebeu uma comissão de milhares de dólares em um projeto que eu participava de uma marcha mortal de cinco semanas. Não posso dizer que isso me fez sentir muito melhor com a situação.
Ray em Dan

7
@quant_dev - todas as situações incentivam os desenvolvedores a liberar porcaria não testada - exceto os testes. Essa é uma pergunta separada.
Chris B. Behrens

18
A maneira mais fácil de ajustar os incentivos é subtrair o valor da hora extra do valor do negócio antes de pagar a comissão percentual.
Robertc 01/11

26

A equipe de desenvolvimento deve ser consultada sobre essas decisões ou você nunca sairá desse ciclo. Se você não está gerenciando a equipe, um dos gerentes de linha precisa defender a equipe de desenvolvimento. Se eles fazem parte do problema, convém considerar outras opções de emprego.

De um modo geral, as vendas não devem se comprometer com nada sem a aceitação do gerenciamento de produtos, que obviamente deve consultar a equipe de desenvolvimento quanto a prazos. Não há realmente nenhuma boa desculpa para contornar isso em uma empresa grande ou pequena, porque, em última análise, a equipe de Vendas aguenta um pouco a entrega insuficiente (seja em qualidade ou escopo).


2
+1 para um somatório preciso e de alto nível. O gerenciamento de produtos deve estar envolvido, mas o comprometimento e a má aparência posteriormente podem ser necessários para a sobrevivência contínua da empresa.
Maple_shaft

É bom dizer coisas assim, mas não é um conselho real que possa ajudar a resolver o problema atual do OP. Que medidas eles poderiam tomar para chegar a essa melhor posição?
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner Além de conversar com a gerência sobre a necessidade de uma melhor entrada do Gerenciamento de Produto nas discussões de vendas, bem ... nada pode ser feito como desenvolvedor. Esses tipos de empresas são definidos à sua maneira e qualquer coisa que não seja uma mudança de gerência não mudará nada.
Maple_shaft

1
Infelizmente, em muitas empresas, a opinião dos "gurus / rockstars" de vendas geralmente tem mais peso do que a do gerenciamento de produtos, que às vezes não é suficientemente forte para apresentar sua causa à alta gerência. Descobri que muitas pessoas de vendas acreditam que, independentemente do tempo estimado pelos desenvolvedores, será muito pessimista e poderá pelo menos ser dividido pela metade facilmente.
Dodgy_coder 2/11

O pessoal de vendas recebe muito mais prestígio que os desenvolvedores, pois estão muito mais intimamente ligados ao fluxo de cheques recebido dos clientes. Isso é verdade mesmo em empresas de software em que os desenvolvedores são sem dúvida muito importantes, mas não tão importantes quanto os vendedores que "trazem para casa o bacon". Infelizmente, é assim que praticamente todos os CEOs / MDs etc. o verão.
CraigTP

21

Isso é quase universal em empresas menores, pois elas têm uma necessidade maior de fechar um acordo. Até que fui levado para as reuniões de vendas da minha empresa, fiquei amargo com isso, mas pelo menos posso entender como e por que isso acontece um pouco mais.

Os clientes querem rápido e muitos vão se esforçar para conseguir. Isso incentiva as vendas a dobrar os compromissos de tempo apenas para obter algo assinado. Um contrato assinado é ouro porque você pode adquirir capital ou crédito usando um. Às vezes, é melhor ter um prazo apertado do que nada para trabalhar.

Outras vezes, se é um mercado quente e há muitos concorrentes, a empresa tem uma necessidade iminente de lançar um produto mais rapidamente do que todos os outros. Uma empresa maior ou uma com mais capital sempre pode contratar mais recursos, uma menor não pode.

A situação é complicada quando os prazos são realmente artificiais e é pressionado pelas vendas e pela gerência para garantir grandes bônus para si.

Não crie o hábito de trabalhar mais de 45 horas por semana, isso faz mal à sua saúde e isso vem primeiro.


2
Concordo que é mais difícil para as empresas menores colocar pão na mesa. Ainda é errado (desagradável) que as vendas recebam comissões pelo esforço extra dos desenvolvedores. A gerência precisa reconhecer e corrigir essa situação ou eles sempre terão uma alta rotatividade de desenvolvedores.
semaj

16
+ 1 "Não faça um hábito de trabalhar mais de 45 horas por semana, é ruim para a sua saúde e que vem em primeiro lugar"
DevSolo

2
O que há com 45 horas? Você não cantou um contrato de 40 horas ??
Sbi

14
@bi: Você pode se surpreender. Onde trabalho, fomos obrigados a cantar o contrato. De fato, demorou cerca de 40 horas para cantar a coisa toda. (Havia muitas letras miúdas.) Isso era particularmente ruim, porque eu tenho uma voz fraca.
Matthew Scouten 1/11/11

3
@MatthewScouten quantas línguas você fala?
jim

11

Eu trabalhei nos dois lados da casa. Lembre-se, sem o pessoal de vendas, não haveria empregos ou projetos a jusante.

Como combater o comprometimento excessivo das vendas : Faça uma estimativa e, em seguida, faça pelo menos um múltiplo de 130% (sempre planeje uma contingência mínima de 30%). Forneça e documente a referida estimativa. Perceba que suas estimativas de esforço serão reduzidas no processo de vendas. Tudo bem, basta que a gerência corte o contrato de licença / venda / comissão em qualquer redução dessas horas. Se você é uma empresa pública, isso fica complicado com o VSOE , mas até que você atinja o pessoal de vendas com responsabilidade de contrato antecipadamente durante o processo de vendas, ela se tornará sua responsabilidade mais tarde.


6
Isso só funciona se o OP puder ver o recurso em potencial e fornecer uma estimativa antes que os vendedores tentem vender. Parece que o OP nem sequer ter a chance : "Here is the committed feature set and here is the committed release date".
FrustratedWithFormsDesigner

2
O problema é que os vendedores geralmente assumem que você adicionou uma contingência e é por isso que eles se comprometem com um prazo anterior.
Dodgy_coder 2/11

Talvez a comissão completa deva se basear em uma entrega pontual, talvez devendo ser recuperada por uma porcentagem do tempo excedente do desenvolvedor gasto. Isso alinharia o interesse da empresa com as vendas.
precisa saber é o seguinte

10

Existem várias estratégias que você pode usar, mas geralmente precisará de aprovação ou adesão da gerência.

  1. Pague aos desenvolvedores horas extras a um ritmo maior. Trabalhar horas extras não é tão ruim quando você está ganhando muito dinheiro com isso. E se isso começar a afetar os resultados da empresa, a administração aplicará pressão nas vendas para fazer uma melhor estimativa do trabalho.

  2. Pague os vendedores com base no lucro, e não nas vendas brutas. Cada hora de trabalho que eles não incluem em sua estimativa afeta negativamente sua comissão.

  3. Limite o número de horas que os desenvolvedores podem trabalhar para 40 (ou qualquer que seja a semana de trabalho padrão em sua parte do mundo).

  4. Faça o pessoal de vendas trabalhar a cada hora que os desenvolvedores trabalham. Se eles querem que você trabalhe horas extras para concluir o projeto, também precisam estar lá. Encontre algo útil para eles fazerem, como escrever documentação ou produzir cópias caligráficas e iluminadas à mão do Design Patterns e da C ++ Standard Template Library .

  5. Faça com que os desenvolvedores calculem cada trabalho em vez de permitir que os vendedores o façam. Pelo menos dessa maneira, você tem a capacidade de tornar o cronograma mais razoável. Porém, essa não é uma ótima solução ... os desenvolvedores geralmente são péssimos em estimar o trabalho necessário. Mesmo que a estimativa seja razoável, eventos imprevistos podem impedir que você atinja seu objetivo. Além disso, todos nós tendemos a não trabalhar no início de um projeto longo com a mesma urgência que fazemos quando o prazo se aproxima. Esses são os fatores que motivam os curtos ciclos de desenvolvimento que os proponentes do Agile adotam.

  6. Adote a abordagem "ágil" e se recuse a confirmar. Ser ágil exigirá muito mais envolvimento do cliente, mas também pode dar ao cliente mais flexibilidade, porque eles também não precisam se comprometer com a forma final do projeto. As vendas podem não ficar satisfeitas com isso no início, mas podem mudar de tom quando perceberem que isso pode oferecer muitas oportunidades para vender mais trabalho.

Penso que a solução menos atraente é algo que faz com que a equipe de vendas pareça ruim aos olhos dos clientes em potencial. A equipe de vendas é o rosto da empresa. Fazer com que pareçam ruins prejudica toda a empresa, e isso pode não resolver o problema - eles podem sentir que precisam fazer um acordo ainda melhor para o cliente, a fim de recuperar sua confiança.


Não pode fazer o nº 4, você sabe disso claramente. As vendas estão buscando 100x as perspectivas de qualquer contrato ativo.
Jé Queue 1/11/11

2
Re 4: Eu trabalhava em uma empresa onde o pessoal de vendas saía às 17h00, 1 hora antes de todo mundo. Não criou bons sentimentos entre as vendas e o restante da força de trabalho.
Quant_dev 1/11/11

2
@Xepoch Se eles vão para casa mais cedo do que os programadores, obviamente não estão ocupados demais para riscar alguns manuscritos iluminados.
Brian Gordon

1
@ Graham, escrevi "estratégias que você pode usar", mas, na verdade, essas são realmente estratégias que a gerência pode usar se virem o supercomprometimento perpétuo como um problema que realmente precisa ser resolvido. O número 1 pode ser, de fato, o mais razoável. Só porque você trabalha com salário não significa que você não é elegível para horas extras, bônus ou horas extras. Eu recebi os três em momentos diferentes enquanto trabalhava como assalariado. Da mesma forma, mudar a estrutura de remuneração dos vendedores não é impossível; as empresas freqüentemente oferecem incentivos ou desincentivos para mudar o comportamento dos vendedores.
Caleb

1
Concordo com Caleb. Além disso, geralmente os clientes que tiveram suas linhas do tempo adiadas e o escopo reduzido não ficam felizes com isso e tendem a se esquivar do pagamento. Não se deve presumir que esses tipos de coisas não afetem a linha de fundo. De fato, muitas vezes é necessário que gerentes e vendas aumentem o escopo sem cobrar mais, a fim de amenizar um cliente irritado. Você deve abordar a gerência com a promessa de que pode ajudar os clientes a deixar de ficar com raiva e oposição, ou pelo menos fazer com que isso aconteça muito menos. Este não é um sonho. Eu já vi isso na vida real.
precisa saber é o seguinte

8

Sair

Já existem muitas sugestões sensatas nas respostas, que, espero, podem ajudar a resolver esse relacionamento disfuncional. Mas no final, você decide quanto deseja trabalhar.

É fácil ser pressionado pelos colegas de trabalho para trabalhar demais. Mas você está sacrificando sua vida pessoal quando faz isso.

Aqui está o que você pode fazer:

  • Diga ao seu chefe: "Eu tive que trabalhar muito mais horas extras do que gostaria aqui. A partir de agora, não vou trabalhar mais de X horas por mês".
  • Como outros sugeriram, estime quantas horas as coisas levarão na frente. Lembre-os de que "no meu limite de X horas por mês, provavelmente não terminarei isso dentro do prazo". Coloque isso em um email para referência posterior.
  • Consulte esse e-mail quando o prazo terminar. "Está vendo? Como projetado, não conseguimos atingir esse prazo em um horário razoável de trabalho".
  • Se eles continuarem pressionando você a trabalhar horas extras e todos os esforços de comunicação falharem, saia.

Experiência pessoal

Saí do meu último emprego porque estava sempre trabalhando horas extras e sempre me pedindo para trabalhar mais. Eu disse a eles claramente na minha entrevista de saída que gostava de muitas coisas sobre o trabalho, mas não via o fim das horas extras à vista.

Também expressei claramente esse desejo em minha entrevista para o meu novo emprego e recebi uma resposta entusiasmada. Eles se mantiveram fiéis à sua palavra: raramente me pedem horas extras aqui.

Meu ex-empregador tem uma alta taxa de rotatividade de desenvolvedores e está com dificuldade em recrutar esses dias porque tem uma reputação de excesso de trabalho. Talvez o custo extra de recrutamento e treinamento lhes ensine uma lição. Mas se não, não é problema meu.


Eu li um bom livro sobre isso uma vez chamado Never Work for a Jerk. Estou surpreso que é fora de catálogo, mas a Amazon ainda tem usado cópias: amazon.com/gp/product/0880297484/?tag=resingnet-20
Tom Resing

6

Primeiro, lembremos que todos geralmente temos empregos para apoiar os negócios que os vendedores fazem, em vez de construir arte de programação tecnicamente perfeita. Se eles não fizerem os acordos, você não tem emprego.

Dito isso, o truque é encontrar maneiras de trabalhar com vendas para fazer com que todos pareçam bons. Processos em que a equipe de tecnologia pode pelo menos expressar uma opinião sobre as propostas antes que elas saiam pela porta é fundamental. Encontrar maneiras criativas de lidar com a compensação também ajuda muito - se as vendas tiverem que "dar gorjeta" à engenharia, quando a engenharia incorre em horas extras maciças, fazendo um cronograma irrealista funcionar, parece reduzir drasticamente a frequência dos projetos de marcha da morte.


4
E se você não implementá-lo, eles também não têm emprego. Não posso aprovar essa visão do programador como suporte para o pessoal de vendas.
Agos

@ Agos: ponto justo. Por outro lado, qual a probabilidade de você ser contratado em outro lugar se for demitido por se recusar a trabalhar? E como a maioria das lojas está disposta a contratar o próximo cara que participará das marchas da morte.
Wyatt Barnett

Se alguém quer aceitar um emprego na marcha da morte ou continuar nele, esse é o problema deles. A empresa para a qual trabalham em breve ficará com apenas as pessoas que NÃO PODEM SAIR, geralmente porque não têm a habilidade e a experiência necessárias para se mudarem para outro lugar. Desenvolvedores qualificados estão cada vez menos distantes do que os vendedores qualificados. Eles merecem ser tratados com pelo menos tanta deferência.
PeterAllenWebb

5

Isso é algo que você precisa levar ao seu gerente (existem gerentes de desenvolvimento, certo?) E explica o problema. É uma mudança que precisa acontecer no nível organizacional - as vendas precisam se beneficiar do desenvolvimento antes de assumir compromissos e, antes que isso aconteça, elas precisam obter a direção de seus chefes.

Não há nada que você possa fazer para que a mudança aconteça, mas você definitivamente deve apresentá-la ao seu gerente.

Além de tentar mudar a cultura (boa sorte), sempre que chegar a um prazo que você não pode cumprir, recue - com números. Divida o projeto e mostre a eles sua estimativa de tempo. Se for um projeto de seis semanas, conte a eles. Se tiver sido prometido ao cliente em quatro semanas, você não poderá fazer isso e precisará divulgar essas informações o mais rápido possível. Felizmente, seus vendedores poderão retornar ao cliente e definir melhores expectativas, ou trabalhar com você para criar um conjunto menor de recursos aceitáveis ​​para entregar dentro do prazo prometido, com os recursos adicionais a serem adicionados posteriormente.

Editar para adicionar: não permita que eles reduzam sua estimativa. Tenha certeza de que está correto e cumpra-o. Eles vão tentar negociar com você, mas não deixe.


8
Mas mostre a eles o que eles podem ter em quatro semanas. Talvez eles possam ter todas as telas com metade dos campos, ou algo assim. Ou três dos cinco principais fluxos de trabalho. Pergunte em qual desses três você deve trabalhar. Torne o problema "deles".
Sdg

1
Excelente argumento, Robert Martin fala muito sobre ser firme nas estimativas do Clean Coder, que fornece o único antídoto razoável para o gerenciamento irracional. Sempre esteja ansioso para oferecer o máximo que puder, mas nunca concorde com uma meta ou mesmo "faça o seu melhor" para alcançá-la, quando não puder ser alcançado de maneira razoável. É seu trabalho alertar sobre restrições. Você é o único que pode vê-los.
PeterAllenWebb

4

Uma sugestão que ainda não surgiu: retrospectivas .

Não diga "não, não estou fazendo hora extra", que sempre incentiva outros desenvolvedores a aparecer e fazer você parecer mal.

Mas diga claramente à sua gerência que toda vez que você precisar fazer mais de 40 horas por semana para concluir um trabalho, todos os envolvidos no projeto deverão sentar-se em uma sala após a entrega do produto , descobrir o que deu errado e o que podemos fazer para impedir que isso aconteça novamente. Ou, melhor ainda, todo projeto deve ter uma retrospectiva para discutir o que correu bem e o que deu errado.

Se você estiver certo e os vendedores se comprometerem demais, isso ficará muito claro muito rapidamente. Mas não preveja a conclusão e não seja contraditório antes do fato. Fale sobre isso em termos de ações que sua equipe pode fazer para entregar a tempo, sem horas extras.

Você nunca sabe, você pode até encontrar melhorias em seus próprios processos, o que pode tornar a estimativa do vendedor mais viável.


3

Não há absolutamente nenhuma maneira de combater isso completamente. A própria natureza das vendas é exagerada. Como representante de vendas, você está lá para fazer desaparecer magicamente os problemas do possível cliente. Os bons representantes de vendas exageram apenas levemente, os ruins causam um grande constrangimento.

Qualquer coisa que você fizer só causará agravamento ou tensão entre o pessoal do produto e o pessoal de vendas (pelo menos). Você pode se esforçar ao máximo para evitar gafes muito ruins por parte de seus representantes de vendas, mas no final do dia os desenvolvedores e os representantes de vendas são pagos com a mesma conta bancária. Sua empresa terá sucesso ou fracassará como unidade, portanto, iniciar uma guerra civil com vendas não ajudará.

Se você tiver um ou mais representantes de vendas que costumam ser constrangedores, o gerenciamento de vendas cuidará do problema. Como desenvolvedor, você não terá o poder de fazer nada a respeito, portanto, você deve se concentrar em fornecer o melhor produto possível com o tempo e os recursos que eles lhe oferecem.


Por que é impossível desenvolver uma reputação como uma sólida loja de desenvolvedores que produz entregas de forma realista, em vez de alegar fazer mágica? Quero dizer, não existem clientes por aí que não são idiotas e que realmente entendem o que estamos falando?
Brian Gordon

Tenho certeza de que o bom senso é tão comum entre os clientes das lojas de desenvolvimento quanto na população em geral. Eu diria que todos os clientes, com ou sem sentido, perceberão a diferença entre o que é prometido e o que é entregue - ou pelo menos a diferença entre o que eles esperavam e o que foi entregue. Os sensatos continuarão voltando quando essa lacuna for pequena ou inexistente. O restante comprará apenas a cotação mais barata, como sempre.
Joel Brown #

3
"A própria natureza das vendas é comprometida demais". Discordo. A natureza das vendas é lançar seus produtos e serviços da melhor maneira possível, vendê-los em todas as oportunidades disponíveis e criar mais oportunidades. Um histórico de entrega dentro do prazo e do orçamento pode ser uma grande vantagem em todas essas situações. Mesmo que uma estimativa externa do esforço de desenvolvimento precise ser reduzida das estimativas técnicas reais feitas internamente para realizar uma venda estratégica, isso não deve ser uma desculpa para impor internamente os desenvolvedores. Isso não é profissional.
precisa saber é o seguinte

2

É difícil responder sem conhecer a estrutura da sua empresa.

Algumas ferramentas gerais para ajudar são:

  • Concordam com (mas os responsáveis, não as vendas) os controles de qualidade
  • Tenha um roteiro de produto (interno e externo)

Ao concordar com os controles de qualidade , você tem um motivo de negócio para não conseguir lançar o software com erros. Você pode precisar convencer seus chefes por que isso é importante (espero que não), mas há muita literatura por aí para ajudar nisso.

Por ter um roteiro de produto , as vendas sabem o que podem e o que não podem prometer aos clientes. Se eles quiserem mudar o roteiro, eles precisam aumentá-lo com o Gerente de Produto / Gerente de Projeto / Gerente de Desenvolvimento ou quem quer que esteja mudando.

Se eles prometerem algo a um cliente que ainda não está de acordo, azar. Esperamos que seu roteiro seja baseado em dados de mercado sobre as necessidades do cliente. "O que exatamente você propõe que retiremos desses oito outros recursos de alta prioridade que evidenciamos que nossa base de clientes precisa?"

Por fim, como já esperado, não funcionam 80 horas por semana. Você nem está ajudando a empresa fazendo isso porque está apenas ajudando-os a cavar um buraco mais profundo.


2

Não

Tentei fazer disso uma resposta de duas letras e a pilha não me deixou ... mas a resposta é

Não

O que não é completamente verdade se você possui / administra a empresa, é claro. Se você estiver nessa posição, poderá arrastar a equipe de vendas pelos ouvidos e "ter a conversa". Se, no entanto, e como eu suspeito, você é apenas uma pessoa técnica "humilde", seu único recurso é reclamar "UP" da cadeia de comando. Dito isto, minha experiência foi que, nas empresas onde isso acontece, a administração está ciente da situação e não se importa.


2

Mostre a eles esta imagem (ou isso ) e diga que você está trabalhando com um triângulo impossível.

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

Em qualquer projeto, se você corrigir dois cantos desses três:

  • Tempo
  • Escopo
  • Qualidade

... então o terceiro é o único flexível. O que torna impossível são as expectativas. Se eles sempre fixarem o Tempo muito curto e o Escopo muito grande, a Qualidade sempre sofrerá. Em um projeto ágil, todos os três cantos são mais ou menos flexíveis.

(Isenção de responsabilidade: excluo o fator Custo do triângulo tradicional do projeto e coloco a Qualidade no canto. O tempo é o custo em projetos de software.)

Espero que você consiga abrir caminho para um gerenciamento de projetos mais ágil.


2

Algumas respostas muito boas aqui já. Acrescentarei apenas que você não deve ser levado a cumprir os prazos dele em seu próprio prejuízo. Além disso, eu definitivamente gostaria de conversar com o vendedor e lembrá-lo de que, se ele promete demais e a empresa não cumprir suas promessas, ele (e a empresa) não serão confiáveis ​​no futuro, perdendo-lhe futuras comissões (e possivelmente seu trabalho), por isso é de seu interesse ser realista (ou seja, consultar a equipe de programação) para que ele ganhe confiança na empresa. No curto prazo, ele pode ganhar por não ser realista, mas, a longo prazo, perderá prejudicando sua reputação junto a clientes, empregadores e futuros empregadores por meio de más referências.

Quando o pessoal de vendas entender o dinheiro mais do que qualquer outra coisa, fale com ele nesses termos.


1

Com o desenvolvimento Agile, vemos consultores vendendo pontos por ~ 1000-1500 cada. Se você puder alterar o processo de vendas para onde eles devem vender com base na escala de pontos, a equipe de vendas será forçada a trabalhar com a equipe de desenvolvimento para obter estimativas razoáveis.


eles apenas aumentarão o pacote de trabalho por "ponto" (mas não a duração de cada "ponto" em uma iteração) até o ponto em que ele se encaixa no escopo e no orçamento / linha do tempo que eles podem vender.
Jwenting

Os pontos por história são atribuídos pelos desenvolvedores e não pela equipe de Vendas ou Negócios.
precisa saber é o seguinte

1

Tudo se resume a um ponto crítico; Se você acha que não consegue manter o ritmo necessário para cumprir o cronograma prometido pelas vendas, não se comprometa com o trabalho. Se as vendas se comprometerem demais, o problema não é seu, até você concordar com o trabalho. ENTÃO é problema seu. Lembre ao seu chefe que tudo o que os vendedores precisam fazer é dizer sim e eles recebem o cheque; é você quem realmente cumpre as promessas; portanto, se você diz que não vai funcionar, seu chefe deve estar ouvindo. Se você tem a má sorte de ter um gerente que ouve mais a sua força de vendas do que a sua força de desenvolvimento em relação ao que é e o que não é possível, então você tem o PHB do estilo Dilbert e deve atualizar seu currículo.

Essa é uma das razões pelas quais eu gosto do Agile; a equipe de desenvolvimento está envolvida no processo desde as discussões iniciais sobre o design. Você pode calibrar um "ponto" de ambas as extremidades; a equipe de desenvolvimento decide (explícita ou empiricamente) quanto tempo de desenvolvimento é inerente a um ponto, que o gerenciamento pode usar para calcular pontos por semana, pontos por mês, etc., o que leva a uma cifra em dólar. Nesse momento, sua equipe de vendas agora possui números relacionados ao custo e tempo necessários para que os níveis atuais da equipe obtenham a quantidade atual de escopo. Se eles se comprometerem em excesso depois de terem esses números, eles estão fora de si.


Ah, mas os vendedores são hábeis na arte da negociação e os engenheiros não. É por isso que eles estão em vendas e nós estamos em engenharia! Na minha experiência, a maioria das pessoas técnicas apenas acena com a cabeça (não ajuda que as estimativas sejam suscetíveis ao viés de ancoragem ). É realmente difícil para o pessoal técnico dizer que levará mais tempo do que alguém pensa, porque sabe que isso pode ser facilmente transformado em uma reflexão sobre sua capacidade. "Você acha que vai demorar duas semanas? Joe disse que pode fazê-lo em pouco mais de uma."
Scott Whitlock

1
Se Joe disser que pode fazê-lo em pouco mais de uma semana, Joe sofrerá com o trabalho. Se Joe falhar, as vendas aprenderão a preencher suas estimativas. Se Joe conseguir ter sucesso, provavelmente não desejando passar mais 80 horas por semana novamente, ele ajustará suas próprias estimativas. Se nada disso acontecer, Joe será demitido por não cumprir seus compromissos muitas vezes ou se esgotará e sairá do excesso de trabalho. Se você está confiante de que Joe está vendendo demais, chame o blefe. Apenas não seja Joe; não vale a pena (ok, ok, muito raramente vale a pena).
Keiths

O ponto principal da estimativa do Agile é que o preço é justo e o ritmo é sustentável. Essas são coisas que têm valor para um cliente; saber quanto custará REALMENTE, e quanto tempo REALMENTE levará, e que eles receberão o que pediram por esse preço e essa quantidade de tempo valem muito mais do que a promessa de "venceremos qualquer preço" .
Keiths

1

Especifique o trabalho depois que ele for entregue a você e informe-o quanto tempo levará. Então, quando eles cantarem sobre isso, diga a eles.

"Sinto muito que você tenha assumido esse compromisso, mas dados os recursos à minha disposição. Demorará X horas para concluir"

Faça isso toda vez ... funcionou para mim.

Basicamente, diga a eles que eles podem usá-lo Rápido, Barato e Bom, escolha dois.


Rápido e barato?
IAdapter

então isso não me faz bem.
jim

Eu acho que eles não se importam com isso, mas apenas para vendê-lo.
IAdapter

contanto que eles saibam disso ... que assim seja.
jim

2
eles se preocupam sobre ele ser bom, eles só vou culpá-lo para o projeto falhar quando o cliente não está satisfeito ...
jwenting

-1

Na verdade, existe um caminho - um caminho real, não um vazio vazio - mas você pode não gostar.

Ter alguém da equipe de desenvolvimento envolvido no processo de vendas .

Agora, obviamente, você precisa de alguém com boas habilidades de pessoas, alguém com quem o pessoal de vendas não fique mortificado em levar o passeio. E essa pessoa precisa ter um amplo entendimento dos tipos de trabalho que você faz. Eles não precisam ser um ninja de código, apenas precisam de um entendimento leve da codificação em geral e do processo de desenvolvimento em particular, e são razoavelmente bons em estimar o trabalho.

Este é realmente um trabalho para um analista de negócios ou gerente de projetos. Há uma razão pela qual esses empregos pagam tão bem em muitas empresas; eles combinam dois conjuntos de habilidades muito importantes e distintas. Se você não tem um BA ou um PM de verdade, mas tem um desenvolvedor ou arquiteto sênior com habilidades sociais, eles também podem fazê-lo.

Você também precisa fornecer diretrizes claras para o pessoal de vendas. Efetivamente, você (como em sua equipe de desenvolvimento) está enviando alguém para negociar em seu nome. Se você não fornecer nenhum parâmetro, eles apenas negociarão o que lhes parecer bom. É por isso que você sempre dá a eles parâmetros.

Depois de entender o escopo do projeto, trabalhar fora quanto tempo você gostaria de ter para construir, testar, mudanças de escopo, e assim por diante, além de uma certa quantidade de buffer, em seguida, dar-lhes esse número juntamente com um "mínimo autorizado" - o o mais baixo possível, antes de colocar o projeto em grave risco. Espere que eles também diminuam esse número em uma certa quantia; portanto, faça com que seu mínimo seja um pouco mais alto do que realmente precisa.

Tenha certeza de que a gerência deles está fazendo a mesma coisa. O gerente de vendas não deseja que os associados de vendas vendam ofertas não lucrativas. Eles estão entrando em cada negociação com um intervalo de números correspondente à rentabilidade alvo e rentabilidade mínima.

Você pode não ser o gerente deles, mas se você documentar tudo isso por escrito antes mesmo de começar a negociar, estará em uma posição muito mais firme com a alta gerência quando as pessoas começarem a fazer perguntas sobre por que o projeto está atrasado. Mas não se trata apenas de CYA; honestamente, a equipe de vendas não faz ideia de quanto tempo certas coisas levarão, e você está fazendo um favor a elas, fornecendo informações abrangentes.

Outra coisa: não espere que a equipe de vendas envolva sua equipe apenas para o inferno. Você precisa da adesão do gerente de vendas e dos executivos também. Realmente não deve ser muito difícil de obter, se você abordar a partir de uma perspectiva de risco. Você não quer vender o fracasso, não é? Pense no custo para a reputação da empresa. Pense no custo de um processo . Alguém técnico deve fazer parte de qualquer negociação antes que qualquer acordo possa ser assinado.

E se você realmente, honestamente, não pode vender a gerência com base na ideia, posso sugerir que encontre um novo empregador? Porque o seu pode não durar muito mais tempo de qualquer maneira.


-1

Desacordos como esse são normalmente causados ​​por falta de comunicação. Ou eles não entendem a pressão que estão exercendo sobre você ou você não entende o que eles realmente estão pedindo. De qualquer forma, para resolver o problema, você precisa entender a situação do outro ponto de vista.

Você já tentou vender software? Pode não parecer a melhor resposta para muitos desenvolvedores, mas até que você tente, será difícil ver os negócios do lado das vendas. Se você é um ótimo desenvolvedor, escreva algo que realmente deseja escrever e venda. Você pode ver que eles têm alguns pontos válidos ou você pode ver que eles não têm!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.