Podría decirle "sí/no, esto es/no es razonable", pero ¿quién dice que yo mismo no soy un desarrollador lento o que tengo la misma opinión que su gerente? Estas cosas son muy subjetivas y difíciles de etiquetar objetivamente.

Sin embargo, hay límites concretos a los que te enfrentas.

Horas de trabajo, para uno. ¿Están pagando sus horas extras? Porque si no lo es, sin embargo, es (implícitamente) requerido, esa es una gran bandera roja

Casi nunca siento que tengo suficiente tiempo para hacerlo sin horas extras, lo cual no puedo hacer indefinidamente porque simplemente me agotaré (como me ha pasado en el pasado). ¿Esto es normal? ¿Soy solo un desarrollador lento?

INCLUSO SI (y eso es un gran SI) fuera realmente un desarrollador lento, nadie debería obligarse a agotarse repetidamente o asumir tareas que no pueden manejar.

Independientemente de si la empresa aplica una presión más que razonable o si solo puede hacer frente a una presión menos que razonable, debe cuidarse a sí mismo y a sus necesidades. No todos pueden manejar todas las situaciones, y eso está perfectamente bien.

Menciono esto no porque crea que usted tiene la culpa o es incapaz (porque creo que la empresa tiene la culpa aquí, más sobre eso más adelante).
Menciono esto porque hay un tono subyacente de que usted asume cosas que dañan activamente su salud mental y su calidad de vida en beneficio de la empresa, que nunca es saludable.

También está el tropo genérico de la gerencia que maximiza las ganancias más allá de los límites razonables. Esto viene en dos variantes: aquellos que reducen la calidad de la producción y aquellos que aumentan la presión sobre el personal trabajando en exceso y/o pagándolos de menos.

Parece que estás tratando con ambos. La gerencia no permite ningún tiempo para las prácticas de desarrollo adecuadas que ha enumerado, por lo que no permite que se realice el trabajo adecuado y, al mismo tiempo, sobrecarga a su personal al hacer que realicen más trabajo del que razonablemente pueden hacer en las horas. están contratados.

No puedo decirle qué hacer, pero por experiencia, este tipo de situaciones son difíciles, si no imposibles, de resolver desde la posición del empleado. El conductor del automóvil tiene el control para conducir el automóvil contra una pared si así lo desea, y la gerencia es igualmente capaz de tomar malas decisiones comerciales y atenerse a ellas. No digo que sea bueno, o que debamos quedarnos de brazos cruzados, pero cuando llega el momento, un empleado no puede decirle a su gerente cómo administrar su empresa, incluso si está siendo mal administrada.

Es posible que la gerencia simplemente esté equivocada y escuche cuando se les explican los problemas, pero en mi humilde opinión (y experiencia) las probabilidades de que eso suceda son muy pocas. La gerencia ya ha demostrado que prioriza las ganancias sobre la calidad de vida del personal y (lamentablemente) pocas personas renunciarían a las ganancias para mejorar la comodidad de otras personas.

La siguiente parte es puramente subjetiva y anecdótica.

Has tocado muchas, muchas banderas rojas que he encontrado antes.

• Empresa que ejerce una presión interminable sobre su personal.
• Sin interés en la calidad de vida del personal o cualquier otra cosa que no genere una ganancia financiera directa
• Las ganancias y los plazos son lo único que importa ("por lo general, varias cosas tienen que ser desmarcadas debido a la falta de tiempo").
• La felicidad del cliente se ignora cuando no genera ganancias directas ("[no es] lo que querían los usuarios, aunque técnicamente cumple con la mayoría de sus requisitos").
• Sin visión de futuro o planificación futura más allá de la fecha límite de entrega. Sin documentación, bases de código infladas, falta de herramientas o fácil depuración, ...
• Los líderes no tienen las habilidades básicas de su propio negocio (es decir, el desarrollo de software). Por lo general, esto se puede mitigar pidiendo consejo a otras personas con dichas habilidades, pero en su caso parece que se descuida.
• "Simplemente haga todo lo que pueda" se utiliza como respuesta predeterminada de los líderes del equipo, lo que indica que los plazos se utilizan como herramientas de aplicación de presión, a diferencia de los plazos en los que razonablemente se puede esperar que algo se termine. Incluso en las mejores empresas, pueden ocurrir retrasos. Pero según su descripción, la empresa está quemando a sus empleados y luego haciendo que los empleados cubran el hecho de que la empresa los quemó.

Si desea quedarse en un sistema de este tipo es su elección. No lo haría, y he renunciado a todos los proyectos de todos los clientes en los que los problemas resultaron ser endémicos o perpetuados deliberadamente por gerentes motivados por las ganancias.

