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:
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.
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
Publicar un comentario