¿Existe una desconexión entre los desarrolladores y los usuarios finales? ¿Por qué o por qué no?

1. Desarrollo de sitios web

No creo que sea tan simple. Detectar errores no equivale automáticamente a deshacerse de ellos.

Según mi experiencia: cuando creamos sitios web, generalmente hay una fecha límite cuando el sitio debe ponerse en línea. Antes de ese día, hay una revisión Alfa, una revisión Beta e innumerables bucles de retroalimentación con los clientes. A veces, nuestros clientes ni siquiera son los clientes finales, por lo que sus comentarios pueden contradecirse entre sí. A veces cambian de opinión y quieren que revocamos una actualización. Todo esto exprime nuestro tiempo de desarrollo y tiempo de prueba.

Para que una página web funcione, debe probarse completamente en todos los navegadores. Lo que para nosotros generalmente significa las dos últimas versiones de Chrome, Safari y Firefox en Windows y OS X; IE8 ~ 11; IOS 6 y 7 en iPhone4, 4s, 5 y iPad; Samsung Galaxy Note 3, S4, S3; Algún otro Android Pad dependiendo de los requisitos del cliente. Casi todos los sitios que creamos responden ahora, por lo que el sitio debe funcionar desde 320 px hasta más de 1440 px, en todas las plataformas anteriores, tanto verticales como horizontales. Cuando tenemos tiempo extra, nos preocupamos por la suavidad de la animación cuando el usuario arrastra la ventana.

Lo que pasa con el sitio web es que, a pesar de escribir todo con la expectativa de que pueda cambiar en cualquier momento (por ejemplo, evitar el estilo explícito de píxeles), no puede saber con certeza cuándo podría decidir romper. Tal vez todo funcione bien ayer, pero con una letra más en la línea hoy simplemente se niega a mostrarse en dos líneas separadas en Samsung S3 con modo horizontal.

En teoría, el sitio necesita ser probado completamente con cualquier actualización trivial. Pero la realidad es que simplemente no tenemos tanto tiempo, con nuevos requisitos cada dos días.

Para aprovechar al máximo nuestro tiempo, nuestro flujo de trabajo del día, cuando ingresamos en la fase de actualización de comentarios cerca del final:

  • enumerar las actualizaciones del día
  • actualizar en el orden de importancia
  • prueba y enumera todos los errores
  • fijar en el orden importancia

Esto podría continuar hasta y, a veces, después de que el sitio se conecte. Nunca será 100% libre de errores. Es solo que tenemos que hacer que nuestro tiempo cuente tratando con los relativamente más grandes, hasta el último segundo.

2. Aplicaciones de escritorio / teléfono

No es mi área de desarrollo, sino como un usuario final que constantemente se encuentra con errores:

  1. No me sorprendería demasiado si no tienen desarrolladores ilimitados, y que sus desarrolladores son seres humanos que solo tienen 24 horas al día
  2. Es posible que los desarrolladores no experimenten los errores de la misma manera que los usuarios finales. Si ellos mismos no son grandes usuarios, es posible que no consideren el mismo error como molesto
  3. No informan a los usuarios, ni a los comentarios de los usuarios directamente, informan a quien toma la decisión sobre su flujo de trabajo. Cuando la compañía crece cada vez más con sobrepeso, las capas entre desarrolladores y usuarios finales se vuelven más gruesas. Es como si los usuarios finales fueran clientes de clientes de clientes de clientes de desarrolladores. Cada uno solo informa a su gerente / cliente y, a veces, los desarrolladores no tienen mucho que decir en la dirección de su trabajo

Entonces sí, creo que están desconectados hasta cierto punto. ¿Cómo reducir esta brecha? Idealmente:

  • Los desarrolladores se lanzaron a crear esta aplicación porque la necesitan realmente, no porque alguien haya dado la orden. Y entonces usan la aplicación con entusiasmo, todos los días. Tienen que ser los propios usuarios finales.
  • Los desarrolladores podrían tener en cuenta cada comentario de los usuarios finales directamente, antes de discutir entre ellos sobre qué características podrían ser dignas de implementar, o qué error debe eliminarse en este momento
  • No tienen que preocuparse por informar a otra persona que no sean los usuarios finales, por ejemplo, un gerente horrible que insiste en que hagan X en lugar de Y, y amenaza con hacer Z si se oponen
  • Tienen comida para comer, lugar para vivir, tiempo suficiente y una fecha límite saludable.

Estos deberían hacer.

No es tan simple como eso. Sabemos cómo hacer que el software esté prácticamente libre de errores. Lo hacemos todo el tiempo. El código RTL que se utiliza para generar todos los circuitos digitales modernos es, para todos los efectos, software. No está completamente libre de errores, pero está prácticamente libre de errores en comparación con la mayoría del software que se envía como software.

¿Cómo lo haces? Dedicas el 80% de tu tiempo a las pruebas. En hardware, la firma lo es todo, el desarrollo es básicamente nada. En el software, típicamente apenas el 20% del total de horas dedicadas a un proyecto estará en pruebas, y las pruebas no reciben elogios de nadie.

