*Tema mítico* : ¿Hay en este foro informáticos (y no informáticos) con tiempo libre?

GoldFever

Madmaxista
Desde
5 Feb 2008
Mensajes
14.536
Reputación
18.658
Lugar
Entre el verde, el azul y el gris
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.
No te voy a contar hasta que punto estás equivocado en algunas cosas, pero bueno.

¿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:

Indignado

Madmaxista
Desde
25 Ago 2006
Mensajes
13.400
Reputación
18.703
Lugar
Asgard
No te voy a contar hasta que punto estás equivocado en algunas cosas, pero bueno...
No lo copio todo porque es largo.

Pero que me explique algún ingeniero informatico, que asignaturas relacionadas con el mundo de la empresa existen en la carrera.....

El software es l'herramienta , pero la productividad es el objetivo.
 
Desde
22 Dic 2009
Mensajes
468
Reputación
592
No te voy a contar hasta que punto estás equivocado en algunas cosas, pero bueno.

¿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.
Apoteósico, Goldfever.

Un buen técnico conoce las reglas. Un maestro conoce las reglas y conoce también las excepciones.

Si el disenyo de una BD fuera tan fácil como "eliminar redundancias de los datos", ya tendríamos programas que nos hicieran automáticamente ese disenyo.

Dicen que Dios hizo al hombre a su imagen y semejanza. El empresario espanyol también crea su empresa a su propia imagen y semejanza. Todos los vicios y carencias del empresario se ven reflejados en la empresa que ha creado.

Si el empresario es desconfiado, llenará la empresa de controles y protocolos absurdos. Si el empresario es desordenado y zarrapastroso, la empresa será un cuchitril. Si el empresario es un pueblerino prepotente la empresa será un nido de acciones más próximas a la delincuencia que a la actividad empresarial ...

Goldfever ya lo tiene claro. Hay empresas espanyolas que son imposibles de informatizar porque su esencia es el caos y la desorganización. En esas empresas hay alguien que genera el caos y quien genera el caos, lo controla y controla a la empresa. Eso no cambiará, incluso el empresario disfrutará viendo como se estrella una empresa informática tras otra intentando satisfacer sus deliros de grandeza.
 

Curro_Jiménez

Madmaxista
Desde
5 Mar 2010
Mensajes
400
Reputación
170
Debes ser funcionario informático o casi.

Sé de bastantes personas que en España no han acabado la carrera de infórmatica (la mayoría porque se dieron cuenta de que sólo valía para acabar con un título que colgar en un despacho cutre) y que se lo montaron por su cuenta muy bien. Y también conozco a gente que acabó la carrera y que han sabido realizar proyectos novedosos en campos como el análisis de imagen (el día que vayas con tu mujer embarazada a que le hagan una ecografía te acordarás de esto) o la aplicación 3D para uso lúdico. Y sí, ganarán 1500 (como mínimo), pero no al mes, sino a la semana. Y a diferencia de tí no necesitan Infojobs ni Tecnoempleo ni ninguna pseudoETT.
Macho, no tienes ni astuta de dónde trabajo ni mucho menos si trabajo por cuenta ajena, propia, soy funcionario, empresario, autónomo... no sabes nada. Lo que sí sabes es que no pico código :D

Todos ellos se han creado su propio trabajo y su propia reputación, ellos eligen a los clientes y ellos deciden con quién trabajar. Y ni tienen granos ni son frikis. Tu concepto del informático creativo da qué pensar. ¿Programas siempre según el manual? ¿Nunca has inventado o desarrollado algo original? Eso es ser gris.

En cuanto a lo de ligar.... si para "ligar" (aunque eso no es ligar, tiene otro nombre) con astutas discotequeras de polígono necesitas sacarles tu título de "ingeniero" informático (¿Existe ese título? ¿En qué colegio de ingenieros estás colegiado?) pues vale, te compras un adobado, te pones la corbatita de lunes a viernes, y sé feliz con tu visillera mientras pagas un IRPF del 40% (porque no lo olvides, tú sigues siendo de los de nómina)
Sobre tu pregunta en negrita. SÍ, soy INGENIERO en Informática, y SÍ, estoy colegiado, y éste es mi colegio, LISTILLO:

Inicio - Colegio Oficial de Ingenieros en Informática de la Comunidad Valenciana

En cuanto a lo de ligar no es que lo diga yo, es que lo dice cualquiera con dos dedos en la frante. Yo estudié una "ingeniería" (no se te olvide) no para dedicarme a picar código, sino para gestionar los diferentes procesos en los que intervenga la informática en entornos empresariales de producción. Yo esto lo tengo muy claro.
¿O es que acaso los procesos informáticos tienen que gestionarlos los economistas? No muchacho, los procesos informáticos les gestionan o así deberían los ingenieros informáticos, al igual que las obras públicas las gestionan los ingenieros de caminos (pero no bajan a picar piedra) y las industrias los ingenieros industriales (tampoco aprietan tornillos en la cadena de montaje). Es lo que hay, si te gusta pues bien, y si no pues también.

A mí me gusta mucho la informática, pero no a nivel de programación, y estoy en mi total derecho de defenderme y reivindicarme como ingeniero en informática de pleno derecho, porque me gustan otras ramas de la informática, concretamente las relacionadas con la gestión, como te digo, de procesos tecnológicos e informáticos.

Si a ti te gusta picar código (e innovar) no eres un problema para mí, ni tampoco eres eso que llaman intruso, ni nada de nada, de hecho en la situación que te acabo de describir, yo sería tu jefe :D, y si desarrollas algo grande y te forras pues cojonudo. No me importa nada. Ya sabes, baja al garaje, móntate tres servidores y empieza...
La programación no es exclusiva ni mucho menos de los ingenieros en informática, ni siquiera de los fps, si quieres programar y ganar 1500 euros a la semana, adelante. Lo que yo te puedo decir es que, a nivel directivo de una de las grandes del IBEX 35, por ejemplo, eso es CAL-DE-RI-LLA, y tú efectivamente lo estás poniendo como la panacea y el paraíso.

Poner la informática de gestión como la panacea es decir que McDonalds es alta gastronomía.
Que no, que no, y que no. ¿No ves como no tienes ni idea? Estoy hablando de gestión de procesos informáticos, no de informática de gestión, pero si no entiendes la diferencia, da igual, no te la voy a explicar, te matriculas de la ingeniería y cuando llegues a quinto y te empiecen a hablar de proyectos, de gestión, de riesgos, de calidades y demás hablaremos.
 

Curro_Jiménez

Madmaxista
Desde
5 Mar 2010
Mensajes
400
Reputación
170
Lo que quiero decir es que no necesita un analisis previo a la implementacion de un software.






A tirar líneas señores... :tragatochos::tragatochos::tragatochos:

El mundo civilizado, como para casi todo, nos lleva 40 años de ventaja:

Crisis del software - Wikipedia, la enciclopedia libre

La necesidad real es disponer de un software plenamente coherente en sus procesos, suficientemente complejo en su diseño como para no perder esa coherencia a medida que la empresa vaya creciendo y autoorganizandose y al mismo tiempo suficientemente simple como para poder implementarse en una organizacion caotica y servir de esqueleto para organizar ese caos.
¿Y si tan fácil es, que no necesita ni de análisis previo, cómo es que no te pones a picar tú mismo?

Qué país, qué paisaje y qué paisanaje.
 

willbeend

Madmaxista
Desde
10 Jun 2009
Mensajes
15.217
Reputación
23.221
Lugar
Negociudad
Informatica de gestion = Altas, bajas y modificaciones

Es asiN de simple, pringaos!



:roto2:
 
Última edición:

willbeend

Madmaxista
Desde
10 Jun 2009
Mensajes
15.217
Reputación
23.221
Lugar
Negociudad
No te voy a contar hasta que punto estás equivocado en algunas cosas, pero bueno.

¿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.
a grandes tochos, pequeño tamaño de fuente :roto2:

 

nihilist

