concepts

Apenas el post pasado, fui un poco duro al mencionar un proyecto realmente malo y mencionaba al postmortem como una posibilidad de reivindicar los errores para lo que viene, porque no significa que si tuviste un proyecto malo, los posteriores tengan que serlo. Así que profundizaré en eso. Por ahí dicen que “de las victorias debes aprender, pero aún más debes aprender, de las derrotas”. En todo proyecto de software al haber concluido bien o mal, es importante tener un análisis postmortem para revisar toda la historia y ver los puntos claves en donde se falló y en donde se hicieron bien las cosas....

Un día común y corriente en un proyecto altamente exigido, llámese altamente exigido a ese proyecto que es un dolor de “##@)($#)”, ese proyecto que solo recordarlo te da nauseas de lo malo que fue, se acerca un PM (Project Manager) a enriquecer un requerimiento que estaba más confuso y tan nublado como la contaminación de la Ciudad de México. Y bueno solo se acercó a el equipo para decirnos que el requerimiento estaba incompleto y que estaba todo mal, que justo todos sabíamos que estaba incompleto solo que él pensaba que no lo sabíamos....

Si, hay mil maneras de hacer bien las cosas, pero también hay mil maneras de cagarla, sobre todo cuando vienes iniciando y te toca elegir la tecnología de un proyecto, te recomiendo que leas algo sobre la deuda técnica, antes de tomar decisiones sobre qué tecnologías usar. El objetivo de un proyecto de software, es que funcione y aún más importante, que durante el paso del tiempo pueda “escalar”. Yo no conozco ningún sistema productivo altamente exigido, que durante su ciclo de vida, no se le pida más, el objetivo es siempre crecer....

Entender… Algo que no todo el mundo tiene la cualidad de profundizar demasiado y me incluyo, cuando algo no te agrada y le sumas que hay que entenderlo, puede ser complicado. Pero es parte del trabajo, parte del día a día, no siempre te van a tocar requerimientos simples y que te complazcan. Es parte del crecimiento profesional enfrentarse a problemas cada vez más grandes y con soluciones un poco más reducidas....

Cuando me topé con este término alguna vez, recuerdo fue un proyecto demasiado burocrático, el cliente tenía un área de tecnología y un equipo de desarrollo backend, nosotros éramos el brazo armado por frontend, la comunicación con analistas y desarrolladores del otro bando era algo común. Así que pensé, ¿Quiénes son los verdaderos stakeholders? El término significa: “Interesados del proyecto” y se le conoce a toda persona que puede influir en el proyecto, persona o grupo de personas que conocen perfectamente el negocio y esperan resultados positivos a la finalización del mismo....