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

En primer lugar, tu 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 se puede resolver (dentro de sus limitaciones de tiempo / presupuesto)?
3. ¿Simplemente no sabes cómo resolver el problema?
4. ¿Tu 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 frente a lo que necesitan?

2) Esto sucederá. "Constrúyeme un puente para mañana" . Asegúrese de saber por un hecho que un problema no se puede resolver dentro de sus restricciones. Su cliente / jefe puede ser flexible en el tiempo / presupuesto y estos pueden modificarse para darle más tiempo / presupuesto.

3) Si el problema es comprensible y las restricciones están dentro de lo razonable, y hay tecnología que puede resolver el problema, pero no sabe lo suficiente ... para eso es StackOverflow e Internet. Asegúrese de hacer su investigación primero. Trate de hacer preguntas explícitas que tengan respuestas cuantificables. Pregunte a sus 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á pidiendo lo imposible. Hacer un poco de investigación Nunca diga que el problema no se puede resolver, 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 el tiempo. ¡Su tiempo!. ¿Es el problema lo suficientemente importante como para resolverlo y justificar la cantidad de tiempo que le llevará investigar y resolver el problema? Discute esto con tu cliente / jefe

6) ¿Es un problema real? Los clientes, muchas veces, entienden lo que quieren, pero no necesariamente entienden lo que necesitan. Trate de comprender lo que realmente necesita su cliente / jefe y discútalas con ellos.

Espero que estas pautas te ayuden.

Dos cosas que debes recordar si te encuentras con un problema aparentemente insoluble:

• Haz que otras personas sepan que estás atascado lo antes posible. Les ayudará a ajustar la estimación a tiempo antes de que sea demasiado tarde.

• Si ves que una manera de resolver un problema no funciona, suéltala antes de que hayas perdido demasiado tiempo. Pida ayuda o pruebe un enfoque diferente. No se trata de demostrar que eres duro e inteligente, se trata de hacer las cosas.

Voy a StackOverflow ;)

Pero dejando a un lado las bromas, no temas a lo desconocido. Toda tu carrera enfrentará lo desconocido, porque si ya lo resolviste, 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, a veces, incluso cuando comienzo a publicar una pregunta en sitios como StackOverflow.

Mira desde diferentes ángulos

He encontrado esto muchas veces, generalmente lo que sucede es:

  

• Tienes un problema, inicialmente tienes una idea en tu 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 preguntar a otros. ¡Nada de eso funciona, la pura frustración!
  

Finalmente, optas por lo que no quieres hacer - >

"The Dirty Hack"

Funciona, pero te sientes sucio ...

Por lo general, hago que alguien más listo que yo lo arregle. Él lo hace y él es mi jefe. Me siento estupido. Seguimos adelante.

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

• lógicamente imposible: discútala con la persona que escribió los requisitos, tal vez haya un malentendido. Ejemplo: en un punto, 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 tener el mismo aspecto en todas las plataformas

• técnicamente imposible: reevalúe las herramientas con las que está trabajando, tal vez no sean apropiadas. Discuta el problema con sus compañeros y con 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 sea demasiado difícil (por ejemplo, NP-duro) y los requisitos no lo tienen en cuenta. Vuelva a evaluar el algoritmo que está utilizando, tal vez haya una manera más rápida. Discuta el problema con sus compañeros y con 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 sabes cómo hacerlo: pregunta a tus compañeros, pregunta stackoverflow, busca en Internet. Póngase en contacto con el soporte de la herramienta / lib que está utilizando. Discútalo con el gerente del proyecto.

• debería funcionar, pero no lo hace, y no tienes idea de por qué: Refactoriza el programa para que sea más comprobable. Ten en cuenta las condiciones de la raza, a menudo son la causa de errores difíciles de encontrar. Pida ayuda a sus compañeros, cuatro ojos ven más de dos. Compruebe en Internet los errores conocidos en las herramientas / libs que está utilizando.

Creo que otras personas señalan muy bien cómo lidiar con esto de una 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á BIEN, incluso si no resuelve los problemas de manera oportuna. La vida continúa.

A veces, el horario sería empujado. El proyecto sería exitoso o fracasado. 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é allí. Todo lo que podemos hacer es dar lo mejor de mí y dejarlo ir.

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

