¿Cómo manejas ser el único técnico en un equipo que no es técnico?

Entonces, ¿está diciendo que el personal de su empresa no es técnico y ha creado algunas hojas de cálculo y VBA para que puedan hacer su trabajo, y que ha reemplazado esto con un sistema que requiere que aprendan Python?

El sistema que ha construido puede ser más extensible, mantenible, escalable, etc., pero si el personal necesita escribir código en Python para configurar proyectos y mantener la infraestructura, entonces está en una posición perdedora, no va a funcionar. suceder De hecho, no debería suceder, presumiblemente el personal tiene otras áreas de conocimiento comercial que son fundamentales para sus trabajos; atención al cliente, gestión de cuentas, análisis de negocios? La codificación es una pérdida de tiempo y experiencia.

Es completamente comprensible que estés en esta posición. Primero tenías que escribir los huesos del sistema. Debe proteger los datos, una interfaz de usuario puede parecer un lujo en esta etapa. Especialmente cuando todo depende de tu software y eres la única persona que hace el trabajo. Sin embargo, debe hacer que el sistema funcione sin depender de la capacidad de codificación de los usuarios.

Me imagino que estás bajo mucha presión por esto. Parece que, solo, ya lo ha hecho mejor que toda una compañía de consultores externos. Ahora es el momento de aprovechar ese éxito para obtener ayuda. ¿Puedes persuadir a la empresa para que contrate a alguien que te eche una mano? Si no es para ayudarlo a escribir una interfaz de usuario, al menos para quitarle la carga a los usuarios, liberando su tiempo para comenzar con una interfaz de usuario. No necesita contratar a un desarrollador senior en este punto, un novato ansioso al que pueda entrenar puede ser una mejor opción.

Una última cosa: he estado en la posición de reemplazar hojas de cálculo monstruosas de Excel que contienen macros de VBA de pesadilla con sistemas codificados correctamente y un enfoque que funcionó fue mantener Excel como la interfaz de usuario en la primera iteración para evitar el problema 'no inventado aquí'. Con el tiempo, vieron que les quitábamos el dolor y les hacíamos la vida más fácil, y confiaron en nosotros cuando se trataba de deshacerse finalmente de Excel.

Esto suena como una situación poco común (y frustrante), en la que no he estado personalmente, por lo que es probable que alguien más tenga una experiencia más directamente relevante. Sin embargo, esta parte me arrojó una bandera roja:

La infraestructura es tan genérica y flexible como puede ser...

Esto al menos suena como lo que he visto hacer a algunos colegas nuevos en trabajos de software. Me salta a la vista que posiblemente sea demasiado complicado para un trabajo inicial, antes de que se haya demostrado algún valor. Los problemas que describe en párrafos posteriores son bastante acertados para mis preocupaciones cuando leí eso.

Creo que , para empezar, necesita morder piezas muy pequeñas de funcionalidad y demostrarse a sí mismo y a su lugar de trabajo que realmente puede ofrecer mejoras de eficiencia. Tenga algunas conversaciones con las personas en su proyecto específico sobre (a) cuáles son los puntos débiles más serios y (b) haga una lluvia de ideas sobre qué tipo de herramienta o interfaz estarían bien para agregar a su proceso. Si su solución requiere la programación del usuario, y no son programadores, entonces no es un buen comienzo. (Si están acostumbrados a mirar Excel, entonces tal vez hacer una plantilla de hoja de cálculo con algunas macros de Python bajo el capó sea una alternativa de inicio razonable).

Obtenga algo de aceptación o interés por una pequeña herramienta por adelantado. Consíguelo en una semana. Obtener algunos comentarios e iterar. Consigue cierta velocidad para reducir el dolor de otras personas. Muestre que el tiempo específico del proyecto en realidad está generando beneficios. Casi tienes que adoptar la mentalidad de una pequeña startup/skunkworks, encontrando formas de venderte para hacer feliz al cliente. Es improbable que sea productivo hacer un gran intento e intentar resolver todos los problemas a la vez (sin la aprobación previa de la interfaz).

En mi campo (videojuegos), he visto a un solo desarrollador adjunto de forma independiente a un departamento no tecnológico (arte), que era muy consciente y sensible a las necesidades del artista (p. ej., facilidad máxima con el pensamiento gráfico basado en lo visual) que tuvo mucho éxito y llegó a ser considerado un miembro invaluable del equipo. Podía atender rápidamente las llamadas de ayuda de los artistas y mejorar las herramientas anteriores basadas en texto para aliviar los cuellos de botella allí.

