El proyecto para el que me contrataron está descarrilado debido a los requisitos en constante cambio, ahora estoy yo en el lugar

DOCUMENTAR TODO

Cada vez que haya un cambio de alcance, haga lo siguiente:

• Documente el cambio.
• Muestra los efectos que esto tendrá en tu trabajo
• Enviar una nueva línea de tiempo
• Haga que las partes interesadas firmen

El alcance del alcance ocurre, pero la única forma de evitar ser el culpable es documentar todo, demostrar el efecto, hacer que las personas firmen para que tenga un rastro en papel.

Mea culpa

Creo que la respuesta de @ Neo está en el camino correcto, pero no estoy de acuerdo con la implementación. Considerar

Desde que estoy aquí, he cometido algunos errores. Uno de los primeros grandes fue que cuando me dijo que desarrollara un arnés de prueba para la aplicación, no insistí en que analizáramos ese cambio. En ese momento, simplemente acepté que un arnés de prueba era algo bueno y seguí adelante con eso. Eso tomó dos meses y medio. Mantenerlo también ha costado X meses.

Sin darme cuenta de ese error, cuando me dijiste que cambiara de "edición en vivo" a un panel administrativo completo, lo repetí. No insistí en evaluar el cambio. Pasamos otro mes haciendo ese cambio.

No puedo seguir cometiendo el mismo error. A partir de ahora, espere actualizaciones de la línea de tiempo cada vez que se proponga un cambio. Aquí está la situación tal como están las cosas hoy...

Luego, explique cuánto tiempo llevará terminar su conjunto actual de tareas según los requisitos actuales. Si están proponiendo nuevos cambios, explique cómo cambiarán esa línea de tiempo. También explique qué sucede si no hace esos cambios ahora y los hace más tarde. Incluso puede hacer eso con los cambios que han solicitado pero que no ha implementado.

Sigo con lo que dijiste aquí, por lo que es posible que me falten partes de la línea de tiempo. Si es así, asegúrese de escribir esas partes para ellos (realmente no necesitamos verlas a menos que necesite ayuda para hablar sobre ellas).

La ventaja de este enfoque es que involucra que usted asuma la culpa. Es de suponer que están de acuerdo en que has cometido errores, por lo que estás empezando por estar de acuerdo. Y no te señala con el dedo excepto a ti. Resalta los problemas y eventualmente pasa a las soluciones.

No olvide incluir el mantenimiento continuo del arnés de prueba en eso. Si eso está ocupando la mitad de tu tiempo, entonces díselo. Pueden cambiar el trabajo de usted (ya sea en la parte delantera o en el arnés de prueba) o pueden vivir con una línea de tiempo más larga.

Si no les cuentas la realidad de la situación, seguirás teniendo el mismo problema.

Avanzando

Cuando leo esto, lo que realmente me llama la atención es el arnés de prueba. Son dos meses y medio de un alcance de seis meses, incluso antes del mantenimiento. Por eso dije X. No sé qué es X, pero parece que era importante. Si pasó incluso medio mes en ello desde entonces, se convirtió en la mayor parte de sus primeros seis meses y posiblemente la mayor parte de su tiempo allí si fue más. Realmente necesitas cuantificar eso.

Calcule cuánto tiempo tomaría hacer el proyecto original desde aquí. Tal vez con algunas campanas y silbatos adicionales que ya ha agregado. No es necesario que saques las cosas. Pero si no agregara nada más que no estuviera en los requisitos originales, ¿cuál sería su cronograma? Luego muéstreles cómo cualquier requisito nuevo afecta ese cronograma. Luego muéstreles cómo sus sugerencias actuales impactarían el cronograma. Nunca necesita decir que no, pero dígales cuánto tiempo están agregando.

Pueden tener Agile o Waterfall. No se pueden mezclar y combinar. Agile acepta requisitos cambiantes porque el sistema siempre funciona en algún nivel. Entonces, todos los requisitos están en el sprint actual o no existen. Waterfall intenta programar todo el proyecto a la vez. Eso significa que cada vez que cambian los requisitos de tiempo, debe cambiar todo el programa. En teoría, el gerente del proyecto debe manejar eso, pero en la práctica, si eso no sucede, entonces es parte de su responsabilidad como contratista. Necesitas manejar tu horario.

Considere también la posibilidad de que parte del trabajo que está planeando hacer actualmente en el front-end se pueda hacer en el back-end en su lugar. Si es así, debe cuantificar cuánto de su tiempo le tomaría. Deje que el desarrollador de back-end cuantifique cuánto tiempo le llevaría codificar en el back-end. Deje que el gerente elija dónde sería mejor hacerlo. Incluso si lleva más tiempo en el back-end, aún puede tener sentido hacerlo allí si está más atrasado y el desarrollador del back-end lo está esperando actualmente.

