![\"eficacia](\"\/app\/uploads\/2024\/05\/1tR8fGHRhmgTIZqb1ad_X-Q.jpeg\" "\\"eficacia")
<\/p>\n
Todos queremos ser delgados y \u00e1gil<\/a> para que el resultado de nuestras actividades, medido en cifras, sea lo m\u00e1s alto posible. Aunque centremos la mayor parte de nuestra energ\u00eda en reducir las p\u00e9rdidas, al final tenemos en cuenta el beneficio que ha aumentado gracias al ahorro generado.<\/p>\n Estos ahorros caen en el mismo saco que el resto de factores y s\u00f3lo quedan al alcance de los m\u00e1s curiosos. De este modo, perdemos el foco y omitimos involuntariamente un mont\u00f3n de valiosas datos<\/a> y, en \u00faltima instancia, la inteligencia.<\/p>\n Aprender de los propios errores es una habilidad especialmente \u00fatil (aunque costosa), pero la cultura organizativa<\/a> y la diplomacia que conlleva esta capacidad no siempre ayudan. A menudo ocultamos el impacto negativo de las finanzas con palabras \"cortina de humo\". Cuando un inversor grita \"\u00a1He perdido mi dinero!\", el gestor se lo comunica al equipo<\/a> diciendo \"deber\u00edamos ser m\u00e1s eficaces\" y todos buscamos por defecto nuevas soluciones y mejoras; en lugar de mirar atr\u00e1s, buscamos constantemente formas de avanzar.<\/p>\n Mientras tanto, las p\u00e9rdidas suelen ser la clave para sacar las conclusiones correctas. Si repasamos los pasos de cierto flujo en el proceso sin la debida consideraci\u00f3n, lo m\u00e1s probable es que las siguientes soluciones est\u00e9n infectadas de los mismos errores.<\/p>\n Por ejemplo:<\/em><\/strong>\u00a0<\/p>\n Un peque\u00f1o equipo de JS<\/a> Los programadores no proporcionan la funcionalidad en el plazo previsto. El inversor, deseoso de acelerar el desarrollo, ordena contratar a un nuevo programador. Introducir a una nueva persona en el proyecto distraer\u00e1 al equipo, lo que ralentizar\u00e1 a\u00fan m\u00e1s el avance del proyecto.<\/p>\n Si el inversor comprendiera mejor las razones de la ineficacia del equipo, llegar\u00eda a la conclusi\u00f3n de que s\u00f3lo aprovecha su potencial en 60-70%. Un equipo mejor y unos d\u00edas de trabajo dedicados a la automatizaci\u00f3n del trabajo resolver\u00edan el problema.<\/p>\n Por desgracia, ahora tiene que pagar a otro promotor que trabajar\u00e1 en el mismo equipo y su eficiencia tambi\u00e9n ser\u00e1 de 60-70%.<\/p>\n Soluci\u00f3n A:<\/strong><\/p>\n \nA partir de ahora el proyecto cuesta $20.200 \/ mes<\/p>\n Gasto total en 12 meses: 12 * 20.200 + 10.000 = $252.400<\/p>\n Soluci\u00f3n B:<\/strong><\/p>\n \nA partir de ahora el proyecto cuesta $30.000 \/ mes<\/p>\n Gasto total en 12 meses: 12 * 30.000 = $360.000<\/p>\n Dos desarrolladores trabajando a 100% hacen aproximadamente lo mismo que tres desarrolladores trabajando a 60-70%. El inversor pagar\u00e1 m\u00e1s de $ 100.000 m\u00e1s al a\u00f1o por la misma capacidad de procesamiento debido a una decisi\u00f3n de dise\u00f1o err\u00f3nea.<\/p>\n Agilidad en el proceso no significa necesariamente esforzarse por conseguir una cobertura de pruebas 100% o batir el r\u00e9cord de rendimiento. Si bien estas m\u00e9tricas proporcionan una visi\u00f3n general del estado t\u00e9cnico del proyecto, son tan insignificantes desde la perspectiva del cliente final que no es necesario alcanzar un estado ideal en un proceso verdaderamente \u00e1gil, ya que no aportan beneficios reales. mercado<\/a> valor.<\/p>\n Desarrollar soluciones t\u00e9cnicas perfectas requiere mucho compromiso por parte del equipo y una comunicaci\u00f3n mucho m\u00e1s extensa. Como resultado, los parches funcionan m\u00e1s despacio y el proyecto se hace pesado por el exceso de desarrollo.<\/p>\n Desarrollo \u00e1gil<\/a> se trata de ofrecer una c\u00f3digo<\/a> con el m\u00ednimo esfuerzo. Las pruebas de c\u00f3digo son, sin duda, una buena pr\u00e1ctica y las pruebas dicen mucho sobre el funcionamiento del c\u00f3digo, pero no deben hacerse por el mero hecho de hacerlas y presumir de ello - la calidad t\u00e9cnica \u00f3ptima de las soluciones se encuentra en alg\u00fan punto entre el m\u00ednimo determinado por la equipo de desarrollo<\/a> y el m\u00e1ximo limitado por el presupuesto.<\/p>\n En \u00faltima instancia, la perfecci\u00f3n no lleva a ninguna parte. Curiosamente, incluso la cuesti\u00f3n de la seguridad est\u00e1 sujeta a esta regla: te\u00f3ricamente, cualquier sistema puede ser pirateado. Sin embargo, el m\u00ednimo de desarrollo antes mencionado debe ser correspondientemente m\u00e1s alto y relevante para el peso, la escala y el coste de las consecuencias potenciales de los percances del c\u00f3digo. A menudo, en lugar de escribir el m\u00f3dulo de inicio de sesi\u00f3n desde cero, que siempre est\u00e1 cargado con un alto riesgo de error y de introducir vulnerabilidades de seguridad, es mejor utilizar, por ejemplo, el bot\u00f3n \"Iniciar sesi\u00f3n con Google\", cuya correcta implementaci\u00f3n es relativamente r\u00e1pida y segura.<\/p>\n Mientras el objetivo sea un plazo de comercializaci\u00f3n corto, las hip\u00f3tesis demasiado ambiciosas resultan contraproducentes. En un proceso aparentemente perfecto, el exceso de entusiasmo puede ser un despilfarro de recursos<\/a>.<\/p>\n El dise\u00f1o centrado en el usuario es genial. La cooperaci\u00f3n centrada en el ser humano es m\u00e1s importante. Cuando el equipo se comunica en la misma longitud de onda, puede reducir espont\u00e1neamente m\u00e1s p\u00e9rdidas potenciales.<\/p>\n A UX<\/a> dise\u00f1ador que est\u00e9 al d\u00eda de las tecnolog\u00edas frontales no propondr\u00e1 una soluci\u00f3n al MVP<\/a> fase que consumir\u00e1 un tiempo excesivo en la fase de aplicaci\u00f3n.<\/p>\n Un desarrollador frontend que conozca la heur\u00edstica de usabilidad podr\u00e1 ajustar la interfaz a una resoluci\u00f3n de pantalla determinada sin necesidad de que intervenga el dise\u00f1ador de UX: arreglo r\u00e1pido, vista previa, aceptar.<\/p>\n Trabajar en una aplicaci\u00f3n requiere sincronizar las actividades de personas con perfiles de competencias completamente diferentes. Necesitas conocer la distribuci\u00f3n de competencias en tu equipo para ofrecer valor a tus clientes con eficacia.<\/p>\n Un equipo comprometido y sincronizado es un generador de ahorro clave. Este tipo de agilidad requiere un desarrollo \u00f3ptimo del producto<\/a>.<\/p>\n El buen rendimiento de un equipo as\u00ed entendido es sumamente dif\u00edcil de conseguir, sobre todo en la era de la trabajo a distancia<\/a>. Las empresas que han sido \"amigas de lo remoto\" durante a\u00f1os tienen una ventaja significativa en este campo sobre las que se han visto obligadas a poner a punto la organizaci\u00f3n durante el cierre y acaban de conocer los nuevos m\u00e9todos y formas de comunicaci\u00f3n.<\/p>\n En el contexto de las crecientes necesidades de comunicaci\u00f3n, herramientas como Whimsical, Miro, Mural, Figma y Balsamiq registran un impresionante aumento de popularidad.<\/p>\n Sin duda, el bloqueo y la necesidad de trabajar a distancia han desempe\u00f1ado su papel en esta explosi\u00f3n de usuarios. Creo que la selecci\u00f3n de la herramienta debe ajustarse a las preferencias individuales, pero echemos un vistazo a Miro:<\/p>\n La popularizaci\u00f3n de estas herramientas impulsa naturalmente el aumento de popularidad de las propias metodolog\u00edas. Alguien que ha comprado Miro para trabajar con personas tiene acceso a docenas de otras plantillas que pueden resultar interesantes e influir positivamente en el trabajo diario del equipo.<\/p>\n Siempre hay que dotarse de herramientas que agilicen el flujo de informaci\u00f3n en el proyecto. La apertura a nuevas herramientas y m\u00e9todos tambi\u00e9n es una de las bases de la eficacia. desarrollo de productos<\/a>.<\/p>\n Dise\u00f1adores experimentados tanto de la interfaz como del arquitectura de software<\/a> suelen detectar varias soluciones potenciales que deben verificarse al principio de la cooperaci\u00f3n y buscan eficazmente inspiraciones adecuadas o incluso soluciones ya preparadas en el mercado. Un buen ejemplo es el framework Material UI, que suele ser una apuesta segura en la fase de prototipo<\/a>.<\/p>\n A veces, basta con revisar algunas implementaciones en Behance o Dribble y utilizar la inspiraci\u00f3n para desarrollar un mood board y luego pas\u00e1rselo al desarrollador. Esta persona lo utilizar\u00e1 para armar un cliqueable prototipo<\/a> que pueden presentarse a los primeros usuarios para recabar sus opiniones. Este esfuerzo org\u00e1nico por conseguir un proceso eficaz en personas comprometidas y con mentalidad de dise\u00f1o es natural.<\/p>\n Si quiere ofrecer productos digitales de forma eficaz, tiene que dejar que la gente haga su trabajo. Usted sabe qu\u00e9 valor\/servicio quiere ofrecer a sus clientes: eso es suficiente. Un equipo de proyecto competente y bien gestionado sabr\u00e1 mejor que nadie c\u00f3mo ofrecer este valor\/servicio lo antes posible con la rentabilidad necesaria.<\/p>\n Demuestre su confianza, comparta la responsabilidad y \u00e1brase a una verdadera comunicaci\u00f3n bidireccional para que su producto<\/a> ser\u00e1 mejor y te quitar\u00e1s de encima la carga de hacerlo todo t\u00fa solo, que a menudo resulta agotadora para fundadores y empresarios. En The Codest<\/a>Adem\u00e1s, trasladamos este principio no solo a los proyectos, sino tambi\u00e9n a los procesos internos; probablemente por eso disfrutamos de altos \u00edndices de retenci\u00f3n tanto de clientes como de empleados (historia real, ambos> 90%).<\/p>\n Reg\u00e1lese un poco de pereza, transfiera con valent\u00eda la responsabilidad y despr\u00e9ndase de cualquier trabajo redundante que no sea necesario para avanzar: las funcionalidades que ser\u00eda \"agradable tener\" siempre pueden esperar.<\/p>\n El proceso de creaci\u00f3n de un producto digital es una colisi\u00f3n constante de diferentes perspectivas, experiencias y fuentes de informaci\u00f3n; cada una de esas colisiones conlleva el riesgo de tomar una decisi\u00f3n de dise\u00f1o equivocada.<\/p>\n Una buena comunicaci\u00f3n interna reduce este riesgo, pero es s\u00f3lo una cara de la moneda. La cuesti\u00f3n de c\u00f3mo mantenerse en contacto con el mercado sigue sin respuesta.<\/p>\n Inteligencia de Negocio, Atenci\u00f3n al Cliente, departamentos de investigaci\u00f3n UX y muchos otros - al igual que la equipo de desarrollo<\/a>deben esforzarse por alcanzar el m\u00ednimo necesario para dar respuestas concretas a las preguntas formuladas por el propietario del producto o el equipo de UX.<\/p>\n La propia marca y la estrategia de comunicaci\u00f3n de la marca tambi\u00e9n son importantes. Sirven para construir una relaci\u00f3n cualitativa con los clientes, que luego se traduce en su compromiso. Si quiere hacer preguntas a los clientes, debe asegurarse de que est\u00e1n dispuestos a responderlas. El tono de su voz importa.<\/p>\n Es cierto que estar en contacto permanente con el mercado permite definir las trayectorias adecuadas para que el proyecto remonte el vuelo. Menos obvio es el hecho de que la necesidad de este contacto debe plantearse desde el principio del proyecto, en torno a la anticipaci\u00f3n de las competencias adecuadas en el equipo (para formular las preguntas adecuadas y responderlas) y la construcci\u00f3n de una estrategia de producto que implique a los grupos destinatarios.<\/p>\n Teniendo en cuenta todo lo anterior, podemos observar varios problemas que aparecen regularmente en el proceso de dise\u00f1o:<\/p>\n - estar excesivamente orientado a los beneficios y evitar fijarse en los fracasos,<\/p>\n - inexactitud y no radiografiar los propios errores,<\/p>\n - perseguir un producto perfecto que tienes en la cabeza, pero que no es lo que necesita el mercado,<\/p>\n - Aplicaci\u00f3n excesiva de los procesos de los libros de texto: desarrollo y dise\u00f1o excesivos,<\/p>\n - inflexibilidad del trabajo en equipo y obligar a los empleados a permanecer \u00fanicamente en sus \u00e1reas de especializaci\u00f3n,<\/p>\n - comunicaci\u00f3n ineficaz,<\/p>\n - tendencia a reinventar la rueda.<\/p>\n La optimizaci\u00f3n del proceso a escala macro incluye la suma de ahorros. Para afrontar adecuadamente los retos mencionados, hay que implicar a los compa\u00f1eros para que presenten abiertamente ideas de mejora del proceso.<\/p>\n A veces basta con hablar menos y escuchar con m\u00e1s atenci\u00f3n a subordinados, clientes, socios -seg\u00fan el papel y la responsabilidad de cada uno- para alcanzar el \u00e9xito.<\/p>\n Cuando no es suficiente, lo m\u00e1s probable es que est\u00e9 invirtiendo en exceso<\/a>. \u00bfTiene demasiado dinero?<\/p>\n M\u00e1s informaci\u00f3n:<\/strong><\/p>\n CTO retos - ampliaci\u00f3n y crecimiento de productos de software<\/a><\/p>\nLecciones aprendidas de los fracasos<\/h2>\n
\n
\n
Construir un producto perfecto es como perseguir al conejo<\/h2>\n
Es bueno saberlo todo sobre algo y algo sobre todo<\/h2>\n
Equipamiento potente antes de salir<\/h2>\n
![\"Miro\"](\"\/app\/uploads\/2024\/05\/miro.png\" "\\"Miro\\"")
<\/p>\nSe puede (y se debe) ser perezoso<\/h2>\n
Centrarse en encontrar las respuestas correctas<\/h2>\n
Conclusiones<\/h2>\n
![\"C\u00e1llate](\"\/app\/uploads\/2024\/05\/meme.png\" "\\"C\u00e1llate")
<\/p>\n\u00a1C\u00e1llate y toma tu dinero! Ah, y adem\u00e1s:<\/h2>\n
\n