7 cosas que he aprendido como Project Manager.

Me gradué de ISC hace menos de un año, he administrado alrededor de 15 proyectos de diversos tamaños y requerimientos. He tenido la oportunidad de trabajar con todos los miembros del equipo Inteli-K, y he aprendido algunas cosas en el camino.

1. La Comunicación Es La Pieza Más Importante De Tu Rompecabezas

Quise ponerla primero, ya que un proyecto donde no esté bien la comunicación, está condenado a fracasar. Desde la redacción de los requerimientos, los factores que se le tienen que pedir al cliente, las dudas de tu equipo. Todo se puede resolver si se tiene una comunicación efectiva con todos los miembros de un proyecto. Es importante que todo esté en orden, para saber cuándo es el momento de escalar un problema, o de presionar para obtener una milestone.

2. Las Notas Son Tus Mejores Aliadas

Probablemente sientas que nadie va a leer la minuta que estás haciendo durante la junta, y aunque la mandes a una lista de distribución de 15 personas, sabes que terminará siendo archivada en otra bandeja de correo; sin embargo, estas notas en realidad están destinadas para poder apoyarte en el momento en el que surjan dudas con tu equipo o con el cliente. Son la mejor forma de comprobar que todo se encuentra documentado y se está tomando en consideración.

3. La Paciencia Es Completamente Necesaria

Normalmente cuando estás realizando un proyecto nuevo, le estás presentando una nueva herramienta a tu cliente. Una que posiblemente nunca ha visto o que sepa poco de ella. Nunca olvides que la paciencia es clave en cualquier proceso de enseñanza, y tenemos la responsabilidad y misión de acompañar a nuestros clientes de inicio a fin. Aún así también tenemos que recordar que…

4. Tu Cliente Sí Sabe Más Que Tú

Nadie conoce mejor su empresa que alguien que trabaja en ella. Preguntar cuando tienes alguna duda es lo más sabio que se puede hacer. Los clientes están esperando que al final del día la herramienta se adapte a sus necesidades lo mejor posible, y van a dar toda su disposición para lograr esto.

5. La Presentación Siempre Ayuda

Esta es una regla doble: Aunque es cierto que nunca hay que subestimar el valor de una presentación de Power Point bien realizada, me refiero más al punto de que tus entregables se vean bonitos y sean funcionales, que cuando ves a tu cliente representes a tu equipo de manera profesional, y que tu lenguaje sea el adecuado para el tipo de cliente con el que estás colaborando. Muchas veces el trato de un cliente puede variar si no sabes cuál es la mejor manera de acercarte a ellos, sé flexible y adaptable.

6. Los Otros PMs Te Van A Entender Y Apoyar

En mi empresa no soy el único Project Manager, y cuando tengo una pregunta de cómo lidiar con alguna situación en específico, sé que me puedo apoyar en ellos cuando sea necesario. Lo más probable es que alguien en la oficina de PMs se ha enfrentado a retos similares a los que te estás encontrando tú en cualquier momento. Escucha cómo manejaron ellos las situaciones y tómalos en cuenta para complementar tu estilo de trabajo.

7. Tu Equipo Es Tu Familia

Sin importar el equipo: PMs, Desarrollo, Configuración, QA, Ventas. Todos en tu empresa están trabajando por las mismas causas: sacar el proyecto adelante, satisfacer las necesidades de los clientes y crecer como empresa. Aprécialos, escúchalos y apóyalos con todo lo que puedas.

30 of the 97 most important things to be a software architect.

For my software architecture class our professor asked us to read a book by O’Reilly called 97 Things Every Software Architect Should know. I chose 30 of the points I thought were interesting; I hope you learn something from them as I did. I’ll try to keep it as brief as possible.
1. Chances are your biggest problem isn't technical

Let us remember that most projects are done by people and for people. Maybe there is someone that did not follow the rules and that’s making your project to be difficult to implement. Communication is key when dealing with other people. Attitude is necessary when you’re about to have a conversation, and have the ability of agreeing with other people’s point of view.

2. Communication is King; Clarity and Leadership its humble servants

Being a software architect means that you are a leader for a group of people. You are in charge of their work, and you will be leading the project to its end. When you are talking to your group you have to be sure that they understand every single word you’re saying. Just as in any other relationship, communication is the key of success. Find the way to be clear and concise, solve doubts as soon as they are presented, and be around for your team.

