Proyecto de desarrollo fallido, ¿cómo restaurar/guardar mi reputación?

He estado trabajando para una pequeña empresa de consultoría, contratado por otra empresa, haciendo proyectos "calificados pero no realmente" durante dos años. Mi objetivo es entrar en el desarrollo, pero mi formación académica es inestable, con una licenciatura técnica, pero no en informática, que terminé tarde.

Hace aproximadamente seis meses, un colega y yo fuimos asignados a un proyecto de desarrollo de JS/Node para un pequeño cliente en un país diferente, haciendo cosas cercanas al hardware. Para él (el colega), se suponía que esto era un trabajo remunerado. Para mí, se suponía que esto era una formación (no remunerada, no programada, remota, además de mi trabajo ya de tiempo completo), con una responsabilidad mínima (o al menos así lo entendí).

Todo se derrumbó horriblemente. No hubo reuniones que condujeran a ninguna parte, el único tipo en las instalaciones que había estado trabajando en el código básicamente estaba afuera, no había un propietario o líder del proyecto, ni especificaciones, ni tickets, excepto los que escribí, sin control de calidad, sin nada. . No tenía acceso al hardware, así que no podía experimentar cómo funcionaba la cosa.

Terminé trabajando en esto solo, en forma aislada. Más tarde descubrí que mi colega (que se supone que es un desarrollador experimentado) simplemente le dijo a nuestro jefe (que estaba negociando con el cliente) que el proyecto era demasiado difícil y lo abandonó. También descubrí que el cliente no estaba pagando por el trabajo que hizo mi colega. Terminé tratando de ayudar como pude, pero nada funcionaba. Ni siquiera pude ejecutar el código (ya que no tengo el hardware).

Después de unos cuatro meses de intentarlo y fallar al estilo solista, programé una reunión con mi jefe y le dije (casi entre lágrimas) que abandonaría este proyecto. Primero me dijo que hasta donde él sabía, el proyecto estaba congelado desde hacía tiempo (una novedad para mí). Luego me regañó y me dijo que los desarrolladores necesitan iniciativa.

Todo este lío me ha dejado una especie de cicatriz. Meses después, todavía estoy tratando de averiguar qué pasó. Ni siquiera puedo entender si todo es mi culpa o no.

Desde entonces, cualquier conversación sobre otros proyectos de desarrollo se ha calmado. Pero sigo aspirando a convertirme en desarrollador.

Tengo un par de preguntas sobre esto:

  1. ¿Algo de esto es normal? Me han dicho que siempre es así, pero me cuesta creerlo.
  2. Hasta ahora, esta es mi única experiencia "real" con trabajo de desarrollo fuera de la escuela y proyectos personales. Siento que no puedo presentar esta experiencia como una experiencia laboral. ¿Es salvable mi carrera? ¿Puedo arreglar las cosas con este empleador (la consultora, no el cliente)? ¿Cómo debo presentar esto a otros empleadores? ¿O no presentarlo en absoluto? ¿Cómo controlo los daños en este tipo de cosas?
Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .

Respuestas (8)

1: ¿Algo de esto es normal?

Sí, hay una TONELADA de gerentes totalmente incompetentes. ¿Por qué gerente incompetente? Porque no puedes tener tu pastel y comértelo y un gerente debe manejarlo.

Primero me dijo que hasta donde él sabía, el proyecto estaba congelado desde hacía tiempo (una novedad para mí). Luego me regañó y me dijo que los desarrolladores necesitan iniciativa.

Entonces, ¿intentar y fallar es no mostrar iniciativa? Pero él, siendo la persona que coordina, o no te dice como desarrollador que el proyecto se ha congelado O ni siquiera se da cuenta de que estás trabajando en él, ¿no es una señal de incompetencia absoluta y total? Vaya, qué gerente. O qué montaje, donde los recursos funcionan durante un tiempo sin ser contabilizados y las personas que gestionan los recursos no lo saben. ESO es lo que yo llamo incompetencia. Supera todo lo que he visto en 30 años.

Hago software durante unos 30 años, con interrupciones. He estado en posiciones de liderazgo con bastante frecuencia y lo estoy. Por un lado, no puedo imaginarme no trabajar con un junior regularmente para obtener informes de estado (al menos mensualmente), y no puedo imaginarme tener recursos trabajando en un proyecto congelado. Eso cuesta dinero, cuesta dinero, y eso es una señal de que alguien no tiene el control de su gente, EN ABSOLUTO. Es una pena que un gerente no debería hablar de iniciativa.

