domingo, 16 de julio de 2017

Diseño Persuasivo: Usando Psicología Avanzada Efectivamente

“Las emociones forman toda actividad en formas adaptativas. En la ausencia de componentes emocionales, la toma de decisiones es virtualmente imposible.” —Saver & Damasio (1991)


Los sitios web han avanzado mucho en poco tiempo–es realmente increíble cómo muchos de estos sitios que pertenecen a las marcas más establecidas de la última década, han cambiado desde su primera iteración.
Cuando los sitios web fueron usados por primera vez por propósitos comerciales, no le prestaron mucha atención a la experiencia de usuario; el punto era poner la mayor cantidad de contenido posible en una página. Ahora ponen un peso mayor en investigación, con una mina de datos, y optimizados para tomar tu atención y ofrecerte el contenido exacto, junto a funcionalidades y opciones al mismo tiempo.
Más y más compañías están usando investigación psicológica avanzada y para empujar a más compras y fidelidad de parte de los usuarios, han transformado lo que era arte en ciencia.
El sitio web de Apple de 1997

Diseño Persuasivo
En adición a muchos elementos esenciales, el buen diseño siempre tendrá en mente las necesidades psicológicas y emocionales. Miremos al diseño persuasivo y exploremos cómo los procesos mentales que influenciaron cómo los humanos se comportan puede ser aplicado al diseño.
La palabra ”persuación” es muchas veces asociada con la manipulación, engaños, y—especialmente para un diseñador–el uso de patrones oscuros. Se ha ganado una reputación particular; sin embargo, seamos claros en que no es eso lo que estamos debatiendo. El diseño persuasivo puede mejorar la experiencia de usuario al hacer un sitio web fácil de usar—entiende de disparadores psicológicos, la conducta de los usuarios y las entabla.
Por ejemplo, Amazon persuade a los usuarios para que sigan comprando más al recomendar productos alternativos y accesorios, y emplea patrones miméticos y persuasivos al mostrar opciones como “clientes que vieron este objeto también compraron…”. Para cerrar una venta rápidamente, también le ofrecen a los compradores la habilidad de comprar con un sólo click.
Todos estamos gastando mucho más tiempo en un mundo online, y los diseñadores pueden usar lo que han aprendido de conductas offline para crear mejores experiencias de usuario. Así quieras modificar un sitio web existente o construir una app, el diseño persuasivo guiará y apoyará la experiencia online del usuario.
¿Cómo puede un diseñador usar lo último en investigación de psicología para mejorar el impacto de sus diseños?
Entender los principios de la psicología te provee con la habilidad de explicar la racionalidad subyacente de tu trabajo. Puede:
  • Servir como fuente de investigación y justificación en déficit de investigación de usuario.
  • Ayudar a validar tu diseño y razonar con un cliente.
Debatamos algunas teorías.

La Percepción Del Control

Como humanos, tenemos una necesidad innata de control. Esto nos lleva hacia nuestros humildes comienzos. En ponerle un precio a la jerarquía de las necesidades, el psicólogo Abraham Maslow nombró las más básicas: salud, comida, y sueño. Todas estas requieren un nivel de control sobre nuestro ambiente.
La Jerarquía De Las Necesidades De Maslow (cortesía de psychologytoday.com)
Como diseñadores UI, necesitamos asegurarnos que nuestros usuarios tendrán una experiencia positiva dentro del ambiente que creamos para ellos. Esto significa hacerlos sentir poderosos al ofrecerles herramientas que los harán sentir como si estuvieran en control de su travesía.
Consultor UX Nadine Kintscher dice, “Hoy, puedes ajustar el brillo de tus pantallas, desactivar notificaciones, y decidir si quieres que tu teléfono se conecte a datos y una red de teléfono o no…Incluso si estos ajustes sólo amplian la batería de tu dispositivo por sólo unos minutos, te da un sentimiento cálido de logro. TÚ estás a cargo.”
Necesitamos crear interfaces que son un balance entre ser funcional y visualmente cautivantes, y darle a los usuarios un poco de control para que tengan una experiencia satisfactoria.
Realestate, un sitio web Australiano de búsqueda de inmuebles, tiene éxito en hacer lo mencionado con anterioridad al dejar que sus usuarios filtren las propiedades de acuerdo a sus preferencias, y al darles la opción de ordenar por una norma limitada.