3. Seek the value in requested capabilities

If you are an architect, you are probably the most prepared person in the room to solve a software problem. The clients may think they know what they need, but most of the times you will be finding a clearer idea by listening to what features the users need. They could bring up a crazy idea on how to get a specific feature, but as an architect, by using the super power of Active Listening, you may find a better and cheaper way to achieve the same result.

4. Stand Up!

This is a pretty straightforward advice. Imagine you are having a meeting with a huge development team. They could be distracted or talking, and an architect is a leader. The action of standing up from your place shows “superiority”, the corporal language is very important when sending a message to people. When I was the captain of the Leadership associations in high school, they told us that our voice, tone, posture, and body language could transmit up to 70% of the message that we actually wanted to tell.

5. There is no one-size-fits-all solution

We all have our silver bullets ready to shoot, but this should not be practiced on our daily routine. Our industry is extremely diverse and broad. We have to understand that, as much as we like to solve problems in one specific way, there could be better and more precise ways of dealing with them. As Tec students, we are used to try to solve any programming problem with Java, and I’m not saying that it is a bad programming language, but as an architect, we should be open to explore the context and look for better ways to solve our problems.

6. It's never too early to think about performance

I laughed a little when I read this one. When I was in my Algorithms Course, we discovered the magic of complexity, and we kept experimenting with the concept in the Operative Systems course. When we got to the Advanced Programming course, the professor told us “Forget everything you learned about performance, just create working code”. So it’s nice to see that I didn’t waste my time studying performance. Start thinking of performance from the beginning of the project, and we can solve a problem before it happens.

7. Commit-and-run is a crime.

For my Management course Ken once brought a Start-Up CEO to the class to talk to us about the industry. They told us that he had an awesome way to stop this horrible crime. Whenever someone made a push to the main branch on the repository that wasn’t tested and fully functional, they had to have a Jesters Hat on their office until the next person made a mistake. If every piece of the code is tested and functional prior to integration, it will make everything else easier.

8. There Can be More than One

Just as we cannot judge every animal by the same rules, we cannot expect our models, formats and transportation work for every one in the company the same. It could be time consuming, but it’s not bad to have 2 solutions ready for the same problem if it is presented. It’s not needed, but we should not be completely closed to the possibility.

9. Architects must be hands on

Being an architect means more than just giving commands to the team, it means to be involved in a project. If a problem is presented, the architect should be aware of it, and should be able to find a solution. I’m not saying that he should be an expert on every single area of the development, but he has to have the tools to lead a team that is actually an expert.

10. Try before choosing

Choosing the technology to be used should be like going shopping with your friends. You are able to try a specific piece of clothing before buying it. Maybe you think that it would be a nice idea to use Java for creating a web application, but you can soon realize that there are better and more effective tools to solve this project. It doesn’t matter if the decision is big or small, testing it before making a decision will save the team a lot of time.

11. Time changes everything

As an architect, you have to be aware of the tendencies around the industry. In the past 30 years we’ve developed more information than in the 2000 before that. Some things have surpassed the test of time, but some others are now outdated. As the architect, you have to find the simplest way to solve the problems you face, also it’s nice when you are comfortable with the choices you made. There might not be a perfect way to solve a project, but you can make it your perfect way for your tea, to work on it.

12. Warning, problems in mirror may be larger than they appear

When you are having an appointment with your team, it’s important to discuss the problems everyone is facing with the code. Talking the problems with everyone present could make them to look smaller, and easier to find a solution to. Trivial issues, bad smells, risks; If the team is aware of them from the beginning, they won’t cause trouble after.

13. Context is King

We live in 2018. Context matters. You can’t take advantage of a piece of a conversation without listening to the full context of it, and this could be troubling. The context is not something fixed. It is always changing, and it is the responsibility of an architect to keep track of all the changes made. The context can influence the architecture, and funny enough this sentence doesn’t limit itself to software. In the past, the World context has made the Architecture of buildings to change with time and space.

14. It's all about performance

Remember how I talked about thinking of the performance from day 1? Here’s why that’s very important: today the only thing limiting us from becoming The Jetsons is that we haven’t been able to get the performances we need to create flying cars and personal assistants. The world spins around the performance the electronic & software engineers are able to obtain.

