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

1. Você entende o problema?
2. Você sabe que o problema é insolúvel (dentro de suas restrições de tempo / orçamento)?
3. Você 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 mais nada, certifique-se de entender o problema. Não há perguntas idiotas. Você entende o que seu cliente / seu chefe está perguntando versus o que eles precisam?

2) Isso vai acontecer. "Construa-me uma ponte até amanhã" . Certifique-se de que você saiba que um problema é insolúvel dentro de suas restrições. Seu cliente / chefe pode ser flexível no tempo / orçamento e estes podem ser modificados para lhe dar mais tempo / orçamento.

3) Se o problema é compreensível e as restrições estão dentro da razão, e há tecnologia que pode resolver o problema, mas você não sabe o suficiente ... é para isso que o StackOverflow e a Internet servem. 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 como seu cliente / chefe está pedindo o impossível. Pesquise. Nunca diga que o problema é insolúvel, a menos que você saiba exatamente por quê e possa esclarecer.

5) ROI significa Return On Investment. Isso se refere a um investimento no tempo. Seu tempo!. O problema é importante o suficiente para resolver o tempo necessário 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 ajudem você.

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

• Deixe que outras pessoas saibam 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, desista antes de perder tempo demais. Peça ajuda ou tente uma abordagem diferente. Não se trata de se mostrar duro e inteligente, é sobre fazer as coisas.

Eu vou para StackOverflow ;)

Mas tudo brincadeira à parte, não tenha medo do desconhecido. Toda a sua carreira estará enfrentando o desconhecido, porque se você já resolveu, não será um problema da próxima vez.

Vou ter que ir 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 algo.

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

Veja de diferentes ângulos

Eu já vi isso várias vezes, geralmente o que acontece é:

• You have a problem, initially you have an idea in your head how you would solve it.
• When it comes to actually implementing your solution, it turns out that is doesn't work (probably due to the weak model of the actual problem).
• After struggling to solve the problem, be it more research or asking others. None of it works, the pure frustration!

Finalmente, você opta pelo que não queria fazer - >

"O hacker sujo"

Funciona, mas você se sente sujo ...

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

Depende do motivo pelo qual você não consegue ...

• logicamente impossível: Discuta com quem escreveu os requisitos, talvez haja um mal-entendido. Exemplo: em um ponto, a especificação diz que o aplicativo deve parecer nativo em todas as plataformas (Windows / Linux / Mac), e em outro lugar, ele diz que o programa deve ser 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 projetos. Exemplo: requisitos rígidos em tempo real em um ambiente onde a coleta de lixo pode interromper 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 levam isso em consideração. Reavaliar o algoritmo que você está usando, talvez haja um caminho mais rápido. Discuta o problema com seus colegas e o gerente de projetos. Considere mudar para uma heurística suficientemente boa em vez de um resultado perfeito. Exemplo: otimização de caminhos com dezenas ou até centenas de nós

• você simplesmente não sabe como fazer isso: 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 de projeto.

• ele deve funcionar, mas não funciona, e você não tem idéia do porquê: refatorar o programa para torná-lo mais testável. Considere as condições de corrida, eles são muitas vezes a razão para erros difíceis de encontrar. Peça ajuda aos colegas, quatro olhos vêem mais de dois. Verifique na internet os erros conhecidos nas ferramentas / libs que você está usando.

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

A linha inferior é que você será FINE mesmo se você não resolver problemas em tempo hábil. A vida continua.

Às vezes, o cronograma seria enviado. O projeto seria bem sucedido ou não. Você pode ser demitido e ter um ótimo emprego. Você nunca sabe.

Não me entenda mal. Isso não significa que não há problema em deixar o problema estar lá. Tudo o que podemos fazer é dar o melhor de mim e deixá-lo ir.

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

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 passar muitas horas tentando consertar um bug ou implementar algum recurso que eu não tenho idéia de como fazê-lo, eu posso dizer a alguém da minha equipe, líder de equipe ou gerente: "Eu estou preso nisso. O que você quer que eu faça? " para que eles saibam onde eu estou. Eles poderiam dizer: "Continue assim, achamos que você conseguirá" ou "Siga em frente para algo que não é tão importante", ou algumas outras coisas, e então eu saberei o que deveria estar fazendo.

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

Dito isso, tive algumas ocasiões em que me deparei com algumas circunstâncias especiais:

