¿Es correcto rechazar con cortesía pero sin rodeos los plazos poco realistas para una tarea de desarrollo de software?

¿Capa pluvial? Es realmente tonto. Esto es como casi cualquier juego de mesa que tiene recursos limitados. Tiene que ser un poco mareado o tener poca experiencia como gerente si ve que tienen un recurso compartido que está sobrecargado y también espera que las entregas se realicen a tiempo.

Una cosa SIEMPRE como mis desarrolladores: ¿cuál es SU estimación? Tienen que vivir o morir según esas estimaciones, y yo doblo esas estimaciones cuando las estoy informando a mis clientes, porque en general la mayoría de los ingenieros realmente apestan las estimaciones.

Así que aquí es cómo va esto

Mgr 1. Aquí están las especificaciones; ¿Cuál es su tiempo estimado de finalización?

Engr: Uh, 3 meses de esfuerzo laboral. (Digamos solo octubre)

Mgr 2. Aquí están las especificaciones (para un proyecto muy similar); ¿Cuál es su tiempo estimado de finalización?

Engr: Uh, 3 meses de esfuerzo laboral. (Digamos que es octubre), PERO … ya especifiqué un Esfuerzo de Trabajo para Mgr 1, así que quien sea primero me atrape y el otro tendrá que esperar.

Mrg 2. ¡Mierda! y sale corriendo para que su proyecto sea aprobado primero!

Dios mío, ¿cómo haces ? seriamente.

Bueno, ¿cuál es la alternativa? ¿Que el ingeniero acepta ambas tareas y falla una de ellas o quizás ambas?

La falla aquí radica en la estructura organizativa que tiene muchos gerentes que realizan solicitudes al mismo ingeniero sin saber o preocuparse por qué otro trabajo se está realizando.

Una forma más sensata de manejar esto es tener una sola persona a cargo de tomar y priorizar las solicitudes, de modo que todos los gerentes le pregunten y luego decida qué tareas deben ser abordadas con mayor urgencia por el ingeniero o los ingenieros.

Esto no solo es común , sino que, literalmente, es el hecho que define la vida cotidiana de la mayoría de los ingenieros de software. Si no tiene un gerente directo que pueda batallar por usted y hacer que los “trajes” se vean realidad, generalmente se queda estancado con plazos formales que no se pueden cumplir y la posterior percepción de un desempeño deficiente. Cómo nos enfrentamos es (en orden):

  1. Dígale a nuestro gerente que necesitan manejarlo, y elija la prioridad que asignen. La razón por la que están allí es para hablar de “gerente” con otros gerentes, y aislarnos de políticas tan mezquinas y demandas absurdas.
  2. Dígale a quienquiera que exija la fecha límite absurda las concesiones para hacer que esa fecha límite (en términos de pruebas, finalización de funciones y otras prioridades) en el correo electrónico de la compañía, para la documentación . Si insisten, y las cosas van al sur, guarde los correos electrónicos para el tiempo de revisión del desempeño.
  3. Pasivo-agresivamente degradar otras solicitudes de ese gerente para respaldar las solicitudes “no urgentes, pero sería bueno tener alguna vez” de los gerentes sensatos. (Sí, no deberíamos hacer esto, pero todos lo hacemos. Somos humanos).

La solución a este tipo de disfunción es tener al gerente del equipo de desarrollo en la misma posición organizativa que todos los demás gerentes departamentales. El gerente de desarrollo debe tener la autoridad para simplemente decir “No” a demandas imposibles. Las compañías que no lo permiten sufrirán una hemorragia en el desarrollo del talento, ya que los buenos desarrolladores se dan cuenta de que la opción # 1 no tiene efecto, la opción # 2 simplemente empeora las cosas y la opción # 3 les hace sentir mal por su trabajo.