GoldFever
Madmaxista
No te voy a contar hasta que punto estás equivocado en algunas cosas, pero bueno.Solo contesto exabruptos ante lo que considero que son insensateces. Este último post tuyo, por ejemplo, no lo es.
El problema es que si bien, como dices, tienes una gran experiencia en el negocio (Entendido como "el funcionamiento de una PYME"), no tienes ni la formación ni la experiencia como analista en el análisis y diseño de flujos a nivel informático, y aun menos en trato con usuario y usabilidad.
Por eso es tan puñetera esta rama. hace falta alguien con todas las patas.
Y el trato con el usuario, Porque en estas cosas tienes un montón de trato con los usuarios cuando absorbes sus conocimientos y les formas en el nuevo manejo (Que la herramienta es solo una parte, la parte orgánica y funcional es la más jodida). Y, seamos sinceros: en tus post se te ve demasiado arrogante como para ser capaz de ganarte a esos "estúpidos mequetrefes condenados a ser esclavos por falta de iniciativa" que van a ser los empleados (Tuyos o de otros) y de convencerles que si, que su vida va a ser más fácil.
Y luego que mira, de verdad, para que estas cosas salgan bien ahce falta una disciplina de análisis que va fifty-fifty en una buena formación y una sólida experiencia, que tienen los analistas ya fogueados.
Que en españa todos sabemos hacer de todo, hasta que lo intentamos, vemos que no es tan facil, y acabamos con un desbarajuste que no sabemos ni como ah pasado.
¿Qué entiendes por analista ya fogueado?
Te voy a plantar una hipotética situación, simple e ilustrativa.
El jefe de adminstración de una empresa quiere un programa de facturación en el que vea en pantalla las facturas, naturalmente, con su número, fecha, código de cliente, nombre del cliente, domicilio, NIF, etc.
El experto en bases de datos, sin ese fogueo que tu dices, automáticamente aplicará sus esquemas mentales de normalizar la base de datos, y ubicará mentalmente el nombre de cliente, domicilio, NIF y similares, en la tabla de clientes, pero no en la de facturas, ya que eso sería una redundancia, y con tener en la tabla de facturas el código de cliente, como FK, es suficiente.
Sin embargo no es así, hay una decisiva y elemental razón de gestión de empresa por la que parte de esa redundancia SÍ debe existir.
¿Estás tan fogueado como para darme la razón de forma instintiva, antes de pararte ni siquiera a pensar por qué? ¿Y pensándolo?
Como ésta te podría contar el ni se sabe y alguna más, que son en las que pillo a más de un paquete de gestión. El analista fogueado no sólo sabe instintivamente qué hay que normalizar, sino qué NO hay que normalizar, así como qué hay preguntar cuando no te lo dicen y a quién, que para mi es la sabiduría más importante en el tema, imprescindible para hacer un modelo lo más preciso posible de la realidad, porque de nada sirve saber modelar si te faltan datos y ni siquiera sabes que te faltan; y eso sólo se puede aprender con la práctica.
Hace 40 años también había analistas, y muy buenos; trabajaban con máquinas de decenas de kilobytes de RAM, unos pocos megas de disco y nada de SQL (ISAM y gracias). Pero lo hacían bien; de hecho más de un proyecto en COBOL de aquella época llegó hasta el año 2000, cuando el famoso cambio. Muchos de aquellos analistas tenían una sofisticadísima titulación académica: auxiliar administrativo; algunos, ni esa. Bien es cierto que también he conocido en la labor a físicos, economistas, etc.
Un amigo mío, mayor que yo, trabajaba de analista-programador en una cadena de franquicias, teniendo todo informatizado y funcionando perfectamente con un sistema del año de la pera (no puedo entrar en más detalles). La cadena fue vendida a un gran grupo, que envió un director financiero, el cual entre sus primeros "logros" emprendió el cambio de la informática de mi amigo (dejándole a él poco menos que para pegar sellos a las cartas), y metiendo un paquete sectorial de la leche, en .NET, con SQL server y la platano con cebolla; hecho por una empresa que sabía un webo y la yema del otro, con hinjineros y tal. Se armó tal cristo informático que el director financiero, ante el acojono, y para no equivocarse más, no se le ocurre otra cosa que meter SAP. La empresa un poco más y quiebra; entre eso y otros aciertos similares, el director financiero a la fruta calle. ¿Era mi amigo hijo de Einstein? No, pero conocía la empresa mucho mejor de lo que llegaron a conocerla los otros informáticos antes de tirarse a la piscina (y no le preguntaron gran cosa, ellos eran hinjinieros, y mi amigo no).
¿Tú has colaborado en una implantación de ERP pata negra, con el jefe de informática de baja por depresión ante el schoscho montado, su ayudante sin hablarse con el gerente por meter aquella cosa de programa, y tú de mediador, que no estás ahí para eso, teniendo incluso que llamar a dicho segundo de a bordo una mañana a las 12:00 para decirle: "Juan tío, venga, no me seas cabrón, no te cojas tú también la baja que vas a jorobar a tus compañeros más que a la empresa"? Y convencerlo ...
Otras veces, parte del problema es que la empresa, sencillamente, no es humanamente informatizable, o no por ti y tu equipo, y tienes que saberlo, no dejarte cegar por la pasta, y marcharte de allí, o la vas a soltar. Eso se lo dije a un palillero (y ese sí era palillero, pero además de los de usar un tronco de árbol como palillo) que nos cambiaba las especificaciones casi a diario, y un poco más y me pega, de bestia que era (empresaurios como he conocido yo, pocos habrán conocido en este foro). Por cierto, su empresa sigue siendo poco menos que "la novatada" para toda nueva empresa de informática que no lo conoce y se acerca a venderle algo. Y hace 15 años del tema.
Yo lo del desbarajuste también lo he vivido, no voy a decir que no la he cagado nunca, pero desde entonces (y hace ya tiempo) he aprendido "algunas cosillas". ¿Has visto mi post de las "máquinas de carbono", en este mismo hilo?
Por cierto, perdona el tocho, pero era para que me ubiques un poco mejor.
Última edición: