Un programa informático de la multinacional Indra provocó un agujero de 10 millones de euros en la Hacienda canaria

La Audiencia de Cuentas constata la "drástica reducción" de ingresos por la vía de apremio en 2017 tras las incidencias registradas por la puesta en funcionamiento del sistema de la tecnológica. Los ingresos tributarios en vía ejecutiva en Canarias disminuyeron en algo más de diez millones de euros en 2017 como consecuencia del "inadecuado funcionamiento" del módulo informático implementado a finales del año anterior por la multinacional tecnológica Indra.

[#15 squanchy]

#14 Eso de los casos de uso es ciencia ficción, como el modelo entidad-relación y tantas otras cosas. La vida real es más dinámica. Telefonazo diciendo que quieren tal cambio, se le preguntan las dudas y se hace. Y la mayoría de las veces el cliente te marea haciendo que cambies cosas cada vez que le presentas el resultado, hasta que queda a su gusto.
Algunos clientes incluso te exigen que ciertos cambios (no todos, pero sí promociones y ofertas, informes, y cosas de ese estilo) se hagan casi de un día para otro. Apenas hay tiempo para programar el código y probar, sin documentar nada. Así de triste, y así salen los churros que salen.

[#18 Desactivado]

#15 Pero habrá clientes y clientes, imagino, no? Supongo que en una aplicación importante para un gran cliente si se desarrollará todo desde el principio con sumo cuidado, aunque luego aparezcan problemas.

Por otra parte, debe ser casi imposible tener en cuenta toda la casuística; Recuerdo cuando, con un compañero informático, nos pasamos varios días elucubrando la manera de proceder en el desarrollo posterior de una aplicación que debía, entre otras cosas, organizar espacialmente las parcelas colindantes de cada parcela, según los puntos cardinales (qué parcelas estaban al Norte, Sur, Este y Oeste). Por más vueltas que le dábamos aparecían más y más casos. Al final tiró por la calle del medio y decidimos que los casos particulares los resolveríamos manualmente.

[#22 squanchy]

#18 Sólo la administración o clientes muy estrictos exigen documentación del proyecto siguiendo alguno de los estándares de metodologías para sistemas informáticos. En España Metrica, en Francia Merisse, en UK SSADM, etc. Las empresas privadas lo que suelen hacer es enseñarte el sistema que ya utilizan, y pedirte que le hagas lo mismo en otra tecnología, y aprovechan para añadir funcionalidades. "Modernizar" lo que ya tienen. Y luego los cambios se los comentan al contacto, el jefe de proyecto, y ése se encarga de repartir el trabajo. Y ahí entra en juego la manera de trabajar de cada empresa. Lo normal es poca o nula documentación interna.

Lo normal es un word o pdf con los campos que se necesitan, los valores que pueden tomar, si son obligatorios o no, y poco más. Nada de casos de uso, salvo que sean contraintuitivos. Es normal, porque desarrollar documentación es tiempo y dinero, y la empresa intenta sacar el máximo beneficio y sólo se hace lo indispensable.

[#20 chulonsky]

#15 Si los casos de uso y el diagrama E/R son para tí ciencia ficción, no me gustaría estar en el pellejo del tipo que herede tus proyectos. Testear y documentar es parte del tiempo de desarrollo. No hacerlo es no ser profesional.

[#23 squanchy]

#20 Dicho por un jefe de proyecto de la empresa donde trabajo (que no comparto): "documentar el proyecto y el código es contraproducente, porque después de tantos cambios probablemente haga cualquier cosa excepto lo que dice la documentación".

[#49 redscare]

#23 Pues... depende. Lo mejor es ser realista. He visto sitos donde la documentación inicial que se genera es un tocho que define cada detalle. Y 3 meses después ya no vale para nada porque nadie la mantiene actualizada. Eso no vale pa na. Obviamente tampoco vale pa na no documentar nada y nunca saber si lo que hace el sistema es bug o feature

Hay que hacer toda la documentación que sepas que es realista mantener actualizada, pero no más.

[#80 derp]

#23 Eso pasa, pero pasa cuando no se cuenta con que la documentación también necesita mantenimiento. De hecho, ante un cambio en los requisitos o en los casos de uso, lo primero que debe actualizarse es la guía de uso de la aplicación y los documentos funcionales describiendo cuál será el nuevo funcionamiento

A partir de ese momento el código pasará a estar mal automáticamente dado que no cumple lo descrito en la documentación. Ahora es cuando toca picar para adaptarlo

[#24 neuralgya]

#20 El tío que herede sus proyectos se comerá el marrón igual que se lo ha comido él. Hay entidades donde hay sobreingenieria y hacer una calculadora simple lleva semanas de reuniones, y otros donde las especificaciones te las dan en una servilleta. No tiene nada que ver con ser profesional o no, es cuestión de adaptarse a lo que quiere el cliente, y si quiere un churro, le das un churro, y si quiere caviar, le das caviar. Obviamente el precio es diferente,

[#25 chulonsky]

#24 No te engañes. Un churrero luego no sabe cocinar un bistec de kobe. Seguirá con lo que ha estado haciendo todo el tiempo, churros.

[#26 neuralgya]

#25 Un churrero no, un cocinero sabe hacer de todo.

[#27 chulonsky]

#26 No. Sabe lo que practica.

[#54 dalton1]

#26 Un churrero no haría nunca una tortilla con cebolla, un cocinero sí.

[#51 vitichenko]

#20 si yo tuviera que documentar todo lo que programo tendría que trabajar unas 16 horas al día y llegaría justos con los plazos, esos plazos que se van a acortando para que cada superior que va vendiendo la idea se lleve su bonus. Recuerdo un proyecto que tenía que estar para 6 meses (Banco muy importante) y yo era el último mono de la cadena, pero para algunas dudas que no había por donde coger acabe teniendo contacto con el que pagaba y me suelta un día "vais muy bien en el proyecto, está casi acabado y lo esperábamos en 2 años"

[#58 redscare]

#51 El truco está en conseguir que documenten otros. Yo en varios proyectos he conseguido que haya un mega excel por cada modulo para hacer tracking de cambios. Y es responsabilidad de los funcionales añadir una entrada cada vez que piden un cambio. Mano de santo. El excel es un poco monstruo pero al menos todos los cambios están recogidos en un único documento. Y sobre todo que lo mantienen ellos

[#70 cosmonauta]

#58 Que antiguo me suena todo eso..no he visto un "funcional" desde el 2005.

[#79 redscare]

#70 Perdón, son ahora Business Solution Analysts en vez analistas funcionales? No me mantengo al tanto de la neolengua.

[#85 cosmonauta]

#79 Por funcional entendí "análisis funcional" y eso me recordó mis tiempos mozos y la metodología de desarrollo en cascada. Y hace mucho de eso.

Supongo que lo que tú entiendes por funcional es lo que otros llaman product owner y/o manager. Y el Excel que te generan sería lo que se conoce como backlog en desarrollo ágil.

Y en ningún caso supone una documentación de nada. Sólo para hacer arqueología y cubrirse el culo.

También le tengo algo de alergia a los excels. Se usan para todo menos para su función principal: hoja de cálculo.

[#86 redscare]

#85 Aaah, un creyente en Agile. Que cuqui. Con los años aprendes que al final la metodología y las herramientas son casi lo de menos. Si, unas son mejores que otras, desde luego. Pero lo importante es controlar el caos. Y si la gente de negocio se apaña bien en Excel, pues que viva el Excel. Prefiero mil veces un Excel actualizado antes que un backlog abandonado en jira.

[#76 Desactivado]

#58
Claro y eso se abre como la caja de Pandora

[#69 Desactivado]

#20
En que pocos sitios gas trabajado tu...

[#21 AutonomoMillonario]

#15 En mi experiencia todo eso que dices que es ciencia ficción es porque no da la gana hacerlo. Sin más.

[#42 pocomoco]

#15 que los casos de uso y el modelo entidad relacion es ciencia ficcion?

Dejame adivinar:

Nombres de variables descriptivos, comentarios al codigo... Eso tambien esta sobrevalorado no?

Repositorio? Eso que es? Lo dejo mas abajo en el mismo archivo como codigo comentado no?

Varios archivos? Varios proyectos? Pa que... todo en un archivo no?

Entornos de desarrollo, de preproduccion, de ... Anda ya, todo a produccion que yo lo que pico funciona y a la primera...

Documentacion???????????? Ajjajajaj...

Espero que no seas asi, sino, es totalmente normal que donde hayas estado te llamen solo a ti... Hasta que encuentren alguien que les haga el proyecto entero mas barato...

[#77 Desactivado]

#42
Te explico yo mejor:
Llegas el primer dia, preguntas por el entorno de desarrollo te dicen por donde anda pero que eso no se usa que ellos programan a pelo en producción.
- preguntas como documentan y es iniciales y fecha.
-variables con nombres haycacho y nohaycacho, cadenas de if else interminables, tablas genericas para ahorrar en objetos con todo el sistema sujeto por ellas.
-licencias de jack sparrow.
-mucha presion de tu jefe venir a tu sitio y contarte un desarrollo corriendo de cabeza como el que recita una copla y tu pararle los pies para anotar algo.
-Empresa grandisima.
Al3er dia queria salir corriendo.

Ahora cuentame cosas de que si diagrama.noseque

[#88 pocomoco]

#77 pues si no hay entorno, jefe con mucha presion, etc... te recomiendo que vayas implantando a donde vayas Scrum.

Puede que los desarrollos se alarguen, y quieran tener las cosas para ayer, pero si se hacen las cosas mal, te vas a joder tu, se va a joder tu jefe y se va a joder el cliente.

Si tu jefe y el cliente no quieren implantar Scrum, entonces, sinceramente, mejor irte de alli corriendo.

[#89 Desactivado]

#88
Scrum? Yo ese tipo de metologias no he usado nunca. Tu creo que no sabes como es el mundo real, que en el mejor caso tienes que tirar siempre de freno de mano para que la gente te escriba un puto correo con pantallazos que quiere, de ahi escribir un cambio, documentarlo, forzarles a que lo prueben primero etc.
Lo demas, eso de irte corriendo es lo que hice, cuando pude.

[#90 pocomoco]

#89 buf...

Acabas de decir:
- Yo ese tipo de metodologias no he usado nunca.
- Tu creo que no sabes como es el mundo real.

Ya con eso directamente te digo que tu por tu bien y por tu cabeza deberias de usar Scrum pero como el comer. Sinceramente. Ya tu veras si quieres seguir asi (por tu salud mental) o no. Y creeme, hay grandes empresas en España ( y en el mundo muchisimas mas, por ejemplo Google), y organismos publicos tambien, que si usan Scrum. Y la cantidad de errores que se evitan, en comparacion a como se hacian las cosas antiguamente, es bestial. Es que no se trata de hacer las cosas rapido y mal.

[#92 Desactivado]

#90
Pero vamos a ver amigo, que llevo 10 años en esto y no sabes a que me dedico. Tu te crees que puedes implantar una metodologia asi porque a ti te parece bien¿? Si ya cuesta hacer que la gente no te escupa "necesito un campo aqui" y lo cambies 7 veces de sitio y que haga 16 cosas diferentes porque no saben ni que quieren.
Que hablo de la programacion del dia a dia en una empresa mediana, no estamos programando en google.
Bastante que documento los cambios y los marco bien.

Y he llegado a usar tableros kanban y era una puta coña: Mover las tarjetas de un lado a otro a lo loco (porque venia el consultor de turno y proaba todo de golpe, el cliente tampoco prueba nada, dependencias entre tarjetas, saltarse las propias normas para no estar de brazos cruzados...

[#93 pocomoco]

#92 buf... llevas 10 años. Yo empece hace 3 meses...

En serio, hazte mirar ese nivel de estres, que no es bueno.

Sinceramente, que hayas usado tableros kanban, no es hacer Scrum. Son mas cosas. Entre otras que tanto el cliente, como el jefe de proyecto entiendan y apliquen la filosofia, y que se especifiquen bien los PBIs y los SBIs. Si la empresa es mediana, pues los PBIs han de ser menores. Y si te llegan como tu dices, con que quieren un campo de texto, que lo cambies 7 veces, y que haga 16 cosas diferentes, pues un PBI, para el campo de texto, un PBI para cada cambio, y un PBI para cada cosa que quieran que haga, en total 24 PBIs puestos en el tablero kanban, que lo vean todos los dias tanto el jefe como el cliente, y asi los pueden ir cambiando ellos, y darse cuenta de que cada cosa que dicen es irrealizable, absurda. Pero se tienen que dar cuenta ellos de que es lo que piden, el tiempo, costes y demas.

Yo tambien quiero un Yate y un rio navegable hasta el mar desde la puerta de mi casa.

Seguro que te sientes muy identificado con el siguiente grafico, que te lo plantan en cualquier curso de SCRUM

[#94 Desactivado]

#93
Entonces chico con 3 meses de experiencia, no des lecciones. Llevo concretamente en 13 años.
No tengo estress en la actualidad por el trabajo, mas que nada porque cambie de pais y no trabajo en consultorias.
No se como esperas que el cliente vea nada si no esta en las oficinas. Si, hay tableros virtuales etc pero un cliente no va a hacer ni el huevo.
La realidad es que a ultima hora se empieza a correr y va todo a salto de mata y asi es como se sacan los proyectos.
Ya te tocara que te pidan el yate y el rio, digas que es imposible y tu jefe te obligue a hacerlo a sabiendas. Es mas, avisaras 10 veces de lo mal que va a acabar, acabe mal y tengas que arreglar tu mismo el destrozo que te obligaron a hacer. No sin antes reconocer tu trabajo=0, es mas diciendo que pierden dinero.
Yo creo que pocas consultorias has probado pero veras en los comentarios que es la opinion general. Ese dibujito es mas viejo que el cagar.

[#95 pocomoco]

#94 Madre mia, como estas de estres, que no pillas ni la ironia de 3 meses...

A ver, a mi como a todo el mundo, me han pedido yate y rio, y como todo el mundo he picado en su momento mas horas de lo habitual, y como todo el mundo, me he comido marrones luego mas tarde por trabajar cosas que resultaron ser absurdas.

Si tu sigues empecinado, en que el trabajo tuyo pues es que a ultima hora es todo trabajar a salto de mata, y asi es como crees tu que se sacan los proyectos, pues no me extrañaria que el indice de fracasos de los proyectos que comentas, este al 90%. Asi no se trabaja. Y si no te convences, pues alla tu. Fijo que los comerciales contigo abarataran todo lo posible, porque barato barato, te lo comes todo.

En lo de que avisaras 10 veces, ya te digo, eso ni con Scrum. Avisaras 15, y aun asi, alguno habra que por intentar abaratar alguna mierda, o porque no se ha leido bien la documentacion, o porque tenia prisa, o porque es asi y punto, la cagara.

Y destrozos, tocara arreglar, tanto si son mios, como si son tuyos, como si son de otro. La diferencia es que cuando los destrozos estan en un codigo legible con los puntos bien definidos, y con una buena operativa, se pueden arreglar rapido y sin mucho coste.

Y si estas fuera de pais, y no trabajas en consultorias, pues me parece genial, muy bien. Lo mismo es que como tu dices, te fuistes hace 10 años, y habia una mala costumbre de trabajar. Que quieres que te diga, si te dicen que con un soplido clavas un clavo, y tu sigues mentalizado en que hay que dar martillazos... pues ese es tu problema. Fijate, tu mismo dices que el dibujito es mas viejo que el cagar. Tan viejo es que todavia no se le quiere hacer caso.

En lo de pocas consultoras, pues a lo mejor son muchas o pocas. Es cierto que antiguamente habia una manera de trabajar, y en algunas todavia se mantiene, porque hay gente que aprendio a clavar con martillo, y aunque les muestres que con un soplido haces mas, no los vas a sacar de ahi. Por si te sirve de referencia, hace unos cuantos proyectos, estuve en una Pyme, en la que se seguia programando como hace 20 años, tanto que la gente entraba y salia con 1 o 2 años ( no se molestaban ni en despedir...) Hubo un compañero, que se propuso cambiarlo parte a Scrum. Y sabes que paso?, que cuando lo volvi a ver al año siguiente, estaba fumando como un descosido, porque ni los programadores hacian caso, ni el cliente hacia caso. Los mando a la mierda, se busco otro empleo, y la pyme se fue al garete.

[#96 Desactivado]

#95
Amigo, pues di las cosas claras porque yo entendi que llevas 3 meses.

No me he ido hace 10 años casi todos trabajados en españa y NADA ha cambiado. Es que la gente se inventa que hay dobles subcontrataciones, condiciones de pena y software pirata o que?

Hubo un compañero, que se propuso cambiarlo parte a Scrum. Y sabes que paso?, que cuando lo volvi a ver al año siguiente, estaba fumando como un descosido, porque ni los programadores hacian caso, ni el cliente hacia caso. Los mando a la mierda, se busco otro empleo, y la pyme se fue al garete
Pues eso amigo, tu desde abajo no puedes cambiar la forma de trabajar de la empresa, eres el ultimo mono, no eres el gerente de la misma.
Habras caido en algun sitio mas o menos decente pero en españa solo hay charcuteras que te venden al peso y un cliente que sencillamente es tu jefe y gente que escupe lo que quiere y lo quiere para ayer. Eso en general.

Y te lo digo yo que me pegue para que en un curro el jefe me hiciera algo de caso, consegui que comprara tablas para no almenos seguir con lo que ellos llamaban "la guarritabla" y se reian: Una generica con todo dentro, a tomar por culo. Tenian de hecho ya 3.

Luego tienes proyectos por fases vendidas muy bonitas y mucho humo que luego no se hace mas que todo el mundo corriendo. La de años que vendieron que se usaba metodologia kanban cuando se dejo de hacer y estaban los tableros con tarjetas de proyectos al menos terminados 1 año atras. Ah y algunos en juicio por denuncias de los clientes.
Aun me acuerdo mi primer proyecto que fue el peor del unvierso. Fue cambiar cosas de arriba abajo y un mes despues: "te acuerdas de esto, pues ya no lo quieren".
No se de donde sacabn los clientes ni como firmaban lo que firmaban.

[#97 Desactivado]

#95:
PD: He estado la mayoria de mi vida en consultoria y luego en españa he estado en un cliente tambien, por eso lo que te contaba del jefe y las tablas.

[#81 derp]

#42 De todo eso sí que pienso que los comentarios están sobrevalorados. Yo no los pongo, me niego. Eso sí, hago (lo intento) el código de manera que una persona que no sepa nada de programación pueda entenderlo, que se pueda leer como si fuera una novela

Ejemplo inventado para que se entienda a qué me refiero:

if (fileAlreadyExists(fullPath))
}

Los comentarios siempre tienden a terminar siendo cosas así, frases vacías que no aportan absolutamente nada:

// Increments the x
x++

// Sets the username
setUsername(username)

// If username starts with "A", add "foobar"
if (username.startsWith("A"))

¿De verdad eran necesarios esos comentarios? Lo bueno es que ahora quieres cambiar ese 'foobar' por 'barfoo' y en el 99% de los casos nadie se va a preocupar de actualizar el comentario, con lo cual quedará inconsistente y no sabrás si es que está mal el código, es una errata, etc... Vamos, confundiendo más que ayudando

[#91 squanchy]

#42 No hombre, precisamente la parte que controlamos los propios programadores es la que va bien. El código es legible y bien estructurado. Usamos git adecuadamente, cada cual desarrollando en su rama, cada proyecto con su propio repositorio, y tenemos tres entornos: desarrollo, pruebas y producción.
Es el departamento de proyectos quien tiene que documentar y no lo hace correctamente. En algunos casos por falta de medios, y en otros por pereza e inutilidad.

[#45 obmultimedia]

#15 ahora entiendo por que la web de Fnac va como va.

[#66 drows]

#15 Que el modelo entidad-relación es "ciencia ficción" ????? WTF??

[#5 Desactivado]

Programas obsoletos con tecnología y arquitectura obsoleta, por ahorrarse cuatro chavos la administración han perdido 10 millones. Brillantes.

[#12 uyquefrio]

#5 Y licitaciones donde no se rinden cuentas al proveedor visto lo visto (lo cual a mi modo de ver las cosas tiene más delito, puedes tener la mala suerte de contratar un servicio a un mal profesional sin saberlo pero que no te cubras las espaldas ante situaciones así es de juzgado de guardia).

[#33 mafm]

#5 de verdad te crees que se los han ahorrado? Angelico!

[#38 eldet]

#5 Ahorrarse? si encima sus servicios son de lo mas caro

[#43 Desactivado]

#38 los precios por hora que paga la administración suele ser de vergüenza. 36 euros a granel, en su día hace unos años. Ahora desconozco cómo anda, pero dudo sea mucho más. Pero comprenderás que con ese precio por hora, que es el precio que le cobran los concesionarios a las aseguradoras por los siniestros. Pues eso, que a precio de mecánico la hora poco se puede hacer.

[#50 Desactivado]

#43 En la cárnica donde yo empecé, los novatos entrábamos en el proyecto de la administración de justicia. Os suena LexNet?

[#55 Desactivado]

#50 es que la precio que pagan la hora o metes Juniors o no te salen las cuentas.

[#78 Desactivado]

#55
Pues les salen, sera que pagan a 36 pero consiguen 100 mil sobrecostes

[#59 mr_x]

#43 Claro, y factura 1000 horas en lugar de las 100 que van a estar. Por no nombrar la cantidad de adendas que aumentan el coste de los proyectos.

[#60 Desactivado]

#59 claro es que juegan a engañarse a ellos mismos. Pero no te creas que se meten tantas horas, cada vez revisan más y aprietan más. Al final tienen lo que pagan, gente sin ganas, obsoleta, con proyectos echos unos zorros.

[#71 tiwaz]

#5 pues quieren hacer un ere de unos mil empleados y una de las excusas es deshacerse de gente que esté en tecnologías obsoletas... A ver quién lo va a mantener...

[#72 Desactivado]

#71 Juniors y externos

[#9 squanchy]

Yo provoqué una vez un agujero de 2.000 euros en una pyme, pero fue por un mal uso por parte de los usuarios, que introdujeron mal los datos. Mi parte de culpa fue no verificar esos datos y mostrar una advertencia.
Llegamos a un acuerdo amistoso para solucionar el problema, y les dije que se buscaran otro programador. Un año después, sin conseguir programador, me hacían la ola para que volviera. Ahora no les hago nuevos desarrollos, pero sí el mantenimiento.

[#10 PowerRanger79]

#9 Hay que ir con un cuidado extremo...

¿Fue algo asi lo wue hicieron?

[#11 squanchy]

#10 No marcaron en la ficha de los productos un check para cobrar cierto concepto. Y estuvieron así durante meses.
Me culpaban de que ese concepto estaba relacionado con otro, "y si marcas el otro, se da por hecho de que esto también se tenía que cobrar".

[#13 Desactivado]

#11 Lo de siempre: no te lo avisan, pero tú tienes que saberlo todo

[#98 Fun_pub]

#13 Exactamente lo mismo que la imagen de #10

Pero claro, si es el usuario, era obvio y es error. Si lo hace el programador, era un error de información en el análisis y no es culpa del analista.

[#14 Desactivado]

#11 No soy programador, pero creo que lo más complejo es definir muy bien desde el principio del proyecto algo que creo que se llamaba "casos de uso", si no me equivoco, y lo que ocurrió es que no se previó esta situación en esa fase, no?

[#44 Desactivado]

#14 Lo de los casos de uso se usa en... la formación. En la vida real te cuentan lo que quieren, y a picar código.

[#52 redscare]

#14 En un proyecto normal, la implementación es casi lo que menos tiempo debería llevar. Yo suelo planificar 30% análisis, 30% desarrollo, 30% pruebas y correcciones menores y 10% de colchón para imprevistos. Pero claro, cuando ha planificado un iluminado que cree que el 90% es implementación... Pues los requerimientos son una mierda y las pruebas otra

[#16 jaramero]

#11 eso debería estar reflejado en un requerimiento, si no, ya pueden decir misa.

[#17 PowerRanger79]

#11 Pues para que sirve el check si haciendo otra cosa ya se cobra?... y... tardaron meses en darse cuenta?... en fin... de que me sonara.

No obstante, lejos de victimismos... los programadores debemos hacer que las cosas sean extremadamente obvias e inequivocas (y no siempre es facil porque es algo subjetivo)... por ahi estuvo tu... "fallo".

[#19 squanchy]

#17 Pues porque tenían clientes especiales que sólo pagaban el primer check pero no el segundo, aunque la inmensa mayoría pagaban las dos cosas. Debimos prever todos que iban a ser unos torpes, y poner que por defecto se marcaran los dos, y luego ya que desmarcasen el segundo si hacía falta.
En fin, que el cliente pide, y yo hago. No soy su madre para tener que estar encima de él.

De lo que estoy más contento es de no haberle dejado poder modificar facturas. Y aún así, de vez en cuano la lían y me llaman para que yo borre o modifique a mano facturas (para no tener que hacer facturas de abono y tal).

[#29 PowerRanger79]

#19 a mi me piden a menudo mas "libeertad" para hacer cosas... y tengo que decir... noooo porque si no la liaras haciendo esto y lo otro....

Eres como un dejavu.

[#30 squanchy]

#29 Y a veces te piden que haga tantas cosas, que luego ellos mismos no saben manejarlo.

[#31 PowerRanger79]

#30 Yo al no ser empleado, sino fabricante, detecto necesidades y escucho sugerencias, pero si tengo que decir no, digo no.

[#56 gadolinio]

#11 en la empresa donde trabajaba antes le dije a mi jefe que era recomendable que quien hacía creado el programa de facturación nos diera un pequeño cursillo de las opciones que tenía y cómo usarlo para poder sacarle todo el partido.

Cuando llamó para preguntar y le dijeron que llevar un técnico a la empresa para explicarnos cómo funcionaba el programa iba a costar dinero decidió que averiguáramos nosotros mismos cómo funcionaba.

Quizá mi exjefe no perdiera dinero de forma directa con el programa pero de forma indirecta: pufff, esa es la mentalidad muchas veces

[#74 Desactivado]

#9
Eso no es culpa tuya ni de coña, si no se prueban las cosas y asumen que " hombre claro es que esta casilla se da por hecho que es también para esto" como dices mas abajo, que les den por ahi.
Ademas 2.000 putos euros ni que fueran 200 mil.

[#48 dragonut]

Esta mal redactado el titular, debería ser:

Un programa informático de la subcontrata de la subcontrata de la subcontrata de la multinacional Indra provocó un agujero de 10 millones de euros en la Hacienda canaria

[#64 estoyausente]

#61 es casi imposible, los criterios de solvencia son una locura. «Facturar más de x durante los últimos y años» siendo x lo que a Indra le venga bien

[#65 j-light]

#64 a mi me paso en un proyecto que alcance a ver. Era muy factible para un pequeño equipo de profesiinales. Pero te pedian una pasta en el banco que no es posible tenee si eres pyme. No puedes dar el salto

[#67 estoyausente]

#65 si hablo desde la experiencia... No es fácil por los requisitos económicos y de historia, es una puta mierda

[#84 mr_x]

#64 Sí, por eso comentaba que es necesario disponer de una gran cantidad de recursos propios. Afortunadamente esto no pasa en otros países del mundo...

[#32 voidcarlos]

Pero y el dinerito que se habrá llevado el comercial de turno de Indra, ¿qué? Y los supermanagers, y todos los que de milagro saben distinguir un teclado de un ratón.

[#6 Desactivado]

¿Por qué Indra está en el ajo de todas estas mandangas?

[#8 squanchy]

#6 Porque las exigencias de la administración a la hora de hacer un contrato hace que sólo las grandes corporaciones puedan apuntarse al carro. Las empresas de chichinabo de tu ciudad pueden acabar haciendo al final el trabajo, pero como subcontratas.

[#61 mr_x]

#8 Has pecado de simplista, aunque acabes teniendo razón.

#6 Cualquiera puede acceder a una licitación pública, pero no es nada sencillo. Los factores determinantes para ganarla pasan por el precio, la calidad, la solvencia y la experiencia. Sin contar que las entidades públicas no se rigen por las mismas normas cuando toca pagar, así que se necesitan muchos recursos propios para tirar adelante.

[#83 oscurete]

#61 Estuve varios años trabajando en varias carnicas para una empresa pública y, junto con otros compañeros en la misma situación, nos planteamos montar nuestra propia empresa para presentarnos.

Imposible. Era necesario que la empresa llevase años funcionando con beneficios, dejar en deposito una fortuna del tamaño de la del rey y pagaban a los 90 días.

Y eso sin contar los chanchullos, como que en teoría yo no podía trabajar allí porque no tenía la carrera terminada, así que presentaba mi curriculum como licenciado, luego decían que esa persona había dejado la empresa y presentaba el mio real como alternativa.

[#39 woody_alien]

#6 Porque está sobre-dimensionada.

[#3 PowerRanger79]

Esto es porque no hicieron los unit tests.. (es sarcasmo).

[#4 TheIpodHuman]

Indra es el nuevo programador de agujeros negros en IT

[#2 PowerRanger79]

Putos programadores informaticos, habria que matarlos a todos.

Fdo: un pr.... oh wait!

[#37 selina_kyle]

#2 menos mal porque para humorista no ibas jaja

[#68 JimmyTM]

#37 Y un sillón de la RAE tampoco se lo iban a dar.

[#34 santim123]

No es un bug, es una feature para el contribuyente

[#28 vvjacobo]

Hail Indra!

[#36 guiked]

y sin responsabilidad penal, 10/10 la estafa.

[#47 Desactivado]

Todo proyecto de Indra provoca grandes agujeros financieros, especialmente en arcas públicas. Que se den con un canto en los dientes que podría haber sido peor.

[#40 rogerillu]

La peli Trabajo Basura ha hecho escuela.

[#53 rogerius]

Al final nos quedaremos sin ozono.

[#82 j0seant]

Ahora le volverán a pagar otro pastizal a Indra para que lo corrija..

[#63 zambombas]

Yo trabajo en la competencia de Indra en temas de tributos , mis jefes deben estar frotandose las manos.

[#75 mialma]

Vienen de un programa hecho en la casa.calculo que Indra tendría en contra a usuarios y al equipo técnico del programa anterior. Montar algo en donde nadie colabora,ni un poquito es complicado. Suerte que llegaron al go-live sin que se hubiese caído el proyecto.

[#41 El_higado_de_Jack]

Y estos son los que dan los resultados electorales a las dos horas de cerrar los colegios.

Estos.

[#57 parrita710]

#41 No, el resultado se publica en el BOE dáis después. Indra solo muestra el conteo preliminar.

[#1 treu]

Skynet corrupto

[#35 Desactivado]

El programador Robin hood esta actualizando su cv en linkedin

[#46 Tannhauser]

La culpa fue del piloto becario.

[#7 Rojista]

Cómo avanza la tecnología , ya son capaces de programar hasta agujeros negros!!! Si Stephen Hawking levantará la cabeza!!!

[#62 Desactivado]

Quiere decir la noticia que por un fallo informático alguien se apropio de 10 millones de euros.

[#73 SlurmM]

El problema es encargar a una empresa el desarrollo de un programa sobre cuya lógica de negocio no tiene ni idea. En mi caso, como analista de la administración, los proyectos q encargo trato de que la implementación de los procesos criticos del negocio sean desarrollados desde la casa, o incluso por mi mismo, y solo externalizo los desarrollos del frontend y de operaciones mas simples.

[#87 Desactivado]

#73 Afortunado tu, tu departamento y tus proveedores.

Lo más habitual es lo contrario:
- En el pliego no hay requisito de conocimiento previo sobre el negocio. O es tan "vago" que cualquier empresa puede presentarse.
- Administración publica que no sabe lo que quiere y los requisitos iniciales eran de verguenza.
- Cambios constantes según el proveedor va preguntando al cliente y el cliente se da cuenta de "pues esto no lo había pensado".
- En proyectos de larga duración hay bajas en el equipo del cliente (embarazos, excedencias, cambios de departamento), que en el mejor de los casos solo significan un retraso y el peor recibir nuevos "inputs".
- Ni dios quiere firmar documentos de especificaciones, requisitos... la respuesta más habitual "vosotros id empezando y ya lo cerramos luego"
-...

Y sin hablar de aceptaciones, planes de pago, etc...

No nos engañemos, nuestras empresas están hechas a la medida de nuestra administración.