Motivación, Habilidad Y Disparador

¿Cómo diseñas una experiencia digital que le permita a los usuarios entablar conductas deseadas que ocurrirán en el momento exacto? Motivación, habilidad, y disparadores—una simple teoría basada en el Modelo Conductual de Fogg—es ideal para cualquiera intentando entender la psicología persuasiva. De acuerdo con el principio de la motivación, habilidad, y disparadores, la conducta ocurre cuando una persona es motivada, tiene la habilidad de tomar parte en la conducta, y es presentado con un disparador. Cuando estos tres elementos se unen en el mismo momento es cuando una conducta deseada puede ocurrir.
Aunque no lo disfrutemos, estamos altamente motivados para archivar nuestros impuestos. Sin embargo, el sistema impositivo de Estados Unidos es, como el de cualquier otro país, muy complejo para comprender fácilmente. TurboTax ha aumentado la habilidad al permitirle a sus usuarios completar más fácilmente sus impuestos al hacer preguntas básicas. Lejos se han ido los largos documentos—y en cambio, TurboTax ha creado un proceso de trabajo donde los usuarios son guiados a través de un proceso paso a paso. El valor final propuesto es la habilidad de fácilmente archivar impuestos de forma electrónica y enviar un pago–el disparador.
Encontrar situaciones exactamente con la combinación perfecta y la habilidad para un disparador perfecta podría sentirse artificial o no natural. Está bien si uno sobrepasa el otro; un buen ejemplo es twittear—la motivación podría ser baja, pero el disparador podría estar ahí y su habilidad ser muy alta.
Como diseñadores, podemos usar esta teoría para examinar cómo estamos construyendo las motivaciones de nuestros usuarios y la habilidad antes de que les pidamos que se comprometan con una conducta determinada.
  • Motivación provee una razón para que alguien se involucre en la tarea.
  • Habilidad provee a las personas con la oportunidad de completar la tarea.
  • Disparadores ocurren en nuestro ambiente o cerebro y dan pie a que una persona haga algo.
Ambas teorías requieren un poco de investigación pero son altamente útiles cuando se diseñan interfaces.
Alternativamente, hay algunas teorías psicológicas más simples que requieren menos investigación y pueden ser implementadas en tus diseños de forma inmediata, como los conceptos de escasez y el miedo de perderse algo (FOMO).
Amazon usa el FOMO efectivamente al añadir una nota de urgencia a un producto (resaltado)

Captura La Atención De Tu Audiencia

Por décadas, los psicólogos han estado obsesionados con nuestra decreciente habilidad de prestar atención.
Rastrear eso mide cuándo y por cuánto tiempo un usuario puede encontrarse en un punto y ha estado cerca por un tiempo determinado. Muestra que el período de concentración promedio en internet es menos que un par de segundos—tomamos decisiones inmediatas sobre un sitio y, si no es para nosotros, nos vamos.
EyeQuant ha tomado esta idea un paso más allá al construir un algoritmo predictivo usando datos de rastreo del movimiento de nuestros ojos. En vez de usar un programa para eso en tu propio sitio, puedes subir un diseño a su sitio web y te dirán cómo las personas perciben y se concentran en tu sitio.
Usando participantes Alemanes, construyeron una base de datos masiva sobre qué atrae la atención del usuario y lo que no—los contrastes de color, por ejemplo, atraen la vista, y así también lo hacen las tipografías y texto en negrita.
Software de seguimiento de ojos puede ser costoso, y en vez de eso, software de análisis como Sumo Heat Maps son útiles para mostrar qué y cómo tus visitantes están haciendo click, y qué les llama más la atención. Sin embargo, es esencial recordar que mientras estemos capturando la atención del cerebro, podríamos empujar a los usuarios lejos de algo más importante.
Usando software de seguimiento de ojos o mapas de calor les permite a los diseñadores tener una devolución inmediata y objetiva de sus diseños. Como diseñador, puede servir como validación para tus ideas de UX y proveer datos para tus decisiones de diseño, además de permitirte optimizar dichos diseños al realizar tests inteligentes A/B.
Sumo Heat Map