1. Enquanto trabalhava em um grande banco canadense em Toronto, eu seria solicitado a fazer todos os tipos de coisas que eu não sabia como fazer quando me deram a tarefa. Por exemplo, me pediram para testar esse método para proteger laptops onde as teclas "Esc" e "Enter" eram trocadas na inicialização e com a sequência de teclas correta o laptop seria utilizável novamente e parecia estranho tentar descobrir Fora, "Isso funcionaria? Como eu sei que isso seria ou não estaria bem com os usuários?" Havia outras tarefas que eu simplesmente não tinha o hardware ou outros recursos para fazê-lo. Ao mesmo tempo, foi bastante educativo, já que isso me deu muitas coisas a serem anotadas em qualquer situação futura de emprego para evitar problemas. Coisas como garantir quando eu pago, como meu tempo é rastreado e outros problemas de comunicação foram ilustrados com grande detalhe aqui que eu realmente não esqueci.

2. Enquanto trabalhava em um Application Service Provider em Calgary, recebi este projeto de tentar criar uma cópia de outro site dentro de nosso aplicativo interno que vendíamos como um serviço. Um ponto chave aqui é que eu não recebi uma linha do tempo ou sugestões sobre qual parte fazer primeiro, apenas pesquisa geral e um mês depois me pediram uma demo assim que eu estava tendo uma reação ruim a algum analgésico. Essa reação durou uma semana que eu tirei o trabalho de repente e, na semana seguinte, fui a um evento da Microsoft que foi meio que a última gota quando fui demitido no dia seguinte. Algo a se notar aqui é como eu tive um relacionamento ruim com meu chefe, pois quando ele chegava perto da minha área, meu pensamento imediato era: "Agora, o que há de errado?" que tendeu a não ser uma coisa bastante saudável para ter como reação a alguém muitas vezes.

Como outros já disseram, a comunicação é fundamental - permitindo que as pessoas saibam (quem será impactado) quando você está preso: seu chefe, membros da equipe, clientes, etc.

Um colaborador esperto uma vez incutiu em mim que o sucesso tem raízes em duas coisas:

1. Relacionamentos
2. Expectativas

Ter um bom relacionamento, suponho, é uma função de boa comunicação e de estabelecer expectativas antecipadas.

Eu sigo o princípio Polya:

"If there is a problem you can't solve, then there is an easier problem you can't solve: find it."

George Polya

A beleza do princípio é que em algum momento haverá um problema que é pequeno o suficiente e que você será capaz de resolver qual, esperançosamente se você fez as coisas direito, permitirá que você inicialize uma solução para o problema original . Este princípio não me falhou ainda.

O " procura de ajuda "as respostas 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ê tiver que 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 um a um e eliminar cada um por sua vez, você acabará encontrando a suposição errônea e novas possibilidades para uma solução se abrirão como resultado.

(Aliás, essa também é a melhor abordagem quando você não consegue ver uma resposta para um problema que você recebe em uma entrevista de emprego. Informe verbalmente suas suposições, determine qual delas está errada e, em seguida, ataque o Quase todas as "perguntas capciosas" baseiam-se em suposições naturais, mas falhas).

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

So for those who have been in industry for any longer length of time, what would happen if you were told to solve a problem that you couldn't? Has it happened, and if so, what did happen? Did they just drop it and said "Oh well, guess we can make do with something else"? Were there consequences? Were you reprimanded, or even fired?

Sim, aconteceu comigo e, não, nunca fui repreendido ou demitido por isso, porque ...

Na indústria, é tudo sobre se você resolve os problemas no prazo e dentro do orçamento, e os gerentes decentes entendem que nem sempre é possível.

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

• Eu fiz algo muito semelhante a isso, então acho que levará três semanas e US $ 3.000 em testes de hardware.
• Eu tenho algo em geral 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 experimentos 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 ao gerente se houver um impedimento. Contanto que você faça isso, em uma empresa razoável, não haverá consequências negativas.

Naturalmente, também existem empresas pouco razoáveis que não lhe dão tempo ou recursos para realizar seu trabalho. Eu trabalhei em alguns deles e todos tiveram problemas que não poderiam 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 eu ainda considero meu chefe e seu chefe de lá bons amigos. / p>     

Existem muitos tipos diferentes de problemas com os quais você vai se deparar, e muitos têm maneiras diferentes de lidar com eles.

