Hace unos días empecé una encuesta cualitativa (las que más me gustan) sobre los típicos problemas a los que se enfrentan los desarrolladores en su vida profesional.
Son desarrolladores de dentro y fuera de Velneo, es decir, son problemas generalizados en el ‘gremio’.
Es aconsejable, en los estudios cualitativos, plantear supuestos imaginarios para que los entrevistados tengan la máxima libertad al expresar sus opiniones.
El supuesto era el siguiente:
Imagínate que un sobrino tuyo se quiere dedicar profesionalmente al desarrollo de aplicaciones profesionales (no me refiero en Velneo !!, sino desarrollo en general !!)
Después de hablar de lo bonito que es desarrollar, de la satisfacción de ver algo funcionando y de crecer con tus clientes,etc…. él te pregunta:“ Y con qué 3 cosas es más probable que tenga pesadillas cuando sea desarrollador de aplicaciones profesionales? “
1->
2->
3->
Las respuestas que recibí no tienen desperdicio y me han ayudado a seguir entendiendo la problemática a la que se enfrentan a diario los desarrolladores y así orientar mejor la comunicación.
Nota: He destacado en negrita las 2 palabras que más han aparecido: “cliente” y “cambio” . Creo que a nadie le extraña 
Vemos algunas de las respuestas que he recibido:
——–
1- Con perder los datos de un cliente.
2- Con dejar una empresa parada durante 24 horas por culpa del software.
3- Con que le prometí a un cliente un modulo X y despues no poder hacerlo.
——–
1- No conocer el lenguaje del cliente ( si contador, si medico, si ingeniero).
2- No establecer desde el principio y por escrito los límites y alcances de lo propuesto.
3- Por no querer pagar por una solución profesional ya hecha ( plantillas, solucion de terceros) perder una infinidad de tiempo y no dar soluciones prontas debido a eso. ( recomiendo a todos la lectura del libro “Padre Rico, Padre Pobre”)
——–
1.- Los Clientes que vienen con Modificaciones adicionales fuera de presupuesto, o cuando haces la presentación del proyecto al final del desarrollo. ( los ‘po ya que’ )
2.- Por un lado, hacer entender al cliente el valor de una aplicación desarrollada a medida, y por otro, cobrarlo después.
3.- Las peculiaridades de los entornos de desarrollo y sistemas operativos, (fallos o no) que hacen que te vuelvas loco buscando el problema de algo que en teoría debe de funcionar.
——–
1.- El presupuesto (económico y plazo de entrega): si está bien calculado, si nos vamos a ver pillados, si vamos a conseguir tardar lo que dijimos…
2.- Los cambios durante el desarrollo: lo que el cliente, supuestamente, quería decir pero se le olvidó comentar, lo que dice que dijo y realmente no dijo, los “pequeños cambios que seguro que son muy sencillos”, …
3.- La implantación y puesta en marcha: si todo funciona realmente bien, la importación de los datos antiguos, que todos los procesos complicados funcionen, que no haya bugs, gazapos o como sea…
——–
1. Agarrar una aplicacion de otro desarrollador y no este documentada, ni tan siquiera los procesos
2. Los tiempos que se le dan al cliente, que siempre son mucho y te dicen, esto es muy facil. incluso te dicen ellos el tiempo que vas a tardar
3. Documentar la aplicacion para el cliente
——–
1- Errores y limitaciones de las herramientas de desarrollo.
2- Análisis erróneos.
3- Clientes que no saben lo que quieren.
——–
1-> bloqueos de los registros en procesos grandes
2-> gestion transaccional de procesos
3-> tiempos de ejecucion de los procesos
——–
1.- Clientes
2.- Clientes
3.- Clientes
——–
1. Los cambios sobre lo previsto, son inevitables y si no se controlan puede suponer que el proyecto nunca termine, que al final no sea rentable y que el cliente se acostumbre al cambio por el cambio.
2. Localizar y reparar errores ocultos, ese tipo de cosas que pasan de vez en cuando, no siempre en el mismo lugar de la aplicación, que no eres capaz de reproducir, que siempre le pasan al usuario cuando no estás delante, te hacen perder muchísimo tiempo y al cliente continuas paradas y cabreo de los usuarios.
3. La generación de informes, te dedicas durante mucho tiempo a diseñar y al final te quedan los dichosos informes, que son ingratos, poco gratificantes y desde luego una de las partes más importantes de una aplicación de gestión, en algunas es casi su única misión, además es difícil que los mismos informes sirvan para todos los clientes, también puedes entrar en el cambio por el cambio.
——–
1-> Con los cambios que le vengan del negocio con el que esté trabajando.
2-> Si tienes que hacer cambios urgentes en toda tu base instalada y tienes que actualizar a todas las instalaciones.
3-> Cuando para un cliente se plantean cambios muy gordos, que afectan al núcleo en una aplicación y por decisión estratégica hay que hacerlos
——–
1-> Problemas de estabilidad del sistema: Transacciones, Incoherencia de datos, problemas de índices…
2-> Informes muy específicos que quiera el cliente
3-> Programación específica de funcionalidades a las que no llega tu herramienta
——–
1.-Que tus clientes no valoraran tu trabajo y lo consideraran más fácil de lo que realmente es.
2.-Que tu herramienta no te permitirá realizar trabajos que requeriran tus clientes.
3.-Que tus ratios de tiempo-desarrollo/venta no sean lo suficientemente buenos y debas de trasladar el coste a tu cliente final en lugar de aprovechar un buen ratio para tener tú mismo más beneficio
——–
1- La falta de documentación por falta de tiempo. Todo hay que hacerlo para ya, y después no te acuerdas de que hacía esto, y mucho menos entender que hace algo desarrollado por otro.
2- El desconocimiento del campo en el que se desenvuelve el cliente. La nomenclatura, lo dificil que es ver un problema todo en su conjunto. Vamos, los problemas de análisis
3- La ausencia de un equipo de pruebas por falta de infraestructura de este tipo de empresas de desarrollo de software de tipo pequeño/medio
——–
1-> Problemas de obsolescencia tecnológica
2-> Problemas de inestabilidad de mis aplicaciones
3-> Poder contratar fácilmente programadores que conozcan la herramienta.
——–
1. La discontinuidad de los productos.
2. La necesidad de estar al tanto de TODO y la necesidad de especializarse.
3. Que un cliente me solicite una modificacion de un programa que hace 5 años que no toco ni me acuerdo de como está hecho.
——–
1) Sentirte solo (desamparado, sin respaldo) ante un proyecto
2) Tener que tragarte documentación (si la hay) que no está en tu idioma (eso cansa mucho!)
3) Tener que picar una y otra vez el mismo código sin poder reutilizarlo
——–
——–
Gracias de nuevo a todos por participar
.
Por cierto….. ¿qué 3 cosas responderías tú?
Etiquetas: aplicaciones cliente, cambios software, cliente, desarrollo aplicaciones, encuesta software, modificacion software, pesadilla programador
(11 voto(s), 5,00 sobre 5)
25.08.2010 11:43
23.08.2010 21:45
02.08.2010 04:30
01.08.2010 10:43
20.07.2010 17:19
27.10.2006 | 165 Comentarios
27.04.2006 | 84 Comentarios
12.04.2006 | 82 Comentarios
23.01.2009 | 65 Comentarios
Noviembre 21, 2008 - 11:42 #
Nico, simplemente Genial.
Gracias me he sentido totalmente identificado con “todas”.
Gracias por compartir esto me encantó.
Noviembre 21, 2008 - 12:02 #
Muy bueno Nico, muy clarificador
Noviembre 21, 2008 - 13:15 #
Buen trabajo Nico. Además, me parrecen todas como si me hubieran pasado a mí!!!
Noviembre 21, 2008 - 15:46 #
Excelente de verdad… a todos nos ha pasado, y no solo en pesadillas!!!
Noviembre 21, 2008 - 18:24 #
Me identifico con casi todas esas pesadillas.
Pero lo cierto, y esto no es coba, es que con Velázquez-Velneo son la mayoría pesadillas pasajeras, otras no son relevantes para mi situación pero me imagino cómo se sentirá la mayoría de los programadores en esas situaciones. Pero lo que sí me ha producido verdaderas angustias es:
“2. Localizar y reparar errores ocultos, ese tipo de cosas que pasan de vez en cuando, no siempre en el mismo lugar de la aplicación, que no eres capaz de reproducir, que siempre le pasan al usuario cuando no estás delante, te hacen perder muchísimo tiempo y al cliente continuas paradas y cabreo de los usuarios.”
Acostumbrado a que todo sea tan sencillo y seguro, encontrarte en esa situación es algo que no le deseo a nadie, y al final cuando todo se resuelve tengas que decirte:
- ¡Si seré idiota! ¡Vaya gilipollez! .
Y, encima, comprobar que has tropezado más de dos veces en la misma piedra.
Noviembre 22, 2008 - 18:59 #
Hola Nico,
No se por qué pero todas esas respuestas me suenan de algo… ;-D
Tras tantos años desarrollando a medida aprendes una cosa fundamental que puede englobar de forma resumida todas las respuestas relacionadas con cliente y cambio:
- Saber presupuestar
Me gusta hablar y contactar personalmente con el cliente, si puede ser cara a cara, para conocer su idiosincrasia de primera mano. De esta visita sacas en claro cómo es ese cliente, si sabe lo que quiere o no, y si va a ser de esos que luego recurren al “pero eso ya lo pedí así desde el principio…”.
Por eso en los presupuestos suelo incluir una muy detallada explicación de los requisitos que la aplicación va a cumplir, fruto de esas primeras negociaciones, y también lo que NO VA A CUMPLIR, es decir, lo que NO ESTÁ INCLUIDO EN EL PRESUPUESTO.
Puede parecer de perogrullo pero es de VITAL importancia para luego evitarnos problemas como los comentados respecto del cliente, cambios y demás.
Con esta inclusión, la gran mayoría de posibles discrepancias posteriores a la firma del acuerdo, normalmente relacionadas con plazos, alcance de la aplicación, utilidades, etc, quedan solucionadas de un plumazo, ya que no queda sitio para el “yo dije, tú dijiste…”. Está todo por escrito y detallado.
Al final el presupuesto parece hecho por Epi, Blas y Coco (SuperCoco), pero la experiencia me dice que es absolutamente necesario para evitar que alguien se lleve a engaño; esto sí y así, esto NO y es que NO.
Ah! y cualquier otro aspecto NO incluido en el presupuesto será objeto de otro presupuesto.
Un saludo,
Noviembre 24, 2008 - 04:32 #
Muy bueno el aporte Nico,
Invaluable para quienes comenzamos en esto del desarrollo de software y en mi primer desarrollo termine cobrando la mitad de lo que hubiese cobrado si hubiera sabido por todo lo que me hiba a tocar pasar en la parte de soporte y desarrollo no estipulado, puero bueno, en esa epoca me toco conformarme con el orgullo de haberme ganado unos muy decentes pesos por el desarrollo de una base de datos para el Municipio de Medellín sin ser programador de profesión.
No creo que quepa dentro de las pesadillas para el desarrollador pero, que mala sensacion queda cuando te preguntan cuanto cobrarias por hacer X desarrollo, te tomas un dia para hacer las estimaciones y pues das un valor y te lo aceptan a la primera sin preguntar, ni regatear, ni nada de eso … queda inevitablemente una sensación de “regale mi tranbajo demonios” … no ?
VSaludos
Cristian Vasquez
Medellín Colombia
Noviembre 24, 2008 - 09:58 #
sí; son geniales las respuestas por su espontaneidad.
Casi cada punto da para un post, a mí (que no soy técnico) me interesa especialmente el tema de la gestión del proyecto; como bien apuntáis: desde la definición de los requisitos (expectativas) hasta la entrega o presentación a cliente.
saludos!!
Noviembre 24, 2008 - 13:42 #
1. El dejarte las pestañas tratando de localizar un error chorra, a.k.a. la falta de una buena herramienta de traceo / debug que te facilite el encontrar errores.
2. Funcionamientos “particulares” de ciertas instrucciones y/o componentes, combinados con falta de información y ejemplos que te expliquen la particularidad de esos funcionamientos.
3. Problemas propios de la herramienta / entorno de desarrollo que utilices, que por ejemplo que te fuerce a realizar ciertos trabajos de una manera que resulte tediosa y poco eficiente.
saludos!
Noviembre 25, 2008 - 15:49 #
Muy bueno, me siento totalmente identificado.
Noviembre 25, 2008 - 16:40 #
Ya me había dicho Alfonso que estaba genial el post, y no esperaba menos de Nico.
Nota para Cristian, de Medellín, respecto a que si regalas tu trabajo…. mi opinión si te sirva es:
- regalamos nuestro trabajo cuando no recuperamos el dinero invertido en lo que hacemos.
- si cobramos lo que queremos cobrar, y el cliente está contento, eso es un buen negocio, y tenemos que estar contentos.
Saludos
Noviembre 25, 2008 - 18:05 #
Hola a todoa. Yo añadiría dos más:
1.- Que la herramienta que utilizo para desarrollar y que he llegado a dominar tras muchas horas de trabajo, de prueba y error, de visitar y preguntar en foros, buceando en Internet, descubriendo detalles mal documentados o no documentados, bugs ocultos de la herramienta, comportamientos erráticos en determinadas circunstancias, posibilidades no descritas por el fabricante, etc. que esa herramienta, digo, tenga que cambiarla por la razón que sea: obsolescencia tecnológica, discontinuidad de la empresa proveedora o del producto o cambio de política de precios del proveedor de la herramienta que haga inviable continuar con su utilización.
2.- Que se popularicen entre los usuarios determinadas facilidades que con mi herramienta actual no pueda hacer facilmente y que mi proveedor no me las provea con la debida celeridad.
En el fondo esto es un trío formado por el proveedor de la herramienta, el desarrollador y el cliente y todas las pesadillas entre cliente y desarrollador se reproducen entre desarrollador y proveedor pero invirtiendo los papeles. En definitiva uno queda en medio y le dan por todos los lados.
Estas si creo yo que son pesadillas pues uno nada puede hacer salvo protestar. Las otras son cuestión de tiempo y esfuerzo. Con los años y las malas experiencias se aprende a deshacerse uno de ellas, pero de estas dos no hay manera. (Si alguien sabe cómo que lo grite por favor)
Saludos cordiales
Manuel Tovar
Barranquilla – COLOMBIA
2.-
Noviembre 25, 2008 - 18:34 #
@Manuel Tovar: estaba ahora leyendo tu primera ‘pesadilla’; gracias. Ahora por fin comprendo el verdadero alcance de la situación que tienen que estar viviendo los desarrolladores de Visual FoxPro o de Visual Basic 6.
saludos
Noviembre 25, 2008 - 20:07 #
@Nosuna, claro que sí a eso me refiero y pasó también con Clipper de Nantucket que luego pasó a manos de Computer Associates como CA-Clipper, lo quiso sustituir por Visual Objects y luego lo abandonó y pasó con FoxPro que fue vendido a Microsoft, ellos sacaron dos versiones, MS lo cambió totalmente con VFP y luego lo abandonó, y casi pasa con Delphi que de ser un lider en el mercado casi se acaba y pasó con Power Builder y muchos más que yo no conozco pero que seguro que hay. Y lo malo es que los desarrolladores nos quedamos a verlas venir porque nadie vende una herramienta con garantía de continuidad. Mira que idea buena: indemnizar a los que invirtieron y aprendieron y se esforzaron por dejarlos “huerfanos”, nadie hace eso. Y yo creo que de ese peligro nadie está exento, ni siquiera Microsoft y sino al tiempo.
Saludos cordiales
Manuel Tovar
Barranquilla – COLOMBIA
Noviembre 26, 2008 - 02:02 #
Muy de acuerdo con Manuel Tovar.
Sobre este asunto de obsolescencia de la herramienta o por quedar ésta muy por debajo de la vara impuesta por las necesidades, quiero decir que es aquí en donde el departamento de I+D o de Soporte juega el rol importante, si es que no se lo han dado: investigar sobre las nuevas tecnologías emergentes en esta área de las TIC. Que no se base en la Moda o en las restricciones impuestas por las instituciones de educación superior, léase universidades, en donde se aprende a programar en: .NET, Delphi, Visual C++ (no C o C++, VISUAL C++), toda la chorrada (como dicen ustedes en la península) de tecnologías “dominantes”.
Yo, de forma independiente, me cuelgo en Internet, buscando y probando nuevas tecnologías en software… Y fue así que encontré a Velásquez Visual. Buscando.
El software… ¿envejece? No. Sólo lo “jubilan”. Por ello, hay que acostumbrarse. No debemos cultivar expertise semi-religioso con alguna herramienta de desarrollo. Por ello, ya lo de picar código no me va en estos días. Busco herramientas que me permitan resolver problemas. He aquí un ejemplo: Velneo. He aquí otro: CodeCharge (varios me han escrito debido al post de un año atrás). Y cómo di con ellos: buscando.
No. Encajonarse porque es más fácil no aprender nuevas “estrategias”. No, no me acoplo a esa idea. Si Velneo se “muere” o no me surte plenamente a mis necesidades de desarrollo… busco otro que sí.
Siempre hay y habrá alternativas. Por último, me trago mis palabras de no querer “picar código” y me pongo a escribir unos y ceros. Punto.
Es mi opinión personal, mía de mí.
Noviembre 26, 2008 - 02:11 #
Aviso de utilidad pública:
Se necesita Software para mejorar redacción… Por favor, comunicarse, URGENTE, conmigo y pronto para entender mi post!!!
Pido las disculpas del caso, pues, lo he escrito en tres tandas, sin revisar, y se me han quedado algunas ideas y líneas colgadas o huérfanas de coherencia.
Pero, para sintetizar: acostumbrémonos al cambio. Evolucionar es la palabra, así sea cambiando de herramienta. Total, al igual que un escritor cambia la desvencijada máquina de escribir mecánica por un procesador de textos y un PC, esta “evolución” tecnológica no incide en nada al genio que lleva dentro, sólo le permite ahorrar en corrector líquido.
Mis cordiales saludos.
RolandoCF
Noviembre 26, 2008 - 09:54 #
@RolandoCF: “Software para mejorar redacción” jajaj Así está bien Rolando!! tranquilo, se captan tus ideas perfectamente
Diciembre 2, 2008 - 11:22 #
@Manuel Tovar: Ahí es donde tienen valor las herramientas de desarrollo de código abierto.
Diciembre 2, 2008 - 20:36 #
esas pesadillas las sufrimos todos
Diciembre 3, 2008 - 02:41 #
@Francisco Lozano. Desde mi modesto punto de vista la única ventaja que le encuentro a las herramientas de código abierto es su gratuidad. Por lo demás están sujetas a los sube y baja de la gente que esté detrás. A veces caminan deprisa, a veces se estancan. Siempre detrás hay personas liderando (normalmente muy pocas) aunque haya muchos aportando. Cuando el lider se frena o se aburre o lo contrata alguien el proyecto se frena, cambia de dirección, se estanca y a veces muere. Multiples ejemplos hay por ahí: Harbour, Clip, Xailer, xHarbour en el nicho de losl xBaseson proyectos con altibajos. En general persisten las que tienen empresas poderosas detrás. Un buen ejemplo es Netbeans con SUN empujando. Tras la adquisición de MySQL por SUN viene con MySQL integrada sin necesidad de gestionar la conexión, con select automáticas, una belleza, lástima que sea Java a pesar del esfuerzo en tutoriales, cógido gratuito, evangelistas de altura, etc. . Al margen, se han dado cuenta cómo se parecen últimamente todos los IDE de las últimas versiones de todas las herramientas: por ejemplo .NET, Netbeans, V7…por cierto siguen el modelo .NET Todos parecen la misma hasta en la distribución de las ventanas.
Saludos cordiales
Manuel Tovar
Barranquilla – COLOMBIA
Diciembre 3, 2008 - 09:28 #
Los años desarrollando aplicaciones te dan un bagaje de situaciones a las que has hecho frente que, sinceramente, no hay ninguna que me llegue a quitar el sueño; al final sabes como afrontarlas y a quién recurrir para pedir ayuda (Velneo, foros, compañeros, incluso clientes). Creo que es la forma de afrontarlas, el dialogo sincero con los clientes y la honestidad lo que te ayuda a solucionar los problemas. Si hay algo que no eres capáz de solucionar, el mero hecho de comentarlo te abre las puertas para encontar la solución, los clientes lo entienden y colaboran contigo para llegar juntos a lo que necesitan.
Diciembre 3, 2008 - 15:57 #
@Manuel Tovar: Respecto al comentario “…la única ventaja que le encuentro a las herramientas de código abierto es su gratuidad”, yo no relacionaría directamente abierto=gratis, porque en realidad no es necesariamente así, o al menos eso tengo entendido.
Me despierta curiosidad como puedes estar al tanto de tantas herramientas y bases de datos, incluido Velneo, y aún no hayas apostado fuerte por ninguna, tiene mucho mérito.
Un saludo
Diciembre 3, 2008 - 17:59 #
@Jorge F. Tienes razón, no quieren decir los mismo, pero casi todas las de código abierto son gratuitas y algunas de código cerrado como NetBeans también. Respecto a tu curiosidad, si he apostado fuerte por una herramienta, trabajo con VFP + MySQL desde hace 6 años y hasta ahora no me va mal. Yo creo que la mejor herramienta es la que uno domina. Cada vez más todas se parecen. Hace unos años las únicas que integraban la BD en el IDE eran Velneo y VFP, ahora casi todas. A pesar de que VFP es un producto descontinuado no he tomado la decisión de cambio a otra herramienta porque ese cambio es muy costoso en tiempo de aprendizaje, en diseños malos, en cometer errores y en compatibilizar sistemas viejos con los nuevos, además de que durante un tiempo debes trabajar en los dos ambientes lo cual es de lo más desgastante que puedo imaginar. JArboleya tiene un artículo en este Blog donde analiza este tema con lujo de detalle. Yo he hecho tres cambios de herramienta importantes en mi carrera: de RPG a Clipper, de Clipper a VFP con BD nativas y de VFP con Bases nativas a VFP con MySQL. Los tres cambios han coincidido con tres bajones grandes en el negocio por pérdida de rendimiento. Esa es la razón de no cambiar hasta estar muy seguro. En lo que he visto Servoy y NetBeans son muy buenos como IDE amigable, multiplataformas, muchos chiches como dicen los argentinos, etc. pero con el inconveniente de la oscuridad del Java.Esperemos la V7 que apunta muy bien, pero esperemos, ya queda poco. De alguna manera debo hacer el cambio pero no a lo loco, una equivocación en este tema es costosísima además de frustante, porque el cambio hay que hacerlo mientras sigues produciendo aplicaciones y cobrándolas.
Saludos cordiales
Manuel Tovar
Barranquilla – COLOMBIA