Nos falto dar el fua

Un proyecto más terminado exitosamente, de unos años para aca los proyectos en los que he trabajado se han terminado bien de 10, 0 proyectos barridos, sin embargo cuando comence a desarrollar pues recuerdo uno, que no se termino tan bien que digamos, todavía me sigo preguntando que nos paso que nos falto, serían los usuarios que nunca tenian tiempo para atendernos, nuestra inexperiencia(becarios) ,o algunos procesos criticos que no fueron identificados, sobre todo las cargas de datos, si bien desafortunadamente trabajar con gente de gobierno es difìcil siento que nos falto más, ya ha pasado bastante tiempo y siento que nos falto involucrarnos más y ponernos más punks, para que casi casi no dejarán trabajar a la par, junto a ellos, siento que nos falto identificar los procesos más críticos, y si a eso le sumamos la resistencia al cambio, no solo de los usuarios a veces hasta de la propia consultoría, sin embargo hoy se que no estabamos tan mal, cuando empezamos a usar diagramas bpmn con bizagi casi nos llamaron locos, hoy se que no y nadie me lo cuenta, hace días tuve la oportunidad de visitar la fabrica de software de mi consultora, esta si es una fábrica de software, donde a parte de desarrolladores, hay arquitectos de software, y me quede sin palabras cuando veía las oficinas y los cubículos repletos de diagramas bpm, aunque los he utilizado en otros proyectos, hoy se que en esa parte no estabamos mal, ver procesos con flechitas que no representan nada, simplemente habla de que nosotros somos los cuadrados, hablando con un compa arquitecto de software, le pregunte si esos diagramas los entienden los directivos, se rio y me dijo, claro su notación es muy fácil de entender, así que de la poca experiencia que tengo hay van los errores más comunes de un desarrollador:

 1. Ver pantallas y tablas donde realmente no existen: Si llegas con el usuario y empiezas a preguntarle de su proceso y ya estan imaginandote pantallas y tablas sin tener todo el mapeo de los procesos.

2. Modelar. Hay programitas como http://builds.balsamiq.com/b/mockups-web-demo/ que te permiten llevar tu lap y armar la interfaz del usuario en minutos, lo padre es que ya tiene la mayoría de controles web como arcodeones, pestañas, ventanas de navegadores, etc.

3. Supociciones.Ya en el desarrollo dices y si le agrego esto para que sea má amigable para el usuario, cuando el usuario, no lo solicito.

4. Ambientes. Los ambientes es uno de los principales problemas con los que en practicamente en casi todos los proyectos he tenido, tienes un ambiente de desarrollo y tienes que loguearte, para generar un reporte tienes que pasar por x flujos en lugar de tener preparada la clase para hacer pruebas unitarias, otro problema de la ambientación es que mi servidor de pruebas no es igual al de desarrollo si aunque usted no lo crea, estoy trabajando con un tomcat, pero en pruebas y producción hay un websphere, de ahí el clásico, en mi máquina si funciona. Y si a eso le agregamos que para conectarme en pruebas y desarrollo es una forma y en producción es otra, nada configurable ni en unos properties o un xml.

5. Mala comunicación con el usuario. Bueno esto me lo piratie un poquitin del diplomado de requerimientos que me dan en la consultora, esto es generalmente porque el usuario es un antiusuario (no quiere el sistema), pues la clave aquí es darle la vuelta, tomar sus criticas como constructivas para mejorar el sistema, y depende como sea el tipo de antiusuario, si es el que siente que lo sabe todo no es bueno elevarlo mucho, de otra forma, se podría mencionar algo como "a el dr uribe hizo esta sugerencia para que se mejorará x sistema", otro error pero más nuestro es hablar con muchos tecnisimos que el usuario no tiene ni idea, deporsí le cuesta trabajo adaptarse al sistema y le hablamos de webservices, clases ,llaves primarias, procedimientos almacenados, etc.

6. La terrible curva de aprendizaje, nunca pensamos que a lo mejor nos tardamos en aprender a usar una herramienta de desarrollo, pero el tiempo de aprendizaje la mayoría de las veces es menor al tiempo que nos vamos ahorrar.

7. Retroalimentaciones por partes de los usuarios, las retros nos sirven para ver si nuestro trabajo es bueno, malo, etc.

Bueno pasemos a lo que más me late de mi trabajo.

1. Cuando surgue un problema: ese problema me da la chamba g g.
2.Cuando resuelvo un problema: Es un reto demostrarme a mi mismo que puedo(en otras palabras que soy chingón) g g.
3.Cuando los usuarios lo prueban y funciona.
4. Cuando los usuarios lo usan.
5. Cuando me vuelven a pedir para proyectos.

Esa es la experiencia que los comparto compas desarrolladores, espero les sirva.