domingo, 9 de abril de 2017

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.

lunes, 20 de febrero de 2017

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.

jueves, 26 de enero de 2017

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