El papel de PM-a siempre está ahí, y si no se asigna a un individuo con la capacitación necesaria, se redistribuye.
A quien?- Todos los miembros del equipo por igual.
- Un miembro del equipo que está listo para combinar esto con su función principal.
- Una persona de afuera, que realmente no participa en el proceso, pero de alguna manera controla.
Todas estas opciones son muy reales y se encuentran en la práctica, especialmente en empresas jóvenes que aún no tienen una estructura y procesos.
Tenga en cuenta las siguientes preguntas:- ¿Quién se comunica con el cliente?
- ¿Quién tiene en cuenta la imagen completa del proyecto? Un mejor documento.
- ¿Quién organiza el proceso?
1. El papel del gerente es compartido por todos , y el equipo tiene una experiencia promedio, será difícil. La gente no sabrá qué hacer, y tomará mucho tiempo recuperarse. El costo agregado de sus horas de discusión irá rápidamente al cielo. Y no el hecho de que se alcanzará un compromiso.
También es necesario poder comunicarse con el cliente; incluso con lo adecuado, con lo inadecuado, a veces es más difícil. Alguien está impaciente con las preguntas y declaraciones de un cliente ignorante, alguien no comprende su negocio en absoluto y por qué necesita un producto. Las actividades y las alegrías también están llenas de problemas, y a los desarrolladores simplemente no les gusta hacer esto, lo que significa que lo hacen de manera mediocre. No olvides que alguien debería controlar todo.
Tal esquema solo funciona con especialistas muy hábiles que están más involucrados en todo el proceso y son capaces de comprender el negocio, los objetivos del proyecto, sus tareas dentro del mismo y no necesitan control, ya que están censurados por ellos mismos. Creo que todos estarán de acuerdo en que hay pocos desarrolladores de este tipo y que están trabajando.
2. Uno de los programadores : de inmediato, ¿podrá comprender adecuadamente los requisitos comerciales y traducir a sus luchadores a un lenguaje comprensible? Después de todo, debes admitir que una persona no entiende las cosas: pasa por alto sus oídos, pero el desarrollador promedio no entiende muchas cosas en los negocios, ya que su esfera no es para nada, y a menudo simplemente no es interesante. Luego explicará brevemente a sus hijos: lo que se necesita, todos nuevamente lo entienden a su manera y el resultado es un completo fracaso. Debido a que necesita poder entrevistar a un cliente, también debe poder explicarle a los demás, y también es necesario moler y pegar al equipo con las personas.
La combinación de los roles de Timlid y PM solo puede ser un especialista muy bueno que sepa cómo entender al cliente, administrar, comunicarse y, por supuesto, programar. Un conjunto serio, pocas de esas personas son excepciones.
3. Una persona que no está profundamente inmersa en el proyecto es la peor opción, en mi humilde opinión. A menudo simplemente no tiene tiempo para esto, recogió un pedido en la ocasión a través de comunicaciones, buen dinero, encontró un equipo de técnicos, y se fue. Paralelamente, él, por regla general, tiene una lección más importante.
Como resultado, los técnicos no tienen idea de qué hacer y no vuelven a preguntar: están aserrando algo. Él mismo no tiene idea de lo que están desarrollando, ocasionalmente verifica, pero básicamente nada sale de la prueba. Generalmente estoy en silencio sobre el cliente. Esto se debe a que, en el 80% de los casos, estos proyectos recaen en autónomos independientes que no saben cómo y / o no quieren trabajar juntos con alguien, y que realmente no saben cómo hacer algo complicado, donde no pueden hacerlo solos, porque prácticamente no existen proyectos de este tipo en los intercambios. En consecuencia, no habrá un equipo autoorganizado de tipos duros. Habrá un grupo de solteros incomprendidos. Tiene suerte si consiguen un líder que pueda reunirlos. Y entonces esto no es inmediato y sin garantías.
Entonces, ¿por qué PM?
El primero es tener en cuenta toda la imagen y documentarla a tiempo desde el punto de vista del diseño. Los miembros del equipo necesitan resolver los detalles, y el proyecto en general a menudo se les escapa. Es difícil pasar constantemente de lo privado a lo general y viceversa. Pero el gerente está obligado a hacer esto, y lo mejor que pueda, para responder todas las preguntas.
El segundo es ser una sola persona de contacto para todos. Toda la información debe pasar a través de ella, de lo contrario el desastre comenzará de inmediato. El cliente estará de acuerdo con un desarrollador individual, o le presentará errores, no le dirá a nadie, los errores se relacionan con otros y de vez en cuando.
Reclamos adicionales: el gerente también es un pararrayos, escucha, acepta todos los reclamos y, de forma constructiva, los transfiere al equipo, sabiendo a quién y cómo influir. Hay casos frecuentes en los que las piedras vuelan hacia un programador en particular, y ese del shock inicial comienza a hacer cosas estúpidas: hablar demasiado, derribar a otros, atacar en respuesta, huir.
El tercero es resolver problemas. Y esto no es si aparecen, sino cuando aparecen. Porque aparecerán con seguridad. Después de todo, debe planificar claramente todo, monitorearlo, luego probarlo, arreglarlo, mostrárselo al cliente, obtener el dinero, contar las horas de cada uno, idealmente, también realizar un informe. En todas estas cosas, surgen colisiones que deben ser advertidas o resueltas en el camino. Es decir, para construir el proceso inicial y determinar las reglas del juego, continuar resolviendo problemas actuales e introducir nuevas reglas si es necesario.
Por cierto, sin conocimientos especializados en gestión es bastante difícil de hacer.
A nivel mundial, usted recibió capacitación preliminar en esta área, o probó todos los rastrillos en usted mismo y salió como un gerente derrotado en golpes. Por supuesto, la educación del perfil de todos los rastrillos no se eliminará, pero en parte, y la velocidad de dominar la experiencia será mucho mayor.