Como empleado remoto, ¿cómo hago para que mis compañeros de trabajo me den la información que necesito para hacer mi trabajo?

Para eso está tu jefe. Si tiene problemas para obtener la información que necesita para hacer su trabajo, y dado que no tiene autoridad para ordenar a nadie que lo ayude, su gerente debe hablar con el otro gerente y solucionarlo.

Para repetir: No tienes poder. No puedes obligar a nadie a hacer nada. Eso no es cuestión de ser independiente. El trabajo de su gerente no es perseguir a nadie. El trabajo de su gerente es hablar con otro gerente que luego puede decirles a sus subordinados que lo ayuden. Si ella no quiere hacer eso, entonces no está haciendo su trabajo.

Solía ​​hacer esto para ganarme la vida. Lo que encuentro es que la gente teme la idea de que se pierda su tiempo. Si les haces saber desde el principio que vas a respetar su tiempo, será mucho más probable que hagan un esfuerzo.

Por lo general, después de armar la tabla de contenido (y obtener su aprobación), dividí todos los temas y "asigné" mentalmente los detalles/lagunas faltantes a personas conocidas como expertos internos o ingenieros originales. Les diría con anticipación que necesitaría X cantidad de tiempo para cubrir los siguientes detalles e incluir todas las preguntas en el mismo correo electrónico. Les hice saber que había 2 fases: la fase de recopilación de información y más tarde, la fase de edición de precisión.

¿Ingenieros tímidos e inaccesibles? No hay problema, si les envía un correo electrónico con anticipación con su lista de preguntas específicas y un tiempo estimado. La mayoría de las personas cooperarán si saben que no es un sumidero de tiempo indefinido.

A veces existen barreras idiomáticas reales, por lo que es posible que necesite fuentes alternativas. Pero esas mismas personas podrían estar dispuestas a revisar los detalles técnicos/la precisión de los pases de edición, una vez que haya desarrollado todo el manual/documento. Una grabadora también ayudó mucho (especialmente cuando alguien está hablando de cosas peludas que posiblemente no puedas entender a la primera y usando una jerga con la que no vives como ellos). ¡Por no hablar de los murmuradores!

Una cosa que me ayudó mucho fue asistir a un par de reuniones de diseño de productos (o el equivalente en su caso), especialmente si puede hacerlo desde el principio. De esa manera, serás "real", en lugar de un extraño del que pueden o no saber. Además, puede evaluar quién va a ser accesible, por adelantado. Esto puede o no ser práctico en su situación. La contratación es genial, pero como dijiste, el truco es que eres un extraño que tiene que producir como un interno.

Soy un escritor técnico que trabaja con desarrolladores remotos, es decir, a 500 millas de distancia, no "en la oficina solo algunos días". Hay dos claves para resolver este problema, y ​​hasta ahora solo ha preguntado sobre una de ellas (hacer que respondan). Llegaré a eso, pero primero voy a hablar sobre el otro.

Los desarrolladores (o cualquier experto en la materia, para el caso) tienden a no responder bien a las personas que les preguntan cosas que las pymes ya han respondido. Eso es cierto para los escritores técnicos, evaluadores, personas de atención al cliente y probablemente otros. Por lo tanto, su trabajo comienza mucho antes de documentar la función que funciona principalmente. ¿Había especificaciones funcionales? ¿Revisiones de diseño? ¿Discusiones de requisitos? ¿Leíste esos documentos y fuiste a esas reuniones? ¿Hiciste preguntas sobre cómo funcionará la función desde el principio? (No, entonces no puede anticipar todas las preguntas, pero es posible que algunas le vengan a la mente). ¿Es usted parte del proceso ?

Si no es así como trabajan los escritores en su organización, le insto a que haga lo que pueda para cambiar eso. Si la cultura es "el desarrollador lanza un comunicado sobre el control de calidad y la documentación cuando está hecho", estarás peleando esta batalla de "muy poca información, demasiado tarde" para siempre. Si es el tipo de organización en la que puede colapsar esas reuniones, comience a presentarse. si no es así, trabaje con su gerente para obtener un acceso más rápido a la información y los planes antes de que se graben en piedra.

