O que acontece se você não conseguir resolver um problema? [fechadas]

Estou a um ano de me formar na universidade e estou realmente ansioso para resolver problemas práticos. Especialmente não triviais, que exigem um pouco de pesquisa e muito pensamento.

Mas, ao mesmo tempo, esse também é o meu maior medo - enfrentar um problema que não consigo resolver, por mais que eu tente. E, com a pressão para entregar código sobre prazos iminentes ao virar da esquina, parece um pouco assustador ao vê-lo nos playgrounds seguros da universidade (onde a pior coisa que pode acontecer é que você precisa refazer um curso ou exame).

Portanto, para aqueles que estão na indústria há mais tempo, o que aconteceria se lhe dissessem para resolver um problema que não poderia? Isso aconteceu e, se sim, o que aconteceu? Eles simplesmente largaram e disseram "Oh, bem, acho que podemos nos contentar com outra coisa"? Houve consequências? Você foi repreendido ou mesmo demitido?

Primeiro de tudo, seu medo é muito saudável e normal. Aqui estão minhas reflexões após cerca de 15 anos na indústria de software.
Aqui estão algumas perguntas para se perguntar:

1. Você entende o problema?
2. Você sabia que o problema é insolúvel (dentro das restrições de tempo / orçamento)?
3. Você simplesmente não sabe como resolver o problema?
4. Seu cliente / chefe está pedindo o impossível.
5. Vale a pena? (ROI)
6. É um problema REAL ?

1) Antes de tudo, certifique-se de entender o problema. Não há perguntas idiotas. Você entende o que seu cliente / chefe está perguntando contra o que eles precisam?

2) Isso vai acontecer. "Construa uma ponte para mim amanhã" . Certifique-se de saber que um problema é insolúvel dentro de suas restrições. Seu cliente / chefe pode ser flexível quanto ao tempo / orçamento e estes podem ser modificados para oferecer mais tempo / orçamento.

3) Se o problema é compreensível e as restrições estão dentro da razão, e existe uma tecnologia que pode resolvê-lo, mas você simplesmente não sabe o suficiente ... é para isso que StackOverflowserve a Internet. Certifique-se de fazer sua pesquisa primeiro. Tente fazer perguntas explícitas que tenham respostas quantificáveis. Pergunte aos seus colegas. Tenha uma sessão de design.

4) Esta é uma variante da resposta número 2. Parece que seu cliente / chefe está pedindo o impossível. Pesquise. Nunca diga que o problema é insolúvel, a menos que você saiba exatamente o porquê e possa esclarecer.

5) ROI significa retorno do investimento. Isso se refere a um investimento no tempo. Seu tempo!. O problema é importante o suficiente para ser resolvido para garantir a quantidade de tempo que você levará para pesquisar e resolver o problema. Discuta isso com seu cliente / chefe

6) É um problema real. Os clientes, muitas vezes, entendem o que querem, mas não necessariamente entendem o que precisam. Tente entender o que seu cliente / chefe realmente precisa e discuta isso com eles.

Espero que essas diretrizes o ajudem.

Duas coisas para lembrar se você está preso a um problema aparentemente insolúvel:

• Informe outras pessoas que você está preso o mais rápido possível. Isso os ajudará a ajustar a estimativa a tempo, antes que seja tarde demais.

• Se você perceber que uma maneira de resolver um problema não funciona - abandone-a antes de perder muito tempo. Peça ajuda ou tente uma abordagem diferente. Não se trata de provar que você é duro e inteligente, mas de fazer as coisas.

Eu vou para StackOverflow ;)

Mas todos brincando à parte, não temam o desconhecido. Toda a sua carreira estará enfrentando o desconhecido, porque se você já o resolveu, não será um problema da próxima vez.

Vou ter que responder com uma resposta simples: peço ajuda. Assim como outros às vezes me pedem ajuda quando estão presos, tentando encontrar uma solução para alguma coisa.

Editar: devo mencionar que frequentemente encontro a solução apenas descrevendo o problema a um colega de trabalho ou, às vezes, até quando começo a postar uma pergunta em sites como o StackOverflow.

