¿Existen estudios de equipos interfuncionales frente a equipos basados ​​en dominios (por ejemplo, basados ​​en proyectos frente a software / mecánica / etc.)?


8

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?


Si. Todos los días, numerosas empresas hacen esta elección. Y todos los días, numerosas empresas descubren que realmente no importa demasiado. Si hubiera un ganador claro, ya se habría encerrado en las prácticas comerciales. Las ideas esenciales han existido desde la invención del ferrocarril y los grandes almacenes. Como no hay un ganador claro, ¿qué te dice eso?
S.Lott

Creo que esta es una buena pregunta, pero me pregunto si obtendrá una visibilidad más adecuada en la gestión de proyectos. Estos problemas generalmente trascienden el desarrollo de software y se pueden aplicar a cualquier equipo en cualquier entorno de proyecto. Además, @ S.Lott sí importa mucho. Sin embargo, no hay un ganador porque ambos funcionan (y funcionan bien) bajo ciertas condiciones. Desafortunadamente, estoy en un descanso muy corto entre tareas, por lo que no tengo tiempo para responder en este momento. Le daré una respuesta tan pronto como tenga más tiempo.
Thomas Owens

@Thomas Owens: "no hay un ganador porque ambos trabajan (y funcionan bien) bajo ciertas condiciones"? Eso no puede ser verdad. De lo contrario, habría una respuesta de libro de cocina, y cada negocio simplemente estaría obligado (por sus abogados y auditores) a seguir ese enfoque de libro de cocina.
S.Lott

Creo que lo que Thomas Owens quiso decir (corríjame si me equivoco) es que depende de la cultura de la empresa. He trabajado en varias compañías, cada una de las cuales ha utilizado uno de estos enfoques y funcionó para ellos. Incluso he visto este trabajo entre departamentos de la misma empresa (cada departamento utiliza un modelo diferente). En lo que a mí respecta, esto depende mucho de la cultura de la empresa y de las personas.
NomadAlien

Respuestas:


3

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:

  • SC Wheelwright y KB Clark, Revolucionando el desarrollo de productos: saltos cuánticos en velocidad, eficiencia y calidad (Nueva York: Free Press, 1992).
  • F. Damanpour, "Innovación organizacional: un metaanálisis de los efectos de los determinantes y moderadores", Academy of Management Journal 34, no. 3 (1991).
  • EF McDonough, "Investigación de los factores que contribuyen al éxito de los equipos multifuncionales". Revista de gestión de innovación de productos 17 (2000).

Gracias, agradezco las referencias, lo investigaré más a fondo.
mikelong

@mikelong Si quieres más, busca otros temas de liderazgo y comportamiento organizacional; esos serían los tipos de recursos que discutirían esto con más detalle.
Thomas Owens

1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.