Aplanando tu Flujo de Trabajo: Una Guía para la Gestión de Proyectos de Estilo "Plano"

Ari Mahpour
|  Creado: Abril 22, 2019  |  Actualizado: Abril 16, 2020

flat project management in pcb design cover image

A medida que las organizaciones planas se vuelven más populares, también lo hacen los métodos y procesos que vienen con ellas. Este blog no discute la estructura organizacional plana en sí, sino cómo funciona una organización plana dentro del ámbito de la gestión de proyectos. Los principios de gestión de proyectos aprendidos de una organización plana pueden ser adoptados tanto en las empresas más planas como en las organizaciones con una estructura jerárquica más marcada.

Ser "plano" está de moda, pero ¿por qué debería hacerlo?

Te podrías estar preguntando, "¿por qué estaría interesado en la gestión de proyectos plana?" Para el gestor de proyectos, la respuesta es simple: menos delegación, menos solicitudes de estado y menos supervisión. Esto se traduce en más tiempo para que te concentres en las cosas que amas... a menos que realmente disfrutes siendo un capataz (y si ese es el caso, deberías dejar de leer aquí). Para el que está siendo gestionado, también es bastante claro: ¿por qué necesitarías tener un señor feudal constantemente acosándote por el estado y "aconsejándote" sobre cómo hacer tu trabajo correctamente? De nuevo, si realmente te gusta eso, entonces este puede no ser el estilo adecuado para ti. La idea aquí es que los gerentes requieren menos gestión y todos los demás tienen la autonomía y libertad para realizar su trabajo como quieran hacerlo sin ser molestados.

Los Prerrequisitos

Antes de comenzar con el proceso en sí, hay tres requisitos previos principales para que esto realmente funcione: Confianza, Transparencia y Comunicación.

AQUÍ

Figura 1. Confianza, Transparencia, Comunicación

Confianza: Confiar el uno en el otro es clave para una estructura de proyecto plana exitosa

Transparencia: La necesidad de que todos sean completamente abiertos sobre lo que están haciendo. Esto se puede lograr comunicando su trabajo a través de algunos de los siguientes medios:

  1. Compromisos de código
  2. Páginas wiki
  3. Sistemas de seguimiento de problemas
  4. Máquina de espresso (es decir, el nuevo punto de encuentro)

Comunicación: Todos necesitan tener la capacidad de comunicarse entre sí y se debe fomentar que lo hagan.

Cuando hay confianza hay transparencia. Cuando hay transparencia, las personas comienzan a sentirse seguras. Cuando las personas se sienten seguras y se les anima a ser abiertas sobre su trabajo, la comunicación simplemente sucede de manera natural.

Implementación

Ahora que hemos cubierto los requisitos previos, podemos discutir la implementación de la gestión de proyectos plana.

El líder del proyecto: "Pero pensé que nadie es el jefe en una estructura plana?" Aunque realmente no se necesita a alguien para ejercer un "mando y control", es importante tener un facilitador. Piensa en el líder del proyecto como un director de orquesta que asegura que todos estén en sintonía y tocando al mismo ritmo.

Objetivos y metas claras: Los objetivos del proyecto deben comunicarse claramente desde el inicio del proyecto. Preguntas como, "¿Cuál es nuestro objetivo? ¿Qué estamos tratando de lograr? ¿Quién quiere este widget de todos modos?" necesitan definirse y un espacio Wiki es el lugar perfecto para hacerlo.

Requisitos y responsabilidad: Ya sea el líder del proyecto o el departamento de marketing, es necesario documentar los requisitos, de lo contrario, el caos puede surgir en un estilo de gestión de proyectos plana. Sin una dirección clara, el "jefe" puede fácilmente intervenir y recoger las piezas en un entorno normal. En un ambiente plano, las personas pueden perderse fácilmente sin requisitos claramente definidos. En un sistema de seguimiento de problemas, como Jira, estos requisitos pueden capturarse como Tareas o Historias. La práctica estándar sería que el líder del proyecto asignara las tareas a los individuos. En un ambiente de trabajo más plano, se presentaría a equipo una lista de tareas sin asignar donde ellos mismos podrían autoasignarse estas tareas (o asignarlas a otros). Este sistema (es decir, donde todas las tareas se presentan) puede ser tan simple como una hoja de cálculo de Excel compartida o tan moderno como un tablero Kanban. Una vez que esto está establecido, todos pueden ver y seguir el estado del proyecto completo sin ser el jefe.

