Descargo de responsabilidad: Hoy solo hablaremos de proyectos fallidos, por lo que no nombraremos nombres, contraseñas y asistencias.
Todos los casos fallidos de mi experiencia y la de mi amigo se pueden dividir en tres tipos según las fuentes de los problemas:
1. Trabajar con las partes interesadas
La razón de muchos problemas del proyecto es que no escuchamos ni escuchamos al cliente. Esto es especialmente crítico al principio, cuando existe el riesgo de perder la respuesta a la pregunta "¿Por qué se inició el proyecto?"
Caso 1
Nos enfrentamos a una tarea sencilla: bloquear todas las posibles transacciones financieras en virtud de contratos que no se acuerdan dentro de la empresa. Calculamos los efectos y trabajamos, como nos pareció, todos los riesgos. Sin embargo, durante la discusión, el usuario principal argumentó que esto no funcionaría: "Tendremos un proceso de producción". Sonaba como una excusa y el cliente principal confirmó nuestra hipótesis e insistió en hacerlo.
El día X, de acuerdo con los planes, lanzamos la funcionalidad, y aproximadamente una hora y media después, nuestro cliente principal, de no muy buen humor, llamó y pidió revertir todo: “¡No funciona!”.
¿Cómo fue necesario?Escuche las preocupaciones del usuario que conoce los detalles del trabajo de la organización desde adentro y resuelva estos riesgos. Siempre existe la oportunidad de encontrar opciones que se adapten a todos.
Caso 2
Era un cliente funcional que entendía perfectamente la tarea y el sistema que habíamos concebido. Pero no tomamos en cuenta el interés del departamento de TI en la implementación de este proyecto y llegamos a ellos bastante tarde: en la etapa de desarrollo de la arquitectura. Tuve que revisar el proyecto y adelantar el plazo para su entrega. Perdimos tiempo, dinero y reputación al sobrestimar la influencia y las capacidades del cliente funcional y subestimar las relaciones internas entre las divisiones de una gran corporación.
¿Cómo fue necesario? Involucrar a todos los interesados en el trabajo del proyecto desde el principio y tener en cuenta sus intereses, a pesar de las garantías del cliente.
Caso 3
Y este fue un caso que casi no tuvo éxito. El cliente funcional, representado por el CEO, quería cambiar la metodología de contabilidad de costes y, según todos los cálculos, el efecto de los cambios debería haber sido significativo. El equipo del bloque financiero estaba listo para los cambios y cuando la tarea llegó a los analistas de TI, la decisión ya se había tomado. Y aquí hicimos lo correcto y preguntamos: ¿Por qué? ¿Cómo funcionará? ¿Quién apoyará el proceso? ¿Cómo consideraste el efecto?
Como resultado, el efecto se recalculó teniendo en cuenta los cambios en el sistema ERP y los costos de mantenimiento del proceso y la herramienta. No solo el efecto “desapareció” en el dinero, sino que también se descubrieron riesgos adicionales. El proyecto se cerró y, para los empleados del departamento de automatización interna, se convirtió en una regla hacer preguntas al principio, incluso si la tarea provenía del CEO.
conclusiones
- Busque siempre una razón, propósito, efecto. Argumenta tu posición. Como dice un amigo mío (director de la clase): "Escuche, no venda ... Luego escuche de nuevo ... y solo luego venda";
- Vive un día con usuarios directos del producto y conoce su rutina en detalle. Esto ayudará a anticipar todos los posibles matices.
- Resuelva todos los riesgos que le parezcan importantes a usted, el cliente funcional y cualquier persona interesada. Preste especial atención a los clientes / usuarios más negativos hacia el proyecto. ¡Ellos claramente saben algo! ;)
- No se pierda ni un solo participante en el proceso. No puede haber un solo participante en el proceso, ¡y el departamento de TI siempre debe tenerse en cuenta!
2. Descripción de requisitos
El lugar santísimo para cualquier analista es una descripción de requisitos. Consideremos errores en esta área en los otros dos casos.
Caso 1
Uno de los equipos de desarrollo recibió un proyecto que requería revisión. El sistema vino con documentación, donde se escribió la descripción de la lógica del sistema mediante consultas SQL. Cuando comenzó el trabajo, el sistema ya se había rediseñado seriamente y las consultas SQL ya no eran relevantes. Tuve que dedicar tiempo a la ingeniería inversa para comprender la lógica y la funcionalidad del sistema.
¿Cómo fue necesario? Vuelva a verificar la relevancia y cumplimiento de los documentos con el nivel de desarrollo del proyecto. Especialmente cuando se lo pasa a otros desarrolladores.
Caso 2
Fue un proyecto interesante para automatizar todos los procesos dentro de la organización. El proyecto involucró 5 sistemas de varias clases, que debían integrarse entre sí para que el proceso continuara sin interrupciones. El equipo estuvo diseñando la arquitectura de la solución durante unos dos meses, cuando me conecté al proyecto.
En el proceso de comunicarme con el cliente, me di cuenta de que él lo ve de una forma y los desarrolladores de otra. Estos fueron los acuerdos mínimos en palabras que cambiaron por completo el proyecto. Tuve que empezar desde el principio y trabajar con todos los requisitos desde cero: ¿Por qué? ¿Qué? ¿Cómo?
¿Cómo fue necesario? Describa claramente no solo los requisitos para la implementación de procesos y subprocesos (cómo funcionará), sino también cómo se verá el resultado final.
conclusiones
A menudo, los equipos temen los comentarios de los clientes y corren para desarrollarse cuando escuchan "bueno, algo así". Podemos suponer que encontró un lenguaje común con el Cliente solo si él mismo comenzó a hacer ajustes con sus propias manos. A algunas personas les resulta conveniente leer textos, otras tienen diagramas y otras tienen diseños de interfaz. Vale la pena intentarlo todo hasta encontrar un lenguaje común, incluso si serán "dibujos en servilletas".
3. Desarrollo de una idea, producto o solución
Estas son historias sobre la gestión de productos, cuando la idea inunda la mente y todo lo demás no importa.
Caso 1
Teníamos un gran producto para automatizar las tareas rutinarias dentro de una organización: desde ingresar información hasta responder cualquier pregunta de los empleados. Y todo fue genial: encontramos los primeros clientes, entendimos el mercado, parecía que había mucho dinero allí, lanzamos un par de proyectos y los completamos con éxito. Y en ese momento abrimos los ojos: nadie calculó el costo de apoyar la solución. Y borró todos los intentos posibles de hacer dinero a cero.
¿Cómo fue necesario? Calcule cuidadosamente todos los aspectos del proyecto: desde el desarrollo hasta el soporte de la solución.
Caso 2
Otra historia es cuando no resolvimos el mercado. Se encontró una idea para un buen producto que no tenía competidores en el mercado, pero tenía clientes. Al menos uno, y estaba dispuesto a pagar e invertir. Nos adentramos en este proyecto y nos enfrentamos a una falta total de base teórica para el desarrollo de dicha funcionalidad, pero lo logramos.
Y luego de ingresar al mercado con el producto, se dieron cuenta de que no en vano no había competidores. Mucha gente descuida esta función a pesar de todos los efectos que garantiza.
¿Cómo fue necesario? Piense por qué no hay competidores en un sector de mercado tan rentable y llegue al fondo de la verdad.
Conclusiones:
Verifique la viabilidad del proyecto en el marco no de un cliente, sino de la competitividad, de acuerdo con la situación actual del mercado.
Cultura del fracaso
Para superar las dificultades y no volver a verse atrapado en ellas, debe encontrar una razón. La mayoría de las veces, radica en la cultura del fracaso que se adopta en las organizaciones. Hay dos malas formas de responder al fracaso en las organizaciones:
- Condena / Castigo
Condenando los errores, matamos la iniciativa. Los empleados tienen miedo de ser creativos y solo toman decisiones seguras. Esto conduce al estancamiento de la empresa.
Solución: defina límites para los errores. Es necesario asignar un recurso para la manifestación de iniciativas y verificarlas en los puestos de control. Bueno, seguir el éxito del proyecto de acuerdo con estrictos criterios acordados de antemano. - Silencio
Esta táctica lleva a repetir los mismos errores una y otra vez. Y esto, a su vez, conduce a la pérdida de posición de la empresa ante los clientes, la competencia y el mercado.
Solución: construir un sistema de intercambio de experiencias entre empleados. La discusión de las posibles soluciones a las fallas conduce finalmente a una metodología que ayuda a evitar estos errores.
La reflexión razonable ayuda a desarrollarse, pero esta no es una razón para rodearse solo de fracasos. Busque el equilibrio, porque aprender de proyectos exitosos es mucho más divertido