15. Talk the Talk

In Mexico we all speak Spanish, but I would say that we speak 50 different versions of it. In Guadalajara we use expressions that could mean something totally different in Culiacán. It’s important to know the “language” of the place you are living and working at. If you were to go to a Software Architects convention for some reason, if you know all the common terms used by them you will have a more useful conversation.

16. Fight repetition

This is an advice I always get while getting a project done. Let us imagine the world “Duplication”, now, add some little horns on it. That’s the way it should be. As an architect you have the responsibility of setting the pace of the project, if you plan for your code to be clean, and following patterns, you will help your team to save some time.

17. Welcome to the Real World

Never forget we are part of a bigger world. We as software engineers can get used to Boolean answers to all our questions, but in the real world things can change in a snap of the fingers. Try not to lose it, and go with the flow. Most of the problems in the real world can be solved being a human being. It’s the responsibility of an architect to try his or her best that these problems don’t affect the team a lot.

18. Don't Control, but Observe

The next two are very connected with each other, the software architect should know what’s happening around him, you can use the metrics that can be achieved by the tools that the programming languages have. It’s useless to try to control every single action happening around a project, and can be exhausting. Try to focus on the big picture, while being alert to possible red flags that could appear.

19. Empower developers

Whenever you decide to lose the “control freakiness”, you will have to learn how to trust your team. They have to feel like they are able to take decisions that could affect the entire project. If they are on your team, they are probably experts on what they do, if they are not experts, just be sure they have the capabilities to make a wise choice.

20. It is all about the data

The other day I was talking to my friends about how did Facebook made money at the beginning of the web page. They didn’t have any advertising, or admission fee; and then it hit us. Facebook had tons of information and they could sell it to other sites, to understand their clients. Information is everything! If it is bad managed, then you will have an overwhelmed team. But when it is on your side, then it’s going to be great.

21. Prepare to pick two

I found this point very interesting, sometimes you have to find yourself in a scenario where you won’t be able to satisfy them all. Perhaps you’ll have to pick between satisfying Linux, Mac or Windows; or maybe Android, Iphone, and Windows Phone (?). But it’s going to be extremely difficult to do everything. It’s part of your work to be realist, and to measure the abilities of your team.

22. Make sure the simple stuff is simple

With the time, we become aware of more tools to solve the problems around us, but we forget the simple ways to solve easy problems. Just as chefs, when they become experienced, they stop cooking beef, and carrots, even though everyone likes those ingredients, maybe looking to the past will help you in the future.

23. If there is only one solution, get a second opinion

I’ve always thought that Computer Science is a team-based major. If you meet a great team, that can give you good advice on how to code better, you are going to have a great time studying this. If you have a problem, probably someone knows a better way to do so. It’s okay to ask for advice, and whenever you get some, please let everyone to know that another human being help you.

24. Shortcuts now are paid back with interest later

As you may imagine, there is not an easy way to do something hard nowadays. Just follow the advice of the old tale of the rabbit and the turtle; it’s better to go slow and steady than fast and risky. The first stages of a project are always the most important ones. Designing greatly helps you to not have more problems in the future. Remember than the sooner we identify a problem, the cheaper it gets to solving it.

25. Avoid "Good Ideas"

We all know a guy named Steve (Or Francisco) who will always say something unachievable. Some days they could be helping to finish the projects, but other days they could be trying to convince you and the boss that we could use some hover boards and penguins to travel faster around the company. When everything is defined, it is important to stick to the plan, if a project suffers a lot of changes, it could die or get too complicated.

26. Stretch key dimensions to see what breaks

I think I started to understand how to be a better UX-er after someone told me this great piece of advice: “Think of the average American person, got it? Now remember than half of your audience is less smart than they”. Sometimes people will do something impossible to understand and break your program. It’s better if you break it yourself in the testing areas than let other people to break it for you.

27. It Takes Diligence

Not all days will be bright while leading a team. You could be having the worst day of your life, but remember, your team needs you to be their leader! Maybe you are dealing with a difficult customer, or something is not going as planned in the development area, be around so you can solve the problems and make everyone’s life a little less complicated in time of need.

28. Take responsibility for your decisions

