Technology Based CRM

Se puede definir un proyecto como, la suma de actividades interrelacionadas a realizar con una meta en común, y es la de conseguir un nuevo producto, servicio o cual fuese el resultado esperado.

“Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único”. Program Management Institute. Guía de Fundamentos para la Dirección de Proyectos (6ta edición) Pennsylvania: Guía del PMBOK. (2017, p 4)

Sin embargo, para poder alcanzar el objetivo de un proyecto, se debe seguir una metodología, la cual te asegure el éxito en la gestión del mismo. Hoy en día es común hablar de metodologías agiles, para el desarrollo de proyectos. Estos conceptos contrastan con metodologías como la del PMI. A continuación, se desarrollará una introducción general y la diferencia entre cada una de ellas.

Enfoque del PMBOK.

Creada por el Program Management Institute (PMI), en su primera versión del año 1996, es el estándar del PMI para la Dirección de Proyectos, esta no es una metodología, sino una norma de dirección de proyectos. Esta norma o estándar, no está restringida solo para proyectos de TI, puede ser aplicable a cualquier tipo de proyectos, desde la construcción de una Central Hidroeléctrica, hasta el plan para construir un nuevo salón de clases en un colegio. Es así pues que no se trata de una metodología, donde hay que seguir paso a paso para obtener un resultado, es más bien como ya se ha mencionado un estándar aplicado a la dirección de proyectos, donde el Director de Proyectos (cargo clave en esta dirección) deberá de acuerdo a su experiencia seleccionar dentro de las áreas de conocimiento y sus procesos los que más se adecuen al logro de su objetivo de proyecto.

El PMBOK se basa en el desarrollo de 10 Áreas de conocimiento donde se distribuyen todos los aspectos de la Dirección de Proyectos, iniciando desde la Integración del Proyecto, con el “Acta de Constitución del Proyecto”, y pasando a definir cada acción o plan en las diversas áreas a través de los 49 procesos, desplegados dentro de los 5 grupos definidos dentro del Ciclo de Vida de la Dirección de Proyectos. Cabe mencionar que este estándar es aplicable a cualquier industria. A continuación, se mencionará brevemente cada uno de ellos:

Áreas de Conocimiento:

Gestión de Integración del Proyecto. Esta parte es específica para los directores del proyecto, es donde se definirán los procesos y actividades de la dirección, entre los cuales destacan el acta de constitución y el de cierre de proyecto.

Gestión del Alcance del Proyecto. Definir el objetivo del proyecto, así como los procesos que aseguren lograr con el mismo. Define que incluye y que no incluye el proyecto.

Gestión del Cronograma de Proyecto. Define los procesos requeridos, sus tiempos de ejecución, secuencias, cronogramas y controles para gestionar el proyecto de forma óptima y llegar a su fecha de cierre acordada.

Gestión de los Costos de Proyecto. Define principalmente el presupuesto del proyecto, y como se va gestionar y controlar a lo largo de la ejecución del mismo.

Gestión de la Calidad de Proyecto. Asegura que el resultado desarrollado sea el esperado. Define los procesos y controles para asegurar lo indicado.

Gestión de los Recursos del Proyecto. Asegura que los recursos solicitados, ya sean lo referido a colaboradores o logísticos, sean los adecuados y estén disponibles en el momento y lugar idóneo para la ejecución del proyecto.

Gestión de las Comunicaciones del Proyecto. Asegura que la comunicación a lo largo del desarrollo del proyecto sea la adecuada. Consta principalmente de dos partes: Desarrollar una estrategia para asegurar que la comunicación sea eficaz para los interesados, es decir que reciban la información que sea necesaria para cada rol. Y la segunda Implementar la estrategia de comunicación, a través de los medios y canales adecuados para el despliegue.

Gestión de los Riesgos del Proyecto. Enfocado en analizar, identificar y monitorear los riesgos, así como asegurar el plan de implementación de respuestas a cada uno de ellos. En suma, es asegurar los factores de éxito del proyecto y minimizar los riesgos del mismo.

Gestión de las Adquisiciones del Proyecto. Se refiere a los procesos para la compra de productos o servicios necesarios para la culminación del proyecto, los mismos que no participan del producto final, pero que son necesarios para completar el proyecto. Entre los cuales están las cotizaciones, identificación de proveedores con experiencia y la documentación necesaria para legitimar la compra.

Gestión de los Interesados del Proyecto. Es de suma importancia identificar a las personas que pueden afectar o ser afectados por el proyecto. A estos se les denomina interesados, dado que de una u otra forma tienen un impacto en el proyecto. Este proceso debe ser continuo y debe buscar involucrar a los mismos.

