El administrador sigue cambiando las especificaciones de requisitos después de cada demostración [cerrado]

Antecedentes de mi entorno laboral

Mi gerente no tiene experiencia ni conocimiento de computadoras o software en absoluto. Es muy probable que no haya visto código en ninguna forma (ni siquiera desde una distancia física de 10 pies o menos) en su vida.

No hay nadie que comprenda la complejidad de lo que se me pide que implemente. Hasta el punto de que si yo semi-hardcode nadie lo sabría.

En la prueba de Joel, obtuvimos una puntuación increíble de 0.

Los problemas

• El gerente y, a veces, otros "superiores" siguen cambiando la especificación de requisitos. Cambios que, si se realiza una buena ingeniería y no "reparaciones" irregulares, requieren un cambio en el diseño subyacente.
• No hay absolutamente nadie que mire el código (probablemente porque nadie sabe cómo hacerlo, o incluso si se debe hacer), lo que significa que nadie podrá:
  • Aprecie la complejidad del problema o la elegancia de la solución.
  • Sugerir mejoras al enfoque.
  • Apreciar la calidad del código.
  • Señale dónde se puede mejorar el código.
• Se utiliza mucha jerga que tiene sentido gramaticalmente pero no tiene ningún sentido de otra manera.
• No se siente, se comporta ni trabaja como una compañía de software.

La pregunta

¿Lo que debe hacerse? Especialmente con respecto a que no haya nadie que señale mejoras en mi código.

Actualizar

Para responder la pregunta de HLGEM (y posiblemente otros) sobre lo que he hecho para intentar solucionarlo. Ofrecí configurar Redmine e introducir el control de origen a todos. Dije que recomendaría distribuido (git o mercurial) pero también hablaré sobre los centralizados y dejaré que el equipo decida. La respuesta fue que las cosas se están haciendo y se harán en unas semanas. No he visto eso ni sé si otras partes de la compañía lo usan.

La versión corta :

Correr.

La versión algo más larga :

Si el gerente no sabe cómo ejecutar un proyecto, y si la persona mayor lo acepta, entonces no tiene casi ninguna posibilidad de arreglar las cosas.

Para administrar proyectos de software, un gerente necesita comprender algo sobre el software. Si los gerentes no lo hacen, primero deben aprender. ¿Cuáles son sus posibilidades de convencer a su gerencia y a su (s) senior (s) de que se equivocaron? ¿Cuáles son las posibilidades de que les enseñes algo?

He estado en una situación similar una vez (solo que no había senior). Renuncié después de un año terrible, y nunca miré hacia atrás (excepto con disgusto).

... siga cambiando la especificación de requisitos. Cambios que, si se realiza una buena ingeniería y no "reparaciones" irregulares, requieren un cambio en el diseño subyacente.

Suena como el mundo real. Esto sucede todo el tiempo, en todas partes. Sí, apesta, pero es soportable con algún tipo de actitud ágil. Además, una medida de la bondad del software es su maleabilidad. Tómalo como un desafío.

Se utiliza mucha jerga que tiene sentido gramaticalmente pero no tiene ningún sentido de otra manera.

De nuevo, no suena tan desconocido ;-)

No hay nadie que comprenda la complejidad de lo que se me pide que implemente.

¿Ni siquiera tú? Si entiendes eso, entonces hay una persona en el espejo que sí entiende eso. Por lo tanto, su responsabilidad sobre el bienestar de su empresa probablemente sea mayor de lo que sugiere su título formal. Si comprende los problemas y su gerente no lo hace, entonces es su responsabilidad dejar las cosas claras a la gerencia para que puedan dirigir adecuadamente la empresa. Puede ser razonable suponer que sus gerentes más cercanos deben ser técnicamente competentes (no necesariamente tan competentes como usted, mientras que ellos son gerentes, usted es el experto, pero al menos un poquito competente), pero si obviamente no lo son y podrías ayudarlos, ¿por qué no?

Una solución escapista simple es cambiar de compañía. Pero como otra opción, considere implementar los elementos de prueba de Joel. Aunque los ítems de 5 en adelante requieren más cooperación con la administración, los ítems 1-4 son tales que podría configurarlos sin preguntar a nadie.

