Hace tres meses comencé a trabajar en una nueva empresa como ingeniero de software. En dos meses, ayudé a incorporar al equipo a muchas de las mejores prácticas contemporáneas. No realizaron un control de fuente adecuado, no realizaron pruebas, no tenían mucha experiencia en la nube y construyeron proyectos de una manera bastante anticuada. Tenga en cuenta que nunca fui un fanático de las "mejores prácticas": simplemente me preguntaron si sabía cómo hacer "tal y cual" y ayudé a guiar al equipo en el camino.
Si bien diría que soy un senior (puedo construir, implementar y mantener un proyecto de principio a fin) y me siento cómodo administrando un equipo, definitivamente tengo mucho que aprender y no estoy listo para ser el arquitecto principal. (ni me pagan con un título para reflejar eso). De cualquier manera, este es esencialmente el rol que adopté cuando me nombraron "desarrollador principal" de un nuevo proyecto altamente crítico.
El primer sprint de este proyecto no salió bien. Subestimé cuánto tiempo llevaría poner en marcha este nuevo programa porque estaba operando bajo las siguientes suposiciones:
Estas resultaron ser suposiciones falsas. La falla crítica aquí es que la ayuda de los desarrolladores senior fue: "No recuerdo cómo hice esto, pero aquí hay una aplicación mal escrita que hicimos hace dos años que lo hace". TL; DR no proporcionaron orientación sobre las cosas que afirmaron haber hecho y tuve que aprenderlo sin su ayuda.
Todo eso está bien. Lo que no está bien es que después de un único sprint fallido, el director de la empresa expresó su frustración y ahora quiere que el director del proyecto tenga controles diarios conmigo y solo conmigo para ver si específicamente "tengo algún bloqueo".
Me siento extremadamente insultado después de todo el arduo trabajo que he hecho y cuánto he ayudado a mejorar las prácticas de los equipos, el conocimiento de la nube y el diseño de software, y cómo asumí un rol de desarrollador líder y mentor sin solicitar un título. o cambio de salario. ¿Estoy exagerando? ¿Cómo puedo comunicar que no estoy de acuerdo con esto?
Si bien este es un paso contraproducente tal como se enmarca, es más efectivo apoyarse en él que luchar contra él. Admite una letanía de errores en el primer sprint, por lo que la gerencia responsable tiene que analizar más de cerca la situación de alguna manera , incluso si esta no es la forma que usted prefiere. Esta es una oportunidad para alinearse mejor con las expectativas y dar una buena impresión después de un paso en falso inicial, parte de una práctica conocida como "managing up" (gestionar su gestión) que le será de gran utilidad en su carrera.
Los dos principios clave de la "gestión" son
Usted es el desarrollador principal, así que suponga que la verificación de bloqueadores no se trata realmente de usted personalmente, sino del progreso general. Sea abierto y servicial con el PM y verán que usted es bueno y altamente calificado y se convertirá en su defensor. Use el registro para obtener más información sobre las metas y expectativas del PM y del director; este es un recurso informativo importante para usted.
Cualquier tipo de "decirles que no estoy de acuerdo con esto" es un movimiento que limita la carrera. Aproveche la oportunidad que se le brinda aquí para hacer un aliado y construir su reputación en la empresa.
De acuerdo con la respuesta que sugiere que convierta este requisito desagradable en su propio beneficio. ¿Quieren que les digan cuáles son sus bloqueadores? Diles tus bloqueadores.
De esa manera, no puede haber malentendidos sobre lo que está pasando y cuál será el resultado probable. No debe preocuparse por el éxito de este proyecto; ese no es su trabajo. Su empleador debe perseguir el éxito del proyecto, y usted es una herramienta entre muchas que desplegarán en ese esfuerzo.
Déjame darte un ejemplo de por qué. Nuestra empresa está trabajando en un proyecto empresarial crítico. Y el grupo en el que estoy es uno de los equipos críticos en ese proyecto, con una buena posibilidad de que estemos en la ruta crítica del proyecto; en otras palabras, si nuestra área se retrasa 1 semana, entonces todo el proyecto podría retrasarse 1 semana. Y mi compañero de trabajo está en la ruta crítica de nuestra parte del proyecto.
Mi compañero de trabajo es increíble. Nadie tiene quejas sobre su trabajo, es una estrella. Pero puedes apostar a que, todos los días, le preguntan si hay algo que le impida desarrollar el proyecto. Porque desde la perspectiva de la empresa, cada hora de pérdida de productividad de él es una hora extra de retraso en el proyecto.
En otras palabras: el hecho de que la alta gerencia quiera comunicarse con usted regularmente acerca de los bloqueadores podría no tener nada que ver con su desempeño; es posible que deseen monitorear de manera proactiva el CriticalPath/LimitingResource del proceso y asegurarse de que todo vaya bien.
Olvídate del insulto, puede que tengas un problema mayor o una gran oportunidad.
Prácticamente nada en el lugar de trabajo tiene la intención de ser grosero, por lo que tomarlo de esa manera no es algo razonable. Sí, ciertamente hay idiotas, pero sus motivaciones rara vez son "Quiero ser un idiota hoy", por lo que interpretar esto de esa manera no te lleva a ninguna parte.
Debe averiguar por qué la gerencia quiere estas cosas. ¿Hay un intento genuino de ayudar que se está haciendo y simplemente ofreciendo (y por lo tanto una gran oportunidad) o simplemente hay una necesidad de culpar a alguien? El historial de la gerencia le informará de qué manera se apoya en esto, pero a las personas que están "frustradas" no suele gustarles.
Activaría #opentowork en LinkedIn en su posición, pero asumo que la gerencia está buscando un jefe.
Me sorprende que no estés consultando a diario con todo el equipo para ver si hay algún bloqueador. Creo que existe una metodología ampliamente utilizada en la industria del software llamada Agile.
Una de las ceremonias que tiene lugar en Agile se llama stand-up diario, que normalmente dura unos 15 minutos. Aquí es donde todo el equipo se reúne para discutir en qué están trabajando y para denunciar cualquier bloqueo.
Búscalo en Google y menciónalo a tu director y jefe de proyecto. Entonces, en lugar de solo comunicarse con usted, pueden unirse a todo el equipo para discutir el trabajo actual en progreso e identificar cualquier bloqueo antes de que se convierta en un impedimento.
Consulte también el Test de Joel , nunca trabajaría para una empresa que no haya respondido afirmativamente a al menos 10 de estas preguntas.
Esta es una gran oportunidad: ¡Convierta al gerente de proyecto en su recurso!
Llame los bloqueadores al gerente del proyecto y asígnele la responsabilidad de desbloquearlos. Eso es en realidad una gran parte de su papel.
Por ejemplo, si los desarrolladores "senior" no están siendo útiles, haga que sea su trabajo ajustar su actitud.
Un poco irónico, pero como han dicho otros, si le das vueltas a esto en la cabeza para pensarlo, esto puede ser útil. La mayoría de los trabajos apestan porque no podemos hablar con personas en una posición de poder que puedan cambiarlos. Por suerte para ti, estás en una situación diferente. Usa el poder que te ha sido dado.
Sin embargo, espere unos días y semanas antes de volverse exigente: primero debe construir la relación y mencionar las cosas con delicadeza al principio. La gente en general confía en los demás una vez que han visto trabajo y honestidad a lo largo del tiempo.
Por supuesto, en realidad no le comunicas esto (el titular) a nadie. Solo tu.
Nota para el futuro: inicie este proceso usted mismo. Ser administrado o gestionarlos. Tu elección.
Permítame dividir esto en dos cuestiones diferentes: sus sentimientos acerca de que le pidan que haga el control diario y cómo reacciona ante esa solicitud.
Tus sentimientos son. Los sentimientos son moralmente neutrales. Están conectados con lo que eres. Por lo tanto, sentir que estás siendo señalado es un sentimiento válido.
Sin embargo, qué hacer con esta situación es una cuestión totalmente diferente.
Usted afirma que el primer proyecto terminó sorprendiendo a la gerencia al no cumplir con la fecha de entrega prevista. El objetivo de "gestionar" tiene que ser no sorprender al gerente. Hágales saber día a día los problemas que enfrenta y lo que necesitan saber para mantener su alta productividad. Además, esta es una muy buena manera de informarles sobre las suposiciones que estaban equivocadas y cambiar el "sprint" lo antes posible (o dejar que tomen medidas de gestión con respecto a los demás).
En otras palabras, la gerencia ya no quiere que usted la sorprenda. Ahora, cómo hacer eso de una manera que se adapte a tu carácter y estilo es algo que debes descubrir (usando las sugerencias de otros).
En el último concierto, voluntariamente comencé a enviar por correo electrónico informes de estado diarios al final del día con lo que había logrado y cualquier nota que quisiera que mi gerente supiera. Esa práctica fue muy útil para continuar con el concierto. Me pareció mejor hacer el estado al final del día mientras aún recordaba todo. Su experiencia puede ser diferente.
Es un poco poco ortodoxo que quieran reunirse con usted y solo con usted en lugar de tener al PO, su Scrum master, usted y su equipo en una rutina de reunión diaria. Así se hacen las cosas en equipos Lean y metodologías SCRUM. Se conoce como scrum diario, pero no se requiere que los maestros de scrum asistan.
Es posible que desee investigar si hay una manera de transformar sus comprobaciones diarias en un SCRUM con su equipo presente, vocal e inmediatamente consciente de las necesidades de sus PO/clientes en términos de funcionalidad, solidez del diseño, prioridades de características y cronograma del proyecto. De esta manera, todos sus compañeros de equipo pueden informarle directamente a usted y al PO sobre cualquier impedimento, y hay total transparencia en toda la pila de administración sobre quién logró qué.
Además, si esta es la dirección que quieren tomar sus PO/gerentes, puede pedirles que proporcionen a su equipo licencias para una herramienta de software Scrum para que todos puedan tener información de RT sobre qué objetivos semanales se han logrado y cuáles están experimentando. retos De hecho, podría incluso ir con todo incluido y solicitar que haya una reunión de planificación semanal o bimensual para cada sprint de 1 o 2 semanas. Esto es normal para scrum. Vea si están de acuerdo o fallan en estas solicitudes.
No tomaría esto como un insulto en absoluto. Si tuvieran un problema grave, no estarían ofreciendo esto, estarían dando algo así como un "plan de mejora del rendimiento", o incluso podrían despedirte dado lo nuevo que eres.
Si son conscientes de los problemas que estaba teniendo, probablemente solo le estén dando exactamente lo que necesita. E incluso si no lo fueran, si la alta dirección es consciente de los tipos de bloqueadores que pueden afectar a los proyectos de software, esta es una buena apuesta para solucionar el problema, no por las deficiencias que tenga, sino porque le permite a alguien superior a usted obtener la información necesaria para hacer lo que hacen los buenos gerentes: eliminar los obstáculos de su camino para que pueda hacer su trabajo de manera más efectiva.
Ejemplo: si tuvo esto en el primer sprint, podría haber mencionado que otros desarrolladores senior no estaban brindando el soporte requerido. Luego, el PM podría intervenir y hacer algo como contactar a sus PM para reorganizar sus sprints y hacer tiempo para brindarle apoyo (es decir, presupuestarlo en el sprint), tal vez incluso asignándolo como un ticket. Su problema se habría resuelto rápidamente en ese caso, si el PM supiera lo que está haciendo.
El hecho de que el PM se reúna contigo y solo contigo indica que se te está brindando un recurso, no un castigo sutil (los lugares de trabajo de IME rara vez hacen esto, y no lo hagas de esta manera), porque si uno de tus blockers es un miembro del equipo debajo de usted, sería más difícil expresarlo si todo el equipo estuviera presente. De hecho, la "reunión de gerentes" es un sello distintivo de tratar a alguien como un administrador adyacente en lugar de solo un desarrollador. Si te vieran como un problema, no desperdiciarían un recurso tan valioso de esta manera. No me sorprendería si la alta gerencia tuviera conocimiento de sus contribuciones tempranas masivas, viera que no cumplió con sus primeros objetivos de sprint e inmediatamente reaccionara asumiendo que estaba siendo bloqueado por fuerzas externas y, por lo tanto, que alguien que pueda aliviarlos debería ser asignado.
Tal vez podría haberse redactado o presentado mejor, pero de un vistazo parece que eso es lo que está pasando aquí.
Me consideraría esencialmente puesto en un PIP y, a menos que tuviera algunas opciones sobre acciones o algo así, simplemente renunciaría y encontraría un nuevo trabajo.
El mercado laboral para desarrolladores experimentados está al rojo vivo en este momento donde estoy, así que solo pasaría el fin de semana presentando solicitudes de trabajo y luego me reportaría enfermo para siempre hasta que me despidieran. Sacarles una semana extra de salario.
Kilisi
nicolaswmin
figari
jyendo
Kaz