En Open Lab hemos estado desarrollando Teamwork y consultando sobre software de gestión de proyectos y trabajo desde 2003.
Cada vez que entrábamos en una empresa con nuestro software, habíamos planeado mostrar cómo funcionaba el software, cómo optimizar su configuración y cómo integrarlo con el software existente. Pero en realidad, lo hacíamos en el último momento de nuestra visita, si es que lo hacíamos.
Pero cuando llegábamos, siempre terminábamos en reuniones tras reuniones donde el tema no eran los detalles de Teamwork, sino cuestiones de gestión del trabajo, y cómo «mapear y estructurar» mejor estas, para que los árboles de proyecto, conjuntos de tareas, flujos de trabajo y así sucesivamente pudieran usarse de manera coherente.
Y hemos aprendido mucho sobre qué mapeos funcionan y cuáles no.
Esta necesidad de mapeos conceptuales está enseñando algo, es decir, dónde está el valor real para los clientes, qué necesitan los usuarios.
Progresivamente nos dimos cuenta de que el valor de un software como Teamwork puede estar simplemente en la introducción de más estructura, más calidad en el trabajo. Esto puede ser mucho más que simplemente usar el software; llevándolo al extremo, uno podría simplemente leer esta guía, reformar las prácticas en la empresa y olvidarse del software 😀
Y a más personas y empresas que conocíamos, más apreciábamos la forma en que habíamos estructurado Teamwork desde el principio para ser muy, muy flexible. Un grupo de diseñadores de moda, una empresa de producción, un equipo de desarrolladores de software, un grupo de TI, ingenieros de hardware, organizadores de eventos, todos estos tienen necesidades diferentes. Y estos grupos pueden estar en la misma empresa, y diferentes modelos necesitan coexistir.
Atender necesidades diversas hizo que Teamwork evolucionara para ser una herramienta de mapeo aún más potente. Aunque está extendida, sigue siendo una herramienta integrada orgánicamente.
Modelar las necesidades de la empresa para organizar el trabajo siempre implica ir más allá del alcance de una sola aplicación: Teamwork siempre se usa en un contexto aplicativo, y por lo tanto su apertura a integraciones externas es algo que, en nuestra experiencia concreta, ha hecho posible una adopción exitosa.
En la guía de usuario para la versión 4.5 también encontrarás algunas de nuestras experiencias de «mapear y estructurar», algunas obtenidas mediante «boot camps» en empresas, otras brindando soporte web. También encontrarás las definiciones de algunos conceptos relacionados con la gestión del trabajo que no están directamente vinculados al uso del software.
Algunos dicen que todo lo que las empresas necesitan es una lista de tareas; para nosotros, esto es solo un síntoma de la escasa experiencia en lo que la gente hace en el trabajo, de lo complejas que son las necesidades de una empresa productiva. Esperamos que la nueva guía pueda ser de ayuda para entender qué mapa se adapta mejor a tu organización.
Algunos de los títulos de las historias:
¿Cómo comienzo la gestión de proyectos?
Gestionar con listas vs. gestionar con árboles
Superando la oposición
Un momento crítico: el cambio
Migraciones
Proyectos públicos
Una empresa de diseño y producción
Gantt o no Gantt
Herramientas sociales para la gestión del trabajo
iPhones para todos
Un grupo de investigación distribuido
Métodos Agile
Trabajando por «pomodoros»
Gestión tipo Kanban
Evaluaciones simplistas de costo/beneficio de la adopción de herramientas organizacionales
Validación de worklog
Integración profunda de TI
Gestión del trabajo y juegos
Cómo se hace Teamwork con Teamwork
Teamwork y multilingüismo
Procesos de negocio
Mesas de ayuda
Estructura de la empresa
Diferentes Teamworks, mismo contenedor de datos
Teamwork y el valor de tu empresa
Related Posts
