Como se inicia en la carrera como Project Manager, o Administrador de proyectos

Ser PM o Administrado de proyectos, en mi caso fue cuestión de suerte o como dicen en mi pueblo "Estar en el tocadero, para que me toque"(algo redundante), ¿Porque?, por la simple razón de que se me dio la oportunidad de incursionar en el área.  

Realmente como profesional me fue necesario picar piedra, iniciar desde cero, y siempre dar la mejor versión de mi mismo. Soy egresado de la carrera como Ingeniero en Sistemas Computacionales del Instituto Tecnológico de Ciudad Guzmán (esto quedo al sur de Jalisco),  como quizás muchos de ustedes les paso, tuve empleos esporádicos mientras estudiaba, inclusive empleos donde era necesario trabajar durante las noches. Al ingresar a trabajar dentro de mi ramo inmediatamente inicie como ingeniero de pruebas,porque en ese momento era la única vacante que existía hasta el momento. Después de permanecer en el área de pruebas solicite con insistencia se me promoviera a desarrollo, estando en dicha área, la vacante como PM que fue liberada para mi, en buen momento, debido al trabajo que venia desempeñando, defendiendo mi proyecto al que fui asignado, era suficiente para que se me otorgara una  propuesta para ser el Administrador de proyectos de la empresa (evidentemente no me lo esperaba, pero me puso feliz). 

La realidad es que en lo particular creo que para ser administrador de proyectos es necesario tener ciertas actitudes y aptitudes que permitirán desenvolverte en el área, por ejemplo la mayoría de los ingenieros tienen problemas para expresarse, muchos fuimos quizás educados a ser solo receptores de información para desembocarlo a un producto final, inclusive a eso puede que nos reduzcan en algunas ocasiones en ciertas empresas. Pero el punto de todo esto es aprender, porque cada empresa de igual forma tiene sus procesos, sus metodologías, a mi parecer ninguna mejor que otra porque al final de cuentas por un camino u otro es que llegamos a entregarle un producto final a nuestro cliente ya sea interno o externo, la clave es ese producto con que calidad lo entregamos y cuanto tiempo acorde a la fecha planeada. 

Los puntos que me gustaría destacar para que un proyecto sea exitoso son:

• Una planificación y presupuesto realista a la complejidad del proyecto.
• Un equipo con los conocimientos necesarios para atender el proyecto, se vale decir no puedo o no cuento con lo que se necesita.
• Controlar los riesgos, ya que es imposible controlar todo el proyecto para que salga de A a B sin complicación, la magia consiste en saber atrapar y resolver las eventualidades.
• Empaparse del proyecto desde su inicio hasta la entrega del mismo.
• Ser un líder de proyecto no un jefe, "hay que comprometerse no solo involucrarse".
• Lo mas importante, la comunicación hacia dentro y fuera de la empresa, debo decir que es necesario en ocasiones ser hipercomunicativo.

Existen mas puntos, pero creo que debería abordarlos en otro articulo, en caso de que coincidan, no coincidan conmigo o exista alguna duda que pueda resolverles pueden comentarlo. 

El contenido que leerás en cada una de mis entradas al blog, son puntos de vista personales. 

¿Por qué es importante el cliente en el desarrollo de su producto?

Generalmente el cliente es quien tiene el conocimiento exacto de lo que quiere (en ocasiones no sabe lo que quiere y es necesario le enfoquemos), esto ayuda al equipo de trabajo en especial al analista de requerimientos a mapear las necesidades que serán atendidas por medio del producto de software que desarrollaremos para el cliente.

Todo parte de una idea, un concepto, una necesidad o un detonante que empuje al cliente a automatizar sus procesos, y brindar al cliente final un mejor servicio.

El cliente tendrá interacción en las siguientes actividades del desarrollo del software:

