Trabajo para una empresa que experimenta un rápido crecimiento, con más crecimiento proyectado en el futuro. Actualmente usamos generalistas que pueden trabajar en múltiples proyectos para una mejor comunicación, trabajo en equipo y maniobrabilidad.
Incluso con los generalistas, algunos miembros terminan con conocimiento de dominio concentrado en ciertos proyectos, por lo que algunos ejecutivos están considerando cambiar a equipos de proyecto dedicados más pequeños que se convertirán en especialistas en un área específica como una extensión natural de ese conocimiento de dominio y el crecimiento de la empresa. .
Mi problema es que esto sería un gran cambio para el estilo de trabajo que hacemos, y no quiero sacrificar la comunicación, el trabajo en equipo y la maniobrabilidad si es posible.
Al trabajar en proyectos a gran escala (piense en desarrollar Excel o el equivalente), ¿cómo puede mantener el mismo nivel de comunicación, trabajo en equipo y maniobrabilidad entre los equipos del proyecto?
La respuesta corta es "no mantienes el mismo nivel de comunicación".
Para usar su ejemplo, es una apuesta bastante justa que las personas que desarrollan Excel nunca serán llamadas para contribuir con los controladores de dispositivos.
Para que un generalista sea útil en múltiples proyectos, es importante mantenerse actualizado en esos proyectos: conocer las tecnologías, conocer a las personas, conocer los problemas, conocer las soluciones a problemas anteriores, etc.
En algún momento hay demasiada información para mantenerse al día. Su generalista tendrá demasiada amplitud/no suficiente profundidad para seguir siendo útil.
Cambiar a equipos dedicados permitirá que esos equipos permanezcan completamente enfocados en su área de interés. Están sacrificando amplitud para ganar (o al menos mantener) profundidad.
Mis principales preocupaciones serían:
Desde un punto de vista organizativo, cambiar a esta estructura podría ser increíblemente perjudicial para los proyectos actuales. (He visto que esto sucedió al menos dos veces y los clientes estaban muy descontentos). ¿Hay alguna ganancia que pueda compensar esta interrupción? Este tipo de cambio afectaría los plazos, afectaría la capacidad de entregar el producto (algunas personas terminarán en proyectos con los que no están muy familiarizadas) debido a que tienen que aprender el nuevo proyecto. También es increíblemente arriesgado, ya que algunas cosas pueden perderse en la confusión ya que las personas actualmente asignadas para hacerlo se trasladan a otros proyectos. ¿Cuál sería el plan? ¿Hay alguna manera de hacer un cambio por fases?
Si hay menos polinización cruzada, ¿estará en problemas si alguien clave en un proyecto acepta otro trabajo? Los desarrolladores tienden a moverse. Tener menos personas que conozcan los detalles de los proyectos podría ser costoso. Si estamos hablando de equipos de proyecto de 5-10, eso podría no ser un problema, pero si los equipos terminan como 1-2 en un proyecto en particular, podría serlo.
Si divide a las personas en líneas de productos específicas, ¿está limitando su capacidad de adquirir nuevos conocimientos (algo imprescindible para la mayoría de los buenos programadores) y, por lo tanto, obligando a los mejores a irse para mantener sus calificaciones profesionales? Cuantos más proyectos tenga utilizando tecnología más antigua, peor podría ser.
¿Qué tan fácil será transferir a otros proyectos? Una vez que llegas a ser experto en un proyecto, las posibilidades de moverse se reducen mucho. Entonces, si los desarrolladores sienten que estás perjudicando sus carreras, se irán en masa y perderás gran parte del conocimiento actual. Como mínimo, necesitará un plan para permitir las transferencias a otros proyectos y una forma de superar los problemas de "No puedo renunciar a él porque es el único que sabe...". La progresión profesional es importante, cuanto más personas especializadas en proyectos son, más difícil es ascender también. Necesitas un plan para manejarlo. Podría considerar mover entre el 5 y el 10 % de los desarrolladores cada año y establecer como requisito que se permita a todos cambiar las líneas de productos al menos una vez cada 5 años. Esto podría ayudar a forzar la polinización cruzada, brinde a las personas la oportunidad de obtener nuevos tipos de experiencia y mantenga la mayor parte del equipo relativamente estable. El tiempo de aceleración debe figurar en los planes del proyecto porque sabe que obtendrá algunos desarrolladores nuevos cada año. También ayudaría a evitar que los gerentes confíen demasiado en una sola persona, ya que saben que eventualmente será transferida. También puede asegurarse de que las personas puedan solicitar nuevas vacantes sin tener que contar con la aprobación de su jefe actual (para evitar que las personas acumulen).
Le preguntaría a su jefe qué espera ganar para compensar los posibles problemas (estoy seguro de que, estando en la situación actual, puede pensar en más de lo que yo podría pensar. Probablemente también pueda ver cuáles podrían ser los beneficios).
También debe tener en cuenta que es posible que tenga especialistas que deban seguir siendo multifuncionales sin importar qué. O ibas a contratar 7 especialistas en inteligencia de negocios (1 por proyecto) en lugar de los 2 que tienes (por ejemplo). La mejor apuesta podría ser hacer una organización híbrida en la que algunos estén aislados y otros no.
Incluso podría hacer un análisis de costo-beneficio que cuantifique los riesgos y las recompensas de ambas posibilidades para que pueda ver cuál sería el impacto.
Si un desarrollador escribe 10 000 líneas de código al año y un equipo de 5 personas trabaja en un proyecto durante 18 meses, se podría esperar que el proyecto tenga 75 000 líneas de código cuando entre en producción. Si permanece en producción durante diez años, probablemente se expandirá a 250.000 líneas durante ese tiempo. Este es un caso altamente hipotético centrado en un sitio web o en un software de suscripción; no se aplicaría necesariamente al control integrado.
100 000 líneas de código divididas por 50 son aproximadamente 2000 páginas, por lo que cualquier desarrollador involucrado en un proyecto maduro debe tener el equivalente a 2000 páginas de instrucciones en su cabeza. Si está distribuyendo personas entre varios proyectos, multiplique esto por la cantidad de proyectos que están asignados para realizar un seguimiento.
Esto podría funcionar si tiene personas que operan en roles muy miopes, nada más que servicios de datos o ciertos tipos de informes resumidos o coherencia de la interfaz de usuario en varios productos. Sin embargo, si desea que algunas personas comprendan a fondo una aplicación determinada, deberían hacerlo a tiempo completo. 'Cross funcional' es una seria dilución de esfuerzo.
jmort253