Tienes que hacer tu propia elección. Quiero agregar que el hecho de que ya se haya quemado en el pasado sugiere fuertemente que la situación en la que se encuentra actualmente no es buena para su salud, tanto mental como física.

Lo más importante que debe hacer es comenzar a ajustar sus plazos y aumentar sus estimaciones.

Me parece que estás dando "estimaciones de días soleados", como solíamos llamarlas. Sus estimaciones suponen que todo va según lo planeado y sin distracciones, cuando es fácil ver con solo la descripción que nos ha dado, que está trabajando en un caos absoluto con sorpresas desagradables al acecho detrás de cada esquina y al acecho en cada sombra.

Tome la mayor cantidad de días en los que perdió un objetivo, agregue cinco a eso y aumente sus estimaciones futuras en esa cantidad. Cuando comience a cumplir con los plazos, puede ajustar ese número.

"Gestionar las expectativas" es más que una palabra de moda. Si dice que algo tardará cuatro días y lo entrega en tres, el cliente dirá "wow, me lo puso a toda marcha", y estará satisfecho. Si tarda los mismos tres días, pero dijiste dos, el cliente se enfadará porque llegas tarde.

Además, eso te da un respiro, en caso de que suceda algo inesperado, para que no sientas que estás a punto de agotarte.

Su empresa ha creado un entorno caótico con el que puede trabajar, pero no puede aplicar los estándares de un taller ordenado a uno caótico. necesita "valorar" el caos en sus estimaciones.

Además, no seas tan duro contigo mismo. No eres ni lento, ni abrumado. Solo necesita ajustar sus expectativas y las de sus clientes al permitir el tiempo adicional que necesitará.

Además, plantee las inquietudes y los retrasos a la gerencia tan pronto como los tenga. Yo le decía a mi gente "Antes de una fecha límite es una preocupación, después es una excusa".

Si comienza a recibir rechazo de la gerencia, simplemente diga la verdad: está haciendo todo lo que puede con los recursos proporcionados.

A veces le decía a mi gerencia: "Una pinta no puede contener un galón, cuando contiene una pinta, ya está haciendo lo mejor que puede".

Enhorabuena, se ha encontrado con el triángulo de la gestión de proyectos , que suele resumirse como "bueno, rápido, barato: elija dos" por muy buenas razones.

Estás trabajando para una consultoría, también conocida como taller de carrocería porque venden el tiempo (cuerpos) de desarrolladores como tú a los clientes. Los dos puntos del triángulo que implícitamente elige una consultoría son rápidos y baratos, porque así lo eligen sus clientes.

En otras palabras, si trabaja en una consultoría, nunca se le permitirá entregar un trabajo de alta calidad, porque va en contra de su modelo de negocio. Si intentas entregar un trabajo de alta calidad, te verás encaminado a un papel sin salida como el de soporte, porque te conviertes en una responsabilidad para la empresa al tomarte más tiempo que un desarrollador al que no le importa la calidad.

Esto nunca va a cambiar mientras trabaje para esa empresa (o, de hecho, para cualquier consultoría). Confía en mí, trabajé en uno durante 8 años (o unos 5 años de más).

Por lo tanto, la única respuesta a su enigma es "encontrar otro trabajo" - difícil en este clima económico, pero no imposible. Especialmente si puede demostrar que se preocupa por la calidad del código: hay casas de desarrollo dirigidas por personas que se preocupan por ese tipo de cosas. Simplemente no vuelvas a trabajar para una consultoría.

En realidad, la pregunta que debería hacerse es: ¿cuánto tiempo puede permanecer en un trabajo en el que no tiene la oportunidad de practicar y aprender cómo hacer software correctamente? ¿Cuánto tiempo puede permitirse permanecer en un trabajo que lo está desgastando activamente? ¿Cuánto tiempo puede permitirse permanecer en un trabajo que felizmente lo despedirá en cualquier momento si puede encontrar a alguien que sea más "productivo" que usted en términos de líneas de código emitidas?

Y tenga cuidado si (con suerte cuando) decide irse. La compañía hará mucho para tratar de mantenerlo, porque entienden que un desarrollador que se preocupa es más útil que una máquina humana generadora de código con muerte cerebral fungible, pero nunca podrán cumplir con el promesas que le harán con respecto a la mejora de la calidad. Una vez más, he tenido esta experiencia.