Gott ist tot
Desde
18 Abr 2007
Mensajes
571
Reputación
349
Pero que me explique algún ingeniero informatico, que asignaturas relacionadas con el mundo de la empresa existen en la carrera.....
Las mismas que en telecos o industriales, por decir un par... en las ingenierías no se enseña el mundo empresarial, y que sepa, nunca se ha enseñado. Eso (tratar con personas, cómo funcionan las empresa y el mundo real, bajarse de la torre de marfil académica si no te dedicas a la investigación, etc) se aprende después. Al menos el que le ponga ganas... al que crea que ya lo sabe todo después de la universidad, le va a costar más. Qué pretendeis demostrar? Que la carrera es imperfecta? Totalmente cierto. Que es completamente inútil? Totalmente falso. Tiene carencias, pero también se aprenden cosas útiles. Ni blanco ni neցro.

Al fin y al cabo el análisis de requerimientos sólo es una parte pequeña de todo lo que representa la informática... es una parte de la rama de ingeniería del software, que es a su vez una parte de la informática (personalmente me gusta más la denominación anglosajona de 'computer sciences'), por lo que no es de extrañar que no se le dedique demasiado tiempo en la carrera... se pasa bastante por encima. De hecho para mi tiene menos de informática que de psicología (si, reiros, pero tienes que intentar meterte en la mente de la gente para hacerlo bien...).

El problema que le veo, es que para muchos ingenieros es algo raro: no tiene mucho que ver con la tecnología. Se trata de tratar con personas, y en eso los informáticos solemos puntuar bajo. Une a eso la idiosincracia propia de las personas en particular, y la idiosincracia propia de la empresa cómo grupo de personas y si enfocas el análisis cómo un problema puramente informático tienes muchos números de que salga mal, o al menos no del todo bien.

Nunca habeis encontrado al típico usuario reticente en un análisis, porque tiene miedo que con el nuevo sistema su puesto de trabajo pueda ser superfluo y hace lo posible por dificultar el proceso e incluso sabotearlo? Luego casi siempre encontrareis resistencia al cambio si vais a implantar un sistema nuevo... a poca gente le gustan los cambios en el trabajo. Luego está el típico error de dejar que los usuarios te expliquen cómo quieren trabajar, en vez de en qué consiste su trabajo. Luego puede haber temas políticos entre departamentos... total, hay más cosas que no dependen de la informática que cosas que dependan de la informática.

Si no han cambiado bastante en la última decada, las metodologías de análisis, especificación y diseño en cascada que se daban en la universidad sólo funcionan bien en proyectos muy bien definidos con requerimientos estáticos. Por desgracia en el mundo real los requerimientos son dinámicos, difusos, van cambiando sobre la marcha (si te los cambian todos los días no es manejable, pero lo normal es que vayan evolucionando a lo largo del desarrollo del proyecto) y vas a perder muchos clientes si no les das algo de cuerda a la hora de ir cambiando los requerimientos sobrel a marcha. No se puede pretender que tras unas entrevistas con el cliente todo quede grabado a fuego y no se pueda modificar. Por suerte existen metodologías flexibles que contemplan que el análisis, diseño e implementación sean continuos en el tiempo y no secuenciales uno detrás del otro, y que permitan que las cosas fluyan.
 

nihilist

Gott ist tot
Desde
18 Abr 2007
Mensajes
571
Reputación
349
Informatica de gestion = Altas, bajas y modificaciones

Es asiN de simple, pringaos!

:roto2:
Te faltaba añadir:

SAP = Altas, bajas y modificaciones

Programación = Asignaciones, bucles, operaciones condicionales y aritméticas.

Arquitectura = Apilar vigas, paredes maestras, muros y pisos.

Transplante = Abrir, sacar órgano enfermo, sustituir por órgano sano

Y así hasta el infinito...

Si es que la gente somos iluso... mira que complicarnos la vida cuando puedes resumir cualquier sistema de gestión en 3 palabras... you are a true genius! :rolleye:
 

xY_MWM _Yx

Madmaxista
Desde
10 May 2010
Mensajes
2.809
Reputación
3.713
Macho, no tienes ni astuta de dónde trabajo ni mucho menos si trabajo por cuenta ajena, propia, soy funcionario, empresario, autónomo... no sabes nada. Lo que sí sabes es que no pico código :D



Sobre tu pregunta en negrita. SÍ, soy INGENIERO en Informática, y SÍ, estoy colegiado, y éste es mi colegio, LISTILLO:

Inicio - Colegio Oficial de Ingenieros en Informática de la Comunidad Valenciana