Olhe de diferentes ângulos

Já me deparei com isso muitas vezes, geralmente o que acontece é:

• Você tem um problema, inicialmente você tem uma idéia em sua cabeça como você o resolveria.
• Quando se trata de realmente implementar sua solução, verifica-se que isso não funciona (provavelmente devido ao modelo fraco do problema real).
• Depois de lutar para resolver o problema, faça mais pesquisas ou pergunte aos outros. Nada disso funciona, a pura frustração!

Finalmente, você escolhe o que não quer fazer ->

"O golpe sujo"

Funciona, mas você se sente sujo ...

Normalmente, eu tenho alguém mais esperto que eu para consertar isso. Ele faz e ele é meu chefe. Eu me sinto estúpido. Nós seguimos em frente.

Depende da razão pela qual você é incapaz ...

• logicamente impossível: discuta-o com quem escreveu os requisitos, talvez haja um mal-entendido. Exemplo: em um momento, a especificação diz que o aplicativo deve parecer nativo em todas as plataformas (Windows / Linux / Mac) e, em outro lugar, diz que o programa deve parecer exatamente idêntico em todas as plataformas

• tecnicamente impossível: reavaliar as ferramentas com as quais você está trabalhando, talvez elas não sejam apropriadas. Discuta o problema com seus colegas e o gerente de projeto. Exemplo: requisitos rígidos em tempo real em um ambiente em que a coleta de lixo pode parar a execução por um tempo indeterminado

• desempenho insuficiente: talvez você esteja usando o algoritmo errado, ou talvez o problema seja muito difícil (por exemplo, NP-difícil) e os requisitos não levem isso em consideração. Reavalie o algoritmo que você está usando, talvez haja uma maneira mais rápida. Discuta o problema com seus colegas e o gerente de projeto. Considere mudar para uma heurística suficientemente boa, em vez de um resultado perfeito. Exemplo: otimização de caminho com dezenas ou mesmo centenas de nós

• você simplesmente não sabe como fazê-lo: pergunte aos seus colegas, pergunte ao stackoverflow, pesquise na internet. Entre em contato com o suporte da ferramenta / lib que você está usando. Discuta com o gerente do projeto.

• deve funcionar, mas não funciona, e você não tem idéia do motivo: refatorar o programa para torná-lo mais testável. Considere as condições de corrida, geralmente são o motivo de erros difíceis de encontrar. Peça ajuda aos colegas, quatro olhos vêem mais de dois. Verifique na Internet se há bugs conhecidos nas ferramentas / bibliotecas que você está usando.

Acho que outras pessoas apontam como lidar com isso de maneira profissional. Eu gostaria de dizer como lidar com o sentimento pessoal como frustração, medo.

Bottom line é que você estará bem, mesmo se você não resolver os problemas em tempo hábil. A vida continua.

Às vezes, o cronograma era pressionado. O projeto teria êxito ou falha. Você pode ser demitido e, em seguida, ter um ótimo trabalho. Você nunca sabe.

Não me interpretem mal. Isso não significa que não há problema em deixar o problema lá. Tudo o que podemos fazer é fazer o meu melhor e deixar para lá.

Às vezes, acho que a frustração, o medo de não resolver o problema, é a minha vida como desenvolvedor comum.

Não tenho certeza se diria que não consegui resolver um problema, mas houve casos em que desisti de tentar resolver um problema. Depois de muitas horas tentando consertar um bug ou implementar algum recurso que eu não tenho idéia de como fazê-lo, posso dizer a alguém da minha equipe, líder ou gerente da equipe: "Estou preso a isso. você quer que eu faça? " para que eles saibam onde estou. Eles poderiam dizer: "Continue assim, nós pensamos que você conseguirá" ou "Vá para outra coisa que não é tão importante" ou algumas outras coisas e então eu vou saber o que devo fazer.

Eu tive bugs que não resolvi e alguns recursos que não foram concluídos, com certeza. Embora eu possa tentar fazer algo, nem tudo está ao meu alcance para resolver em um tempo razoável. Um ponto chave nisso é ter comunicação para que seus superiores saibam onde você está.

