¿Cómo lidiar con plazos poco realistas como pasante en una startup?

El trabajo de su gerente es hacer demandas y manifestar expectativas. Esta es la razón por la que él / ella es su superior.
Lo que te pasa a ti le pasa a muchos. Esto se debe a que los gerentes no siempre son conscientes de las implicaciones a nivel micro. Y, si lo piensa, es fácil ver que la persona que debe asumir la responsabilidad de informar a su gerente sobre lo que se puede hacer de manera realista es usted.

1. Planifique cuidadosamente su trabajo.
2. Comience a implementar durante uno o dos días y vea dónde se encuentra después de este período de tiempo.
3. Cuando esté listo, diríjase a su gerente y ayúdelo a comprender por qué lo que se le pidió es humanamente imposible de lograr en el marco de tiempo especificado anteriormente.
4. Siga haciendo su trabajo a un ritmo realista. Si tu jefe pide lo imposible solo porque quiere exprimir lo mejor de ti, está bien. Si él / ella pide lo imposible en un modo pasivo agresivo, entonces es hora de comenzar a buscar un nuevo trabajo.

¡La mejor de las suertes!

Estoy esperando el "¿y qué?". ¿No te contratarán si fallas o te dan una mala recomendación porque no pudiste hacer lo imposible? ¿Hay un bono involucrado? ¿Llevarte detrás de la oficina y darte una paliza?

Si hubo consecuencias nefastas que pensaron que le darían la motivación/miedo para completar esta tarea, se lo harán saber.

Es una puesta en marcha. Eres su única esperanza (Obiwan). Tal vez lo consigas. Tal vez no sea tan robusto, por lo que deben tener cuidado con la forma en que lo usan. Se están arriesgando contigo. Olvídate de fallar. Haz tu mejor esfuerzo. La mayoría de la gente deja una pasantía y no ha aprendido nada ni ha construido nada. Tendrás algo que poner en un CV.

En 17 días trabajados, se supone que debo hacer:

Para completar esa frase: “Lo imposible”.

Siendo realistas, debes tomar lo que ellos quieren que hagas y dividirlo en partes realistas. Proyecto gestionar sus propias tareas. Es decir, después de 17 días, ¿qué puede presentar de manera realista del proyecto más grande que sea viable incluso sin completar todo el proyecto?

Este para mí es el mejor tacto. Porque, de manera realista, usted, o cualquier otra persona, no podrá completar los objetivos descritos en 17 días. Pero si puede construir una base sólida sobre la que luego se pueda construir, mientras no se cumpla la fecha límite formal, al menos tendrá un sólido... Algo... Sobre lo que se pueda construir cuando la realidad golpee al equipo dentro de 18 días.

Me pidió que hiciera una planificación de Gantt para equilibrar la carga de trabajo en mayo.

¿Ya has hecho esto? Así es como su gerente puede ver lo que es y lo que no es realista.

Al crearlo, debe ceñirse a lo siguiente.

1. Ningún artículo debe durar más de 3 a 5 días (dependiendo de la duración del proyecto). Durante 17 días, iría con un límite máximo de 3 días para el artículo.

2. Todo lo que supere los 3 días debe desglosarse aún más.

3. El gráfico de Gantt debe mostrar qué función depende de otra (es decir, no puede comenzar antes de que termine otra o no puede eliminarse sin eliminar otras partes).

4. No subestimes. Tu jefe te exigirá esos números.

5. Puede rellenar algunas de las tareas, pero no sobrellene los números. De lo contrario, su jefe no creerá todo el asunto. Si su gerente tiene experiencia, entonces puede completar los números internamente (ya que pocas personas creen que un desarrollador puede estimar correctamente cuánto tiempo lleva una tarea).

6. Debes detallar cosas que quizás no consideres relevantes. Por ejemplo, configuración de máquinas, capacitación, etc.

7. No tenga en cuenta los fines de semana/fuera de horario en su gráfico.

Una vez que tengas eso, dáselo a tu jefe. Depende de ellos abandonar, retrasar u obtener más recursos (o hablar sobre su horario de trabajo irrazonable).

Entonces, la respuesta general a esto es doble: abordar la parte real de alcance y entrega y la parte de comunicación.

En cuanto al alcance y la entrega, asegúrese de limitarse al producto mínimo viable absoluto que cumplirá la tarea. No lo diseñe en exceso, el objetivo es obtener el trabajo suficiente para que los usuarios participen y luego cambiarlo en función de sus comentarios. Sus especificaciones pueden o no ser "correctas" y es la validación y refactorización del usuario lo que lo revelará. Por lo tanto, limite su alcance de trabajo a entregar el mínimo requerido con suficiente energía. Idealmente, habría dividido sus especificaciones en historias y tareas con cierta granularidad y habría trabajado con alguien para clasificarlas en prioridad para saber qué podría fallar. Y, por supuesto, como otros han señalado, como pasante en una startup, se espera que produzca código 20 horas al día.

Esto nos lleva a la parte de la comunicación: si incluso se molesta en hablar primero, no hay suficiente comunicación entre usted y su supervisor. Debe hablar todos los días y expresar sus preocupaciones y pedir orientación sobre la marcha. Es posible que lo esté pensando demasiado y que él diga "mire, simplemente junte algo mínimo en dropwizard, póngale un front-end de arranque, y listo". No sé si tienen pruebas e implementación para cualquiera de sus otros bits o si eres el primero en cruzar ese abismo, pero si no, sin duda adoptaría cualquier marco que ya tengan implementado. Pero estas son grandes preguntas para él.