Hay docenas de marcos y metodologías que se utilizan en el trabajo de diseño. Ya no hay personas que no escucharían acerca de los enfoques ágiles, scrum, kanban y otros. Cada uno de ellos prometió convertirse en una bala de plata, lo que ayudará a llevar a cabo proyectos para que cumplan con todos los parámetros del éxito. Pero en la práctica, solo el trabajo competente con riesgos le permite llevar los proyectos al final a toda costa.En este artículo intentaremos considerar los riesgos más importantes que pueden interponerse en su camino. El material será útil para todos los involucrados en el trabajo de diseño.
Entonces, ¿qué proyectos se consideran exitosos? Es habitual resaltar los siguientes parámetros:- el proyecto fue entregado a tiempo;
- sin exceder el presupuesto;
- con un número mínimo de defectos;
- funciona según lo previsto;
- la gente lo usa;
- resuelve los objetivos que se le plantearon;
- - ;
- .
Entonces, ¿qué, de hecho, con qué frecuencia los proyectos completados cumplen con todos estos puntos?Con una pequeña diferencia en las estimaciones de los estudios del Grupo Standish, el Project Management Institute, Gartner, Wellingtone y otras organizaciones respetables , se nos dice que un tercio de los proyectos en TI resultan ser fallidos, y la mitad experimenta dificultades. Solo piense, estas son estadísticas impresionantes.Es difícil decir qué nivel de proyectos participaron en las muestras, pero supongamos que se trata de grandes historias como la modernización fallida de la infraestructura de TI de la cadena de tiendas KMart por $ 1.2 mil millones, que se ha convertido en uno de los factores clave en la bancarrota de la empresa.¿Significa esto que los proyectos más pequeños que hacen estudios web rusos no están sujetos a los mismos problemas? Si lees reseñas de clientes en el agregador popular, veremos que incluso en el caso de las páginas de destino típicas y las tiendas en línea de plantillas, los criterios anteriores para el éxito rara vez se cumplen:“Pedimos el desarrollo y diseño del sitio en 2015. Diseño hecho rápidamente, pero eso no quiere decir que sea de calidad. El desarrollo se introdujo hasta el año 2017 y nunca se implementó ”
“El sitio después de tal trabajo tuvo que ser completamente renovado, al principio, por supuesto, el trabajo fue activo y parecía que todo estaba bien. Pero luego comenzaron a notar que estábamos repitiendo la misma tarea durante un mes, como resultado, casi dejamos de responder preguntas. Como resultado, resultó en una gran desventaja, porque tuve que contratar a otro proveedor "
“Varias veces pospusieron los términos de la implementación del sitio mediante acuerdos adicionales. Como resultado, todos los plazos acordados también se interrumpieron y el desarrollo del sitio tomó 1,5 años. La producción fue un producto crudo que no puede ser utilizado. Tuve que dar el sitio para su revisión a otro estudio "
¿Qué podemos decir sobre el desarrollo individual más extenso? Después de todo, cuanto más grande es el proyecto, más posibilidades tiene de no sobrevivir hasta su finalización. Por lo tanto, cualquier cliente y contratista debe tener una pregunta: cómo no llegar al cementerio de proyectos inacabados.Veamos qué podría salir mal en un proyecto de desarrollo personalizado y qué hacer al respecto:Riesgo 1. Calificaciones inadecuadas de los contratistas.
El problema aquí es cómo funciona el desarrollo personalizado. El cliente a menudo no entiende en quién confía el proyecto, porque en cada esquina prometen un ciclo de desarrollo completo y un trabajo llave en mano.Habiendo decidido digitalizar parte del negocio, la compañía recurre a un estudio web (también conocido como agencia digital / integrador web). El servicio se realiza en un formato de ventana única. Se le pide al cliente que complete un breve, en base al cual se compila TK. Si el proyecto es complejo y requiere programadores experimentados, el desarrollo se subcontrata a producción.El subcontratista debe llevar a cabo el trabajo en los Términos de Referencia, que fue compilado por personas incompetentes. Si un proyecto sobrevive al lanzamiento, a menudo resulta que el producto no resuelve las tareas de la compañía, nadie quiere usarlo.
— , , . .
No importa cuán trivial sea, lo más importante es comprender el problema. No ahorramos recursos para la inmersión en el negocio del cliente. Estamos listos para organizar un viaje de negocios y comunicarnos en el acto no solo con las partes interesadas, sino también con las personas que utilizarán el producto final. No comenzaremos a gastar el presupuesto del proyecto hasta que estemos convencidos de que lo descubrimos.El estudio web de TK está formado por analistas que trabajaron como probadores ayer. Sin comprender las complejidades del desarrollo, crean un documento que describe los elementos de la interfaz, pero al mismo tiempo prácticamente ignora las complejas integraciones y algoritmos que se esconden detrás de estos elementos.
Un ejemplo real de formulaciones en base al cual el contratista general requiere calcular el costo de desarrollo final.
El contratista general solicita calcular el costo de desarrollo utilizando un ejemplo de servicios similares en formato, pero implementados de manera completamente diferente. "Hágalo allí, lo resolveremos"Cuando se trata de automatizar una empresa, este enfoque es incorrecto. No es suficiente dibujar diseños y describirlos en los TOR. Por lo tanto, es mejor confiar la etapa de análisis a los arquitectos de sistemas que entienden lo que se esconde "debajo del capó".Riesgo 2. Agotamiento del presupuesto antes del lanzamiento del producto
El mercado de servicios digitales está dominado por presupuestos fijos y pospago. Por lo tanto, es más probable que las cuentas y las ventas acuerden un estimado y concluyan un acuerdo. Si el estudio web redactó incorrectamente los términos de referencia, realizó un alcance incompleto y atrajo a subcontratistas para el desarrollo, el infierno de producción podría suceder en el proyecto.El volumen de trabajo será mayor, el contratista general comenzará a proteger sus intereses y empujará a los artistas finales para que se ajusten al presupuesto. En ambos lados, la lógica pervertida funciona, cada uno tiene una excusa para hacerlo un poco peor que el oponente: “¿Has proporcionado un TK pobre y ahora aumentan el volumen? ¡Entonces no tendremos en cuenta algunos de los comentarios! / "¡Ya le hemos prometido al cliente adónde irán, terminarán o no recibirán el dinero!".Estas guerras políticas están ocultas a los ojos del cliente. No sabe quién está involucrado en el proyecto y cómo va el proceso de desarrollo: los socios del estudio web firmaron el NDA. Como resultado, la producción sacrifica la calidad del producto para no trabajar con pérdidas, y el estudio web solo piensa en cómo firmar los actos y recibir el pago lo antes posible. A nadie le importan los beneficios para el cliente.Método de evitación
Al hacer estimaciones, los estudios web se limitan solo a las etapas generales de trabajo: análisis, diseño, diseño, programación. Mientras que un contratista competente incluirá en la estimación todos los elementos funcionales del sistema desarrollado.Sobre la base de una conversación de cinco minutos con un cliente, es imposible evaluar el alcance del trabajo sobre la transformación digital de una empresa. Por lo tanto, trabajar con la estimación en sí misma requiere varias etapas, y sin análisis no será posible obtener el costo de desarrollo final.Ofrecemos a los clientes con dudas que calculen el costo del proyecto de acuerdo con nuestros detalles. Hasta ahora, ninguno de los competidores ha aceptado, aunque ha habido estudios que prometieron hacer más barato.Pero incluso con las especificaciones técnicas y estimaciones elaboradas, el proyecto no está protegido contra el desequilibrio en el cronograma de producción. Tan pronto como surja tal amenaza, es importante no solo advertir al cliente, sino también proponer un plan de acción alternativo y la optimización del alcance del trabajo. No puedes quedarte callado y esperar que "tal vez explote".Riesgo 3. Cambios en la mitad del proyecto.
Los proyectos para el desarrollo de sistemas digitales duran un promedio de al menos un año. Cualquier cosa puede pasar durante este tiempo.Puede suceder que en medio del proyecto el cliente haya cambiado la forma de hacer negocios, o hayan aparecido tecnologías más avanzadas, o tal vez algo haya cambiado en el mundo.Por ejemplo, desarrollaron un sistema de entrega de mensajería, pero debido a la situación política, el mercado cambió, los grandes agregadores redujeron sus comisiones y el proyecto ya no resuelve los objetivos establecidos para él. En tales circunstancias, es absolutamente normal si el cliente comienza a cambiar las tareas sin esperar la finalización del desarrollo. Necesitas poder trabajar con esto.Método de evitación
Si el cliente se ofrece a cambiar algo, antes que nada debe averiguar por qué sucede esto y qué circunstancias llevaron a esta decisión. Lleve al cliente a una conversación franca para comprender su dolor.Solo después de eso, evalúe si estos cambios beneficiarán al proyecto e intente anticipar los riesgos asociados, incluido el exceso del presupuesto. Luego, encuentre el mejor enfoque para implementar estos cambios en el producto y ofrézcalo. Pero la elección debe quedar con el cliente.Riesgo 4. Pérdida de interés por parte del propietario.
Cuando algo cambia en el mundo, el cliente puede dejarse llevar por otra línea de negocios y olvidarse del proyecto actual. La pérdida de interés lleva al hecho de que se le pide al intérprete que reduzca completamente el trabajo o, peor aún, que se quede en el limbo. Esperar una decisión conduce a tiempos de inactividad y costos.Pero con mayor frecuencia, el interés desaparece cuando ocurren cambios serios en la estructura organizacional del lado del cliente, las personas cambian en el proyecto. Como regla general, estas personas no poseen el contexto completo y, por lo tanto, no ven el valor del proyecto. Su motivación para lanzar el producto es extremadamente baja.Método de evitación
Para mantener constantemente el interés en el proyecto, mostramos al cliente todos los resultados intermedios. Los proyectos grandes generalmente consisten en un conjunto de servicios, por lo tanto, como resultado de cada iteración de desarrollo, nos esforzamos por demostrar la funcionalidad completamente preparada de un servicio separado que ya se puede utilizar. Entonces el cliente ve que el producto resuelve sus problemas comerciales.Durante el desarrollo, verificamos si los objetivos del proyecto han cambiado y consultamos regularmente con ellos. Realizamos análisis adicionales y recopilamos comentarios del público objetivo. Involucramos a representantes de los clientes en el proceso de desarrollo y apoyamos la evaluación de las perspectivas del proyecto en un estado actualizado.Riesgo 5. El cliente no asigna tiempo para participar en el proyecto.
Los empleados del lado del cliente no brindan la información necesaria, el gerente responde lentamente y todo se ralentiza. Al mismo tiempo, sabemos con certeza que el cliente necesita el proyecto, no se ha perdido el interés, los plazos aún son convenientes.Desafortunadamente, esto sucede a menudo. En este caso, un ejecutor sin experiencia comenzará a ofenderse, reducirá las prioridades de las tareas del cliente y, en última instancia, cambiará a todo el equipo de desarrollo a otro proyecto. La lógica del artista es clara aquí, nadie quiere un tiempo de inactividad del equipo debido a aprobaciones excesivamente largas. Esto resulta en una relación rota con el cliente. El proyecto no se está completando.Método de evitación
Estamos personalmente de acuerdo con el cliente en la definición de personas responsables. Discutimos su estado y grado de responsabilidad. Arreglamos sus funciones y responsabilidades en el horario de trabajo.Tan pronto como notamos que las personas responsables han encontrado algunas restricciones, junto con el cliente estamos buscando una solución sobre cómo eliminar estos obstáculos y continuar el proceso de desarrollo. Si las personas designadas no cumplen completamente con el acuerdo, sugerimos nombrar a otros empleados en su lugar.Riesgo 6. Ajustes / mejoras prolongados
El cliente no siempre es lo suficientemente competente como para evaluar el grado de preparación del proyecto. Esto es normal. Es mucho peor cuando el contratista no comprende si el proyecto está listo. La puesta en servicio a menudo se retrasa debido a cambios irrazonables. Esto lleva al hecho de que ambas partes pierden tiempo y dinero.La situación a menudo está relacionada con el hecho de que las ediciones son ofrecidas por personas que no son responsables del resultado final. Si no se ocupa de arreglar a las personas responsables por adelantado, los comentarios vendrán de personas no calificadas que tienen un contexto incompleto. Sucede que están conectados en una etapa tardía y, por lo tanto, no saben nada sobre las limitaciones y los objetivos del proyecto.Un contratista inexperto disputará sin cesar estas ediciones para no hacerlas por su cuenta o, por el contrario, tendrá absolutamente en cuenta todos los comentarios. Todo esto afecta negativamente el logro de los objetivos iniciales del proyecto.Método de evitación
Si los comentarios provienen de una persona que no es responsable, los arreglamos y discutimos con aquellos que son directamente responsables del proyecto. Antes de realizar modificaciones, tratamos de comprender cómo estos cambios ayudarán a los objetivos generales del proyecto. Si las ediciones no ayudan, pero solo interfieren, expresamos nuestras preocupaciones.En el caso de que el propietario del producto solicite cambios, advertimos que esto retrasará el lanzamiento. Ofrecemos una solución competente para optimizar el alcance del trabajo, teniendo en cuenta las nuevas introductorias. Junto con el cliente, descubrimos qué sucederá si lanzamos el producto en la forma en que está. Cuando no hay consecuencias negativas claras, sugerimos posponer las ediciones a las etapas posteriores. Además, la elección siempre queda con el cliente.Riesgo 7. Falta de disponibilidad de infraestructura para el lanzamiento
El hecho de que la infraestructura del cliente no esté preparada, los matices legales no están redactados y no hay acuerdos de asociación que pueden impedir el lanzamiento del proyecto en funcionamiento.Por ejemplo, el sistema está diseñado para funcionar en SSD, y la infraestructura actual usa HDD, o el negocio está lanzando una nueva dirección, pero aún no ha recibido el permiso del departamento gubernamental.El contratista a veces continúa trabajando en tal situación, ignorando los problemas del lado del cliente. Porque se siente cómodo de no ir más allá de su área de responsabilidad. Formalmente, el contratista hace lo correcto, el problema está en el lado del cliente. Pero, ¿de qué sirve un producto que será imposible de lanzar, qué beneficios traerá?Método de evitación
Antes de comenzar a trabajar, discutimos con el cliente los recursos necesarios para lanzar el proyecto. Le damos recomendaciones sobre qué personas contratar y qué equipo comprar. Si el proyecto no es estándar, consulte con abogados y asegúrese de que no habrá problemas por parte de la legislación al momento del lanzamiento.En la etapa de formación de TK, verificamos las oportunidades de integración y otros aspectos técnicos de la operatividad del producto final.Conclusión
Todos los riesgos están de alguna manera interconectados. Un problema que no se ha solucionado a tiempo puede causar un efecto de bola de nieve.Pero la experiencia muestra que hay tres formas universales de prevenir y minimizar las consecuencias de los riesgos:- Arreglando riesgos potenciales;
- Plan de acción para evitarlos;
- Disponibilidad para cambiar de rumbo y buscar soluciones alternativas.
Pensar correctamente no se trata de proyectos, sino de clientes. Comuníquese constantemente y trabaje con las expectativas del cliente. No escondas nada y ayuda a ver la plenitud de la situación.Detrás de cada riesgo descrito se encuentran casos reales de la experiencia de Work Solutions. Estas no siempre fueron historias con un final feliz; algunas le costaron a la compañía millones de rublos.Pero todas las fuerzas que ponemos para construir asociaciones de confianza con los clientes a menudo dan sus frutos, aunque no rápidamente.Debido a la transparencia en las relaciones, tenemos clientes con los que hemos trabajado durante más de seis años, y para los que hemos descargado decenas de miles de horas hábiles. Durante tanto tiempo de cooperación, surgieron varios riesgos antes del proyecto, pero siempre tratamos de informarlos a tiempo y proponer formas de resolverlos. Por lo tanto, creemos que una gestión de riesgos competente asegura la finalización de los proyectos.En los comentarios, sugiero compartir historias de su experiencia cuando los proyectos no se completaron. ¿Alguno de los 7 riesgos que describimos fue responsable de esto? ¿O era la razón algo más?