¿Qué sucede si no puede resolver un problema? [cerrado]

Estoy a un año de graduarme de la universidad y tengo muchas ganas de resolver problemas prácticos. Especialmente no triviales, que requieren un poco de investigación y mucho pensamiento.

Pero al mismo tiempo, ese es también mi mayor temor: enfrentar un problema que no puedo resolver, sin importar cuánto lo intente. Y con la presión de entregar el código en fechas límite inminentes a la vuelta de la esquina, parece un poco aterrador cuando se ve desde los patios de juego seguros en la universidad (donde lo peor que puede pasar es que tengas que rehacer un curso o un examen).

Entonces, para aquellos que han estado en la industria por un período de tiempo más largo, ¿qué pasaría si se le dijera que resuelva un problema que no puede? ¿Ha sucedido, y si es así, qué pasó? ¿Lo dejaron caer y dijeron "Oh, bueno, supongo que podemos arreglarnos con otra cosa"? ¿Hubo consecuencias? ¿Fue reprendido o incluso despedido?

En primer lugar, su miedo es muy saludable y normal. Aquí están mis reflexiones después de unos 15 años en la industria del software.
Aquí hay algunas preguntas que debe hacerse:

1. ¿ Entiendes el problema?
2. ¿Sabe que el problema no tiene solución (dentro de sus limitaciones de tiempo / presupuesto)?
3. ¿No sabes cómo resolver el problema?
4. ¿Su cliente / jefe está pidiendo lo imposible?
5. ¿Vale la pena? (ROI)
6. ¿Es un problema REAL ?

1) En primer lugar, asegúrese de comprender el problema. No hay preguntas estúpidas. ¿Entiendes lo que te pregunta tu cliente / jefe en comparación con lo que necesitan?

2) Esto sucederá. "Construye un puente para mañana" . Asegúrese de saber con certeza que un problema no se puede resolver dentro de sus limitaciones. Su cliente / jefe puede ser flexible en cuanto al tiempo / presupuesto y estos pueden modificarse para darle más tiempo / presupuesto.

3) Si el problema es comprensible y las limitaciones están dentro de lo razonable, y existe una tecnología que puede resolver el problema, pero simplemente no sabe lo suficiente ... para eso es StackOverflowy para qué sirve Internet. Asegúrese de hacer su investigación primero. Intente hacer preguntas explícitas que tengan respuestas cuantificables. Pregúntale a tus compañeros. Tener una sesión de diseño.

4) Esta es una variante de la respuesta número 2. Parece que su cliente / jefe está preguntando lo imposible. Investiga un poco. Nunca diga que el problema no tiene solución, a menos que sepa exactamente por qué y pueda aclararlo.

5) ROI significa retorno de la inversión. Esto se refiere a una inversión en tiempo. ¡Su tiempo!. ¿Es el problema lo suficientemente importante como para resolverlo para garantizar la cantidad de tiempo que le llevará investigar y resolver el problema? Discuta esto con su cliente / jefe

6) ¿Es un problema real? Los clientes, a menudo, entienden lo que quieren, pero no necesariamente entienden lo que necesitan. Intente comprender lo que su cliente / jefe realmente necesita y hable sobre esto con ellos.

Espero que estas pautas te ayuden.

Dos cosas para recordar si está atrapado con un problema aparentemente irresoluble:

• Hágales saber a otras personas que está atrapado lo antes posible. Les ayudará a ajustar la estimación a tiempo antes de que sea demasiado tarde.

• Si ve que una forma de resolver un problema no funciona, suéltela antes de perder demasiado tiempo. Pide ayuda o prueba un enfoque diferente. No se trata de demostrarte duro e inteligente, se trata de hacer las cosas.

Voy a StackOverflow ;)

Pero dejando de lado las bromas, no temas a lo desconocido. Toda su carrera se enfrentará a lo desconocido, porque si ya lo resolvió, no será un problema la próxima vez.

Voy a tener que ir con una respuesta simple: pido ayuda. Al igual que otros, a veces me piden ayuda cuando están atrapados tratando de encontrar una solución para algo.