Ciclo de Dirección de Proyectos. La dirección de proyectos, está conformada por 49 procesos desplegados en 5 grupos.

Figura 24. Grupos de procesos de la Dirección de Proyectos.

Fuente: Elaboración propia.

Cabe señalar que un proceso es un conjunto de actividades relacionadas con un objetivo común. Cada proceso dentro del enfoque PMI está conformado por entradas, herramientas, técnicas y salidas. Los que a su vez pueden interactuar entre sí.

Figura 25. Estructura de un Proceso PMI.

Fuente: Elaboración propia.

Procesos de Inicio. Sirven para definir el inicio de un nuevo proyecto, o una nueva fase de uno existente. Constan de 2 procesos

Procesos de Planificación. Establecen el alcance del proyecto, redefinen objetivos, sin que diste mucho del inicialmente planteado y define el cronograma. Constan de 24 procesos.

Procesos de Ejecución: Procesos que aseguran completar los trabajos definidos para alcanzar los objetivos del proyecto. Constan de 10 procesos.

Procesos de Monitoreo y Control. Procesos que hacen seguimiento a los trabajos realizados, asegurando que se encuentren dentro de lo programado en tiempo y esfuerzo. Identificar las áreas donde se requieran cambios en el plan de acción e iniciarlos según los planes de respuesta. Consta de 12 procesos.

Procesos de Cierre. Proceso que se encarga de cerrar formalmente el proyecto. Asegurando que cada proceso, culminó satisfactoriamente. Consta de 1 proceso.

La salida de un proceso por lo general es la entrada de otro, de esta forma los procesos se encuentran mayormente relacionados entre unos y otros. Así mismo los grupos de procesos se pueden traslapar a lo largo del desarrollo del proyecto, como se puede visualizar en el siguiente gráfico.

Figura 26. Interacción de los grupos de procesos.

Fuente: Guía de los Fundamentos para la Dirección de Proyectos (6ta edición) Pennsylvania: Guía del PMBOK (2017, p 555).

A continuación, se muestra la matriz de procesos del PMI, también se adjunta como anexo N° 3, para facilitar su visualización. Esta matriz muestra la relación entre grupo de procesos y áreas de conocimiento.

Fuente: Guía de los Fundamentos para la Dirección de Proyectos (6ta edición) Pennsylvania: Guía del PMBOK (2017, p 556).

Metodología SCRUM.

La primera vez que se cita el termino SCRUM (melé, que hace referencia a una jugada de rugby), fue en un artículo publicado por la Harvard Business Review, en el año 1986. Cuyos autores fueron Hirotaka Takeuchi y Ikujiro Nonaka. En dicho artículo, hace referencia a la nueva visión que se daba en el desarrollo de nuevos productos, dentro de las empresas de manufactura tecnológica y automotriz japonesas, donde dejan de lado las clásicas teorías de administración piramidal, secuencial, objetivos duros, para dar paso a un enfoque de equipos multidisciplinarios, colaborativos y altamente comprometidos, con objetivos a corto plazo, para entregar los productos de forma más rápida, en un entorno altamente cambiante. Se citará tres párrafos de dicho artículo, los cuales nos ayudaran a cimentar el enfoque ágil:

“El enfoque tradicional, secuencial o de "carrera de relevos" para el desarrollo de un producto, puede entrar en conflicto con los objetivos de inmediatez y flexibilidad. En cambio, un enfoque holístico o de "rugby", donde un equipo trata de recorrer la distancia como una unidad, pasando la pelota de un lado a otro, puede servir mejor a los requisitos competitivos de hoy en día.”

“Un equipo de proyecto, empieza a trabajar como una empresa, cuando esta toma iniciativa, asume sus propios riesgos y desarrolla una agenda independiente a la unidad de negocio a la que pertenece. En algún momento el equipo crea su propio concepto de manejo. De esta forma un equipo posee una capacidad de auto organización cuando posee tres características: Autonomía, auto transcendencia (se refiere a fijar sus propias metas) y fertilización cruzada (equipos multidisciplinarios son más apropiados para la innovación)”.

“Debido a que los miembros de un equipo se encuentran cercanos a fuentes de información externa, ellos pueden responder rápidamente a cambios en las condiciones del mercado. Estos equipos comprometidos con procesos constantes de aprendizaje, a través de pruebas de ensayo error, encuentran la mejor alternativa de solución del proyecto. El equipo multidisciplinario, adquiere conocimientos y habilidades que les ayuda a resolver una variedad de problemas rápidamente. Este aprendizaje se