This is an advice that we got when we were in elementary school; yet, everyone seems to have forgot it. We are not perfect; we can make mistakes and the important part is to take responsibility and find a way to solve the problem. Never forget the importance of communication and become the psychologist of your team. Listen to all their problems (at least the related to the code) and try to leave everything clear as water.

29. Choose your weapons carefully, relinquish them reluctantly

It’s common that the Software Architects are the most experiences (and older) developers of an enterprise. The are surrounded by technologies that they have worked with for years. It’s important to choose the tools you will use and then, be proud of your choices. Everyone must be aware of what tools the team is using and support the decision. #GoTeam!

30. It will never look like that

It’s extremely important to plan, but also to know how to let go. Sure, you took 3 weeks on designing how the upper button will look like, but some of those things like that are disposable. Never get attached too much to stuff, because maybe in the process the team could discover a way to do something better.

Portafolio ISC

Para mi clase de Introducción a la Vida Profesional nos pidieron que desarrolláramos un portafolio con las actividades más importantes que desarrollamos en nuestra universidad, y siguiendo el consejo de mi amigo Miguel Pérez Durán, voy a hacer una entrada en mi blog describiendo algunos de los proyectos más importantes en mi "Vida Tec". He desarrollado otros proyectos también, pero considero que estos son los más importantes, o los que más me enseñaron al realizarlos.

Agosto a Diciembre 2017 - Misión: Marte

Misión Marte fue un proyecto que desarrollé en Semestre-I, donde utilizando conceptos de ludificación, creamos un videojuego web para el Colegio Miguel Hidalgo, parte del grupo Enseña Por México y patrocinada por el Grupo Aeroportuario del Pacífico.  Cursamos los módulos de Seguridad Informática, Administración de Proyectos, Aprendizaje Automático, Gráficas Computacionales, Desarrollo Web y Ciudadanía, para poder obtener herramientas para crear nuestro juego. Mi equipo estuvo conformado por Alfonso Ruiz Velasco, Edgar Javier Díaz, Daniel Jiménez y Manlio García. Misión Marte es un juego cooperativo que busca reforzar las habilidades matemáticas de 3er y 4to grado de primaria utilizando conceptos básicos de codificación, comunicación y trabajo en equipo.

Liga a nuestra documentación
https://drive.google.com/drive/folders/0B8QEyzod9huEOEstc3IybnF5WlE?usp=sharing
Liga al juego
https://misionmarte.net
Video de uso del primer avance:

Octubre 2016 - Hello Social World

Quizás este es el evento que más me ha gustado de mi carrera profesional. En el marco del Quinto Changemaker Day, en el Tec de Monterrey Campus Guadalajara, mi equipo (Diego Toledo, Daniel Jiménez, Fernanda López, César Alfredo Espinosa y Hugo Michel), un formidable grupo de personas, y yo creamos un reto social y tecnológico, en conjunto con Techo, Unidos, El Banco de Alimentos y los gobiernos municipales de Tequila y otros dos municipios en Jalisco. Con más de 150 participantes y 30 proyectos presentados, lo considero como el giro necesario para mantener vivo el concepto de Hackathon.

Video:

Enero 2015 a Mayo 2017 - Wallet Dots / E-Dots

Sé que parecen muchos meses para el desarrollo de un proyecto, pero E-Dots fue una aplicación móvil que desarrollé junto con Rodolfo Lepe a lo largo de las clases de mi carrera. La idea nació en Diseño de Interfaces, la continuamos en Algoritmos y Bases de Datos, para terminar su desarrollo en el curso de Aplicaciones Móviles. La aplicación detecta si estás en clase y premia a los usuarios por no utilizar el celular mientras está dentro del salón.
La aplicación estuvo en la Google Play Store, pero después de un cambio en los términos de uso, la tuvimos que dar de baja.

Video

Enero a Mayo 2018 - Econutri

Econutri es un proyecto que desarrollamos Valeria Macedo, Griselda Herrera y yo en mi clase de Emprendimiento Social Honors Onceava Generación. Realizamos alianzas estratégicas con ONI A.C. y Agropacific, para proponer una solución accesible económicamente para las madres de familia de la colonia Lomas de la Primavera en Zapopan, Jalisco.

Video:

Enero a Mayo 2016 - Tay Tay Love

