Introducir "20% de tiempo" en un lugar de trabajo [cerrado]

20% de tiempo es la cultura de un empleador, lo que permite que sus empleados pasen el 20% de su tiempo trabajando en proyectos que les parezcan interesantes: puede ser inventar una nueva aplicación o mejorar un proceso existente, etc. Algunas personas pueden conocer esto como mofeta Sin embargo, ese término puede no significar nada (o algo completamente diferente) para usted.

Hay muchos casos documentados de excelentes productos que nacen del 20% / trabajo de mofeta en una empresa. Parece una situación de ganar / ganar; la empresa potencialmente puede obtener un gran producto o aplicación nueva, y el desarrollador tiene la oportunidad de flexionar sus músculos creativos e innovar.

Intenté en numerosas ocasiones introducir alguna forma de 20% / Skunk trabajando en mi empleador anterior sin éxito.

¿Cómo puedo justificarlo mejor ante la gerencia? ¿Cuál es la forma "correcta" de abordar este tipo de arreglo de trabajo?

La razón principal del 20% de tiempo es mantener la utilización de la capacidad al 80% en lugar de al 100%.

Puede pensar en una organización de desarrollo de software como un sistema que convierte las solicitudes de características en características desarrolladas. Puede modelar su comportamiento utilizando la teoría de colas .

TEORÍA

Si las solicitudes llegan más rápido de lo que el sistema puede atenderlas, se ponen en cola. Cuando las llegadas son más lentas, el tamaño de la cola disminuye. Debido a que los procesos de llegada y servicio son aleatorios, el tamaño de la cola cambia aleatoriamente con el tiempo.

Los matemáticamente inclinados pueden preguntar sobre esta "aleatoriedad": debe haber alguna distribución de probabilidad, entonces, ¿cuál será el tamaño de la cola en promedio? La matemática (teoría de colas) tiene una respuesta a eso: si los procesos de llegada y de servicio son Markov, entonces N = rho ^ 2 / (1-rho).

(Donde rho es el coeficiente de utilización igual a la relación de servicio y tasas de llegada. Si los procesos no son de Markov, la matemática es más complicada, pero no cambia las conclusiones).

Si traza esta función, puede ver que la longitud promedio de la cola permanece baja mientras la utilización es de hasta 0.8 , luego aumenta bruscamente y llega al infinito. Puede comprender esto intuitivamente pensando en la CPU de su computadora: cuando su utilización se acerca al 100%, la computadora deja de responder.

PRÁCTICA

La economía del desarrollo de software es tal que las compañías de software incurren en grandes costos cuando sus colas están en estados de alta cola. Esto incluye oportunidades de mercado perdidas, productos obsoletos, proyectos atrasados ​​y desperdicio causado por las características del edificio en previsión de la demanda.

El 20% del tiempo es, por lo tanto, la respuesta científica al problema de optimizar los resultados económicos: evite estados de alta cola evitando los índices de utilización que los causan. Es esencialmente la holgura lo que mantiene al sistema receptivo.

Varias conclusiones prácticas siguen inmediatamente:

• si está considerando un 20% de tiempo y está haciendo una contabilidad de costos (el tiempo de los desarrolladores cuesta X, pero / y la empresa puede / no puede permitírselo), lo está haciendo mal.
• si está asignando un 20% a un viernes cada semana, lo está haciendo mal
• si está configurando un sistema de envío / revisión / aprobación de propuestas de proyectos del 20%, lo está haciendo mal
• si estás completando hojas de tiempo, lo estás haciendo mal
• Si utiliza la innovación como motivador durante un 20% de tiempo, lo está haciendo mal. Si bien los nuevos productos han salido del 20% de los proyectos, no eran el punto. Si su empresa no puede innovar durante sus horas centrales, ¡eso es un problema!
• El 20% del tiempo no se trata de creatividad. No digas que liberarás tu creatividad con un 20% de tiempo, pregunta por qué no eres lo suficientemente creativo durante tus horas centrales.

RESPUESTAS A PREGUNTAS EN LOS COMENTARIOS

Dan , entendiste bien y describiste con precisión el error cometido por muchos. No puede elegir su porcentaje de utilización, porque es una variable de salida. Es una relación de características de dos procesos, por lo que es lo que es porque los procesos son como son. Una organización tiene influencia sobre ambos procesos; la capacidad y la demanda de correspondencia es uno de los problemas difíciles que aborda el cuerpo de conocimiento de desarrollo de software lean. La utilización es uno de los indicadores de qué tan bien se resolvió este problema en una organización. La holgura emerge a medida que avanza su iniciativa Lean y elimina el desperdicio del flujo de valor. Pero si ordena un 20% de tiempo, terminará en la misma trampa de utilización con menos capacidad disponible.

Kim , todavía es parcialmente una cuestión de cultura. La referencia cultural más cercana que se me ocurre es el nivel sinérgico del llamado modelo Marshall de cambio organizacional. Emerge al final de las transformaciones lean exitosas o está presente en organizaciones construidas Lean desde el principio. ( Aquí hay un enlace al documento técnico de Bob Marshall (PDF)) .

Referencias