manifiesta en varios niveles (individual, grupal y corporativo) y en múltiples funciones, a lo que denominan el Multi Aprendizaje.”

The New Product Developement Game, por Hirotaka Takeuchi (Hitotsubashi University) y Ikujiro Nonaka. Harvard Business Review, enero-febrero de 1986.

En el año 1995, durante la Conferencia OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) organizada por la ACM (Association for Computing Machinery). Los señores Ken Schwaber y Jeff Sutherland, hicieron publica esta metodología, refiriéndola inicialmente hacia el ámbito de TI. Su más reciente aporte hacia esta metodología, de sus autores fue la publicación The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game (2017), de donde se extrae dos conceptos importantes:

“La esencia de Scrum es un pequeño equipo de personas. El equipo individual es altamente flexible y adaptativo. Estas fortalezas continúan operando en un equipo, en varios, en muchos y en redes de equipos que desarrollan, liberan, operan y mantienen el trabajo y los productos de trabajo de miles de personas. Ellos colaboran e interactúan a través de arquitecturas de desarrollo sofisticadas y ambientes finales de liberación”.

“Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo”.

Se puede definir entonces a SCRUM como una metodología ágil, aplicable a entornos altamente dinámicos y complejos, donde es probable que el objetivo pueda cambiar de su concepción inicial hacia una nueva, debido a la dinámica del mercado o del escenario donde se desenvuelva este. Esta metodología no es aplicable a escenarios rígidos con requisitos estables y productos poco innovadores. Se basa en equipos multidisciplinarios, que se toman como una unidad, altamente comprometidos con el proyecto, con alta creatividad y su esquema organizativo es lineal, es decir todos tienen la misma jerarquía.

Una de las principales características de esta metodología, es que trabaja por interacciones, es decir no es secuencial, siguiendo los valores del Manifiesto Ágil. Las características del entregable final, son abordados por fases, y en cada una existe un entregable, que son priorizadas por riesgo y el valor aportante para el negocio. La

planificación entre fases puede ser cambiante, he ahí donde radica su principal diferencia con un enfoque tradicional.

Para ahondar este tema, se abordará el Manifiesto Ágil, documento redactado en el 2001, por 17 expertos en el desarrollo de software, quienes acordaron que las técnicas hasta ese momento conocidas ya no eran aplicables, debido a su rigidez y a la distancia que existía con las realidades cambiantes. Dentro de este manifiesto, se proponen 4 valoraciones y 12 principios, las cuales mencionamos:

Valoraciones:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Principios:

Nuestra mayor prioridad es satisfacer al cliente, mediante la entrega temprana y continua de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Recuperado de https://agilemanifiesto.org.

Dentro de la metodología existen tres roles, siete actividades y tres artefactos, los cuales se mencionarán a continuación.

Roles:

Product Owner. Es el que desempeña la voz del cliente dentro del equipo, el cual debe conocer muy a detalle las características del producto esperado, capaz de priorizar actividades de desarrollo. Su rol es muy activo y es el nexo entre el equipo de desarrollo y los stakeholders (los interesados en que el proyecto se realice, pueden ser internos o externos).

Scrum Master. Líder del equipo, su función principal es ser un facilitador del equipo (no es un jefe), debe aclarar dudas procedimentales o buenas prácticas de SCRUM y liberar impedimentos al equipo de desarrollo.

Development Team. Son los responsables de todas las tareas técnicas (diseño, desarrollo, pruebas), no tienen un rol específico dentro de estas, pero cada uno lo desempeña de una forma ordenada y específica, sin embargo, su conocimiento es muy especializado en algún área, sin descuidar las demás dentro del ámbito de TI. Un equipo puede estar conformado entre 5 y hasta 9 personas, no suelen ser muy grandes.

Figura 28. Roles dentro de la Metodología SCRUM.

Fuente: Rubin, K.S. Essential Scrum: A Practical Guide to the Most Popular Agile Process (2012, p 15).

Actividades: Dentro de esta área se describirá el framework o plataforma general dentro de un proyecto SCRUM. Partiendo desde la premisa que es el Product Owner, el que conoce las necesidades del cliente y las clasifica o prioriza según el riesgo o valor de negocio del cliente, es decir los de mayor impacto.