Editar: debo mencionar que a menudo encuentro la solución simplemente describiendo el problema a un compañero de trabajo, o incluso a veces cuando empiezo a publicar una pregunta en sitios como StackOverflow.

Mira desde diferentes ángulos

Me he encontrado con esto muchas veces, generalmente lo que sucede es:

• Tienes un problema, inicialmente tienes una idea en la cabeza de cómo lo resolverías.
• Cuando se trata de implementar realmente su solución, resulta que no funciona (probablemente debido al modelo débil del problema real).
• Después de luchar para resolver el problema, ya sea más investigación o preguntando a otros. Nada de eso funciona, ¡la pura frustración!

Finalmente, optas por lo que no quisiste hacer ->

"El truco sucio"

Funciona, pero te sientes sucio ...

Por lo general, consigo a alguien más inteligente que yo para solucionarlo. Lo hace y es mi jefe. Me siento estupido. Seguimos.

Depende de la razón por la que no puede ...

• lógicamente imposible: Discuta con el que escribió los requisitos, tal vez haya un malentendido. Ejemplo: en un momento, la especificación dice que la aplicación debe verse y sentirse nativa en todas las plataformas (Windows / Linux / Mac), y en otro lugar, dice que el programa debe verse exactamente idéntico en todas las plataformas

• técnicamente imposible: reevaluar las herramientas con las que está trabajando, tal vez no sean apropiadas. Discuta el problema con sus compañeros y el gerente del proyecto. Ejemplo: requisitos difíciles en tiempo real en un entorno donde la recolección de basura puede detener la ejecución por un tiempo indeterminado

• rendimiento insuficiente: tal vez está utilizando el algoritmo incorrecto, o tal vez el problema es demasiado difícil (por ejemplo, NP-hard) y los requisitos no lo tienen en cuenta. Vuelva a evaluar el algoritmo que está utilizando, tal vez haya una forma más rápida. Discuta el problema con sus compañeros y el gerente del proyecto. Considere cambiar a una heurística suficientemente buena en lugar de un resultado perfecto. Ejemplo: optimización de ruta con docenas o incluso cientos de nodos

• simplemente no sabe cómo hacerlo: pregunte a sus compañeros, pregunte stackoverflow, busque en Internet. Póngase en contacto con el soporte de la herramienta / lib que está utilizando. Discuta con el gerente del proyecto.

• debería funcionar, pero no funciona, y no tienes idea de por qué: refactoriza el programa para que sea más comprobable. Considere las condiciones de carrera, a menudo son la razón de los errores difíciles de encontrar. Pida ayuda a sus compañeros, cuatro ojos ven más de dos. Compruebe en Internet si hay errores conocidos en las herramientas / bibliotecas que está utilizando.

Creo que otras personas señalan amablemente cómo tratarlo de manera profesional. Me gustaría decir cómo lidiar con el sentimiento personal como la frustración, el miedo.

La conclusión es que estará FINO incluso si no resuelve los problemas de manera oportuna. La vida continua.

A veces, el horario se presionó. El proyecto sería exitoso o fallido. Puede ser despedido y luego tener un gran trabajo. Nunca se sabe

No me malinterpretes. No significa que esté bien dejar que el problema esté ahí. Todo lo que podemos hacer es hacerlo lo mejor posible y dejarlo ir.

A veces, creo que la frustración, el miedo a no resolver el problema es mi vida como desarrollador promedio.

No estoy seguro de decir que no podría resolver un problema, pero ha habido casos en los que dejé de tratar de resolverlo. Después de pasar muchas horas tratando de corregir un error o implementar alguna función que no tengo idea de cómo hacerlo, puedo decirle a alguien de mi equipo, líder o gerente del equipo: "Estoy atascado en esto. quieres que haga? para que sepan dónde estoy. Podrían decir: "Sigue adelante, creemos que lo entenderás" o "Pasa a otra cosa que no sea tan importante", o algunas otras cosas y luego sabré lo que debería estar haciendo.

He tenido errores que no resolví y algunas características que no se hicieron, claro. Si bien puedo intentar hacer algo, no todo está a mi alcance para resolverlo en un tiempo razonable. Un punto clave en esto es tener comunicación para que sus superiores sepan dónde está.

