Publicado por Grafix Digital con autorización de Whattheythink.com

Construir un buen software toma un (pequeño) grupo de personas con diferentes conjuntos de habilidades. No trate de construir un software con sólo un desarrollador, usted terminará con el software que sólo los desarrolladores quieren utilizar!

El software se compone de código. El código está escrito por desarrolladores de software. El propósito de este artículo es desacreditar la idea de que cuando se necesita software, lo único que se necesita es un desarrollador de software.

Hacer buen software no es simplemente una cuestión de escribir código, al igual que obtener productos de impresión de alta calidad de su planta no se logra sólo cuando se imprime. Usted necesita su equipo de oficina al frente para capturar los detalles exactos de la orden, necesita su equipo de preimpresión para preparar y probar los archivos del arte, necesita su equipo de acabado y envío para hacer el trabajo de postproducción para entregar el producto al cliente adecuado a tiempo.

Al igual que el resultado de los productos de impresión que producen depende de lo que ocurre antes y después de la ejecución de la impresión, el software depende en gran medida del pensamiento, la estrategia y el diseño que sucede antes de que el código esté escrito y la prueba después de que el código este compilado.

Un buen software está determinado por el buen pensamiento y el diseño por adelantado y buenas pruebas en el back-end (lado interno). El pensamiento inicial es generalmente relegado al gerente de producto o propietario del producto de la solución, el diseño es idealmente realizado por una interfaz de usuario (UI) o diseñador de experiencia de usuario (UX). La prueba o el aseguramiento de la calidad (QA) son idealmente desarrollados por alguien con un contexto comercial sobre la solución (por ejemplo, alguien que pueda predecir lo que los futuros usuarios podrían hacer para romper el sistema).

Un software deficiente suele ser el resultado de pensar que un desarrollador de software puede desempeñar todos esos roles simultáneamente.

Tengo una regla muy estricta en los proyectos de software que ejecutamos, los desarrolladores no toman decisiones UI / UX. Todos en el equipo pueden dar retroalimentación, dar sus ideas, hablar, pero las decisiones UI / UX se enrutan al experto UI / UX. Nunca deja de sorprenderme cómo todos en el equipo piensan que conocen mejor la experiencia del usuario. También nunca deja de asombrarme cuando entregamos desafíos de UI / UX a nuestro talentoso recurso, ellas  siempre regresan con soluciones que nos recuerdan por qué no deberíamos tomar estas decisiones sin ellas. La interfaz de usuario del software ES LA SOLUCIÓN para los usuarios. Las decisiones tomadas allí son críticas para el éxito y la adopción del producto.

¿Qué aspecto tiene el software cuando los desarrolladores toman decisiones de UI / UX?

Enfocan casi todas las soluciones de MIS de impresión en una pista. Pantallas llenas de cosas, zonas difíciles de leer, agrupaciones sin sentido de tareas, muchas pestañas, menús complejos y submenús – ¡sabes exactamente de lo que estoy hablando! Lo que es una buena experiencia de usuario – irónicamente, es una experiencia de usuario que no es memorable porque no se interpone en su camino. Usted no recuerda la experiencia del usuario porque acaba de obtener lo que necesitaba hacer sin pensar!

La creación de un buen software toma un (pequeño) grupo de gente bien coordinada. Los recursos que considero críticos son los siguientes:

1. Dueño de producto / gerente de producto: esta es la persona que es en última instancia responsable de lo que el producto se convierte. Tienen que tomar las decisiones sobre lo que entra en el producto, y lo más importante lo que NO lo hace. Decidir qué NO hacer es igual de importante. Más no es mejor con el software, pero más es siempre más complejo. Un propietario de producto escribe las historias de usuario (requisitos) que los desarrolladores utilizan como manual de instrucciones para escribir el código). El propietario del producto es el gran traductor entre los retos empresariales y las soluciones técnicas. Este es un trabajo difícil, cuando la gente es buena en ello, crean increíbles herramientas de software. Cuando a la gente no se le facilita ésta tarea, se gasta mucho tiempo y dinero construyendo la cosa equivocada, resolviendo los problemas equivocados.
2. Arquitecto: es la persona que es responsable en última instancia de la calidad técnica del producto. Esta persona puede no escribir una sola línea de código. Esta es la persona que debe supervisar a las personas que escriben el código. El arquitecto de software es como un arquitecto de edificios – están planeando el diseño técnico de la solución.
3. UI / UX: un diseñador toma las historias de usuarios que son escritas por el propietario del producto y luego las convierte en una interfaz de usuario que tiene en cuenta las limitaciones de la plataforma que está construyendo. La entrega del diseño es una imagen de cómo será el software y notas sobre cómo se comportará (por ejemplo, al hacer clic en este botón, esta acción sucede). Y cada vez más importante cada día, al mirar esta página en su dispositivo móvil, así es como el diseño “responde” a la pantalla estrecha – el móvil se está convirtiendo en el punto de acceso a Internet dominante. No diseñe nada que no responda totalmente a todos los tamaños de pantalla.
4. Desarrolladores: el desarrollador o los desarrolladores son los que realmente escriben el código. Consumen las historias de los usuarios y escriben un código que idealmente resuelve los desafíos descritos por el propietario del producto. Los desarrolladores pueden tener un impacto positivo real en la calidad del producto basado en su cuidadosa interpretación de las historias de los usuarios y la calidad del código que escriben. Su capacidad para acceder al propietario del producto es clave para su éxito, ya que la programación ágil no es pesada en la documentación por lo que se basa en la comunicación diaria entre el propietario del producto y los desarrolladores.

A menudo trato de hablar a los impresores de la construcción de software personalizado porque sé que para hacerlo bien, se necesita un pequeño equipo y esto significa tiempo, esfuerzo e inversión. Hay muchas razones para construir software personalizado o lo que me gusta pensar en el montaje de las mejores soluciones para resolver los desafíos empresariales únicos. Por ejemplo, si se encuentra en un negocio de nicho muy específico y desea una solución de comercio electrónico de empresa a empresa que admita flujos de trabajo únicos. Nunca sugeriría que empezara desde cero. Le sugeriría que compre la licencia o utilice software de código abierto para toda la “funcionalidad esperada” como carril de compras, autenticación de usuarios, catálogos, etc., y luego construya lo que lo hace especial sobre esa tecnología. Este enfoque limita su inversión en software personalizado mientras que le brinda la libertad de resolver sus desafíos únicos.