Get best of the week

Cómo entender que un proyecto es un proyecto y ejecutarlo correctamente

Dos días antes de la demostración. El equipo observa una funcionalidad específica: la integración de nuestro producto con Google Maps. La integración es aserrada "en la rodilla": lo principal es tener tiempo para mostrarle al cliente potencial las capacidades del sistema.

La demostración pasa y el cliente hace una pausa para pensar.

Seis meses después, los vendedores venden otra solución con la integración de Google Maps a otro cliente. Bueno, vieron que hace medio año todo funcionaba en la demostración.

¿Cuál es el problema aquí?

Trabajé en diferentes empresas. En algún lugar estaba claro que íbamos a hacer este proyecto. ¿Por qué estaba esto claro? El cliente vino y dijo: Necesito hacer tal sistema y lo describe. El gerente planifica cuánto tiempo tomará el proyecto en tiempo y dinero, negocia con el cliente y trabaja con anticipación. Es: la carta, el plan del proyecto, los riesgos, el control de calidad y otros artefactos del proyecto. Claro y entendible.

En otras organizaciones, el proyecto se lanzó desde arriba: estamos haciendo esto y esto, llevamos a la gente y nos vamos. Menos extensiones, pero también clara y claramente.

En tercer lugar, el más difícil, con proyectos no es fácil. En mi opinión, hay una serie de problemas sobre los que me resulta difícil juzgar desde mi nivel. Todo sucedió como se describió al principio: es más probable que el proyecto esté muerto que vivo.

¿Qué problemas surgen?

  • , — . , .
  • .
  • , .

El equipo del proyecto comenzó a elaborar el plan de implementación y aparecieron matices "repentinos".

Sin embargo, un clásico del género: tanto nosotros como el cliente entendimos de manera diferente "integración", por ejemplo, o el término "auditoría". Para ellos, era una palabra terrible asociada con verificadores malvados, y para nosotros, un término que significa funcionalidad.

Como resultado, el proceso de implementación se traduce en un proyecto de revisión. Formalmente, el borrador del estatuto no cambió; todos los objetivos de alto nivel permanecieron igual.

¿Cómo rodar? La tarea principal es averiguar exactamente lo que se debe hacer, determinar prioridades, plazos, recursos, riesgos, notificar a todas las partes interesadas, preparar varios escenarios de desarrollo. Como resultado, acordar con el cliente la cantidad requerida que se ajustará al presupuesto asequible.

Los principales matices: el proyecto ya se ha vendido, ya tiene un presupuesto y la cantidad de trabajo. Restricciones bastante duras. Pero esto no significa que deba tragarlo todo y tomarlo como verdad en primera instancia. En el 99% de los casos, puede negociar, ya sea un cliente o un patrocinador.

Comenzamos el proyecto


Dio la casualidad de que soy más partidario de planes claros. Cascada y el enfoque PMI son similares en espíritu, aunque algunos aspectos de Agile no son extraños.

Entonces, el proyecto comienza y la prueba de que se lanzó es la carta del proyecto. Para aquellos que son poco familiares o desconocidos, les explicaré qué tipo de bestia es.

De acuerdo con la ideología de PMI, este es un documento que describe los objetivos de alto nivel, plazos, presupuesto, riesgos, y también otorga autoridad formal al gerente del proyecto y, lo que es más importante, determina el nombre del proyecto. A continuación explicaré por qué.

A menudo, el administrador del proyecto prepara el estatuto, acordado con el patrocinador, el cliente y otras partes interesadas clave.

En una de las empresas donde trabajaba, no había una definición clara de lo que era un proyecto. Había una cierta actividad, un cierto flujo, que se llamaba proyecto, pero en realidad no lo era. Eso fue una suposición. Bien, llamémoslo proyecto y al menos decidamos un nombre para que todos entiendan de qué estamos hablando. Hubo confusión con los nombres cuando el patrocinador dijo: “¿Cuál es el progreso en el proyecto para integrar soluciones?”. Luego, el jefe del departamento y el gerente pensaron en diferentes cosas. El jefe del departamento llamó a este proyecto "integración del cliente", y el gerente del proyecto "optimización de la base de datos". Todos pensaban a su propio nivel.

Agile no tiene presupuesto ni plazos, incluso los de nivel superior, ya que todo es flexible y puede cambiar en cualquier momento. Sí, Agile puede estimar el tiempo de finalización, pero solo después de varias iteraciones cuando se evalúa el rendimiento del equipo. Pero hay objetivos. Sabemos lo que queremos hacer.

Daré un ejemplo. Hay dos equipos de desarrollo. Ambos tienen el mismo proyecto: desarrollar una solución móvil para el control de calidad de los alimentos.

El equipo A trabaja en Waterfall. El equipo B trabaja en Agile. Diferentes enfoques de planificación y desarrollo. Pero el objetivo es uno. Entonces, ¿por qué no arreglarlo al principio? ¿Cuál es la probabilidad de que el equipo B en el medio del sprint entienda que el cliente no necesita una aplicación para el control de calidad, sino que necesita una aplicación para grabar partidos de fútbol? Muy pequeño, con una mayor probabilidad, sin embargo, alcanzarán su objetivo original.

NB: estoy asumiendo y hablando sobre desarrollo personalizado, no sobre startups.

Con el nombre, calendario, presupuesto, más o menos claro. ¿Qué pasa con los riesgos?

PMI se refiere a esto formalmente. En mi opinión, el proceso de gestión de riesgos es algo independiente. Déjame explicarte lo que quiero decir.

El proceso de gestión de riesgos consta de las siguientes etapas:

  1. Identificación
  2. Análisis
  3. Planificación
  4. Supervisión

