Cuando no existen procesos ¿Que debemos hacer? - Capítulo 1

Generalmente empresas de reciente creación nacen evidentemente sin procesos, conforme las mismas van creciendo, se inician a crear estructuras, departamentos, según sea el caso de la compañía y los servicios que ofrece en el mercado; en lo que a mí concierne desarrollare el tema en torno a los departamentos de software, que es donde mayormente se encuentra mi trabajo como Project Manager.

Partamos de que los procesos no son mágicos, esto quiere decir que el generar los procesos solo por escribirlos aporta 0% para mejorar el funcionamiento del departamento de software, de hecho una incorrecta implementación podría provocar resistencia al cambio dentro de los equipos y por ende romper las formas de trabajo actuales preexistentes. Intentare desmenuzar por puntos ordenados como en mí experiencia profesional ha funcionado:

1. Contar con experiencia en procesos y/o metodologías de desarrollo de software: Parece obvio, pero es importante contar con participaciones en la implementación procesos, evaluando procesos y/o sobre todo conocer metodologías de trabajo orientadas a desarrollo de software, esto dará solides a la redacción de tu trabajo implementación del mismo, y las herramientas para desatar ciertos "nudos" que pueden hacerse en cualquiera de los puntos a tocar. 
2. Conversar con los directivos e involucrados: Es importante que antes de realizar cualquier sugerencia en cuanto a generación/implementación de procesos exista un dialogo abierto entre los directivos e involucrados con los procesos; esto con la finalidad de saber que se tiene el apoyo del, o los directores, y las personas relevantes en cada una de las áreas encargadas de tomar decisiones en alto y bajo nivel, de igual forma la persona encargada de redactar, y ejecutar la implementación de procesos debe tener la autoridad/facultad para levantar incidencias y corregir a los miembros del equipo que incumplan los procesos, sin importar si es el director, el team lead o algún miembro del equipo. Para formalizar el área de procesos, y la posición del encargados de procesos es importante dejarlo asentado en un acta y si es posible establecerlo en un organigrama. Sin la participación de todos ellos(directores y team leads) será más complicado ya que deben respetarse los procesos en todas las alturas del organigrama. 
3. Observar las formas de trabajo actual: La observación del equipo de trabajo y como funcionan en la actualidad, es importante ya que debe revisarse como es que se toman las decisiones sobre las actividades a realizar, investigar si existen flujos de trabajo internos o externos que puedan trasladarse a los procesos, como capturan los requerimientos, como se les da seguimiento a los mismos, como se planean las actividades, que tipo de proyectos se están realizando y para quienes van dirigidos, entre otros. Debe observarse desde todas las áreas establecidas en la empresa, inclusive debe llevarse más allá la observación y anotar las sugerencias sobre las áreas que podrían estar faltando para llevar a cabo un proceso en el desarrollo de software lo más completo y limpio posible. 
4. Conversar lideres dentro de la empresa: Personas importantes en la implementación de los procesos son los lideres encargados de los proyectos, de células de trabajo y generalmente encargados de tomar decisiones a bajo nivel. La conversación debe ir orientada a saber como es que sé está trabajando actualmente en sus equipos tomando nota de los temas relevantes a tomar en cuenta, es decir lo que ya se cree sé está implementando y lo que podría estar haciendo falta para completar el ciclo de trabajo. Si es posible obtener feedback referente a su experiencia profesional en algunas otras empresa, con la finalidad de enriquecer las formas de trabajo. Toda la platica que se pueda tener lideres de proyectos debe ser para librar dos objetivos, el primero y muy importante es para hacerlos sentir suyo él o los procesos involucrándolos en la construcción de los mismo, y la otra muy importante que ya mencione con anterioridad es que no debemos romper las formas de trabajo actuales, "traumando" y "estrangulando" lo menos posible sus actividades actuales.

Por el momento les dejare los puntos actuales, esperando surjan dudas muy concretas por favor háganlas sabes sobre los comentarios o directamente a mi correo personal angelfsanchezn@gmail.com, con gusto les responderé. El siguiente capitulo (2 de 2) se centrara en la creación de artefactos para los procesos, ejecución de los procesos y evaluación de los mismos.

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

Desarrollo de software: Deseo VS necesidad

En ocasiones es complicado alinear al cliente referente a los requerimientos del sistema, mostrándole que es una necesidad real en su producto, y que es un deseo. Para iniciar mostrare la definición tal cual nos la da la real academia de la lengua española:

Necesidad: Aquello a lo cual es imposible sustraerse, faltar o resistir.

Deseo: Anhelar que acontezca o deje de acontecer algún suceso. 

Partiendo de las anteriores definiciones, y trasladándolo a desarrollo de software es importante conversar con el cliente el porque es relevante basar su producto en las necesidades reales de su empresa y operaciones como primer lugar, y posteriormente agregar los deseos expresados que podrían agregar un plus al sistema o producto a desarrollar.

La mayoría de las metodologías hoy en día nos instan a generar un primer MVP (Most Valuable Player), lo que en español significa producto mínimo viable, esto debido a que es importante ayudar a madurar el producto con lo esencialmente necesario para ser lanzado al mercado y tomar métricos de retorno con la finalidad de saber si vamos por buen camino o es necesario virar en otro sentido en caso de que las el producto no este retornando lo que se esperaba (eso será tema de otro post), ya que, quien marca "el buen camino" es el cliente/ mercado y no el Stackholder, el Project Manager o los libros.

Teniendo las piezas armadas, deseos y necesidades separadas es importante dirigirse a revisar que metodología se utilizara y cual es el camino a seguir, les dejo un post anterior donde hablo acerca de ello. 

Si tienen alguna duda para ampliar el tema, puede dejarlo sobre los comentarios o mandarme un correo electrónico. 

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