• Levantamiento de requerimientos macro: El cual es cuando de manera general el analista toma las necesidades del cliente con la finalidad de hacer un bosquejo macro.
• Entrevistas para levantamiento de requerimientos: En estas entrevistas se toman los requerimientos mapeados de manera macro para tomarlos como base e indagar a detalle si existe algo ya definido, si es un proceso o sub-proceso nuevo, ayudando siempre al cliente a distinguir cual es la necesidad de su empresa y cual seria un deseo.
• Validación de requerimientos: El cliente en conjunto con el analista debe ayudar a validar los requerimientos que se hubieran mapeado de manera correcta en la historia de usuario o cualquier otro artefacto (esto variara dependiendo si es desarrollo en cascada, Agile o alguna otra metodología).
• Proveer infraestructura de su proyecto: Este punto es variable dependiendo de como se vendió el proyecto con o sin infraestructura, esto quiere decir si la empresa que desarrollara el software proveerá hardware necesario, licencias del software, servicio de Internet y soporte, o en su defecto lo proveerá la empresa que contrata los servicios. Las características de la infraestructura deben ser definidas por el equipo técnico de la empresa que desarrolla el software, ya que será lo mínimo necesario para un buen funcionamiento y preparación del ambiente donde se hospedara el software con la finalidad de no tener contratiempos con las fechas de entrega.
• Validación en sitio del producto de software: Generalmente se construye un checklist con los criterios de aceptación del software, en conjunto el cliente y el analista de requerimientos, cuando el sistema se tiene en ambiente de pruebas e idealmente en el ambiente donde el sistema finalmente se hospedara entonces se realiza un recorrido punto por punto con el checklist en mano para corroborar que el sistema cumple con lo solicitado por el cliente.
• Firma de acta de entrega: Es donde el cliente plasma su firma. El acta de entrega según  la empresa varia, ya que prácticamente el cliente firmara de conformidad que está recibiendo su producto tal cual lo pidió, o parcialmente como lo pidió según los acuerdos finales, esto debido a que un proyecto por diversas situaciones entre ellas económicas, desacuerdos entre ambas empresas (de desarrollo y el cliente) o por la necesidad, el acta se ajusta para que contenga los puntos a aceptar con la firma del cliente.

Prácticamente los puntos antes mencionados serian las actividades del cliente en la ejecución de un proyecto. En esta entrada mencione al cliente, pero el a su vez puede asignar a alguien de su confianza que es "ungido" como el responsable de tener el conocimiento necesario para llevar a cabo las sesiones de levantamiento de requerimientos y validación de los mismos, en estos casos, el cliente pasa a ser el sponsor del proyecto y el ungido será el proveedor valido de requerimientos, en Agile se le llama stakeholder normalmente. 

Iniciare a administrar un nuevo proyecto....

El inicio de un proyecto depende mucho de la organización donde te encuentres trabajando, o de igual forma si trabajas por tu cuenta, también depende de la metodología a utilizar para la ejecución del mismo.

En lo particular conozco dos caminos que bien ejecutados tendremos resultados sorprendentes a largo o corto plazo según sea la opción que tomemos. Las opciones a usar podrían ser "desarrollo en cascada" o "Agile". En el caso particular del presente articulo lo explicare de manera neutra, dejando para futuras entradas ambos caminos antes mencionados. 

Básicamente deberíamos tener los siguientes elementos:

• Un cliente con la necesidad de resolver su problemática, o gestionar su flujo de trabajo por medio de una aplicación, un sistema o el conjunto de ambos.
• Requerimientos bien definidos por parte del cliente. En ocasiones el cliente está iniciando con su negocio o está definiendo nuevos flujos de trabajo para incorporarlos al ya existente, por lo que necesitan de ayuda de nosotros (el grupo de trabajo incluido el PM) para saber lo que quiere realizar y como lo desea ejecutar. 
• Equipo de trabajo conformado por analista, diseñador, DBA, desarrollador de software, ingeniero de pruebas y un PM con el conocimiento necesario que demande el proyecto. En ocasiones una sola persona ejecuta todas las tareas, lo cual podría tornar complicada la situación.
• Herramienta de trabajo para el equipo de trabajo en sus respectivas áreas.

Bueno teniendo todo lo anterior, ¿Que hago ahora?, sugiero los siguientes pasos:

1. Tener una serie de entrevistas con el cliente para detectar que es lo que necesita realmente, en muchas ocasiones el cliente se enfoca en los deseos, más no en las necesidades, por lo tanto es importante ayudar a enfocar al cliente respecto a la solución y deshacernos de esos deseos que generalmente no aportan precisamente al flujo del negocio. 
2. Iniciar en forma con el levantamiento de requerimientos para lo cual es necesaria la participación de la persona que conoce a la perfección el flujo del negocio y la analista especialista en la documentación de requerimientos, teniendo como resultado requerimientos consistentes para iniciar con la ejecución de las etapas consiguientes. 
3. Basándose en los requerimientos establecidos, se inicia con la construcción de la primera versión de la base de datos, y de igual forma la primer versión del front end para someterlo a medida de lo posible a escrutinio del cliente. Si el tiempo lo permite es importante generar prototipado de Front End y de funcionalidades importantes que tendrá el sistema.
4. Teniendo aprobada la base de datos y el front end, se inicia con la implementación de la funcionalidad solicitada en los requerimientos, y el uso de los prototipos en caso haberse construido, finalmente se integra todo lo construido.
5.  Se inicia con los ciclos de pruebas pertinentes, cada organización varía el numero de ciclos que se ejecutan sobre el software, debido a que todo depende de varios factores que hablaremos más adelante.
6. Por ultimo se implementa y entrega el sistema al cliente.

