Consejos, conocer y respetar los derechos de las partes implicadas

En todo proyecto de desarrollo de software hay por lo menos dos partes implicadas, el cliente, y el equipo de desarrollo. Es muy aconsejable que en la reunión de lanzamiento del proyecto se dén a conocer los derechos propios, y se comprometan a respetar los de la otra parte.

Derechos del cliente
- Establecer los objetivos del proyecto, y tener seguiento de los mismos.
- Saber cuanto tiempo y cuanto dinero va a costar el software.
- Decidir qué funcionalidades están o no en el proyecto.
- Realizar cambios razonables durante el curso del proyecto, y conocer el coste de realizar esos cambios
- Conocer el estado del proyecto de manera clara y confidencial.
- Ser informado regularmente de riesgos que puedan afectar coste, planificación o calidad, y disponer de una herramienta para comunicar problemas potenciales.
- Tener acceso real a los entregables a lo largo del proyecto.

Derechos del equipo de proyecto
- Conocer los objetivos del proyecto y las prioridades.
- Conocer en detalle el producto que se supone que debe desarrollarse, y poder aclararlo si no lo está.
- Tener acceso real y continuo al responsable de la toma de decisiones por parte del cliente.
- Trabajar en cada fase de una manera técnicamente responsable, sin ser forzado a comenzar la codificación demasiado pronto.
- Dado que en cada etapa del proyecto, se tiene mayor conocimiento para poder reestimar tareas, realizar nuevas estimacions y reajustar la planificación.
- Trabajar en un entorno productivo, sin interrupciones y distracciones.

Conseguir que esto se respete a lo largo del proyecto es tarea difícil, pero no lo lograrás si no lo planteas desde la primera reunión.

Otros consejos:
Marca hitos y reestima tras alcanzarlos.
Desarrollo del proyecto por etapas

servido por jarroyo sin comentarios compártelo

Consejos, desarrollo del proyecto por etapas

Seguro que conoces la máxima divide y vencerás, pues bien, los proyectos de desarrollo de software no son una excepción. Mi consejo en este caso es que abordes el desarrollo del proyecto por etapas, obteniendo una versión entregable e instalable en producción al final de cada fase.

El enfoque por etapas, se basa en entregar el software por "trozos" en vez de todo al final del proyecto. Esto reporta importantes beneficios:

- La funcionalidad crítica estará pronto disponible, si la planificas y abordas en las primeras etapas.

- Se reducen riesgos, al detectarlos antes en el tiempo.
* De integración entre subsistemas al tener que entregar algo que funcione.
* De fallo en la toma de requerimientos.
* Da señales del progreso del proyecto, y se puede identificar si no es el apropiado.

- Los problemas se hacen antes evidentes.

- El trabajo extra para informar del estado del proyecto se reduce, ya que las entregas son el mejor indicativo del estado del proyecto.

Basándome en esto, una de las primeras tareas que te aconsejo hacer en tu proyecto, es planificar las etapas en las que lo particionaras, teniendo en cuenta la prioridad a la hora de establecer el orden del desarrollo.

¿Tienes algún consejo sobre gestión de proyectos de software? Me encantaría que me los contaras.

Otros consejos:
Marca hitos y reestima tras alcanzarlos.
Conocer y respetar los derechos de las partes implicadas

servido por jarroyo 2 comentarios compártelo

Consejos, marca hitos y reestima tras alcanzarlos

Se han escrito libros y más libros sobre gestión de proyectos de desarrollo de software, muchos excesivamente teóricos para mi gusto, y otros pocos más práticos y aplicables. De estos últimos, me gustaría remarcar Software Project Survival Guide, de Steve McConnell's, del que se pueden extraer bastantes cosas concretas a aplicar en el mundo real.

De la lectura de este y otros libros, y de mi experiencia personal, me gustaría dar algunos consejos prácticos que me han resultado útiles, y que pueden ponerse en marcha en cualquier proyecto, por pequeño que sea.