No estoy seguro de decir que no pude resolver un problema, pero hubo casos en los que me di por vencido al intentar resolver un problema. Después de dedicar muchas horas a tratar de corregir un error o implementar alguna función que no tengo idea de cómo hacerlo, es posible que le diga a alguien de mi equipo, al líder del equipo o al gerente: "Estoy atascado en esto. Qué quieres que haga para que sepan donde estoy. Podrían decir: "Manténganse al tanto, creemos que lo logrará" o "Continúen con otra cosa que no es tan importante", o algunas otras cosas, y luego sabré qué debería hacer.

He tenido errores que no resolví y algunas características que no se hicieron, seguro. 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 se encuentra.

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, se me pedía 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 intercambiaban las teclas "Esc" y "Enter" en el arranque y, con la secuencia de teclas correcta, se podría volver a utilizar la computadora portátil, lo que parecía extraño para tratar de calcular "¿Funcionaría esto? ¿Cómo sé que esto estaría o no estaría bien con los usuarios?" Hubo otras tareas que, o bien no tenía el hardware u otros recursos para hacerlo. Al mismo tiempo, fue bastante educativo, ya que esto me dio muchas cosas para anotar sobre cualquier situación laboral futura para evitar problemas. Cosas como garantizar cuándo me pagan, cómo se realiza el seguimiento de mi tiempo y otros problemas de comunicación que se me ilustraron con gran detalle aquí que realmente no he olvidado.

2. Mientras trabajaba en un proveedor de servicios de aplicaciones en Calgary, me dieron este proyecto de intentar crear una copia de otro sitio web dentro de nuestra aplicación interna que vendimos como un 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 más tarde 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 que dejé de trabajar repentinamente y luego, la semana siguiente, fui a un evento de Microsoft que fue la última gota cuando me despidieron al día siguiente. Algo a tener en cuenta aquí es que tuve una relación bastante mala con mi jefe, ya que cada vez que se acercaba a mi área, pensé de inmediato: "¿Qué pasa?" que tendía a no ser algo saludable como reacción a alguien muchas veces.

Como han dicho otros, la comunicación es fundamental: avisar a las personas (a quién afectará) cuando esté atrapado: su jefe, miembros del equipo, clientes, etc.

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

1. Relaciones
2. Expectativas

Supongo que tener una buena relación 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 puedes resolver, entonces hay un problema más fácil que no puedes resolver: encontrarlo".

     

George Polya

Lo bello del principio es que en algún momento habrá un problema que sea lo suficientemente pequeño y que podrás resolverlo, que con suerte si hiciste las cosas bien, te permitirá iniciar una solución al problema original. . Este principio no me ha fallado todavía.

El " busque ayuda "las respuestas son definitivamente correctas. Es altamente improbable que seas la primera persona en encontrar un problema en particular.

Pero como un experimento, ¿y si no hay ayuda? ¿Qué pasa si debes resolver el problema por tu 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 supuestos sobre un problema uno por uno y eliminarlos uno por uno, eventualmente se encontrará con el supuesto erróneo 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. Haga una lista verbal de sus suposiciones y determine cuál es la incorrecta y luego vuelva a atacar a la problema. Casi todas las "preguntas de truco" se basan en supuestos naturales pero defectuosos).

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

  

Así que para aquellos que han estado en la industria   por un período de tiempo más largo, qué   sucedería si le dijeran que resolviera   ¿Un problema que no pudiste? Lo tiene   sucedió, y si es así, ¿qué pasó?   ¿Lo dejaron caer y dijeron "Oh   Bueno, supongo que podemos conformarnos con   Algo más "? Estaban ahí   ¿Consecuencias? ¿Fuiste reprendido, o   incluso despedido?

Sí, me ha pasado, y no, nunca me reprendieron ni me despidieron por eso, porque ...

En la industria, todo depende de si solucionas 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 tu gerente dice: "Me gustaría que hagas 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 te contestaré esta tarde.
• Nunca he hecho algo como esto. Así que déjame investigarlo y te contestaré mañana.
• Nadie en el planeta ha hecho esto alguna vez. Si quieres verlo, me llevará dos semanas hacer suficiente experimentación para hacer una estimación.

Es el trabajo del gerente decidir si y cómo proceder. Si deciden continuar, es su trabajo cumplir con sus estimaciones o informar al gerente si hay un impedimento. Mientras lo haga, en una compañía razonable no habrá consecuencias negativas.

Por supuesto, también hay compañías irrazonables que no le dan el tiempo o los recursos para hacer su trabajo. He trabajado en algunos de ellos, y todos recibieron problemas que no podían resolverse dentro de las limitaciones de la compañía. Uno de ellos despidió al 98% del personal de programación en ocho meses, y eso ciertamente fue una consecuencia, pero no fue dirigido personalmente a mí, y sigo considerando que mi jefe y su jefe son buenos amigos. / p>     

