Parece que estou repetidamente preso a uma situação em que as datas de lançamento não são baseadas 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 aqui está a data de lançamento comprometida", e é difícil argumentar, porque neste momento há dinheiro circulando, e isso supera tudo.
Em geral, há uma maneira de fazer isso? Se não fosse essa versão, que tal no futuro? O problema que tenho é que a única maneira de ver uma maneira de fazer isso é fazendo o melhor que posso, mas libero o software 'como está', por assim dizer.
Eu não quero lançar software repleto de bugs, pois é o meu nome em anexo, mas fazer 80 horas semanais por meses de cada vez justifica a data de lançamento arbitrariamente definida.
edit: para o registro, eu não estou fazendo 80 horas semanais agora, apenas isso vem à mente como o que seria necessário para cobrir o recurso esperado definido pela data de lançamento.
Pare de fazer as 80 horas semanais. Isto é reforço positivo . Porque eles estão recebendo o produto no prazo com os custos esperados, eles vão continuar a fazê-lo, independentemente do que ele faz para você.
Se eles não podem orçar o tempo adequadamente, então isso é culpa da administração. Não é seu.
Deixe-os perder alguns prazos.
In general, is there a way to push back on this? If not for this release, what about in future?
Claro, há: Deixe-os falharem com esta abordagem. Nada ensina nem falha.
Faça uma estimativa antes de começar e mostre-a para eles. Então faça o seu melhor, escreva um bom código, pare compensando pela estupidez com o seu tempo livre, e quando eles reclamarem depois, lembre-os da estimativa de tempo mostrada, com base nos princípios de engenharia.
E é melhor você começar a fazer isso com o projeto atual .
Se eles continuarem a culpá-lo pelo problema, é melhor você 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 esta pergunta realmente garante um link para a famosa história da EA como destaque em um dos livros de Joel: EA: a história humana .
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 com base no salário. Os vendedores têm várias alavancas para trabalhar: recursos, custo e data de entrega. Eles têm um strong desincentivo para reduzir o custo, porque isso geralmente reduz sua comissão, então eles tendem a aumentar os recursos e a data de entrega (em termos de ser mais cedo). Eles vão empurrar os mais altos que puderem, a fim de fechar o negócio.
Experimente e veja do ponto de vista deles, só por um momento. Eles têm uma família para alimentar também - e se a diferença entre fechar uma venda na qual venho trabalhando há meses é apenas cortar algumas semanas da programação, então é uma tentação incrível, especialmente se eu não realmente entende o que isso significa.
A tentação é dizer "sempre foi assim e sempre assim será". Mas um lugar em que trabalhei pelo menos teve uma solução PROPOSTA, se não implementada ... um gerente finalmente ergueu as mãos e disse: "Se as horas extras dos programadores estão sendo usadas para fechar uma venda, elas devem receber uma porção de a Comissão." Ele não foi implementado, mas teria alinhado os incentivos de todos mais de perto ... os programadores teriam ficado emocionados ao ouvir sobre um novo recurso que teve que sair em breve, porque eles estariam antecipando a comissão, e o os vendedores estariam MENOS aptos a criar essas circunstâncias, porque eles seriam menos propensos a trabalhar a seu favor.
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, então um de seus gerentes de linha precisa defender a equipe de desenvolvimento. Se eles são parte do problema, então você pode querer considerar outras opções de emprego.
Em geral, as vendas não devem se comprometer com nada sem a aceitação da Gerência de Produto, que obviamente deve estar consultando a equipe de desenvolvimento para os cronogramas. 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 de subfornecimento (seja em qualidade ou escopo).Isso é quase uma coisa universal em empresas menores, pois elas têm uma necessidade maior de fechar um acordo. Até que fui trazido para as reuniões de vendas na minha empresa, fiquei amargurado com isso, mas posso pelo menos entender como e por que isso acontece um pouco mais.
Os clientes querem rápido e muitos vão jogar duro para conseguir. Isso incentiva as vendas a dobrar em compromissos de tempo apenas para conseguir 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 se trabalhar.
Outras vezes, se é um mercado quente e há muitos concorrentes, então a empresa tem uma necessidade iminente de ter um produto mais rápido do que todo mundo. Uma empresa maior ou com mais capital pode sempre contratar mais recursos, e uma menor não pode.
Onde é scummy é quando os prazos são verdadeiramente artificiais e é empurrado por vendas e gestão para garantir grandes bônus para si.
Não crie o hábito de trabalhar mais de 45 horas por semana, é ruim para sua saúde e é o que vem primeiro.
Eu trabalhei nos dois lados da casa. Lembre-se de que, sem pessoal de vendas, não haveria empregos ou projetos a jusante.
Como combater o excesso de comprometimento de vendas : estimar e, em seguida, usar pelo menos um múltiplo de 130% (planeje sempre uma contingência mínima de 30%). Forneça e documente a estimativa. Perceba que suas estimativas de esforço serão reduzidas no processo de vendas. Tudo bem, basta que a gerência esclareça o contrato de licença / vendas / comissão qualquer redução dessas horas. Se você é uma empresa pública, isso é complicado com VSOE , mas até você atingir o pessoal de vendas com responsabilidade por contrato antecipadamente durante o processo de vendas, ele se tornará a sua responsabilidade mais tarde.
Existem muitas estratégias que você pode usar, mas geralmente você precisa de aprovação ou adesão da gerência.
Pague horas extras aos desenvolvedores a uma taxa maior. Trabalhar horas extras não é tão ruim quando você está ganhando muito dinheiro fazendo isso. E se isso começar a afetar o gerenciamento da linha de base da empresa, pressionaremos as vendas para fazer uma estimativa de trabalho melhor.
Pague os vendedores com base no lucro, em vez de nas vendas brutas. Cada hora de trabalho que eles não incluem em sua estimativa afeta negativamente sua comissão.
Limite o número de horas que os desenvolvedores podem trabalhar para 40 (ou qualquer que seja a semana padrão de trabalho em sua parte do mundo).
Faça o pessoal de vendas trabalhar a cada hora que os desenvolvedores trabalham. Se eles querem que você trabalhe horas extras para realizar o projeto, eles também precisam estar lá. Encontre algo útil para eles, como escrever documentação ou produzir cópias com caligrafia, iluminadas à mão de Padrões de Design e A Biblioteca de Modelos Padrão C ++ .
Os desenvolvedores devem estimar cada trabalho em vez de permitir que os vendedores o façam. Pelo menos desta forma você tem alguma habilidade para tornar o cronograma mais razoável. Esta não é uma ótima solução, embora ... os desenvolvedores geralmente sejam péssimos em estimar o trabalho necessário. Mesmo que a estimativa seja razoável, eventos imprevistos podem impedir que você atinja seu alvo. 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 ciclos de desenvolvimento curtos que os defensores do Agile defendem.
Adote a abordagem "ágil" e recuse-se a se comprometer. Ser ágil exigirá muito mais envolvimento do cliente, mas também pode dar ao cliente mais flexibilidade, porque eles não precisam necessariamente se comprometer com a forma final do projeto. As vendas podem não ser felizes com isso no começo, mas podem mudar de tom quando perceberem que pode oferecer muitas oportunidades de vender mais trabalho.
Acho que a solução menos atraente é qualquer coisa que faça a equipe de vendas parecer ruim aos olhos dos clientes em potencial. A equipe de vendas é o rosto da empresa. Fazê-los com aparência ruim prejudica toda a empresa, e pode não resolver o problema - eles podem achar que precisam fazer um negócio ainda melhor para o cliente, a fim de recuperar a confiança.
Já existem muitas sugestões sensatas nas respostas, o que, esperamos, pode ajudar a resolver este relacionamento disfuncional. Mas no final, você decide quanto quer trabalhar.
É fácil ser pressionado por colegas de trabalho para o excesso de trabalho. Mas você está sacrificando sua vida pessoal quando você faz isso.
Veja o que você pode fazer:
Saí do meu último emprego porque sempre trabalhei horas extras e sempre fui solicitado a trabalhar mais. Eu disse a eles claramente na minha entrevista de saída que eu gostava de muitas coisas sobre o trabalho, mas não vi nenhum fim para as horas extras à vista.
Eu também expressei claramente esse desejo em minha entrevista para o meu novo trabalho, 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á encontrando dificuldades para recrutar esses dias, porque eles têm uma reputação de excesso de trabalho. Talvez o custo extra de recrutar e treinar lhes ensine uma lição. Mas se não, não é problema meu.
Primeiro, vamos lembrar que todos nós geralmente temos empregos para apoiar os negócios que os vendedores fazem, em vez de construir uma arte de programação tecnicamente perfeita. Se eles não fizerem as ofertas, você não terá emprego.
O truque é encontrar maneiras de trabalhar com as vendas para que todos pareçam bem. Processos em que a equipe de tecnologia pode, pelo menos, expressar uma opinião sobre as propostas antes de saírem pela porta são fundamentais. Encontrar maneiras criativas de lidar com a compensação também ajuda muito - se as vendas tiverem que "desviar" a engenharia quando a engenharia incorre em horas extraordinárias, fazendo um cronograma irreal, parece reduzir drasticamente a frequência dos projetos de marcha da morte.
Isso é algo que você precisa levar para o seu gerente (há gerentes de desenvolvimento, certo?) e explicar o problema. É uma mudança que precisa acontecer em um nível organizacional - as vendas precisam ser compradas do desenvolvimento antes de assumir compromissos, e antes que isso aconteça, elas precisam obter essa direção de seus chefes.
Não há nada que você possa fazer para realmente fazer a mudança acontecer, mas você definitivamente deve trazê-la ao seu gerente.
Além de tentar mudar a cultura (boa sorte), sempre que chegarem até você com um prazo que você não pode cumprir, retroceda - com números. Divida o projeto e mostre a sua estimativa de tempo. Se é um projeto de seis semanas, diga a eles. Se foi prometido ao cliente em quatro semanas, você não pode fazê-lo, e você precisa divulgar essa informação o mais rápido possível. Espero que seus vendedores possam voltar ao cliente e definir melhores expectativas, ou trabalhar com você para criar um conjunto de recursos aceitável menor para entregar dentro do prazo prometido, com os recursos adicionais a serem adicionados posteriormente.
Editar para adicionar: não deixe que eles informem sua estimativa. Tenha certeza de que está correto e cumpri-lo. Eles irão tentar barganhar com você, mas não os deixe.
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 aparecerem e fazer você parecer mal.
Mas diga claramente à sua gerência que toda vez que você tiver que fazer mais de 40 horas por semana para realizar um trabalho, todos os envolvidos no projeto devem se sentar em um quarto após o produto ser entregue , descobrir o que deu errado e o que podemos fazer para impedir que isso aconteça novamente. Ou, melhor ainda, todos os projetos devem ter uma retrospectiva para discutir o que correu bem e o que deu errado.
Se você está certo e seus vendedores estão supercomprometidos, isso ficará muito claro muito rapidamente. Mas não se antecipem à conclusão e não sejam adversários antes do fato. Fale sobre isso em termos de coisas que sua equipe pode fazer para entregar no prazo 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.
Não há absolutamente nenhuma maneira de combater isso completamente. A própria natureza das vendas é excessiva. Como um representante de vendas, você está lá para fazer com que os problemas do cliente em potencial desapareçam magicamente. Bons representantes de vendas irão apenas exagerar um pouco, os maus causarão grande constrangimento.
Qualquer coisa que você fizer só causará agravamento ou tensão entre as pessoas do produto e o pessoal de vendas (pelo menos). Você pode se esforçar muito para evitar gafes realmente ruins por parte de seus representantes de vendas, mas no final do dia os representantes de vendas e de vendas são pagos da mesma conta bancária. Sua empresa terá sucesso ou fracassará como uma unidade, então iniciar uma guerra civil com vendas não ajudará.
Se você tiver um ou mais representantes de vendas que habitualmente se envergonham, a gerência de vendas resolverá o problema. Como desenvolvedor, você não vai ter o poder de fazer nada sobre isso, então você deve se concentrar em entregar o melhor produto possível com o tempo e os recursos que eles lhe dão.
É difícil responder sem conhecer a estrutura da sua empresa.
Algumas ferramentas gerais para ajudar são:
Ao concordar com controles de qualidade , você tem um motivo de negócios para não ser capaz de liberar software com bugs. Você pode precisar convencer seus chefes por que isso é importante (espero que não), mas há muita literatura disponível para ajudar nisso.
Ao ter um roteiro de produtos , as Vendas sabem o que podem ou não 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 isso.
Se eles prometem algo para um cliente que ainda não tenha concordado, azar. Espero que seu roteiro seja baseado em dados de mercado sobre as necessidades dos clientes. "O que exatamente você propõe que abandonemos esses outros oito recursos de alta prioridade que temos evidências de que nossa base de clientes precisa?"
Por último, como já esperado, não trabalhe 80 horas por semana. Você nem está ajudando a empresa fazendo isso porque está apenas ajudando-os a escavar um buraco mais profundo.
Não
Eu tentei fazer uma resposta de duas letras e a pilha não me deixou ... mas a resposta é
Não
O que não é totalmente verdade se você possui / administra a empresa, é claro. Se você estiver na posição , poderá arrastar a equipe de vendas pelos ouvidos e "conversar". Se, no entanto e como eu suspeito, você é apenas uma pessoa técnica "humilde", seu único recurso é reclamar "CIMA" a cadeia de comando. Dito isto, minha experiência tem sido que, nas empresas em que isso acontece, a gerência está ciente da situação e não se importa.
Mostre a eles esta imagem (ou esta ) e diga a eles que você está trabalhando com um triângulo impossível .
·-----------------------·
/ \ \
· \ ·-------------------·
\ \ \ /
\ \ \-----------· /
\ \ \ / / /
\ \ \ / / /
\ \ \ / / /
\ \ / / /
\ \ / / /
\ · / /
\ / /
\ / /
\ / /
·---·
Em qualquer projeto, se você corrigir dois cantos destes três:
... então o terceiro é o único flexível. O que torna impossível é as expectativas. Se eles sempre corrigirem 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 faço a Qualidade O canto é o custo em projetos de software.)
Espero que você consiga chegar a um gerenciamento de projetos mais ágil.
Algumas respostas muito boas aqui já. Vou apenas acrescentar que você não deve ser obrigado a cumprir seus prazos em seu próprio prejuízo. Além disso, eu definitivamente teria uma palavra com o vendedor e lembraria que se ele prometer demais e a empresa não puder cumprir suas promessas, ele (e a empresa) não será confiável no futuro, perdendo comissões futuras (e possivelmente o seu trabalho), por isso é do seu interesse ser realista (consultar o pessoal de programação) para que ele ganhe confiança na empresa. A curto prazo, ele pode ganhar por ser irrealista, mas a longo prazo ele vai perder por prejudicar sua reputação com clientes, seu empregador e futuros empregadores através de referências ruins.
Como as pessoas de vendas entendem o dinheiro mais do que qualquer outra coisa, fale com ele nesses termos.
Com o desenvolvimento Agile, vemos consultores vendendo pontos por ~ 1000-1500 cada. Se você puder alterar o processo de vendas para onde eles têm que vender com base na escala de pontos, a equipe de vendas será forçada a trabalhar com a equipe de desenvolvimento para chegar a estimativas razoáveis.
Tudo se resume a um ponto crítico; Se você acha que não consegue sustentar o ritmo necessário para cumprir o cronograma prometido, não se comprometa com o trabalho. Se as vendas prometem demais, não é problema seu, até você concordar com o trabalho. Então é problema seu. Lembre o seu chefe que todos os vendedores têm que fazer é dizer sim e eles recebem o cheque; você é quem realmente cumpre as promessas, então se você disser que não vai funcionar, seu chefe deve estar ouvindo. Se você tem a má sorte de ter um gerente que ouve sua força de vendas mais do que sua força de desenvolvimento sobre o que é e o que não é possível, então você tem o PHB do estilo Dilbert, e você deve estar atualizando seu currículo.
Essa é uma das razões pelas quais gosto de Agile; a equipe de desenvolvimento está envolvida no processo desde as discussões iniciais de design. Você pode calibrar um "ponto" de ambas as extremidades; a equipe de desenvolvimento decide (de forma explícita ou empírica) o quanto as horas-homem de desenvolvimento são inerentes a um ponto, que a gerência pode usar para calcular pontos por semana, pontos por mês etc., o que leva a um valor em dólar. Nesse ponto, sua equipe de vendas agora tem números relacionados ao custo e ao tempo necessários para que os atuais níveis da equipe recebam a quantidade atual de escopo. Se eles superpromissem uma vez que tenham esses números, eles estão fora de si.
Especifique o trabalho depois que ele for entregue a você e informe-o quanto tempo levará. Então, quando eles cantam sobre isso, diga-lhes.
"Sinto muito que você tenha assumido esse compromisso, mas, com os recursos à minha disposição, levará X horas para ser concluído"
Faça isso toda vez ... funcionou para mim.
Basicamente diga-lhes que eles podem ter Rápido, Barato e Bom, escolha dois.
Existe realmente um caminho - um caminho real, não uma platitude vazia - mas você pode não gostar disso.
Peça a alguém da equipe de desenvolvimento envolvido no processo de vendas .
Agora, obviamente, você precisa de alguém com boas habilidades pessoais, alguém com quem os vendedores não ficarão mortificados por levar o passeio. E essa pessoa precisa ter um amplo entendimento dos tipos de trabalho que você faz. Eles não precisam ser um código ninja, eles só precisam de um entendimento moderado da codificação em geral e do seu processo de desenvolvimento em particular, e ser razoavelmente bons em estimar o trabalho.
Este é realmente um trabalho para um analista de negócios ou gerente de projeto. Há uma razão pela qual esses empregos pagam tão bem em muitas empresas; eles combinam dois conjuntos de habilidades muito importantes e distintos. Se você não tem um BA ou PM real, mas tem um desenvolvedor sênior ou um arquiteto com habilidades sociais, eles também podem fazer isso.
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 lhes der nenhum parâmetro, eles apenas negociarão o que parece bom para eles. É por isso que você sempre lhes dá parâmetros.
Depois de entender o escopo do projeto, calcule quanto tempo você gostaria ter para construir, testar, alterar o escopo e assim por diante, além de uma certa quantidade de buffer. número junto com um "mínimo autorizado" - o menor que eles podem possivelmente ir antes de colocar o projeto em grave risco. Espere que eles reduzam esse número em uma certa quantidade também, então faça o mínimo um pouco maior do que realmente precisa ser.
Tenha certeza de que o gerenciamento deles está fazendo a mesma coisa. O gerente de vendas não deseja que os associados de vendas vendam transações não lucrativas. Eles estão entrando em cada negociação com uma série de números que correspondem à meta de lucratividade e rentabilidade mínima.
Você pode não ser o gerente deles, mas se você documentar tudo isso por escrito antes eles começarão a negociar, então você estará mais firme na alta administração quando as pessoas começarem a fazer perguntas sobre porque o projeto está atrasado. Mas não é apenas sobre o CYA; a equipe de vendas honestamente não tem ideia de quanto tempo certas coisas levarão, e você está fazendo um favor ao fornecer informações abrangentes.
Uma outra coisa: não espere que a equipe de vendas envolva sua equipe apenas por isso. Você também precisa do buy-in do gerente de vendas e dos executivos. Realmente não deveria ser muito difícil de conseguir, se você abordar isso 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 conseguir vender a gerência sobre a ideia, então sugiro que encontre um novo empregador? Porque o seu pode não estar por aqui por mais tempo.
Desentendimentos como esse são normalmente causados por falta de comunicação. Ou eles não entendem a pressão que estão colocando em você ou você não entende o que eles realmente estão pedindo. De qualquer maneira, 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ê tenha tentado, será difícil ver o negócio do lado da venda. Se você é um grande desenvolvedor, escreva algo que realmente queira escrever e vender. Você pode ver que eles têm alguns pontos válidos ou você pode ver que eles não têm!