Todos los que estamos involucrados de alguna manera en proyectos de internet hemos vivido ese dilema muchas muchas veces. Desarrollo con n funcionalidades, planificado para terminar el dia x, llega cerca del dia x con un 40% de funcionalidad hechas, otro 40% "casi hecho" (lo que suele significar se necesita el doble de tiempo previsto para finalizarlo).
En mi rol de CTO de atrapalo he intentado sin éxito lograr que se cumplan tanto fechas como features. Si las fechas y las funcionalidades entraban en conflicto, aceptaba retrasos como algo inevitable para poder terminarlo todo y salir a producción con todas las funcionalidades exigidas por los requerimientos del negocio. En retrospectiva, considero éste como mi mayor error profesional.
Tras leer algunos libros interesantes que hablan del tema, he llegado a la conclusión firme de que hay primar el cumplimiento de fechas, por encima de las features. En caso de que haya funcionalidades que por cualquier motivo (requisitos incompletos, insuficiente nivel de analisis técnica, baja calidad o entrega de desarrolladores) no pueden terminarse a tiempo, hay que sacarlas del plan de desarrollo para una fase posterior.
Aceptando el retraso por primera vez envias una señal que es aceptable pedir desarrollos poco pensados; hacer funcionales flojos o preparar presupuestos poco realistas; que es aceptable empezar a programar sin definir una buena arquitectura del desarrollo; que se puede seguir leyendo la Marca o chatear en facebook también cuando peligran los deadlines... Aceptando el retraso por décima vez reconfirmas todo esto, y además señalas que no sabes cómo mejorar la situación, cómo mejorar la metodología de desarrollo.
Da igual, si se trata de un proyecto de desarrollo externalizado a una empresa de desarrollo, hecho en un equipo de programadores profesionales o hecho como un proyecto hobby por dos amigos que comparten piso. Sólo una disciplina estricta de fechas es capaz de destapar los puntos mejorables en otras areas.
Cuando en mis tiempos universitarios estudiaba con mucho entusiasmo la teoría de juegos, una de las conclusiones más impactantes que recuerdo es la diferencia de estrategias ganadoras que hay si el mismo juego se juega sólo una vez o con repetición. Proyectos de desarrollo son casi siempre juegos con repetición, por lo cual las estrategias ganadoras han de tenerlo en cuenta. Si solamente se maximiza la ganancia de una ronda de juego (o sea, del proyecto en curso), se puede perder el juego entero.
Bueno es una lucha titanica que hemos sufrido casi todos en nuestra piel en algun momento profesional.
ReplyDeleteMi experiencia personal me ha demostrado que no se cumplen fechas (deadlines) porque no se analizan los proyectos correctamente (features). Creo que esa es la clave por que ese es el origen. Sin las features no habria deadline.
No se dimensionan, ni se presupuestan los recursos, y tampoco se estiman los tiempos correctamente por esa falta de analisis. Pero el problema es el no saber lo que quiero, o como faseo este proyecto para que se pueda entregar como un coleccionable.
Es la pescadilla que se muerde la cola.
Las fechas deben ser el punto mas estricto, la guia la referencia, la estrella polar. La disciplina de las entregas on time nos lleva a no leernos es marca y cumplir con el deadline. A estar motivado para llegar a la meta. Pero si no sabemos para que estamos compitiendo?
En general estoy de acuerdo, aunque con matices. Creo que es necesario aplicar el sentido común correctamente y poder trabajar codo con codo con otros departamentos del equipo. Por mi experiencia, esas intentonas de detección de problemas en otras partes del equipo lo único que consiguen es señalar con el dedo. El típico problema que he visto en todos los sitios en los que anteriormente a montar Trovit he trabajado de "tirar la pelota a otro tejado". Podria poner ejemplos en los que tiene sentido no acatarse a los timings para mejorar a medio plazo. Cuando eres una punta de lanza, las cosas cambian de un dia para otro y hay que flexibilizar y cooperar.
ReplyDeleteNosotros estamos empezando a utilizar SCRUM para controlar precisamente este desfase entre fechas y funcionalidades que tantas veces aparece.
ReplyDeletePues pasa, claro que pasa... ;-)
ReplyDeleteMaria, Daniel, lo de tirar la pelota al otro tejado es muy frecuente en equipos compuestos... Y pasa independientemente de si las fechas se cumplen o no.
ReplyDeleteReconozco la radicalidad de mi conclusión, pero ésta viene tras años largos de intentar a buscar matices y soluciones mixtas...
Jordi, algún dia me explicarás lo de SCRUM y vuestras experiencias. No eres el primero que habla bien de este tipo de proceso de desarrollo.
Iñaki, lo tuyo tiene pinta de tener fechas y features cumplidos, veremos dentro de unas semanas:-)
como Jordi ya te comento, Scrum si tiene herramientas para tener más *transparencia* en el proceso de desarrollo.
ReplyDeleteVale la pena ver unos de los gurus de scrum. En youtube encontrarás mucho: p.e.
http://es.youtube.com/watch?v=9y10Jvruc_Q
Gracias Konrad por la referencia. Sé de alguno de tus emails que eres de los "Scrumers". Algún dia me contarás más de las ventajas. Nunca es tarde para aprender cosas nuevas e utiles.
ReplyDeletemuy interesante lo que comentas... lo de estar inmerso en la rutina de retrasos es una sensación que puede acabar quemando mucho, sobre todo porque es dificilisimo solucionar el tema...
ReplyDeletetambién está el factor de hasta donde puedes apretar al equipo sin llegar a quemarle, o establecer ritmos o sprints...
relacionado con el tema de la metodologías ágiles, scrums, y demás, está el tema de la "user stories", escribir definiciones de funcionalidad que son ya parte del código, y que te ayudan a anticipar muchas de las preguntas que son las que luego provocan retrasos, porque alguien no las supo hacer en su debido momento...
a ver si saco un rato para escribir sobre ello :)