Producto vs proyecto
Durante mi "carrera" profesional siempre he desarrolado software, sin más, resolviendo lo que los clientes me pedían, no era consciente de que eso eran proyectos, no productos.
A partir de que en la empresa decidimos desarrollar un producto "estándar" empecé a darme cuenta de las diferencias entre desarrollar proyectos y productos.
En los proyectos resuelves problemas que te comentan personas que conoces, que tienes cerca, en un entorno conocido y sobre el que, en cierta forma, puedes intervenir para adecuarlo a la solución del problema. A cambio, no siempre se aplica la mejor solución (desde el punto de vista técnico) para el problema, muchas veces simplemente se soluciona, bien porque el cliente lo quiere para YA!!!! o porque sabes que no se va a utilizar mucho (a veces una sola vez).
En un producto... tienes que resolver problemas "abstractos" de gente que no conoces, de clientes que lo pueden ser del producto, sobre una plataforma determinada pero no sobre unos equipos concretos, debes dejar el software lo más abierto posible para que el usuario pueda "personalizarlo". Debes escribir código robusto, lo más que puedas, porque no sabes donde se va a ejecutar, no sabes la preparación "informática" de los usuarios. En definitiva, todo muy amplio, muy abstracto.
En un proyecto, estás a disposición del cliente (al menos esa siempre ha sido mi postura), te tienes que adaptar a sus necesidades cambiantes (porque cambian, verdad?), muchas veces se cancelan, o se congelan, determinadas funcionalidades porque se cambia de prioridad.
En un producto, debes escuchar a los usuarios, recoger información sobre sus necesidades, tener capacidad para sintetizarlas y extraer lo común, lo realmente útil y no "caprichos" individuales. Y en base a ésto realizar un plan de desarrollo, y seguirlo. Está en tus manos (en cierta forma) la evolución del producto (mal harás si no escuchas a tus usuarios).
Como veis las cosas son muy diferentes, por ello me costó mucho cambiar de "chip", acostumbrado durante varios años a atender a las necesidades concretas de un sólo cliente he pasado a tener que recopilar sugerencias, necesidades, estudios de competencia para decidir que funcionalidades se le añaden al producto y cuales se quedan en la recámara.
(Continuará ...)
A partir de que en la empresa decidimos desarrollar un producto "estándar" empecé a darme cuenta de las diferencias entre desarrollar proyectos y productos.
En los proyectos resuelves problemas que te comentan personas que conoces, que tienes cerca, en un entorno conocido y sobre el que, en cierta forma, puedes intervenir para adecuarlo a la solución del problema. A cambio, no siempre se aplica la mejor solución (desde el punto de vista técnico) para el problema, muchas veces simplemente se soluciona, bien porque el cliente lo quiere para YA!!!! o porque sabes que no se va a utilizar mucho (a veces una sola vez).
En un producto... tienes que resolver problemas "abstractos" de gente que no conoces, de clientes que lo pueden ser del producto, sobre una plataforma determinada pero no sobre unos equipos concretos, debes dejar el software lo más abierto posible para que el usuario pueda "personalizarlo". Debes escribir código robusto, lo más que puedas, porque no sabes donde se va a ejecutar, no sabes la preparación "informática" de los usuarios. En definitiva, todo muy amplio, muy abstracto.
En un proyecto, estás a disposición del cliente (al menos esa siempre ha sido mi postura), te tienes que adaptar a sus necesidades cambiantes (porque cambian, verdad?), muchas veces se cancelan, o se congelan, determinadas funcionalidades porque se cambia de prioridad.
En un producto, debes escuchar a los usuarios, recoger información sobre sus necesidades, tener capacidad para sintetizarlas y extraer lo común, lo realmente útil y no "caprichos" individuales. Y en base a ésto realizar un plan de desarrollo, y seguirlo. Está en tus manos (en cierta forma) la evolución del producto (mal harás si no escuchas a tus usuarios).
Como veis las cosas son muy diferentes, por ello me costó mucho cambiar de "chip", acostumbrado durante varios años a atender a las necesidades concretas de un sólo cliente he pasado a tener que recopilar sugerencias, necesidades, estudios de competencia para decidir que funcionalidades se le añaden al producto y cuales se quedan en la recámara.
(Continuará ...)
2 comentarios
Jose Alberto -
Anónimo -