Project Management

En mi tiempo como Freelance llevando proyectos con clientes nuevos y no tan nuevos, he sumado una experiencia competitiva a la hora de encaminarnos a lo que en realidad necesitan para su negocio. Si tú eres una persona independiente como yo, te habrás dado cuenta que lo más complicado es explicarle a un usuario “no técnico” los requerimientos principales de software que satisfaga su negocio. Si, estoy de acuerdo, el “cliente siempre tiene la razón”, pero también toca tomar un enfoque que no dañe los requerimientos de software y que el proyecto salga a producción exitosamente....

He escrito mucho de requerimientos pero no me he explayado en este aspecto sobre todo si alguien viene iniciando, no sabrá de qué estoy hablando. Los requerimientos son las piezas fundamentales de todo proyecto de desarrollo software ya que nos dan la pauta para la planeación, podemos dictar costos y manejar recursos, “tener claro lo que se va a hacer durante la ejecución del proyecto, es clave para el éxito del mismo”....

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....

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....