Solo en un país como el nuestro, excesivo en todo lo que sea la cultura del pelotazo, puede existir un número tan elevado de empresas que dedican la totalidad o gran parte de su plantilla a servicios de trabajo temporal. Las llamadas “cárnicas”; esas que se autodenominan: Consultoras de servicios informáticos. En esta segunda parte quiero echar una mirada crítica en profundidad a dichas consultoras, a su forma de hacer las cosas y a clarificar porque no son empresas de desarrollo de software.
Comentarios
#4 No sé de donde sacas eso.
El cliente pacta unos requisitos iniciales. Es obvio que en los funcionales y en los presupuestos va a haber lagunas.
Ahora bien, qué pasa si a mitad del proyecto se descubre un problema gordo que debería retrasar la salida al mercado del proyecto durante seis meses, o alguien se da cuenta de que ese proyecto tan costoso no cumple con los requisitos de negocio? Si es un producto desarrollado por un cliente final, habrá una reunión de varios departamentos en la que el jefe del departamento de desarrollo tendrá que aguantar bastante presión, pero si sabe explicar lo ocurrido se aceptará el retraso. Qué pasa con una consultora? Pues que el cliente querrá que la consultora asuma los costes del problema, la consultora dirá que no, porque no estaba previsto en el funcional y al final se hará lo que esté reflejado en el documento, sea lo que sea.
Y esto nos lleva a una segunda parte. Si los desarrolladores del cliente ven este problema, saltarán la alarma. A la consultora le interesa cobrar y si eso ya lo arreglará durante el mantenimiento.
Y no es que sea evidente. Es que el cliente no sabe si una aplicación va a cumplir realmente con sus requisitos hasta que no la ve funcionando y la prueba. Dices que es evidente de forma sarcástica, pero es que es evidente. Yo ahora trabajo en cliente final (afortunadamente pude abandonar el mundo de las consultoras), haciendo un producto que usan otras empresas, y muchos de los que solicitan el producto no saben exactamente lo que quieren (y cuando lo ven deciden si lo quieren o no). Es por eso por lo que se ofrecen periodos de prueba gratuitos. No es ningún insulto al cliente, es que es obvio que no se puede estar en todo, y mucho menos cuando se habla de comenzar algo complejo desde cero. Hasta que no se ve un mínimo esqueleto no se sabe exactamente qué es lo que se va a necesitar o cual es la mejor forma de organizarlo.
#5 No sé de donde sacas eso. ¿25 años como informático cliente quizá?
pero si sabe explicar lo ocurrido se aceptará el retraso Hijo, no sé (nooo, ni quiero, lo de la privacidad y esas cosas) en qué empresa trabajas, cuál es su modelo de nogocio. Yo trabajo en un cliente final de los que (creo) probáblemente vean tu producto para decidir si lo quieren, para aprender de las cosas que se pueden pedir porque es lo que hay en el mercado, o solo para ver si tu producto se adapta a sus requisitos (me he visto en las tres, son muchos años, comprendeme). Pero también me he visto en proyectos a medida en los que la parte informática, de cinco años/hombre de trabajo, era menos del 10% escaso del proyecto de negocio completo. Y no, el cliente no asume el retraso. El día pactado para salir al aire se sale al aire, y el informático se apaña como puede. Y se apaña, te lo aseguro.
Otra cosa es la negociación comercial de quién paga qué.
#6 Me refiero a que no sé de donde sacaste lo de que no conocemos la realidad.
Yo tengo menos años de experiencia, pero he trabajado en tres consultoras y en un cliente final, y mantengo contacto con gente que trabaja en otras consultoras y clientes. Solo tengo 8 años de experiencia, pero yo también he visto abrirse el infierno, y en las consultoras eso pasa frecuentemente, afecte a tu proyecto o al de al lado. Lo que tienen las consultoras es que la gente se mueve mucho hasta encontrar una consultora que le gusta (raro) o conseguir un contrato de cliente final.
En consultora he visto "apañárselas" para sacar proyectos en el tiempo haciendo horas extras los siete días de la semana cuando se acerca el plazo, ocultando los problemas con la esperanza de que en producción no pase nada... y mil cosas más. En cliente lo que veo es un plazo orientativo. Las estimaciones finales son internas y los comerciales dicen siempre que X actualización está prevista "para estas fechas". Está claro que tiene que haber un buen motivo para no cumplir el plazo, pero ni éste plazo es tan estricto (nadie dice que el 6 de Julio es la puesta en producción llueva o haga sol) ni es inamovible.
Aunque supongo que cada cliente final actuará de una forma, claro.
La negociación comercial es para mí la clave. Los intereses de los informáticos del cliente final pueden ser opuestos a los de los de la consultora. Bueno, más bien a los de los jefazos de la consultora. Es lo que he dicho, mientras la consultora tiene como objetivo cumplir los requisitos firmados en los funcionales el cliente tiene como objetivo que el producto funcione, sea la definición de "funcionar" la que se ha plasmado en los funcionales u otra muy distinta que se va viendo con el tiempo. Por eso prefiero la mentalidad de cliente final.
Estoy de acuerdo con su opinión negativa de las consultoras, pero no con el desarrollo de la noticia.
- Sí que son empresas de desarrollo de software, ya que son empresas y desarrollan software.
- Sí que se puede pedir una estimación de cuanto tiempo se va a tardar en hacer algo, lo que ocurre es que en el cliente final se comprende que el producto podría salir más tarde si no cumple los requisitos para salir al mercado o podría salir antes ya que no se está facturando por horas y a nadie le interesa retrasarlo (bueno, a los comerciales por estrategia de mercado para hacerlo coincidir con algún otro evento, pero no es algo tan genérico).
Lo de la división estoy de acuerdo. En otros lugares no se es programador senior sin 7 u 8 años de experiencia, y el siguiente paso es lead developer o arquitecto de sistemas, algo que la mayor parte de la gente no es. La división de las consultoras existe para jerarquizar y dar caramelos a la gente que se porta bien.
- Afirma que Una persona con dos años puede ser mucho más productiva de lo que será nunca una con 10 años de experiencia. En teoría. En la práctica, una persona con 10 años de experiencia real se ha encontrado con todos los problemas previstos e imprevistos, mientras que la que tiene dos años de experiencia no lo ha hecho. Podrá codificar más rápido, o ser mejor aplicando patrones, pero a la hora de la verdad no será más productiva salvo que la de 10 años de experiencia se haya acomodado y se esté rascando los huevos. Esto pasa en las consultoras, claro. Una vez te das cuenta de donde trabajas, no hay nada que te motive a hacer bien tu trabajo.
- Apartado "colocar al junior como AP". Si ya hemos quedado en que la clasificación es absurda, hay poco más que decir. Lo que hacen es tratar de vender sus recursos lo más caro posible.
#1 El problema que tú también comentas de la productividad viene porque, al ritmo que hoy en día se actualiza la tecnología, la clasificación en años de experiencia es absurda.
Sobre la estimación de tiempo las opiniones son tantas como trabajadores. Particularmente creo que lo ideal son las metodologías ágiles aplicadas a la tecnología pero, sabiendo que ni siquiera los clientes saben muchas veces lo que quieres, es prácticamente imposible estimar tiempos cuando los funcionales cambian cada semana (si es que se hacen, porque para muchas consultoras es tiempo que se pierde).
#2 Una clasificación tan inamovible es absurda, pero tampoco vamos a poner a alguien que lleva toda su vida trabajando en tecnologías host con un lenguaje orientado a objetos o a programar en front end. En realidad he visto hacerlo en consultoras, pero no es lo aconsejable.
En general, un programador con experiencia programando en struts y mySQL podría cambiarse tranquilamente a Spring y HQL sobre cualquier base de datos. Cualquiera que tenga experiencia en un lenguaje estructurado puede aprender rápidamente PL/SQL o cualquier otro similar, aunque la sintaxis sea diferente al lenguaje con el que aprendió. Alguien con experiencia en Java podría aplicar rápidamente sus conocimientos a Android (aunque un cambio así ya es bastante radical, y me parece desaprovechar gran parte de la experiencia).
Los funcionales cambian cada semana, como también cambian los requisitos si estás en cliente final. Una metodología ágil se adapta a eso. Lo que ocurre es que en la consultora tienen que hacer un presupuesto al principio del proyecto, o definir costes extra para cambios... sí, ya digo que esto es uno de los problemas de la consultora. Pero estimación de tiempo hay que hacer, la diferencia está en cuando esta estimación es orientativa (porque tú eres el cliente final, el dueño del producto y sabes que la calidad del producto es tu principal objetivo), o cuando es inaceptable porque estás vendiendo un producto que cumple una serie de requerimientos, y cualquier cambio extra no te aporta beneficios y sí costes, por muy necesario que sea el cambio para el software desarrollado.
#3 La pequeña tontería de que el mundo no se detiene para que podamos hacer nuestro proyecto como lo hemos pactado, y que cuando el cliente pide un cambio es proque los requisitos de su negocio han cambiado, o los ha comprendido mejor, que también se da, esas cosas no las tenemos en cuenta, ¿verdad?
El cliente final, que es el que paga, no tienen ni idea de su negocio, es evidente, y como consecuencia los comerciales le venden lo que les da la gana, faltaría más, etc etc.
Anda que al que ha redactado este artículo y a la mitad de los informáticos que escriben en meneame no les hace falta un paseíto por la realidad.