Cuando trabajo en un proyecto, después de que las partes interesantes están codificadas, mi motivación se ve severamente disminuida. ¿Qué haces para superar este problema?¿Cómo se supera la inevitable "depresión" motivacional al final de los proyectos?
No deje todos los bits "aburridos" hasta el final - asegúrese de que cada componente funcione, con pruebas de regresión y documentación, tan pronto como sea posible en el proyecto.
Dicho esto, las últimas semanas seguirán implicando buscar los errores realmente elusivos, lidiar con los cambios de último momento, finalizar la documentación y, en general, sacar la maldita cosa de la puerta. Mi enfoque es simplemente hacer las paces: bajar la cabeza y saber que cuanto antes lo haga, antes podrá comenzar con todas las cosas de menor prioridad y más interesantes que se han puesto en cola detrás del lanzamiento actual.
No puede evitar por completo los cambios en los requisitos/documentos de último momento, salvo que sus clientes estén todos de vacaciones justo antes del lanzamiento. O póngase en una posición dominante como Apple y Google, de modo que los clientes no tengan conocimiento previo de los lanzamientos.
"Deberías" perseguir errores difíciles de alcanzar (me refiero a los que son tan difíciles de reproducir que no tienes un caso de prueba consistente) temprano, porque no puedes estimar cuánto tardarán en arreglarlos. Pero en la práctica, una parte de ellos será menos elusivo a medida que avance el proyecto, o se conviertan en efectos secundarios de otro problema conocido, por lo que ahorrará tiempo en promedio al darles una oportunidad limitada de hacerlo. La desventaja de esto es que, hacia el final, quedarán algunas. Sin embargo, si hay más de dos, lo has hecho mal.
Tomar un breve "descanso" después de una fecha límite importante para hacer lo que más le divierta es una buena manera de evitar el agotamiento a largo plazo. Incluso si termina tirando la mayor parte de ella porque omitió una planificación difícil, se habrá hecho más productivo.
repito:. 'Hasta que se puso en marcha' Mi código no existe hasta que se comprueba en la
O si usted no está utilizando el control de versiones, 'hasta que se publique' o
También podría usar el miedo y decir que si USTED no termina y lo lanza, alguien más lo hará.
Utilice el desarrollo basado en pruebas. Una prueba fallida siempre es una gran motivación.
Por lo general trato de decirme a mí mismo que conseguir que las cosas funcionan en el mundo real es tan interesante, porque allí es donde su código va créditos o será mejoraron por errores descubiertos y peticiones.
Deje que algunos testers lo suelten. Nada es más motivador que ver a la gente usar sus partes interesantes y encontrar mejoras obvias.
Estoy de acuerdo en que es difícil. Lo único que me mantiene en pie es tener en cuenta la sensación que tendría después de verla completa/enviada/en manos de los clientes.
No hagas todas las partes interesantes primero.
Me motiva hacer el código aburrido siempre dejando un poco decente hasta el final y siendo estricto sobre completar la sección de aburrido primero.
"si USTED no termina y lo lanza, alguien más lo hará".
Me dije eso antes. A veces, sin embargo, es bueno tomar un descanso por un par de horas y luego volver a él. Entonces no estás tan cansado como tú.
Mi motivación es solo para hacerlo. Como dijo onebyone, solo tienes que agacharte y hacerlo. Todo es una cuestión de prioridades. Cuanto antes se quiten las prioridades, antes podrá volver a las cosas interesantes.
Intento impulsar el concepto de días/noches de error. Establezca un objetivo de errores/problemas a la dirección y cuando llegue a ese número, todos saldrán por (pagado) pizza/cervezas. Mantiene la moral del equipo y actúa como un foco en un período aburrido.
También puede agregar en este concepto premios/¡enhorabuena para la mejor pieza de refactorización o la mejora del rendimiento, etc.
En general, cuando se ha hecho el 90% de la obra, que casi ha terminado, sólo hay que ver el último 90% :-)
Siempre pensar en eso, y verás eso es un largo camino hasta que esté funcionando.
Estoy feliz de hacer las tareas creativas y divertidas de la programación.
Pero después de eso, pienso en hacer feliz al usuario.
No estoy de acuerdo. Los bits "aburridos" son probablemente los más arriesgados. Deberías hacerlas primero. –
No entiendo. Estoy diciendo lo mismo: los bits "aburridos" deben hacerse temprano, excepto cuando eso no sea posible. Añadiré algunas aclaraciones. –
Lo siento, quise decir lo opuesto. Los bits interesantes son los más arriesgados. Deberías hacerlas primero. –