Cuando hablamos de implantación de procesos, debemos de pensar en todas las partes que vamos a cubrir, empezando por la parte que aplica al diseño del trabajo, definición y análisis, continuando con el desarrollo del trabajo y cumpliendo, en diferentes puntos del mismo, validaciones y controles.
Un proceso debe de ser uno, pero afectará a muchos puntos, personas y se tendrán que dar y cumplir una serie de pautas o pasos que puedan garantizar su correcto funcionamiento. Estas pautas o pasos tienen que ser definidas y estipuladas de una manera férrea y sin fisuras, teniendo siempre las respuestas del porqué se realizan y en el caso de que exista una duda o una fuga, tener casuísticas que nos ayuden a retomar el camino de nuevo y a volver a poner en orden todas las piezas.
Un proceso completo debe de comenzar en la fase de diseño de la funcionalidad en la que vamos a trabajar, quizá esta sea la pieza fundamental del conjunto, ya que si desde aquí, se comienzan a realizar las cosas no del todo bien, todo lo demás, caerá por su propio peso. Por ejemplo, un desarrollo sin una buena base de requisitos, acabará siendo un desarrollo vacío y que no se ajuste a las necesidades, no por el hecho de que se hagan las cosas mal, si no, porque el trabajo se basa en algo que ya viene desde el principio no del todo correcto. Otro ejemplo que podemos encontrarnos será en la definición de casos de prueba, si no partimos de unos buenos requisitos y criterios de aceptación, la cobertura de los casos no será la idónea.
Si partimos de una primera fase rígida y bien realizada, lo demas, irá rodado, eso es seguro.
En toda esta "sección" del proceso, entrarán en juego una serie de buenas prácticas o recomendaciones que se pueden resumir en los siguientes puntos:
- Al realizar los requisitos, es esencial hacer un trabajo de consensuación con los equipos de desarrollo. Esto permitirá ajustarse más a la realidad, jugando con las dos visiones, la de negocio y la técnica.
- Es importante escuchar las necesidades de los clientes y usuarios. Esto es un estudio de mercado gratuito y posiblemente podremos tener ideas que nos hagan destacar del resto de competidores.
- La realización de un a Roadmap nos aportará visibilidad y firmeza, ya que el trabajo estará mejor organizado y permitirá dar luz a los clientes, pudiendo proporcionarles fechas y datos reales del avance de los diferentes desarrollos o funcionalidades abiertas o marcadas durante un periodo de tiempo.
- El Roadmap no debe de ser puramente de negocio, si no que debe de tener ciertos hitos técnicos, esto permitirá aportar valor a los diferentes equipos de desarrollo y que no de la sensación de quedarse en segundo plano. Una buena repartición de componentes de negocio y técnicos es indispensable.
Como veis, todo comienza de esta base, y por mucho empeño que se ponga en las siguientes, no llegarán a funcionar del todo bien si esta primera no está engrasada hasta el último milímetro.
Debe de existir un contacto directo entre los equipos de producto o negocio y los técnicos, buscando siempre homogeneizar caminos e ir de la mano en la realización y diseño de las funcionalidades del proyecto donde nos embarquemos. Eso si, este contacto directo no debe de ser solo al inicio, si no que debe de existir durante todo el desarrollo de la funcionalidad, en forma de puntos de control, ajustes, reuniones o incluso demos, donde mostrar avances y pudiendo recolocar las piezas en el caso de que se hubieran descolocado.
Con las nuevas formas de trabajo lejos quedan los tiempos donde se trabajaba de manera independiente, ahora los equipos deben de ser multidisciplinares, transversales y que trabajen mano a mano diariamente. Los modelos de trabajo actuales así lo demandan y los resultados en diferentes empresas lo reafirman. Ademas, con las metodologías emergentes esta filosofía es mucho mayor y, aunque, no estoy de acuerdo del todo con ciertas ideas, si que es verdad que el trabajo fluye mucho mejor, más rápido y habitualmente, con una mejor calidad.
0 Comentarios