Hay muchos tipos diferentes de problemas con los que te vas a encontrar, y muchos tienen diferentes maneras de manejarlos.

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

Otro es un problema muy grande para resolver. Este tipo de problema puede abordarse iterativamente. Te dicen "Implementar Humongous". Lo miras y escribes tantos pasos como puedas entender. Luego, desglosas los pasos complicados en pasos más pequeños. A medida que se ven obligados a pensar en pasos más pequeños, se vuelven más claros. Si encuentra alguna dificultad técnica, pruebe 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 una cosa que hace "x" y no te dicen cómo se debe hacer. Para estos, un buen enfoque es hacer un prototipo de una interfaz (normalmente una GUI) y dejar que alguien juegue con ella.

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

Generalmente encontrarás tu camino a través de las cosas de una manera u otra. Es aterrador, pero una vez que estás dentro de él, casi siempre puedes encontrar algún camino.

Su mejor apuesta puede ser simplemente 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 spet se realiza solo si el anterior no funcionó):

1. Intenta buscar en google
2. preguntar a alguien
3. Buscar SO directamente (sin pasar por Google)
4. piensa
5. humo (== cabeza clara)
6. Haz una pregunta en SO
7. Espere hasta la mañana (== aclarar la cabeza aún más)
8. Usa ese truco sucio y siéntete mal conmigo mismo :(

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

Los problemas realmente malos realmente 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: cambiar a otra tarea por el resto del día e intentar 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 que suceda así. En primer lugar, nunca se te da un problema que no pueda resolverse 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 puede resolverse, debe levantar una bandera y decirle a su gerente que este problema llevará más tiempo o es realmente difícil de resolver. Es todo sobre el horario. Si prometes algo y no podrás cumplir, entonces es un problema. Pero si sigue informando sobre su estado y sus preocupaciones, es responsabilidad del gerente cuidarlo. Él debería redirigirlo a una persona adecuada que pueda ayudarlo, o ajustar el horario.

¡Aquí hay un gran consejo! Mi valor de dos centavos es; No se sienta abrumado por el GRAN problema, no olvide que la parte emocionante y desafiante de resolver un problema es descomponerlo en una serie de subproblemas manejables y, lo que es más importante, comprensibles, que a su vez se desglosan una y otra vez en pequeños sub-problemas. Cualquier buen programador normalmente lo hará minuto a minuto mientras crean código (usando funciones, métodos, sub-rutinas, 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 cara 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 las siguientes:

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

El número 3 puede requerir un descanso del problema y volver a visitarlo 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 algún esfuerzo de resolución le falló .

Recuerde la regla de oro: 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, se trata de un informe fallido temprano (mucho mejor que uno tardío).

En resumen, si cree que puede encontrar la solución, no dude en probarla, pero proporcione una estimación a su jefe sobre el riesgo y el costo del tiempo. Es su problema ahora.

Si los proyectos de cien millones de dólares pueden fracasar incluso con personas experimentadas, no debe preocuparse por su fracaso, ya que aún es un estudiante. He tenido un problema en el que trabajar y descubrí que si es algo en lo que te quedas atascado, debes registrar cada intento que hayas hecho para resolverlo.

Eso ayuda:

1. Prueba de los intentos realizados para resolver un problema.
2. Registrar este tipo de falla es importante para que aprendas de él y no lo hagas de nuevo unos días más tarde, pensando que funcionará.

Mi experiencia es que un recién graduado no es arrojado a las profundidades. En su lugar, es probable que forme parte de un equipo que también incluya desarrolladores con experiencia.

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, discútala con ellos. Y si sientes que estás atrapado en algún lugar, toma a uno de los chicos experimentados y explica tu problema y pide ayuda.

La mayoría de las veces, solo la explicación de su problema revelará una solución y la explicación de su solución también puede revelar fallas en ella.

A menudo esto sucede porque no ha definido el problema correctamente y con precisión. Quizás esté intentando resolver una solución preconcebida en lugar del problema en sí.

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

"Mi coche con sangre 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 iniciado el automóvil con éxito, no tiene ninguna prueba de que la batería sea la causa del problema.

Simplifica y sigue simplificando. Romperlo en partes pequeñas. Si no puedes resolver esas partes, destrúyelas. Te sentirás mejor. Luego descomponerlo en diferentes partes pequeñas. Cada una de esas partes debe ser fenómeno observable.