Sobre requerimientos "platicaditos" y estimaciones

Hola a todos, primero que nada espero estar poniendo este post en el lugar correcto de lo contrario una disculpa. Segundo, estoy aquí para preguntarles sus experiencias en cuanto a los requerimientos de desarrollo de módulos que algún “vendedor/preventa” levanto y solo se le entregan al desarrollador de manera “platicadita”. ¿Alguno de ustedes ha trabajado en alguna empresa que trabaje de esta manera? y ¿Que han hecho para que proyectos grandes o pequeños no se salgan de control o vuelvan un caos de por esta situación?

Tercero y aprovechando el viaje y siendo sincero soy malo estimando el tiempo que tardare en los desarrollos o modificaciones en módulos o pantallas. ¿Puede alguien darme un tip para mejorar este aspecto?
Gracias a todos por su tiempo.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

El trabajo del vendedor es

El trabajo del vendedor es que la empresa tenga proyecto por desarrollar, pero no puede ( ni debe ) hacer un análisis completo de los requerimientos.

Hay que refinar esos requerimientos platicaditos y ponerlos en algo más concreto pero aún de alto nivel. Hay que buscar tener una lista de cosas por desarrollar y el orden en el que deben de construirse.

Luego se toma el primer elemento de esa lista y se construye, para construirlo hay que dividirlo en cosas más pequeñas y concretas, surgirán muchas preguntas sobre tal o cual pantalla, ese es el momento de aclararlas con los usuarios.

Cuando las tareas tienen un tamaño significativamente pequeño, es mucho más fácil estimar la duración pero no debe de tomarse este estimado como una promesa de entrega, finalmente es un estimado, no una predicción, la razón por la cual no se puede ni se debe usar como predicción es porque simplemente eso que se va a construir jamás se ha construido antes, no hay forma de saber cuanto toma construirlo.

Esta es la idea general, para más detalles puedes revisar algunas metodologías de desarrollo como Scrum o métodos como Kanban.

Imagen de ezamudio

platicadito

Si te dan una spec "platicadita" pues cuando te preguntas cómo van les platicas que muy bien. Si te preguntan exactamente para cuándo va a estar, cuánto tiempo va a tomar, dales una platicadita de lo que es una especificación real para poder hacer un estimado más exacto. Cuando quieran una demo ps les platicas cómo funciona el sistema pero no se los enseñas, cuando la hagan de pedo les dices "ps igual me diste una spec, no?"

Pero ya en serio, yo me topo con eso más o menos seguido y la manera de lidiar con ello es poner por escrito lo que yo entendí de lo que me piden y mandarlo de vuelta para su aprobación. Ahí yo defino lo más que puedo y generalmente salen dudas en el camino. Las dudas las pongo por delante y me las tienen que resolver de manera muy específica. Y al final pues ya tengo algo un poco más formal que la vil platicadita o el pinche powerpoint de dos slides donde "explican" lo que tiene que hacer el sistema.

Dependiendo el grado de confianza que tengas con quienes pidieron el sistema, y qué tan bien los conozcas, qué tan honestos sean, etc pues la aceptación puede ir desde un simple correo con "ok así está bien, sí, eso es lo que queremos" hasta que tengas que imprimirlo y hacer que firmen ante testigos de que ESO es lo que quieren porque ESO es lo que vas a hacer.

Porque luego vas y desarrollas lo que especificaste, que es realmente lo que entendiste de lo que te platicaron, y siempre a la mera hora que lo vean van a decir que algo está mal. Esa aceptación que tienes de parte de ellos, es un impermeable contra la caca que va a empezar a volar en ese momento cuando dicen que se perdió tiempo, que ahora todo va atrasado, que hiciste las cosas mal, etc etc.

Imagen de sr.bug

Gracias

Les agradezco sus comentarios me sirvieron de mucho.

Saludos