 Bueno, tenemos a Alivia Elizabeth Berker de HumanMate. Es polla manager allí desde abril de 2016. Para los que conozcan HumanMate es una agencia de enseños increíble, de la top de WordPress a nivel mundial. Le encanta trabajar con clientes, construyendo proyectos increíbles, usando WordPress, y es cierto. En el pasado trabajaba principalmente en cine y televisión. Estuvo en el Daily Show con John Stewart y también en el canal que se llamaba Food Network. Se mudó con su marido, que eres tú, trabajó a Vermont en 2014 y le encanta caminar por la montaña y mezclarse con la comunidad técnica local. Va a hablar de proyectos sostenibles. Un fuerte aplauso para Alivia. Hola, bienvenido. Mi nombre es Elizabeth Berker. Soy el director de proyectos seniores de HumanMate, que es una agencia global y distribuida en todo el mundo. Así que a dos miembros de todo el mundo, de New Zealand, de América Latina, de España, de Canadá. Hemos trabajado entre diferentes idiomas, de diferentes idiomas. Es mi primera vez en Los Palmas, así que estoy muy honrada de estar aquí por la primera vez en Francairia. Una de las cosas que me gusta mucho es que tenemos estas oportunidades para estar juntos en la comunidad y hablar de experiencias. Sí, esa es mi línea. Es una imagen muy bonita, así que no pretendo que exista. Así que, sí, me encanta estas oportunidades para aprender de cada otra experiencia. Lo que quiero hablar de hoy es algo que probablemente hemos compartido trabajando en proyectos. Y es ese momento, probablemente, a la mitad de un proyecto que se ha caído hace un par de meses, el lanzamiento parece que no va a suceder. Y se realiza que algo ha ido mal. Tenemos un problema. Su equipo de proyectos es frustrante, es confuso, y como manager de proyectos se preguntan cuándo van. Cuando empezó el lanzamiento, pensó que se consideró cada contingencia, todos los partidos. Tienes muchos planos maravillosos que todos estaban en la mesa, pero de repente no funcionan más. ¿Por qué? Probablemente ha cambiado. Un proyecto es un sistema complejo. Y cuando hablo de sistemas complejos, estoy hablando de un sistema que incluye un número de componentes unidos o agentes que se interagan juntos. Y esto crea fluctuación y no puede crear un cambio. Esto es un tipo de cosa que encontramos todo el tiempo en nuestras vidas. Puede ser como la forma en la que la temperatura de la casa interactúa con un poco de café. Así que, en este caso, los agentes son la temperatura de la casa interactuando con el café, uno de mis más favoritos. Otro ejemplo es la forma en la que un shop opera los agentes en este caso, el manager del shop aquí que responde a las demandas de sus clientes para extender su shop con un producto de la manufactura que se ha distribuido en este truco. Y también define su proyecto. En este caso, los agentes son los agentes y su equipo de proyectos. Pero los más agentes adentran al escenario, si es un servicio de hostia o una agencia de diseño, la más complexidad es introducida en este sistema. En este particular sistema, es bastante común en mis proyectos, los dos agentes interactúan en dos diferentes maneras durante el proceso. Es una complejidad adicional trabajando juntos con el proyecto. Y, de nuevo, durante la revisión en QA antes de que el producto esté distribuido. Entonces, la pregunta es ¿Por qué no importa? Queremos todos nuestros proyectos a seguir más fácilmente, a distribuir más, queremos distribuir más a los equipos, queremos proporcionar más valor a nuestros clientes. Entonces, los planes son excelentes y es fundamental. Creo que no hay agencia en el mundo que vendrá un proyecto si no hay un plan en el lugar. También sabemos que estamos trabajando en los sistemas complexos y los sistemas complexos son subjectos a cambio. Entonces, podemos justamente cruzar nuestros dedos y asumir que todo va a pasar totalmente, hay que pensar cuando estamos creando planes, pero creando lo que me gustaría llamar proyectos sustentables, que no solo empecemos a cambiar, pero celebramos. Creo que esta cuota es realmente plazando un sistema en un rato de constancia, y que tiene la rigidez de evolucionar. No queremos hacer proyectos en el lugar donde tendrán frágil. Queremos poder evolucionar. El primer paso en empeciendo los cambios es con la rigidez de riesgo. Y esto es algo que es un ejercicio útil por todo el proyecto. Siempre en el pico. Pero cuando veamos la rigidez de riesgo veamos a todos los agentes involucrados y los diferentes riesgos potenciales que pueden introducir a un proyecto. Entonces, cuando trabajas en un proyecto que tiene múltiples estados, como esta, entonces el riesgo potencial que podrás encontrar es que hay una habilidad para llegar a una decisión entre los dos estados, cómo construir las continuidades para eso en tu proyecto. Si estás trabajando con el equipo de proyectos tendrás que considerar los riesgos de on-board y off-boarding, lo que las acuerdos pueden surgir. Si un equipo saldrá, si un equipo saldrá en productividad, si un nuevo equipo saldrá, pero esos son lo que queremos llamar los riesgos de on-board y los riesgos de on-board que nunca podrás tener anticipado en el proyecto. Así que, como manager de proyecto tengo que preguntar a mí qué podemos hacer para construir las flexibilidades para que nunca podrás tener anticipado en el proyecto y siempre lo hacemos. ¿Qué actividades puedes llevar para mantener la comunicación, el fluido y el rato de nuestro equipo? Así que, lo hacemos por construir un sistema de feedback y en un sistema complexo el sistema de feedback es un canal que permite el sistema asesinarse y proporcionar input en nuestro ambiente. Así que, es una forma muy complicada de decir que es mirar un proyecto de un nivel metálico cómo asesinarse y mejorar a ser más productiva y efectiva. Así que, aunque es un poco esotráfico los tools que usamos para construir las flexibilidades son cosas que estamos todos familiarizados con. Es como pensando en ellos en diferentes contextos. Entonces, voy a hablar de tres de los más comunes que he encontrado en la documentación, comunicación y el proceso de transporte. Entonces, en mi experiencia, la documentación es la fundación de cualquier proyecto. Creo que esto es algo que los desarrolladores son realmente, yo aprendo mucho de ellos en términos de documentar, incluso las relaciones clientes. Cuando estás buscando un código y sabes que estás buscando un código fuerte, puedes pinpointar cuando y por qué la decisión fue realizada y cómo eso impactará el ecosistema del código. Pero esto es solo lo más complicado cuando estás trabajando clientes también. Una buena documentación de las relaciones clientes deberías poder volver a un momento en el que la decisión fue realizada y tener acceso a el contexto de por qué esa decisión fue realizada. Así que, me gusta pensar que es una buena documentación o un proyecto sexual nervioso, que nos dice quién es acudible y quién es responsable para ciertas tareas. Y eso cambia y esto es importante porque cuando las cosas cambian tenemos que tener un punto de referencia a lo que es la última para que podemos hacer la más informada decisión sobre lo que la próxima fase será. Y es todo en mi cuando pensamos en usar documentaciones de feedback, hay un par de cosas que son muy importantes para hacer eso efectivo. Entonces, en ese contexto todas las documentaciones deberían ser fáciles, accesibles y entendidas a todos y a la comunidad. Esto es algo que un humano me ha contado mucho porque todos trabajamos remotamente y muchos de nosotros son experiencias de idioma. Entonces, vamos con lo que nos parece es una parte muy importante de lo que es nuestra laboralidad. El documentación de clientes es importante. El documentación de desarrolladores. Entonces, comentar tu teléfono con la que te llamas el código es muy claro cuando la decisión es tomada y dar contactos por por qué. Mucha de mis colegas actualmente se highlighten y caen cada vez que la decisión es realizada y atalazan. Entonces, ¿cuál es la posibilidad para que llegue a ese momento antes de lanzarse? Bueno, la posibilidad no está ahí porque 6 meses atrás decidimos tener tiempo para construirla y el stakeholder lo aprobó y eso es lo que vamos a hacer. Tenemos una memoria de lo que pasa en el proyecto y con eso debe ser rigoramente mantener la comunicación como documentación algo que requiere mantenerla rigoramente. Y esto es lo que he aprendido en el proyecto Hardway. En el principio de cada proyecto el default es hacer una estrategia de comunicación y el default es que tengamos una reunión con el cheque cada semana donde usamos el estatus que planificamos para la semana una base gratificada pero, de nuevo, como el proyecto fluctua necesitas que el cliente sea cambiado necesitas que el equipo de desarrollo sea cambiado y tienes que poder asesar eso y crear alternativas que mantien a cada persona entonces un ejemplo reciente de esto es un proyecto que currently working on this launching on Monday, I hope we started off with our default communication strategy weekly check-ins and it was going smoothly at first but as we got further into the project our development team started raising a lot of questions around scope as they dug in more which was very natural and they would raise us during calls unfortunately this left our stakeholder feeling a little bit frustrated because she felt she didn't have enough time to prepare questions so she could adequately communicate and discuss the implications of these questions so we took some time to determine what would be an appropriate solution to help her feel that she was more engaged in the project and we came up with a tool and a process for so the agenda is ahead of time so that she could dig into those questions and feel like a more engaged member of the team so what I took away from that experience is that well everyone kind of hates more meetings setting up times during the life cycle of a project to really assess how communications are going or a way to keep them really healthy to keep your stakeholders feeling engaged and like to have ownership and also to make sure that your team is getting the information that they need in the most effective way so some keys for communication in my experience are identifying needs and deliverables review those over the course of a project make sure your assumptions are still correct be flexible and ready to evolve and to do that build communications assessments of your timeline and be vigilant and observe the dynamic between your team body language and language cues textual cues can really provide a lot of insight to when communication gaps may be emerging and off-boarding though project team is all about the individuals that are a part of the team that's sort of what defines a workflow at any time that team changes the workflow will change a little bit as well and that's something that needs to be considered in advance this happens with our agency quite frequently actually we're a pretty large team we're about 60 people and because of the time zone spread and different areas of expertise that may be needed on a project we tend to rotate developers every 6 to 8 months depending on the project this can be a challenge as we talked about a little bit earlier any time a developer leaves a project you risk opening up a knowledge gap there's so much intellectual work that goes into developing and working with clients finding a way to capture that knowledge before someone leaves is really important so that's something that is important to consider at the beginning of a project but also as a project continue to make sure that it's being effective and this is true for onboarding as well although slightly different one of the biggest concerns when onboarding a new team member is not only re-establishing trust for the client which can be challenging sometimes if you're not really close to a team so that's a potential risk that can impact productivity but also getting up to speed with a new development environment learning a new workflow technology those are all things that can impact how a project's help is overall and the rest of the team so creating proactively creating sorry that's my words some are processed for people to make those transitions and to test them over the course of the project is really important we do a couple of different things one of the more creative I thought was one of our developers creates videos that outline how to set up a development environment and that explains the functionality of certain features so if he's unavailable and someone has a different time zone they need immediate assistance they can look to these videos and that's the way of onboarding capturing his knowledge and letting onboarding buddy work so every time they do a new developer joins very shadow a current developer on the project to kind of get a knowledge share from them and we also do offboarding calls and this is sort of like an exit interview it gives about the team a time to to get what knowledge they can from a developer who may be leaving a project I also just wanted to call out the wall onboarding is a bit bittersweet when I'm working with a team I always feel like very connected with them but it's also a great time to build in celebration whether someone's contribution or someone joining a team and I think that's sort of to tie this all together underscores the sort of larger philosophy behind the session which is how we embrace change and leverage it to strengthen our teams strengthen our projects our client relationships so that you know as we move forward in our work they sustain us and help us to do more interesting things and that's, I think I'll pretty much on my time so I need a 30 questions I guess ¿Tenés alguna pregunta? Any questions? What kind of system do you use for documentation? For documentation it can depend a bit on the project we use our kind of source of truth as the GitHub wiki everything lives in there and we try to get clients to use that as much as possible that's not always the case so Google Docs anything that can be kind of quickly processed that's part of the project GitHub is preferable because that's where the code lives to so obviously it's a lot closer to the work and it's also where we document development issues so we try and client-facing documentation there as well and have a page we have a set of pages for you know all our call notes are in there sort of our process for like when we do calls I wonder why would you horrify that sort of thing and that's a favorite of the project so just follow up on documentation I'm awake our experience in a lot of projects has been intense documentation and it's not being read so whenever we have a meeting people ask questions that are already like documented when saying that people actually read the documentation know what has been discussed already yeah that's always hard that is sort of taken on a project by project basis but you could make it kind of I mean one thing that we try and do is gamify things a little bit so you could are you a project manager or a developer account manager oh so you can have like a pop quiz at the beginning of a meeting and be like if you read the documentation you'll know just keep it short to like 2 minutes and then start giving out prizes like tokens or something and you know it's like monopoly money but you know they're like certain characters that feel like they don't have to read the documentation it's like reload them you know this kind of character yeah do you ever so like an agile we would approach them individually and try and have a conversation about it or even call them out in a meeting but I think if you also create some some stakes or something that would hold them accountable then you know they might start to realize that they're in the same position as everyone in a project share responsibility and the moment that you kind of shirk your responsibility you're putting it off onto everyone else which builds more work etc so anything that kind of makes that concrete in their minds I think yes do you use any particular tool to make all these videos that you talk about the videos I think that he just does like screen screencast like a quick time screen guys on screen recording but he didn't have a particular tool it's sort of like quick time was great mas crueltas so how do you compile those videos that are searchable in some way do you guys use Slack and then compile the documentation somewhere yeah we do use Slack although we don't use Slack to store documentation it's too difficult to search so it would either be any documentation either in github or google drive but for videos I think that he I think that he was able to build a build a way to include them in the admin as like a helper and then he also included them in github but the description of the feature and he would link to the video which was like in dropouts or something mas crueltas mas crueltas un fuerte aplauso para