Planificación y el jefe de Bungie
Dilbert tiene muchas tiras sobre el jefe bungie. Nuestros desafíos y expectativas sobre la planificación pueden ser tanto la causa como el efecto de la maldición del liderazgo. Mi experiencia en una compañía Fortune 100 fue que en un año, todos los que comenzaron el año como líderes del proyecto salieron. Quizás esto se debió al problema de planificación. No estoy seguro de si su líder anterior se fue por esta razón, pero cuando su rol requiere que haga un plan con un compromiso, si no se cumple, a menudo, el resultado es una salida relacionada con la fecha límite.
Contexto Organizacional de Planificación
Si no se siente cómodo con la planificación, quizás se sienta incómodo con la responsabilidad de los compromisos asumidos con el marketing u otras partes interesadas antes de que se documenten o comprendan los problemas a resolver. Este es un buen instinto.
La planificación es una herramienta importante. No lo descuides. No lo malentiendan.
La planificación está integralmente vinculada a los compromisos, la rendición de cuentas y el poder de negociación. La planificación ágil tiene muchos méritos. Debe conocer sus técnicas, así como las técnicas de metodologías planificadas. Su organización puede tener su propio enfoque y obtener consejos y trabajar con alguien que ha sobrevivido al liderazgo de muchos proyectos puede ser sorprendentemente útil.
Un ejemplo de planificación simple: no debe ser sobre software ...
Si una empresa de techado vino a mi casa para ofertar por un reemplazo, si ofertan demasiado bajo, pueden perder dinero en el trabajo, pero si ofertan demasiado, no obtendrán el trabajo en absoluto. De cualquier manera, están fuera del negocio. En su nuevo rol, si muerde demasiado, ejecutará el proyecto hasta que la responsabilidad comience, entonces tendrá problemas. Si estima un proyecto con suficiente relleno para asegurar el éxito en la fecha límite, muchos simplemente eligen a alguien más para liderar. La patada es que no eres como el techador. Puede ver qué tan grande es el techo y tiene datos históricos sobre cuánto tiempo dura ese techo.
Convertirse en un mejor planificador
Es posible que desee considerar algún tipo de capacitación. En las metodologías ágiles, y las metodologías planificadas más recientes, la estimación es una actividad de todo el equipo. En consecuencia, también debería considerar capacitar a su equipo.
Por experiencia, puedo decirle que puede ser frustrante obtener estimaciones de los miembros del equipo que lo pospondrán, darle estimaciones que hacen en dos minutos en función del nombre de la tarea sin referencia a un requisito o descripción de la característica o el código existente, o quienes insisten en que varias de las tareas que usted enumera se pueden realizar en una fracción del día a pesar de que los proyectos pasados han pasado semanas en problemas similares.
Existen varios cursos y certificaciones de capacitación para gerentes de proyectos, pero yo buscaría uno que estuviera acreditado de forma independiente. Puede valer la pena pensarlo dos veces antes de elegir certificar con enfoques basados en metodologías planificadas si espera trabajar con equipos ágiles (o al revés).
SLIM es un método inventado por Putnam después de trabajar en GE y otras compañías en proyectos de DoD en la década de 1970. SLIM es influyente, y su compañía QSM ofrece una certificación que parece fluir de una herramienta que fabrican. Dependiendo de si su empresa ha adoptado su herramienta, puede no tener valor o tener un valor alto.
Steve McConnell (autor de Code Complete) también escribió un libro sobre estimación de software, y su compañía Construx enseña dos clases para créditos PDU que están acreditadas a través del Project Management Institute. Tengo su libro, y si quisiera aprender sobre el tema a través de la capacitación en el aula, probablemente elegiría Construx. También hacen capacitación Scrum y administran varias evaluaciones scrum acreditadas a través de Scrum.org.
Otra fuente que podría proporcionar una gran capacitación académica sobre la estimación de proyectos de software sería el grupo de Barry Boehm en USC , basado en su extenso trabajo en el modelado de costos constructivos de COCOMO y COSYSMO que se ha utilizado en la NASA y otros contratistas grandes para estimar proyectos muy grandes. No estoy seguro de ser un verdadero creyente en COCOMO, pero me gusta el trabajo empírico que han realizado para correlacionar los efectos de los factores de escala y costos en la duración del cronograma.
También encontré un capítulo de un libro de texto publicado por O'Reilly que discute brevemente los principales métodos de estimación de software, incluidos Watts Humphreys PROBE y el juego de planificación de Kent Beck. PROBE incluye una noción de que los ingenieros realizan un seguimiento de las métricas de su propia productividad y luego las aplican a su parte asignada en nuevos proyectos. Planning Game es muy colaborativo entre desarrolladores y otras partes interesadas.