Esa es una de las razones por las que dejo mi empresa actual. Pero vayamos a usted, desde el cliente en el que estoy, a menudo me pusieron en un proyecto después de las reuniones para decidir las características y el tiempo de desarrollo, así que muchas veces recibía un correo electrónico con "Oye, tienes que hacer esto". antes del 10 de junio" (generalmente seguido de "¿Qué es esto?") y también tengo otros proyectos en los que trabajar. Siempre termino trabajando horas extra que nadie me paga.

Un día después de la tercera vez que esto sucedió, llevé a mis supervisores directos, llamémoslos gerentes de proyecto y en una reunión les pedí amablemente: "Por favor, antes de darle tiempo de desarrollo a los clientes, hablemos de eso porque no es solo una cuestión de hacer algo sino también de gestionar las prioridades y evitar los días de entrega cruzada", a partir de ese día las cosas fueron un poco mejor.

Así que mi consejo es que hagas un discurso muy claro y conciso con tus jefes de proyecto y les hagas entender que eres TÚ quien da un cronograma de desarrollo, no ellos, ya que ellos nunca están involucrados.

Para responder si eres lento o sobrecargado, habla con tus compañeros de equipo. Vea si están de acuerdo con sus estimaciones y si también necesitan hacer horas extras no pagadas para cumplir con sus plazos. Si todos están de acuerdo en que una tarea debe tomar una semana pero el jefe quiere que se haga en 3 días, no lo va a despedir por tomar una semana porque cualquier reemplazo tomaría al menos una semana para hacer la misma tarea.

También puede ver si la empresa tiene dificultades para contratar y retener personal.

En el improbable caso de que descubra que realmente es lento en comparación con otros con la misma experiencia, averigüe qué partes del trabajo hace más rápido o mejor que ellos, y vea si puede pasar a ventas/gestión de proyectos/pruebas o lo que te venga bien.

En el caso mucho más probable de que la compañía esté sacrificando su salud y su tiempo libre por sus ganancias, interprete "haga lo que pueda" como "haga lo que pueda en el tiempo que le pagamos, y deje el problema al vendedor que subcotizó en para ganar un contrato que no era rentable".

No hay necesidad de ser militante acerca de salir a tiempo, especialmente si le causaría un problema a un colega, pero (a diferencia de los directores) no tienes capital en la empresa y no te beneficias de tus horas extra.

Debido a que somos una empresa tan pequeña, tenemos que:

1. Toma cualquier trabajo que podamos conseguir, y
2. Sea lo más barato posible

La forma en que nos mantenemos económicos es básicamente comprimir el desarrollo en el menor tiempo posible.

Entonces, ¿su empresa pudo tener la trifecta de eficiencia (calidad, gestión o como se llame)? Personas, tiempo y dinero O Rápido, barato y bueno (donde solo puede seleccionar dos).

Si es barato y tiene poca gente para hacer el trabajo por poder. Necesitas poner énfasis en el tiempo. ¿Crees que algo toma 10 horas? Escribe 15 o incluso 17.

Una vez hice un experimento. Escribí cuánto tiempo realmente dedico a hacer algo. No solo hacerlo, sino dejar de trabajar en otra cosa, revisar, mirar, guardar, volver a mi trabajo anterior y estar exactamente donde lo dejé. 2 minutos del trabajo B se convirtieron en 30 minutos sin hacer el trabajo A.

Ahora, como te diste cuenta, eso te golpeó. Porque su empresa no tiene la trifecta. Es pagar la deuda de tiempo/presupuesto contigo. Estás haciendo horas extra, estás dedicando tiempo a ponerte al día con la documentación o los bloques mientras piensas que TÚ estás tomando tiempo de todo el proyecto.

El primer problema que debe enfrentar es que la empresa lo ve como SU problema. El producto es barato y a tiempo. Por lo tanto, no hay problema con retrasar o cambiar los plazos. Tampoco tiene una marca de tiempo "mire, este problema nos llevó 5 días, así que tuvimos que retrasar la fecha límite 6 días".

Puedes contar las horas extras. Es medible. Pero no puedes medir cuánto te esfuerzas durante toda la semana. Es posible que esté haciendo 2 horas adicionales además de sus 8. Pero puede exprimir 15 horas allí. Sin frenos, sin comprobaciones, sin repeticiones, recortes en la escritura de documentación, etc.

Entonces, si toma Project Time y agrega horas extras, será el 75% del tiempo real necesario para entregar el producto. Producto con el que estará satisfecho, con buena calidad general, documentos, etc.

Hacer todo lo que puedas no debe interpretarse como "Haz todo lo que puedas en este tiempo". Debería ser "Haz solo las cosas que PUEDES y haz solo las cosas que puedas encajar en el intervalo de tiempo".