¿Por qué hay esta diferencia cultural? Pura economía. El parcheo de un error de software no cuesta casi nada: simplemente se elimina con la próxima implementación o la próxima versión, que en estos días llega muy pronto. Reparar un error de hardware es muy costoso: existe el costo de piezas muertas, solucionar el problema si es posible en el software y el costo de la reparación de la máscara, que podría ser de millones de dólares.

Los usuarios finales pueden odiar los errores, pero lo odiarían aún más si las compañías de software gastaran el 80% de sus recursos en pruebas. Tendrías un software muy bien probado que no hizo casi nada.

El problema es a menudo el enfoque de desarrollo moderno.

  1. Las empresas / webapps de hoy dedican demasiado tiempo a la microoptimización. Se preocuparán más por mover un logotipo un píxel a la izquierda que por el hecho de que sus enlaces de resumen no se abren con URL absolutas y, por lo tanto, son inútiles (Quora como ejemplo). Se preocuparán más por cómo se ve la página de inicio que nadie usa, pero no podrán implementar la sincronización de notificaciones, una característica muy básica y fácil de implementar, durante años (Twitter como ejemplo). Se preocuparán más por reemplazar los menús contextuales nativos con soluciones personalizadas con mucho JavaScript, que el hecho de que esta diarrea de JavaScript hace que su aplicación consuma 3 GB de RAM (Google+ como ejemplo).
  2. Los desarrolladores que los crean no son sus usuarios. Cuando no es un usuario activo de su propio producto, no puede desarrollarlo ni probarlo correctamente. A propósito de las pruebas …
  3. Demasiada confianza en las pruebas automatizadas que no son indicativas del uso en la vida real. Puede escribir tantas pruebas de comportamiento, funcionales o unitarias como desee, pero un usuario con un dedo que hace clic con picazón puede solucionar todos los casos límite definidos por la prueba. Demasiado enfoque en la automatización, muy poca retroalimentación humana real.
  4. Las aplicaciones de hoy tienen una vida corta, y la hiperconectividad del mundo de hoy asegura que ninguna idea sea única por mucho tiempo. Si no entrega primero, no entrega en absoluto, incluso si entrega un producto malo. Esto es especialmente cierto en dispositivos móviles: las aplicaciones en dispositivos móviles mantienen el interés del usuario durante un par de meses como máximo, si eso es así. Si dos compañías tienen la misma idea, la que envía primero gana, incluso si envía un producto defectuoso, porque lo único que les importa es que la competencia parezca imitadores ahora. Tienen reclamo de originalidad, y por lo tanto mantendrán el interés del usuario. ¿Te acuerdas de Flappy Bird? ¿Cuánto tiempo vivió esa tendencia? Ahora intenta recordar cuánto tiempo de vida tuvo cualquiera de sus clones. Las aplicaciones actuales son barras de magnesio encendidas: arden brillantes, pero arden rápidamente y se convierten en polvo demasiado pronto.

Entonces, ¿están los desarrolladores y los usuarios finales en un estado de desconexión? Definitivamente sí. Los desarrolladores se han convertido en drones para los altos mandos, los altos mandos solo buscan complacer a los inversores y accionistas, y los accionistas no son usuarios, solo “observadores de cuentas bancarias”. Es la odiosa cultura de inicio de hoy que está haciendo esto, y no parece que mejore antes de que empeore.

More Interesting

¿Cuál es la mejor manera de ganar dinero y obtener experiencia en el desarrollo de software para un estudiante en la universidad?

¿Puede un desarrollador de software usar stackoverflow en su lugar de trabajo?

¿Qué se debe esperar con una carrera en desarrollo de software?

Además de OOP y la estructura y algoritmo de datos, ¿qué fundamentos de las ciencias de la computación deben poseer todos los desarrolladores de software (por ejemplo, compiladores)?

¿Qué trabajo es mejor: un desarrollador de software o un analista de negocios?

¿Cuáles son los componentes del software y las diferentes fases del desarrollo del software?

¿Tiene sentido establecer la meta de trabajar como desarrollador de software a la edad de 40 años? Un profesor dijo una vez que a la mayoría de los trabajos no les gusta contratar personas mayores.

Para un desarrollador, ¿qué camino es bueno para una carrera futura: desarrollo de .NET / SharePoint o desarrollo móvil (Android / iOS / HTML5)? ¿Cuáles son las perspectivas profesionales y las ganancias?

Cómo conseguir un trabajo de desarrollador de software en Japón

¿El SOW es proporcionado por el cliente o por el proveedor (que se supone que debe diseñar y desarrollar un software)? ¿O es establecido por ambos?

¿Por qué seguimos teniendo dificultades para medir el progreso a medida que se desarrolla el software?

Dentro de un año, ¿alguna startup en Sydney me emplearía para una pasantía remunerada como desarrollador junior de software? ¿Por qué o por qué no?

¿Los desarrolladores web fallaron los desarrolladores de software?

¿Por qué algunos programadores informáticos desarrollan un software sorprendente o nuevos conceptos, mientras que otros están atascados con el trabajo de programación básica?

¿Qué compañías de software apoyan y / o han creado las mejores comunidades de desarrolladores?