Es posible que el desarrollador de back-end se haga cargo del arnés de prueba. Si solo hay dos desarrolladores y le está quitando demasiado tiempo, no hay muchas otras opciones. Y estaría mucho mejor si pudiera concentrarse en su proyecto original. Si el desarrollador de back-end lo ha estado esperando, entonces esto le da trabajo mientras tanto.

¿Hay alguna manera de que pueda revertir esta situación?

Creo que estás en un pequeño problema aquí, ya que no me parece que hayas manejado sus expectativas .

Lo mejor que puede hacer tan tarde en el juego es documentar todo el escenario , incluida la línea de tiempo , tal como lo ha hecho con nosotros. A veces, los clientes tienen poca memoria y solo recuerdan el pasado inmediato (ahora) o a corto plazo. Dudo que recuerden lo que te pidieron que hicieras hace varios meses.

Recordarles

Asegúrese de que cuando detalle el trabajo, tenga en cuenta todas y cada una de las decisiones que le obligaron a modificar drásticamente la arquitectura.

Más allá de eso, no estoy seguro de qué más se puede hacer.

por tu futuro

Asegúrese de documentar todo lo que hace y, si tiene una solicitud de cambio (cambio en la declaración de trabajo original), asegúrese de documentar el cambio y el impacto en la línea de tiempo .

pero no digo nada

¿No es eso una gran parte del trabajo de cualquier desarrollador, especialmente los autónomos?

Sus gerentes no son desarrolladores, no pueden diferenciar los cambios de requisitos pesados ​​de los más ligeros, ni las direcciones buenas (desde el punto de vista del desarrollador) de las direcciones malas (todavía pueden tener buenas razones de marketing para probar esas direcciones, por ejemplo).

Cada vez que discuta cosas nuevas para hacer, debe decirles cuánto tiempo llevará (o cuán impredecible es este tiempo), incluso si no preguntan .

Tienes que controlar los daños porque, en mi opinión, mucho de esto es culpa tuya.

Debería haber gestionado los cambios más rápido o haberse asegurado de que quedara claro que los 6 meses ya no se aplicarían si querían que se hiciera algo más. En su lugar, simplemente recaudó dinero mientras observaba cómo los plazos se desvanecían.

¿Hay alguna manera de que pueda revertir esta situación?

Opción 1: Haz el trabajo y deja de perder el tiempo.

Opción 2: Infórmeles sobre los plazos basados ​​en la realidad, las razones por las que no se cumplirá el original y siga adelante a partir de ahí. Las personas inteligentes entenderán, puede que no estén contentas o impresionadas, pero entenderán.

Como freelancer, tu reputación es tu mayor activo, necesitas ser mejor, más organizado, más rápido y más profesional de lo normal para construir una reputación, a veces esto significa trabajar unas horas extra gratis en situaciones de presión.

Para decirlo sin rodeos, si esto es su culpa, terminará recibiendo un golpe en su reputación o en su billetera.

Como profesional, generalmente se espera que pueda proporcionar estimaciones razonables de cuánto tiempo tomará el trabajo y que notifique a su empleador de inmediato si el cronograma deja de ser realista.

No digo que tú seas el único culpable, pero si hay algo que realmente deberías haberles dicho hace 4 meses, entonces cometiste un error que les está costando . Y cuanto más tiempo permaneces en silencio, peor se vuelve la situación.

Dicho esto, tengo entendido que ya hay un desarrollador Frontend y Backend en el equipo que también debería tener una idea razonable del impacto de los cambios de alcance. Entonces parece que todos están entrando en pánico y apretando a los demás, o tal vez simplemente confían más entre ellos que en ti, por lo que te están apretando.

Una cosa para recordar es que muchas veces, cuando todos están estresados, las personas se desincronizan por completo y malinterpretan por completo lo que hacen los demás. Por ejemplo, tal vez lo que usted ve como "manos a la obra" es que ellos quieren superar los obstáculos rápidamente, y lo que usted ve como "disminuir la comunicación" es en realidad que todos tienen prisa. De la misma manera, pueden estar tomando las cosas que haces de manera incorrecta. La solución a estos problemas es la COMUNICACIÓN.

Que haría yo

Esto se basa en una serie de suposiciones que estoy haciendo sobre la situación, así que ajuste según sea necesario.

Primero, propondría rápidamente un cronograma realista para el proyecto en papel y calcularía el tiempo máximo que puede trabajar y el dinero mínimo que aceptaría si la alternativa es perder el trabajo y una crítica muy mala. Necesita este tipo de cifras en su cabeza porque las cosas pueden estallar rápidamente en un proceso de negociación. Y averigüe si están más preocupados por el presupuesto o por el cronograma, si puede.