Dito isto, tive algumas vezes em que tive algumas circunstâncias bastante especiais:

1. Enquanto trabalhava em um grande banco canadense em Toronto, me pediam para fazer todo tipo de coisa que eu não sabia fazer quando recebia a tarefa. Por exemplo, me pediram para testar esse método para proteger laptops, onde as teclas "Esc" e "Enter" foram trocadas na inicialização e, com a sequência correta de teclas, o laptop seria novamente usado, o que parecia bizarro tentar descobrir out, "Isso funcionaria? Como eu sei se isso seria ou não aceitável para os usuários?" Havia outras tarefas em que eu simplesmente não tinha o hardware ou outros recursos para fazê-lo. Ao mesmo tempo, foi bastante educativo, pois isso me deu muitas coisas para anotar em qualquer situação futura de emprego para evitar problemas. Coisas como garantir quando sou pago, como meu tempo é monitorado,

2. Enquanto trabalhava em um provedor de serviços de aplicativos em Calgary, recebi esse projeto de tentar criar uma cópia de outro site em nosso aplicativo interno que vendemos como serviço. Um ponto importante aqui é que não recebi uma linha do tempo ou sugestões sobre qual parte fazer primeiro, apenas uma pesquisa geral e, um mês depois, me pediram uma demonstração, pois estava tendo uma reação ruim a algum medicamento para dor. Essa reação durou uma semana em que eu saí do trabalho de repente e, na semana seguinte, fui a um evento da Microsoft que foi a última gota quando fui demitido no dia seguinte. Algo a ser observado aqui é como eu mantive um relacionamento bastante ruim com meu chefe, pois sempre que ele se aproximava da minha área meu pensamento imediato era: "Agora, o que há de errado?"

Como já foi dito, a comunicação é fundamental - informar às pessoas (quem será impactado) quando você está parado: seu chefe, membros da equipe, clientes etc.

Certa vez, um colega de trabalho afiado incutiu em mim que o sucesso tem raízes em duas coisas:

1. Relacionamentos
2. Expectativas

Ter um bom relacionamento, suponho, é uma função da boa comunicação e do estabelecimento de expectativas antecipadamente.

Sigo o princípio da Polya:

"Se há um problema que você não pode resolver, há um problema mais fácil que você não pode resolver: encontre-o."

George Polya

A vantagem do princípio é que, em algum momento, haverá um problema pequeno o suficiente e você poderá resolver o que, esperançosamente, se você fez as coisas corretamente, permitirá que você inicie uma solução para o problema original. Este princípio ainda não me falhou.

As respostas " procurar ajuda " estão definitivamente corretas. É altamente improvável que você seja a primeira pessoa a encontrar um problema específico.

Mas como um experimento, e se não houver ajuda? E se você precisar resolver o problema sozinho? A capacidade de resolução de problemas mais importante é a capacidade de identificar e desafiar suas próprias suposições . Se você puder enumerar suas suposições sobre um problema, uma por uma, e eliminar cada uma delas, acabará encontrando a suposição incorreta e novas possibilidades para uma solução se abrirão como resultado.

(A propósito, essa também é a melhor abordagem quando você não consegue ver a resposta para um problema que obtém em uma entrevista de emprego. Liste verbalmente suas suposições e determine qual delas está errada e depois ataque novamente o problema. Quase todas as "perguntas complicadas" são baseadas em suposições naturais, porém erradas).

Pedir ajuda é realmente a melhor resposta, mas aqui está um pouco mais que pode ser útil.

Portanto, para aqueles que estão na indústria há mais tempo, o que aconteceria se lhe dissessem para resolver um problema que não poderia? Isso aconteceu e, se sim, o que aconteceu? Eles simplesmente largaram e disseram "Oh, bem, acho que podemos nos contentar com outra coisa"? Houve consequências? Você foi repreendido ou mesmo demitido?

Sim, aconteceu comigo e não, nunca fui repreendida ou demitida por isso, porque ...