Repositorio de diseño centralizado: Un repositorio de diseño centralizado es clave para crear y mantener este estilo de gestión de proyectos. No hay un resumen o estado constante del diseño de cada miembro del equipo a un “jefe”. Si las personas no pueden ver el trabajo de los demás, entonces no hay controles ni equilibrios. Cada miembro del equipo es un control para el otro. En el mundo del software, esto se hace formalmente creando una Solicitud de Extracción y permitiendo que tus compañeros de trabajo revisen tu trabajo a través de una revisión de código (en lugar de que el jefe actúe como el guardián). En la captura esquemática o el diseño, esto también se puede lograr mediante un proceso similar. Este blog discute cómo comprometer tu diseño en un repositorio Git (es decir, el nuevo “SVN” o “CVS”). En este caso, uno seguiría la misma práctica de Ingeniería de Software de comprometerse con una rama de desarrollo y luego emitir una Solicitud de Extracción. Para más información sobre este tema, puedes referirte a el tutorial de Git de Atlassian sobre cómo hacer solicitudes de extracción.

Ejemplo: Un Widget de Sistema Embebido

En este ejemplo, puedes ver que hemos configurado un pequeño proyecto que contiene diferentes requisitos que conforman un widget de sistema embebido. El proyecto, en este caso, es un Epic que contiene los requisitos para construir una placa de "LED parpadeante".

Figura 2. Un Epic que contiene los requisitos de diseño para construir una PCB de "LED parpadeante y elegante"

En este espacio de proyecto tenemos "componentes" mecánicos, eléctricos y de software en los cuales cada uno de esos componentes está asignado a un líder de componente.

Figura 3. Una vista de todos los componentes y líderes de componentes para el proyecto

Figura 4. Un ejemplo de una tarea que contiene múltiples componentes

El área eléctrica está utilizando Altium y subiendo su código al servidor Git (Bitbucket en este caso).

Figura 5. Commits de Git del diseño esquemático

Los ingenieros de software y mecánicos hacen lo mismo. En este proyecto particular solo hay tres miembros del equipo, pero podría contener innumerables miembros del equipo, siempre y cuando haya un líder de componente (es decir, alguien que es responsable de esa parte del proyecto).

Este espacio wiki permite que se produzca una conversación entre todos los usuarios que participan en las fases de concepto del producto, implementación o verificación.

Figura 6. Una página wiki que contiene información sobre el producto (incluyendo tareas)

Ya sea una hoja de cálculo, lista de tareas, página wiki o una cadena de correos electrónicos, es importante para el facilitador del proyecto y el resto del equipo tener la capacidad de ver todo lo que está sucediendo dentro del proyecto. Esto permite que todos sean responsables ante los demás y no solo ante un único gerente. Dentro de nuestra empresa, encontramos que el tablero Kanban es la mejor manera de visualizar toda la actividad del proyecto.

Figura 7. Un tablero Kanban que contiene las tareas del proyecto de ejemplo

Finalmente, si un miembro del equipo encuentra un problema, debe sentirse empoderado para crear tareas y asignarlas a otros compañeros sin ninguna duda. Quizás encontraron un error o simplemente necesitaban una pieza adicional de hardware para apoyar su implementación de software - independientemente, necesitan sentirse cómodos tomando la iniciativa y haciendo esa solicitud de manera lateral en vez de de arriba hacia abajo.

Conclusión

La micromanagement se ha vuelto tan pasado de moda. Gestionar un proyecto de manera horizontal en lugar de de arriba hacia abajo no solo se ha vuelto popular, sino que también alivia la presión sobre todos. El gerente del proyecto se enfoca menos en perseguir el estado y los diseñadores pasan menos tiempo generando esos informes de estado. Este artículo expuso los principios detrás de un enfoque de gestión de proyectos de estilo horizontal y cómo se ve esa implementación. No es necesario aplanar toda la estructura corporativa para adoptar un enfoque de gestión de proyectos de estilo horizontal - solo necesitan adoptar los principios mencionados anteriormente y sumergirse de lleno.

¿Te gustaría saber más sobre cómo Altium puede ayudarte con tu próximo diseño de PCB? Habla con un experto en Altium o sigue leyendo sobre cómo la biblioteca integral de componentes de Altium Designer se integra directamente con tus herramientas de diseño y simulación, para diseñar fácilmente sistemas embebidos con la funcionalidad que necesitas.

 

Únete y Ahorra

Obtén Ahorros Especiales Cuando Agregas un Nuevo Asiento de Altium Designer®

Sobre el autor / Sobre la autora

Sobre el autor / Sobre la autora

Ari es un ingeniero con una amplia experiencia en diseño, fabricación, pruebas e integración de sistemas eléctricos, mecánicos y de software. Le apasiona integrar a los ingenieros de diseño, de verificación y de pruebas para que trabajen juntos como una unidad cohesiva.

Recursos Relacionados

Documentación técnica relacionada

Volver a la Pàgina de Inicio
Thank you, you are now subscribed to updates.