Dicho esto, nadie aquí en SE puede saber su situación exacta. Es posible que estés en una empresa llena de imbéciles incompetentes, y hacer algo bueno de tal desorden podría ser demasiado para cualquiera. Debe evaluar la situación usted mismo.

Dices en uno de los comentarios que este es tu primer trabajo. Los gerentes a menudo no son técnicos en ninguna parte excepto en una tienda de software dedicada en mi experiencia. Esto es parte de la vida, solo acostúmbrate a eso.

Lloras y te quejas porque no hay nadie que aprecie la elegancia de tus soluciones. El verdadero problema aquí no es que no haya nadie para apreciar la elegancia de sus soluciones, sino que no hay nadie que le enseñe que sus soluciones no son tan buenas como cree que son. Prácticamente todos los nuevos programadores sobreestiman sus habilidades reales. Sin mentor, no hay nadie para ayudarlo a mejorar sus prácticas. Si no hay nadie allí para guiarlo, únase a grupos de usuarios locales, participe activamente y busque a alguien para guiarlo. Aún mejor, eso te ayudará a encontrar un mejor trabajo eventualmente.

¿Sacas un cero en la prueba de Joel? Si eres el único codificador (y parece que lo que escribiste que eres), ¿por qué no estás usando el control de fuente? ¿Qué te impide? Si no eres el único codificador, ¿por qué no hay nadie que pueda hacer revisiones de código? Todos nuestros desarrolladores revisan el código, no es una función de administración, especialmente cuando los gerentes no son técnicos.

Los requisitos cambian en casi todos los lugares. Las necesidades comerciales cambian continuamente y los no programadores a menudo no pueden visualizar lo que hará el programa hasta que vean algo. Entonces se dan cuenta de que no es lo que necesitan. Es por eso que Agile surgió realmente porque los métodos más antiguos no manejaban bien ese cambio.

Configure el seguimiento de errores incluso si la administración no desea ingresar los datos ellos mismos. Sea responsable de ingresar nuevas características / errores como alguien le mencione. Realmente ayuda poder decirle al gerente cuando quiere un cambio que le han asignado otras 27 cosas y aquí está la lista, ¿cuál quiere que mueva hacia abajo en la lista de prioridades para acomodar este nuevo cambio? Ayudará en el momento de la revisión porque podrá contar la cantidad de correcciones de errores y características que implementó. Si todo el mundo no lo está usando, entonces al menos puede hacerlo para su propio trabajo. Si no le permiten instalar ningún software, use una hoja de cálculo de Excel. Toma algo de iniciativa. Una vez que pueda mostrar resultados, otros estarán más interesados. Si crees que hay demasiado trabajo para una persona, el rastreador de errores te ayudará a probarlo.

¡No proporcione demostraciones de aspecto pulido! Las demostraciones deben verse como si estuvieran garabateadas con lápiz en una hoja de papel. Cuanto más pulida se ve la interfaz, más piensa la persona no técnica que está terminada.

Aunque nadie lo sabría si no sigue las mejores prácticas y el código semiduro, por ejemplo, lo sabrá y tendrá malos hábitos descuidados. Eso no te servirá bien en tu próximo trabajo. Entonces, haga las cosas lo más cerca posible de la manera que sea posible, dadas las circunstancias. Asegúrese de escribir pruebas (solo considere esto como parte del tiempo de desarrollo y dedique el tiempo para hacerlo en cualquier estimación que administre, incluso si no dice específicamente que es parte de la estimación) y use esas pruebas para asegurarse Los cambios posteriores no rompen otra cosa.

Debe ver esto como una oportunidad invaluable para crecer y mejorar. Tiene más libertad en la codificación real que muchas personas tienen en esa etapa de su carrera. Considere esto una oportunidad para crear una cartera de proyectos implementados exitosamente. Cuando vaya a buscar el próximo trabajo, ser capaz de señalar logros tales como el control de fuente instituido, el seguimiento de errores instituido, el número X creado de implementaciones exitosas de proyectos, etc., lo hará sobresalir del resto.