Sprint. Se denomina al ciclo que forma parte de un proyecto, pero como tal, tiene un objetivo, un plazo y sobre todo un entregable o lo que se denomina Producto Terminado. Un sprint puede iniciar un proyecto o continuar cuando finalice con otro sprint, dentro de la cadena de actividades identificada. Dentro de un Sprint ya iniciado, no puede cambiarse los objetivos (Sprint Goal) o plazo. Por lo general, estos no duran más de un mes y se realizan dentro lo que se denomina un Time Box. El sprint, al ser un ciclo, está compuesto por otras actividades que se seguirá desarrollando.

Sprint Planning. Se desarrolla con la participación de todo el equipo SCRUM, y es el plan del desarrollo del Sprint, este tiene como máximo 8 horas de duración para un time box de 1 mes, luego debe ser proporcional. Durante esta `planificación se desarrollan dos preguntas: ¿Qué puedo hacer durante el Sprint?, se refiere al alcance del Sprint o mencionado también como el incremento del Producto Terminado; la definición del mismo, parte del Scrum Master, pero es consensuado por todo el equipo, quienes es base a los recursos y plazos máximos definirán los elementos del producto a desarrollar o el Sprint Goal. ¿Cómo conseguiré completar el trabajo seleccionado? El equipo SCRUM decide el orden del desarrollo de las características seleccionadas, y el plan para desarrollar, lo que finalmente serán incrementales del producto terminado, a este

último se le denomina Sprint Backlog. Cabe mencionar que cada incremental o Sprint Goal terminado es un entregable al Stakeholder externo y puedo ser implementado en el negocio.

Daily Scrum. Es una reunión de máximo 15 minutos, donde participa todo el equipo, todos de pie, y ayuda a dar una revisión del status del proyecto. Normalmente se responden tres preguntas. ¿Qué hice ayer para ayudar al equipo alcanzar el objetivo? ¿Qué hare hoy para ayudar alcanzarlo? Y ¿Qué impedimentos tengo o avizoro que impedirán que se alcance el Sprint Goal? Normalmente respondidas por el equipo de desarrollo. Estas reuniones permiten tener un feedback rápido del estado del proyecto, por eso se le denominan Ciclos de Inspección y Adaptación, si luego de esto, es necesario profundizar el tema, será el equipo de desarrollo quien lo lleve a cabo, pero fuera del Daily Scrum.

Sprint Execution. Se refiere a la ejecución de las actividades para cumplir con las características a implementar, dentro de este esta las actividades propias de desarrollo: codificación, pruebas, despliegue. Todo lo referido a la técnica de desarrollo de software.

Sprint Review. Es una reunión con todos los integrantes del equipo SCRUM, junto con los Stakeholders, en la cual se muestra el producto terminado, a través de una demo, mostrando haber alcanzado los objetivos del Sprint. En esta reunión se busca la conformidad por parte del cliente hacia el entregable.

Sprint Retrospective. Son reuniones dentro del equipo de proyecto para analizar el despliegue que se está llevando a cabo, si es el correcto o es necesario realizar algún cambio. No se analiza el entregable, sino la planificación de los Sprint o la concepción del proyecto.

Product Backlog Gromming. Como ya se ha mencionado el Product Owner es quien conoce y está cerca al cliente y a sus necesidades inmediatas, es así que puede reorganizar la lista denominada Product Backlog, priorizando actividades.

Cabe mencionar que un Proyecto SCRUM puede estar conformado por varios Sprint, de hecho, esa es la ventaja de esta metodología, al dividir un objetivo general, en varios partes, pero que cada una es de rápida aplicación al negocio.

Artefactos: Son representaciones de la gestión realizada por el equipo, se denominan a todo aquello que ayude a tener la información de una forma transparente y de rápido entendimiento, que ayude a conseguir el objetivo.

Product Backlog. Es la clasificación que realiza el Product Owner, según las necesidades del cliente en base al valor del negocio o su impacto para el cliente. Se puede decir que es una lista agrupada de características a desarrollar del producto final, donde a cada una de ellas, tiene un valor funcional incremental respecto a la anterior. Esta lista no es estática y puede ir cambiando de acuerdo a las necesidades del cliente o del escenario del mismo, a esta reclasificación se le denomina Grooming, consiste en priorizar, desclasificar, desestimar, agrupar o descomponer actividades a desarrollar.

Sprint Backlog. Parte de lo realizado en el Sprint Planning y en su priorización que este tiene, consiste en que el equipo de desarrollo toma las características a desarrollar y define un orden y un plan de ejecución calendarizado, de acuerdo al plan y a los tiempos límite con los que se cuenta.

Potencially shipeable product increment. Es el artefacto terminado, dentro de las