Devolver el tiempo
Si hay una empresa que me guste ahora, esa es Atlassian. Buenos productos y una imagen envidiable en la red. Comparten sus ideas, y distribuyen sus productos con una licencia muy interesante para los usuarios.
Ahora acaban de publicar el "experimento" que van a realizar con sus ingenieros: "El 20% del tiempo". Y además van a blogear los resultados de sus experimentos, así que hay que seguir atentos. Este asunto trata de permitir dedicar a los desarrolladores el 20% de su tiempo en la dirección que elijan, de innovación, tecnologías o mejoras en los productos que soportan.
Me direis que esa es la famosa regla que Google aplica en su empresa, pero primero, tampoco dan tanta información, y segundo, tengo la impresión que es el 20% de 11 o 12 horas diarias de trabajo, no de una jornada normal. Atlassian reconoce que "copia" esa regla. :)
Dar esa confianza a los desarrolladores, puede significar sacar a flote grandes ideas que permanezcan escondidas tras la burocracia y las jerarquías. Supongo que se trata de recuperar, o no perder, la ventaja competitiva que tiene una "startup", a la vez que crecer de manera controlada.
Ahora acaban de publicar el "experimento" que van a realizar con sus ingenieros: "El 20% del tiempo". Y además van a blogear los resultados de sus experimentos, así que hay que seguir atentos. Este asunto trata de permitir dedicar a los desarrolladores el 20% de su tiempo en la dirección que elijan, de innovación, tecnologías o mejoras en los productos que soportan.
Me direis que esa es la famosa regla que Google aplica en su empresa, pero primero, tampoco dan tanta información, y segundo, tengo la impresión que es el 20% de 11 o 12 horas diarias de trabajo, no de una jornada normal. Atlassian reconoce que "copia" esa regla. :)
Dar esa confianza a los desarrolladores, puede significar sacar a flote grandes ideas que permanezcan escondidas tras la burocracia y las jerarquías. Supongo que se trata de recuperar, o no perder, la ventaja competitiva que tiene una "startup", a la vez que crecer de manera controlada.
A startup engineer must be all things - he (or she) is a full time software developer and a part-time product manager / customer support guru / internal systems maven.
As a company grows, an engineer spends more time doing the software development - but paradoxically he spends less time building the things he personally wants in the product.
Ahora le doy vueltas a cómo este tipo de resolución se puede aplicar a una empresa de servicios. Una empresa de servicios factura por horas, no hay un producto dónde se pueda producir un retorno de la inversión claro, ni donde centrar los esfuerzos personales-divergentes dedicados en ese 20% de tiempo. ¿Qué os parece? ¿cómo se podría trasladar este tipo de iniciativas a una empresa de servicios de software, que funciona por proyectos?
Mi Twitter
¿Cómo lo trasladaría yo?
ResponderEliminarPues innovando en sus proyectos... Está bien que no sería realmente 'elegir el propio camino', puesto que no sería un proyecto personal, pero sí sería crear un área más personal saliéndose de las especificaciones un poco.
Ejemplo: Quieres aprender la tecnología X. Intenta encajarla en el proyecto.
Esto puede dar lugar a una funcionalidad nueva que el cliente necesita y no sabe, o simplemente enriquecer un área del proyecto, a la par que motivar al trabajador a que el desarrollador sienta el proyecto como algo 'suyo'.
¿Y cuál es el valor de retorno? Probablemente, un cliente muy contento que volverá a confiar en nosotros.
Penyaskito, sí, podía ser ver el proyecto como el producto en construcción,... yo quizás pensaba más en dedicar ese 20% del tiemp a ver como mejorar el desarrollo de proyectos, pero quizás solo personas bastante experimentadas podrían trbajar en ello.
ResponderEliminarJoserra: como indicas, para una empresa de servicios la dificultad radica en la limitada cantidad de productos que se vendan mucho. No hay mucho espacio para sacar nuevos productos, porque sabes bien que las inquietudes de un desarrollador no siempre están alineadas con la empresa.
ResponderEliminarSin embargo, yo veo otras posibilidades. Desde permitir el refactoring hasta probar nuevas funcionalidades de modo experimental, como dice penyaskito, pasando por plantear metodologías innovadoras e intentándolas incorporar al desarrollo. Otra opción es dedicar ese tiempo a la formación realizando sesiones por áreas (humm, me suena), o aceptando propuestas para dedicar ese tiempo de una manera que esté alineada con la gestión de la empresa.
No estoy de acuerdo en que no se produzca un ROI, lo difícil, eso sí, es cuantificarlo para trasladar ese coste al cliente. Es difícil estimar cuanto ha mejorado el ciclo de vida de un proyecto por usar por ejemplo CMMI o SCRUM o TDD, salvo comparándolo con proyectos similares en los que no se hiciese uso de estas herramientas/metodologías, pero no casi nunca se tiene una comparación "apples to apples".
ResponderEliminarViene a ser como el principio de incertidumbre de Heisenberg aplicado a la mejora de procesos de software. xD
Sin embargo, el hecho de no poder cuantificarlo fácilmente no lo hace menos necesario, así que ya estás tardando en proponerlo. ;)