Hay solamente una cosa que me está volviendo completamente loco de las startups y quizás otras empresas. Y esta es la pésima calidad o absoluta ausencia de trabajo colaborativo. Esto es muy fácil de identificar por los productos que estas lanzan al mercado hoy en día, muchos de estos no son pensados de antemano, no tienen al usuario en mente, carecen de pruebas para que estas cumplan con estándares de calidad mínimos o son muy difíciles de utilizar.
Antes de continuar, puedes leer este post o ver y escuchar esta información en formato de video en nuestro canal de Youtube, te dejamos el link por si prefieres este formato. 😃 👍
¿Por qué estamos tolerando todo esto?, es sumamente frustrante trabajar con software que no cumple con su objetivo, y es más frustrante aún trabajar en un software del cual no te sientes orgulloso de estar manteniendo.
Ha existido una degradación importante en la forma de trabajar de los equipos hoy en día, y lo primero que se me viene a la mente es, que puedo hacer yo para ayudarlos a ustedes.
Encarémoslo, muy dentro de nosotros sabemos que la parte más importante del desarrollo de software es la planificación.
Planificación
Existen muchas formas… y muchas NO formas de planificación. Convengamos lo siguiente, al ser este la parte más importante del proceso de desarrollo deberíamos destinarle una gran cantidad de tiempo.
Pero muchos entregan como requerimiento un post-it y de este esperan un producto final. Y lo más incorrecto y lo que más me molesta de esto no es el post-it, sino la falta de trabajo y profesionalismo de quien entregó el post-it.
Lo peor de un requerimiento mal tomado y mal planificado es que este puede terminar, irremediablemente en un bodrio, algo que no soluciona ningún problema, y no sirve de nada mas que para culparse entre los distintos miembros de la Organización.
Esto no nos ayuda en nada, necesitamos organizaciones que busquen ayudarse, que busquen colaborar entre ellos, que busquen solucionar un problema, y esto empieza desde la concepción.
Propuesta/solución
Pero lo bueno es que esto puede solucionarse, por cada historia de usuario o épica, redacten un pequeño documento que intente explicar cuál es el problema para que todos los involucrados sepan qué es lo que se necesita solucionar. En todo desarrollo de software, el desarrollador deberá tomar decisiones, sin que el consumidor final, jefe de proyectos, líder técnico o quien quiera que sea esté presente y, al ocultar el problema y entregar solamente el requerimiento no le estás permitiendo al desarrollador que haga lo que mejor sabe hacer, qué es pensar, diseñar, solucionar problemas.
Luego de anotar el problema viene el siguiente paso, redactar lo que quieres hacer.
Este es el momento para expresar tu creatividad y tu conocimiento técnico. En el mismo documento que nosotros vimos antes, agregaremos un apartado donde podremos extendernos más. Podemos utilizar la forma que queramos para redactar esta parte, casos de uso, bdd lo importante es qué pensamiento debe quedar bien plasmado en el documento y, lo más importante, si este documento lo leen dos personas deben entender exactamente lo mismo, la libre interpretación en estos documentos es algo que no queremos.
Luego de redactar este documento viene la parte más importante y donde todos aprendemos, la revisión grupal de este.
Esto también sirve para medir el interés de los integrantes de tu equipo en colaborar, deja un mensaje en el chat de tu empresa preguntando a quién le gustaría asistir para revisar el documento y le envías una invitación solo a quienes la pidan. Este tipo es muy importante, ya que el equipo debe ser autogestionado. Tú no quieres que todos vayan por obligación, tú quieres que vayan porque quieren hacerlo. O también puede ser que estén ocupados. Esto sirve para medir el interés en colaborar del equipo.
Ahora viene la parte interesante, prepárate porque la intención acá es hacer muchas preguntas sobre este documento que redactaste.
- ¿Consideraste el escenario «a»?
- ¿Cuántos registros estamos manejando?
Acá todos deben presentar tu opinión y, lo más importante, no debes defender tu documento a muerte, el equipo está para ayudarte y todas las opiniones o preguntas son válidas. Y esto te ayudará con el tiempo para redactar mejores documentos.
Luego de esto, debes actualizar el documento con las observaciones que te hicieron. Lo compartes online para que le den la última revisada y vean que todas las observaciones fueron incluidas.
El siguiente paso es crear los tickets, tarjetas de Kanban, la lista de tareas… eso da lo mismo, todos hacen lo mismo al final del día.
Lo más importante de esto es que es un proceso asíncrono, un día redactarás documentos, el día siguiente estarás programando, al día siguiente estás revisando los documentos que escribió algún compañero tuyo, al día siguiente programando, y así sucesivamente. Es por esta razón que es sumamente importante que el dueño del producto, product owner, CEO o quien sea que esté recopilando los requerimientos tenga siempre un backlog lleno de historias de usuario, épicas o requerimientos a ser desarrollados.
Y con esto espero haber podido ayudarte, y para que planifiques más y cada vez mejor y vayas practicando la parte que nosotros sabemos hacer mejor que es «pensar».
Y esto ha sido todo de este post, si te ha encantado, ¡golpea al botón de me gusta!, dejanos un comentario, y visita nuestra Academia Hola Mundo, donde encontrarás todos los cursos para formarte como un desarrollador o desarrolladora.
Y para no perderte nada, no olvides suscribirte a este blog, seguirnos en todas las redes como Youtube, Twitter e Instagram, y por último, te invitamos a escuchar nuestra música «Hola Beats«, diseñada para ayudarte a concentrarte y acompañarte en tu aprendizaje o trabajo, la puedes encontrar en Spotify, Apple Music, Amazon Music, Youtube Music y Deezer.
¡Hasta la próxima!, y chao mundo
Deja un comentario