Soy un freelancer de programación/ingeniería que trabaja como consultor para una corporación mediana. Esta corporación mediana tiene muchos clientes, incluida una empresa financiera muy grande (una de las 10 principales empresas financieras del mundo), a la que llamaremos "Cliente X". Hace años (antes de que comenzara a trabajar aquí), mi cliente creó un sitio web de cumplimiento personalizado para el Cliente X.
Originalmente me contrataron para simplemente implementar un nuevo diseño sobre la infraestructura existente del sitio web, pero pronto me asignaron nuevas tareas (corrección de errores, pequeñas mejoras) y luego proyectos más grandes (nuevas aplicaciones para el sitio web, etc.).
La mayoría de estas tareas y proyectos se han gestionado utilizando hojas de cálculo muy rudimentarias, comunicación por correo electrónico y reuniones ocasionales. Continuamente he solicitado Especificaciones Funcionales y/o documentos de Reglas Comerciales del Cliente X, pero nunca me han respondido. En cambio, me dan una lista de tareas/proyectos de una línea y plazos para cada uno (que generalmente no son razonables).
Además de esto, el Cliente X rara vez ayuda con las Pruebas de aceptación del usuario y, en cambio, espera que simplemente tome sus solicitudes, las cree, las implemente y haga que todo funcione exactamente como lo solicitaron.
Cuando aparecen insectos, sus plumas se erizan mucho. Se quejan de los errores y del tiempo que se tarda en corregirlos, etc.
Ahora, sé que como el único ingeniero de software de mi cliente, soy responsable de los errores. Sin embargo, creo que sin una gestión de proyectos adecuada, es más difícil crear código libre de errores. Como resultado de la falta de asistencia del Cliente X, tuve que hacerme responsable de realizar todas las siguientes tareas para cada proyecto:
Ahora, no me malinterpreten, disfruto cada paso del proceso: soy perfeccionista y me gusta ser organizado. Sin embargo, tengo que admitir que no soy un gran control de calidad o probador de aceptación de usuarios. No soy un usuario "normal" del sitio web en cuestión, por lo que no puedo pensar en todos los escenarios para probar. Además, el tiempo que llevaría probar correctamente cada función me quita el tiempo que podría estar trabajando en otros proyectos para el Cliente X.
Es una trampa 22: quieren que sus tareas/proyectos se realicen rápidamente y sin errores, pero no se dan cuenta de que esas dos cosas no siempre existen juntas.
El primer paso que he dado es comenzar a escribir scripts de prueba y ejecutarlos para cada tarea/proyecto en el que trabajo.
Pero, aquí también hay inconvenientes. Me pagan como programador/ingeniero de software. No tengo ningún problema en que me paguen mi tarifa actual para probar aplicaciones/características, pero me parece ridículo que me paguen tanto como ellos por este aspecto, cuando podrían estar pagándole a alguien mucho menos (no sé, $15-20/hora ?) para ser un probador. El cliente X se queja de las implicaciones financieras de trabajar en la corrección de errores, pero para mí, tendría sentido contratar a un probador por mucho menos dinero para ejecutar scripts de prueba y liberar mi tiempo para escribir código.
Intenté explicarle estas cosas a mi supervisor, que es 1. el enlace del Cliente X 2. el programador original del sitio web y 3. el vicepresidente de mi cliente, pero se apega al viejo adagio de "el cliente es siempre tiene la razón", y piensa que si no quieren escribir especificaciones funcionales y no quieren ayudar a probar y no quieren usar una gestión de proyectos adecuada, NOSOTROS tenemos que lidiar con eso.
Entonces, ¿cuáles son algunas formas en que puedo "lidiar" con este entorno/cliente?
Mi consejo sería adoptar un enfoque ágil/iterativo .
Dependiendo de la complejidad del sistema y de los cambios que esté realizando, puede que no sea necesario emplear una metodología de Waterfall tradicional y completa.
Sin embargo, asegúrese de tener un control de fuente adecuado y algún tipo de sistema de seguimiento de cambios (incluso si es solo una hoja de cálculo por ahora).
Si lo que preguntan no está claro, haz más preguntas hasta que lo entiendas y luego haz los cambios.
Explíqueles que lanzará pronto y con frecuencia , y que probará el software usted mismo, lo mejor que pueda.
A partir de ahí, puede ser responsabilidad del usuario final verificar que lo que ha hecho es realmente lo que quería.
Con un ciclo de lanzamiento corto, podrá tomar esos comentarios, cambiar los cambios rápidamente y hacerlos felices.
Preparé un minisitio completo con algunos consejos adicionales que también podrían ser útiles: http://doingitwrong.jasonhanley.com/
"¿Cuáles son algunas formas en las que puede 'dear' con este entorno/cliente?" Sencillamente, aprenda a hacerlo a su manera.
Si bien entiendo su frustración, especialmente como perfeccionista, el hecho es que usted es un consultor externo contratado. Tu trabajo es hacer aquello para lo que te contrataron y hacerlo dentro de su entorno. 'Usted' tiene que adaptarse, no ellos.
Como ha señalado, las dos empresas tienen una historia, y para bien o para mal, para bien o para mal, funciona para ellas. Así que no lo vas a cambiar.
Entonces, como sugirió David, acepte que así es como hacen negocios y aprenda a trabajar dentro de ese modelo. Simplemente no espere que cambien sus métodos.
Y tal vez tenga suerte en el camino y al menos haga que adopten 'algunas' de sus sugerencias.
Parece que tienes varias cosas diferentes con las que te gustaría recibir ayuda. Trataré de brindar alguna orientación sobre algunos de ellos, pero la respuesta básica es comenzar a recopilar métricas (si aún no lo ha hecho) y presentar su información con números de $ reales adjuntos.
1. Pruebas
Es posible que ya haya seguido esta ruta, pero si es así, no lo vi en su pregunta. ¿Ha tratado de armar el caso de negocios a su supervisor de que vale la pena contratar a un probador? Parece que el Cliente X no quiere contratar a un probador, pero ¿qué pasa con su cliente directo? ¿Puede reunir el siguiente tipo de información y presentársela a su supervisor?
Es probable que los primeros tres de ellos sean un poco más sencillos para capturar la información que los últimos. Pero esos dos últimos son los que realmente ayudarán a presentar su caso.
2. Requisitos / Entendimiento compartido
¿Alguno de los errores en los últimos 6 meses se debió a una desconexión entre lo que el Cliente X quería y lo que implementó? Si es así, considere realizar un ejercicio similar al anterior (reemplazar las pruebas con la captura de requisitos). Asegúrese de que el Cliente X entienda cómo lo que está pidiendo se relaciona directamente con la obtención de un producto de mejor calidad en un período de tiempo más corto.
¿Ha recibido alguna solicitud de cambios/adiciones en los últimos 6 meses que le haya hecho retroceder y realizar grandes cambios en el código existente que había tocado recientemente para otros cambios/adiciones? Ser capaz de capturar esto y ponerle un valor en dólares puede ayudarlos a que hablen con usted acerca de sus objetivos completos en lugar de identificar cambios individuales a la vez. Y si tiene una mejor comprensión de sus objetivos finales, puede asesorarlos mejor acerca de si ciertas características están conectadas y deben llevarse a cabo juntas.
Considere buscar alternativas a las especificaciones funcionales formales para capturar los requisitos. Busque opciones como usar historias de usuarios que permitan al Cliente X transmitir lo que quieren en un lenguaje que les resulte más cómodo.
3. Gestión general del proyecto
Parece que debería tener una conversación franca con su supervisor. Si se supone que su "equipo" debe manejar la gestión del proyecto (porque esa es la expectativa del Cliente X), entonces debe quedar claro quién se supone que debe desempeñar ese rol. ¿Se supone que eres tú? Luego, su cronograma y los plazos deben reflejar que el rol requiere una cierta cantidad de tiempo para realizarse correctamente, incluso en un proyecto pequeño.
Tiene más problemas aquí que solo un método de PM faltante. Pero, de nuevo, parece que esta es la forma en que su cliente y el cliente X han estado operando durante "años". Tengo la impresión de que no quieren invertir una tonelada de dinero en la capacidad que desarrollas y tal vez es solo cultural quejarse y quejarse.
La entrega de cualquier cosa sin errores es imposible y, a menos que el Cliente X cuente con monos, esa noción es conocida. Así que tengo la impresión de que solo se quejan como una forma de administrar a sus proveedores.
Creo que la probabilidad de que obtenga algún cambio aquí es bastante baja. Parece que esta configuración es el nivel de capacidad y madurez que quieren para su área, es decir, el nivel de inversión es consistente con sus expectativas de rendimiento.
Tiago Cardoso
lunívoro
eric belair
jhsowter
agente provocador