¿Son estos signos de un mal desarrollador? [cerrado]

Solía ​​culpar a las especificaciones cambiantes de los clientes por la descomposición del código, sin darme cuenta de que los modelos de negocio cambian y es mi trabajo desarrollar de manera adaptable. Ahora veo eso como un signo de un mal desarrollador (¡he cambiado!).

Pero ahora veo otros 'whinges' en mí mismo. Recientemente, me encontré a mí mismo diciendo 'es como tratar de colocar una clavija cuadrada en un agujero redondo', y también me encuentro culpando a la indecisión del cliente por un proyecto que no avanza.

¿Hay señales de que debería estar atento a dónde debería cambiar mi actitud? ¿El cliente siempre tiene la razón, o a veces estoy justificado para frustrarme?

No diría que eres un mal desarrollador. Ser consciente de los problemas ya te lleva más allá de esta definición.

Cambio de requisitos. Eso es un hecho. Un buen desarrollador necesita tener esto en cuenta. Muchas técnicas modernas de programación ayudan a lidiar con eso.

Mantenerse fiel a las especificaciones originales no es realista. Tampoco es realista cambiar los requisitos todo el tiempo.

El cliente definitivamente no siempre tiene la razón. Sin embargo, es "correcto" con más frecuencia de lo que queremos que él / ella sea (como en, trate de acomodarlo si no está totalmente apagado). Pero cuando lo vea conducir el proyecto en la dirección equivocada, intente defender las cosas que cree que son correctas.

No hay reglas estrictas sobre estas cosas, e incluso los desarrolladores buenos y experimentados no han logrado el 'Zen' perfecto. El único enfoque equivocado es no tratar de mejorarlos.

Hay casos en que ES el cliente. Pero ese también es tu problema

Hay casos donde es el desarrollador, y hay casos, donde es el cliente. Pero, por lo general, ambos son su problema, por lo que la actitud de culparse a sí mismo tiende a ser más exitosa, ya que se equivoca al lado de la resolución de problemas en lugar de señalar con el dedo indefenso. Por lo tanto, a menudo lo encontrarás en desarrolladores más experimentados.

Una actitud aún mejor es en mi humilde opinión mirarlo sin culpa: "es culpa de los clientes que tenga un código pésimo, porque siempre cambia los requisitos" y luego se convierte en "este cliente está descubriendo lo que quiere, por lo que la retroalimentación, la creación rápida de prototipos y la flexibilidad son más importante que la integridad, robustez y velocidad ".

Una especie de mente Zen: no lo juzgues, solo míralo como es.

Primero, un cliente no sabe lo que quiere hasta que lo ve. Eso es parte del atractivo de las pequeñas iteraciones del paradigma ágil con una gran participación del cliente. En segundo lugar, no espere que un producto esté "completo" cuando tenga el código completo.

Microsoft emplea un producto llamado 'Watson' (el mensaje de envío de comentarios que recibe cuando explota Windows) para rastrear los problemas directamente a un cliente. La trazabilidad es una buena forma de rastrear los problemas a los usuarios que los experimentan. Puede obtener trazabilidad preguntando. O, si tiene los recursos, integre la funcionalidad en los productos. La clave es rastrear los problemas / mejoras para que puedan abordarse.

Finalmente, los clientes seguros pueden ser volubles. En tales casos, trato de concentrarme en el secreto del iceberg .

Los requisitos cambiantes son un hecho difícil de la vida; pero la descomposición del código no es causada por eso.

La descomposición del código ocurre cuando hay algunas partes de su código que no ejercita con frecuencia; así que cuando realice algunos cambios que "no deberían afectar a nada más", podría introducir errores. En otras palabras, el código que no ve la luz del día se descompone lentamente y no se puede decir cuándo dejó de funcionar.

Sí, es tu culpa y no de tu usuario.

¿La verdadera solución? prueba todo tu código con frecuencia. Por supuesto, la mejor manera es tener pruebas automatizadas con buena cobertura.

La indecisión del cliente puede ser un gran problema y si usted no es el responsable de administrar la relación con el cliente, puede ser muy difícil tratarlo. Puede hablar con la persona que trata con el cliente y explicarle con calma que el progreso no puede suceder hasta que el cliente tome una decisión. Si está a cargo de la relación con el cliente, debe decirle al cliente que debe tomar una decisión antes de que el proyecto pueda continuar. Es posible que su actitud no necesite una revisión, solo un minuto de meditación para calmarse. ;)

