En los últimos 10 años con la difusión de Agile, he visto a los desarrolladores asumir cada vez más responsabilidades en la creación del software. Por lo general, las decisiones de implementación son un trabajo de equipo y ya no una tarea de una sola persona. Pero… ¿todavía hay hueco para los directivos?
Ahora estoy iniciando mi propia empresa y comencé a formar un pequeño equipo, y es interesante notar que cuanto más hábil es un desarrollador, más pretende tener algo que decir en la implementación. Sin embargo, considerando que la inversión es mía, me gustaría tomar decisiones importantes sobre la implementación yo mismo. Hoy esto se ha vuelto imposible sin molestar a la gente. ¿Hay una solución a todo esto? ¿O debo limitar mis decisiones a la funcionalidad y dejar todos los detalles de implementación al equipo?
La regla de oro es "el que tiene el oro hace las reglas". Sin embargo, eso no significa que el que hace las reglas tenga necesariamente la razón o esté actuando en su mejor interés. Puede tener lo que desea, pero es posible que no lo lleve a donde realmente necesita ir.
Estoy comenzando mi propia empresa y comencé a formar un pequeño equipo, y es interesante notar que cuanto más hábil es un desarrollador, más pretende tener algo que decir en la implementación. Sin embargo, considerando que la inversión es mía, me gustaría tomar decisiones importantes sobre la implementación yo mismo.
Si bien su pregunta podría ser más adecuada para The Workplace , ciertamente hay gerentes de proyecto (sobre el tema aquí) y dueños de negocios (fuera del tema aquí) que tienen preocupaciones similares. Sin embargo, el problema es más a menudo una definición de roles y rasgos de personalidad que cualquier otra cosa.
Sin pretender ser peyorativo, su declaración citada arriba es bastante común entre las personas que son:
No hay absolutamente nada de malo en querer que un producto o servicio sea vendible y adecuado para su propósito, pero incrustada en su declaración está la creencia implícita de que no se puede confiar en que otros implementen algo de la manera en que lo haría usted mismo. En lugar de medir los resultados (p. ej., el software funciona y es fácil de mantener), se centra en la implementación, que suele ser un antipatrón comercial.
El principal problema de ser un "fanático del control" en una industria basada en el conocimiento como la TI es que aleja a las personas creativas y talentosas. La microgestión sofoca la innovación y el pensamiento independiente. Las únicas personas que tolerarán la gestión basada en el miedo, un entorno en el que una figura de autoridad quiere controlarlo todo, suelen ser aquellas que prefieren un estilo de gestión altamente directivo porque no son emprendedores o trabajadores que son personas temerosas. Por lo general, esto da como resultado un "equipo" en el que las personas hacen solo lo que se les dice y nada más. Pragmáticamente, esto a menudo da como resultado un desarrollo más lento y menos innovación porque el microgestor realmente está haciendo todo el trabajo, pero con el costo adicional de tener que delegarlo y luego verificarlo.
Los marcos ágiles tienen principios y valores que apuntan a resolver muchos de estos problemas reemplazando técnicas ineficientes de comando y control con procesos colaborativos, desarrollo iterativo, ciclos de retroalimentación de control de calidad y equipos autoorganizados que valoran (en lugar de sofocar) soluciones creativas que puede que no hayas pensado en ti mismo. Definitivamente hay casos de uso para enfoques más directivos, pero su publicación original no es realmente uno de ellos.
Al final, como gerente de proyecto o propietario de la empresa, puede contratar por adecuación cultural. Si prefiere contratar a personas que no sean ágiles, o que prefieran un estilo de gestión más directivo, está bien. Sin embargo, eres dueño del proceso de entrevista y selección, y también eres dueño en gran medida de los resultados de elegir buenas o malas contrataciones.
En otras palabras, si contrata personas basándose principalmente en su voluntad de ser administrado de cerca, entonces no puede quejarse de que no son personas que disfrutan trabajar de forma independiente. Por el contrario, si contrata a personas con iniciativa propia, no debe quejarse de que aportan sus propias perspectivas para resolver un problema.
Ningún extremo es bueno para el desarrollo, los negocios o la formación de equipos. Su trabajo es identificar el mejor equilibrio de colaboración e independencia para sus objetivos, y luego seleccionarlo deliberadamente en su proceso de contratación. Cometerá errores, porque todo el mundo lo hace, pero si no está atrayendo el talento que desea o si no está haciendo malas contrataciones constantemente, entonces necesita inspeccionar y adaptar su cultura organizacional y estilo de gestión en lugar de culpar a los demás.
El movimiento ágil surgió debido a que muchos, muchos proyectos de software fallaron, no cumplieron con sus plazos o los costos se dispararon. Todas las partes (clientes, desarrolladores e incluso algunos gerentes) estaban insatisfechas con la forma en que se ejecutaron los proyectos (consulte: agilemanifesto.org/history.html ). Trabajar juntos como un equipo hace que el software sea mejor , las decisiones de implementación deben tomarlas quienes lo hacen (además de estimar el esfuerzo). ¿Tal vez tus colegas piensen en otras cosas que podrías olvidar? 8 ojos pueden ver más que 2, es una ventaja discutir los detalles de implementación. ¿No creo que quieras estúpidos "Code Monkeys"?
Como gerente (o propietario del producto o como quiera llamarlo; sé que no son exactamente lo mismo), la tarea es descubrir qué necesitan los usuarios de su software y explicar el valor del cliente al equipo. Las historias de usuario, por ejemplo, pueden no contener detalles de implementación y eso es algo importante, ya que deben cumplir con los criterios de INVEST .
En Scrum hay reuniones en las que usted, supongamos que es el PO, puede contribuir con su opinión sobre los detalles de implementación (en este punto, algunos pueden estar en desacuerdo), pe Desglose de tareas. Para mí, el hecho clave es que confíes lo suficiente en tu equipo como para dejarles tomar sus propias decisiones y no dictar soluciones.
Puede comenzar con un Sprint Zero , donde se toman algunas decisiones arquitectónicas y puede discutirlas con sus compañeros de equipo. Mientras que Sprint Zero no es recomendado por todas las organizaciones de Scrum (Mitos de Scrum: Está bien tener un Sprint 0, Design Sprint, Hardening Sprint... )
A medida que el proyecto crece (supongo que ese sería el objetivo), no podrás conocer todos los detalles, por lo que TIENES que dejar que el equipo tome sus propias decisiones.
Como hombre de negocios, no me importa la implementación técnica a menos que afecte mi billetera. Me reservo el derecho de decirle al equipo: "No. No voy a pagar por eso. ¿Cuáles son las otras opciones?", pero, sinceramente, no me importa cómo hacen el trabajo. Lo único que me importa es que lo hagan de manera oportuna y rentable. Voy a contratar gente para hacer un trabajo y confiar en ellos para que lo hagan.
Si no confío en los técnicos para tomar decisiones técnicas, entonces, ¿por qué los contraté para empezar? No es mi trabajo tomar esas decisiones. Es mi trabajo establecer una visión, objetivos y estrategias para alcanzarlos. Es su trabajo implementar, déjenlos implementar. Ellos son los expertos, no yo. Lo entiendo, independientemente del hecho de que también soy desarrollador de software y podríahacen su trabajo, que no entiendo los detalles tan bien como ellos y probablemente me interponga en su camino. Si me interpongo en su camino, ralentizaré las cosas, desmoralizaré al equipo y perderé a mis mejores desarrolladores. ¿Harán las cosas de manera diferente a como lo haría yo y cometerán algunos errores? Claro, pero haría más porque no estoy tan íntimamente familiarizado con el espacio problemático como ellos. Involucrarse demasiado en la implementación no me hace ningún favor a mí mismo, a mi equipo y a mi empresa.
Dicho esto, eres el hombre que firma el cheque de pago. Es tu empresa y tienes derecho a hacer lo que te gusta. Sin embargo, si quieres tener éxito, dejaría que el equipo hiciera lo que les pagas.
Agile (y muchos métodos propuestos) tiene su raíz en el pensamiento lean , y si comenzamos a retroceder, puede encontrar tal relevancia en TQM (incluida la enseñanza de Deming) y TPS (lo que estudiaron Womack y Jones).
No puedo darle una respuesta directa de lo que puede hacer, pero mi favorito personal para convertirme en un mejor gerente es leer Gestión del lugar de trabajo del genio de la fabricación de Toyota, Taiichi Ohno. Su enseñanza pone una gran cantidad de énfasis en los líderes en el gemba haciendo kaizen (mejora continua). El libro viene con un artículo de Jeffrey Liker, que de alguna manera resume las responsabilidades de un gerente: 1) aprender en el gemba, 2) adelantarse a sus alumnos, 3) mantener un alto estándar, 4) amar a sus alumnos, y 5) ser apasionado y obsesionado con kaizen.
Dicho esto, su presencia como maestro (o gurú, o líder de servicio, como algunos lo llamarían) en el taller para aprender junto con la gente, como preguntar los 5 por qué , en lugar de dirigir, generará una mayor confianza y una cultura más positiva.
MCW
ppasler
Todd A. Jacobs
ppasler