Tal vez pase un fin de semana pensando en cómo es su proceso de desarrollo de software de un solo hombre. Incluso el modelo de cascada SDLC tradicional comienza con numerosas entrevistas a los clientes en los pasos iniciales. No creas que puedes saltarte eso.

Fue un gran error de su parte asociar las horas de infraestructura a un proyecto en particular. Desde el principio, debería haberse asegurado de que hubiera un proyecto dedicado a esto.

También sospecho que fue un error de su parte implementar un sistema que no parece ser utilizable por nadie más. De todos modos, lo hecho, hecho está.

Tengo la sensación de que este problema en particular no es tan raro.

Debe encontrar algún gancho para que las personas puedan comenzar a usar la infraestructura subyacente y obtener algunas ganancias de productividad iniciales que los liberen para aprender más. Probablemente debería hacer esto de tal manera que les permita usar las herramientas con las que están familiarizados para empezar.

Solo como ejemplo, si están acostumbrados a modificar datos a través de scripts en una hoja de cálculo de Excel, debe considerar proporcionar un punto final de odata que Excel pueda leer/escribir. Puede hacer que este punto final sea configurable para realizar algunas transformaciones de datos de acuerdo con los archivos de configuración. Luego se convierte en una cuestión de migrar lentamente, con el tiempo, las transformaciones comunes de los scripts de VBA a las características de su terminal.

Los usuarios avanzados pueden eventualmente darse cuenta de que pueden escribir sus propios puntos finales de odata, o incluso pueden decidir deshacerse de Excel por completo para llegar a la infraestructura directamente.

Sospecho que necesita encontrar el proyecto que tiene más probabilidades de beneficiarse de esto con la menor cantidad de esfuerzo y apuntar a eso.

Has chocado contra una pared. Desafortunadamente, para hacer más, es posible que deba cambiar, ya sea de compañía o de lo que está haciendo.

Construiste un buen sistema, pero nadie puede usarlo. Este es un desajuste típico entre una persona técnica y los usuarios.

Una solución sería cambiar el enfoque. Los "clientes" de su trabajo son sus compañeros de trabajo. En mi experiencia, es mejor averiguar qué tipo de solución pueden usar mis clientes antes de comenzar a construir algo. En este caso, parece que los clientes pueden usar soluciones basadas en Excel y VBA, pero nada más. Sí, VBA no es tan limpio como Python, pero aun así puede hacer el trabajo.

¿Hay alguna manera de tomar lo que ya ha escrito y reescribirlo en VBA? Encuentro que darle a la gente una breve macro de VBA que les ayude hace una gran diferencia en su aceptación de lo que estoy haciendo. Repetir.

Está en una situación difícil, básicamente siendo lanzado en paracaídas a una empresa para automatizar sus antiguos procesos manuales, con poco o ningún apoyo de la alta dirección, poco o ningún apoyo de sus compañeros de trabajo y el conocimiento de que un intento previo de hacer este trabajo terminó en fracaso.

Su objetivo de lograr que sus compañeros de trabajo aprendan Python es bueno, pero no a corto plazo; comprensiblemente, preguntarán 'qué hay para mí', y una respuesta de 'tal vez una carga de trabajo algo reducida en 6 meses' no parecerá satisfactoria.

Tampoco subestimes el factor miedo de cualquier cambio en el status quo; sus compañeros de trabajo pueden estar preocupados de que sus habilidades de codificación inexistentes no estén a la altura de la tarea, y la gerencia los despedirá porque no pueden codificar. Este miedo puede ser completamente infundado, pero puede influir subliminalmente en su juicio cuando se trata de involucrarse.

Por lo tanto, debe crear un proyecto emblemático que demuestre cuán maravilloso y no amenazante es su enfoque. Elija una tarea manual particularmente tediosa, que generalmente no le gusta a todos, y automatícela. A corto plazo, tendrá que hacer toda la codificación, pero cuando los usuarios soliciten mejoras, podría sugerirles amablemente que cambien el código, bajo su atenta mirada. Si logra mejorar la carga de trabajo de una persona, se correrá la voz y gradualmente otros mostrarán interés, pero lamentablemente esto llevará bastante tiempo y no sería sorprendente que se quedara sin entusiasmo por un trabajo que se siente como vadear. a través de la melaza, y buscó una compañía que fuera más receptiva a sus talentos.