Ir al contenido principal

Gestión de proyectos para novatos

Sé que en un post escrito el día 31 de diciembre se debería hacer retrospectiva del año, pero hay veces que es mejor tener una cierta perspectiva, que solo el tiempo te da, para analizar todas las aristas de una historia, por eso he decidido escribir sobre otras cuestiones.

Recientemente un amigo que se disponía a encarar su proyecto fin de carrera, después de tenerlo bastante tiempo parado, me pidió consejos que le sirvieran para encarar con éxito los trabajos a realizar. Se trataba de un proyecto para un cliente real, y externo a la Universidad. A partir de aquí me pareció que podría ser interesante escribir sobre ello, ya que podría haber otras personas en su misma situación, también podría interesarle a nuevos freelances, que nunca se han enfrentado en solitario a todas las fases de un desarrollo de software, o a jefes de proyecto juniors.

La mayoría de cuestiones que voy a escribir pueden resultar obviedades, pero en este tipo de tareas hay que ser muy metódico, disciplinado y ordenado, por lo que es muy importante tener estas ideas presentes.

Desde el punto de vista de la gestión de proyectos, éstos tienen las siguientes fases:
• Iniciación,
• Planificación,
• Ejecución,
• Seguimiento y Control, y
• Cierre.

Dirigir un proyecto por lo general implica:
• identificar requisitos,
• abordar las diversas necesidades, inquietudes y expectativas de los interesados según se planifica y efectúa el proyecto,
• equilibrar las restricciones contrapuestas del proyecto que se relacionan, entre otros aspectos, con:
el alcance,
la calidad,
el cronograma,
el presupuesto,
los recursos y
el riesgo.

Podría extenderme mucho si tuviera que detallar cada unos de los subprocesos y las herramientas para llevar a cabo con éxito estos procesos, pero no es objeto de este artículo. En este artículo quiero dar un enfoque muy ágil que evite la mayoría de los problemas que llevan a un proyecto de desarrollo software al fracaso.

La iniciación debe comenzar con una reunión de arranque de proyecto, o una reunión de toma de requisitos iniciales. Una reunión debe tener una hora de inicio, una hora de fin, y unos objetivos claros. Es responsabilidad del jefe de proyecto marcar los tempos de la reunión. En este sentido, es importante tener seguridad en uno mismo, al fin y al cabo, tu eres el experto, y llevas preparada la reunión.

Afrontándolo desde un punto de vista ágil, a medida que transcurre la reunión hay que pensar en las pantallas, formularios... detectar qué posibles problemas pueden surgir, y adelantarse a ellos. Tu opinión tiene que oirse como la de un experto. Hay ocasiones en el que el usuario no tiene claro lo que quiere, o no sabe detallarlo, o no sabe que la tecnología le permite optimizar procesos. El jefe de proyecto debe convertirse en el socio tecnológico del cliente, asesorarle y orientarle.

A partir de un requisito, un experto detecta reglas, validaciones, restricciones, los campos que tendrían las tablas en la base de datos, y las relaciones entre ellos (o en los objetos si se opta por el paradigma de orientación a objetos). Es importante definir también los requisitos en negativo (lo que el sistema no debe permitir), así como los requisitos no funcionales relativos a usabilidad, políticas de seguridad, matrices de compatibilidad de navegadores o sistemas operativos... Es vital definir bien los requisitos, para no propagar errores al resto del desarrollo.

Es muy importante cerrar bien el alcance. No se puede cerrar un proyecto sin alcance... siempre parecerá inacabado. En este sentido, sería conveniente plantear en siguientes fases pruebas de aceptación del sistema, que definan objetivamente cuando el proyecto se ha terminado.

En el momento de la recogida de requisitos, se debe pensar en un entregable base completamente funcional. Los adornos y "florituras", es conveniente derivarlos a una segunda fase. A medida que la reunión avance, sobretodo si hay más de una persona, irán pidiendo más y más funcionalidades, algunas accesorias y no imprescindibles para el funcionamiento base de la aplicación. Hay que equilibrar los intereses de los participantes, y detectar las partes críticas para el proyecto. Just in time: ocúpate solo de tu problema de ahora... el de después ya tendrás tiempo para solventarlo en el futuro.