TayTayLove es un juego móvil que desarrollamos Rodolfo Lepe y yo para nuestro curso de videojuegos. La dinámica es simple, solo tienes que seguir las órdenes que los clientes que entran a tu cafetería te piden. La aplicación se encuentra en la Google Play Store y es compatible con la mayoría de los dispositivos Android.

Link al juego

https://play.google.com/store/apps/details?id=com.WhiteGirlSquad.TayTayLove

Enero a Diciembre 2016 - Redes

Durante este año aprendí a configurar redes junto con mi equipo, Rodolfo Lepe, Daniel Jiménez y Alfonso Ruiz Velasco. Fue una de mis clases favoritas, y en la que más podías darte cuenta lo mucho que había aprendido en mi carrera.

Videos

Enero a Mayo 2018 - Habitioli

Este semestre en mi clase de Arquitectura de Software, formé equipo con Rodolfo Lepe, Daniel Jiménez, Alfonso Ruiz Velasco, Sebastián de la Hoz y Manlio García para desarrollar una aplicación web que funcionara a base de micro servicios. La app te deja configurar tu cuenta, con hábitos y tareas diarias.

Adjunto el microservicio que yo desarrollé.

Habits
https://github.com/geravm/habitsHabitioli

Friday - UX Course by Wizeline. (5)

Sprint is a methodology used to find solutions to problems in just five days. Jake Knapp divided the chapters of his books by days of the week; Monday is all about planning, defining the problem, and choosing an objective, Tuesday is the time when we start looking for ideas to solve the problem, Wednesday talks about evaluating the ideas, and choosing the best solutions proposed by the team. On Thursday, we have to create a prototype of the product. And Friday is the grand finale: We will interview people to know their points of view. After that, we will learn what we have done right and what we have to modify.

This time around, the book starts talking about how we will plan our interviews. We have to be prepared to observe how the people that will help us with the validation react to it. You will become Sherlock Holmes in this day; getting all the information we can from the interactions of our validator. Before anything else happens, we will take a detour to Orlando, because they have the Magic 5 on their city (I’m sorry for the bad basketball pun). According to Knapp, 5 is the perfect number of interviews to get good results.

Now we are ready to interview people! And we will go back to our favourite number (5, like the week days). The interview can be divided, starting with a warm welcome, then we will give our user some context by asking them some related questions, we will present our prototype to them, and after it, we will ask him to do something specific. The fifth element (not the futuristic one) of the interview is to create a brief text of the impressions of our client.

Sometimes the user will be a little lost when they are using your prototype, so you can guide them through some questions, to see if they can manage the tank you gave them. Another important thing is to never forget to be a good host, just as Lumière was to Belle. You should not cut a conversation if it’s not relevant to your app, make him / her feel relaxed with your interview.

Now you may be in one of two scenarios. First scenario: when you get all the feedback it may destroy everything you liked about your prototype, and make you re-evaluate every part of it, to make it a better app, of course. The second scenario is that you get some positive feedback, which means you did something wrongly in your interview. This is just a joke, but probably, you will get more bad comments than good, just as in the Internet.

We have to learn about this experience, we will find patterns, or comments that were repeated in more than one interview. We will embrace the good and fix the bad for the next time we have to share our project.

With the end of the Friday, we come to the end of the Sprint as well; Knapp found out that this was the most effective way to use our time to develop an idea. I learned so much from this experience and I’m thankful for it.

Thursday - UX Course by Wizeline. (4)

Sprint is a methodology used to find solutions to problems in just five days.

Jake Knapp divided the chapters of his books by days of the week; Monday is all about planning, defining the problem, and choosing an objective, Tuesday is the time when we start looking for ideas to solve the problem, Wednesday talks about evaluating the ideas, and choosing the best solutions proposed by the team. Thursday is a very busy day; we have to create a prototype of the product.

This time around, we are going to divide the day in two: The Dali & Picasso version of our prototype and the Manet one. In the morning, we will have to change our surrealistic expectations to prototype expectations. So, without further ado, here I present our philosophies for the next hours.

We can create a prototype with almost anything. When I took my User Interfaces course we created a prototype only with a card board and some post its. Prototypes are disposable. We can’t fall in love with them; our project is too young for that! Create only for learning purposes. We are looking to get data, we can go full façade, and it doesn’t have to be functional just yet. The prototype must LOOK real. It has to be like the actual product, so the users can imagine how would that work.