Deseo Mimético

¿Te has dado cuenta que los seres humanos naturalmente imitan los deseos de otros seres humanos? El deseo humano es, de lejos, deseo arbitrario. Esta teoría, originada por Rene Girard, sugiere que si alguien muestra deseo por un objeto, también desearás ese objeto. Los publicistas amarán esto–ya que ha demostrado ser exitosos.
Tú y yo somos criaturas miméticas. Diseño Neuronal por Darren Bridger exploró esta teoría y encontró que tenemos un sistema de neuronas espejo. En otras palabras, el sólo ver a alguien hacer algo como recoger un objeto puede causar que tu cerebro copie esa acción.
La teoría del deseo mimético significa que queremos algo más si vemos que alguien más lo posee—un diseñador puede emplear esto al usar prueba social.
Un ejemplo de la técnica de “prueba de usuario” son los testimoniales. Los testimonios funcionan porque vienen de personas que comparten sus deseos de usuarios y valores. Por ejemplo, Foundrmag no sólo usa la voz del usuario sino que también les muestra rostros, disparando el sistema de neuronas espejo.
Foundrmag
Otra implementación es “prueba social experta”, donde tu producto recibe una “estampa de aprobación” de un experto con credibilidad, como un blogger de industria. Esto puede aparecer como una mención de Twitter, una cita textual de prensa, o inclusive un artículo de blog. Google usa esta técnica en su última campaña para el smartphone Pixel.

Psicología En El Diseño De Hoy Y Más Allá

Es un momento emocionante para los diseñadores—tenemos los recursos e investigación para apoyar todo nuestro trabajo.
Tendencias de diseño suelen moverse al tacto, voz, realidad virtual (VR), realidad aumentada (AR), realidad mixta (MR), y el Internet De Las Cosas (IoT); mientras nos movemos hacia estas tecnologías de interacción, las personas requerirán formas más intuitivas de usar sus interfaces.
Veremos muchas nuevas oportunidades de diseño, y de psicología en general tendrá un rol directo y esencial en estos desarrollos.
El siguiente gran cambio será cómo interactuemos con nuestros dispositivos día a día—moviéndonos de lo táctil a auriculares que leerán nuestras ondas cerebrales. Esta tecnología está ya disponible y le da a las personas la habilidad de controlar sus dispositivos directamente con su pensamiento.
A medida que nos acercamos a los pensamientos reales de las personas, la psicología en el diseño–y la responsabilidad moral del diseñador–tendrán un rol muy importante e que incluso será aún mayor.
Además de usar analíticas, investigación de usuario, mapas de empatía y otros acercamientos para ayudar a tomar decisiones de diseño e iterar en un producto, los diseñadores deberían considerar juntar sus “bolsas de trucos” con los métodos de diseño persuasivo anteriormente mencionados.
El diseño persuasivo no es malo. Es una herramienta, y como cualquier herramienta esta puede ser mal usada. Sin embargo, con la investigación correcta y su aplicación bien pensada, puede ser una valiosa incorporación al juego de herramientas de cualquier diseñador.
Por: Bronwen Rees
Articulo vía: Toptal


domingo, 2 de julio de 2017

Guarda la Calma y Transiciona a un Nuevo Equipo de Desarrollo

