Tengo experiencia técnica en desarrollo de software y pasé algún tiempo como líder de un pequeño equipo. El año pasado, me convertí oficialmente en gerente de proyecto en un equipo mucho más grande con cuyo trabajo estoy mucho menos familiarizado y tengo menos tiempo para aprender los detalles técnicos.
A veces, cuando estoy buscando información, un desarrollador puede decirme que la información que estoy buscando está en alguna carpeta enterrada dentro de la aplicación o en un repositorio de git, como si esperara que la busque allí. Técnicamente podría dedicar tiempo y esfuerzo a hacerlo, pero eso ya no es mi responsabilidad y me quitaría tiempo de mis responsabilidades reales.
¿Cómo les digo, educadamente pero con autoridad y sin sonar como "ese no es mi trabajo", que necesito que me proporcionen esa información en una forma ya digerida?
Ha formulado su pregunta como un problema interpersonal, con la presunción de que tiene que ver con su autoridad delegada dentro de su marco organizacional. Esta es una suposición, de la que hablaremos en breve.
Incluso si aceptamos la premisa de que se trata de una cuestión de autoridad, no se trata necesariamente de una cuestión personal o interpersonal. Dado que el alcance de la responsabilidad de un gerente de proyecto es aplicar controles a un proyecto, cualquier falla en el control de problemas conocidos dentro de un proyecto puede afectar el éxito del proyecto. Por lo tanto, es mejor enmarcar el problema en el contexto de un proyecto en lugar de uno interpersonal.
Además, los gerentes de proyecto a menudo son responsables del proceso de un proyecto y de administrar las comunicaciones dentro del proyecto y entre sus procesos. Por lo general, esas son áreas que reciben menos atención que el presupuesto y el cronograma, y ciertamente menos que la política y las cuestiones de autoridad posicional.
Con todo esto en mente, le recomiendo que inspeccione los procesos y las comunicaciones de su proyecto . Si encuentra brechas o fallas en cualquiera de ellos, puede trabajar con el equipo del proyecto para adaptarlos según sea necesario.
Esta pregunta, tal como se publicó actualmente, está plagada de suposiciones. Contiene suposiciones de su parte, además de obligar al lector a hacer suposiciones sobre los roles, la autoridad y el contexto de su situación. Con el fin de responder a la pregunta tal como se publicó originalmente , documentaré algunas suposiciones fundamentales para permitir una respuesta. Los supuestos son:
Si alguna de estas suposiciones es falsa, la respuesta se dejará tal cual para futuros visitantes, pero es posible que deba revisar su pregunta para reflejar con mayor precisión sus circunstancias dadas.
Dado que asumimos, a priori , que realmente necesita la información que le entregaron los desarrolladores y que todos preguntan y responden de la manera que consideran apropiada, entonces nos quedamos con la presunción de que hay un proceso o comunicaciones. fracaso en el trabajo aquí. Veamos ambas posibilidades.
Está bajo presión de tiempo para entregar algo (por ejemplo, un informe u otro artefacto del proyecto) y, por lo tanto, necesita algo de los desarrolladores. Sin embargo, a menos que esta tarea se haya asignado de la manera estándar para su proyecto, está creando presión de tiempo y riesgo de cronograma para los desarrolladores (y, por lo tanto, para el proyecto) al pedirles que:
Cambio de tareas.
El cambio de tareas puede tener un gran impacto negativo en el flujo cognitivo en el trabajo del conocimiento. No es simplemente el tiempo que lleva cambiar de marcha; esto también implica una interrupción cognitiva y crea una carga cognitiva a medida que el trabajador del conocimiento cambia de contexto a otra tarea. Como caso único, esto no es un proyecto asesino, pero la capacidad del equipo generalmente disminuye a medida que aumenta el cambio de tareas y la carga cognitiva.
Capacidad de turno.
Básicamente, sus solicitudes requieren que los desarrolladores cambien una parte de su capacidad disponible de lo que sea que estuvieran trabajando, o cualquier hito que se les haya fijado en esta etapa del proyecto, hacia otra cosa. Esto tiene un costo directo para el proyecto, ya que los proyectos generalmente tienen una capacidad finita. Esto también puede tener efectos colaterales si alguna tarea dependiente se ve afectada por la capacidad reducida de un miembro del equipo.
No se necesita mucha reducción en la capacidad del equipo para afectar un cronograma. Como muchas organizaciones caen presa de la falacia de utilización del 100 %, no se necesita mucha variación en la capacidad individual o del equipo para descartar la tolerancia de un proyecto. Incluso si el cronograma de su proyecto proporciona cierta holgura, debe considerar cuánto impacto acumulativo tienen estas solicitudes en la holgura disponible, o si la capacidad reducida simplemente crea más presión para cumplir con los plazos a pesar de la holgura insuficiente.
Realiza trabajos invisibles.
Dado que esta solicitud no forma parte del cronograma del proyecto y, presumiblemente, no se rastrea como un entregable del proyecto, le está pidiendo al desarrollador que cambie de una tarea visible de la que es responsable a una tarea "invisible" que no ser inmediatamente visible para las partes interesadas o su superior jerárquico. Como estos tipos de solicitudes pueden acumularse rápidamente, es posible que esté creando más trabajo "extraoficial" de lo que piensa.
Nunca hay una respuesta fácil para las fallas en los procesos, ya que son (por definición) de naturaleza sistémica. Sin embargo, es posible que pueda inspeccionar y adaptar su proceso de una o más de las siguientes maneras:
También puede haber otras formas de arreglar el proceso. ¡Hable con los desarrolladores y vea lo que puede resolver!
En realidad, este es un problema mucho más complicado con muchas más variables que una posible falla del proceso. Sin embargo, podemos resumir la mayor parte en dos áreas clave: contexto y transparencia .
Contexto
Tiene un contexto con respecto a lo que necesita, lo que necesita el proyecto y cuáles son los roles de todos. Esto puede no ser un contexto compartido.
Además, los desarrolladores también tienen un contexto. Puede comprender o no el contexto de los desarrolladores, o tener una comprensión completa de cuáles son sus percepciones y motivaciones dentro de su contexto mutuo.
Probablemente deberías discutir esas cosas juntos.
Transparencia
A nivel de proceso, es posible que no tenga visibilidad sobre lo que están haciendo los desarrolladores y las presiones bajo las que se encuentran. Es casi seguro que lo contrario es cierto: los desarrolladores rara vez tienen una idea de lo que están haciendo los gerentes de proyecto, o el impacto que cualquier cosa tiene en el proyecto fuera de sus responsabilidades asignadas.
Desde el punto de vista de la comunicación, lo que falta es transparencia. Es posible que usted y el equipo de desarrollo necesiten comunicarse de manera más efectiva sobre las presiones sobre el proyecto en su conjunto y sobre cómo esas presiones afectan al equipo. También puede ayudar tener más transparencia sobre la organización, incluida la cadena de mando y las líneas de autoridad delegada.
La única forma de mejorar la transparencia desde el punto de vista de las comunicaciones es hablar de las cosas explícitamente, en lugar de confiar en un contexto compartido o marcos de referencia asumidos. Tal vez sienta que no debería tener que sacar ciertas cosas a la luz y hablar de ellas, pero a menos que lo haga, seguirán siendo problemas opacos para todas las partes involucradas.
Entonces, habla de cosas. ¡Juntos!
Ciertamente hay otros tipos de fallas en las comunicaciones. Tal vez descubras algunos de ellos a medida que profundices. Sin embargo, al final, la solución casi siempre comenzará con hablar más abiertamente y garantizar que los problemas se discutan en un contexto compartido explícitamente.
Tal vez necesite ajustar la forma en que solicita información.
Cuando ya no tiene tiempo para hacer la investigación usted mismo, tiene que delegar. Pero debe asegurarse de comunicar este cambio claramente. Obviamente, la gente todavía piensa que puede obtener datos del repositorio. La próxima vez, deja claro lo que necesitas:
Hola Bob, ¿puedes preparar un breve informe sobre cómo funcionan las reglas para nuestros tres pies principales con respecto al nuevo widget y enviármelo mañana por la mañana? Gracias.
Ah, y no llames a las personas "recursos". Si me llamara "recurso", le enviaría una respuesta pidiéndole que consulte con mi gerente de línea para las tareas. Sé amable y conocerás gente agradable.
Si usted es el gerente del proyecto y esos recursos le reportan a usted, entonces delegue la tarea y describa sus expectativas de lo que necesita, cómo lo quiere y cuándo lo quiere, y si lo ignoran, tome medidas.
Como gerente de proyecto, puede delegar el trabajo a los miembros de su equipo de confianza. Cambie su enfoque de comando y control para este problema. Muestre su calidad de liderazgo de servicio a los miembros de su equipo y apóyelos en sus actividades diarias. No significa que usted tiene que hacer su trabajo. Explique la importancia de la información que está buscando y gane la participación de los miembros de su equipo
Si usted es quien necesita la información y los desarrolladores ya están ocupados con el desarrollo, ¿por qué es su trabajo encontrar la información por usted? Al decir "Creo que está en este repositorio", podrían estar pensando que están siendo útiles al indicarle la dirección correcta.
nathan cooper
pedro
Todd A. Jacobs
pedro