Dicho esto, tuve un par de veces en las que me encontré con algunas circunstancias bastante especiales:

1. Mientras trabajaba en un gran banco canadiense en Toronto, me pidieron que hiciera todo tipo de cosas que no sabía cómo hacer cuando me dieron la tarea. Por ejemplo, me pidieron que probara este método para asegurar las computadoras portátiles donde se intercambiaron las teclas "Esc" y "Enter" en el arranque y con la secuencia de teclas correcta, la computadora portátil sería utilizable nuevamente, lo que parecía extraño tratar de imaginar "¿Funcionaría esto? ¿Cómo sé que esto estaría o no bien con los usuarios?" Había otras tareas que simplemente no tenía el hardware u otros recursos para hacerlo. Al mismo tiempo, fue bastante educativo, ya que esto me dio muchas cosas para tener en cuenta en cualquier situación laboral futura para evitar problemas. Cosas como asegurarme cuando me pagan, cómo se registra mi tiempo,

2. Mientras trabajaba en un proveedor de servicios de aplicaciones en Calgary, me dieron este proyecto de tratar de crear una copia de otro sitio web dentro de nuestra aplicación interna que vendimos como servicio. Un punto clave aquí es que no me dieron una línea de tiempo o sugerencias sobre qué parte hacer primero, solo una investigación general y un mes después me pidieron una demostración justo cuando estaba teniendo una mala reacción a algunos medicamentos para el dolor. Esa reacción duró una semana en la que dejé el trabajo de repente y luego, la semana siguiente, fui a un evento de Microsoft que fue la gota que colmó el vaso al día siguiente. Algo a tener en cuenta aquí es cómo tuve una relación bastante pobre con mi jefe, ya que cada vez que se acercaba a mi área, mi pensamiento inmediato era: "¿Y ahora qué pasa?"

Como otros han dicho, la comunicación es crítica: informar a las personas (quién se verá afectado) cuando está atrapado: su jefe, miembros del equipo, clientes, etc.

Un gran compañero de trabajo una vez me inculcó que el éxito tiene raíces en dos cosas:

1. Relaciones
2. Expectativas

Tener una buena relación, supongo, es una función de una buena comunicación y establecer expectativas por adelantado.

Sigo el principio de Polya:

"Si hay un problema que no puede resolver, entonces hay un problema más fácil que no puede resolver: encuéntrelo".

George Polya

La belleza del principio es que en algún momento habrá un problema que es lo suficientemente pequeño y que podrá resolver lo que, con suerte, si hizo las cosas bien, le permitirá iniciar una solución al problema original. Este principio aún no me ha fallado.

Las respuestas de " buscar ayuda " son definitivamente correctas. Es muy poco probable que seas la primera persona en encontrar un problema en particular.

Pero como un experimento, ¿qué pasa si no hay ayuda? ¿Qué pasa si debe resolver el problema por su cuenta? La capacidad de resolución de problemas más importante es la capacidad de identificar y desafiar sus propias suposiciones . Si puede enumerar sus suposiciones sobre un problema uno por uno y eliminar cada uno a su vez, eventualmente encontrará la suposición errónea y, como resultado, se abrirán nuevas posibilidades para una solución.

(Por cierto, este también es el mejor enfoque cuando no puede ver una respuesta a un problema que obtiene en una entrevista de trabajo. Enumere verbalmente sus suposiciones, determine cuál está mal y luego vuelva a atacar el problema. Casi todas las "preguntas capciosas" se basan en suposiciones naturales pero defectuosas).

Pedir ayuda es realmente la mejor respuesta, pero aquí hay un poco más que puede ser útil.

Entonces, para aquellos que han estado en la industria por un período de tiempo más largo, ¿qué pasaría si se le dijera que resuelva un problema que no puede? ¿Ha sucedido, y si es así, qué pasó? ¿Lo dejaron caer y dijeron "Oh, bueno, supongo que podemos arreglarnos con otra cosa"? ¿Hubo consecuencias? ¿Fue reprendido o incluso despedido?