Na indústria, tudo se resume a resolver problemas dentro do prazo e do orçamento, e os gerentes decentes entendem que isso nem sempre é possível.

O que realmente acontece é que seu gerente diz: "Eu gostaria que você fizesse o X, o que você acha que será necessário?" E você pode dar muitas respostas. Os bons incluem:

• Fiz algo realmente semelhante a isso, então acho que levará três semanas e US $ 3.000 em testes de hardware.
• Eu tenho algo geralmente semelhante a isso. Então deixe-me pensar sobre isso e voltar para você esta tarde.
• Eu nunca fiz nada assim. Então, deixe-me pesquisar e voltar para você amanhã.
• Ninguém no planeta jamais fez isso. Se você quiser investigar, levarei duas semanas para fazer experiências suficientes para fazer uma estimativa.

O trabalho do gerente é decidir se e como proceder. Se eles optarem por continuar, é seu trabalho atender às suas estimativas ou informar o gerente se houver algum impedimento. Enquanto você fizer isso, em uma empresa razoável, não haverá consequências negativas.

Obviamente, também existem empresas irracionais que não fornecem tempo ou recursos para você fazer seu trabalho. Já trabalhei em alguns deles e todos receberam problemas que não podiam ser resolvidos dentro das restrições da empresa. Um deles demitiu cerca de 98% da equipe de programação em oito meses, e isso certamente foi uma consequência, mas não foi pessoalmente direcionado a mim, e ainda considero meu chefe e seu chefe bons amigos.

Existem muitos tipos diferentes de problemas nos quais você se depara e muitos têm maneiras diferentes de lidar com eles.

Um tipo de problema é implementar algo que você nunca viu antes, como uma API de som estranho ou algo assim. Nesse caso, eu perguntaria sobre o SO, sério.

Outro é um problema muito grande para resolver. Esse tipo de problema pode ser abordado iterativamente. Eles dizem "Implementar Humongous". Você o examina e escreve os passos que conseguir descobrir. Então você divide as etapas complicadas em etapas menores. À medida que você é forçado a pensar em etapas menores, elas se tornam mais claras. Se você encontrar uma dificuldade técnica, tente uma implementação de teste e pergunte aqui, se necessário.

Um dos problemas mais irritantes são solicitações mal especificadas. Eles só querem algo que faça "x" e não digam como deve ser feito. Para eles, uma boa abordagem é criar um protótipo de uma interface (normalmente uma GUI) e deixar alguém brincar com ela.

Existem restrições de tempo que não podem ser atendidas. Isso geralmente envolve modificar as expectativas e fornecer protótipos funcionais.

Você geralmente encontrará seu caminho através das coisas de uma maneira ou de outra. É assustador, mas uma vez que você está nele, pode sempre encontrar alguma maneira de fazê-lo.

Sua melhor aposta pode ser pintar as palavras "Não entre em pânico" na parte externa do seu laptop. E não esqueça sua toalha.

Minha sequência de solução de problemas (todo próximo spet é realizado apenas se o anterior não funcionar):