En el caso de que a estas alturas aun no haya precio cerrado, el cliente tendrá mucho interés en saber cuánto le va a costar. Mi consejo es no dar nunca un precio en caliente. Esto debe hacerse de manera meditada, junto con el equipo que vaya a participar en el proyecto, haciendo estimaciones temporales, asignación de recursos...

Un objetivo importante de la reunión debe ser sensibilizar al propio cliente de lo importante que es para el éxito del proyecto que le dedique tiempo para pruebas, validaciones... al fin y al cabo es su proyecto, y nuestro interés es entregarle un aplicativo que realmente sea de su gusto.

Al finalizar la reunión, es importante redactar un acta con los participantes, temas tratados y compromisos adquiridos, a ser posible con fecha de cumplimiento. Lo que se habla queda en el aire... estas serán tus armas para defenderte dentro de x meses, cuando el cliente no se acuerde de lo hablado (o no quiera acordarse).

A partir de los requisitos, que podemos modelar como historias de usuario, si estamos trabajando con metodología Scrum (por ejemplo: como administrador de la plataforma puedo dar de alta a otros usuarios), sería conveniente diseñar la interfaz de usuario (no es necesario que se entregue con la línea gráfica). Se trata de un pequeño esquema de cómo se mostraría la información y los campos de los formularios, con su navegabilidad... esto después de las iteraciones que sean necesarias, debe ser validado por el cliente.

Tus pasos iniciales deberían ser cerrar la propuesta de una arquitectura. ¿Qué piezas has decidido utilizar o integrar?, ¿por qué esas y no otras?, tienes que dominar esto, o el cliente te pillará en un renuncio. Todo el mundo tiene amigos a quién preguntar, tu opinión de experto podría quedar en entredicho.

Para la fase de programación o desarrollo puro, podemos utilizar Scrum, con Sprints de dos semanas. Es importante que al finalizar el Sprint seas tu mismo el que muestre el entregable (o el equipo que lo ha desarrollado), y las funcionalidades implementadas. Utilizando Scrum, conseguirás no tener un desfase grande en tiempo y no defraudarás las expectativas del cliente, porque él irá viendo paso a paso lo que se está construyendo, y podrá opinar desde el principio sobre ello.

En la disciplina de la gestión de proyectos hay mucha teoría. Yo he intentado darle un enfoque práctico a partir de mi experiencia a lo largo de los años. El aprendizaje debe ser continuo. Si pensáramos que ya lo sabemos todo, no podríamos mejorar, ni evolucionar. En este sentido, al 2012 le pido cometer nuevos errores, y no repetir los anteriores.

Feliz 2012 a todos.

Comentarios

Entradas populares de este blog

Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas.

Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla.

Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que …

¿Por qué Yii Framework?

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos.

Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes.

En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja.

Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en pr…

Gestor documental Alfresco vs sistema de archivos

En muchas ocasiones, antes incluso de tener que justificar por qué implantar Alfresco y no otro gestor documental, debemos argumentar a nuestros clientes qué ventajas les aporta usar Alfresco sobre su habitual forma de trabajo, que es, casi siempre, utilizar carpetas en el sistema de archivos de un servidor.

Estos son los argumentos que solemos dar en Soltel:

- Facilidad de explotar la documentación desde otras aplicaciones. Alfresco tiene una API potente a través de la cuál podemos sacar el máximo partido de éste cuando lo integramos con otras aplicaciones.
- Acceso a la información desde cualquier lugar, a cualquier hora y desde múltiples dispositivos (PC, Dispositivos móviles, Tablets, etc.). Toda la información que necesitamos se encuentra en la red y debidamente protegida. Solo necesitamos una conexión a internet. Ya no hacen falta ni VPNs, ni escritorios remotos.
– No es necesario el acceso al sistema operativo anfitrión, evitando que usuarios puedan visualizar aplicativos o informa…