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.
|
etiquetas: indra , hacienda , canarias , agujero , programa , audiencia , cuentas
Fdo: un pr.... oh wait!
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.
¿Fue algo asi lo wue hicieron?
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".
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.
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".
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.
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).
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.
Eres como un dejavu.
Estos.
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...
pilotobecario.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
Hay que hacer toda la documentación que sepas que es realista mantener actualizada, pero no más.
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
#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.
En que pocos sitios gas trabajado tu...
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.
Claro y eso se abre como la caja de Pandora
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
Pues les salen, sera que pagan a 36 pero consiguen 100 mil sobrecostes
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
Ejemplo inventado para que se entienda a qué me refiero:
if (fileAlreadyExists(fullPath)) {
let answer = askWhatToDo()
if (answer === 'keepBoth') {
let sequentialSuffix = ' (1)'
/* etc etc etc */
}
}
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")) {
username += 'foobar'
}
¿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
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.
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.
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.
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.
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.
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.
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.
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...
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
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.
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.
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.
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.
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.