Me incorporé a esta pequeña empresa hace un par de años, de momento de menos de 10 empleados. El producto principal es una aplicación SAAS en la que la base de clientes crece constantemente. El fundador y director ejecutivo codificó la mayor parte de él mismo desde cero, con la ayuda de un trabajador ocasional. Respeto profundamente lo que ha hecho hasta ahora con el negocio, no he conocido a muchos tan motivados como él.
Luego me contrataron como desarrollador experimentado para ser una especie de líder tecnológico, con el objetivo de aumentar el nivel de calidad y agregar código a la escalabilidad organizacional, para que podamos contratar a más desarrolladores de los que ya tenemos, y pronto. Ojalá aún más. Hasta ahora, he introducido el control de versiones, las pruebas y he tratado de modernizar y establecer cierto nivel de estándares y pautas de codificación junto con mi equipo, lo que funciona bastante bien, todavía con un espacio definido de mejora, pero en el camino correcto. El problema para mí es el CEO. Es autodidacta, no es que sea un problema en sí mismo, pero no ha adquirido ninguna habilidad de programación más allá de tutoriales de bajo nivel específicos para la tecnología que usamos. Por razones que nunca desafiaría, pasa poco tiempo en la oficina, principalmente ejecutando tareas gerenciales como definitivamente debería. Se va temprano o trabaja algunos días fuera de casa y, a menudo, pasa tiempo codificando fuera del horario de oficina. En su mayoría, salta sobre nuevas ideas o características específicas que los clientes individuales han solicitado y las agrega directamente a la producción superando nuestros procedimientos habituales como si todavía fuera el único desarrollador, sin preocuparse por los estándares sobre los que siempre parece muy positivo. Su trabajo a veces conduce a problemas que nos afectan a mí y a mis compañeros de equipo o simplemente nuevas funcionalidades que no sabemos cómo deberían funcionar porque no tenemos tiempo para analizarlas y cuando él no está, dedicamos tiempo innecesario a las preguntas de los clientes. a cerca de ellos. En su mayoría, salta sobre nuevas ideas o características específicas que los clientes individuales han solicitado y las agrega directamente a la producción superando nuestros procedimientos habituales como si todavía fuera el único desarrollador, sin preocuparse por los estándares sobre los que siempre parece muy positivo. Su trabajo a veces conduce a problemas que nos afectan a mí y a mis compañeros de equipo o simplemente nuevas funcionalidades que no sabemos cómo deberían funcionar porque no tenemos tiempo para analizarlas y cuando él no está, dedicamos tiempo innecesario a las preguntas de los clientes. a cerca de ellos. En su mayoría, salta sobre nuevas ideas o características específicas que los clientes individuales han solicitado y las agrega directamente a la producción superando nuestros procedimientos habituales como si todavía fuera el único desarrollador, sin preocuparse por los estándares sobre los que siempre parece muy positivo. Su trabajo a veces conduce a problemas que nos afectan a mí y a mis compañeros de equipo o simplemente nuevas funcionalidades que no sabemos cómo deberían funcionar porque no tenemos tiempo para analizarlas y cuando él no está, dedicamos tiempo innecesario a las preguntas de los clientes. a cerca de ellos.
Entiendo que estamos creciendo y necesitamos alcanzar una mayor rentabilidad, pero definitivamente se siente como si él persiguiera bolas bajas a corto plazo para obtener clientes geniales o grandes que pueden o no dar sus frutos, y dice que nosotros (los empleados del desarrollador) arreglaremos y limpiaremos más tarde, pero en cambio se convierte en un montón de pequeños dolores de cabeza en los que no tenemos tiempo para trabajar de todos modos porque siempre hay algo más importante.
He intentado plantear mis problemas con esto a mi jefe y al propietario del producto cofundador, y responden con aceptación y comprensión. Pero en nuestra última evaluación de empleados, recibí comentarios de que "a veces debería tratar de completar las tareas más rápido, en lugar de tratar de encontrar la mejor manera posible", pero también que están impresionados por la calidad de mi trabajo en general. Estoy de acuerdo en que no se puede dedicar tanto tiempo a cada tarea y acepto la premisa de que podría tener una perspectiva estrecha, pero al mismo tiempo sí creo que el CEO no sabe de métodos de desarrollo, ni tiene una comprensión teórica de arquitectura de software o incluso más que una orientación a objetos muy básica, lo que hace que la retroalimentación sea un poco difícil de tragar.
Estoy empezando a pensar que no soy un buen candidato para esta empresa. Sé que tengo las habilidades técnicas, pero supongo que extraño las habilidades blandas necesarias para ser un líder tecnológico en este tipo de organización que se suponía que debía ser y me gustaría ser. Simplemente no veo cómo puedo abordar esto sin ser despectivo, ya que siento que ya estoy escribiendo esto. Probablemente estoy un poco frustrado por sentir que me estoy convirtiendo en un peor desarrollador debido a esta situación.
¿Es hora de seguir adelante y encontrar una oportunidad en la que pueda desarrollar esas habilidades en un entorno mejor para mí? ¿O hay una mejor manera de manejar algo como esto?
Este es un problema muy común en las tiendas pequeñas; Yo mismo creé los mismos tipos de problemas al ejecutar un inicio de software en el pasado.
La clave para solucionarlo es la educación. Ya sea que su CEO esté interesado o no en ser un desarrollador de gran D, si está expuesto a ideas sobre la calidad del código, qué son las pruebas unitarias y por qué son importantes, etc., se dará cuenta y, en última instancia, buscará su liderazgo. .
Una forma de educarlo es hacer que asista a conferencias técnicas políglotas como CodeMash o That Conference y alentarlo a que "vuelva con nuevas ideas sobre cómo podemos mejorar la calidad de nuestro código". Aún mejor: acompáñelo y plantee el tema de cómo no publicar software defectuoso con otros en la conferencia mientras él está presente.
Otra buena opción es invitar a una empresa local de consultoría técnica para que venga y ofrezca un almuerzo informal sobre el tema. La mayoría hará ese tipo de cosas gratis y (¡bonificación!) puede insistir en que el jefe esté allí, ya que así es como obtienen ventas. (En este caso, debe dejarlo como una pista para la empresa de consultoría: "Por favor, asegúrese de que asista nuestro director ejecutivo; realmente necesita escuchar esto"). Una gran ventaja de los consultores es que son un tercero independiente y creíble al que se le paga decir la verdad al poder, que es lo que se necesita en este caso. (Descargo de responsabilidad: actualmente trabajo para una empresa de consultoría).
En cuanto a los comentarios que ha recibido sobre la velocidad frente a 'la mejor manera posible', puede señalar que hay una diferencia sustancial entre 'simplemente envíelo' con algunas funciones faltantes y '¡envíelo AHORA!' con errores que hacen que los usuarios se sientan frustrados y enojados. Si aprende la conexión entre la calidad del software y los clientes satisfechos, es más probable que apoye lo que está tratando de hacer.
Si el CEO es accesible, debería estar completamente abierto a esta retroalimentación. Después de todo, lo ha contratado como líder tecnológico, por lo que si decide que se deben cumplir ciertos estándares y que sus contribuciones no están a la altura de ese estándar, debe informarle.
Si desea la forma "más suave" de hacer esto que no parezca que lo está destacando, presentaría revisiones de código obligatorias para todo el código que está comprometido (si es que aún no lo está haciendo). Asegúrese de que todo el trabajo se envíe a través de relaciones públicas en lugar de a la rama de desarrollo principal directamente, y luego, cada vez que alguien envíe una relación pública (usted, su subalterno, el director ejecutivo, etc.), asigne a otra persona para que verifique ese código con la calidad del código documentado. y normas antes de aprobar. Muchos sistemas le permiten hacer cumplir esto, por lo que está prohibido comprometerse directamente con la rama principal.
Por supuesto, si el CEO dice que no a eso, o se ofende porque le dicen que su código no está a la altura, realmente no tiene demasiadas opciones: él es el jefe. Si decide que debe buscar empleo en otro lugar, la buena noticia es que puede hacerlo en su propio calendario. Es más probable que este tipo de estilo de codificación cause problemas a mediano y largo plazo (deuda técnica), por lo que no hay una necesidad inmediata de salir ahora como podría haber con problemas más grandes.