Luego entre y diga "Chicos, este proyecto obviamente está estresando a todos. ¿Podemos dar un paso atrás y tener una discusión tranquila al respecto? Quiero entender y tal vez contribuir a cómo vamos a abordarlo desde aquí".

Si se niegan, entonces diles que aunque seguirás dando tu mejor esfuerzo, no puedes cumplir con las expectativas que tienen de ti en este momento porque hay demasiado trabajo y poco tiempo.

De lo contrario, puede tener una discusión con ellos sobre el proyecto. No seas conflictivo. Haga hincapié en que comprende que existen presiones comerciales complejas y que las decisiones finales dependen de ellos, pero presente lo que cree que es el mejor curso de acción desde su punto de vista. Si le lanzan una bola curva (por ejemplo, una función de la que no está seguro de cuánto tiempo se necesitaría), dígales que tendrá que investigarla antes de poder confirmar que es realista.

Lo más importante es presentar soluciones , no problemas. En lugar de "No me dijeron nada sobre bla", di "¿Podrías informarme sobre bla en el futuro?"

Usted escribió: "No especificamos. Es un contrato ad-hoc y solo tuvimos una reunión antes de comenzar".

Esta es su causa raíz. Hay suficiente trabajo por ahí que cualquier éxito de este proyecto le causará solo pequeños problemas, en mi opinión. Además, muchas empresas también entienden cómo sucedió esto y no lo culpan.

Recuerde, si bien ellos tienen influencia sobre su reputación, usted tiene influencia en el sentido de que han gastado una gran cantidad de dinero y tiempo en esto y gastarían más en otra persona. Has aprendido tu lección también en la planificación. El 80% de un proyecto debe estar en planificación y el 20% en implementación.

Ha aprendido la lección sobre el uso de un buen contrato en el trabajo por contrato y, siempre que cumpla con sus obligaciones contractuales, no debería preocuparse por su reputación. De hecho, siempre que cumpla con sus requisitos, corren peligro si le dan calificaciones bajas o una revisión.

En resumen, ¡cree un buen contrato y haga verdaderas reuniones de planificación! Puede recuperarse de esto, pero ahora debe hacerlo de la manera correcta, que es protegerse a sí mismo y a su cliente mediante el uso de un contrato y un plan real paso a paso, paso a paso, que cubra todo, desde el idea general a la ubicación exacta de los elementos de la ventana.

Aún así, en mi experiencia, consideraría esto como una buena lección aprendida y buscaría un nuevo comienzo en otro lugar, tomando mis bultos con calma.

Me gustaría ampliar un poco la respuesta de Brythan. Uno de los puntos planteados, pero pasado por alto, fue el uso de Waterfall o Agile. Por su descripción, dudo seriamente que estén usando Agile, y por la descripción de su empresa, probablemente ni siquiera sepan qué es. Voy a escribir mi respuesta suponiendo que quien la lea no esté familiarizado con Agile (o Waterfall). Como mínimo, podría ser útil para explicarle a la empresa lo que quiere hacer, ya que Agile puede ser complejo, especialmente si están acostumbrados a Waterfall. Si no está familiarizado con este término, Waterfall es el viejo "planee todo desde el principio, déle un marco de tiempo a todo y rece para que nada salga mal y que haya acertado con su estimación de cuánto tiempo". tomará"

En el ejemplo de qué decir en la respuesta de Brythan, cambiaría el párrafo final a algo como esto:

En un esfuerzo por evitar esta situación en el futuro y traer más transparencia al proyecto, me gustaría proponer lo siguiente:

Primero, cada dos semanas, tendríamos una reunión para decidir qué se debe hacer en las próximas dos semanas. Proporcionaré una lista de tareas que aún deben realizarse, y podemos decidir juntos cuál es la prioridad y qué puedo lograr razonablemente en esas dos semanas. Al final de las dos semanas, tendríamos otra reunión para demostrar lo que se ha completado para que pueda aprobarlo.

Por lo general, el proceso de dividir un proyecto en "tareas" (o Historias de usuario, como las llama Agile) lo realizarían usted y el administrador del proyecto, pero es posible que deba manejarlo usted mismo. Divídalos en partes que se puedan completar en dos semanas o menos. Y al final de esas dos semanas, cada tarea debe ser algo que pueda demostrar a la empresa como un componente completamente funcional. A veces, lo que crea no es algo que realmente pueda entregar de forma independiente, pero aun así, intente encontrar alguna forma de mostrar la funcionalidad. La idea es que vean avances.

Además, me gustaría tener una reunión diaria, de no más de 15 minutos, para discutir el progreso diario. De esta manera, siempre puede saber exactamente cuál es el estado del proyecto y, si surge algún problema, puede abordarse de inmediato.

Esta es una implementación muy básica de Agile, pero es una gran mejora con respecto a Waterfall y brinda a los propietarios del proyecto comentarios inmediatos y continuos sobre dónde está el proyecto.