(Sí, esto significa que algunas cosas que aprendes desde el principio tendrás que desaprenderlas más tarde; los planes cambian. Habiendo hecho ambas cosas a lo largo de mi carrera, puedo decir con confianza que es mejor tener acceso temprano. Toma buenas notas para que pueda volver a consultar más tarde a medida que la verdad muta).

Hay un beneficio en este enfoque más allá del simple acceso a la información. Desea que los desarrolladores se acostumbren a verlo en esas reuniones (física o virtualmente). Quiere que empiecen a pensar en usted cuando necesiten discutir un cambio con alguien. Mi equipo de desarrollo me trata como un miembro del equipo en casi todos los aspectos (no tengo que depurar las fallas del conjunto de pruebas :-)), y eso no es un accidente. yo lo cultivé.

Ahora, dicho todo esto, llegamos a la pregunta que hizo: cómo obtener (a) cualquiera y (b) mejores respuestas a sus preguntas. Estoy de acuerdo con otros consejos que ha recibido sobre el envío de correos electrónicos con sus preguntas/temas específicos y la programación de reuniones cuando sea necesario, pero más allá de eso: haga buenas preguntas. Por lo que quiero decir:

• Se específico. "¿Cómo funciona el servidor?" es amplio y vago; el desarrollador probablemente piensa que estás pidiendo una clase. "¿Cómo maneja el servidor demasiadas solicitudes entrantes?" es mejor.

• Muestra lo que ya has hecho. ¿Es esta una pregunta que puede responder al menos parcialmente usando el software? Entonces haz eso. "Intenté enviar un montón de solicitudes tan rápido como podía moverme por las pestañas del navegador, pero no pude hacer que fallara" muestra que ha intentado ayudarse a sí mismo. O si no es algo que pueda probar razonablemente (va a necesitar decenas de miles de solicitudes y no sabe cómo escribir el código para escribir eso), muestre el esfuerzo de fondo de alguna otra manera: "Revisé el diseño spec y vi la sección sobre cómo debemos manejar este caso, pero no entiendo lo que dijiste sobre los grupos de subprocesos y las colas de prioridad".

• Si sigue teniendo el mismo tipo de preguntas, pregunte cómo pescar: "Necesito saber qué código de error devolvemos si X, y sé que pregunté sobre el código de error para Y la semana pasada. ¿Hay algún lugar en el código que ¿Puedes buscar esto?" A veces no puedes o no vale la pena el esfuerzo o te llevará por mal camino, pero mostrar que tu primer instinto es "tratar de resolverlo" en lugar de "preguntarle al desarrollador" gana puntos brownie en mi experiencia.

• Cuando les pidas que revisen algo, (a) diles lo que estás buscando y (b) enfócate en ello adecuadamente. Los desarrolladores son las mejores personas para revisar la precisión técnica; debería buscar su revisión o su giro de marketing en otra parte. Si han visto borradores anteriores, destaca lo que es diferente en este y cómo respondiste a sus comentarios anteriores.

Finalmente, si su organización tiene probadores, entonces tiene un aliado natural. Tanto tú como ellos necesitan gran parte de la misma información. Intenta formar equipo con ellos.

Tu primer párrafo se contradice:

Soy un redactor técnico que trabaja en la oficina 1 día a la semana. El trabajo que tengo no requiere mucho trabajo en equipo porque soy el único escritor, pero necesito obtener información de los desarrolladores.

Está claro que no puedes trabajar en total aislamiento de otras personas, ya que dependes de ellas para obtener la información que necesitas. Sin embargo, usted dice que no requiere trabajo en equipo para hacer su trabajo.

Su falta de tiempo en la oficina es probablemente un factor contribuyente y visitarla con más frecuencia probablemente resolvería muchos de los problemas a los que se enfrenta. Parece que estás luchando contra "fuera de la vista, fuera de la mente". Más interacciones cara a cara con su gerente, los desarrolladores y los gerentes de desarrollo contribuirán en gran medida a resolver esto.

Otro problema es que se malinterpreta el papel de un redactor técnico. Un trabajo anterior fue en una organización con un pequeño equipo de redacción técnica y muchas personas en realidad no entendían qué valor agregaban o cuáles eran sus roles/responsabilidades. Al hablar con ellos, esto es bastante común en muchas empresas, por lo que tendrá que estudiar. Si tu jefe no quiere perseguir a la gente, tendrás que ser tú quien persiga a la gente. Dado que perseguir constantemente a la gente es una pérdida de tiempo, querrá hablar con su jefe acerca de poder educar al resto del personal sobre lo que hace con respecto a los productos o servicios que ofrece su empresa, cómo encaja en el proceso y las cosas que necesita para poder hacer su trabajo a tiempo.

