Esto no pretende ser una respuesta completa, ya hay varias muy buenas que mencionan cosas importantes como cómo usar su VCS y su software de gestión de proyectos, sino más bien un anexo que agrega algunos puntos que no vi en ningún otro, que yo es muy útil y espero que otras personas también lo encuentren útil.
1. Ninguna tarea es demasiado pronto o demasiado pequeña para escribir
Las personas generalmente hacen listas de TODO para las cosas que planean hacer en el futuro , pero dado que la programación requiere concentración, y dado que podemos interrumpirnos en cualquier momento , he encontrado útil escribir incluso lo que estoy haciendo ahora, o lo que estoy a punto de comenzar en cuestión de segundos . Usted puede sentir que estás en la zona y que posiblemente no podría olvidar la solución que sólo le golpeó en que aha momento, pero cuando su compañero de trabajo se reduce en el cubo se puede mostrar la imagen de un dedo del pie infectado , y que está solo capaz finalmente de deshacerse de él comenzando a roer su propio brazo , es posible que desee haber escrito una nota rápida, incluso si solo en una nota Post-It ™.
Por supuesto, algún otro medio más persistente podría ser mejor (me gusta especialmente OmniFocus ), pero el punto es tenerlo en algún lugar , incluso si terminas en 20 minutos y luego tiras el Post-It ™. Aunque puede descubrir que esa información se vuelve útil, para poner hojas de tiempo o facturas para el cliente, o cuando su jefe / cliente le pregunta en qué ha estado trabajando y no puede recordarlo. Si suelta todas estas notas en una caja, un cajón o una carpeta, cuando se produce una gran interrupción (un proyecto de interrupción), puede echar un vistazo y recordar muchas de las cosas que hizo para llevar su código al punto donde encuéntrelo cuando regrese al proyecto.
2. Use una pizarra blanca en su escritorio para capturar ideas generales
Tengo una pizarra blanca de 3 "x 4" al lado de mi escritorio, así que cuando comienzo un proyecto puedo hacer una lluvia de ideas sobre las soluciones a todos los problemas que percibo en un proyecto. Podrían ser diagramas arquitectónicos, casos de uso, listas de riesgos y obstáculos, o cualquier cosa que le parezca relevante.
Algunos enfoques más formalizados requieren que genere diagramas y casos de uso, entre otros, como "entregables" en algún formato en papel o electrónico, pero creo que eso puede crear mucho trabajo adicional, y simplemente convertirse en una serie de subproyectos que terminan divorciarse del propósito real del proyecto principal, y solo parte de un proceso formalizado que tiene que hacer pero al que nadie le presta mucha atención. Una pizarra es lo más simple que realmente funciona, al menos en mi experiencia. Es tan persistente como desee (con una cámara) y lo más importante le permite obtener sus ideas de inmediato.
Creo que es mejor con un bolígrafo en la mano, por lo que arrojar mis pensamientos sobre una superficie blanca es algo natural para mí, pero si no encuentra que ese sea el caso para usted, aquí hay algunas preguntas que pueden ayudarlo a decidir qué es relevante :
- Si yo fuera el desarrollador principal, a punto de irme de luna de miel durante 3 meses mientras otros desarrolladores completaban el proyecto, ¿qué dirección general me gustaría darles? ¿Qué ideas desearía asegurarme de que conocieran, o qué enfoques desearía asegurar que tomaron? ¿De qué bibliotecas u otras soluciones útiles me gustaría estar seguro?
- Si este proyecto fuera mi idea de un millón de dólares que sabía que garantizaría mi futura independencia financiera, pero estaba programado para una cirugía crítica que me incapacitaría durante 3 meses, ¿qué me gustaría que tuviera mi futuro yo para asegurar la finalización exitosa de ¿el proyecto?
(Cuando escribo las ideas por primera vez, solo me preocupa que tengan sentido para mi ser actual. Una vez que están abajo, puedo mirarlas de manera más crítica y hacer cambios para asegurarme de que tengan sentido para mi futuro o para los demás. Preocuparme demasiado acerca de comunicarse con los demás a medida que los escribe inicialmente puede conducir al bloqueo de los escritores: una mente obstruida por objetivos en competencia. Bájela primero; preocúpese por la claridad más tarde).
Le recomiendo que gaste el dinero para comprar una pizarra decente, al menos 3 "x 4", y colgarla en el espacio donde normalmente trabaja. Hay muchas ventajas de una pizarra física sobre cualquier sistema virtual.
- Es largo. Al ocupar mucho espacio, hace sentir su presencia, y los planes en él se sienten como parte de su espacio de trabajo, lo que ayuda a orientarlo en la dirección correcta todo el tiempo.
- Está allí de manera persistente: no tiene que iniciar una determinada aplicación o sitio web para acceder a ella, y no se arriesgará a olvidar cómo acceder a ella, ni a que esté allí.
- Es inmediatamente accesible cuando tiene una idea en la que desea pensar.
Pierde muchos de los beneficios si solo usa una pizarra en una sala de reuniones y luego toma una instantánea con su teléfono. Si gana dinero programando, vale la pena el costo de una pizarra decente.
Si usted tiene otro proyecto interrumpir la que ha llenado su pizarra, puede que tenga que recurrir a la instantánea en su teléfono, pero al menos tendrás que en 3 meses cuando se termine el proyecto "urgente" y usted tiene que volver al otro. Si desea volver a crearlo en su pizarra, probablemente solo le tomará 15 minutos, y puede descubrir que puede mejorarlo mucho en el proceso, lo que hace que esa pequeña inversión de tiempo valga la pena.
3. Informar a los interesados sobre el costo de interrumpir un proyecto.
La metáfora de un avión me parece útil: comenzar y completar un proyecto es como volar un avión. Si se rescata a la mitad del vuelo, el avión no solo se quedará sentado en el aire esperando que regrese, y necesita alguna forma de viajar desde el proyecto / vuelo actual al siguiente. De hecho, si estás en medio de un vuelo de Phoenix a Fargo y te dicen que debes interrumpir ese vuelo para tomar otro avión de Denver a Detroit, tendrás que aterrizar el primer avión en Denver (que afortunadamente no está lejos de su ruta de vuelo (no siempre es el caso con interrupciones reales) y alguien tiene que averiguar qué hacer con la carga y los pasajeros. No se quedarán sentados y esperarán por siempre.
El punto de esto para los proyectos es que la transición de un proyecto a otro conlleva un gran gasto de tiempo y deja muchos extremos perdidos que deben ser tratados.
En un proyecto, obviamente e inevitablemente sucede mucho en su cabeza mientras trabaja, y no todos los pensamientos pueden ser serializados en un medio escrito, y no cada ápice de esos pensamientos que se serializan permanecerán cuando se deserialicen. Aunque podemos capturar parcialmente nuestros pensamientos por escrito, es un formato con muchas pérdidas.
El problema (como lo veo) es que los gerentes de proyectos y otras personas de negocios piensan en los proyectos como una serie de pasos que a menudo se pueden reordenar a voluntad (a menos que haya una dependencia explícita en su diagrama de Gantt) y se puedan distribuir fácilmente entre las personas o retrasado hasta que sea más conveniente para el negocio.
Cualquiera que haya realizado alguna cantidad de programación sabe que los proyectos de software no pueden tratarse como bloques de Lego para moverse de la forma que desee. Creo que la metáfora de los viajes aéreos al menos les da a las partes interesadas algo concreto en lo que pueden pensar que claramente no puede tratarse como una serie de pasos dispares que deben reordenarse por capricho. Al menos, facilita la comprensión de su punto de que hay un costo por tales interrupciones. Por supuesto, sigue siendo su decisión, pero debe informarles antes de que interrumpan un proyecto para darle otro. No seas combativo, pero ofrece información útil y la perspectiva útil del desarrollador, listo para hacer lo que necesiten de ti, pero solo ofreciéndoles información que tal vez no conozcan si no les dices.
En breve:
- Escriba todo lo que está a punto de hacer, incluso si no cree que alguna vez podría necesitarlo. Incluso un lápiz corto supera un recuerdo largo.
- Haga una lluvia de ideas sobre el panorama general en una pizarra física a la que tiene acceso persistente.
- Usted puede evitar interrupciones del proyecto si se hace responsables de las decisiones conscientes de que hay un costo de tales interrupciones, y al menos tendrá que establecer las expectativas para que sepan el proyecto tomará un poco más cuando se reanude.