La lógica anterior está bien respaldada en la literatura de ingeniería de software. Mary y Tom Poppendieck lo insinuaron en su libro 2006 Implementing Lean Software Development . Donald Reinertsen en su libro de 2009 Principios del flujo de desarrollo de productos (Capítulo 3) brinda un tratamiento exhaustivo de este tema, con fórmulas y gráficos.

Catorce meses después de escribir esta respuesta, se me ocurrió una mucho mejor .

No he trabajado en un lugar donde tales trabajos hayan sido reconocidos oficialmente. Pero de mis conversaciones e intentos de aprender sobre esta práctica, encontré esto, bueno, principalmente lo que no es el "20% de tiempo":

• de hecho es una cultura y no una política
• no puede ser decretado por la alta gerencia
• no puede ser instituido por un comité de desarrolladores
• no son 32 horas en esto y 8 horas en eso

" Skunkworks " no es lo mismo que 20% de tiempo. 20% de tiempo es como usted dijo: tiempo en que el desarrollador elige por sí mismo en qué trabajar Skunkworks es totalmente diferente. Un proyecto de Skunkworks es un proyecto de alto valor y alto costo en el que trabaja un equipo (a menudo un equipo astuto de gurús) que no se informa a la alta gerencia, y el equipo decide por sí mismo cómo debe proceder el proyecto sin la dirección de la gerencia . Estos proyectos a menudo están motivados por una necesidad táctica o comercial de hacer algo, pero no hay espacio en el presupuesto para ello. Si hay que hacer algo , se hace: se condenan los presupuestos.

Gestioné un equipo de desarrollo donde implementé el 20% del tiempo. O lo intenté, de todos modos. Tenía la aprobación de mis superiores, así que eso no fue un problema. El problema era que el equipo era demasiado pequeño y especializado. Cada vez que surgían problemas que necesitaban una intervención inmediata, el 20% del tiempo se reducía. Esto terminó sucediendo muy a menudo.

También descubrí que algunos de mis desarrolladores encontraron mi falta de dirección inquietante. Aunque dije "trabaja en lo que quieras, siempre y cuando esté relacionado con la programación", todavía tuvieron dificultades para aceptar la parte de "cualquier cosa". Pensaron que algunos proyectos serían mejores que otros, por lo que inevitablemente trabajaron en solicitudes de implementación de bajo nivel en el producto principal, cosas así. Quería que se ramificaran y crecieran, pero en su lugar profundizaron en su experiencia principal.

Lo volvería a hacer, pero prohibiría expresamente trabajar en el producto principal y podría comenzar con algunas ideas para elegir para comenzar.

Estoy trabajando para una startup que ha implementado la política del 20%. Este es mi primer empleador en hacer esto, y cuando lo mencionó en la entrevista de trabajo, me sorprendió mucho, ya que la mayoría de los otros empleadores intentaban no perder una sola hora.

Me uní a la startup cuando se formó, y durante casi un año fui el único desarrollador. Pasé mi 20% básicamente con un par de cosas:

• Informar / corregir errores en proyectos aleatorios de código abierto : esto puede ser tan pequeño como bifurcar un proyecto interesante en Github y corregir algunos errores tipográficos en los documentos.
• Escribir "cosas" de código abierto : cosas como desafíos de programación, solo por diversión.
• Ir a conferencias y sprints : de vez en cuando iba a un sprint donde puedo trabajar en proyectos (algunos de los cuales podrían ser utilizados por la aplicación principal, otros no) y ganar algo de experiencia. Hay algunas bibliotecas que son utilizadas por nuestra aplicación y por aplicaciones desarrolladas por otras compañías que envían desarrolladores a conferencias, por lo que puede verse como un beneficio directo para nuestra compañía.
• Aprendiendo nuevas tecnologías : así es como aprendí Go , a pesar de que no lo usamos en la empresa. Esto es especialmente alentado por mi empleador. Últimamente he estado siguiendo algunas de las clases en línea gratuitas de Stanford.

Los tiempos no se miden con precisión, definitivamente no son 32 + 8 horas, a veces hay cosas urgentes que hacer cuando simplemente no hay tiempo suficiente para cortar ese 20%, otras veces tengo más tiempo libre.

Estoy trabajando de forma remota, y utilizamos el chat Campfire de 37signal para comunicarnos y rastrear la presencia del otro, y estas horas se registran como horas de "trabajo", estoy conectado al chat y disponible para los compañeros de trabajo, aunque haciendo Está claro que no estoy trabajando en nuestro proyecto en este momento.

Desde mi pequeña experiencia, muchos de nuestros proyectos realmente comenzaron de esta manera. Teníamos tiempo libre y ancho de banda para asumir nuevos proyectos, nos reunimos y se nos ocurrieron posibles ideas interesantes para nuestro departamento. En nuestro tiempo libre desarrollamos un prototipo y, una vez que estaba bastante pulido, se presentaba a un nivel superior y generalmente ven el beneficio.

Me parece que el nivel superior sabe lo que quieren si lo ven, pero no saben que lo necesitan / lo quieren hasta que lo ven. La creación de prototipos nos ha permitido crear nuestros propios proyectos, proponerlos y luego, una vez aprobados, desviarles más tiempo para completarlos.