En cuanto a lo de ligar no es que lo diga yo, es que lo dice cualquiera con dos dedos en la frante. Yo estudié una "ingeniería" (no se te olvide) no para dedicarme a picar código, sino para gestionar los diferentes procesos en los que intervenga la informática en entornos empresariales de producción. Yo esto lo tengo muy claro.
¿O es que acaso los procesos informáticos tienen que gestionarlos los economistas? No muchacho, los procesos informáticos les gestionan o así deberían los ingenieros informáticos, al igual que las obras públicas las gestionan los ingenieros de caminos (pero no bajan a picar piedra) y las industrias los ingenieros industriales (tampoco aprietan tornillos en la cadena de montaje). Es lo que hay, si te gusta pues bien, y si no pues también.

A mí me gusta mucho la informática, pero no a nivel de programación, y estoy en mi total derecho de defenderme y reivindicarme como ingeniero en informática de pleno derecho, porque me gustan otras ramas de la informática, concretamente las relacionadas con la gestión, como te digo, de procesos tecnológicos e informáticos.

Si a ti te gusta picar código (e innovar) no eres un problema para mí, ni tampoco eres eso que llaman intruso, ni nada de nada, de hecho en la situación que te acabo de describir, yo sería tu jefe :D, y si desarrollas algo grande y te forras pues cojonudo. No me importa nada. Ya sabes, baja al garaje, móntate tres servidores y empieza...
La programación no es exclusiva ni mucho menos de los ingenieros en informática, ni siquiera de los fps, si quieres programar y ganar 1500 euros a la semana, adelante. Lo que yo te puedo decir es que, a nivel directivo de una de las grandes del IBEX 35, por ejemplo, eso es CAL-DE-RI-LLA, y tú efectivamente lo estás poniendo como la panacea y el paraíso.



Que no, que no, y que no. ¿No ves como no tienes ni idea? Estoy hablando de gestión de procesos informáticos, no de informática de gestión, pero si no entiendes la diferencia, da igual, no te la voy a explicar, te matriculas de la ingeniería y cuando llegues a quinto y te empiecen a hablar de proyectos, de gestión, de riesgos, de calidades y demás hablaremos.
Tienes una carencia de autoestima de aúpa.

Una duda: el año pasado, cuando las reivindicaciones por dignificar tu profesión, ¿saliste a la manifestación con o sin corbata?

Y otra cosa, yo sí conozco a ingenieros industriales que sí que apritan tornillos, pero es que estos están a otro nivel muy por encima del de la calaña tuya, que simplemente trabajan de lunes a viernes sus 7 horitas. Como decía, están los informáticos creativos y pioneros que inventan cosas útiles y no les importa "embarrarse" las manos y luego los meapilas de oposición que con si titulito debajo del brazo se dedican a vender farfulladas (¿los porteros de discoteca te dejan entrar con el título debajo del brazo?)

El día que inventes algo decente entonces puede que se te tenga en consideración, pero mientras tanto seguirás siendo tan especial como el resto de los mortales, incluso de los picacódigo, de la señora de la fregona y del albañil. Porque tú lo sabes: no eres especial ni imprescindible.

Por cierto, hay pilinguis y puñeteros que ganas más de 1500 al día. Te lo digo para que cuando pete el IBEX35 los ingenieros puedan seguir pagando su zulito. :D

PD: El que no sabe a lo que me dedico eres tú, ni lo sabrás, porque a mí no es tan fácil tirarme de la lengua, ingeniero coiicv
 

bertok

Será en Octubre
Desde
23 Jul 2009
Mensajes
42.337
Reputación
72.933
Lugar
Rocky Mountains
No te voy a contar hasta que punto estás equivocado en algunas cosas, pero bueno.

¿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.
Las cosas como son, se ha ganado un thanks.

Totalmente de acuerdo con la exposición.
 

JyQ

Madmaxista
Desde
29 Jul 2009
Mensajes
9.331
Reputación
13.829
Veo hoy otras dos páginas de la misma discusión que las 48 anteriores (quitando que ya no se habla de cómo es una BD) que no resuelven nada y que por cierto, he estado a puntico de leerme.

Y encima no he hecho pole en la 50 :( :( :(