Trabajo como desarrollador de software integrado para una empresa en crecimiento que fabrica productos físicos y, en mi opinión, está experimentando algunos problemas de crecimiento debido a su rápido crecimiento. Durante décadas, fue una empresa bastante pequeña con solo un par de docenas de ingenieros en todas las disciplinas, no solo software, y lanzó una cantidad relativamente pequeña de productos.
El modelo de desarrollo de productos que normalmente se ha seguido ha sido reunir un equipo de ingenieros de todas las disciplinas (software, electricidad, mecánica, marketing, fabricación, etc.) y luego el equipo trabaja para entregar el producto de forma ágil. Al menos así es como se supone que funciona en teoría.
En realidad, el trabajo está extremadamente aislado, ya que yo, como ingeniero de software, no puedo actualizar los modelos CAD o diseñar una placa de circuito, y mis otros colegas del equipo tampoco tienen idea de cómo escribir software. En lugar de un equipo cohesivo, termina siendo una especie de grupo de equipos de 1 hombre, todos haciendo su trabajo específico de disciplina y revisando un informe de estado durante nuestras reuniones de pie.
Hasta hace poco no había un modelo de software compartido real, cada proyecto básicamente bifurcaba el código base de un producto similar y hacía las modificaciones necesarias para el que se estaba desarrollando. Como era de esperar, esto resultó en una plétora de variaciones dispares de implementaciones muy similares, pero algunos desarrolladores se han esforzado más por crear una biblioteca compartida para mitigar este problema.
La mayoría de los desarrolladores están de acuerdo en que esta es la dirección hacia la que debemos avanzar, pero cada uno tiene su propia idea de cómo debe lograrse y no hay un mandato de una forma u otra, por lo que nunca sale nada de eso. Hay una biblioteca interna en particular creada y defendida por un desarrollador senior que es la más prometedora y la más utilizada, pero a algunos de los otros desarrolladores no les gusta su estilo arquitectónico, por lo que no la usan. Este desarrollador sénior también está en una división de I+D diferente, separada del desarrollo de productos, donde estamos yo y los demás desarrolladores de productos, por lo que tampoco tiene autoridad para emitir ningún tipo de mandato.
Nuestro gerente de software no ha realizado un desarrollo real en mucho tiempo y es más un gerente de personal en lugar de un verdadero líder tecnológico, y los líderes de productos reales generalmente provienen de otras disciplinas además del software, por lo que sus ojos tienden a nublarse cuando cualquier software surge la conversación. Y dado que cada producto generalmente solo tiene un desarrollador de software asignado, no hay mucha responsabilidad para mantener ningún tipo de estilo o arquitectura consistente.
La cantidad de productos que estamos desarrollando, así como su complejidad, ha crecido enormemente en los últimos años, y siento que estamos cabalgando peligrosamente cerca de un precipicio del desastre si nuestro modelo actual continúa como hasta ahora.
TLDR : Tenemos alrededor de una docena de programas de software de un solo hombre en el mismo departamento sin un mandato real sobre cómo se debe estructurar nuestro software.
¿Cuál es la mejor manera de abogar por una mejor organización en la que los equipos de software sean más colaborativos y estén menos aislados? Varios de nosotros sugerimos que el equipo de software aborde los proyectos como una unidad completa en lugar de tener solo un desarrollador por producto, pero el método de organización actual se basa en el nivel de vicepresidente y no estoy seguro de que mi propio administrador de software tenga el poder. hacer tal cambio incluso si quisiera.
Solo he estado en la empresa durante unos pocos años, así que no estoy seguro de ser la mejor persona para sugerir cambios de proceso tan radicales, pero al mismo tiempo siento que podría haber muchas mejoras con la estructura adecuada en lugar.
Usted menciona que su gerente no es extremadamente técnico, por lo que esta sería una buena oportunidad para que alguien en el equipo dé un paso al frente. Parece que tienes interés y algunas ideas, así que tal vez puedas encargarte de esto. Probablemente querrá avisar a su gerente, pero no es necesario que lo involucre demasiado en este punto. Al dar un paso al frente y tomar la iniciativa en esto, un buen gerente apreciará el hecho de que usted se preocupa y que ha tomado la iniciativa para ayudar a mejorar el equipo y la empresa, especialmente dado que su gerente puede carecer del conocimiento técnico para hacerlo. personalmente.
El primer paso es investigar y compilar los resultados. Identifique los problemas, tal como los ve, y explique cómo afectan negativamente a la empresa. Es completamente normal que una empresa en crecimiento tenga dificultades de esta manera, así que busque otros ejemplos y estudios de casos para respaldar sus afirmaciones. A continuación, tendrá que pensar en posibles soluciones. Sea minucioso al explicar los costos y beneficios. Tenga en cuenta que es posible que desee incluir a los miembros de su equipo aquí, ya que parece que ellos también tienen ideas, tanto con los problemas como con las soluciones. Solo asegúrese de mantener las cosas enfocadas y no deje que se convierta en una distracción.
Una vez que haya identificado algunos problemas y posibles soluciones sobre las que se puede actuar, le recomiendo convertirlo en una presentación. Programe una reunión con su equipo (jefe incluido). El objetivo de esta reunión es a) obtener retroalimentación yb) lograr que todos estén en sintonía. Al finalizar esta reunión, es fundamental que comience a planificar cómo implementar los cambios acordados y un cronograma para hacerlo. Si necesita la aprobación de un superior, aquí es cuando necesitará la ayuda de su gerente. En este punto, ha hecho el trabajo para ayudar a empoderar a su gerente menos técnico y, con suerte, le ha brindado las herramientas necesarias para poner las cosas en marcha.
Lo último es asegurarse de que lo que ha decidido como equipo se implemente realmente. Es probable que haya cosas sobre las que usted y los miembros de su equipo puedan actuar de inmediato y otras que puedan requerir cambios/compras/etc. más grandes que requieran la ayuda de la gerencia. Recomiendo programar una reunión periódica para verificar el progreso e identificar cualquier obstáculo que pueda estar deteniéndolo. La consistencia y la rendición de cuentas son claves para la implementación exitosa de estos nuevos procesos.
Una nota final: si no siente que ha estado en la empresa el tiempo suficiente para asumirlo personalmente, puede aplicarlo a un miembro senior del equipo o asumirlo como grupo. Modifique para requisitos particulares para caber sus necesidades.
Tome la iniciativa y encuentre y solucione un problema recurrente que tenga el equipo
Usted dice que todos los desarrolladores están de acuerdo en que la forma actual de hacer negocios no funciona, pero nadie está de acuerdo en qué hacer. Debe encontrar una cosa que haya sido un problema recurrente e implementar una solución.
Hable con otros desarrolladores que conozca y obtenga al menos 3 o 4 de ellos a bordo con su plan. Entonces ejecuta tu plan. Una vez hecho esto, cuéntaselo al resto del equipo y a tu jefe.
Cuando le diga a la gente lo que ha hecho, concéntrese en el hecho de que está perdiendo el tiempo debido a un mal proceso. Algo como...
Después de perder el evento/fecha límite XYZ, decidí solucionar este problema. El problema del problema de inserción me puso en una posición realmente mala en la que tuve que perderme un evento/fecha límite importante de la vida. Realmente me gustaría escuchar lo que todos piensan de esta solución.
Strader
Dan
Strader
Dan
Mawg dice que reincorpore a Monica