Cómo administrar un proyecto cuando está congelado/retrasado por un tiempo indefinido

Question

En este momento, estoy extremadamente frustrado porque estaba en el proceso de desarrollar un mecanismo genial para optimizar un sistema de cálculo al reducir el número de cálculos de alrededor de medio millón a solo unos pocos miles. Tomó mucho tiempo examinar y analizar datos, escribir cosas, hacer algunas pruebas y, en general, hacer mi trabajo. Luego tuvimos una reunión de proyecto. Le expliqué lo que quería hacer, cuánto tiempo tomaría y cuánto podría mejorar el proyecto e incluso permitir la creación de nuevas funciones. Luego se decidió que era demasiado tiempo para hacer esto antes de la próxima fecha límite. (Una fecha límite que tendría que extenderse si se me permitía continuar). Una lluvia de ideas rápida dejó en claro que hay una solución fácil de usar que podría usarse en su lugar, lo que demoraría la optimización por unos meses más.

Bueno, ¡duro!

Bien ... Acabo de escribir la frustración. Ahora la pregunta ... ahora tengo todo este diseño en mi cabeza. Gran parte de ella son solo esquemas y papeles con texto escrito a mano, algunas impresiones e incluso algunas preguntas aquí en SO. Estas ideas se congelarán por un tiempo, pero tendré que recordarlas en el futuro nuevamente. Puedo obtener un día, tal vez dos para limpiar las notas y comenzar a documentar las cosas.

Así que necesito consejos sobre cómo recordar mejor mi diseño en, por ejemplo, 4 meses a partir de ahora. O quizás dentro de un año ... ¿Cuál sería el más importante de anotar? ¿O documento? (Considerando el poco tiempo que tengo ...) ¿Alguna sugerencia?

¿Por qué? De lo contrario, me sentiré frustrado de nuevo dentro de cuatro meses. :-)

Answer 1

Depende de lo que funcione para usted y cómo le gusta aprender. Me gusta usar diagramas, así que en la situación en que diseñé un algoritmo genial (¡aunque nada tan complejo!) Hago lo siguiente:

1) Dibuje el algoritmo en papel o escríbalo .

2) Añada anotaciones para que complete sentido para usted.

3) Describe el algoritmo para otra persona solo a partir de lo que dibujaste. Esto le impide rellenar espacios en blanco de su propio conocimiento del algoritmo.

4) Si hay lagunas en su descripción, agregue detalles adicionales a medida que avanza, para que el documento se convierta en un registro completo de su descripción.

5) Guarde el dibujo durante una semana y vea si todavía tiene sentido. En este punto, aún debería ser lo suficientemente familiar como para agregar detalles faltantes.

Ya sea que sea lo suficientemente claro dentro de un año, o si incluso querrá usarlo, queda por ver.

Espero que ayude!

Answer 2

En mi experiencia, los diseños antiguos siempre parecen rancios cuando se desempolva. En los próximos meses, el código existente cambiará, los requisitos cambiarán y usted cambiará como programador. Tal vez deberías escribir una breve explicación y asumir que tendrás que volver a trabajar en el futuro de todos modos.

No te frustres con proyectos específicos, centra tu energía en mejorar como desarrollador. Y lleva esa experiencia contigo.

Answer 3

Un documento de requisitos detallados que describe todas las entradas y salidas es probablemente una de las mejores maneras de comenzar. Si se trata de un diseño de código muy exclusivo, el metacódigo podría ser un buen paso. es decir.

[Meta Object] 

    [Return String(string param1, string param2)] 

     Return param1 + " " + param2 

    [Return Integer(integer param1, integer param2, integer param3)] 

     Return (param1 + param3)/param2 

[End Meta Object] 

Hacer que se vea algo similar a su idioma w/o pruebas ni nada, acaba de obtener el log C teórica sobre el papel (bloc de notas) de esa manera usted tiene un trampolín cuando/si alguna vez tiene que volver a ella ... luego documenta la luz del día.

Answer 4

En cuanto a la frustración, generalmente intente ver un proyecto como un viaje en lugar de un destino.

Si ha estado prestando atención, habrá sacado mucho provecho del proyecto hasta la fecha: cosas que ha aprendido sobre la tecnología y el negocio, ha creado módulos de código que puede volver a utilizar, habrá creado las relaciones con los miembros del equipo o los usuarios, cometieron errores que no cometerá de nuevo, y así sucesivamente. Podría ayudarte personalmente a escribir una lista de lo que sabes ahora que no hiciste al comienzo del proyecto.

En última instancia, es posible que la empresa no haya implementado el proyecto, pero gran parte de los beneficios que acumula como persona y como desarrollador todavía existen. De hecho, a menudo aprendes más sobre proyectos que salen mal y en empresas que no son tan buenas como cuando las cosas funcionan como un sueño.

Al igual que con el resto de la vida, mientras más satisfacción obtengas de las cosas día a día, y cuanto menos te centres solo en los logros de la marquesina, más feliz estarás.

No digo que entregar proyectos no es bueno, obviamente es por eso que codificamos, pero no está completamente bajo nuestro control, por lo que debe ser realista y equilibrado sobre cuánto permite que eso le afecte.

(el vínculo obligatorio a algo o Joel Jeff escribió: http://www.codinghorror.com/blog/archives/001297.html)

Answer 5

Si ha encontrado la solución una vez, hay muchas posibilidades de que encontrará a cabo solución incluso 4 meses en la línea para el mismo problema. Lo que NO DEBE perderse es el problema real.

Debe anotar todos los problemas de optimización que son las fuentes de problemas o los problemas reales. Debe mantener nítidamente las notas de estos problemas problemáticos.

Ahora, la próxima vez [digamos 4 meses en la línea] cuando quiera volver a esto. Solo necesita leer los problemas de sus notas, y su cerebro comenzará a trabajar en la dirección correcta como lo hizo anteriormente.

Para hacerlo aún mejor, puede intentar revisar las notas del problema una vez cada mes o dos. Esto entrenará a su cerebro hacia la solución, ya que cada vez terminará con la solución tal como lo hizo por primera vez.

Además, si puede escribir el problema o inquietud que realmente lo motivó lo suficiente como para luchar por la solución, sería genial.