Consejo: Marca hitos y reestima tras alcanzarlos.

- Marca hitos intermedios en el desarrollo, y evita dejarlo todo para una única entrega final. Estos hitos intermedios son más fáciles de gestionar.

- Las metas son importantes para tener la percepción de que el proyecto avanza, y es la mejor forma para representar el estado del mismo. La lista de hitos alcanzados es muy útil para informar a clientes y partes implicadas de la marcha del proyecto.

- Tras cada hito, tenemos mayor conocimiento del proyecto, por lo que si reestimamos una vez alcanzados, estas estimaciones serán más exactas que las previas, lo que también nos dará una idea más precisa de lo que falta.

- Los hitos deben ser 100% hechos o 100% no hechos, otro porcentaje nos llevaría a engaño.

¿Tienes consejos sobre gestión de proyectos de software? Me encantaría que me los contaras.

Otros consejos:
Desarrollo del proyecto por etapas
Conocer y respetar los derechos de las partes implicadas

servido por jarroyo 2 comentarios compártelo

Control de cambios

El software debe cambiarse constantemente por distintos motivos, lo que no puede permitirse bajo ningún concepto, es hacer cambios a la ligera.

Dado un cambio, todas las partes implicadas deben analizarlo, y ver el impacto y el coste (tiempo, dinero) que tiene llevarlo a cabo.

Posteriormente, cada parte debe conocer el coste del cambio en el resto de partes, de manera que se conozca el coste total.

Por último, para que el cambio se lleve a cabo, todas las partes deben aprobar expresamente el coste que implica la modificación.

Esta es la única forma de que todas las partes interesadas se responsabilicen y conozcan los plazos antes de empezar el cambio.

Otros artículos relacionados:
Artículos de gestión

servido por jarroyo sin comentarios compártelo

Desarrollo con prototipo Vs enfoque clásico

Antes, que trabajaba en una empresa de servicios, era un firme defensor del desarrollo de software mediante el enfoque clásico.

En este enfoque es imprescindible tener el proyecto lo mejor definido posible en el análisis de requerimientos, realizar las fases de análisis funcional y técnico, y finalmente abordar el desarrollo y las pruebas de calidad.
Los análisis de requerimientos, y funcional, debían ser revisados y validados por el cliente, y eso era la biblia para la implementación. Cualquier cambio que surgiera posteriormente, debía ser estudiado, y ver si implicaba un coste adicional o podía asumirse dentro del proyecto.

Ahora que trabajo en una "empresa final", es decir, que desarrollamos para nosotros mismos, las cosas cambian. Puedes realizar igualmente el análisis de requerimientos, y funcional, pero es difícil que las personas no técnicas de tu propia empresa se tomen el tiempo requerido para revisarlo detalladamente y validarlo. ¿Por qué? ... pues porque los cambios que se realicen posteriormente no les cuestan dinero, solamente tiempo. Puedes decir que el tiempo es dinero, y tienes razón, pero mientras no haya una correspondencia directa entre modificación y euros, eso se diluye.

Estos son los casos en los que estoy comprobando, que es valioso el desarrollo con prototipo. Hacer los análisis más ligeros (no quiero decir que desaparezcan), y comenzar a desarrollar antes, para tener pronto algo básico sobre lo que discutir. A esto que los "no técnicos" pueden "palpar", si que le prestarán atención, propondrán y validarán funcionalidades ... vamos, que el prototipo podrá evolucionar hasta alcanzar el producto deseado.

Con todo esto que quiero decir, ¿es mejor el enfoque clasico o el prototipado?. Pues como te habrás imaginado tu mismo, depende del marco del proyecto. Si tuviera que volver a desarrollar para un cliente, dificilmente optaría por el prototipo, porque el factor tiempo, es muy dificil de estimar.

Otros artículos relacionados:
Artículos de gestión
Artículos de desarrollo

servido por jarroyo sin comentarios compártelo