10 Razones por las que fallan los proyectos web

[Fuente: http://speckyboy.com/2012/08/24/10-reasons-why-website-projects-fail/]

A menudo me pregunto porqué hay tantos clientes que vienen a nosotros después de que sus proyectos Web hayan fallado. Alrededor del 75% de nuestro negocio viene de proyectos donde alguien no ha podido terminar su trabajo. La situación más común es lo que yo llamo el “Money Pit”. Ahí es donde el programador sigue diciendo al cliente que está casi hecho pero nunca lo acaba.

Hoy todos los proyectos utilizan algún tipo de Gestor de Contenidos. En vez de pintar un lienzo como en los viejos tiempos del HTML, estamos haciendo aplicaciones que necesitan seguir aproximaciones al desarrollo más tradicionales. Si el proyecto es codificado de forma impropia, entonces muy a menudo tienes que tirarlo todo a la basura y empezar de nuevo. El coste de arreglar todos estos problemas puede ser significativo.

Pienso que debería compartir las razones más comunes que hemos visto alrededor de todos estos años que hacen que los proyectos fallen.

1. El “Sindrome Freelance”: programadores no cualificados; utilizando tu marca , amigo / vecino , contratando en tu nombre o yendo más alla de lo que deberían.

Quieres hacer un web increible que automatizará las gestiones de tu negocio y se beneficiará de las maravillosas oportunidades que Internet proporciona. Todos te dicen que pueden hacerlo para ti y todos te suenan a lo mismo. El problema es que la mayoría de la gente con la que estás hablando no están cualificados para realizar el trabajo. La mayoría de las agencias de marketing son increibles a la hora de construir tu marca, pero tienen gente en su empresa apropiada para desarrollar tu aplicación web?

Asegurate que ellos no están subcontratando tu proyecto a freelances o incluso peor, lo están encargando a grupos de trabajo en paises lejanos. Visita o habla con la gente que está desarrollando tu website y mira su trabajo. Habla para pedirles referencias. Mira que no te den gato por liebre. Han hecho ellos proyectos de complejidad similar? Hacer negocios con amigos / vecinos no tiene sentido. Contratar programadores para tu empresa  puede convertirte en aprendiz de todo maestro de nada. Hace falta varios perfiles con diferentes especializaciones para construir los websites de hoy. Los recursos de la casa se ajustan mejor a una fase del proyecto en la que el proyecto ya ha sido comenzado. Es en ese momento en el que el programador de tu empresa puede servir de soporte de recursos según sean necesarios a los programadores de tu website ahorrandote dinero.

2. Saltarse lo fundamental: Carencia de una clara definición del ámbito y los requerimientos

Todo el mundo está siempre ansioso para empezar y estamos seguros de conocer lo que tienen que hacer. Pero no pensamos  sobre cómo va a funcionar y qué sucede bajo distintos escenarios. Estos es especialment cierto cuando una compañia pone su negocio online. Cómo afectará este nuevo proceso a su negocio? La mayor parte de los clientes creen que saben lo que ellos quieren, pero el diablo está en los detalles. No puedo decirte cuántos clientes conocemos que cuando les presionamos a detallar su funcionalidad, ellos habian pasado por alto algunas ramificaciones. Asegurate que pasas por un ejercicio de planificación detallado antes de empezar a programar. asegurate de programar algo que tus clientes quieren y necesitan, no solo lo que ellos quieren. Saca input de tus clientes.

3. Perdida de liderato. Falta de interés en comprar y falta de participación

La gestión quiere una nueva web para alcanzar objetivos corporativos e incrementar el ROI. La gestión no tiene tiempo de estar en la toma de las decisiones estratégicas que deben ser hechas. Aparecen grandes problemas cuando la gestión prueba la versión Beta y encuentra que no es lo que originalmente ellos querian. Algunos de los mejores proyectos en los que hemos trabajado son aquellos en los cuales la gestión ejecutiva estuvo más activamente involucrada desde el comienzo. Los cambios pueden ser muy caros en tiempo y dinero si tienen que hacerse al final del proyecto en vez de al comienzo.

4. El “Sindrome Facebook” abarca más de lo que puede abarcar

Hay que ser cuidados de no querer abarcar más de lo que se puede. Roma no fue construida en un día. Si tienes entre manos un proyecto realmente complejo, hazlo en fases. No tienes que sacarlo todo en la primera versión de una vez. No hay nada malo con reemplzar la web antigua después de que se hayan completado tres o cuatro fases.

5. Anteponiendo el diseño como lo primero: Diseñar sin proposito ni función

Hemos visto diseños muy bonitos para nuevos proyectos que directamente no pueden ser programados o son muy caros de construir. Es mejor diseñar toda la funcionalidad teniendo en cuenta la plataforma donde el diseño va a ser integrado. Entonces debes hacer trabajar a tu equipo de programadores junto con el diseñador, asi juntos deben llegar a algo que es bonito y funcional a la vez. De otra forma llegarás a tener un Frankestein que no hay por donde cojerlo.

6. Código descontrolado: No utilizar un Control de Versiones

Hoy en día es insondable programar una web sin algún tipo de sistema de control de versiones de código. Nosotros utilizamos GITSVN. Cuando los programadores crean , soportan y actualizan archivos de código fuente para una aplicación grande, la coordinación puede ser compleja. Los sistemas de control de código fuente graban todos los cambios de los archivos, con comentarios , en un proyecto. Necesitas tener la posibilidad de poder recuperar la funcionalidad, fundir distintas ramas de desarrollo y trabajar off line. Un apropiado control de versiones es vital para cualquier proyecto.

 

7. Programadores descontrolados: Carencia de buena gestión del Proyecto

The Project Manager (PM) is the Quarterback of your football team. The PM is responsible for the successful planning, execution, monitoring, control and closure of a project. The PM needs to understand the client’s needs and provide communication to and from the developers. Without a proficient PM, the project will get off track and become a run away train that ends up in disaster. A good PM will publish weekly progress reports keeping everything on track.

8. Intentar reinventar la rueda: hackeando el core o el código fuente

Hacking is changing the source code structure. We always believe in K.I.S.S, Keep it short and simple. When an unqualified developer doesn’t know how to do something, they tend to hack the code to make it do it. This causes a number of problems and greatly affects quality. If your developer fixes one problem and another arises, it may be the result of a lot of hacks.

Doing so will make it near impossible for site updates due to Security and bug fixes. It also makes it difficult for those that come in after to maintain the site and could possibly leave your site vulnerable to exploits. We have a tool we run that uncovers all of the Hacks for our customers who come to us in trouble. Then we show them the results and why their website doesn’t work.

9. Getting Off Track: Scope Creep

Esto sucede mucho. La tarea principal de un buen PM es mantener las cosas en el buen camino. Es natural según avanzas en el proyecto de desarrollo, que se te ocurran nuevas ideas y cosas que quieres. Pero necesitas darte cuenta que cada vez que haces un cambio, esto suma tiempo y coste en tu proyecto.

This happens a lot. A good PM’s main job is to keep things on track. It’s natural as you go through the development, to come up with new ideas and things you want. You need to realize that every time you make a change, it adds to the time and cost of your project. Changes late within the process have large affects. If a website is built and tested, you will have to retest after the change. Some changes are beneficial, especially if they make the website better for your users. But lots of indecision and changing can derail a project. Scope Creep happens when decision makers aren’t involved early on or the project didn’t go through proper planning.

10. Inexistencia de Testing de funcionalidad: carencia de pruebas de Calidad sólidas

Es importante hacer pruebas unitarias de cada pieza de funcionalidad y entonces hacer test de regresiones en el producto final. Todos los proyectos tienen bugs (fallos), asi que es mejor hacer que los programadores encuentren los problemas a los usuarios. Nosotros generalmente reservamos de un 20 a un 25% del tiempo de desarrollo a tareas de QA

It’s important to unit test each piece of functionality and then do regression testing on the final product. All projects have bugs, so it’s better to have the developers find the problems instead of your users. We usually set aside 20% to 25% of the development time to perform proper QA. Make sure there is a comprehensive QA Plan, otherwise you could get a website that has a lot of issues. Developers need to be thinking about quality from day one and be responsible to fix their problems. Otherwise it could get very sloppy.

Conclusion

Building a successful website requires all ten of these areas to be properly addressed. Failure to perform any of these tasks could derail a project which ends up being completely wasted money in the budget. When you select a developer make sure they can address all of these before you start. Properly done projects can be a tremendous asset to the wellbeing of your company.