VOLVER
Perseguir unicornios es un pasatiempo condenadamente caro. Cada año, las startups se comen miles de millones para que sólo una entre decenas o centenares obtenga beneficios millonarios. Los fundadores y propietarios de productos recaudan dinero de los inversores y sacrifican su independencia para conquistar el mercado más rápido. En última instancia, sin embargo, no consiguen fondos suficientes la mayoría de las veces. ¿Quizá fue acertado decir "cállate y llévate tu dinero" en el momento oportuno?
El dinero en efectivo lo domina todo. Ni siquiera las organizaciones más turquesas pueden negarlo. El desarrollo de proyecto los métodos de gestión, el ajuste y la optimización de los procesos o la motivación de los empleados obedecen básicamente a la necesidad universal de dinero. La agilidad en el diseño implica ciertos riesgos.
Todos queremos ser delgados y ágil para que el resultado de nuestras actividades, medido en cifras, sea lo más alto posible. Aunque centremos la mayor parte de nuestra energía en reducir las pérdidas, al final tenemos en cuenta el beneficio que ha aumentado gracias al ahorro generado.
Estos ahorros caen en el mismo saco que el resto de factores y sólo quedan al alcance de los más curiosos. De este modo, perdemos el foco y omitimos involuntariamente muchos datos valiosos y, en última instancia, inteligencia.
Aprender de los propios errores es una habilidad especialmente útil (aunque costosa), pero la cultura organizativa 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 "¡He perdido mi dinero!", el gestor se lo comunica al equipo diciendo "deberíamos ser más eficaces" y todos buscamos por defecto nuevas soluciones y mejoras; en lugar de mirar atrás, buscamos constantemente formas de avanzar.
Mientras tanto, las pérdidas suelen ser la clave para sacar las conclusiones correctas. Si repasamos los pasos de cierto flujo en el proceso sin la debida consideración, lo más probable es que las siguientes soluciones estén infectadas de los mismos errores.
Por ejemplo:
Un pequeño equipo de desarrolladores JS senior no proporciona 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á al equipo, lo que ralentiza aún más el avance del proyecto.
Si el inversor comprendiera mejor las razones de la ineficacia del equipo, llegaría a la conclusión de que sólo aprovecha su potencial en 60-70%. Un equipo mejor y unos días de trabajo dedicados a la automatización del trabajo resolverían el problema.
Por desgracia, ahora tiene que pagar a otro promotor que trabajará en el mismo equipo y su eficiencia también será de 60-70%.
Solución A:
A partir de ahora el proyecto cuesta $20.200 / mes
Gasto total en 12 meses: 12 * 20.200 + 10.000 = $252.400
Solución B:
A partir de ahora el proyecto cuesta $30.000 / mes
Gasto total en 12 meses: 12 * 30.000 = $360.000
Dos desarrolladores trabajando a 100% hacen aproximadamente lo mismo que tres desarrolladores trabajando a 60-70%. El inversor pagará más de $ 100.000 más al año por la misma capacidad de procesamiento debido a una decisión de diseño errónea.
Agilidad en el proceso no significa necesariamente esforzarse por conseguir una cobertura de pruebas 100% o batir el récord de rendimiento. Si bien estas métricas proporcionan una visión general del estado técnico del proyecto, son tan insignificantes desde la perspectiva del cliente final que no es necesario alcanzar un estado ideal en un proceso verdaderamente ágil, ya que no aportan beneficios reales. mercado valor.
Desarrollar soluciones técnicas perfectas requiere mucho compromiso por parte del equipo y una comunicación mucho más extensa. Como resultado, los parches funcionan más despacio y el proyecto se hace pesado por el exceso de desarrollo.
El desarrollo ágil consiste en entregar una código con el mínimo esfuerzo. Las pruebas de código son, sin duda, una buena práctica y las pruebas dicen mucho sobre el funcionamiento del código, pero no deben hacerse por el mero hecho de hacerlas y presumir de ello - la calidad técnica óptima de las soluciones se encuentra en algún punto entre el mínimo determinado por la equipo de desarrollo y el máximo limitado por el presupuesto.
En última instancia, la perfección no lleva a ninguna parte. Curiosamente, incluso la cuestión de la seguridad está sujeta a esta regla: teóricamente, cualquier sistema puede ser pirateado. Sin embargo, el mínimo de desarrollo antes mencionado debe ser correspondientemente más alto y relevante para el peso, la escala y el coste de las consecuencias potenciales de los percances del código. A menudo, en lugar de escribir el módulo de inicio de sesión desde cero, que siempre está cargado con un alto riesgo de error y de introducir vulnerabilidades de seguridad, es mejor utilizar, por ejemplo, el botón "Iniciar sesión con Google", cuya correcta implementación es relativamente rápida y segura.
Mientras el objetivo sea un plazo de comercialización corto, las hipótesis demasiado ambiciosas resultan contraproducentes. En un proceso aparentemente perfecto, el exceso de entusiasmo puede ser un despilfarro de recursos.
El diseño centrado en el usuario es genial. La cooperación centrada en el ser humano es más importante. Cuando el equipo se comunica en la misma longitud de onda, puede reducir espontáneamente más pérdidas potenciales.
Un diseñador UX que esté al día de las tecnologías frontend no propondrá una solución al MVP fase que consumirá un tiempo excesivo en la fase de aplicación.
Un desarrollador frontend que conozca la heurística de usabilidad podrá ajustar la interfaz a una resolución de pantalla determinada sin necesidad de que intervenga el diseñador de UX: arreglo rápido, vista previa, aceptar.
Trabajar en una aplicación requiere sincronizar las actividades de personas con perfiles de competencias completamente diferentes. Necesitas conocer la distribución de competencias en tu equipo para ofrecer valor a tus clientes con eficacia.
El buen rendimiento de un equipo así entendido es sumamente difícil de conseguir, sobre todo en la era de la trabajo a distancia. Las empresas que han sido "amigas de lo remoto" durante años tienen una ventaja significativa en este campo sobre las que se han visto obligadas a poner a punto la organización durante el cierre y acaban de conocer los nuevos métodos y formas de comunicación.
En el contexto de las crecientes necesidades de comunicación, herramientas como Whimsical, Miro, Mural, Figma y Balsamiq registran un impresionante aumento de popularidad.
Sin duda, el bloqueo y la necesidad de trabajar a distancia han desempeñado su papel en esta explosión de usuarios. Creo que la selección de la herramienta debe ajustarse a las preferencias individuales, pero echemos un vistazo a Miro:
La popularización de estas herramientas impulsa naturalmente el aumento de popularidad de las propias metodologías. 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.
Siempre hay que dotarse de herramientas que agilicen el flujo de información en el proyecto. La apertura a nuevas herramientas y métodos también es una de las bases de la eficacia. desarrollo de productos.
Los diseñadores experimentados tanto de la interfaz como de la arquitectura del software suelen darse cuenta de varias soluciones potenciales que deben verificarse al principio de la cooperación y buscan eficazmente inspiraciones apropiadas o incluso soluciones ya hechas en el mercado. Un buen ejemplo es el framework Material UI, que suele ser una apuesta segura en la fase de prototipo.
A veces, basta con revisar unas cuantas implementaciones en Behance o Dribble y utilizar la inspiración para desarrollar un mood board y luego pasárselo al desarrollador. Esta persona lo utilizará para elaborar un prototipo en el que se pueda hacer clic y que se pueda presentar a los primeros usuarios para recabar sus opiniones. Este esfuerzo orgánico por conseguir un proceso eficaz en personas comprometidas y con mentalidad de diseño es natural.
Si quiere ofrecer productos digitales de forma eficaz, tiene que dejar que la gente haga su trabajo. Usted sabe qué valor/servicio quiere ofrecer a sus clientes: eso es suficiente. Un equipo de proyecto competente y bien gestionado sabrá mejor que nadie cómo ofrecer este valor/servicio lo antes posible con la rentabilidad necesaria.
Demuestre su confianza, comparta la responsabilidad y ábrase a una verdadera comunicación bidireccional para que su producto será mejor y te quitarás de encima la carga de hacerlo todo tú solo, que a menudo resulta agotadora para fundadores y empresarios. En The CodestAdemás, trasladamos este principio no solo a los proyectos, sino también a los procesos internos; probablemente por eso disfrutamos de altos índices de retención tanto de clientes como de empleados (historia real, ambos> 90%).
Regálese un poco de pereza, transfiera con valentía la responsabilidad y despréndase de cualquier trabajo redundante que no sea necesario para avanzar: las funcionalidades que sería "agradable tener" siempre pueden esperar.
El proceso de creación de un producto digital es una colisión constante de diferentes perspectivas, experiencias y fuentes de información; cada una de esas colisiones conlleva el riesgo de tomar una decisión de diseño equivocada.
Una buena comunicación interna reduce este riesgo, pero es sólo una cara de la moneda. La cuestión de cómo mantenerse en contacto con el mercado sigue sin respuesta.
Inteligencia de Negocio, Atención al Cliente, departamentos de investigación UX y muchos otros - al igual que la equipo de desarrollodeben esforzarse por alcanzar el mínimo necesario para dar respuestas concretas a las preguntas formuladas por el propietario del producto o el equipo de UX.
La propia marca y la estrategia de comunicación de la marca también son importantes. Sirven para construir una relación cualitativa con los clientes, que luego se traduce en su compromiso. Si quiere hacer preguntas a los clientes, debe asegurarse de que están dispuestos a responderlas. El tono de su voz importa.
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ón de las competencias adecuadas en el equipo (para formular las preguntas adecuadas y responderlas) y la construcción de una estrategia de producto que implique a los grupos destinatarios.
Teniendo en cuenta todo lo anterior, podemos observar varios problemas que aparecen regularmente en el proceso de diseño:
- estar excesivamente orientado a los beneficios y evitar fijarse en los fracasos,
- inexactitud y no radiografiar los propios errores,
- perseguir un producto perfecto que tienes en la cabeza, pero que no es lo que necesita el mercado,
- Aplicación excesiva de los procesos de los libros de texto: desarrollo y diseño excesivos,
- inflexibilidad del trabajo en equipo y obligar a los empleados a permanecer únicamente en sus áreas de especialización,
- comunicación ineficaz,
- tendencia a reinventar la rueda.
La optimización del proceso a escala macro incluye la suma de ahorros. Para afrontar adecuadamente los retos mencionados, hay que implicar a los compañeros para que presenten abiertamente ideas de mejora del proceso.
A veces basta con hablar menos y escuchar con más atención a subordinados, clientes, socios -según el papel y la responsabilidad de cada uno- para alcanzar el éxito.
Cuando no es suficiente, lo más probable es que esté invirtiendo en exceso. ¿Tiene demasiado dinero?
Más información:
CTO retos - ampliación y crecimiento de productos de software
Qué base de datos elegir para el tipo de datos específico de su proyecto de software
Spanish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Dutch