Javier señala que los requisitos cambiantes son un hecho difícil de la vida. Yo también me siento frustrado por estas situaciones ya que con demasiada frecuencia me encuentro trabajando en un producto en el que el desarrollador tiene que tomar decisiones. Mi opinión solía ser "¿Por qué la gerencia no puede resolver esto con el cliente?" O "¿Por qué comenzamos este proyecto si el cliente no sabe lo que quería?", "Es mucho dolor de cabeza cuando cambian tanto tarde en el desarrollo ".

Hecho simple: esto siempre sucederá, no solo en la programación / desarrollo de software sino en todos los ámbitos de la vida. El mundo sería simplemente un lugar muy aburrido y muy diferente si las personas nunca cambiaran de opinión, nunca se adaptaran, nunca abordaran el cambio. Las personas tienden a mirar lo que reciben y a mejorarlo. ¿No haces lo mismo con tu código? Si tengo un bloque de código con el que no estoy satisfecho (es ineficiente, desordenado), lo mejoraré. (¿El sistema operativo se queja de mí? ... a veces, si estoy usando un determinado sistema operativo sin nombre, pero generalmente no)

Como programadores, necesitamos aprovechar las oportunidades para mejorar las cosas, y no deprimirnos ni molestarnos por ellos. Aproveche la oportunidad de hablar con la gente, mejorar su estilo, mejorar su ética de trabajo, abordar las cosas con una mente abierta, esforzarse por ser mejor de lo que era ayer. Avanza en tu carrera y no te conformes fácilmente.

Entiendo que no todos estarán de acuerdo con esta respuesta, pero creo que es importante que las respuestas a esta pregunta cubran una perspectiva más amplia.

Cuando estás interactuando con un cliente, no estás programando; Estás aprendiendo y enseñando.

Mantener informados a los clientes y educarlos sobre el proceso. El cambio va a suceder. Hágales saber que intentará implementarlos, pero le costará más. Déjalos decidir.

No entre en detalles técnicos incluso cuando la pregunta que hacen es de naturaleza técnica. Estás tentado porque te sentirás un poco a la defensiva y querrás enfrentarte a un desafío / ponerte geek. No lo hagas; no les importan los detalles y dejarán de escuchar después de 45 segundos.

Si no les dijiste con anticipación, no esperes que sepan sobre los estándares de la industria y las mejores prácticas o cualquier otra excusa para hacer lo que haces. Odio cuando no veo una tarifa hasta el final solo para que el vendedor me diga que es estándar en la industria. No debería esperar que lo supiera. Mi respuesta es: "¿Me está haciendo sentir como un idiota un estándar también?"

Cuando esté con un cliente, preste más atención que nadie o cualquier otra persona en la sala. Los perros domesticados son genios en esto; especialmente si tienes comida.

Es una mala gestión de requisitos o un mal análisis. Su analista de negocios (si tiene uno) o quien obtenga los requisitos debe sentarse con el cliente e intentar obtener todos los requisitos, incluso aquellos en los que el cliente puede no pensar. Los clientes generalmente no saben todo lo que quieren, un gran analista de negocios los ayudará a resolverlo todo.

Esta es la razón por la que siempre debe obtener una configuración de documento de requisitos comerciales y cerrarla antes de que cualquier aplicación vaya más allá de la fase de creación de prototipos / investigación.

Ahora, la idea de que este documento es realmente final es defectuosa, pero esto debería ayudarlo a tener una mejor idea de lo que el cliente realmente quiere. Y siempre que escriba su código teniendo en cuenta el mantenimiento, puede mantener sus problemas al mínimo.

Y si alguna vez necesita una excusa para recurrir, puede culpar a BRD por cualquier retraso, que el cliente haya firmado, sin incluir tal o cual característica, etc.

(Por supuesto, esto es solo una excusa en caso de que lo necesite. Siempre debe planear que cambien algo )

En la cita de Emerson, "Una consistencia tonta es el duende de las mentes pequeñas ..." la palabra que más a menudo se pasa por alto es tonta . La consistencia no es negociable en ciertos entornos, pero a menudo sustituye al análisis y el pensamiento crítico.

Por un lado, muchos modelos de desarrollo están diseñados específicamente para ayudar en el entorno que está describiendo; así que si te encuentras teniendo que violar tu modelo, entonces, o no lo estás implementando correctamente en primer lugar, o tienes el modelo incorrecto.

Pero, por otro lado, si tiene una justificación justificada y justificada para violar sus reglas, y puede demostrar que su método falso produce un código más limpio y fácil de mantener, entonces no debe tener miedo de tomar la ruta sensata.