También tiene una gran oportunidad aquí para aprender a manejar las expectativas al alza. Esta es una pregunta útil para el resto de su carrera. No tiene nada que perder al intentar hacer esto aquí, las cosas ya no están bien. Pero puedes aprender las habilidades políticas que te ayudarán en mejores lugares más adelante. Aprenda a hacer un análisis de costo-beneficio. Aprenda a comprender el dominio comercial para que pueda ser convincente cuando hable con ellos. Aprenda a hablar en términos de beneficios para la empresa y ganancias. Haga estimaciones para cada tarea que se le asigne e incluso si no coinciden con lo que la administración le está dando, mantenga registros de lo que calculó y de lo que realmente se necesitó para mejorar su propia capacidad de estimar el trabajo. Una vez que pueda demostrar que sus estimaciones históricamente han sido más precisas que las de gestión, serán más propensos a escuchar cuando les diga que la estimación es demasiado baja. Pero primero debe crear un historial de las estimaciones más precisas y, lo que es más importante, la capacidad de entregar los proyectos y hacer que funcionen. Nuevamente, esta es una buena habilidad para tener a medida que avanzas en tu carrera.

Sobre todo, no seas pasivo y espera que la mejora venga de arriba.

Si yo fuera tú, trataría de encontrar otro trabajo. ¿Por qué? Creo que sabe que, desafortunadamente, su gerente es, bueno, "no es bueno". Sin embargo, debe intentar resolver algunas cosas con su gerente.

Si no quiere irse, y / o no va a hablar con nadie, entonces tendrá que encontrar algo usted mismo. Si nadie en la empresa conoce su código, ¿cómo se supone que su gerente debe saber que cumple con los requisitos? Solo digo.

Hable con su gerente y con las personas mayores sobre esto. Explica tus problemas y sugiere soluciones. Prepare la charla un poco para conocer el mensaje general que desea transmitir.

Después de la charla, dale un poco de tiempo . A ver si las cosas cambian o no. Si no lo hacen, intente implementar los cambios usted mismo y muéstrele al gerente y a las personas mayores los resultados positivos de sus cambios .

Si la charla no ayuda y se descartan sus cambios, debe evaluar por sí mismo cuánto le gusta trabajar en ese lugar. Sí, el trabajo puede ser malo, pero ¿tal vez la paga es buena y solo tienes un viaje de 5 minutos? ¿Los aspectos positivos de su trabajo superan a los negativos? Si no lo hacen, comenzaría a buscar un nuevo trabajo.

Su problema es que los sistemas de venta de entradas y el control de versiones son cuestiones TÉCNICAS y debe hacerlo independientemente de la entrada de un gerente no técnico. Esto debería suponerse como una práctica recomendada técnicamente y si no tienen esta configuración, entonces debe asumir la responsabilidad de que esto suceda.

No puede esperar que un gerente no técnico comprenda los beneficios del seguimiento de defectos, el control de origen y la integración continua. Es por eso que no son técnicos, se supone que no deben saber ni preocuparse por eso, son expertos en dominio y conocimiento del negocio. Lo único que deberían proporcionar es una dirección y requisitos de alto nivel.

También tengo un gerente no técnico y pude aumentar el puntaje de Joel Test de 4 a 8 solo porque fui y los hice y no pedí permiso.

Su grupo necesita un líder técnico fuerte y nadie ha dado un paso al frente.

Visite http://community.rallydev.com/ tienen una edición comunitaria que hace un excelente trabajo de gestión de proyectos ágiles y seguimiento de defectos. Eso solo aumentará su puntaje de Joel y no le costará NINGÚN espacio o tiempo de servidor para configurarlo.

Si esta es una pequeña tienda donde usted y el otro "senior" son básicamente las únicas personas que codifican, entonces en realidad podría ser su responsabilidad indicarle al gerente qué debe hacerse para satisfacer la "Prueba de Joel".

Los cambios en los requisitos siempre estarán ahí, y su trabajo es aceptarlos, que es uno de los principios básicos del desarrollo ágil :