Then, for the rest of the day, we will have our hands busy. The team will be joining forces for the last time to choose the tools to be used. When this is defined, we will call our inner-Cersei Lannister, because we will divide our team and conquer the project. Some will work only on the prototype, and we don’t need any fancy tools to prototype. If we want to develop an app, we can use Power Point to sketch it. Others will be in charge of getting assets, stitching everything together, and that it makes sense. Don’t forget to document everything, so you know what we did right and what we did wrong.

Thursday may be the most tiring day out of all. The team’s project is becoming a “reality” and we will have a model to understand how people would use it. By changing our mentality to a more flexible one, and defining how we are going to be working, we are set to start a great idea to work on. 

Wednesday - UX Course by Wizeline. (3)

Sprint is a methodology used to find solutions to problems in just five days. Jake Knapp divided the chapters of his books by days of the week; Monday is all about planning, defining the problem, and choosing an objective, Tuesday is the time when we start looking for ideas to solve the problem, and Wednesday talks about evaluating the ideas, and choosing the best solutions proposed by the team.

In the morning, we are going to have to canalize our inner Meryl Streep, because we are going to be taking tougher decisions than Sophie’s Choice. Usually, everyday starts with a meeting where everyone gives his or her points, and nothing happens after it. Sprint recommends us another way to do so. Instead of having everyone arguing about whose idea is better, the team observes all the ideas, they will be displayed as if they were paintings in a museum.

                  
After the team has the chance of observing them for a while they will have the chance of remarking the most interesting parts in every idea. This should be achieved almost anonymously. Then, for the first time, the team will have the time to chat about the best points of each solution. After this brief moment of talking, we get the chance of remaining quiet again for some more time; we have to vote for the best solution. If there’s a tie, the decision maker will have to use his super-vote.

                  
By having this process in silence, the team feels more confident on making observations and giving negative feedback, without having the fear of hurting someone’s feelings. Honesty is key on getting a real solution for a problem.

                  
Congrats! If you got to this part, you already know your solution! But it is still way too soon to start prototyping. There’s a tool in cinematography called Story Boarding. This tool helps you to understand graphically how do you want your script to be seen as. We will use it to generate a 15 squares user story, imagining what do we want the user to do with our technical solution. We have to show every step from the moment the user gets to know the solution to the moment he/she gives us feedback about it.

Although prototyping is something that we are good at, and the fastest way to solve the problem in our heads, we have to be sure that we are working on the best solution possible. By analyzing every solution, and remarking the most important parts of it, we can assure to have an item that will be used. After having picked a solution, we have to pretend to be the customer, and if we get a good experience from the solution, we can hope other people do it as well.

Tuesday - UX Course by Wizeline. (2)

Sprint is a methodology used to find solutions to problems in just five days. Jake Knapp divided the chapters of his books by days of the week; Monday is all about planning, defining the problem, and choosing an objective, Tuesday is the time when we start looking for ideas to solve the problem.

The day is divided in just two sections. The fist part is all about mixing and improving actual solutions that exist to similar problems. If the problem you chose is about the medical industry, you are going to have to research about actual hospitals and clinics that already cover your problem. When you have identified some references, you will have to try to make it better somehow. The next step is to find a way to get all these good ideas and try to apply them on your project. What we’re looking forward is to get a functional prototype. After focusing on a specific part of the problem, and looking through all the possible existent solutions we can start designing some possible solutions.

The second phase of the Tuesday talks about designing possible solutions for the problem. The book shows us that you don’t have to have any expensive tools to start making designs for projects, and how drawing helps you to understand what you really want to achieve with your solution. We learned about the Crazy-8 method, where in only 8 minutes, you have to draw 8 sketches of possible solutions and make them as different as possible, this will help you to understand what are the most important features of the solution you want to implement.

In the next phase, you have to draw a story, so you can see how an user would interact with the solution, if it is not easy to understand, it will be useless, and we want our solution to be adopted.

It is important to design before starting to implement, maybe you don’t have a clear idea of what you are really looking forward, or maybe it would not help to solve the problem you wanted to. It is cheaper to correct a design than to correct a finished solution.