1. Tente pesquisar no google
2. Pergunte a alguém
3. Pesquisar SO diretamente (ignorando o Google)
4. Pensar
5. Fumaça (== cabeça limpa)
6. Faça uma pergunta sobre SO
7. Espere até de manhã (== cabeça limpa ainda mais)
8. Use esse truque sujo e sinta-se mal comigo mesmo :(

Problemas desagradáveis ​​são resolvidos nas etapas 5-6.

Problemas realmente muito ruins geralmente precisam de algum tempo (a etapa 7 é a solução para a maioria dos problemas de 'parece que eu não posso fazer nada'). E eu quero dizer isso - mude para outra tarefa pelo resto do dia e tente resolver o problema logo de manhã. Isso faz maravilhas.

E só então vem o passo 8.

Eu nunca ouvi falar de nada acontecendo assim. Antes de tudo, você nunca recebe um problema que não pode ser resolvido. O problema pode ser difícil e pode demorar para ser resolvido. Quando houver um problema, você precisará informar que esse é o tempo que exigirei. Se em sua pesquisa você acha que esse problema realmente não pode ser resolvido, é preciso levantar uma bandeira e informar ao gerente que esse problema levará mais tempo ou que é realmente difícil de resolver. É tudo sobre o cronograma. Se você promete algo e não será capaz de entregar, então é problema. Mas se você continuar dizendo seu status e preocupações, é responsabilidade do gerente cuidar disso. Ele deve redirecioná-lo para a pessoa adequada que pode ajudar ou ajustar a programação.

Há ótimos conselhos aqui! Meus dois centavos valem; Não fique impressionado com o GRANDE problema, não se esqueça de que a parte empolgante e desafiadora de resolver um problema é dividi-lo em uma série de subproblemas gerenciáveis ​​e mais importantes, compreensíveis, que por sua vez se dividem repetidamente em pequenos sub-problemas. Qualquer bom programador normalmente faz isso minuto a minuto enquanto cria código (usando funções, métodos, sub-rotinas etc. para ajudar a reduzir a complexidade geral de uma seção do código) e essa metodologia geralmente se aplica a qualquer GRANDE problema que você rosto na vida (não apenas no trabalho).

Depende de qual é o problema específico, obviamente. Mas a resposta pode ser uma das seguintes:

1. Encontre uma solução alternativa / substituição
2. Compre uma solução comercial que se aproxime do que você deseja
3. Não desista e continue trabalhando o tempo que for necessário até ter sucesso .

O número 3 pode exigir uma folga do problema e revisá-lo semanas ou meses depois. Isso geralmente ajuda.

Na minha experiência, às vezes há problemas que você não pode resolver, pelo menos na restrição de tempo. Portanto, procure ajuda o mais rápido possível, depois de algum esforço para solucionar o problema .

Lembre-se da regra de ouro: sempre observe o motivo pelo qual o chefe o contrata. Faça o que achar que pode fazer para obter o melhor resultado do trabalho e, às vezes, esse é um relatório de falha antecipada (muito melhor que o final).

Em resumo, se você acha que pode encontrar a solução, sinta-se à vontade para tentar, mas faça uma estimativa ao seu chefe sobre o risco e o custo do tempo. É problema deles agora.

Se projetos de cem milhões de dólares podem falhar, mesmo com pessoas experientes, não se preocupe, pois ainda é um estudante. Eu tive um problema para resolver e descobri que, se é algo em que você fica preso - deve registrar todas as tentativas feitas para resolvê-lo.

Isso ajuda:

1. Prova de tentativas feitas para resolver um problema.
2. A gravação desse tipo de falha é importante para que você aprenda com ela e não a faça novamente alguns dias depois, pensando que funcionará.

Minha experiência é que um recém-formado não é jogado nas profundezas. Em vez disso, você provavelmente fará parte de uma equipe que também inclui desenvolvedores experientes.

Meu conselho seria: faça uso deles. Quando não tiver certeza de como lidar com um problema ou se quiser saber se sua solução está indo na direção certa, discuta isso com eles. E se você sentir que está preso em algum lugar, pegue um dos caras experientes, explique seu problema e peça ajuda.

Na maioria das vezes, apenas a explicação do seu problema revelará uma solução e a explicação da solução poderá igualmente revelar falhas nele.

Muitas vezes isso acontece porque você não definiu o problema de maneira adequada e precisa. Talvez você esteja tentando resolver uma solução preconcebida em vez do próprio problema real.

O problema é apenas o que você observa, não o que você imagina.

"Meu maldito carro não liga" é um problema. "A bateria está descarregada." é uma solução preconcebida para o problema de partida do carro. Mesmo testando a bateria não prova que é a única causa do problema. A menos que você tenha realmente recarregado ou substituído a bateria e iniciado o carro com êxito, não há provas de que a bateria seja a causa do problema.

Simplifique e continue simplificando. Divida em partes pequenas. Se você não conseguir resolver essas partes, esmague-as. Você se sentirá melhor. Em seguida, divida-o em diferentes partes pequenas. Cada uma dessas partes deve ser um fenômeno observável.