Empresa y Tecnología: Gestión de proyectos TIC

PARTE I | PARTE II | PARTE III | PARTE IV | PARTE V

DESARROLLO = PLANIFICACIÓN + ANÁLISIS + DISEÑO + CONTROL

PLANIFICACIÓN

Al tratarse de un proyecto TIC, se abarca la temática del software, de los sistemas de información empresariales, de las telecomunicaciones, de dispositivos o artefactos que puedan ser considerados tecnologías de la información o de comunicaciones, por ello durante la lectura del presente documento encontrará los términos "solución TIC" o "producto" en general.

Una vez que se ha pactado, acordado o establecido claramente las expectativas del cliente, se ha definido el modelo de relación a nivel ejecutivo, de usuarios y técnico, se han identificado y formalizado responsabilidades, canales de comunicación e interlocutores, es el momento de el inicio operativo del proyecto.

Probablemente el contrato ya establezca un cronograma, en ese caso no hay mas que ajustarse a los tiempos establecidos, aunque se sepa a partir de los análisis de riesgos que por imprevistos o cambios de los requisitos en mitad del proyecto pudieran aparecer dilataciones de tiempos, es importante asumir lo que esta escrito en el contrato, negociar cuando sea el momento y conocer los procedimientos formales para anticiparse y lograr las aprobaciones necesarias en el caso de cambios en las fechas de entrega, esto es importante especialmente si el cliente es empresa pública y el proyecto es de gran tamaño tanto en tiempo como en precios, ya que existen normativas de control interno y causas establecidas en las leyes y reglamentos que pueden permitir aplazamientos o por el contrario aplicar multas al proveedor.

Muchos podrían cuestionarse y decir si se hace un buen cronograma, no es necesario aplazar nada, sin embargo la realidad indica que, aunque se diga lo contrario, el cliente de soluciones TIC suele percatarse de fallas en sus propias definiciones, carencias en los requisitos originales, observa que lo que esta hecho podría incorporar mas utilidades y en esta situación hay que saber la manera de gestionar los cambios mas los costes asociados.

Por esta razón se debe tener claro que "elaborar un cronograma no es planificar" aunque es una actividad inherente a la planificación.

Planificar es, una vez conocida la línea de tiempo o los plazos del proyecto, usar la experiencia para anticiparse y definir mecanismos de acción ante situaciones que se presentarán con mayor probabilidad, con la finalidad de asegurar los recursos y actuaciones necesarias para lograr los objetivos del proyecto. Esto implica determinar la manera en que se van a reducir riesgos, optimizar costes, corregir desviaciones.