¿Es salvable mi carrera?

No ha sido dañado. Sin embargo, buscaría otro trabajo, porque lo que me dijiste es que el próximo gerente es un imbécil.

¿Puedo arreglar las cosas con este empleador (la consultora, no el cliente)?

Bueno, básicamente presentaría una queja sobre eso, porque lo último que alguien empieza a hacer mejor es culparme por ser un idiota. Y nuevamente, tengo serios problemas con un gerente que no le dice a un recurso que el proyecto está congelado. ¿QUIERES salvar eso? Empieza a buscar otro trabajo.

¿Cómo debo presentar esto a otros empleadores?

Positivo. Eres un desarrollador junior. No hace falta hablar de los fracasos. Listar experiencia laboral. No puede entrar en detalles DE TODOS MODOS debido a NDA. Di de qué se trataba el proyecto, qué se intentó, qué tecnologías. Cualquier pregunta sobre el éxito que usted redirige (los proyectos se enlatan TODO EL TIEMPO) o dice que no puede revelar los detalles del cliente.

¿Cómo controlo los daños en este tipo de cosas?

Como se dijo anteriormente. No hay daño real para un desarrollador junior aquí.

Buena respuesta. Sugiero agregar una nota que explique que en realidad fue una buena experiencia a largo plazo. (a) Ver cómo no ejecutar un proyecto y una empresa puede ser más instructivo que ver una operación sin problemas. (b) Esta experiencia muestra cómo la mayoría de los proyectos de desarrollo de software fallan debido a problemas de gestión más que a problemas técnicos.
No es parte de la respuesta, pero sí, totalmente. Mira, en el momento en que cambias de Junior a un rango superior, mucho tiene que ver con la experiencia del mundo real, y debes experimentar esto seriamente (es por eso que la cantidad de proyectos realizados y el tiempo en la profesión cuentan para convertir a alguien en senior) para saber cuán ridículamente estúpido pueden ser algunas organizaciones y cuánto pueden descarrilarse las cosas. Esto definitivamente puso algo de experiencia en la categoría "bien, algunas organizaciones están dirigidas por monos que pretenden ser inteligentes". Como dije, supera todo lo que he visto en 30 años.
Sin embargo, puedo ver las cosas desde el punto de vista del gerente. Su crítica parecería mucho más válida si el usuario 123557 fuera un recurso como un miembro del personal pagado. Aparentemente, él era solo un freebee, por lo que la gerencia puede haberlo visto esencialmente como un no recurso, y la tarea principal de la gerencia era evitar que causaran problemas, manejados asignando el freebee a un miembro inferior del personal. Luego, ese miembro del personal resultó no ser bueno (renunció porque era "demasiado difícil"), por lo que ahora la necesidad de supervisar al freebee que casi lloraba pasó de ser manejado a un problema que necesitaba atención.
Dudo que no le pagaran; si le pagan, no es un obsequio para la empresa. No lo tomé como un obsequio: "He estado trabajando para una pequeña empresa de consultoría, contratado por otra empresa". Suena que le ofrecieron gratis, pero aún así pagó. Eso significa perder dinero cada hora: bueno como parte de un paquete, MUY malo como un recurso que trabaja en un proyecto congelado.
Buena respuesta, y captura una buena parte de los problemas sistémicos que pueden ocurrir en una organización de desarrollo SW. OP debería tenerlos en cuenta para su futura carrera; Otro síntoma que surge a menudo debido a esto es la creencia de que el problema/proyecto se solucionará simplemente contratando a un desarrollador "experimentado/senior/rockstar/brillante/(etc.)", que también puede ser una falacia, y que a menudo ver en artículos, comentarios de blogs e incluso anuncios de trabajo.
@ fr13d O contratar a más personas en general. Oh, nos estamos quedando atrás, dupliquemos el número de empleados, seguido de "¿por qué está bajando nuestra velocidad? Tenemos tantas personas nuevas" (que no tienen idea del proyecto y lograr que se incorporen es una gran carga para los desarrolladores existentes) , de ahí la caída de la velocidad). Es un mundo loco a veces.
Sí, @TomTom, los gerentes ya no leen a Fred Brooks , por lo que están condenados a repetir la historia...
Si bien estoy de acuerdo en que el gerente no se ha desempeñado bien aquí, hay una lección importante que aprender aquí para el OP: 4 meses sin consultar con su gerencia es demasiado tiempo. Hacemos esto todos los días (5 minutos) y es invaluable.
Bueno, todos los días puede ser demasiado, depende de quién sea el gerente. si se ejecuta en un equipo de desarrollo, eso es parte de scrum, pero si el gerente está asignando personas a los clientes, al menos una llamada mensual debería ser normal. Ese es el escenario tal como lo entiendo aquí.

