Diseño funcional: cuando el negocio encuentra al software
Introducción al diseño funcional
El propósito del diseño funcional es definir los requerimientos a ser implementados por una solución de software. Sin importar la forma que tomen, las especificaciones funcionales tienen la intención de capturas qué cosa requiere hacer el software para apoyar a un usuario de negocio. A menudo, los diseños funcionales son revisados y aprobados lo mismo por involucrados de negocio que involucrados técnicos. Los usuarios de negocio confirman que, sí, esto es realmente lo que desean que el sistema haga. Los usuarios técnicos confirman que, sí, estos requerimientos son realizables, posibles de implementar y susceptibles de prueba. Para poder aprender más acerca de los detalles finos del diseño funcional y nuestro enfoque único en Engineering Industries eXcellence, nuestro equipo de mercadeo se sentó con uno de nuestros gurús técnicos principales y expertos de diseño funcional para una conversación genuina, cara a cara, con preguntas y respuestas.
Conozca a nuestro experto: Guillermo Padron
ZB: ¡HOLA GUILLERMO! GRACIAS POR REUNIRTE CON NOSOTROS ESTE DÍA PARA PLATICARNOS UN POCO MÁS ACERCA DE TI Y LO QUE HACES.
GP: Es un placer, ¡adelante!
ZB: PRIMERAMENTE, HÁBLAME UN POCO ACERCA DE TI Y TU HISTORIAL. ¿CUALQUIER COSA QUE TAL VEZ LA GENTE NO SEPA DE TI?
GP: Mis padres inmigraron a los EE. UU. desde Cuba en 1979 durante el gobierno de Fidel Castro. Cuba tenía un acuerdo con el gobierno de EE. UU. para permitir migrantes a Estados Unidos, y Castor usó esto como oportunidad para deshacerse de quienes no deseaba –prisioneros de estado, disidentes políticos del régimen comunista– ya te imaginas. En ese momento, mi padre era un prisionero político. Se le dijo a él y mi mamá que les subirían a una balsa a Florida, así que eso hicieron. Eventualmente llegaron a Nueva York y se asentaron en New Jersey. Nací ahí en 1991.
ZB: ¡QUÉ INCREÍBLE HISTORIA, G! NO SÉ BIEN A DÓNDE ENFILAR DESDE AHÍ, PERO DADO QUE ERES UNO DE LOS ESPECIALISTAS TÉCNICOS MÁS TALENTOSOS EN NUESTRO EQUIPO DE EEUU, ME PREGUNTO CÓMO ERAS DE NIÑO. ¿NACISTE PARA ESTAR EN ESTE CAMPO?
GP: Tal vez no nacido, pero definitivamente criado para este. En la escuela primaria, todo era Matemáticas y Ciencia. Me agradaban y resulta que era bastante bueno en ellas. Estas eran concretas, y era mucho más fácil para mí el comprender ya mismo cuál era la respuesta a un problema. Así era como funcionaba mi mente. También era que estaba en una escuela en la que esas materias se enfatizaban, ya que vivía en un área en la que las oportunidades educativas no eran siempre las mejores, de forma que los maestros animaban a los estudiantes a encausarse a escuelas prácticas y de comercio. Luego en el bachillerato, volteé a ver a Omar, mi hermano mayor, para inspirarme. El ingresaba al colegio para estudiar Ciencias Computacionales, y yo deseaba seguir sus pasos.
ZB: ¿CUÁL ES TU PRIMERA MEMORIA DE LA TECNOLOGÍA?
GP: Cuando era más joven, mi hermano y yo íbamos a visitar a papá en la oficina. Al terminar el día, si no soportábamos bien y todos se habían retirado de la oficina, él tal vez nos dejaría jugar unos cuantos juegos en la computadora. Eso me encantaba. Para cuando ingresé a high school, las computadoras personales comenzaban a ser mucho más comunes en casa, y entonces pudimos tener una en la nuestra. Siendo así, cuando esta se volvió mucho más disponible para mí, realmente me cautivó. ¡Salté al mundo de los juegos de computadoras y jamás di vuelta atrás!
ZB: MUY BIEN, PARA EL REGISTRO, DANOS ESAS CREDENCIALES EDUCATIVAS.
GP: Asistía a Rutgers University y me gradué con doble especialidad en Ciencias Computacionales y Matemáticas. Realmente no había nunca antes tocado un lenguaje computacional, pero sin duda quería ir para allá. Así que di mis primeros pasos durante un tiempo ahí… fueron variados cursos de programación, sistemas operativos, lenguajes. No me vino tan fácilmente. Aun puedo recordar momentos puntuales de frustración, así como de claridad, al intentar entender por qué el código que yo escribía no corría o por qué mi diseño no producía los resultados que esperaba. Pero, no puedes aprender a ser un buen solucionador de problemas sin contar con muchos problemas para resolver.
ZB: BIEN DICHO. ¿TIENES UN LADO CREATIVO?
GP: ¡Sí! Siempre me ha encantado escribir, los juegos, la música –la creatividad es algo central en todo ello–. Inicialmente, recurrí a la programación porque deseaba crear un juego de video. Si bien no tenía una mente puramente creativa, el diseño de videojuegos requiere una muy buena mezcla de conocimiento matemático técnico para asegurar que el sistema trabaje correctamente, así como requiere de ingenio para crear un mundo único, inmersivo e interesante en el que una persona desearía jugar.
ZB: ¿DECÍAS: DISEÑO DE VIDEOJUEGOS? PUES ENTONCES, ¿CÓMO LLEGASTE A ENGINEERING USA?
GP: Resultó ser que el mundo de los videojuegos es una industria increíblemente competitiva y retadora a la cual entrar, no realmente una que admita graduados universitarios sin experiencia alguna. Algún día, aún espero vivir mi sueño de videojuegos, pero sabía que de principio no era para mí. Yo deseaba aprender, crecer como profesional y expandir mi conjunto de habilidades técnicas, y Engineering Industries eXcellence me dio la oportunidad de hacer las tres cosas.
ZB: ¡SÍ! ¿QUÉ ES LO QUE HACES EN ENGINEERING USA?
GP: He trabajado en Engineering Industries eXcellence por un poco más de 5 años. Al comienzo, se me expuso a muchas áreas de experiencia práctica diferentes dentro de nuestra compañía. Tecnologías PLM, MES, SPC. Proyectos para capacitación de software de manufactura, validación de soluciones, integración de sistemas. Los clientes en Comidas y Alimentos, Dispositivos Médicos, Petróleo y Gas, Energía, Manufactura Química. Agradezco realmente esta diversidad de experiencias, ya que me ayudaron a desarrollar una comprensión profunda lo mismo de los procesos de manufactura como de los de implementación de soluciones. Esto ha sido crítico para mi éxito como Diseñador Funcional.
Diseño funcional en Engineering Industries eXcellence
ZB: OH, SÍ, EL CÉLEBRE DISEÑO FUNCIONAL. DE NUEVO, ¿QUÉ ES TODO ELLO?
GP: El diseño funcional consiste en tomar un requerimiento de negocio, que es lo que el cliente ultimadamente quiere que haga el sistema, y traducirlo a especificaciones técnicas que los desarrolladores puedan atender con base al sistema con el que funcionan. El diseño funcional es el momento de verdadera alineación entre negocios y TI, y como un Diseñador Funcional, soy responsable de asegurar que nada se pierde en la traducción.
ZB: CREO ENTENDER…
GP: Por ejemplo, digamos que un cliente desea un programa en donde puedan ingresar 2 números y la computadora proporcionará una suma. El Diseñador Funcional recibirá el requerimiento de negocios y lo convertirá en una serie de casos de uso, o especificaciones funcionales, que los desarrolladores podrán seguir para lograr el objetivo final. Entonces:
- Esta es la interfaz que deberás tener;
- Deberás tener dos campos;
- Necesitarás este botón para pulsar enviar;
- Cuando el usuario final lo pulsa, esto deberá pasar.
Claro, al entregar una solución de TI avanzada, estas especificaciones son mucho más extensas y completas.
ZB: ¿CÓMO FUNCIONA EL PROCESO DE DISEÑO FUNCIONAL? ¿ES QUE EN ENGINEERING USA TENEMOS UNA METODOLOGÍA ESPECÍFICA?
GP: La línea temporal y alcance de cada proyecto es diferente, pero en términos generales, seguimos una metodología agile en Engineering Industries eXcellence. Esto es una metodología basada en sprints, y aplica lo mismo a los aspectos de diseño funcional y los de desarrollo de nuestro proyecto. Un sprint cubre un pedazo de requerimientos de negocio de una lista grande. Básicamente, decimos: “Para este sprint, que durará x, nos concentraremos en x requerimientos y haremos que trabajen”. El beneficio del método agile es que habilita prototipos rápidos. Entre más cortos sean tus sprints, menos trabajo entregas por sprint, pero con mayor frecuencia podrá el cliente ver tu progreso y darte retroalimentación. En contraste, el modelo de cascada hará de la realización de cambios algo difícil y prolongado. Es mucho más fácil cambiar un diseño después de un sprint más pequeño que cambiar algo tras 8 meses de desarrollo, especialmente si el cliente tuvo oportunidad de observar o usar el producto. Cada producto cambia en una forma u otra una vez que el cliente gana una visión mejor del objetivo final.
ZB: PERO, SI EL DESARROLLO AGILE NO TIENE DESVENTAJAS, SERÍA LA ÚNICA METODOLOGÍA DISPONIBLE. ¿QUÉ TIENE DE NEGATIVO?
GP: Los proyectos complejos con un alto número de requerimientos no siempre se separan fácilmente en sprints. La desventaja de agile es que a menudo requiere que desconectes ciertas fases de proyectos que no debieran separarse, todo con el fin de mantener un sprint en un tamaño razonable. Como ejemplo, podrías tener un grupo de funcionalidades que se relacionan todas con cronogramas o gestión de inventarios, o lo que sea, pero ese grupo es demasiado grande como para ser gestionado en un sprint único, así que tienes que dividirlas. Como resultado, existe el riesgo de que lo que pase en el segundo sprint pueda afectar adversamente lo que se hizo en el primer sprint, requiriendo de más tiempo empleado en arreglar y volver a probar. También hay mucha presión en los sprints agile tempranos para proporcionar algo que pueda correr auténticamente temprano en el desarrollo. En ocasiones, esto significa emplear menos tiempo en esqueletos y herramientas organizacionales, lo cual puede terminar ralentizando el desarrollo más adelante. En ese punto es donde las relaciones con herramientas existentes y asociaciones son invaluables. Estos proporcionan mucho de los esqueletos preexistentes, de forma que podemos lanzarnos en franco a satisfacer los requerimientos del cliente. Pero con la mayor frecuencia, los beneficios de agile y la obtención de retroalimentación del cliente tan frecuente sea posible durante un programa superan los negativos y conducen a la entrega de una solución final mejor y más efectiva. Así que nos quedamos con esta.
ZB: ¿QUÉ COSAS CONSTITUYEN A UN BUEN DISEÑADOR FUNCIONAL?
GP: Como diseñador funcional, eres un aliado crítico entre el cliente que compra la tecnología y el equipo de desarrollo que desarrolla el software. Como el mediador principal entre negocio y software, cuentas con mucho control sobre cómo va a darse finalmente una estructura de solución. Con este poder, necesitas considerar ambas partes en cada paso de tu trabajo. Necesitas considerar no solo cómo es que un diseño lucirá visualmente para el usuario final, son también cómo (y si acaso) se puede desarrollar, probar y soportar. En ocasiones, lo que es bueno para una parte no es bueno para la otra. También, siempre debes de intentar entender lo que ocurre para obtener los mejores resultados a largo plazo para el diseño. Puedes diseñar algo fácilmente si no tienes restricciones y simplemente cargas un número interminable de requerimientos al equipo de desarrollo. Más, tu deseo es asegurarte de que tus desarrolladores cuentan con suficiente tiempo en su sprint para programar lo que tú diseñas. Al mismo tiempo, necesitas considerar cómo se probará ese diseño. Si tú sobre-diseñas cada aspecto de un requerimiento, crearás un escenario que es demasiado retador para que la validación le soporte. Estas intentando entender cuándo del diseño es explícito y obligatorio, cuánto del diseño necesita ser agregado por buenas prácticas de programación, y cuanta tolerancia deseas dar al diseño en forma tal que todos los requerimientos de negocio se satisfagan. Es una gran suerte de balanceo.
ZB: ¿QUÉ ES LO QUE TE DIFERENCIA COMO DISEÑADOR FUNCIONAL, GUILLERMO?
GP: En mis 5 años en Engineering Industries eXcellence, he sido parte de todos los aspectos diferentes de un proyecto de TI. He pasado mucho tiempo en el lado de consultoría en TI, mucho tiempo con el software, y mucho tiempo con operadores en el piso de manufactura. He visto de primera mano cómo mis diseños de propagan en lo que ocurre en el piso de producción. Eso me ha permitido tener una perspectiva única más allá de solo el escenario general de un programa. Sé que los usuarios usarán esto en su trabajo diario, y no quiero complicar su trabajo. Entiendo este impacto y lo tomo como una severa responsabilidad.
ZB: TE TENGO SOLO UNA PREGUNTA FINAL, Y TE DEJO REGRESAR A HACER TODAS LAS COSAS IMPORTANTES QUE HACES. ¿QUÉ ES LO QUE DISFRUTAS MÁS ACERCA DE LO QUE HACES?
GP: El diseño funcional me ha dado la oportunidad de aprender mucho acerca de las necesidades de la industria y la naturaleza de los proyectos de desarrollo de software de forma simultánea. Disfruto de mi rol porque este me permite comunicar con y obtener retroalimentación de todos los agentes que son impactados por mis diseños –la gente allá arriba, los usuarios finales y mis propios equipos de desarrollo y validación–. Mis diseños afectan lo que ellos hacen y cuán fácil o difícil resultan ser sus trabajos. Esta interacción me ayuda a entender cuando mis diseños son buenos y cuando fallan. Esto ha sido un factor clave tras mi crecimiento como especialista y la mejora continua del trabajo que produzco.
