Trabajo en una organización que crea muchos productos de sistemas integrados, es decir, se trata de productos completos con diseño / fabricación mecánica / sistema / electrónica / software. Por el momento, la mayoría de los equipos están organizados en torno a proyectos de una manera funcional cruzada. La ventaja de una organización como esta es que las personas que trabajan en estrecha colaboración para un objetivo común están cerca.
Las desventajas provienen del aislamiento de los ingenieros de sus pares. Por lo general, a un proyecto se le asigna un solo ingeniero de software. Esto significa que los proyectos tienen un alto factor de camión, un mínimo intercambio de conocimientos y mejores prácticas, y el desarrollo técnico es limitado.
Entonces mi pregunta es: ¿hay algún estudio que compare el costo / beneficio de estos dos enfoques?
fuente
Respuestas:
El mejor tipo de estructura de equipo para usar no es necesariamente uno de costo-beneficio, sino más bien en la cultura organizacional actualmente en vigor, las características de los empleados y el tipo de proyecto que se lleva a cabo. Debido a estas variables, no hay forma de decir que una estrategia o enfoque particular es mejor, pero hay algunos indicadores generales sobre cómo puede estructurar mejor un equipo para completar la tarea en cuestión.
Hay muchos tipos de equipos y formas de organizar equipos y organizaciones . Algunas de las formas más comunes son funcionales, ligeras, pesadas y autónomas. A continuación, resumo una parte de un libro sobre gestión de la innovación tecnológica: la Gestión estratégica de la innovación tecnológica de Melissa A. Schilling .
Un equipo funcional es completamente no funcional. Cada empleado permanece dentro de su propio departamento. Aislamiento total entre ciencia, ingeniería, recursos humanos, etc. Un empleado se reportará a un gerente funcional. Bajo esta estructura, las personas que trabajan en un proyecto tienden a estar más comprometidas con su departamento funcional que con el proyecto. Esta estructura es apropiada para lo que se conoce como proyecto derivado: aprovechar el trabajo existente con solo modificaciones o mejoras menores y proyectos que solo (o en su mayoría) requieren un solo tipo de experiencia.
Los equipos livianos ocurren cuando los miembros residen en sus departamentos funcionales e informan a los gerentes funcionales. Sin embargo, se presenta un gerente de proyecto. El gerente del proyecto supervisará a las personas que se necesitan para llevar a cabo el proyecto, pero no las administrará directamente. La función del gerente del proyecto es facilitar la comunicación y garantizar que cada miembro del proyecto contribuya de manera adecuada. Esta estructura es mejor para proyectos derivados que no requieren una gran cantidad de coordinación y comunicación entre los miembros.
Los equipos pesados eliminan a las personas requeridas de sus departamentos funcionales, sin embargo, aún se reportan a un gerente funcional. Un gerente de proyecto supervisa las actividades del proyecto, pero no supervisa ni administra directamente a los miembros individuales del equipo. Los gerentes de proyecto generalmente superan a los gerentes funcionales en este entorno y son responsables de evaluar, recompensar y liderar a los miembros del proyecto. Estos equipos tienen un alto grado de comunicación y colaboración entre los asignados al proyecto y los miembros también están comprometidos con el éxito del proyecto. Este formato se utiliza en proyectos de plataforma, que se utilizan para mejorar el costo, la calidad y el rendimiento de una generación anterior (pero podrían no tener una innovación nueva significativa).
Los equipos autónomos eliminan a los miembros de los departamentos funcionales por completo, y hacen que trabajen directamente bajo un gerente de proyecto. Los gerentes de proyecto aquí son miembros del personal senior y líderes de la organización. A veces, estos equipos tienen una libertad inmensa para "hacer el trabajo" desarrollando sus propias políticas y procedimientos. Al mismo tiempo, serían responsables por los éxitos o fracasos del proyecto. Estos tipos de equipos a menudo se implementan en proyectos innovadores, que introducen nuevas innovaciones en los productos de la organización, o para producir nuevas unidades de negocios.
Sin embargo, solo porque un tipo de equipo en particular podría ser bueno para un tipo de proyecto en particular, también importa cuál sea la cultura de la organización. Algunas organizaciones no pueden (o no) apoyar equipos autónomos por razones culturales. Otros "siempre lo han hecho" de cierta manera y simplemente no cambiarán. También importa qué tipo de personas hay en el equipo: algunas personas funcionan mejor si están ubicadas y tienen un alto grado de comunicación y capacidad de colaboración, mientras que otras prefieren su espacio para resolver el problema y descartarlo.
Los siguientes documentos / libros / documentos son citados por la sección del libro que estoy leyendo:
fuente
Si bien puede tener equipos interfuncionales, tampoco hace daño al personal de esos equipos con múltiples ingenieros a tiempo parcial. Podría, por ejemplo, poner a Bob en el proyecto a y el proyecto b y también a Jane en el proyecto a y el proyecto b. De esta manera, se distribuyen, sin embargo, si tiene proyectos que son lo suficientemente pequeños como para construirlos con un solo ingeniero de software, incluso este enfoque puede tener limitaciones.
Otra opción podría ser mantener la estructura del equipo igual pero organizar el entorno de trabajo alrededor de la función. Reúna a todos los ingenieros de software para que puedan colaborar en un entorno abierto. Esto va en contra de pensar un poco y, a veces, las personas se ponen a la defensiva cuando derribas los muros, pero podría ser útil trabajar en un arreglo tipo toro.
El concepto de trabajo conjunto también se basa en esto. Los consultores y diseñadores independientes que de otro modo trabajarían en una oficina basada en el hogar, se mudarán a una instalación compartida donde pueden alimentarse de las fortalezas de los demás.
Puede que no haya mucho sobre estas ideas, tal vez pueda presentarlo a los equipos involucrados como un experimento para obtener una mejor productividad y satisfacción en los trabajos. Luego, escriba un libro blanco sobre los resultados.
fuente