Sí, me pasó a mí, y no, nunca me regañaron ni me despidieron por eso, porque ...

En la industria, se trata de resolver los problemas a tiempo y dentro del presupuesto, y los gerentes decentes entienden que eso no siempre es posible.

Lo que realmente sucede es que su gerente le dice: "Me gustaría que hicieras X, ¿qué crees que tomará?" Y puedes dar muchas respuestas. Los buenos incluyen:

• He hecho algo realmente similar a esto, así que creo que tomará tres semanas y $ 3,000 en pruebas de hardware.
• Tengo algo generalmente similar a esto. Así que déjame pensarlo y responderte esta tarde.
• Nunca he hecho algo así. Déjame investigarlo y responderte mañana.
• Nadie en el planeta ha hecho esto. Si quieres investigarlo, me tomará dos semanas experimentar lo suficiente como para hacer una estimación.

Es el trabajo del gerente decidir si se debe proceder y cómo hacerlo. Si eligen continuar, es su trabajo cumplir con sus estimaciones o informar al gerente si existe algún impedimento. Mientras lo haga, en una empresa razonable no habrá consecuencias negativas.

Por supuesto, también hay compañías irracionales que no le dan el tiempo o los recursos para hacer su trabajo. He trabajado en algunos de esos, y a todos se les entregaron problemas que no podían resolverse dentro de las limitaciones de la compañía. Uno de ellos despidió a aproximadamente el 98% del personal de programación en ocho meses, y eso ciertamente fue una consecuencia, pero no fue dirigido personalmente a mí, y todavía considero que mi jefe y su jefe de allí son buenos amigos.

Hay muchos tipos diferentes de problemas en los que se encontrará perplejo, y muchos tienen diferentes formas de manejarlos.

Un tipo de problema es implementar algo que no has visto antes, como una extraña API de sonido o algo así. En este caso, preguntaría sobre SO, en serio.

Otro es un problema muy grande para resolver. Este tipo de problema puede abordarse de forma iterativa. Te dicen "Implementar Humongous". Lo revisas y escribes tantos pasos como puedas imaginar. Luego divide los pasos complicados en pasos más pequeños. A medida que se ve obligado a pensar en pasos más pequeños, se vuelven más claros. Si encuentra una dificultad técnica, intente una implementación de prueba y pregunte aquí si es necesario.

Uno de los problemas más molestos son las solicitudes mal especificadas. Solo quieren algo que haga "x" y no te digan cómo se debe hacer. Para estos, un buen enfoque es crear un prototipo de interfaz (generalmente una GUI) y dejar que alguien juegue con ella.

Luego hay limitaciones de tiempo que no se pueden cumplir. Esto a menudo implica modificar las expectativas y entregar prototipos funcionales.

En general, encontrará su camino a través de las cosas de una manera u otra. Es aterrador, pero una vez que estás dentro, casi siempre puedes encontrar la manera de salir.

Su mejor opción puede ser pintar las palabras "Don't Panic" en el exterior de su computadora portátil. Y no olvides tu toalla.

Mi secuencia de resolución de problemas (cada siguiente paso se realiza solo si el anterior no funcionó):