Um tipo de problema é implementar algo que você não viu antes, como uma API de som estranha ou algo assim. Nesse caso, eu perguntaria com SO, seriamente.

Outro é um problema muito grande para resolver. Esse tipo de problema pode ser abordado iterativamente. Eles dizem "Implementar Humongous". Você examina e escreve quantos passos conseguir. Então você divide os passos complicados em etapas menores. Como você é forçado a pensar em passos menores, eles se tornam mais claros. 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 os pedidos mal especificados. Eles só querem uma coisa que faz "x" e não dizem como isso deve ser feito. Para estes, uma boa abordagem é prototipar uma interface (normalmente uma GUI) e deixar alguém brincar com ela.

Depois, há restrições de tempo que não podem ser atendidas. Isso geralmente envolve a modificação de expectativas e a entrega de protótipos funcionais.

Você geralmente encontrará seu caminho através das coisas de uma forma ou de outra. É assustador, mas quando você está nele, você pode sempre encontrar algum caminho.

Sua melhor aposta é pintar as palavras "Don't Panic" do lado de fora do seu laptop. E não esqueça sua toalha.

Minha sequência de resolução de problemas (cada próximo spet é realizado somente se o anterior não funcionou):

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

Problemas desagradáveis são resolvidos nos passos 5-6.

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

E só então vem o passo 8.

Eu não ouvi nada acontecendo assim. Primeiro de tudo você nunca é dado um problema que não pode ser resolvido em tudo. O problema pode ser difícil e pode levar tempo para ser resolvido. Quando dado um problema, você terá que dizer que este é o tempo que vou exigir. Se em sua pesquisa você acha que este problema realmente não pode ser resolvido, você tem que levantar uma bandeira e dizer ao seu gerente que este problema levará mais algum tempo, ou é realmente difícil de resolver. É tudo sobre o cronograma. Se você prometer 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 redirecionar você para a pessoa certa que pode ajudar ou ajustar o cronograma.

Há ótimos conselhos aqui! Meus dois centavos vale a pena; Não se assuste com o grande problema, não se esqueça que a parte excitante e desafiadora de resolver um problema é dividi-lo em uma série de subproblemas gerenciáveis e, mais importante, mais compreensíveis, que por sua vez se dividem novamente em pequenos sub-problemas. Qualquer bom programador normalmente fará isso minuto a minuto enquanto estiver criando código (usando funções, métodos, sub-rotinas, etc. para ajudar a reduzir a complexidade geral de uma seção de código) e essa metodologia tipicamente se aplica a qualquer problema GRANDE que você cara na vida (não apenas no trabalho).

Depende de qual é o problema específico, obviamente. Mas a resposta pode ser qualquer um:

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 nisso o tempo que for necessário até conseguir .

O número 3 pode exigir tempo livre do problema e revisitá-lo semanas ou meses depois. Isso geralmente ajuda.

Na minha experiência, às vezes há um problema que você não consegue resolver, pelo menos na restrição de tempo. Então, buscando ajuda o mais rápido possível, depois que algum esforço de solução falhou você .

Lembre-se da regra prática: sempre observe o motivo pelo qual o chefe o contrata. Faça o que você acha que pode fazer para obter o melhor resultado de trabalho e, às vezes, isso é um relatório de falha inicial (muito melhor do que o atraso).

Se projetos de centenas de milhões de dólares puderem falhar mesmo com pessoas experientes, você não deve se preocupar com a sua falta, pois ainda é um estudante. Eu tive um problema para trabalhar e descobri que se é algo em que você fica preso - você deve gravar todas as tentativas que você fez para resolvê-lo.

Isso ajuda:

1. Prova de tentativas feitas para resolver um problema.
2. Gravar esse tipo de falha é importante para que você aprenda com isso e não faça isso 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 você não souber como resolver 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 e explique seu problema e peça ajuda.

Na maioria das vezes, apenas explicando o seu problema irá revelar uma solução e explicando sua solução pode igualmente revelar falhas nele.

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

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

"Meu maldito carro não liga" é um problema. "A bateria é plana." é uma solução preconcebida para o problema do arranque de automóveis. 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 com sucesso o carro, então você não tem nenhuma prova de que a bateria é a causa do problema.

Simplifique e continue simplificando. Divida-o em pequenas partes. Se você não pode 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.