Los anteriores serian el "happy path" de un software, sin embargo es importante mencionar que la mayoría de las veces no cabe en el camino correcto, ya que suelen presentarse ciertas situaciones que nos obligan a tener desviaciones en la planificación.

En los próximos capítulos les platicare de "SCRUM" y "Desarrollo en cascada".

Estaré atento a sus comentarios, y retro-alimentación ya que, cada quien vive estos temas de manera distinta, no mejor ni peor.

Equipos de trabajo multidisciplinarios y nuevas estructuras de trabajo.

Debido a los cambios tan drásticos en la industria del software en general, y claro, en los cambios que existen en el desarrollo profesional de las nuevas generaciones considero que esto impacta positivamente en las formas de trabajar sobre todo en nuestro rubro.

En lo personal me tocó vivir la transición de pasar de una estructura piramidal en la que al final se perdía la comunicación existente entre los niveles de jerarquía de la organización en los grupos de trabajo, a conjuntos de trabajo flexibles en los cuales todos tenemos la misma importancia y peso en las toma de decisión de un proyecto.

Al iniciarme como administrador de proyecto fue que aprendí esta forma de trabajar, no es algo inventado por mí, si quiera fue algo inventado por quien me mostró esta vía de dirigir, Carlos Martínez. Dicha estructura de trabajo consiste en pulverizar las tareas (no de manera exagerada) de tal forma que empoderamos a cada uno de nuestros miembros de la fase de desarrollo en la cual están participando, y por ende en sus actividades. Es importante darse cuenta que debemos descentralizar las decisiones, hacer partícipes a cada uno de los miembros en los pasos que se van ejecutando, y sobre todo compartir la responsabilidad de las acciones teniendo vías de comunicación bi-direccionales abiertas.

Una vez explicada la estructura de la organización, empoderamiento de los miembros del equipo y descomposición de las tareas, pasamos al tema que nos atañe, los equipos multidisciplinarios, los cuales de manera textual son un conjunto de colaboradores con diferentes capacidades y aptitudes profesionales llámese analista de requerimientos, desarrollador de software, diseñador (UI/UX), DBA, arquitecto, tester, administrador de proyectos, entre otros...lo anterior es manera textual, sin embargo, ¿De qué nos sirve un conjunto de personas con habilidades diversamente requeridas para el proyecto?, la respuesta seria que dependiendo de la disponibilidad de los colegas de trabajo, es necesario intentar invitar/asignar actividades a las personas que tienen alta experiencia en la habilidad requerida, y de igual forma el complementar con colegas que está iniciándose dentro de la misma habilidad o que tiene poco trayecto en la misma, con el fin de que preparamos a nuestro equipo de trabajo de manera íntegra, para afrontar los proyectos de reciente creación o darle seguimiento al que actualmente está involucrado, teniendo como resultado eliminar la dependencia de sobre-asignar o saturar a un colaborador (independientemente el área de expertise) evitando así centralizar las tareas a alguien que naturalmente podría tener un problema de salud, participar en algún otro proyecto o verse en la necesidad de abandonar la empresa. En lo particular no me cierro a que los proyectos sean conformados solo por personas con un alto nivel de conocimientos en su área, me aseguro que el colega que recién está iniciando dentro de su formación como analista, desarrollador, DBA, etc. participe de manera activa pero con una baja interacción dentro del proyecto e ir incrementando paulatinamente su involucramiento dependiendo de su desempeño y resultados.

Dichos los dos puntos anteriores no nos exenta de que los administradores de proyecto mostremos o defendamos el proyecto al final del proceso ante el cliente, pero si ayuda a que la liberación en la comunicación y toma de decisiones hagamos participes a cada uno de los miembros del equipo y lo defienda como suyo.

Por ultimo les comento que en este año estaré estudiando y poniendo en práctica el concepto de equipos de alto desempeño, los resultados espero sean positivos, de igual forma les compartiré mi experiencia al respecto.

Estaré atento a sus comentarios, y retro-alimentación ya que, cada quien vive estos temas de manera distinta, no mejor ni peor.

BIENVENIDOS A EL RINCÓN DEL PM

Blog realizado desde la inquietud de compartir la mucha o poca experiencia que tengo dentro de la administración de proyectos de software, espero de igual forma leer tus comentarios y aportaciones.

Angel Sánchez