Debido a mis condiciones como Aspie, noté bastantes veces, en ambientes de trabajo, que tengo una gran barrera de comunicación cuando se trata de asignaciones de tareas. La mayoría de las veces, tengo que trabajar en un proyecto varias veces, ya que la tarea tenía un significado diferente al que yo entendía. El principal problema aquí es que no entiendo el alcance. O no estoy al tanto de las soluciones para los problemas que encuentro mientras el trabajo está en progreso.
Un ejemplo clásico (pero técnico) que debería demostrarlo bastante bien. Una vez estaba diseñando una herramienta de análisis visual en Qt. Una de mis tareas escritas dice así:
Visualización del gráfico principal en un marco Qt.
Entonces, mi proyecto tenía un objeto de marco Qt adicional para agregar, como era nuevo en Qt, busqué las capacidades de ese objeto de marco Qt específico y descubrí que puede inicializarse como un marco OpenGL (lo que técnicamente, como yo sabe ahora, funciona de manera diferente que el Qt). Entonces realicé toda la función con un marco OpenGL, cargado en el marco Qt. Después, mi jefe no estaba tan contento, ya que desenterró la tarea escrita y me dijo cómo puedo usar un marco OpenGL, si escribimos "en un marco Qt", probablemente este es el sentido común. Me falta, ya que no puedo entender cómo usar un marco OpenGL como característica del marco Qt viola "Visualizar el gráfico principal en un marco Qt".
La mayoría de las veces, recibo el siguiente consejo: " Pero si no está seguro, ¡solo pregunte! ". Pero estaba seguro. No sabía que el marco Qt tenía otros medios para resolver este problema. Acabo de encontrar una manera de resolver mi problema, que respeta (supuestamente) los requisitos. Entonces, ¿por qué debería seguir buscando otros medios para resolverlo? Y si lo hago en general, ¿cómo sabría cuándo encontré la mejor solución y puedo dejar de buscar otras?
Entonces, ¿cómo puedo asegurarme de haber entendido correctamente una tarea, cuando carezco de la experiencia para saber qué formas hay disponibles para resolver la tarea y mi jefe cree que es lo suficientemente claro en su redacción?
Pero si no estás seguro, ¡pregunta!
Este. Porque, actualmente, su enfoque es:
1: Según el punto de vista de su gerente, porque no se ajusta a sus requisitos.
Por lo tanto, siga los consejos de su gerente. Pero, y aquí está el punto, ¡no como lo haces ahora mismo! .
Enseño temas técnicos y de seguridad a personas que no saben nada de ellos. Entonces, cuando lo hago, uso el viejo truco del juego en el que alguien tiene que dejarte saber lo que está pensando, sin decirlo. Modifiqué las reglas aquí, para adaptarlas a mis necesidades. Todo se basa en más de 20 años de experiencia y mejora. Y funciona como un encanto .
“Lo que entiendes bien, lo enuncias claramente ”, decía el autor y filósofo francés Nicolas Boileau . Entonces, lo que hago es explicar algo a alguien, luego hacer que esta persona, con sus propias palabras, explique el mismo concepto a otra persona, que no nos escuchó primero.
Si puedes explicarlo, lo has entendido. Si no, escucha de nuevo y vuelve a intentarlo...
Mi consejo es aplicar esto a ti mismo. Obtenga la tarea y reformúlela con sus propias palabras. Luego, vuelve con tu gerente:
Hola jefe, me pediste que hiciera X. Planeo hacerlo de esta manera: A / B / C. ¿Es correcto y qué esperas de mí? De lo contrario, también podría ir con D/E/F. ¿Qué os parece? ¿Es mejor o no? Gracias por la respuesta.
Desde aquí te lo hará saber. Y sabrás si lo entendiste bien o no.
Pero si no estás seguro, ¡pregunta!
Me gustaría reformular eso para:
Si cree que sabe cómo resolverlo, discuta su solución con un miembro del equipo. Pregúntele a un miembro del equipo si cree que su solución propuesta es el camino a seguir, o si hay otras formas de hacerlo.
Soy un ingeniero de software junior y sigo aprendiendo mucho. Lo que se hace en mi lugar de trabajo para evitar que haga 'lo completamente incorrecto/lo bueno de una manera completamente incorrecta':
Esto es, como Erik señaló en los comentarios, muy diferente de la programación de pares 'pura', pero el principio se deriva de eso, estoy seguro. Es una muy buena manera de obtener/dar retroalimentación y asegurarse de que se haga lo que se debe hacer.
Entonces, ¿cómo puedo asegurarme de haber entendido una tarea correctamente, cuando carezco de la experiencia para saber qué formas hay disponibles para resolver la tarea y mi jefe cree que es lo suficientemente claro en su redacción?
No sé si es posible para usted (requiere algo de energía/interacción social), pero si es posible, pregúntele a su jefe si le permitiría a usted y a su(s) compañero(s) de trabajo (quizás incluso 1 persona designada), hacer el tipo de programación en pareja que describí anteriormente . Incluso podría hacer esto junto con su jefe, aunque es posible que no tenga tiempo de sobra.
Si tanto usted como otro programador no entienden lo que se supone que se debe hacer (o tienen opiniones muy diferentes al respecto), acuda a su jefe para que lo aclare antes de implementar la historia. Preséntele ambas opiniones y pídale que tome una decisión. (En mi equipo, también hay un líder técnico para esto).
Especialmente si te falta experiencia, necesitarás un mentor, un navegante. Con la experiencia también viene la capacidad de comprender mejor lo que quiere decir su jefe porque llega a conocer los límites del código base. Hasta entonces, necesitará un intérprete/tutor que lo proteja de hacer las cosas 'de manera incorrecta'.
En respuesta a su comentario sobre 'cómo implementar esto'. Primero, pregúntele a su jefe gerente:
Oye, como sabrás, mi Asperger con frecuencia me hace malinterpretar las cosas escritas o tomar las cosas demasiado literalmente. Hay una solución para esto que básicamente significa que una vez que creo que sé lo que se supone que debo hacer, ejecuto esta solución con otro compañero de trabajo y pido su aprobación. De esa manera, evitamos que haga 'las cosas malas/las cosas buenas de manera incorrecta'. A la larga, nos ahorra mucho tiempo y, a medida que conozco mejor el estilo de comunicación dentro de esta oficina y obtengo más experiencia con el código base, incluso podría tomar cada vez menos tiempo (hasta que se acerque a una especie de ' mínimo esfuerzo requerido', ya que probablemente siempre será necesario para usted).
Básicamente, cómo implementas esto:
Cuando su jefe escribió "Visualizando el gráfico principal en un marco Qt", probablemente tenía una idea clara de cómo quería que hiciera eso, pero no puede leer su mente. Además, la declaración es muy breve y concisa, propensa a malas interpretaciones. No culpes demasiado a tus Aspergers aquí, probablemente todos se estarían rascando la cabeza con este.
Por lo tanto, podría haber pedido una aclaración, como "¿Ya pensó en una forma de codificar esto? Si es así, dígame, me ahorrará tiempo". o "¿Cuál sería su forma preferida de implementar esto?"
En este caso, el jefe dedicaría 5 minutos a escribir una descripción más detallada de su tarea, ahorrándole varias horas de investigación, lo cual es una buena compensación.
También podría forzarse a pensar en dos soluciones. Tener Asperger podría hacer que esto sea un poco incómodo, pero espera.
Así que aquí encontró una solución con un marco OpenGL. Escriba una breve descripción de él usando sus propias palabras mientras está fresco, luego retírelo al fondo de su mente y busque otra solución, profundice en los documentos, está bien preguntar a sus colegas (o incluso a stackoverflow). En este caso, podría haber profundizado en los documentos del marco Qt.
No necesita escribir todo el código para ambas soluciones completas, solo tenga una idea vaga de cómo lo hará, tal vez un diagrama en papel con algunas notas.
Después de esto, escriba una breve descripción de la otra solución y pregúntele a su jefe cuál prefiere. Describe las ventajas y desventajas de cada solución.
Darle a elegir entre dos opciones le da una razón legítima para que le pidas ayuda, también debería halagarlo un poco que valoras su autoridad.
Además, cuando encuentras una solución... todo el mundo tiende a pensar que su primera idea es la mejor y la única solución posible. Entonces, cuando tenga esta primera solución, juegue al abogado del diablo y encuentre todos sus defectos antes de implementarla. Tal vez encuentre lo suficiente como para pensar que será mejor emplear su tiempo buscando otra solución más práctica que inicialmente no era obvia. De todos modos, tener solo una opción debería ser un poco sospechoso, es un indicador de que no ha considerado otras opciones, tal vez mejores.
... Pero estaba seguro. No sabía que el marco Qt tenía otros medios para resolver este problema. Acabo de encontrar una manera de resolver mi problema, que respeta (supuestamente) los requisitos. Entonces, ¿por qué debería seguir buscando otros medios para resolverlo?
Comentaré esta parte porque la he visto mucho con los desarrolladores:
Elegir lo primero que encuentran suele ser malo porque significa que no han pensado en el problema y las compensaciones. El resultado es mucho más trabajo (a corto y largo plazo).
Pasar mucho tiempo es un problema porque no se dan cuenta de que hay problemas hasta que ya se ha pasado el tiempo.
Entonces, antes de comenzar a codificar, dedique un poco de tiempo a encontrar tres opciones y pruebe algunos ejemplos básicos usándolas. Luego presente esas opciones con una recomendación y deje que su gerente lo dirija desde allí.
Y si lo hago en general, ¿cómo sabría cuándo encontré la mejor solución y puedo dejar de buscar otras?
Esto requerirá experiencia para desarrollarlo. Pero si puede encontrar tres opciones, puede seleccionar la "mejor" de ellas y saber que es al menos mejor que otras dos. El acto de elegir requerirá que pienses en compensaciones, lo que te ayudará a convertirte en un mejor desarrollador. Y te da un punto de comparación cuando recibes comentarios, especialmente si te perdiste algo.
Recientemente tuve una entrevista en una empresa, que es muy sensible al tema del autismo en el trabajo.
Y no entender las asignaciones de trabajo correctamente si no es lo suficientemente específico es un problema del que son muy conscientes por parte de sus empleados aspie.
Me habló de las herramientas que desarrolló para llevarse bien con él, para ver si podía hacer uso de ellas.
Y uno de ellos fue algo de lo que literalmente me enamoré.
Una de las herramientas que mencionó no era solo hacer listas de tareas pendientes para las asignaciones de trabajo, sino también hacer listas de cosas que NO HACER.
También mencionó que nunca antes había tenido un aspie en sus equipos, pero pensó que este sistema también está ayudando a sus desarrolladores a no verse afectados por el autismo.
Entiendo que esta solución es algo que no es fácil de aprender para un superior que no está abierto a ella.
Entonces, mi requisito de OP de que yo mismo sea capaz de llevar ese sistema a la posición no se cumple con esta respuesta, ya que requiere el esfuerzo de la persona que me supervisa.
Pero aún así encuentro esto lo suficientemente brillante como para merecer una respuesta por sí solo.
Esto suena muy familiar (yo mismo tengo un diagnóstico de asperger). Yo también estaría seguro, en la situación que describiste.
En la empresa donde trabajo, tenemos una regla general (no específica para los trabajadores de aspie) para mostrar el resultado en aproximadamente el 80% del tiempo asignado.
Personalmente, lo he adoptado para mostrar mi trabajo cuando creo que he terminado en un 50%, independientemente de si siento que es bueno/correcto o no. En mi experiencia, esto ayuda mucho a mantener/retomar el rumbo.
Cuando se le proporciona menos información, está obligado a hacer suposiciones.
Le aconsejo que resuelva este problema
Revisión y confirmación de los supuestos
La forma de hacer esto es simplemente haciendo preguntas de confirmación.
Simplemente, piense en cada suposición que tenga y confírmela.
Comenzando con suposiciones que tienen más probabilidades de ser falsas.
Actualmente, el problema en su flujo de trabajo parece ser que asume una tarea y la completa si es posible, trabajando de forma aislada hasta que llega a un bloqueador. Como mencionas, te han dicho que preguntes si no estás seguro, pero no lo hagas porque te sientes seguro. Esta no es una buena manera de trabajar.
Para cualquier tarea de resolución de problemas donde puede haber múltiples soluciones para obtener el resultado final, es importante involucrar a las personas en tantos pasos como sea posible.
Entender que pedir retroalimentación no es pedir ayuda
Pedir retroalimentación no significa afirmar que no entiende lo que se supone que debe hacer, o hacer preguntas para obtener una mejor comprensión. No es pedirles que te hagan un favor pidiéndoles un consejo.
Significa invitar a alguien más a dar su opinión sobre lo que estás pensando. Esto les da la oportunidad de participar en su proceso y ofrecer su opinión. Debe ver esto como algo bueno para ellos: los incluye en la toma de decisiones y les da la oportunidad de expresar sus inquietudes.
Con eso en mente, debería quedar más claro que brindar más oportunidades para recibir comentarios generalmente será bien recibido por sus colegas y no se considerará que los molesta para obtener ayuda.
Planifique la retroalimentación durante su ciclo de desarrollo
Entonces, como esto es algo bueno tanto para sus colegas como para usted, debe quedar claro que pedir comentarios con más frecuencia es algo bueno. Como tal, debe programar mentalmente el tiempo en su planificación para cuándo solicitará comentarios.
Algunos ejemplos de veces que podría tener sentido son:
Después de leer inicialmente la especificación
Después de hacer una investigación inicial sobre el problema y encontrar posibles soluciones
Después de crear prototipos de áreas del problema y encontrar nueva información
Después de decidirse por una implementación final, antes de implementarla por completo
Después de completar la implementación mínima, antes de firmarla
Dependiendo de la situación, es posible que desee ofrecer más o menos oportunidades para la retroalimentación. Pero definitivamente necesita ofrecerlo con más frecuencia de lo que lo hace actualmente. Recuerde, no está pidiendo ayuda, está dando a sus colegas la oportunidad de participar.
Cómo pedir la retroalimentación
Ahora que tiene un plan para obtener la retroalimentación, es importante concentrarse en lo que desea obtener de ella y en la mejor manera de invitar a las personas a que la den.
Al solicitar comentarios, sugeriría incluir lo siguiente:
Brinde a las personas un resumen de lo que ha hecho hasta ahora (que puede ser simplemente "Leí la especificación y la entendí como x")
Describa qué opción cree que es la mejor competidora ("Estaba buscando implementar esto usando un marco OpenGL, que debería permitirnos hacer x, y")
Explique qué inquietudes tiene ("Pero deduzco que podría ser mucho trabajo" o "Aunque no estoy seguro de que sea lo mejor, no he encontrado ninguna alternativa").
Invítelos a dar su opinión ("¿Tienes alguna idea sobre esto?", "¿Te parece sensato?", "Sé que tienes experiencia contigo, ¿tiene sentido para ti?").
El proceso no necesita ser formal/escrito (aunque puede serlo si te funciona mejor), puede ser un rápido "¿Tienes 5 minutos para revisar algunas cosas contigo?" conversación.
Anne intimidada GoFundMonica
dhein
Xander
Fildor
dhein
dhein
dhein
Fildor
Xander
dhein
campanita
campanita
Fildor
dhein
alefcero
dhein
Córcega
dhein
Acumulación