Todo el mundo sabe que una estimación precisa de los proyectos de desarrollo web es importante, pero la pregunta es cómo lograrla. Mi nombre es Sergey, y soy CTO en JetBase. Cada día, estimo cientos de proyectos, y los jueves, dirijo una escuela para líderes de equipo, donde hay lecciones dedicadas específicamente a la estimación.
En nuestra agencia, hemos desarrollado una metodología para la estimación y la perfeccionamos constantemente. Hoy, me gustaría compartir mis observaciones y experiencia con todos los interesados. Prepárense para ejemplos reales de la práctica y no menos estadísticas y cifras.
Escribo este artículo para todos los interesados en el tema, pero principalmente para mis compañeros líderes de equipo y también para nuestros clientes que contactan diariamente con nuestro departamento de ventas y solicitan precios. La estimación precisa de proyectos es crucial para estas dos categorías de personas.
Con frecuencia he encontrado la frustración tanto de los principiantes en el liderazgo de equipos como de los clientes. Los nuevos líderes de equipo se sienten frustrados cuando se enfrentan a datos insuficientes del cliente y tienen miedo de hacer preguntas adicionales, mientras que los clientes, a su vez, se quedan perplejos cuando ven ciertas cifras. Ambos necesitan una estimación perfecta, pero ¿es fácil de lograr? Descubramos cuál es la verdadera historia.
¿De verdad quieres TikTok?
Comencemos con la historia de un cliente que una vez se acercó a nosotros queriendo crear una plataforma social similar a las aplicaciones de streaming existentes y populares como Instagram y TikTok. Los requisitos proporcionados eran bastante generales, como suele ocurrir en el 95% de las situaciones, y, como de costumbre, no se mencionaban los objetivos de negocio del proyecto.
No fue difícil adivinar que el objetivo de negocio del proyecto era la venta de publicidad. El deseo primordial del cliente era saber cuánto tiempo y dinero tomaría lograr este objetivo. Bueno, podríamos haber dado cifras aproximadas como 3 años y 1 millón de dólares, pero ese no es nuestro enfoque en absoluto.
El objetivo de nuestra empresa es realizar un trabajo de calidad, y el objetivo del equipo técnico no es solo proporcionar una estimación, sino analizar los requisitos y perfilar la implementación del proyecto a lo largo del tiempo, en sprints y etapas.
Nuestro objetivo es evaluar las tareas esenciales para el proyecto, concentrándonos en el núcleo del mismo. A lo largo de los años, nos ha quedado claro que este enfoque es más realista y práctico que dar estimaciones aproximadas y luego intentar ajustarse a ellas. Además, la era del desarrollo de productos llave en mano ha terminado.
Hoy en día, todos los productos se desarrollan de forma iterativa, evolucionando en el entorno, en el espacio.
Volviendo al cliente que quería crear una plataforma como TikTok, en primer lugar, personalmente, creo que copiar el camino de otra persona no es la forma más fiable. Desde nuestra perspectiva, sugerimos no hacer un TikTok, es decir, no mencionarlo en absoluto. En cambio, proponemos analizar el proyecto basándonos en su esencia, describiendo sus objetivos de negocio, abordando los puntos débiles de los usuarios y descubriendo cómo el producto puede resolver los problemas de los usuarios.
En otras palabras, crear un MVP, probarlo, hacer cambios. Solo entonces quedará claro qué representará realmente la plataforma. Al final, podría resultar ser completamente diferente de TikTok, quizás más parecido a Snapchat.
Acerca de la Estimación de Proyectos — En General y Muy Brevemente
Ahora, vayamos a la esencia: cómo se ve el proceso de estimación en JetBase. Anteriormente hemos escrito en detalle sobre la estimación en el artículo "Estimación del Desarrollo de Software: Una Guía Exhaustiva".
Aquí están las tres etapas principales de las que consta el proceso de estimación (habrá teoría, pero después de eso, lo verán todo en la práctica):
Etapas de Estimación:
Etapa 1. Obtención de datos iniciales del cliente con wireframes, un resumen de JetBase.io
En esta etapa, nuestro equipo de desarrolladores liderado por un líder de equipo realiza un análisis del proyecto, lo que implica no solo comprender los aspectos técnicos, sino también identificar la esencia del proyecto. A menudo, esto implica algún objetivo de negocio. Por ejemplo, un cliente puede querer crear un sitio web para el registro de participantes en conferencias o una aplicación con recomendaciones de recetas vegetarianas. En el primer caso, el objetivo es la venta de entradas, y en el segundo, la venta de suscripciones.
| Consejos para stakeholders y propietarios de proyectos: | Consejos para líderes de equipo y gerentes de proyecto: |
|---|---|
| Además de los requisitos técnicos, especifique también el objetivo de negocio del proyecto. No confunda la esencia con las expectativas. Vea el ejemplo con TikTok arriba. | Haga tantas preguntas como sea posible en esta etapa, especialmente sobre los aspectos del proyecto donde haya lagunas. |
Etapa 2. Creación de la arquitectura del proyecto, desglosándolo en subtareas
Si en la primera etapa descrita anteriormente queremos comprender la esencia del proyecto —el núcleo—, aquí, en la segunda etapa, tomamos esta gran idea de proyecto y la desglosamos en pequeñas partes, visualizando simultáneamente las funciones constructivas. En otras palabras, descomponemos la tarea grande en subtareas y creamos la arquitectura del proyecto. Esta etapa es crucial e ineludible. Hay muchos tipos de descomposición en subtareas, pero hablaremos de eso en otra ocasión.
Visualizar el flujo de trabajo y la arquitectura del proyecto infunde confianza en todos los involucrados, especialmente en aquellos que invierten fondos sustanciales. En JetBase, firmamos contratos con nuestros clientes solo después de detallar meticulosamente los flujos de trabajo del proyecto a través de tareas grandes, medianas y pequeñas. Esto garantiza la tranquilidad de nuestros clientes y fomenta una comprensión más clara en nuestro trabajo colaborativo.
| Consejos para stakeholders y propietarios de proyectos: | Consejos para líderes de equipo y gerentes de proyecto: |
|---|---|
| Prepárese para el hecho de que la arquitectura propuesta por los desarrolladores será ligeramente diferente de sus expectativas. Asegúrese de que los especialistas técnicos son expertos para proporcionar recomendaciones más precisas y óptimas. | Tenga en cuenta que cuanto más detallado sea el desglose del proyecto, más precisa será la estimación. Preste especial atención a esta etapa. |
Etapa 3. Estimación del proyecto por alcance de trabajo, roles, responsabilidades y horas.
Aquí comienza el poner los puntos sobre las íes — la estimación real. En esta etapa, debe activar su mente matemática y no perderse nada importante; cada valor numérico afecta la cantidad final. Al mismo tiempo, no olvide que la estimación de proyectos no es solo ciencia sino también arte, y mucho dependerá de cómo pueda ver a través de los números y las tablas la esencia del proyecto para el cual se realiza todo este trabajo meticuloso.
Estimación Exitosa. Ejemplo Real
Ciertamente, uno debe aprender de los errores, pero en la Escuela de Líderes de Equipo, donde enseño los martes, durante una lección práctica, proporciono un ejemplo de estimación precisa. Este es un ejemplo real del portafolio de JetBase, donde estimamos las horas con la máxima exactitud. ¿Un milagro? No, solo una mezcla de ciencia y arte y mucho trabajo meticuloso. Nos tomó dos semanas para esta estimación, y ese es un plazo relativamente corto.
Durante la etapa de análisis, descubrimos que la esencia del proyecto es el registro de participantes para juegos offline. Esto no se declaró explícitamente en los datos iniciales del cliente, pero es crucial saberlo desde el principio. Luego, tomamos estos datos iniciales del cliente y sus wireframes, dividiendo el proyecto en módulos que describen lo que debe hacerse a un alto nivel tecnológico, por ejemplo:
- Crear la aplicación inicial
- Conectar la base de datos
- Crear entidades del proyecto
- Configurar servicios externos, etc.
A continuación, cada módulo debe desglosarse en características y subcaracterísticas con una descripción detallada para cada una, tanto en el frontend como en el backend. Veamos un ejemplo real. Aquí hay una página del proyecto mencionado.
Un líder de equipo inexperto o desinteresado podría estimar esta página de forma aproximada y, digamos, asignar 8 horas de trabajo. Se puede entender su perspectiva, ya que los clientes a menudo se acercan a los desarrolladores para obtener una cifra rápida y final del proyecto y son reacios a esperar un período prolongado.
Pero en JetBase, no seguimos ese enfoque. Invertimos más tiempo en la estimación, pero logramos un resultado más preciso. Así es como se ve nuestra estimación para la página mencionada:
La cuestión es que, para futuros especialistas de proyectos, estimar subcaracterísticas es mucho más sencillo, ya que es una tarea técnicamente clara y comprensible que el líder de equipo identifica durante la etapa de estimación. Aquí es donde reside el secreto de la estimación precisa: en la descomposición meticulosa.
Y si se continúa descomponiendo cada módulo como en el ejemplo de la página discutida anteriormente, y luego se calculan todos los riesgos y tareas relacionadas, el resultado es una estimación limpia y fiable.
A continuación, proporcionaré un ejemplo de una estimación deficiente, y para concluir toda la historia sobre una buena estimación, puedo decir que lograr lo que se llama ideal o pureza no es tan difícil. Es totalmente posible e incluso necesario para todos los participantes en el proceso. Como dijo Steve McConnell en su libro "Software Estimation: Demystifying the Black Art":
"Una buena estimación es una estimación que proporciona una visión suficientemente clara de la realidad del proyecto para permitir que el liderazgo del proyecto tome buenas decisiones sobre cómo controlar el proyecto para alcanzar sus objetivos."
Estimación Fallida. Ejemplo Real.
Antes de alcanzar el nivel actual de experiencia en estimación en JetBase, cometimos errores. Aprendimos a mejorar a partir de ellos, y afortunadamente, no fueron demasiados. Ahora, mencionaré brevemente un ejemplo de estimación deficiente, para que entiendan dónde se esconden los riesgos y por qué es una historia triste tanto para el equipo como para el cliente.
Antecedentes:
Una vez, un cliente se acercó a nosotros para crear un portal de aprendizaje en línea para actores y profesionales de la industria cinematográfica. Inicialmente, había muy pocos datos disponibles, pero aun así estimamos el proyecto, lo que resultó en una estimación global fija.
Resultado:
Como mencioné anteriormente, proporcionamos un precio fijo para el proyecto. Sin embargo, en realidad, terminamos excediendo el presupuesto estimado porque se hizo evidente que se necesitaba más tiempo para el trabajo. Aunque nuestro cliente no objetó esto, el problema surgió cuando no realizaron ningún pago por las etapas de trabajo (sprints), lo que les permitió rechazar el proyecto por completo al final.
En consecuencia, tuvimos que rehacer todo el proyecto, lo que requirió el doble de esfuerzo, pero no fuimos compensados por nuestro trabajo. Trabajamos sin pago para salvaguardar nuestra reputación, mientras que nuestro cliente perdió su valioso tiempo y se decepcionó con su experiencia en el desarrollo web. Los errores deben ser compensados.
Dónde se enterraron los errores:
- El cliente proporcionó datos insuficientes al inicio.
- No utilizamos métodos ágiles.
- El cliente no pagó por las etapas de trabajo, por lo que no estuvo involucrado en los resultados intermedios.
- Proporcionamos un precio fijo en lugar de estimar por sprints (podríamos haber utilizado el método de estimación preciso descrito anteriormente).
Resumen
En cuanto a los dos ejemplos de estimación proporcionados anteriormente, es evidente que ciertas estrategias y prácticas son cruciales para una estimación precisa en el desarrollo web.
De estos casos, surgen varias conclusiones clave:
- Se debe evitar la estimación de precio fijo, ya que a menudo no refleja con precisión las necesidades reales del producto.
- Las solicitudes de los clientes a menudo tampoco se alinean con la realidad del proyecto.
- Más datos de entrada al inicio conducen a una mayor precisión en la estimación.
- Cuanto más meticulosa sea la descomposición de las tareas, más precisa será la estimación.
- Una comunicación efectiva, como involucrar a los clientes en revisiones de demostración regulares y sesiones de planificación, es esencial para la toma de decisiones informada y el desarrollo eficiente del producto.
Además, quiero enfatizar que el problema de la estimación precisa y, en general, cualquier problema técnico no son solo problemas técnicos de los que el sector de TI deba preocuparse. Los clientes y las empresas también deben involucrarse; entonces, habrá más luz verde para estimaciones meticulosas, lo que conducirá a un beneficio mutuo y menos demanda de enfoques torpes de precio fijo.
Espero que mi artículo haya sido útil tanto para los profesionales de TI como para los stakeholders que buscan un equipo de desarrollo web. No duden en contactarnos si necesitan una estimación de proyecto; haremos todo lo posible para adaptarla a sus necesidades específicas.
Fuente: El problema de TI 'No es mi problema' de las empresas.
