Manual de Developer Advocacy
(developer-advocacy.com)La versión más reciente del "Manual del evangelista de desarrolladores" que Christian Heilmann publicó hace 15 años
- ¿Qué es Developer Advocacy / Evangelism?
→ Definirlo
→ La mentalidad correcta: una persona que impulsa cambios para los desarrolladores
→ El rol y cómo aprovechar sus fortalezas
- Colaborar con tu propia empresa
→ Prepararse para los prejuicios: es un rol único que abarca varias funciones. No te desanimes
→ Afrontar los cambios dentro de la empresa: seguir los procesos legales. No existe el "off-the-record". No actuar por emoción ni hacer suposiciones
→ Estar al lado de los desarrolladores internos: escuchar
→ Colaborar con PR y marketing: no son competidores, hay que comunicarse de forma constante
→ Ser percibido como un canal externo: hacer saber a los miembros qué canales manejas
→ Educar a otros advocates y a los desarrolladores: dar capacitaciones y charlas internas, y compartir feedback externo
→ Compartir habilidades útiles: comunicar internamente las habilidades que vayas aprendiendo
→ Equilibrar los canales personales y los oficiales
→ Quitar la marca: separar tu identidad de la marca de la empresa. Enfócate solo en lograr que los desarrolladores puedan experimentar con el producto
- Colaborar con competidores
→ Al trabajar con competidores:
✓ ser una persona independiente interesada en lo que resulte valioso, sin importar de qué empresa sea el producto
✓ familiarizarte siempre con cosas nuevas
→ Respetar a los competidores: no puedes ser un gran DA y al mismo tiempo una persona pendenciera.
→ Reconocer cuando el producto del competidor es mejor: valora la buena tecnología, no temas la competencia sino dale la bienvenida, y también puedes dar feedback al equipo interno
→ Conocer a los competidores: si vas a hablar comparando, primero debes conocerlos
→ Crear y usar ejemplos con productos de la competencia: permite comparar y entender las diferencias
- Preparar el outreach
→ Entender los hechos con precisión: preguntar al equipo de producto en detalle sobre especificaciones exactas, funciones y lo que no hace
→ Conocer a la audiencia y sus necesidades
→ Tener expertos de respaldo listos:
✓ anotar las preguntas que no puedas responder y dar seguimiento después
✓ no prometer cosas que no estés seguro de que el equipo de producto pueda ofrecer
→ Elegir el medio adecuado: diapositivas, video, audio, live coding, ejemplos guiados en línea...
→ Prepararse para el fracaso:
✓ copias locales y en línea de las diapositivas.
✓ guardarlas también en una memoria USB.
✓ prepararte para poder continuar como sesión de Q&A si no se pueden usar las diapositivas
✓ lo online siempre puede fallar, así que prepara una alternativa local o hotspot
- Buscar oportunidades para hablar
→ Participar en podcasts
→ Participar como panelista: conviértete en experto de un tema específico o en miembro de un grupo
→ Asistir a barcamps/meetups: charlas cortas
→ Escribir artículos para revistas online, etc.
→ Organizar sesiones brown bag: seminarios a la hora de la comida
→ Hacer preguntas en conferencias
→ Convertirte en un ponente al que quieran invitar: publicar y difundir tus temas de charla (Term)
✓ información personal, biografía actualizada, diapositivas/videos de charlas recientes
✓ temas que te gustaría tratar, tecnologías que usas
✓ qué esperas de los organizadores de conferencias, etc.
- Viajes de trabajo y asistencia a conferencias
→ Tips de viaje: dejar un día de buffer, viajar de forma económica
→ ¿Quién paga los gastos?
→ En la sede de la conferencia, asistir a distintos eventos y convivir con otros ponentes
→ Usar redes sociales al asistir a eventos:
✓ dejar tus contactos de redes sociales en las diapositivas
✓ compartir con hashtags, etc., que estás asistiendo a la conferencia
✓ compartir contenido interesante o buenas charlas
✓ volver a compartir noticias de los organizadores de la conferencia
✓ publicar las diapositivas online y hacérselas llegar a la gente
→ Construir red de contactos a través de eventos
→ Crear y llevar un calendario para registrar la asistencia a eventos
→ Aprovechar el buzz de la conferencia
→ Ser parte de la conferencia en la que presentas
→ Publicar de inmediato la charla y los materiales relacionados
→ Escribir sobre la conferencia
- Dar charlas y workshops
→ Sé tú mismo: tu mejor activo es la confianza en ti mismo.
→ Invitar a la comunicación
→ Preparar materiales para que los asistentes se lleven (takeaways)
→ Preparar la sesión de QA y controlarla por completo
→ Ser honesto y decir solo la verdad: si no sabes la respuesta, no adivines
→ Dar seguimiento a la comunicación después de la charla
- Tips de presentación: manejo del tiempo y otros temas
→ Cómo meter todo esto en X minutos
→ Less is More: empieza con una sola cosa importante (insight, resultados de investigación, estado actual de X, nueva función del producto X). ¿Qué quieres que la gente recuerde de esta charla?
→ Tu presentación es muy importante solo para ti
✓ tu charla es una entre muchísimas otras
✓ tu charla será grabada y circulará por muchos lados
✓ la gente no recordará todo el contenido completo
✓ la gente no te necesita a ti para obtener la información. Esa información se puede encontrar fácilmente online
→ Organizar la información adicional
→ ¿Live coding? Cosas con las que debes tener cuidado
→ Evitar preguntas
→ Cosas que conviene recortar: diapositiva de índice, información de la empresa, presentación personal, chistes y memes
→ Cosas que puedes usar como relleno durante la charla: dónde están los materiales, cómo contactarte, colegas y expertos a quienes contactar además de ti...
→ Preparar un resumen de la presentación
- Cosas que no deberías decir en el escenario y sus alternativas
→ "Esto es fácil": "para hacer esto solo hay que pasar por algunos pasos", "estas herramientas están bien documentadas, así que tú también..."
→ "Por si alguien no lo sabe, lo repito brevemente": "dicho de nuevo, X es...", "como saben, X es..."
→ "Cualquiera puede hacerlo": "si haces esto, el resto del trabajo te resultará más agradable" "como es muy efectivo, pruébalo y compártelo con otras personas"
→ "No se preocupen, X resolverá este problema": "como X resuelve problemas relacionados con Y, puedes construir Z"
"X fue creado para facilitar Y y ya se está usando en la práctica. Los resultados también son alentadores"
→ "Como todos saben": "últimamente se ha hablado mucho de esto y está bien explicado en X (enlace)"..
→ "Como aprendimos en la escuela": "esto formaba parte del plan de estudios de ciencias de la computación, y hay una razón para ello"
→ "Y (nuestro producto) es mucho mejor que X (competidor).": "así es como se hace usando X. Nosotros tomamos un enfoque distinto y estas son las razones."
"Hay varias soluciones para esto. Sabemos que a X le faltan algunas funciones que podrían hacerlo más eficiente..."
→ "Se puede hacer con solo unas cuantas líneas de código": "como pueden ver, es posible empezar con unas pocas líneas de código. Lo simplifiqué para mostrarlo aquí, y el código fuente está en X"
→ "Si quieren volverse expertos (profesionales), hagan X": "la ventaja de X es Y, por eso se convierte en una herramienta profesional al usarla.
→ Además, mira tus propias charlas/videos y piensa: "si yo no supiera esto, ¿cómo me haría sentir escuchar estas palabras?"; luego quita contenido o reformúlalo
- Escribir buenos textos y artículos
→ Simple is not stupid: escribir de forma fácil de entender y simple es muy difícil. Usa palabras sencillas, términos que una audiencia amplia pueda comprender y frases concisas
→ Di lo esencial. No lo endulces
→ La longitud importa. Los textos técnicos para internet deben ser breves y transmitir solo lo esencial. Si es demasiado largo, divídelo en varios artículos
→ Agrega distintos medios relacionados: video, audio, diapositivas, imágenes, etc.
→ Estructura el contenido con encabezados por niveles, etc.
→ El contenido también necesita fecha de vigencia.
→ Cita otras fuentes para demostrarlo
→ Escritura preventiva (Pre-emptive): haz que tu producto despierte interés entre los desarrolladores. "Vender" es tarea del equipo comercial
- Escribir ejemplos de código excelentes
→ Resolver problemas mediante ejemplos
→ Mostrar ejemplos que funcionen
→ Explicar el entorno necesario
→ Escribir código que se pueda Copy & Paste
→ Ofrecer descarga de ejemplos
→ Escribir ejemplos limpios e inteligentes
→ Hospedar el código y las demos
✓ el control de versiones es tu amigo
✓ hacer hosting automático
✓ usar code sandboxes
✓ entorno de live coding
- Preparar excelentes materiales de presentación
→ Tener muy claro qué cosas sabes
→ Empezar por el contenido mismo, no por las diapositivas
→ Empezar escribiendo en un formato de texto portable
→ Tips para crear diapositivas rápido: descomponer los bullets
→ Elegir y preparar una buena herramienta de presentaciones
✓ debe poder adaptarse sin importar si es 16:9 o 4:3
✓ debe permitir recortar y redimensionar imágenes fácilmente
✓ debe permitir mover objetos libremente en pantalla
✓ debe permitir control remoto
✓ debe hacer fluida la transición a otras presentaciones
✓ soporte de pantalla completa
✓ posibilidad de mostrar elementos uno por uno
- Crear grandes diapositivas para presentar
→ No lo documentes con palabras; explica con frases cortas/imágenes/capturas de pantalla/gráficas
→ Buscar y usar buenas imágenes
→ Hacer que los ejemplos de código se vean bien
→ Tips para usar sonido y video
→ Usa animaciones solo donde hagan falta (sin que todo brille demasiado)
→ Sé conciso: si es posible, cubre un solo tema
→ Ten en cuenta a la audiencia
→ Si hay plantillas de la empresa o la conferencia
→ Todo el material debe personalizarse e interiorizarse: no reutilices tal cual materiales que te hayan dado otras personas
→ Compartir y disfrutar
→ Tips adicionales para presentar
✓ presentarte: por qué eres la persona adecuada para dar esta charla y por qué/qué quieres contar
✓ usar humor: ten cuidado de no atacar a otras personas
✓ crear conexiones con la realidad
✓ controlar la velocidad para no ir demasiado rápido: hacer pausas ayuda a la audiencia
✓ evita "Hello World"
✓ si es posible, usa materiales nuevos. Mantenlos actualizados
- Checklist para presentaciones más fáciles de entender, accesibles y accionables
→ Materiales de presentación
✓ ¿es HTML/PPTX/PDF?
✓ ¿el código está online?
✓ ¿los videos/audios embebidos pueden reproducirse sin importar el OS y también offline?
→ Formato
✓ ¿los medios embebidos tienen soporte de accesibilidad? (subtítulos, texto alternativo, transcripción, etc.)
✓ ¿la tipografía es lo bastante grande?
✓ ¿es del tamaño adecuado para la conferencia? 16x9, 4x3
✓ ¿tiene suficiente contraste para verse bien incluso si el proyector tiene fallas?
✓ ¿hay márgenes de seguridad suficientes por si el proyector recorta?
✓ ¿necesitas tipografías alternativas si vas a presentar en una computadora que no es la tuya?
→ Contenido
✓ ¿incluye contenido agresivo o potencialmente detonante?
✓ ¿se puede entender sin un contexto específico?
✓ ¿hay términos que intérpretes/traductores deban conocer de antemano?
✓ ¿hay algo que pueda malinterpretarse si solo se comparte una parte o una sola diapositiva?
✓ ¿todas las fuentes y materiales tienen la atribución indicada y se revisó el copyright?
→ Seguimiento
✓ ¿puedes saber quién descargó los materiales?
✓ ¿la última diapositiva tiene un Call-to-Action y un enlace descargable?
→ Seguro
✓ ¿todos los materiales son accesibles offline independientemente de la computadora? (incluyendo diapositivas/ejemplos/medios, todo en una memoria USB)
✓ ¿incluye material explicativo preparado para cuando el video/audio no funcione bien?
- Dejar registro de todo el trabajo
→ Grabar en audio todas las presentaciones
→ Si es posible, grabarlas también en video
→ Reunir en un solo lugar todos los enlaces usados en la presentación
→ Llevar una lista de todas las conferencias a las que fuiste o irás: incluyendo enlaces a diapositivas/blog/video
- Conocer y aprovechar la web (social)
→ Encontrar buen contenido web
→ Redistribuir contenido web: escribir en blogs, guardarlo en sitios de marcadores sociales, usarlo en presentaciones, citarlo en listas de correo o foros, publicarlo en Twitter
✓ siempre dar attribution al creador original
→ Darte a conocer en la web
→ Usar sitios y productos sociales potentes: Flickr, YouTube, Vimeo, Archive.org, GitHub, LinkedIn, Facebook, Meetup, Twitter
→ Usar la web como repositorio, canal de distribución y herramienta de cross-promotion
→ Dar pistas sobre el producto, hacer teasing y publicar previews
→ Medir el efecto: agregar telemetry a documentos/blogs, suscribirte a feeds de comentarios, usar acortadores de URL rastreables
→ Construir red de contactos
→ Crear o participar en newsletters
→ Crear o participar en podcasts
- Trabajar desde mi computadora
→ Equipos: micrófono externo, monitor, cámara, iluminación
→ Grabar screencasts y capturas de pantalla
→ Streaming
→ Participar en chats online en tiempo real
→ Cuidados y tips al participar en eventos online en tiempo real
- Tips para grabar mis presentaciones online
4 comentarios
El título de la versión anterior era Developer Evangelist Handbook, pero hoy en día se usa la palabra Advocacy en lugar de Evangelist/Evangelism, así que eso se reflejó aquí.
También es un libro que consulté casi como una biblia cuando trabajaba como developer evangelist en 2010.
El autor trabajó durante 20 años como desarrollador y es un veterano que ha desempeñado este trabajo durante los últimos más de 10 años en Yahoo, Mozilla y Microsoft.
Se expresa de varias maneras, como Developer Advocate/Evangelist/Relations, pero creo que les puede servir de referencia a todas las personas que trabajan en áreas relacionadas, así como a desarrolladores que hacen muchas presentaciones externas.
En la creación de materiales para presentaciones, lo de "No reutilices sin personalizar - Don't reuse without personalising" es algo en lo que yo también hago mucho énfasis.
Si usas imágenes o diagramas tomados de algún otro lado, muchas veces hay partes que no encajan y, de hecho, también pasa que quien presenta no termina de entender por completo ese diagrama.
Si es posible, recomiendo volver a dibujarlo según tu propia interpretación y usarlo de forma que encaje con el concepto de tu presentación.
Gracias por el buen resumen. “No lo reutilices sin personalizarlo” suena como una traducción demasiado literal, así que en el contexto que mencionas quizá algo como “interiorizarlo y reutilizarlo” podría entenderse más fácilmente.
Ahora que lo escribo, sí, así es ^^; ya lo reflejé un poco. Gracias.
@_@)b