Es común que un producto de software haga una transición de un equipo de desarrollo a otro en el curso de su vida. Las diferentes etapas del producto pueden requerir un equipo de desarrollo diferente: una consultaría para construir la versión inicial, un desarrollador independiente para mantenerla, un equipo interno para llevarlo a escala, o un diseñador profesional para hacerlo visualmente llamativo.
A pesar de que esto ocurre con frecuencia, muchos fundadores no técnicos y los propietarios de los productos no se encuentran preparados y luchan cuando llega el momento de traer al próximo equipo. Esto a menudo da como resultado una incapacidad para que el nuevo equipo pueda avanzar rápidamente, una pérdida de tiempo, y una frustración que incluye a todos los miembros.
Si esto suena como que podrías ser tú, ya sea ahora o en el futuro, entonces deberías estar algo preocupado. Por suerte, voy a guiarte a través de los pasos a seguir para prepararte para esta eventualidad y hacer la transición lo más sencilla posible.

Pasar la Antorcha: Abordando un Nuevo Equipo de Desarrollo

En este artículo, voy a ofrecerte una lista de verificación que te ayudarán a prepararte para un cambio de este tipo. Comenzarás a conocer tu producto en un nivel más íntimo y obtendrás un mayor control sobre los diversos servicios y tecnologías que conlleva el hacerlo, lo cual te ayudará a abordar un nuevo equipo con tranquilidad relativa y confianza.
Passing the torch to new developers? Make sure the new team doesn’t get burned and you don’t waste time firefighting.
Al pasar la antorcha a los nuevos desarrolladores, asegúrese de que el nuevo equipo no se queme.
¿Pero si no estás reemplazando todo el equipo? ¿Deberías tomarte el tiempo de leer esto?
Incluso si algunos miembros del equipo anterior permanecen a bordo, puede ser que no tengan todas las respuestas e información necesaria para una transición sin problemas. A pesar de que pueden proporcionar continuidad y ayuda en el proceso de transferencia de conocimiento del antiguo equipo al nuevo, depender de los miembros del equipo titular no reemplaza el hecho que el dueño del producto se haga cargo y facilite la transferencia. Además, no poder hacerse cargo podría causar fricción entre los nuevos y antiguos miembros del equipo, o responsabilizar a antiguos miembros del equipo con tareas innecesarias, obligándolos a perder demasiado tiempo comunicándose con los nuevos miembros del equipo y resolviendo distintos problemas.
Sin embargo, si algunos miembros del equipo se quedan a bordo, pueden ser de gran valor en tus esfuerzos de transición. Consulta con ellos, mantenlos informados y trata de aprovechar su experiencia sin inundarlos con demasiadas tareas relacionadas con la transición. ¡No esperes que ellos hagan todo el trabajo pesado! Ese es tu trabajo.
Así que sin más preámbulos, ¡metámonos de lleno en esto!

Reunir Documentación

A los desarrolladores independientes a menudo se les pide saltar en una base de código existente que nunca han visto antes. Esto es especialmente cierto con respecto a los ingenieros de software de Toptal. Nuestro objetivo es siempre ponernos en marcha tan pronto como sea posible para que podamos empezar a tener un impacto positivo para nuestros clientes.
Tener acceso a una documentación clara e íntegra sobre el proyecto puede acelerar dramáticamente el proceso de incorporación, y ayudar a los desarrolladores a evitar errores que pueden impedir el progreso.
Una buena documentación debe cubrir al menos los siguientes temas:
  • Creación de un entorno de desarrollo - La primera tarea para cualquier nuevo empleado es instalar la aplicación y ponerla en funcionamiento en sus propias computadoras. El proceso para hacer esto varía entre las tecnologías. En general, requiere tareas tales como obtener el código fuente, la creación de la base de datos, la instalación de dependencias, configurar el entorno con claves de la API y las credenciales, la importación de datos de muestra, y así sucesivamente. Los desarrolladores tienen una buena idea de todo lo relacionado con este proceso dentro de sus respectivos campos, y deben tener la capacidad de ajustar los detalles conformemente.
  • Ejecutar el conjunto de pruebas automatizadas - Al ver pasar las pruebas de una aplicación nos aseguramos que todo se ha configurado correctamente y que los próximos cambios no rompen ninguna de las características actuales.
  • Implementar en los servidores de ensayo y producción - Actualizar la aplicación en vivo con los nuevos cambios es un proceso altamente estructurado, y el orden de esas operaciones se debe esbozar paso a paso lo más detallado posible.
  • Cualquier otra información que sea relevante para un nuevo desarrollador a bordo - Cada aplicación tiene su propio conjunto de peculiaridades. Al escribir estas peculiaridades, se le ahorra a futuros equipos, esfuerzos innecesarios en depurar problemas que el equipo anterior ya ha descubierto cómo solucionar.