No hiciste nada malo aparte de no hablar antes con tu gerente sobre los problemas que enfrentabas. No has arruinado nada de tu carrera.

No es necesario que controle los daños, el proyecto simplemente salió mal. Estas cosas suceden y es un fracaso de la gestión más que tuyo. Acabas de salir de la universidad, ¿cómo puedes ser responsable de algo?

Esta respuesta menciona lo único que podría mejorar usted mismo: dar una actualización de estado. No es realmente la responsabilidad de dar uno, se debe pedir. Pero cuando no te lo pidan, dale uno :)
Probablemente arruinó un poco sus posibilidades con este empleador. PERO ese es un empleador del que querrías alejarte de todos modos
@Martijn Algo en desacuerdo con la parte "debe solicitarse la actualización de estado" de su comentario. Esperaría que haya un proceso simple de una reunión/reunión diaria (como máximo semanal) en la que se actualice el estado de las cosas realizadas desde la reunión anterior, actualmente en curso y planificadas hasta la próxima reunión, es una locura asumir todas las necesidades. que siempre se le pregunte, debe ser simplemente un "proceso normal". Pero como dice la respuesta: esta es una buena lección para que el OP aprenda de cualquier manera.
@rkeet Es una muy buena habilidad para aprender. Mantenga a las personas relevantes actualizadas, haga preguntas a mitad de camino para que no escuche todos los problemas al final. No es porque 'ellos' lo requieran, es porque puedes hacer mejor tu trabajo, cambiar de dirección más rápido.
Las actualizaciones de estado de @Martijn son útiles, pero diría que no son obligatorias hasta el punto de asegurarse de que sucedan si su gerente no las solicita. Si todo va bien, generalmente no hay necesidad de asomar la cabeza y decirlo. Pero tan pronto como se encuentre con un obstáculo o suceda algo que afecte su capacidad de entregar a tiempo, AHÍ es cuando necesita hablar y arreglar las cosas para que pueda volver a la normalidad.
@aleppke No es que esto le haya sucedido a OP, pero probablemente también desee brindar una actualización de estado cuando se haya logrado un progreso visible. Esto se debe en parte a que a los gerentes les gusta el progreso y les gusta informar sobre el progreso a sus gerentes, clientes, accionistas, directorio, etc. se quería no son exactamente lo mismo.

Terminé tratando de ayudar como pude, pero nada funcionaba. Ni siquiera pude ejecutar el código.

Básicamente desperdiciaste cuatro meses de tu tiempo porque no te pagaban. Solo deberías haber estado trabajando en las tareas que se te asignaron, sin tratar de hacer nada por ti mismo.

Habiendo dicho eso, la información provista por su gerente también tiene parte de culpa, por no saber lo que estaba sucediendo.

Simplemente avance a partir de esto y aprenda las lecciones que pueda sacar de ello.

Luego me regañó y me dijo que los desarrolladores necesitan iniciativa.

Para alguien que no te pagó, seguro que tiene algunos nervios.

Si está dispuesto a trabajar de forma gratuita sin ningún mentor cercano o sin supervisión cercana, como estaba dispuesto a hacer en este caso, trabaje en su propio proyecto.

Con su propio proyecto, puede controlar el alcance del mismo. Con su propio proyecto, puede publicarlo en github. Y es mucho más fácil tener iniciativa en algo que realmente te pertenece a ti mismo.