Una vez que esté frente a la gente con más frecuencia y los eduque sobre lo que está haciendo, muchos de los problemas que enfrenta disminuirán. El equipo de desarrollo que no se preocupa por la documentación es un problema cultural mucho más profundo en ese equipo que probablemente esté fuera de su control. El tiempo crítico extremo en torno a los lanzamientos también es indicativo de otros problemas de procesos o proyectos que probablemente también se encuentren en un nivel superior.

Si hay resistencia a las soluciones: no puede educarse, no puede obtener tiempo con las personas para hacer su trabajo, no puede lograr que los gerentes lo desbloqueen, esos son signos de problemas organizacionales más profundos.

Odio decirte que este no es un problema único. Incluso cuando eres el jefe de alguien, esto puede pasar.

La sugerencia de involucrar a su gerente es una recomendación sólida. Sin embargo, decir que eres impotente es un poco exagerado.

Tienes al menos dos herramientas en tu caja.

1] Cada vez que alguien pueda rechazarte, lo hará. ¡Recuérdalo! Entonces, ¿Qué haces? Da un paseo. Elija el momento de cada semana que más le convenga (varía el día y la hora cada semana) y camine hacia cada uno de los desarrolladores y comience a hacer preguntas. Sea cordial. Di hola. Presentarte. Explique su problema y cómo pueden ayudar con una sonrisa. Di gracias. Sea lo más amable y gentil posible, pero sea firme en cuanto a que necesita que le respondan sus preguntas. Si no es ahora, será más tarde. Deja en claro que no estás allí para hacerles la vida más difícil. Si después del almuerzo es mejor entonces bien. Después del almuerzo es. Si continúan desconcertándolo, simplemente explique que la gerencia probablemente hará preguntas y que preferiría decir eso. es extremadamente útil en lugar de no particularmente útil. Otros dos trucos que ayudan es hablar suavemente en un tono natural para que nadie más pueda escuchar. Aprendes mucho más de esa manera. Además, si está hablando con ellos, bájese tanto o más bajo que ellos. Me he puesto en cuclillas sobre mis talones para que esto suceda. Sonreír. Sé amable. Después de un tiempo, es posible que se sorprenda de que comiencen a enviar detalles por correo electrónico a medida que avanzan. Ellos saben lo que está en juego para ti y para ellos y ahora eres un miembro del equipo. Esto puede tomar algunas semanas para que realmente comience a funcionar bien. Mientras entiendan que esto no es un comportamiento único, cederán. Ellos saben lo que está en juego para ti y para ellos y ahora eres un miembro del equipo. Esto puede tomar algunas semanas para que realmente comience a funcionar bien. Mientras entiendan que esto no es un comportamiento único, cederán. Ellos saben lo que está en juego para ti y para ellos y ahora eres un miembro del equipo. Esto puede tomar algunas semanas para que realmente comience a funcionar bien. Mientras entiendan que esto no es un comportamiento único, cederán.

2] Si no puede caminar, otra gran herramienta es la rendición de cuentas. Odio ser un dolor en el culo (PIA), pero a veces, esta es tu única opción, sin embargo, no debería ser tu primera opción. Si está enviando un correo electrónico, envíe un cc a su jefe. Solicite una respuesta a todos. Si no responde a todos, envíe cualquier respuesta a su jefe con un cc de vuelta a la persona. Archiva todo para siempre. Lo mismo con tu jefe. Pronto, todos comenzarán a darse cuenta de que existe responsabilidad y que no responder es un suicidio profesional. Ciertamente, al menos ha documentado por qué tiene problemas para hacer su trabajo. Puedes explicárselo a tu jefe. Explique que está facturando horas improductivas y que prefiere que no sea así. Esta es una buena opción de todos modos, ciertamente por CMMI, ISO y otras razones, sin embargo, prefiero la opción 1 como la mejor.