Good documentation is the cornerstone of any successful transition. Make sure your new team has everything they need to take over.
Una buena documentación es la piedra angular de cualquier transición exitosa. Asegúrate de que tu nuevo equipo tiene todo lo que necesita.
La documentación debe ser escrita por un desarrollador que tenga experiencia de primera mano en la configuración de la aplicación y contribuyendo a la base de códigos.
¡Antes de que ocurra cualquier transición, solicita que el equipo de desarrollo anterior facilite la transferencia de conocimientos mediante la creación de un recurso que toque los temas anteriores!
Si la escritura no es el punto fuerte del equipo, pídeles que registren una o más capturas de pantalla que demuestren la configuración del entorno de desarrollo, despliegue, etc. Hoy en día incluso hay herramientas como Vagrant y Docker que permiten a entornos de desarrollo completos ser empaquetados y distribuidos a los demás. En esencia, en lugar de dar instrucciones a alguien sobre cómo construir un martillo, entregales el martillo.
La prueba de fuego para saber qué tan comprensible y efectiva es la documentación de un proyecto, es la rapidez en que un nuevo desarrollador puede entender la configuración de su entorno de desarrollo y ejecución de su aplicación.

Entiende tu Producto

Tener gran documentación no te exime de la necesidad de conocer los fundamentos de la tecnología de tu propio producto. Como propietario de un producto de software, es tu responsabilidad entender tu aplicación lo mejor posible, incluso si no posees muchos conocimientos técnicos.
No technical background? There's no excuse for failing to properly understand the building blocks of your project. It could cost you dearly.
¿Sin antecedentes técnicos? No hay excusa para no comprender adecuadamente los componentes básicos de tu proyecto. Te puede costar muy caro.

  • ¿Qué elementos tecnológicos utiliza tu aplicación? - Hay muchos marcos de aplicación común para el back-end y el front-end, y cualquier equipo nuevo de desarrollo debe estar familiarizado con los que utiliza tu aplicación. Algunos ejemplos de tecnologías web de back-end son Ruby on RailsNode.js, y [Django](https://en.wikipedia.org/wiki/Django_(web_framework). Algunos ejemplos de tecnologías web front-end son React.jsAngular.js, y Ember.js.
  • ¿Dónde se encuentra alojado? - Diferentes servidores web tienen diferentes procesos de implementación, que requieren diversos niveles de experiencia. En los últimos años, las tecnologías de nube han creado una serie de nuevas opciones de alojamiento web, y tendrás que identificar cuál de estos, en concreto, estás utilizando y describir por qué lo elegiste sobre los demás.
  • ¿Cuál es el proceso de desarrollo? - ¿Tu equipo utiliza una herramienta de gestión de control de fuente específica como [Git](https://en.wikipedia.org/wiki/Git_(software)? Si es así, ¿cuál es el proceso por el cual una nueva característica se ha desarrollado, probado, aprobado, e implementado? El proceso debe ser normalizado, debidamente documentado y fácil de reproducir por los nuevos integrantes.
  • ¿Qué servicios de terceros utiliza tu aplicación? - Algunas aplicaciones se basan en servicios de terceros como Shopify. Por favor, ten en cuenta que la dependencia de los servicios de terceros está aumentando gradualmente, e incluso si actualmente no utilizas ningún servicio adicional, tu proyecto puede decidir emplear un servicio de terceros más adelante.
  • ¿En qué plataformas se puede ejecutar tu aplicación? - ¿Tu aplicación es una aplicación de escritorio, aplicación web, sitios web responsive para teléfonos móviles, una aplicación nativa de iOS, aplicación nativa de Android, o alguna otra? ¿Se ejecuta en varias plataformas diferentes? ¿Cuál plataforma es tu prioridad en un momento dado? ¿En cuál plataforma es tu producto más fuerte o más débil? Asegúrate de conocer todos los detalles de las plataformas actuales de tu aplicación, e incluso a cuáles se puede ampliar.

Toma Posesión

El proceso de desarrollo de software de hoy en día utiliza una gran cantidad de servicios de terceros y herramientas. Ya sea que lo sepa o no, tu aplicación no es una excepción.
Durante el trascurso de desarrollo, tu equipo anterior puede haberse registrado o suscrito a tu nombre, o incluso utilizado sus propias cuentas para obtener acceso a los servicios que se necesitaban. La transición a un nuevo equipo significa que debes tomar posesión y estar en control de cada uno de los servicios y herramientas en las cuales tu aplicación está basada, para que así puedas permitir el acceso a tu nuevo equipo, sin necesidad de pasar por un intermediario o perseguir a los desarrolladores originales.
La siguiente lista muestra las diferentes herramientas o servicios externos de los que tu aplicación podría sacar provecho:
Pregúntale a tu equipo de desarrollo saliente cuáles son aplicables. Para cualquiera de los servicios que son de propiedad del equipo de desarrollo, pídeles que te transfieran la propiedad. Si eso no es posible, entonces pídeles ayuda para crear una nueva cuenta y asegúrate de que la aplicación utiliza tu cuenta en lugar de la de ellos. Esto no debería requerir nada más que cambiar algunos ajustes de configuración para tu aplicación. No hace falta decir que debes asegurarte de que cada contrato de desarrollo protege tus intereses desde el primer día y garantiza una transición sin problemas, sin importar la situación.

Autoriza el Acceso

Con una sólida comprensión del ecosistema de tu aplicación y la propiedad de las diversas herramientas y servicios que utiliza, ahora puedes dar acceso completo al equipo entrante o miembro.
La mayoría de los servicios te permitirá añadir un colaborador a tu cuenta y otorgarle un determinado nivel de acceso. Está bien ser conservador en este caso, muchos fundadores, especialmente los empresarios individuales, prefieren dar a sus desarrolladores acceso de administrador a sus servicios y hacer que manejen todo. Esto tiene el efecto secundario de mantenerte fuera del circuito, que como hemos aprendido, puede hacer más difícil la transición en el futuro.
¿Deberías darle a tus desarrolladores privilegios completos de administrador? Es tu decisión, a la mayoría de las personas no parece importarles el uso de este enfoque. Sin embargo, siempre se debe planificar a futuro y asegurarse de que tu decisión no afecte negativamente a un nuevo equipo de desarrollo. De no hacerlo en las primeras etapas del proyecto puede tener consecuencias molestas en el futuro.

Gestionando el traspaso
Ahora que has cubierto todas las bases, necesitas gestionar el traspaso de un equipo a otro. Estos son algunos consejos básicos para enfrentar tanto al equipo entrante como al de salida.
Make sure you properly manage the technical and personal aspects of your project handoff. Make your new team feel at home and don’t antagonize your old team.
Asegúrate de administrar adecuadamente los aspectos técnicos y personales de tu traspaso de proyecto. Permite que tu nuevo equipo se sienta como en casa.

Equipo Entrante

  • Establece expectativas - El nuevo equipo debe saber cuáles son tus objetivos más importantes para que puedan centrarse en la dirección correcta. La gestión de tus propias expectativas sobre lo que el nuevo equipo puede lograr de inmediato es igualmente importante.
  • Realiza visitas de control a menudo - No dejes al nuevo equipo a su suerte. Debes hacer visitas de control con frecuencia para asegurarte de que tienen todo lo que necesitan, y que no se sientan como que tienen que valerse por sí mismos. Trata de hacer esto sin llegar a hacer micro gestión. Asegúrate de que sepan que estás para apoyar y ayudar si lo necesitan, pero no pongas presión innecesaria sobre ellos.
  • Sé paciente - Se necesita tiempo para que los desarrolladores puedan adaptarse a una nueva base de códigos. Entiende que habrá un poco de tiempo de aprendizaje antes de que el nuevo equipo pueda igualar el ritmo del anterior.

Equipo Saliente

  • Recolecta todo el código en circulación - Asegúrate de que todo el código fuente se haya registrado en el repositorio principal, y que sabes el estado de lo que se ha desplegado y lo que no. El nuevo equipo tendrá que saber exactamente dónde retomar y empezar a trabajar. Yo mismo he experimentado una situación en la que seguí el trabajo de un equipo que había desplegado código sin ponerlo en el repositorio principal. Esto llevó a que se crearan bugs, la duplicación de trabajo y dolores de cabeza que podrían haberse evitado fácilmente si el equipo saliente hubiera dejado el código fuente en un estado coherente.
  • Actualiza el nivel de acceso - Si se separaron en buenos términos, es posible que desees mantenerlos con acceso a tu código y/o despliegue. Muchos equipos están dispuestos a ayudar durante la fase de transición, hasta que el nuevo equipo pueda asumir plenamente. Si no, considera cambiar o revocar el acceso para evitar cualquier problema accidental o conflictos con el nuevo equipo.
  • Dales las gracias por su trabajo - Las transiciones pueden ser agitadas. Mientras estás ocupado con el nuevo equipo, no te olvides de agradecer a tu equipo saliente por su contribución al proyecto.

Conclusión

Cualquier transición en la vida puede dar miedo, lo cual trae la incertidumbre de si funcionará o no, el miedo a lo desconocido, y así sucesivamente. La transición a un nuevo equipo de desarrollo no es diferente, pero puedes y debes tomar medidas para que sea más fácil. En la mayoría de los casos, sólo se requiere un poco de planificación a largo plazo.
Tener un mayor conocimiento técnico y no técnico de tu producto de software, el proceso de desarrollo, y todas las cosas que entraron en el proceso ayudará a que cualquier transición de un equipo a otro, sea tan tranquila y sin dolor como sea posible.
Lo mejor de todo: ¡Tu nuevo equipo te respetará y dará las gracias por estar preparado! Es probable que les ahorre tiempo y esfuerzo, lo que también significa que vas a ahorrar dinero. Además, cuanto más pronto el nuevo equipo se dé cuenta de la insistencia en un alto nivel profesional, mejor. Lo más probable es que continúen la implementación de estas prácticas una vez tomen el control del proyecto, por lo que la próxima transición será también sin problemas.
Así que vamos a revisar los puntos clave que deben preceder a cualquier transferencia de propiedad de tu producto de software:
  • Recoger o crear la mayor documentación posible acerca de tu aplicación, el entorno de desarrollo y el proceso de despliegue.
  • Conocer tu producto dentro y por fuera.
  • Mantener el control de todos los servicios y dependencias de terceros de tu aplicación, y tener los nombres de usuario y contraseñas para todo.
  • Esté preparado para darle a tu nuevo equipo acceso a todo lo que necesitan para empezar a funcionar.
  • Sé proactivo y no dejes nada al azar, o para el equipo de desarrollo de salida.

Por: Carlos Ramirez III

Articulo vía: Toptal