tools the techniques strategies skills ppt management classroom book time-management

time management - the - ¿Tienes tiempo de "holgura"?



time management techniques (6)

Solo quiero mencionar la política de Google sobre el tema.
El 20% del día debería usarse para proyectos e investigaciones privadas.

Creo que es hora de que los directivos se enfrenten al hecho de que la mayoría de los buenos desarrolladores son un poco flojos. Si no lo fueran, no tendríamos conceptos como la reutilización del código.
Si esta pereza puede enfocarse en una fuerza creativa, y los desarrolladores pueden leer sobre cuestiones técnicas y experimentar con las características de arquitectura y lenguaje, estoy seguro de que el resultado final será un mejor código y un desarrollador más satisfecho.

Entonces, si usted es un administrador: Deje que sus desarrolladores florezcan de vez en cuando. Aliéntelos a celebrar pequeños seminarios con el equipo para analizar nuevas formas de hacer las cosas.

Si eres un desarrollador: lee, aprende y ama tu oficio. Usted tiene uno de los mejores trabajos del mundo, siempre y cuando esté dispuesto a dedicar un tiempo a aprender las mejores formas de hacer su trabajo.

El equipo de CodePlex tiene una política de tiempo de holgura , y les ha funcionado muy bien.

  • Jim Newkirk y yo mismo lo usamos para trabajar en el proyecto xUnit.net .
  • Jonathan Wanagel lo usó para trabajar en SvnBridge .
  • Scott Densmore y yo mismo lo usamos para trabajar en un prototipo ObjectBuilder 2.0 .

Para otros, fue un gran momento para explorar cosas que técnicamente no estaban en el cronograma, pero que eventualmente podrían ser de gran utilidad para el resto del equipo. Estoy tan convencido del valor de esto que si alguna vez vuelvo a dirigir un equipo, lo voy a hacer parte de la cultura del equipo.

¿Has tenido una política formalizada de holgura en tu equipo? Como resulto?

Editado: Me acabo de dar cuenta de que no definí a Slack. Para aquellos que no han leído el libro, Slack es el "tiempo del 20%" de Google: le dan un pedazo de su día / semana / mes / año en el que trabajar en cosas que no están necesariamente relacionadas directamente con su trabajo diario, pero podría tener un beneficio indirecto (obviamente, si trabajas en cosas que no son totalmente útiles para tu trabajo o tu empresa, tu gerente probablemente no piense muy bien de la forma en que pasaste el tiempo :-p )


Actualmente soy un profesional independiente a tiempo completo que trabaja para un solo cliente. Si quiero obtener un total de 40 horas de pago, cada minuto que gasto la codificación debe contabilizarse en el plan de proyecto aprobado. O al menos tiene que ir hacia algún tipo de tarea de mantenimiento realista. Supongo que se podría decir que esta es una de las desventajas de contratar ... realmente no hay espacio para holgura o estar inactivo. Solo tienes que seguir y avanzar en la tarea que tienes entre manos. Puede ser bastante agotador, pero de nuevo me gusta cómo me mantiene responsable. Y, por supuesto, la paga es un poco mejor de lo habitual.

Dicho esto, me encantaría tener tiempo disponible para trabajar en proyectos de mascotas, pero ningún cliente aceptaría pagar por eso.

De todos modos, solo pensé en señalar cómo esto ejemplifica algunas de las grandes diferencias entre el trabajo independiente y el empleo a tiempo completo.


Tampoco he trabajado en ninguna parte donde haya una política formal, pero siempre he encontrado que es necesario invertir un poco de tiempo en I + D / construcción de herramientas. Muchas veces obtendré ganancias de productividad que me permitirán aún más tiempo ''slack''.


Tenemos tiempo de inactividad e intentamos programarlos entre lanzamientos. Una vez que sale un lanzamiento, le pedimos a nuestros desarrolladores que pasen el 60% del día corrigiendo errores y luego el otro 40% por tiempo de holgura. Sin embargo, tenemos políticas sobre lo que puede usar el tiempo de holgura. Luego, cuando un lanzamiento vuelve a aumentar, les pedimos a todos los desarrolladores que dediquen todo el día a implementar funciones o corregir errores para esa versión.

La política permite al desarrollador usar el tiempo de holgura para la capacitación, crear algo nuevo que la compañía podría usar, o simplemente crear herramientas dentro de la empresa para facilitarnos las cosas. Nos ha funcionado bien Creemos que es un gran beneficio.


Nunca he trabajado en ninguna parte que tuviera una política formalizada, pero prácticamente todos los gerentes que he tenido me han permitido dedicar algo de tiempo a cosas que no estaban directamente relacionadas con el proyecto actual o luchar contra un incendio.

Creo que la clave es hablar sobre las cosas que te gustaría probar. La mayoría de los gerentes quieren que sus equipos hagan algo genial, algo extraordinario, por lo que si puedes convencerlos de que puedes entregar algo, es posible que tengas la oportunidad. O quizás te permitan hacerlo solo para mantenerte feliz.

Ahora que soy contratista y no empleado, no me pagan para hacer cosas divertidas, pero generalmente solo trabajo de 30 a 35 horas por semana, así que todavía tengo tiempo para aprender y jugar.


No tenemos una política formal en mi equipo, principalmente porque hay mucho trabajo por hacer que justificar sería difícil. Lo cual es bastante irónico.

Empecé a hacer algunas cosas formales bajo la apariencia de "Reuniones de desarrollo" para inyectar al menos la esencia de esto en el equipo. Un ejemplo de esto es un proyecto de desarrollo que pretende enseñar nuevas tecnologías y producir una aplicación genial al final.

Es temprano, veremos cómo va.