En mi opinión, el artículo
"Los jefes de los chupasangres en el contexto ..." no reveló la razón del desglose de los equipos autónomos, pero la razón fue la baja velocidad de distribución de los requisitos del producto y la falta de comprensión de que el líder siempre es parte del equipo.
Al cambiar el enfoque para planificar el departamento de diseño durante el desarrollo de un nuevo producto, puede aumentar la velocidad con la que se distribuye la información, que es mucho más importante para un proyecto que simplemente tener información.
Diseño clásico
En el esquema clásico, el proceso de planificación del trabajo y el proceso de desarrollo tienen plazos claros. Por lo general, el proceso de planificación tiene lugar antes del desarrollo. Al final de la planificación de cada mes, aparece un "programa de trabajo de red", según el cual comienza el proceso de desarrollo de productos por parte del departamento de diseño. No hay muchos tipos de gráficos de red, principalmente
PERT y
GANTT . Los términos en el cronograma de la red generalmente son declarativos y no están respaldados por nada, lo que crea un alcance imaginario cuando el departamento de diseño y desarrollo realiza un trabajo en el proceso de desarrollo. De hecho, los plazos en el cronograma de la red se acuerdan con el cliente y el contratista se ve obligado a cumplirlos; de lo contrario, el incumplimiento de los plazos clave de desarrollo podría amenazar el cierre del proyecto en su conjunto. Nadie pregunta a los desarrolladores en el esquema clásico, y el gerente de proyecto simplemente reduce los plazos para cada trabajo a los desarrolladores.
Por un lado, parece que el gerente del proyecto les está dando a todos una especie de caña de pescar (herramienta) y dice: “Atrapa mientras se hace la carpa cruciana. A finales de mes iré y comprobaré cuántos han sido capturados. Necesitamos atrapar 2 toneladas ". Durante el mes, el gerente del proyecto celebra reuniones en las que informa quién, cuántas toneladas y qué tipo de pescado pescó. A finales de mes, el gerente del proyecto publica un nuevo cronograma de red "actualizado", según el cual el cliente quiere capturar no la carpa cruciana, sino por ejemplo
"calabacín" . El "administrador de proyectos sabio" tiene la oportunidad de obtener una bonificación por comprar un nuevo plasma o un nuevo SUV moderno. Si tiene suerte y habrá al menos uno que atrape “peces calabacín”, se pagará una bonificación a sí mismo y al pescador afortunado, y pagará una multa a los demás.
Este modo de operación obliga al gerente del proyecto a asumir algunas de las tareas de desarrollo por sí mismo, y los desarrolladores de dicho proyecto están constantemente retrasados en el trabajo, y a veces tienen que ir los fines de semana para poder desarrollar nuevas interfaces de interacción de usuario con el producto a tiempo. Todo esto, como mencioné anteriormente, se ve agravado por el hecho de que los requisitos para el producto final pueden cambiar, y luego se ajusta el cronograma de la red, y el ajuste se realiza de tal manera que no afecte las fechas clave del proyecto.
En tal esquema, todo el trabajo depende del factor humano, que juega un papel clave. El factor humano puede minimizarse mediante la introducción de sistemas automatizados de planificación y desarrollo, que, en esencia, muchas personas hacen implementando
CAD ,
CAM ,
CAE ,
PDM ,
ERP ,
CRM ,
PLM , etc. en sus empresas.
Sin embargo, la base en forma de un esquema clásico, cuando la planificación y el desarrollo tienen límites de tiempo claros, permanece sin cambios. Como resultado, los desarrolladores deben mantener actualizadas numerosas ediciones del producto de software y la documentación en cada sistema automatizado, así como también apoyar constantemente la integración del sistema, lo cual es muy problemático en las condiciones competitivas actuales del mercado de TI. En última instancia, el cliente solo necesita una cosa: el producto terminado o la producción optimizada. En el esquema clásico, la lista de documentación desarrollada por el contratista siempre será redundante, ya que ni el cliente ni el contratista tienen plena confianza en que se alcanzará el objetivo, lo que significa que es necesario documentar el proceso al máximo para identificar a quién "culpar" por incumplimiento de los plazos. Incluso si el objetivo final se formula inicialmente como específico (específico), medible, alcanzable, realista y basado en el tiempo, como resultado, después del primer requisito adicional, el artista puede perder la confianza alcance del objetivo final y, por lo tanto, habrá un desglose de los plazos y el cierre del proyecto.
Entonces, ¿cómo asegurarse de que el cliente no cambie los requisitos con demasiada frecuencia y que el contratista cumpla con todos los requisitos del cliente a tiempo?
En el esquema clásico, el proceso de planificación lo lleva a cabo un experto experimentado en el campo de la planificación de proyectos, quien, según su experiencia, determina la lista de tareas y sus términos. Creo que todo esto no puede ser realizado por un experto experimentado, porque el equipo en sí puede determinar el momento de las tareas, así como la lista de tareas necesarias para completar. Para esto, el experto por parte del cliente debe describir el producto lo más detallado posible en su
TK y la fecha límite en la que se necesita el producto, ¡y eso es todo! El equipo, bajo la guía del gerente del proyecto, puede llevar a cabo la planificación del trabajo, identificar las dificultades, descomponer las tareas, en resumen, todo el trabajo que realiza un experto experimentado.
El "problema" es que, en este caso, cada miembro del equipo conoce el objetivo final, es transparente y en cada momento se sabe a qué distancia está el equipo. El "gerente de proyecto inteligente" no podrá incluir su mega-objetivo en este objetivo: "comprar un SUV moderno". Para que logre el 100% de su meta meta con éxito, necesita separar los procesos de planificación y desarrollo, y entregar listas de tareas en lotes a medida que surgen "problemas". En este caso, la tarea del gerente de proyecto es desviar la atención del equipo hacia el objetivo final del proyecto tanto como sea posible, y centrar su atención en la solución exactamente a tiempo para el trabajo específico de la red. En otras palabras: "llenar el equipo con trabajo de rutina".
Un esquema de trabajo fundamentalmente diferente es un esquema de trabajo que utiliza metodologías de desarrollo flexibles, donde el principio principal es:
frecuentes entregas continuas de un producto de valor para el cliente.Esto se logra principalmente mediante la transparencia del proceso de planificación, cuando cada miembro del equipo conoce el objetivo final y participa en la formación del grupo de tareas durante las próximas 1-4 semanas, después de lo cual el cliente verá la primera versión del producto con una nueva funcionalidad. Es responsabilidad del gerente del proyecto obtener la aprobación del cliente o simplemente notificarle la versión del producto con la nueva funcionalidad, que estará lista después de la finalización de la iteración. Todos los requisitos adicionales que provienen del cliente deben tenerse en cuenta al planificar el equipo del grupo de tareas en las siguientes iteraciones.
Para no desviarse del camino para lograr el objetivo final, el equipo se reúne todos los días para manifestaciones de 15 minutos, en las que cada miembro del equipo responde tres preguntas:
- ¿Qué se ha hecho desde la reunión anterior?
- ¿Qué se hará para el próximo rally?
- Cuales son los problemas?
Sin embargo, en el caso de que la planificación se realice por separado del desarrollo, el gerente del proyecto da la respuesta a la segunda pregunta, al igual que la respuesta a la tercera.
Al final de cada iteración (sprint), el equipo demuestra el producto con una nueva funcionalidad para el cliente. Después de cada demostración, el equipo se reúne por separado del cliente para realizar una retrospectiva. Hay muchos métodos para realizar retrospectivas, quiero señalar una retrospectiva en el estilo "PLUS / DELTA", en el que cada miembro del equipo expresa 10 puntos positivos (PLUS) y diez puntos que hicieron que el equipo se desvíe (DELTA) del logro del objetivo previsto.
En el esquema de trabajo que utiliza técnicas de desarrollo flexibles, los sistemas automatizados juegan un papel clave, permitiéndole obtener un producto con la nueva funcionalidad más avanzada al final de la iteración. Después de cada iteración, el producto puede enviarse para su desarrollo tecnológico en sistemas
ERP o
CRM para comenzar a producir un prototipo de producto para probarlo en condiciones lo más cercanas posible a las reales. Por lo tanto, después de cada iteración, el producto de software se refina y se crean nuevos requisitos funcionales. Los propios clientes que ya se encuentran en la etapa de desarrollo tecnológico o en un proyecto piloto a través de comentarios en el sistema
CRM expresarán requisitos en los que ni siquiera pensaría. Lo principal es llevar estos requisitos a los desarrolladores a tiempo, y no esconderlos en sus propios pasillos de la mente, como a veces hacen los "Administradores de proyectos sabios".
Sacar conclusiones
Los intentos de construir el proceso de desarrollo de acuerdo con el esquema clásico usando metodologías flexibles usualmente fracasan, y ver a muchos gerentes de proyectos por sus "megaceldas" o simplemente siguiendo automáticamente el principio fundamental de "divide y vencerás" se niega a aplicar los conocimientos modernos de gestión de proyectos en la práctica.