Bienvenido a los requisitos cambiantes, incluso al final del desarrollo Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.

Pero adaptarse a los requisitos cambiantes significa seguir otros principios ágiles también. A nivel de gestión, esto significa que el gerente debe poder presentar de manera transparente al cliente que todos esos cambios tienen un costo: o el alcance del proyecto debe cambiarse para cumplir con los plazos, o los plazos deben cambiarse (no se recomienda este último).

Si se trata de una especie de proyecto en el que su gerente es el que presenta todos los requisitos, entonces debe actuar como si fuera su cliente ágil y explicarles lo mismo (alcance <--> compromisos de la fecha límite )

Pero a nivel de desarrollador en una pequeña empresa, diría que es su responsabilidad asegurarse de que la parte de codificación se ajuste a las recomendaciones ágiles.

Estos son algunos pasos que absolutamente necesita hacer, y probablemente tendrá que hacer usted mismo:

• que debe tener un sistema de control de versiones (se tarda un día para configurarlo para un equipo pequeño)
• usted debe tener scripts de construcción para asegurarse de que usted puede hacer comunicados de frecuencia (bastante rápido para establecer también)
• usted debe utilizar las pruebas unitarias automatizadas (esta es una forma de codificar, y dicta su diseño entero radicalmente, por lo que podría ser difícil de añadirlos en el medio de un proyecto fuertemente acoplado)
• También puede configurar un sistema de integración continua para garantizar compilaciones y pruebas automatizadas, así como pruebas funcionales y de GUI (que son un poco más difíciles de escribir)

Recuerde que puede tener un repositorio SVN localmente en su propia máquina. Una simple lista TODO podría servir como un sistema de seguimiento de errores de los pobres (un poco extremo, pero bueno). Y no hay excusa para no tener scripts de compilación.

Además, antes de hacer declaraciones sobre compromisos de alcance / fecha límite, alguien también necesita hacer predicciones sobre cuánto tiempo tomará cierta característica. Esto generalmente se hace en "días ideales" en un mundo ágil, lo que significa que debe hacer todo lo posible para predecir el esfuerzo relativo de cada función, y luego usar su velocidad de codificación real para ver qué tan bien pronosticó (y escalar la "curva" en consecuencia )

Creo que faltan niveles de responsabilidad en su equipo. Debe haber un gerente de proyecto, analista de sistemas, analista de negocios y desarrolladores. El rol de Gerente de Proyecto es responsable de definir y hacer cumplir la estrategia de comunicación cliente-proyecto (entre otras tareas).

Los gerentes no están obligados a comprender el código o las complejidades. La necesidad de entender, recursos, costo y riesgo.

Las versiones del código fuente, la calidad del código, la complejidad, etc. son responsabilidad del PM o del desarrollador principal.

La solución es:

1-Definir la estructura del equipo del proyecto y sus responsabilidades.

2-Educar al gerente en casos de fallas de software causadas por una mala administración - Manténgase alejado de los detalles técnicos. Puedes encontrar algunos ejemplos buscando en Google.

Especialmente con respecto a que no haya nadie que señale mejoras en mi código.

¿No podría intentar configurar revisiones de código para que haya personas mirando el código? ¿Existen convenciones y estándares que ayudarían a darle al código alguna estructura? Esto supone que no eres el único desarrollador allí, por supuesto.

Si bien es probable que esté en un lugar menos que excelente, ¿parece que al final está funcionando? ¿Se están realizando proyectos y las cosas avanzan? ¿Se están haciendo las cosas? El programador de cinta adhesiva sería el artículo de Joel que es posible que desee leer.

Opción 1: dígales "con todos los cambios que está realizando en este proyecto, para cuando lo implementemos, el sistema se ejecutará muy lentamente" o "el cliente no podrá resolverlo". Sus gerentes no se preocupan por el código de espagueti, pero sí se preocupan por el cliente. Explíqueles el problema en términos de lo que comprenden, no en términos de escritura de código.

Opción 2: darles lo que quieren. Cuando se quejan de algo, dices "pero eso es lo que pediste"