1. Intenta googlear
2. Pregúntele a alguien
3. Buscar SO directamente (sin pasar por Google)
4. Pensar
5. Humo (== cabeza clara)
6. Haga una pregunta sobre SO
7. Espere hasta la mañana (== cabeza despejada aún más)
8. Usa ese truco sucio y me siento mal conmigo mismo :(

Los problemas desagradables se resuelven en los pasos 5-6.

Los problemas realmente muy malos generalmente necesitan algo de tiempo (el paso 7 es LA solución para la mayoría de los problemas de "parece que no puedo hacer nada"). Y lo digo en serio: cambie a otra tarea por el resto del día e intente resolver el problema a primera hora de la mañana. Eso hace maravillas.

Y solo entonces viene el paso 8.

No he oído hablar de nada así. En primer lugar, nunca se le da un problema que no se puede resolver en absoluto. El problema puede ser difícil y puede llevar tiempo resolverlo. Cuando se le presente un problema, tendrá que decir que este es el tiempo que necesitaré. Si en su investigación cree que este problema realmente no se puede resolver, debe levantar una bandera y decirle a su gerente que este problema tomará más tiempo o es realmente difícil de resolver. Se trata del horario. Si promete algo y no podrá cumplir, entonces es un problema. Pero si sigue contando su estado y sus inquietudes, es responsabilidad del gerente cuidarlo. Debería redirigirte a la persona adecuada que pueda ayudar, o ajustar el horario.

¡Hay algunos buenos consejos aquí! Mis dos centavos valen la pena; No se sienta abrumado por el GRAN problema, no olvide que la parte emocionante y desafiante de resolver un problema es dividirlo en una serie de subproblemas manejables y más importantes, que a su vez se descomponen una y otra vez en pequeños subproblemas Cualquier buen programador generalmente hará esto minuto a minuto mientras crea código (usando funciones, métodos, subrutinas, etc. para ayudar a reducir la complejidad general de una sección de código) y esta metodología generalmente se aplica a cualquier problema GRANDE que usted enfrentarse en la vida (no solo en el trabajo).

Depende de cuál sea el problema específico, obviamente. Pero la respuesta puede ser cualquiera de:

1. Encuentre una solución / sustitución
2. Compre una solución comercial que se aproxime a lo que desea
3. No te rindas y sigue trabajando en ello todo el tiempo que necesites hasta que tengas éxito .

El número 3 puede requerir tiempo libre del problema y revisarlo semanas o meses después. Eso a menudo ayuda.

En mi experiencia, a veces hay un problema que no puedes resolver, al menos en la restricción de tiempo. Por lo tanto, buscar ayuda lo antes posible, después de que un esfuerzo de resolución le haya fallado .

Recuerde la regla general: siempre mire la razón por la que el jefe lo contrata. Haga lo que crea que puede hacer para obtener el mejor resultado de trabajo y, a veces, es un informe de falla temprana (mucho mejor que uno tardío).

En resumen, si cree que puede encontrar la solución, siéntase libre de intentarlo, pero déle a su jefe una estimación sobre el riesgo y el costo del tiempo. Es su problema ahora.

Si los proyectos de cien millones de dólares pueden fallar incluso con personas experimentadas, no debe preocuparse por fallar ya que todavía es un estudiante. Tengo un problema en el que trabajar y descubrí que si es algo en lo que te quedas atascado, debes registrar cada intento que hiciste para resolverlo.

Eso ayuda:

1. Prueba de intentos realizados para resolver un problema.
2. Grabar este tipo de falla es importante para que aprenda de él y no lo vuelva a hacer unos días después pensando que funcionará.

Mi experiencia es que un recién graduado no es arrojado a las profundidades. En cambio, es probable que formes parte de un equipo que también incluye desarrolladores experimentados.

Mi consejo sería: hacer uso de ellos. Cuando no esté seguro de cómo abordar un problema, o si desea saber si su solución va en la dirección correcta, hable sobre esto con ellos. Y si siente que está atrapado en algún lugar, tome uno de los muchachos experimentados y explique su problema y solicite ayuda.

Muy a menudo, solo explicar su problema revelará una solución y explicar su solución también puede revelar fallas en ella.

A menudo esto sucede porque no ha definido el problema de manera adecuada y precisa. Quizás esté tratando de resolver una solución preconcebida en lugar del problema real en sí.

El problema es solo lo que observas, no lo que imaginas.

"Mi coche sangriento no arranca" es un problema. "La batería está descargada." es una solución preconcebida para el problema de arranque del automóvil. Incluso probar la batería no prueba que sea la única causa del problema. A menos que haya recargado o reemplazado la batería y haya arrancado con éxito el automóvil, no tiene pruebas de que la batería sea la causa del problema.

Simplifica y sigue simplificando. Divídalo en partes pequeñas. Si no puede resolver esas partes, aplastarlas. Te sentirás mejor. Luego, divídalo en diferentes partes pequeñas. Cada una de esas partes debe ser un fenómeno observable.