Descubrí que ambas opciones funcionan bien. Toma semanas para que todo comience a funcionar bien. Sin embargo, con la opción 1, se está preparando para un éxito increíble. Utilicé esta técnica cuando me hice cargo de proyectos fallidos para una empresa de telecomunicaciones global que tenía el ojo puesto en el CEO/Presidente de la Junta. Cuanto más usaba la opción 1, más personas se daban cuenta de que les estaba haciendo un favor y la cantidad de cooperación que obtuve fue asombrosa. De hecho, tuve más impacto que sus propios jefes que me amaban porque también los hacía quedar bien sin que la gerencia realmente entendiera por qué. todos ganan

Usted es una parte interesada en el proceso de desarrollo y, como persona que tiene sus propias partes interesadas, diría que es más un cerdo que una gallina (alguien que no solo tiene una participación, sino un compromiso).

Insértese en el proceso de gestión de proyectos/scrum. Asiste a las reuniones de estado/de pie y dile a todo el equipo del proyecto que tu contribución está siendo bloqueada, que no lograrás el compromiso que se te delegó y que aceptaste con respecto a la próxima versión que se puede enviar. Obtenga criterios de aceptación (requisitos) y tareas procesables en las historias destacadas, de modo que la "definición de hecho" de esa historia incluya su contribución.

Lo que esto hace es mejorar la responsabilidad de otras personas ante usted y su visibilidad ante los demás que participan en el proceso. Incluidos los stakeholders del negocio. También le da a las personas cuyo tiempo y atención necesita el permiso para dárselo, ya que es parte de la planificación de la capacidad y la estimación del desarrollo.

El correo electrónico es una mala forma de programar y hacer un seguimiento de las tareas. Debe plantear el problema a su jefe, quien luego debe programar una reunión con el jefe de desarrolladores. El objetivo debe ser definir alguna Definición de Hechopara desarrolladores, por lo que una tarea o una historia de usuario debe marcarse como completa solo si también se cumplen los requisitos de documentación (similar a las pautas de codificación, pruebas unitarias, etc.). Esto suena como un enfoque difícil, pero oh, esto elimina cualquier argumento o emoción de la discusión. Después de varios años de luchas, la ingeniería de software moderna ha llegado a un acuerdo de que los pasos de calidad, como el análisis de código estático, las pruebas unitarias, etc., deben integrarse en el proceso en lugar de dejarlo al azar. La documentación aún no está completamente allí, ya que es difícil de automatizar y también se está debatiendo cuánta documentación es suficiente. Sin embargo, si su empresa había decidido que debería haber documentación, entonces esa tarea también debería estar integrada en el proceso.

Su trabajo como redactor técnico debería ser entonces discutir la calidad de la documentación, no tratar de convencer todo el tiempo si documentarían en absoluto.

Los correos electrónicos tímidos obtienen respuestas tímidas, los correos electrónicos asertivos obtienen respuestas asertivas.

Como han dicho otros, siempre que sea posible, es mejor escalar esto a través de la cadena de gestión. Si la empresa ha decidido conscientemente no asignar suficientes recursos a la documentación, eso es algo que debe mencionarse durante la revisión después de que haya enviado. Pero la pregunta parece estar buscando una solución alternativa cuando la gerencia no vio venir un problema hasta que estuvieron demasiado sobrecargados para reaccionar.

Otras personas han descrito los pasos necesarios para convencer a la gente de que sabes lo que haces. Si ha hecho todo eso y aún no puede obtener una respuesta, intente inventarse una respuesta que parezca plausible, luego envíela por correo electrónico a los desarrolladores y diga "Creo que esto es correcto. Confirme antes del <fecha>, cuando Lo agregaré a la documentación oficial" .

Si su comunicación muestra claramente su claridad de pensamiento y respeto por sus colegas, harán un cálculo mental rápido: si no respondo, esta persona probablemente sea lo suficientemente articulada como para culparme a mí; si respondo, me ganaré el respeto que me han dado .

Obviamente, este enfoque tiene sus riesgos, pero si ha descartado la solución correcta (escalándose a través de la administración), esta podría ser la apuesta que tiene.

Respuesta corta, diría, no puedes "hacer" que la gente responda a tus correos electrónicos...

...y larga respuesta, yo diría que, personalmente, la forma en que me gusta que me aborden los problemas es que me pidan ayuda...

... entonces, para una respuesta más larga, diría que no puede "hacer" que las personas respondan, pero puede hacer que sus correos electrónicos sean más "atractivos para la respuesta".