Podrías ser las dos cosas al mismo tiempo. Para tu velocidad de trabajo (que no solo depende de tu desempeño/habilidades/motivación sino también del tipo de tareas y calidad de preparación) tienes demasiadas tareas.

Todo lo que puede hacer es asumir que se trata de una sobrecarga y mejorar la situación (rechazar, procesar de manera más eficiente, dar retroalimentación para reducir la necesidad de rehacer, etc.). La pregunta de si es demasiado lento o no será notada por sus compañeros y gerente, en relación con el resto del personal. Solo asegúrese de que tengan la imagen completa (son minuciosos, amigables, útiles, confiables o producen menos necesidad de reelaboración, luego asegúrese de que esto se tenga en cuenta).

Pídale a su jefe que priorice los artículos, para que pueda dejar los artículos menos necesarios cuando se le acabe el tiempo.

Si bien nadie más ha mencionado esto, "simplemente haga todo lo que pueda" es una parte importante del proceso Agile. Básicamente, cuando un proyecto comienza a tener restricciones de tiempo y costo, hay dos soluciones posibles: la primera es aumentar el tiempo y el costo del proyecto para terminar todo (la solución Waterfall). El segundo es descartar las partes menos críticas del proyecto para poder enviar un Producto Mínimo Viable en la fecha límite: el enfoque Agile.

Como tal, es importante si su jefe le pide que simplemente "haga todo lo que pueda" para que priorice qué partes del proyecto son las más importantes, para que pueda terminarlas primero. Entonces, al final, has hecho todo lo que has podido y lo que no hiciste en el tiempo disponible simplemente no se hizo.

Una herramienta común utilizada para este tipo de priorización en Agile es MoSCoW: debe hacer, debería hacer, podría hacer y no hará. Debe evitar asignar más del 60% de sus artículos de Story Point a Must para evitar perder flexibilidad.

Haber obtenido la aceptación de su jefe en esto, también puede ayudarlo a liberarse de la sensación de que necesita trabajar horas extras para hacer todo, porque no necesita hacerlo todo. Solo necesita hacer todo lo que pueda, en su tiempo normal de trabajo.

¡Bienvenido al desarrollo de software! Cada desarrollador tiene esta misma experiencia. Sus únicos problemas son la estimación y el equilibrio entre el trabajo y la vida personal, no la "lentitud".

Que eres lento es justo lo que tu jefe de proyecto quiere que creas. Concéntrese en una estimación precisa, no en "ser más rápido". De esa manera, si su estimación no se alinea con la fecha límite artificial, puede tener conversaciones difíciles sobre el alcance y las expectativas muy temprano en el proyecto, en lugar de muy tarde. Y no permita que lo presionen para hacer horas extras semana tras semana. Si haces eso, inevitablemente te quemarás y serás miserable y menos productivo.

por lo general pone en proyectos ya sea en solitario o en un equipo muy pequeño

La próxima vez que esto suceda, vea cómo se compara su rendimiento con el del resto del equipo. Si le toma 2 semanas terminar la estimación de 3 días, vea si otros ingenieros también cometen errores de estimación similares. Cuando desarrollen una función, revise su código e intente ver cuánto tiempo le tomaría hacerlo y compararlo con su tiempo.

Dado que eres relativamente nuevo, está bien si estás al 60-70 % de la productividad de las personas mayores, pero si estás al 20-30 %, eso no es bueno.

Desafortunadamente, una gran cantidad de trabajo por contrato es así. La "solución" más común es implementar exactamente y solo lo que requiere la especificación. Las pruebas se limitan a la forma precisa en que la especificación dice que se utilizará el software. Olvídate de hacer un buen trabajo, cumplir el contrato y nada más.

Como ejemplo, un software que fue subcontratado hace unos años vino a mi manera de probar. Me di cuenta de que si ingresaba más de 20 caracteres en uno de los campos de entrada, fallaría. Cuando lo consulté, respondieron con una cotización para cambiar la especificación y agregar pruebas adicionales, porque originalmente mi empresa no especificó "no debe bloquearse si ingresa más de 20 caracteres".

Apesta, la mayoría de la gente odia hacer un mal trabajo cuando saben que pueden hacerlo mejor, pero es lo que quiere su cliente. Si quisieran más, especificarían más y pagarían más.

La buena noticia es que con 3 años de experiencia en una selección de diferentes tecnologías, tuvo que aprender que está en una excelente posición para encontrar un mejor trabajo de desarrollador de nivel medio.