Esto es esencialmente un proceso iterativo. Es aplicable tanto a las operaciones como a los enfoques ágiles.

Al comenzar un proyecto, hay un riesgo global: puede fallar.
El libro de Edward Yordon, The Kamikaze Path, tiene un pensamiento interesante: vale la pena tratar cualquier proyecto como un fracaso. Con esta actitud, necesita construir una estrategia de desarrollo, es decir, pensar en un conjunto de acciones que harán que un proyecto exitoso sea un fracaso.

Entonces, ¿por qué no alejarse de este pensamiento y hacerlo realidad? Sí, hay pocos datos al comienzo. Pero es por eso que son riesgos de alto nivel, para mostrar a las partes interesadas qué podría salir mal.
Total: el borrador del estatuto es un documento que permite a todas las partes clave acordar una terminología, objetivos globales y riesgos de alto nivel. Todos entienden a dónde vamos, qué queremos lograr y qué podría suceder mal.

Establecimiento de objetivos del proyecto


Muchos gerentes de proyectos novatos pasaron por esto: debe elaborar un estatuto y determinar el (los) propósito (s) del proyecto. Y nacen esos monstruos:

  • Desarrollo e implementación de un programa corporativo y sistema de gestión de proyectos para mejorar la interacción entre departamentos;
  • Reciclar el sistema de contabilidad fiscal para optimizar el proceso contable;
  • Implementación de un sistema de control de costos para aumentar la ganancia de los departamentos.
  • Tales proyectos no pueden completarse. Si ve esta redacción en la carta, entonces este proyecto ya está muerto.

¿Por qué debería un "sistema corporativo" mejorar la colaboración? ¿Cómo entenderá el cliente que ella hizo esto?

"Reciclaje del sistema contable": lo modificaremos, pero ¿cómo? Cambiar los elementos del menú en la interfaz. ¿Esto agiliza el proceso de contabilidad?

“Implementación del sistema de control”: ¿cómo entendemos que el sistema está implementado? Supongamos que todos están de acuerdo en que se implementa, pero ¿aumentará la ganancia de los departamentos? ¿Qué pasa si no implementamos nada, pero la ganancia aumenta, por razones que escapan a nuestro control? ¿Podemos suponer que el proyecto ha alcanzado su objetivo?

Si formulamos los objetivos del proyecto, entonces este debería ser un conjunto de objetivos: ¿qué hay que hacer específicamente y cómo entendemos que lo hicimos? ¿Qué deberíamos ver, sentir? ¿Qué debería cambiar? ¿Qué costos debería lograrse? ¿Cuando? Si hay varios objetivos, ¿cuáles son sus prioridades? Puede resultar que los objetivos dependen unos de otros, o puede ser que algunos objetivos sean mutuamente excluyentes.

Establecer metas INTELIGENTES


  • Específico - específico.
    ¿Qué queremos hacer? Algo para mejorar? ¿Y cuánto?
  • Medible - medible.
    ¿Podemos medir la meta en dinero, porcentaje, tiempo ahorrado?
  • Alcanzable: alcanzable ¿Tenemos suficientes recursos, conocimiento, experiencia y tiempo para lograr el objetivo?
  • Relevante: relevante o significativo.
    ¿Aquí necesita determinar qué se requiere para lograr el objetivo?
  • Tiempo limitado - tiempo limitado.
    ¿Cuánto tiempo debe lograrse el objetivo?

Ejemplo: Implemente un sistema de gestión de proyectos basado en Project Server para 20 lugares de trabajo de la oficina del proyecto utilizando un registro electrónico de riesgos y correos electrónicos con la notificación automática de aplazamiento de los plazos.

El sistema debería ayudar a reducir los horarios de cada proyecto en un 15% dentro de los 2 meses posteriores al lanzamiento.

El sistema debe implementarse en 6 meses, a más tardar el 15 de diciembre.

Ya más cerca, pero aún es posible refinar.

Preguntas adicionales que puede hacer:

  • ¿Lo que debe hacerse?
  • ¿Por qué necesitas hacer esto?
  • ¿Qué beneficios debe aportar el proyecto?
  • ¿Están todos familiarizados con este plan?
  • ¿Todos lo entienden de la misma manera?
  • ¿Todos están de acuerdo con él?
  • ¿Cuándo necesitas terminar el trabajo?
  • ¿Quién es el usuario final?
  • ¿Qué calidad esperas recibir?
  • ¿Qué funcionalidad se espera?
  • ¿Qué instalaciones hay disponibles?
  • ¿Quién controla el éxito y con qué criterios?
  • ¿Qué no debería suceder en ningún caso?
  • ¿Qué trabajo no pertenece al proyecto?

Las dos últimas preguntas son las llamadas "no metas".

Describen lo que no es relevante para el proyecto y lo que no debería suceder, ya que esto interfiere con el progreso del proyecto o viola las restricciones internas. Los resultados que no son relevantes para el proyecto no deben caracterizarse como perjudiciales, pero debe tener en cuenta que el cliente no paga por ellos.

Resumen


¿Ves, hay una cierta cantidad de trabajo con ciertos esquemas e incluso hay una línea de tiempo y un presupuesto para ello? Con un alto grado de probabilidad, este es un proyecto. Estamos negociando con el personal de ventas para que tanto los gerentes como los ingenieros participen en el proceso de ventas. Al menos como consultores, y luego trabajarán con él.

Antes de comenzar, determinamos el nombre del proyecto y la terminología. Escribimos la carta y formamos objetivos claros y entendibles. SMART es nuestro todo.

More articles:


All Articles