Como posible pasante, ¿cómo evalúo qué tan fácil sería para mí mejorar las prácticas de un equipo?

Incluso antes de que me contraten, ¿cómo calculo mejor qué tan receptivo será un equipo a mis intentos de cambiar sus hábitos? ¿Es apropiado simplemente preguntar directamente? Si es así, ¿hay alguna forma de formular la pregunta para alentar respuestas más honestas, realistas y reflexivas?

La respuesta corta es que no hay realmente una manera de hacer esto que sea ni siquiera medio confiable. La mejor manera de evaluar esto es a través de la experiencia, que no tiene (y por qué está haciendo esta pregunta en primer lugar), pero eso no significa que no haya nada que pueda hacer:

NO

Pregunta sin rodeos: corres el riesgo de ponerlos a la defensiva (con la crítica implícita de sus prácticas laborales actuales) y parecer arrogante. Incluso si no es así como lo toman y dicen todas las cosas correctas como usted dice "hablar es barato", decir todas las cosas correctas incluso si están respaldadas por las mejores intenciones no significa que las acciones seguirán.

HACER

Pregúnteles cuáles creen que son sus problemas actuales en su proceso de desarrollo: si enumeran algo que se puede resolver implementando git o cualquiera de las otras prácticas que le gustaría implementar, puede usarlo como una sugerencia. De ninguna manera es una certeza que seguirán adelante con esto, pero es un indicador tan bueno como el que obtendrá.

Como regla general, es una mala práctica comercial cambiar los procesos sin tener una idea bastante clara de qué tipo de mejoras se obtendrán. Cambiar los procesos casi siempre resulta en una caída a corto plazo en la productividad, incluso si todo el trabajo de implementación lo realizó usted mismo, habrá un período de ajuste para el equipo titular que está acostumbrado a trabajar de la manera en que lo hace en este momento, esto significa pasarán tiempo acostumbrándose al nuevo proceso (tiempo que de otro modo habrían dedicado a ser "productivos"), cualquier proceso nuevo también probablemente resultará en un aumento en la tasa de error a corto plazo porque las personas que no están familiarizadas con un es más probable que el proceso se equivoque y entonces se pierde más tiempo mientras se corrige el error.

Otra buena regla general en los negocios (y créanme, no estoy tratando de sonar duro cuando digo esto) es que, por lo general, no hará cambios significativos en sus procesos comerciales simplemente siguiendo el consejo de pasantes sin experiencia, por lo que diría que Si va a tener alguna esperanza de conseguir que se lleve a cabo alguno de estos cambios, necesitará el apoyo de uno o más miembros del equipo de desarrollo existente y, para ser sincero, no parece que lo tenga. Si uno o más miembros del equipo existente respondieron a su pregunta de git con algo como

Dios, sí... implementar git sería genial, ¡me haría la vida mucho más fácil!

entonces eso habría sido alentador porque si el gerente vale su salario antes de implementar alguna de sus propuestas, consultará con su equipo existente para ver si este pasante que apenas conocen tiene alguna idea de lo que están hablando y menos que Es probable que una respuesta entusiasta mate esa idea allí mismo.

Trabaje de la forma en que desea trabajar, siempre que no afecte negativamente a la productividad de su equipo. Por supuesto, haga esto con el permiso del líder del equipo.

Hacerlo de esta manera significa que no está imponiendo agresivamente prácticas de trabajo en el equipo y depende de ellos ver lo que está haciendo e incorporar cualquier punto bueno que vean (o descartarlos como mejor les parezca).

Tenga en cuenta que el código bien escrito no necesariamente necesita comentarios por todas partes (no sé cómo es este código, por lo que esto podría ser subjetivo). Cree su propia documentación y envíela con su trabajo. Para un rastreador de errores, solo usaría una hoja de cálculo para comenzar y alentaría a las personas a mirarla para realizar un seguimiento de su progreso en los errores. Las personas pueden comprar y agregar errores a la hoja de cálculo si los guía (pero no fuerce el problema).

A nadie le gusta que un chico nuevo sea insistente, pero es bueno ver demostraciones de buenas prácticas, y son más fáciles de adoptar si se demuestra que ayudan a su propia productividad.

Es 2018 y no están utilizando ningún sistema de control de código fuente. Es posible que mi memoria no se remonte lo suficiente, pero usé el control de código fuente (SCCS en ese momento) en 1996. Están 22 años atrás. Lamento decir esto, pero no tienes la más mínima posibilidad de cambiar lo que están haciendo.