Si se quiere una referencia para comprender la definición y el sentido de la planificación, Wikipedia (http://es.wikipedia.org/wiki/Planeamiento#cite_note-4) señala:

"La planificación, la planeación o el planeamiento, es el proceso metódico diseñado para obtener un objetivo determinado. En el sentido más universal, implica tener uno o varios objetivos a realizar junto con las acciones requeridas para concluirse exitosamente. Otras definiciones, más precisas, incluyen "La planificación es un proceso de toma de decisiones para alcanzar un futuro deseado, teniendo en cuenta la situación actual y los factores internos y externos que pueden influir en el logro de los objetivos". Va de lo más simple a lo complejo, dependiendo el medio a aplicarse. La acción de planear en la gestión se refiere a planes y proyectos en sus diferentes ámbitos, niveles y actitudes."

El cronograma seguramente nos muestra las actividades a desarrollar, los hitos principales o puntos de revisión, los costos de cada actividad, los recursos necesarios de cada actividad, el inicio y fin de cada actividad. Entonces ¿Qué más hay en una planificación?, pues documentos que dictan la forma de actuar, son documentos cambiantes que realmente se emplean para reflejar acciones durante todo el proyecto, y pueden ser los siguientes:

1. Un plan de comunicaciones, contiene las necesidades de información del cliente, los interlocutores y los mecanismos de comunicación, a nivel técnico, de usuarios y ejecutivo, aquí podrían definirse incluso los documentos y productos que se entregarán en el cierre del proyecto.

2. Plan de compras y contrataciones, si el proyecto requiere personal, que se monte una oficina, que se encargue partes del desarrollo a una factoría de software, que se entreguen como parte del mismo servidores y equipos, es necesario documentar como se llevarán a cabo las decisiones de compra o contratación, así como identificar quiénes son los proveedores, cuál es el presupuesto disponible, fechas de desembolso.

3. Plan de calidad, este documento refleja las normas, requisitos o exigencias que el ciente requiere formalmente que se cumplan para la aceptación del producto, y la manera en como se va a demostrar que efectivamente se cumplen.

4. Plan de gestión de riesgos, cada actividad del cronograma tiene asociado algún riesgo, cada objetivo del proyecto tiene asociado un riesgo, estos deben evaluarse de forma documentada y analizar si vale la pena preocuparse por los mismos. Riesgo según el PMBOK versión 4 es : "Un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo en los objetivos de un proyecto".

5. Plan de contingencia, servirá como fuente documentada que permita responder de forma eficiente ante riesgos que al materializarse provoquen efectos negativos. Por ejemplo: pérdida de energía en el data center, borrado accidental o intencionado de datos, problemas con el versionamiento del software, daños en equipos (clientes, servidores, impresoras), pérdida de las comunicaciones, daños en las instalaciones del cliente, robo de materiales o información, accidentes laborales, abandono por parte de un miembro del equipo de trabajo, cambios el alcance del proyecto.

ANÁLISIS + DISEÑO

Un proyecto relacionado a las TIC, contempla fases de análisis y la de diseño, se debe tener en cuenta que el jefe de proyecto esta obligado a revisar el trabajo de otros o asegurar las formas de revisión, dado que se encuentra frente a un compromiso contractual con el cliente y será el responsable por parte del proveedor.

Tanto si el cliente adquiere un producto ya desarrollado, o contrata desarrollo a la medida, no se librará del "análisis" + "diseño", en el primer caso al tratarse de paquetes ya desarrollados usualmente se realizan personalizaciones, configuraciones y tratamiento de datos, en el segundo al ser a la medida queda todo por hacer.

¿Qué se considera análisis?

Son todas aquellas actividades encaminadas a detectar los objetivos y necesidades del cliente, sus particularidades y requisitos específicos que desea ver reflejado en el producto final. Estas actividades deben tener resultados tangibles, reflejados en documentos que plasmen el entendimiento de lo que desea el cliente, por ejemplo: diagramas de procesos (BPM), catálogos de servicios, casos de uso, historias de usuarios, modelos lógicos de los datos, diagramas y definición de interfaces de usuario, definición de interfaces con otros sistemas internos o externos a la organización. Es importante que el analista no solo capte necesidades, sino además plantee soluciones eficaces, eficientes, coherentes, completas, claras y que elimine contradicciones e incompatibilidades entre requisitos.

¿Qué se considera diseño?

Consiste en definir los subsistemas con sus respectivas interfaces y dependencias, se debe responder al ¿cómo se hace?, y esto lo hacen los programadores de sistemas informáticos, siempre que se parta de un buen análisis, se define: un modelo físico de los datos, los entornos y arquitecturas de hardware y software, los módulos del sistema, los paquetes, las librerías, los frameworks. Todo esto se enfocará en ir construyendo las partes mas pequeñas de la solución TIC objeto del proyecto para ir uniéndolas en un todo que cumpla los objetivos establecidos en los documentos de la oferta, contrato y proyecto.

CONTROL

Iniciar el desarrollo de soluciones TIC, significa emplear metodologías, que permitan reconocer errores, detectarlos de forma temprana, establecer secuencias de pasos que permitan organizar el trabajo y responder rápidamente a cambios inesperados. Mantener el control del desarrollo es una tarea compleja que requiere experiencia.

Los modelos de desarrollo son tema de arduo debate, se muestra el resumen de cuatro, partiendo del mas clásico, hasta los más dinámicos y útiles entornos con alta incertidumbre.

"El modelo en cascada"

Llamado algunas veces ciclo de vida clásico, sugiere un enfoque sistemático, secuencial, hacia adelante, este modelo fue propuesto por Wiston Royce (http://en.wikipedia.org/wiki/Winston_W._Royce ), e incluía ciclos de retroalimentación, la inmensa mayoría de quienes lo ponían en práctica lo hacían de forma estrictamente lineal, sin embargo y a pesar de las iteraciones, se ha llegado a demostrar en proyectos reales que no se sigue un flujo secuencial, si se adopta estrictamente el modelo, en situaciones de cambios o modificaciones, el equipo de trabajo llegará a estados de bloqueo, donde unos miembros del equipo deben esperar a otros para terminar tareas dependientes. Este modelo es útil en escenarios donde los requerimientos no van a ser modificados y el trabajo se realiza de forma lineal.

"Construcción de prototipos"

Cuando los clientes definen al inicio del proyecto, e incluso en el contrato, un conjunto de objetivos generales y requisitos que no están detallados dejando de entrada dudas por la falta de definiciones, pudiera funcionar correctamente este modelo, hay que estar conscientes de que un prototipo no es el producto final, entonces el cliente puede pedir cambios y no entender por que se tarda tanto en implementarlos de forma definitiva, es decir para entrar en operaciones, se debe a que un prototipo se consigue de forma acelerada con herramientas especiales para obtener "algo que mostrar", sin embargo esta lejos de ser una solución completa, por lo que el cliente debe tener muy claro que el prototipo sirve para definir requisitos y que una vez se llega a un acuerdo, se desarrollará la solución TIC definitiva con orientación a la calidad.

"Modelo en espiral"

No hay mejores palabras que las de su creador, Barry Boehm (http://es.wikipedia.org/wiki/Barry_Boehm), para explicarlo:

"El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es el enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras disminuye el grado de riesgo. La otra es un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorios".

Se trata de un modelo evolutivo, que en cada iteración consigue tener un sistema cada vez mas completo, el riesgo se reduce conforme se avanza. Incluso este camino en espiral podría permitir generar nuevos productos a partir de otros conseguidos en iteraciones anteriores.

Se considera un modelo útil para desarrollo de sistemas a gran escala, puede emplear también la elaboración de prototipos, sin embargo su finalidad principal se dirige a adaptarse mas a lo que ocurre en el mundo real, evitar que los riesgos se materialicen, lograr una participación mas activa del usuario en el proceso de desarrollo y conseguir un producto cada vez mas completo.

"SCRUM"

Este método prueba su eficacia en proyectos con tiempos de entrega muy reducidos, requisitos cambiantes y condiciones críticas en los negocios.

En este caso los "retrasos" o "acumulados", es una lista que contiene los requisitos que son prioridad para el cliente, son las características de la solución TIC que le dan valor al negocio, en cualquier momento se pueden agregar elementos a esta lista y el ejecutivo que dirige el desarrollo del producto evalúa y re-asigna prioridades.

El "SPRINT" o ciclo, es la unidad de trabajo requerida para satisfacer un conjunto o paquete de requisitos (retrasos, acumulados) en un período de tiempo determinado, usualmente 30 días (entre 2 a 4 semanas), una vez iniciado el SPRINT, no puede introducirse mas requisitos ni cambios, esto proporciona al equipo de trabajo un ambiente estable y le da velocidad al desarrollo ya que al final de cada ciclo se tiene un resultado funcional.

Una vez lanzado el SPRINT, se lleva a cabo una reunión cada 24 horas, generalmente de 15 minutos, con la finalidad de descubrir y resolver problemas, el líder evalúa el avance y procura mantener al equipo como una unidad auto-organizada. En esta reunión cada individuo responde a las tres preguntas siguientes:

¿Qué hiciste desde la última reunión ?

¿Cuáles obstáculos encontraste?

¿Qué esperas lograr para la siguiente reunión del equipo?