Es decir, desde la perspectiva del desarrollador al que se le pide, estaría más inclinado a ayudar si solo me pidieran que corrigiera, en lugar de que me pidieran que proporcionara.

Cuando me piden que corrija, es mi experiencia personal lo que necesita.

Cuando me piden que proporcione, casi (podría) sentir que podría haber investigado la respuesta usted mismo.

Como dicen, se cazan más moscas con miel que con vinagre.

Al mismo tiempo, no esperaría al desarrollador si mi fecha límite se acercara.

Continuaría enviando mi trabajo a mi superior a tiempo con una lista de documentación que aún puede necesitar revisión (quizás también agregando la última vez que el desarrollador y yo hablamos por cada elemento de la lista).

De esta manera, seguiría cubriendo todas mis bases y al mismo tiempo aprendería cosas nuevas que me ayudarían en mi profesión.

Pero tal vez así es como lo has estado haciendo ya.

En cuyo caso, lamento que esté en un lío, pero puede estar seguro de que ya está siendo proactivo y está haciendo su trabajo.

Una cosa que hago para asegurarme de que los correos electrónicos sean respondidos es enviar un correo electrónico a una persona a la vez. He visto una y otra vez, si envías un correo electrónico a un grupo de personas, se queda en el camino porque nadie es necesariamente responsable. Entonces, si alguien en el equipo de desarrollo puede ayudarlo, elija uno y envíele un correo electrónico específicamente.

Cuando no obtenga una respuesta, envíe un correo electrónico a su gerente algo como "Oye, le envié un correo electrónico a Steve solicitando esta información. Necesito esto para el final del día, pero aún no he recibido respuesta, ¿puedes asegurarte de que lo reciba? "

Ahora, ha hecho que Steve y su gerente rindan cuentas.

Si aún no obtiene respuestas, suba un nivel al superior de ese gerente y solicite ayuda de la misma manera hasta que alguien haga algo.

Muestre el rastro en papel según sea necesario.

Primero, serás tú quien persiga a la gente porque nadie más con autoridad quiere ocuparse de esta tarea.

En segundo lugar, aborde el problema con su jefe. Una vez más, usted hará el trabajo, pero es posible que ella tenga algunas estrategias. En algún momento, llegará un momento en el que no obtendrá lo que necesita a tiempo, entonces, ¿qué hace al respecto? ¿Cuánto tiempo es razonable para que usted diga: "Si no tengo algo, necesito 'x' cantidad de tiempo antes de la fecha de vencimiento, cómo reprogramamos/repriorizamos?" Lo siento, pero los que toman decisiones deben enfrentarse al problema. Concéntrese en el hecho de que quiere hacer las cosas a tiempo, pero no tiene la autoridad para responsabilizar a todos para obtener la información que necesita. Documente todas las solicitudes y entregas.

Además de todo esto, a menudo estoy muy apurado para preparar la documentación, por lo que es un gran problema.

El hecho de que estés "apurado" no es un problema, obtendrás mucha simpatía de cualquiera. Debe hacer que su jefe se comprometa con una fecha/hora de vencimiento cuando, si no obtiene lo que necesita en ese momento, no se hará a tiempo.

Lo malo de su empresa es cuando los diferentes equipos/divisiones se evalúan de forma aislada. Los programadores se salen con la suya al no ayudar con la documentación. Para ser justos con ellos, si solo son responsables de su código, eso siempre tendrá prioridad sobre todo lo demás. Si la documentación es importante (es decir, su empresa gana dinero con ella directa o indirectamente), todos los responsables a lo largo de la cadena de eventos deben compartir la responsabilidad y las recompensas. En cierto sentido, usted y los desarrolladores deben estar en el mismo equipo cuando se trata de documentación. Si los desarrolladores le envían la información a tiempo y usted no la entrega, eso depende de su compensación y viceversa. No puede haber escenario cuando un lado inhibe al otro sin sufrir las consecuencias.

Cualquiera que sea el valor que la documentación determinada aporte a la empresa, todos deben cosechar las recompensas cuando se hace y aquellos que no hacen su parte sufren. Desafortunadamente, las empresas no hacen esto. Averiguar tal estructura debería ser para lo que están los gerentes. De lo contrario, ¿qué están haciendo para generar dinero para la empresa?