Tenga en cuenta que no hay ningún signo de interrogación en el título. No quiero discutir si se necesitan gerentes de proyecto en el desarrollo de software moderno o no. La práctica muestra que no. Solo estoy tratando de entender por qué sucedió.
Después de haber trabajado durante más de 20 años en la industria de TI, comencé a construir cada nuevo desarrollo desde la oficina del proyecto. Además, varias veces tuve que explicarle a la gerencia por qué contratar piems. Con los jefes de departamento, no es tan fácil explicar a las personas que no están directamente involucradas en el desarrollo de software qué harán exactamente los gerentes de proyecto. Tuve que superar una notable resistencia.
Pero para mí fue un axioma que la oficina del proyecto y los gerentes del proyecto son la base del éxito. Y cuéntame a alguien hace unos cinco años que no se necesitan gerentes de proyecto, discutiría con él hasta el final.
Nota del editor: este texto es el resultado de un informe de Dmitry Kruglov de la llegada al mitin de Piemnaya.
¿O todavía necesitas
Comencemos tratando de proteger esta profesión. Aunque solo sea porque se han logrado los resultados en los últimos lugares de trabajo, incluso gracias a las oficinas de proyectos construidas con éxito.
La gestión de proyectos no es prerrogativa de TI. Esta es una ciencia que tiene más de 50 años. Una ciencia que tiene su propio libro sagrado . Por supuesto, PMBoK no es único, hay PRINCE y, probablemente, varios libros más que afirman más o menos los laureles. Pero PMB®K es la base de los estándares internacionales y esto indica su alto nivel de reconocimiento. Así que lo desarrollaremos.
Juguemos: si trabaja como gerente de proyecto, intente, sin mirar hacia el futuro, recordar sus principales áreas de actividad desde el punto de vista de un estándar internacional y un instituto que tiene más de 50 años.
Por ejemplo, gestione los requisitos del proyecto. O gestionar las expectativas. Quizás te acuerdas de la gestión del tiempo. Seguramente, los colegas que representan a la empresa preguntan regularmente cuándo exactamente esta o aquella tarea estará lista. Tal vez recuerde la gestión de las partes interesadas, que es mucho menos común. Que mas Gestión de comunicaciones. Este último es tan raro como las partes interesadas. Pero esta es una tarea importante y difícil en nuestro tiempo, cuando todos los participantes del proyecto prefieren compartir información importante en Telegram, en lugar de los correos electrónicos requeridos por el borrador del estatuto. ¿Cómo puede gestionar las comunicaciones si simplemente no lo invitan a un chat en el que discuten, por ejemplo, la calidad de su trabajo?
Compare lo que recordó con la lista de PMBoK:
Todos los artículos son muy cuerdos. Parece que esta actividad realmente debe ser realizada por cada gerente de proyecto. Algo de esto puede ser menos obvio, como la integración de proyectos. Pero si utilizó el poder de varios equipos para crear una característica realmente grande, que necesita reunir antes del lanzamiento, entonces comprende de qué se trata este punto. Por cierto, la tarea de desarrollar una funcionalidad en varios equipos en paralelo aún no se ha resuelto sistemáticamente.
Diagrama de Gantt
Si hay una actividad, debe haber su resultado. Mi opinión personal es que el trabajo se realizó con el artefacto apropiado. Para un programador, este es un código de trabajo. Para un especialista en pruebas, scripts de prueba desarrollados o ejecutados, errores introducidos en el sistema o pruebas automáticas creadas. Para el diseñador - diseños gráficos.
¿Qué es un artefacto de gerente de proyecto? De todos los artefactos posibles, incluidos los mensajes en el Telegrama: "Agrégame, finalmente, a tu chat, ¡no puedo administrar el proyecto sin él!", Primero notaría el diagrama de Gantt. Esta es una gran herramienta que puede responder muchas preguntas sobre el proyecto y ayuda a visualizar la mayoría de las áreas de actividad del gerente del proyecto. Después de todo, un buen diagrama de Gantt contiene tiempos, recursos, costos y dependencias. Allí puede agregar requisitos de comunicación como tareas. Incluso puede agregar control a las partes interesadas y sus expectativas con hitos y una descripción del resultado esperado. Resulta una herramienta universal para todas las ocasiones.
La mayoría de las tareas en estas áreas se resuelven a través de la administración de una entidad: el diagrama de Gantt.
Su popularidad y versatilidad se confirman por la cantidad de herramientas y servicios que le permiten crear sus diagramas. Intente buscar "Gantt en línea" y vea cuánto dura la lista de enlaces para cada gusto y color.
Lo que resulta: tenemos una profesión, tenemos una actividad y tenemos un buen artefacto, como resultado. Entonces, ¿cuál es el problema?
Se trata de los matices. Por ejemplo, con Gantt, no todo es tan bueno.
Primero, los diagramas de proyectos grandes tarde o temprano se vuelven ilegibles. Tenía experiencia trabajando con un proyecto de "más de un año" en Microsoft Project. Para imprimir su plan, era necesario pegar seis hojas de A4. En una hoja, el texto era demasiado pequeño.
En segundo lugar, los diagramas de grandes proyectos requieren mucho trabajo para su mantenimiento. Los cambios a menudo solo pueden ser realizados por el propio autor, de lo contrario el plan se desmorona debido a un complejo sistema de dependencias.
En tercer lugar, debe admitirse que nadie, excepto muchos de los gerentes de proyecto, leen muchos diagramas. Resulta que este artefacto fue producido por el primer ministro y él solo lo necesita y lo comprende.
En el desarrollo de software moderno, Gantt, en su mayor parte, fue abandonado. Dejamos de usar este artefacto para crear un producto, ¿realmente necesitamos su autor?
Si intenta buscar en Google el tema de la utilidad de los gerentes de proyecto en TI, queda claro que esta discusión ha estado ocurriendo durante mucho tiempo. Se las arregló para convertirse en otra holívar, como la confrontación entre los amantes de iOS y Android, Windows u OS X. Solo las citas en los resultados de búsqueda son aún más emotivas: "¿Necesitamos PM?", "¿Por qué decidimos deshacernos de los PM?" ¿El trabajo de PM no tiene valor?
No pretendo decir que el equilibrio en la disputa global está a favor de rechazar a PM, pero al menos el número de partidarios de este punto de vista es significativo.
Metodologías ágiles
Al comenzar a trabajar en una empresa donde tengo la tarea de construir un equipo de desarrollo desde cero una vez más, me di cuenta de que durante los próximos seis meses a un año no tengo tareas para PM. Al principio lo agregué a la estructura organizacional por costumbre. Y luego golpeó con su propia mano. Tachado intuitivamente, pero se preguntó: "¿Por qué sucedió?".
Mi investigación sobre los motivos me llevó a comprender que TI tiene una serie de cualidades únicas que permitieron la implementación de metodologías flexibles. Hay una comparación clásica: construir una casa y desarrollar software. Estas son disciplinas algo similares, no sin razón en ambas hay un papel del arquitecto. Tanto allí, como existe un conjunto de requisitos funcionales y no funcionales, hay infraestructura, comunicaciones internas, montaje, entrega e integración.
Pero la construcción se lleva a cabo en el mundo real y tiene un ciclo de producción muy largo y costoso hasta la primera prueba, antes de recibir la primera respuesta, antes de recibir el resultado. El precio de un error en la construcción es muy alto.
El producto de TI es digital. Y el ciclo de producción puede ser muy corto. Durante dos décadas, pudimos crear herramientas y tecnologías que condujeron al surgimiento de metodologías de desarrollo flexibles. Aquí estoy listo para argumentar que una relación causal es solo esto: la capacidad de experimentar rápidamente y obtener un resultado funcional ha llevado a la aparición de metodologías sobre cómo hacer esto. Por supuesto, esta es una breve respuesta positiva, y las herramientas continuaron desarrollándose. Y luego nuevamente la metodología fue finalizada. Y así sucesivamente en una espiral, nos apresuramos hacia un tiempo de comercialización cada vez más corto.
Roles
Las metodologías ágiles se han convertido en el estándar de facto y han aportado nuevas funciones al proceso de desarrollo de software. Y estos nuevos roles comenzaron a quitar actividades y artefactos de los gerentes de proyecto.
Propietario del producto (PO)
Hay proyectos que tienen varios clientes, varios propietarios y varios tomadores de decisiones. PM para ellos es la persona que busca un compromiso. Los reúne a todos, ayuda a priorizar, se reconcilia. Él le dice a alguien: "No", alguien está presionando. Pero el negocio entiende que en una búsqueda continua de compromisos, los recursos se desperdician de manera ineficiente. El recurso más valioso se gasta sobre todo: el tiempo.
Por lo tanto, las metodologías flexibles hacen exactamente eso: le dicen a una persona del negocio algo en el espíritu: “Eres extremo por el dinero, el tráfico y la conversión. Y para ser honesto, no nos importa qué y con qué prioridad haga en el producto. Lo principal es que para fin de año la conversión aumentará del 1% al 1.1%, de lo contrario, el proyecto no será rentable ". Y la OP obtiene el derecho de tomar decisiones individualmente, determina la prioridad, crea los artefactos correspondientes (planes, hojas de ruta, requisitos) y toma un trabajo del PM.
Techlide (TL)
Hace unos diez años, TI comenzó a cambiar la arquitectura establecida.
Antes de estos cambios, las tecnologías y herramientas se creaban principalmente para la "arquitectura en capas": la capa de base de datos, la capa de proceso de negocio, la capa de agregación, la capa de cliente. Pero tan pronto como este enfoque se volvió clásico, tan pronto como las compañías adquirieron las capas correspondientes de departamentos, surgieron metodologías flexibles. Y todos decidieron por unanimidad que los “pasteles de hojaldre” eran malos y que era necesario formar equipos multifuncionales.
Por no decir que era una idea nueva. ¿Cómo se llaman los desarrolladores universales? Pila completa Uno de los desarrolladores mayores de 30 años en la entrevista dijo: "Yo era un desarrollador de full stack en un momento en que el término full stack no existía". Una vez estábamos todos completos, porque teníamos que hacer todo, incluida la administración de la base de datos y la configuración de la computadora del director.
Los equipos multifuncionales han traído un nuevo rol: los deslizamientos tecnológicos. Tehlid no solo presionó a los jefes de departamento, sino que también se hizo cargo de la parte técnica del trabajo de PM. En primer lugar, todo lo relacionado con la evaluación de la complejidad y el momento. En el momento de la transición a metodologías flexibles, muchos han aceptado el hecho de que el equipo de desarrollo debe evaluar los términos de su trabajo.
Analista de sistemas (SA)
Un analista de sistemas no es un rol nuevo, y muchas metodologías ágiles no. No pretendo decirlo con certeza, pero es posible que esté explícitamente disponible en SAFE. Pero SAFE, en general, es una metodología límite. Sin embargo, este papel es extremadamente útil e interesante. Al igual que un lubricante en un mecanismo complejo, le permite trabajar de manera silenciosa y suave. Un analista de sistemas es en parte el propietario del producto, en parte el arquitecto. Aclara y detalla los requisitos comerciales al nivel de características específicas. Los mejores analistas de sistemas pueden avanzar sus ideas y visión en ambas direcciones, utilizando una combinación de conocimientos técnicos y habilidades blandas. Cuando los analistas de sistemas trabajan, el gerente del proyecto se ve privado de las actividades de gestión de requisitos.
Scrum Master (SM)
Scrum Master exprimió enormemente el papel de gerente de proyecto. Es una pena que ahora las propias SM se hayan convertido en candidatas para la extinción.
En serio, tarde o temprano Scrum Master enseñará en las escuelas. Habrá lecciones sobre Agile, donde Scrum Master les dirá a los estudiantes de 12 años cómo funcionan las metodologías ágiles y qué prácticas existen. La experiencia ágil se ha convertido en una experiencia de desarrollo ubicua. En una entrevista, 19 de cada 20 personas trabajan en iteraciones de dos semanas, y hablar sobre los procesos se convierte en una lista de sus parámetros:
- ¿Cuál es la evaluación?
- Puntos de historia.
- ¿Qué es la velocidad?
- 68.
- ¿Cómo planeas proyectos?
- En las calificaciones de "camiseta" de S, M, L.
Esta es una conversación muy rápida. Con los techlides actuales, todos los parámetros del proceso pueden discutirse en una hora. Después de eso, van a trabajar con el equipo y no necesitan Scrum Master para esto. La industria casi ha digerido este papel y está avanzando.
Por supuesto, este no es el caso en todas partes. Seguramente hay muchas compañías que necesitan alcanzar los estándares del mercado y este no es un proceso rápido. En Rusia, después de 10 años, será posible encontrar un trabajo como Scrum Master en algún tipo de "Lenoblkhozpromlespoval" cuando la organización decida transferir sus tres programadores a Agile.
Durante su popularidad, Scrum Master logró eliminar por completo todas las preguntas del equipo del proyecto de PM. No se lo llevaron a sí mismos, sino a los miembros del equipo, facilitando su participación en el trabajo de diseño. Esto, por cierto, aumentó significativamente el nivel de madurez de TI a los ojos de la empresa.
O aún no es necesario
Lo que queda Me tomé la libertad de resaltar aquellas tareas que, al trabajar en metodologías flexibles, son resueltas por otros roles.
¿Qué queda con los gerentes de proyecto después de esto? Restantes comunicaciones, integración y adquisiciones. ¿Parece que no hay mucho para mantener a una persona dedicada en este papel? Es hora de decir que los PM no son necesarios. Pero no
Todavía necesito
Hay categorías de proyectos de TI en los que la falla sin un gerente dedicado está prácticamente garantizada.
Proyectos del mundo real
Quienes trabajan con el desarrollo móvil saben que con la velocidad de hacer cambios y el costo del error, las cosas no son tan fáciles. Si se perdió un error en el desarrollo móvil y no lo notó de inmediato, será difícil realizar una actualización para toda la audiencia. Algunos usuarios no actualizarán sus aplicaciones y el error permanecerá. A partir de este problema, por ejemplo, han aumentado los enfoques con control remoto de la funcionalidad de las aplicaciones móviles.
Pero esta es la centésima parte del dolor de los PM que gestionan el desarrollo de software, por ejemplo, para gestionar el transportador de clasificación en un almacén con una escala de 5 millones de unidades de mercancías. En tales proyectos, docenas de dependencias de los proveedores de equipos, las iteraciones se miden en meses y el precio del error aumenta en un orden de magnitud.
Los proyectos relacionados con equipos nos devuelven del mundo digital a nuestra realidad, en la que el control clásico de PMBoK sigue siendo relevante.
Proyectos Paraguas
En proyectos generales, las metodologías flexibles se estancaron. Tales proyectos son grandes y complejos. La complejidad significa dependencias explícitas e implícitas, y en cierta escala, el desarrollo sin un gerente de proyecto dedicado se vuelve extremadamente ineficiente. En tales proyectos, las tareas principales de PM son la integración de proyectos, la dependencia y la gestión de tiempos.
Proyectos con un alto costo de error
Siempre habrá industrias en las que los errores deben eliminarse al máximo: medicina, aviación, industria espacial y el ámbito militar. En estas áreas, cuando ocurre un error, las personas mueren o se pierde mucho dinero. Los ejemplos son fáciles de encontrar en Internet. Comience con una historia sobre el misil europeo Arian-5.
En tales áreas, el PM seguirá siendo demandado, pero se les exigirá mucho en términos de competencias y experiencia. Y cuanto menor sea la proporción de tales proyectos, más estricta será la selección de candidatos.
Proyectos sin parte de roles
La vida es algo duro, y no siempre es posible tomar una persona dedicada para cada uno de los roles. Hasta que el mundo sea perfecto, quedarán PMs que hacen el trabajo de Product Owner. O PMs que de facto funcionan como deslizamientos tecnológicos. Tales combinaciones son a menudo características de las startups.
Si ampliamos en el tiempo esas tendencias que están teniendo lugar en la industria ahora, tendremos un futuro en el que el papel de PM en su forma pura sigue siendo relevante para un pequeño número de proyectos de desarrollo de software cuyo trabajo aún no sabemos cómo automatizar o distribuir entre otros. miembros del equipo
Texto preparado por:
Autor - Dmitry Kruglov
Editores - Eugene Shklyar, Denis Vonsarovsky
La opinión del autor sobre algunos temas puede no coincidir con la opinión del consejo editorial del blog y la compañía Yandex.Money.