Estoy bastante seguro de que "no pagado" en este contexto significa que el cliente no estaba pagando por el personal de OP, no que OP estuviera trabajando literalmente sin dinero (es decir, el cliente pagó por un ingeniero, obtuvo uno + OP). Pero acepte que, si OP realmente estaba trabajando sin dinero, entonces deberían dejar de hacerlo de inmediato. OTOH, las empresas de consultoría son extrañas y es posible encontrar una forma sensata de hacer que esto funcione (por ejemplo, si hay un salario base alto y algunos trabajos pagan extra además de eso).
@Kevin, no lo sé. Por lo que dice, no parece que esté trabajando en otra cosa. Entonces, si no está trabajando en nada más, ¿por qué le pagarían? Me parece que está haciendo algún tipo de pasantía (una muy mal estructurada).
@Stephan Branczyk desde la perspectiva de una empresa de consultoría europea, hacemos cosas así con regularidad, lo que significa que podemos agregar algunas tecnologías al CV de un desarrollador junior que nos permite cobrar al próximo cliente la tarifa de un desarrollador con experiencia. Entonces, básicamente, la empresa invierte en sus recursos tomando un pequeño costo ahora para obtener mayores ganancias en un par de meses.
@kevin No veo cómo un tipo con básicamente cero experiencia podría pasar 4 meses sin contacto con la gerencia y aún así recibir el pago. Incluso una persona mayor tendría al menos 1 reunión por trimestre comercial (mucho más si se trata de un sistema ágil). Espero que el tipo sea despedido dentro de 1 mes. Tal vez 2-3 si ese fue un período de prueba y la gerencia fue demasiado tonta para despedirlo antes. No digo que sea culpa de OP que dejó caer la pelota. Todo esto depende de la administración aquí.
@StephanBranczyk: En realidad, es bastante común que las empresas de consultoría paguen a las personas que están "en el banquillo" (no asignadas a ningún proyecto) durante al menos un período corto de tiempo, porque es más económico que despedir y volver a contratar personas constantemente cada vez que se firma el contrato. La desventaja es que tienes mucho menos control sobre tu carrera y es posible que te pidan que trabajes en tecnologías que nadie más quiere tocar.
@Kevin, tu explicación realmente tiene sentido. Si el OP aún no ha respondido en unos días, eliminaré mi respuesta. ¡Gracias!
De acuerdo con Lijat y Kevin. En Europa no se puede simplemente despedir a los jóvenes si hay una desaceleración temporal. Asignarlos a un contrato externo sin facturar al cliente es una idea razonable. El cliente no puede quejarse de la tarifa por hora, y se entiende que el junior puede ser reasignado en cualquier momento cuando un proyecto pagado esté disponible.

He estado trabajando para una pequeña empresa de consultoría, contratado por otra empresa, haciendo proyectos "calificados pero no realmente" durante dos años.

Hace aproximadamente seis meses, un colega y yo fuimos asignados a un proyecto de desarrollo de JS/Node para un pequeño cliente en un país diferente, haciendo cosas cercanas al hardware.

Buenas noticias: no todo ha sido una cancelación. Dependiendo de cómo lo exprese, ahora tiene de 6 a 24 meses de experiencia como desarrollador profesional, lo que ayudará a que su currículum se destaque de otros que solicitan trabajos de desarrollador junior.

No sea negativo acerca de sus terribles (pronto ex) colegas en sus entrevistas: concéntrese en lo que ha aprendido y cómo preferiría hacer las cosas en el futuro, con el beneficio de su experiencia actual.

Siento que no puedo presentar esta experiencia como experiencia laboral

Por supuesto que puede. es experiencia _ Alguien que ha recibido algunos golpes y sigue adelante vale mucho más que alguien que nunca ha enfrentado un solo desafío.

En primer lugar, las buenas noticias: tus futuros empleadores solo saben las cosas que les cuentas sobre tu trabajo anterior. Nadie lleva la cuenta. Por eso se pone tanto peso en las entrevistas.

En segundo lugar, los proyectos de software fallan todo el tiempo , a menudo por razones estúpidas. es endémica No suele ser una mancha en ninguna carrera individual. Pero puede ser traumático, y lamento que te haya sucedido aquí.

Terminé trabajando en esto solo, en forma aislada.

Intentaste llevar el peso del mundo sobre tus hombros, y fue demasiado.

me dijo que los desarrolladores necesitan iniciativa.

Lo que quiso decir fue "¿por qué no viniste a mí antes?".

Si hay una lección inequívoca de Agile, es que los proyectos necesitan un flujo regular de contacto entre el desarrollador y aquellos para quienes se desarrolla el software. Ningún proyecto debería suceder sin al menos un informe de estado semanal; eso puede ser unas pocas oraciones verbalmente en una reunión, pero debe mencionarse. Eso le hubiera brindado la oportunidad de mencionar que no estaba progresando y que ellos mencionaran que el proyecto estaba congelado.

Esto es su culpa, no la tuya.

¿Cómo controlo los daños en este tipo de cosas?

No. esta hundido De hecho, otras personas lo habían olvidado. Siga adelante. La mejor respuesta es centrarse en la entrega de calidad de su trabajo actual .

Otras respuestas han señalado muy bien cómo se manejó mal la situación, solo agregaré algunos consejos sobre estos puntos específicos:

¿Es salvable mi carrera? ¿Puedo arreglar las cosas con este empleador (la consultora, no el cliente)?

  • Tu carrera no se ha dañado como han dicho otros, y puedes aprovechar la oportunidad para aprender algunas cosas. Primero, aprenda a reconocer lo que es salvable y lo que no lo es. No puede corregir la mala gestión si su situación no le otorga ningún poder sobre ella. Por lo general, es una señal de alerta que sugiere que debe seguir adelante y cambiar de trabajo, la mayoría de las veces, todo lo que puede esperar de una mala gestión es más mala gestión. Y al final, la culpa puede incluso recaer sobre ti. A veces las personas no merecen que las cosas sean reparadas, haz tu trabajo concienzudamente y eso pagará con el tiempo.
  • Además, aprenda a reconocer patrones para malos proyectos. El hecho de que tenías que codificar un hardware al que no tenías acceso es algo que ocurre a veces. Pero el hecho de que no se le proporcionó un entorno de prueba adecuado para este hardware es una gran señal de alerta. Con experiencia, podrá pedir precisiones/recursos directamente desde el principio cuando vea que las cosas pueden convertirse en un desastre.
  • En el trabajo, no te tomes las cosas demasiado personales, a veces estás entre el martillo y el yunque, y la solución más fácil de tu jefe es echarte la culpa para que no quedes como un tonto frente al cliente. Mientras sea solo una excusa y tu jefe no te regañe o tu reputación se dañe públicamente, estas son cosas que suceden. No deberías tomar todos los fracasos como fracasos personales.
  • La mayoría de las veces, la comunicación es la clave. No dudes en pedir confirmación en caso de duda o antes de ir todo trabajo en solitario, preferiblemente por escrito y guarda las respuestas. Esto te puede ayudar mucho a enfrentarte a gerencias/clientes con mala fe.

Esto no es tu culpa.

Parece que "caíste en un agujero". Es decir, su proyecto era lo suficientemente insignificante y su papel lo suficientemente pequeño como para que cuando se desechara el proyecto, nadie se acordara de contárselo.

Ese es un comportamiento inaceptablemente poco profesional por parte de todos los demás involucrados, no de usted . En particular, su supuesto gerente es la principal persona responsable de garantizar que tenga trabajo y lo esté superando, y no cumplió con esa responsabilidad por completo. Un miembro junior del equipo necesita más comunicación, no menos, y tú no obtuviste ninguna .

Que este tipo de cosas sucedan es bastante posible en una gran empresa, pero en una pequeña consultoría me tiene rascándome la cabeza. El tiempo del desarrollador es un recurso increíblemente preciado, especialmente cuanto más pequeña es la empresa involucrada: ¿cómo puede su empresa pagarle si ha pasado cuatro meses trabajando en algo por lo que no se les paga? Sospecho algún tipo de fraude de facturación por parte de su empleador.

Tu carrera es absolutamente salvable porque todavía no tienes una. Esa es la ventaja de empezar desde abajo, no hay expectativas; la desventaja es que hay muchas personas que comienzan desde el mismo lugar que tú. Y al menos tienes algo de experiencia para ponerte un poco por delante.

Si desea contar esto como experiencia laboral, depende totalmente de usted. Dicho esto, si lo hace, es probable que le pregunten al respecto, y considerando que no avanzó mucho durante este tiempo, esas pueden ser preguntas incómodas. Alternativamente, puede simplemente decir que esos 4 meses fueron parte de su especificación de trabajo "estándar" (por lo que si estuvo escribiendo aplicaciones web durante 8 meses antes de eso, solo diga que tiene 8 + 4 = 12 meses de experiencia escribiendo aplicaciones web). Lo más importante es que ahora tiene una experiencia de vida de primera mano de "cómo funciona una empresa disfuncional" para que, si alguna vez vuelve a estar en la misma situación, lo reconozca y pueda actuar para evitar un resultado similar. .

Personalmente, recomendaría encontrar un nuevo trabajo lo antes posible (lo que aprecio puede ser difícil en este momento), porque parece que su empleador actual es increíblemente incompetente o está involucrado en algunas prácticas sospechosas. Su otra opción es tener una reunión con su gerente y preguntarle por qué demonios no lo controlaron durante tanto tiempo, y si no obtiene una respuesta satisfactoria, siéntase libre de escalar el asunto. Solo tenga en cuenta que, al hacerlo, podría molestar a su gerente (lo que, sinceramente, no parece ser lo peor del mundo: ¡podría terminar siendo reasignado para trabajar con alguien que sea realmente competente)!