-
Administración / Management / Administración de Proyectos / Project Management / Destacadas / Featured / Product ManagementStrategic planning and prioritization present significant challenges for today’s Product Managers and Product Owners. A comprehensive and effective product roadmap[1] creation is the cornerstone for navigating these hurdles. Just as a street map guides you from point A to point B, a product roadmap[1] bridges the gap between product strategy and the development process.
Understanding the Core of a Product Roadmap
Think of the product roadmap[1] as your strategic compass. It provides a structured plan for outlining your product’s direction, articulating the vision, and delineating crucial deliverable phases. This roadmap[1] offers essential context for stakeholders, elucidating the reasoning behind your development endeavors. Ideally, it offers a concise overview that fosters alignment among product managers and key stakeholders such as product marketing, sales, and customer service. However, it’s essential to remember that the product roadmap is a blueprint, not an inflexible commitment.
The product roadmap[1] transcends a mere list of features or tasks in a backlog. It must paint a broader picture, highlighting initiatives that drive progress, capitalize on emerging markets, respond to competitive dynamics, and deliver customer value.
Distinguishing Between Product Roadmap and Backlog
It’s vital to distinguish between a product roadmap[1] and a backlog. While there’s a tendency, particularly in startup environments, to blur the lines between them, understanding their unique roles is crucial. The product roadmap operates higher, focusing on communication and strategic alignment. In contrast, the backlog is meticulously crafted for execution, detailing specific tasks and requirements. To draw a parallel, envision the product roadmap as an enticing menu description of a dish, while the backlog serves as the detailed recipe guiding its preparation.
Enlarge
Roadmap vs Backlog It’s worth noting that, while the product roadmap operates at a higher level than the backlog, utilizing tools capable of synchronizing items between the roadmap and the backlog is ideal. This ensures that information remains updated, minimizing the risk of team misalignment or prioritization errors.
The Crucial Role of Product Roadmaps in Business Success
A product roadmap serves as a navigational aid, streamlining the journey toward your destination. For a product manager, it stands out as the paramount tool for articulating the vision and strategy of a product and securing support from crucial stakeholders. Picture it as the vital link between strategic planning and the development process.
Understanding the Significance of Product Roadmaps
Imagine a roadmap as your compass in the vast terrain of product development, providing clear direction and guidance to navigate the journey from conception to execution. Much like a detailed outline before a research paper, a product roadmap offers a structured plan, empowering product managers with invaluable insights and a strategic advantage.
Key Objectives of Product Roadmap Creation
A well-designed product roadmap serves multifaceted purposes, including:
- Defining the vision and strategy of the product
- Directing the execution of strategic initiatives
- Aligning internal stakeholders toward common goals
- Facilitating discussions on potential options and scenarios
- Communicating development progress transparently
- Sharing the strategic direction with external stakeholders
Your best resource for outlining your goals and approach for a product is a product roadmap.
Navigating the Challenges: Roadmaps Pitfalls and Solutions
While product roadmaps offer transparency and insight into a product’s future trajectory, they also present challenges and potential pitfalls. One such challenge is the risk of revealing strategic plans to competitors, potentially enabling them to capitalize on innovative features before your product launch. To mitigate this risk, consider implementing dual roadmaps – one for internal planning and another for external communication. Furthermore, once a roadmap is disclosed, making alterations can be challenging, as it may become inadvertently tied to contracts, transforming a strategic plan into a binding commitment. To address this, exercise caution in the distribution of physical roadmaps, ensuring the product manager exclusively manages discussions about the product’s future.
Mastering the Art of Product Roadmap Creation
In the dynamic landscape of product development, mastering the art of Product Roadmap Creation is essential for driving business success. By leveraging a well-designed roadmap, product managers can confidently align stakeholders, communicate strategic vision, and navigate the complexities of product development. Embrace the power of Product Roadmap Creation as your guiding compass toward achieving business objectives and staying ahead in the competitive market landscape.
Exploring Effective Product Roadmaps: Types and Strategies for Success
When we talk about product management, mastering the art of Product Roadmap Creation is essential for driving strategic initiatives and achieving business objectives. However, it’s crucial to understand that not all roadmaps are created equal. In this guide, we get into common types of effective product roadmaps and explore strategies for their successful implementation.
Unveiling the Diversity of Product Roadmaps
While the term “product roadmap” is often used in singular form, the reality is that organizations often utilize multiple roadmaps, each tailored to specific purposes and audiences. By understanding the nuances of different roadmap types, product managers can effectively communicate strategy, align stakeholders, and drive successful product development initiatives.
Types of Effective Product Roadmaps
- Portfolio Roadmap: This high-level plan outlines general milestones for executing the strategy across an entire product portfolio. It’s instrumental in demonstrating how individual or team contributions align with the broader picture.
- Strategy Roadmap: Consider this as the inaugural roadmap for a new product. It communicates the product’s strategy, major milestones, core features, and planned releases.
- Releases Roadmap: While maintaining a high-level perspective, this roadmap delves deeper into product releases. It includes specific tasks leading up to a release and designates responsible individuals or teams.
- Features Roadmap: This roadmap outlines the timeline for releasing specific product features. Emphasizing general dates (e.g., “Week 2” or “Q3”) prevents committing to specific dates that may be challenging to meet.
- Theme-Based Roadmap: Instead of a features roadmap, based on experience I recommend adopting a theme-based roadmap. This approach provides flexibility by grouping similar product features, epics, or initiatives under overarching themes tied to measurable strategic goals. For instance, a theme like “Customers Complete First Purchase Faster” aligns with a strategic objective. The theme-based roadmap allows for reprioritization without setting unrealistic expectations for stakeholders.
In the changing environment of product management, understanding the diversity of product roadmaps is key to driving successful outcomes. By leveraging different roadmap types strategically, product managers can effectively communicate vision, align stakeholders, and navigate the complexities of product development with confidence. Embrace the power of Product Roadmap Creation as your guiding compass toward achieving business objectives and driving innovation in today’s competitive market landscape.
Do not forget to differentiate your roadmaps for internal versus external audiences. An example, developers versus marketing people, etc.
Crafting a Compelling Product Roadmap
Before diving into the intricacies of Product Roadmap Creation, laying a strong foundation is essential. The most critical phase of the roadmap process occurs during the strategic planning phase, where the vision and goals for the product are established and aligned with stakeholders. This foundational step is key to crafting a roadmap that resonates with your team and drives meaningful outcomes.
Establishing Product Strategy and Vision
When developing a strategy for your Product Roadmap, it’s imperative to start by familiarizing yourself with your product strategy. This involves pinpointing and articulating the vision and principles that underpin your product—the “why” behind its existence. By investing time in defining your product’s mission, you lay the groundwork for a roadmap that is purpose-driven and aligned with your overarching goals.
Documenting the Product Mission
Before diving into roadmap planning, take the time to distill your product’s mission into a clear and concise statement. This statement should encapsulate the product vision, target customer base, problems addressed, and the value proposition it brings to the market. Documenting this information solidifies key elements that shape your roadmap and facilitates communication and alignment with stakeholders.
Advantages of a Strategy-First Approach
Embracing a strategy-first methodology offers numerous advantages in Product Roadmap Creation. It streamlines communication of the product vision across the organization, ensuring alignment before detailed discussions begin. Additionally, it provides clarity on priorities and helps identify elements that may not align with the overarching product vision.
Formulating Outcome-Oriented Goals
Building on the product vision, establish clear and outcome-oriented goals that shape the initiatives outlined on your roadmap. These goals serve as a roadmap’s backbone, translating strategic vision into actionable plans that drive tangible results.
Driving Success Through Strategic Product Roadmap Creation
Crafting a compelling Product Roadmap requires careful planning, strategic vision, and alignment with stakeholders. By investing in the strategic planning phase and establishing a clear product vision, you set the stage for a roadmap that not only guides your team but also drives meaningful outcomes and success in today’s competitive market landscape.
Maximizing Product Roadmap Success with Integrated Key Performance Indicators
When you get involved in Product Roadmap Creation, the integration of Key Performance Indicators (KPIs)[2] plays a pivotal role in driving strategic decision-making and elevating roadmap effectiveness. Let’s explore how the strategic integration of KPIs can enhance your product roadmap and propel your business forward.
Setting the Stage for Strategic Planning
Once your product vision is crystallized, the subsequent step involves defining distinct product goals accompanied by assigned metrics. These goals, spanning shorter durations, typically one to two years, provide a roadmap for success. Whether you opt for a North Star metric model or a set of equally weighted metrics, the integration of KPIs ensures alignment with overarching strategic objectives.
Leveraging Metrics for Informed Decision-Making
Metrics serve as invaluable tools for steering both product decisions and the trajectory of your roadmap. Business-oriented metrics such as revenue, margin, acquisition cost, and retention act as effective connectors, linking roadmap initiatives to your overarching strategy. Additionally, customer-centric metrics like product usage and retention offer valuable insights, aligning with broader strategic objectives and driving sustainable growth.
Strategic Prioritization: Elevating Initiative Ranking
With your product goals and metrics in place, strategic prioritization becomes paramount. Prioritizing initiatives for inclusion in your product roadmap ensures maximum impact and success. Our recommendation is to utilize the Value vs. Effort model. Assess each initiative essential to realizing your product release vision and place it on the Value vs. Effort scale. This strategic approach optimizes resource allocation, prioritizing and aligning high-impact initiatives with your overarching product strategy.
In conclusion, the integration of KPIs into Product Roadmap Creation enhances decision-making, drives strategic alignment, and maximizes business success. By leveraging metrics effectively, you can propel your roadmap forward and achieve your organizational goals with precision and clarity.
Strategic Initiative Blend
Achieving a balanced mix of initiatives across both blue and yellow quadrants is crucial. Start with low-effort, high-value tasks—the low-hanging fruit. Then, incorporate high-value, high-complexity initiatives that could set you apart from competitors.
Addressing Customer Requests
To cater to customer needs, include some low-value/low-effort initiatives that customers have requested. While individually they may not drive significant impact, collectively addressing customer feedback enhances overall satisfaction.
Refining Focus and Prioritization
Alternatively, among other methods, explore different prioritization models like the Kano Model[4], which evaluates initiatives based on customer delight, or maybe you can use the MoSCoW model, which is useful for finding features or qualities. Categorize initiatives as essentials, performance enhancers, or delight-inducing features to stand out from the competitors.
Utilizing Contemporary Models: The RICE Scoring Model
The RICE[3] Scoring Model is a modern approach to prioritization. Assess initiatives based on Reach, Impact, Confidence, and Effort:
- Reach: Influence on customer base
- Impact: Effect brought about
- Confidence: Level of confidence in reach and impact
- Effort: Time and effort required
As I mentioned, RICE is not the only prioritization model but is an excellent starting point, consistency is key. Commit to a prioritization method and use it as a foundation for adapting your roadmap to stakeholder requests throughout the development process. Consistency ensures alignment with strategic objectives and enhances roadmap effectiveness. In conclusion, effective prioritization strategies are essential for successful product roadmap creation. By adopting a strategic blend of initiatives, addressing customer needs, and leveraging modern prioritization models, you can optimize your roadmap to drive innovation and stay ahead in the competitive landscape.
Stakeholder Involvement: Engaging Your Collaborators for Product Roadmap Success
Product development is swiftly evolving, largely driven by agile software development practices. Gone are the days of lengthy development cycles lasting 12 to 24 months; today, products can materialize in as little as three to six months, or even less.Collaboration with stakeholders should be ingrained in your planning and development processes from the project’s inception. By incorporating their input early on, you ensure alignment and buy-in throughout the roadmap creation process. After crafting your product roadmap, it’s crucial to secure stakeholder endorsement. While close collaboration throughout the process minimizes surprises, obtaining formal endorsement ensures alignment and commitment to the roadmap’s objectives. Collaborating with stakeholders to refine prioritizations further enhances roadmap effectiveness and stakeholder satisfaction.Maintaining Stakeholder Engagement Throughout Execution
Even as the product roadmap is set into motion, maintaining frequent engagement with stakeholders is essential. The roadmap serves as a valuable reference point during stakeholder interactions, facilitating collaborative decision-making and alignment with strategic objectives. Example Scenario: Leveraging the Roadmap for Collaborative Decision-Making For instance, if the VP of Sales urges the inclusion of a specific feature based on customer feedback, referencing the prioritization method and roadmap allows for an objective assessment of the feature’s value. This collaborative approach ensures that roadmap decisions are driven by data and strategic alignment rather than individual preferences.Optimal Update Frequency: How Often Should You Revise Your Product Roadmap?
Adaptability is Key: Revisiting Your Product Roadmap
The frequency of revisiting and updating your product roadmap depends on several factors, including your development timeline, market shifts, competitive landscape, and consumer expectations. Ideally, conducting a weekly or daily review and update of your roadmap proves beneficial. However, this doesn’t necessitate communicating these updates at the same frequency. Depending on your audience, periodic weekly or monthly communication may suffice. Embracing agility in product roadmap creation is essential to stay ahead in today’s dynamic market landscape. Adopting a flexible approach to roadmap revision and communication allows you to navigate the evolving product development landscape with confidence and agility.Adapting Product Roadmaps to Agile Environments
Enhancing Roadmap Effectiveness with Measurable Success Benchmarks
- Clear Success Metrics: Introduce measurable success benchmarks for each roadmap item to provide clarity and encourage accountability within the development team. This ensures that every feature or functionality aligns with tangible business goals and can be tracked for its impact on overall success.
- Alignment with Purpose: Connect every aspect of the roadmap with the product’s overarching purpose, closely tied to the organization’s mission. By framing roadmap items within the context of their purpose, scrum teams gain a deeper understanding of their work’s significance and its contribution to broader organizational goals.
Plans are nothing … Planning is everything
Establish a Robust Communication Framework
To know more:
[1] The concept of the “product roadmap” originated in the early 1900s as motorist aids, with the first roadmaps listing instructions on how to get from one town to another, where to find gasoline, and where to find a repair shop.
[2] The concept of KPIs saw its last big change in the 1990s with the introduction of the Balanced Scorecard by Dr. Robert Kaplan and Dr. David Norton Kaplan, in 1996 The Balanced Scorecard: Translating Strategy into Action.
[3] RICE prioritization model was developed by Intercom, a messaging-software producer, to improve its internal decision-making process https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
[4] “Attractive Quality and Must-Be Quality” – Professor Noriaki Kano introduced Kano Analysis, a revolutionary approach to understanding customer satisfaction that expanded beyond conventional marketing theories in 1984. https://www.jstage.jst.go.jp/article/quality/14/2/14_KJ00002952366/_article/-char/en
Related links:
Agile’s Origins and Values
The Scrum Team Size
What Scrum Master Certification to Choose?Some books to know more:
Moore introduces the “crossing the chasm” marketing theory, which segments customers into different groups (innovators, early adopters, early majority, late majority, and laggards). The book provides insights on how to market products to each group sequentially, building upon the success of the previous one.
Christensen explores why established companies often fail to adapt to disruptive technologies. By understanding the innovator’s dilemma, product managers can make informed decisions and navigate technological shifts.
This book compiles Mironov’s popular articles from his column, “Product Bytes.” It covers topics like understanding customers, pricing products, and maintaining effective product organizations.Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Criptomonedas / Cryptocurrency / Destacadas / Featured / Finanzas Personales / Personal Finance / Póntelo / Put it onMe he hecho de un Trezor Model T…
Ok, ok, antes de hablar del Trezor Model T, haré un poco de intro para los menos experimentados en el tema de las criptomonedas.
Como persona que ha tratado de aprender de finanzas personales desde hace unos años, es imposible no llegar en algún momento, a considerar la inversión en criptomonedas, al menos por un momento.
Al entonces decidir invertir en este tipo de activos, ya sea en Bitcoins, Ethereum o cualquier otra criptomoneda, eventualemente también se entienden sus riesgos.
Mientras que algunos confían en exchanges para custodiar sus cripto-assets, los usuarios que van adquiriendo más experiencia, comienzan a considerar otras opciones más seguras, como las hot wallets y las cold wallets.
Al final una cartera o monedero frío o cold wallet, como los que ofrece la marca Trezor, se vuelva una de las opciones más populares y seguras en el mercado, pues ofrece seguridad, comodidad y versatilidad.
Unboxing de la Trezor Model T
Me gustó mucho el empaque en el que venía la Trezor Model T. Se nota que la empresa se tomó un tiempo para planificar el tipo de experiencia que deseaba que tuviera cada cliente.
El equipo de SatoshiLabs planificó metódicamente el tamaño y las dimensiones específicas de la caja para que la parte inferior se deslice lentamente desde la parte superior. Así también, los espacios de todos los elementos que vienen dentro de esta. En fin, una experiencia premium, que no tenía desde que abrí mi último Ipod Touch (sí, hace mucho…)
El dispositivo en si viene con una etiqueta de seguridad para evitar una manipulación indebida. Esto ayuda a poder percatarse si el dispositivo ha sido comprometido durante su envío.
Al ver lo que la caja contiene la caja, nos encontramos con sus elementos esenciales y un par de agradables detalles. Como se muestra en la imagen, en el lado izquierdo está el monedero Trezor Model T y en el lado derecho una pequeña caja que contiene el cable, las tarjetas para anotar las palabra de recuperación o semilla, el manual de instrucciones y unos bonitos stickers. El monedero se fija a la estructura de la caja mediante un práctico y estético imán.
En detalle, lo contenido dentro de la caja es:
- El dispositivo Trezor Model T. La billetera con su etiqueta de seguridad que garantiza la integridad de la misma. En caso de que esté despegada o dañada hay que ponerse en contacto con SatoshiLabs para que reemplacen el dispositivo por uno nuevo. Cómo mencioné anteriormente, esta etiqueta sirve para asegurar que el dipositivo no ha sido manipulado durante el envío.
- Manual. Está escrito en inglés e indica las especificaciones del Trezor Model T, las recomendaciones de instalación, el contenido de la caja y una serie de instrucciones relativas a la seguridad.
- Cable USB C/USB. Es el cable que permite conectar el monedero a la computadora. No he probado, pero la billetera también funciona con dispositivos móviles a través de cable USB-C/USB-C que el fabricante ofrece por separado,
- Dos tarjetas “recovery seed”. Son unas tarjetas de papel donde se puede anotar las palabras semillas de recuperación de la billetera. Es importante guardar estas palabras en un lugar seguro, ya que permiten recuperar el monedero si el dispositivo es dañado o extraviado, y desea regenerar sus criptos en un dispositivo nuevo.
- Stickers de Trezor. Curioso detalle del fabricante 🙂 , no se necesitan para ningúna funcionalidad.
Configuración del Trezor Model T
La cartera o monedero digital Trezor Model T es un cold wallet basado en hardware, lo que significa que utiliza claves generadas por una fuente que no está conectada a la blockchain y por tanto, tampoco a Internet, logrando así un alto nivel de seguridad.
En otras palabras, cuando se hace una transacción, la operación se firma en el dispositivo y, de esa forma, se evita que las claves privadas estén expuestas, a diferencia de lo que ocurre en los monederos para PC, monederos para móvil o carteras en línea.
Para comenzar a usar el Trezor Model T, sólo hay ir al URL oficial y observar los siguientes pasos:
1. Instalar el Trezor Bridge
El monedero funciona en los principales navegadores. En mi caso he utilizado Chrome, ya que es el más empleado. Para que pueda funcionar es necesario instalar el Trezor Bridge, de lo contrario el navegador (ni carteras de PC compatibles, como Exodus), podrán detectar ni permitirle acceder al dispositivo.
Para instalar el Trezor Bridge e iniciar el monedero hay que conectar el mismo a la PC y entrar en la web oficial que aparece en la pantalla del dispositivo.
2. Seleccionar el modelo de cartera Trezor
Al momento de publicar esta entrada, la SatoshiLabs comercializa dos tipos de carteras digitales: Trezor One y Trezor Model T. Al momento de configurar esta cartera digital o querer acceder a los fondos en ella, la página web siempre preguntará por el tipo de monedero empleado.
Cómo es obvio, en este caso, hay que hacer click en “Trezor Model T” para poder continuar con la configuración de la cartera.
3. Instalar el firmware en el Trezor Model T
Al recibir la cartera digitial Trezor esta no incluye su firmware previamente instalado, ya que suele actualizarse con frecuencia para ofrecer nuevas funcionalidades y corregir posibles bugs. Debido a esto cuando se configure el dispositivo por primera vez, aparecerá un mensaje en el que se solicita autorización para descargar e instalar el firmware.
Simplemente hay que hacer click en el botón “Install Firmware” y aparecerá la barra de progreso de la instalación del mismo firmware.
4. Crear nueva cartera o recuperarla
Una vez instalado el firmware, aparecerán dos opciones. Una opción es para el caso en el que a usted le interese recuperar una antigua cartera en el nuevo dispositivo. Para recuperar la cartera necesitará tener a la mano las palabras de recuperación. Una vez recuperado aparecerán todos los fondos en el nuevo dispositivo.
Pero profundicemos en el caso supuesto de que no tiene ninguna cartera Trezor (hasta ahora). Para este caso, vamos a hacer click en “Create wallet”.
En seguida nos muestra otra opción en donde podemos crear una billetera con respaldo simple o con respaldo Shamir . El respaldo Shamir permite crear varias frases de recuperación si así lo desea, pero para mi caso decidí mantener las cosas simples e irme por la opción sencilla haciendo click en “Create with Single Backup”.
5. Crear nueva cartera Trezor Model T
Después de seguir las instrucciones en la pantalla del dispositivo, donde se confirma que quiere crear una nueva cartera, la billetera ya ha sido configurada esencialmente, pero para garantizar que todo esté seguro, es muy importante hacer una Backup de la misma.
El proceso de backup tiene una duración de alrededor de 3 minutos e incluye escribir las palabras que aparecerán en la pantalla, en la tarjeta de papel “Recovery Seed”. Con esto en mente hacemos click en “Create backup in 3 minutes”.
Antes de iniciar buckup, se mostrará un mensaje con advertencia de seguridad:
Su semilla (o palabras) de recuperación solo se puede mostrar una vez. Nunca haga una copia digital de su semilla de recuperación y nunca la cargue en línea. Guarde su semilla de recuperación en un lugar seguro.
SatoshiLabs no se hace responsable de las obligaciones de seguridad de las pérdidas financieras que resulten de no seguir las instrucciones de seguridad.También se muestra un lista de acciones a evitar:
- No tome fotos de la semilla (o palabras) de recuperación.
- No la escriba en la computadora.
- No la coloque en ningún lugar de almacenamiento (USB, disco duro, etc.).
- Nunca la suba a Internet.
En resumidas cuentas, la semilla debe escribirse en papel (la tarjeta que viene con la billetera) y guardarse en un lugar seguro. Cualquiera que sea dueño de la semilla o palabras de recuperación será dueño de todos los fondos en la billetera.
Luego entonces, las palabras aparecerán en la pantalla de la cartera y, una vez finalizado, el dispositivo pedirá que se elijan tres palabras aleatorias de las 12 generadas.
Una vez que todo el proceso se ha realizado, en la pantalla del navegador se mostrará un mensaje indicando que todo ha ido bien e invitará a continuar con la configuración de la billetera.
En le siguiente paso, hay que crear un PIN de acceso. Es muy importante realizar este paso para evitar que en caso de pérdida alguien pueda acceder a los fondos de la cartera electrónica. Este proceso se completa en la pantalla del dispositivo.
A continuación, se dará la opción de asignar un nombre a la cartera . En mi caso he puesto EHRWallet01 y he pulsado en “Confirm to continue”.
Finalmente en el siguiente paso, sólo se nos sugiere agregar a nuestro marcadores la URL wallet.trezor.io para evitar caer en alguna otra página falsa que pretenda aplicar phishing para obtner nuestros datos.
Opcionalmente, también se ofrece la opción de incluir un correo electrónico para mantenernos al día con actualizaciones y noticias relacioanadas con Trazor. Personalmente, en la políticia de proporcionar la menos información posible, me salte este paso en “Skip this step”.
¡Listo con esto, nuestra cartera digital está preparada para usar!
Funcionalidades de la cartera Trezor Model T
Dentro de las características destacadas del Trezor Model T están que incorpora una pantalla táctil que permite interactuar de forma muy sencilla con el dispositivo. Incorpora una ranura microSD que ofrece, entre otras cosas, gestionar contraseñas desde tarjetas SD en vez desde la nube, lo que añade otra capa opcional de seguridad.
El introducir claves y confirmar transacciones se realiza todo a través de la pantalla táctil y, por tanto, resulta mucho más cómodo y más seguro con respecto a la captura en pantalla que hacen otras carteras.
Esta cartera tiene la capacidad de reconocer algo más de 500 criptomonedas y tokens (el modelo Trezor One soporta sólo 100).
Además de lo anterior y entre otras posibilidades, se ofrecen las siguientes:
- Enviar y recibir criptomonedas.
- Crear varias carteras para gestionar los fondos desde una misma cuenta.
- Realizar transacciones OP_RETURN para realizar pruebas de existencia o grabar mensajes en la blockchain.
- Programar envíos en fecha y hora determinada.
- Realización de envíos a múltiples destinatarios.
- Firmar y verificar mensajes.
- Exportación de las transacciones en tablas csv.
- Integración con Dropbox para almacenar información sobre las transacciones (etiquetar cuentas, transacciones, etc).
Hay más para comentar, pero por ahora, si alguien desea saber más detalle o quieren una continuación de esta entrada, déjemelo saber en los comentarios, en el Twitter, Fecebook o Instagram de Internet80 o bien en mi cuenta personal de Twitter. ¡Buena suerte!
Otros enlaces:
Tienda oficial del Tresor Model T
Resenaña en Bitdegree.org (inglés)
BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxwLTC: LdiiMfiJvqrXDw1xPMqDptXGFEkyADZzVVDOGE: DKehWtHnmrf7JTRWpEQ9LtqwqY8HdbdkbUSOL: 3f2RR9w2VwmBqjLm5DmbuUPwWfdYH7GXCbHVWhsq5skyEmmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Nowadays Mobile Testing is so important to ensure Quality, but one of the most common problems is the speed of an automated test. There’s no point in automating a set of test cases if the execution time of a single Automated Test is more than one or more Manual Tests.
This problem is really common when automating Android Test Cases using Appium and UIAutomator or UIAutomator2, one solution is to use “Espresso Driver” but requires:
- App has to be an Android Native.
- It’s important to have the source code of the App.
But most of the time, Companies doesn’t always provide the source code (Commonly if the App was made by a third-party) or the App’s development is with a No-Native Android App using external frameworks as React-Native.
In these scenarios, there’s also another big problem, not all developers use unique and fast locators while developing an App, whether for Android or IOS like the usage of IDs. Most of the time we have to deal with XPaths, that is not only not recommended, due to the change of the DOM’s structure but also are extremely slow when are processed by Appium’s most common drivers like UIAutomator and UIAutomator2.
Here is where TestProject comes to help, even though I don’t recommend using the UI Interface of TestProject for big Projects because of the lack of maintainability and scalability. Using the UI of TestProject has a lot of dependency on the tool itself because it’s more focused on the “No Coding” Framework. Later on, if there’s a feature or functionality that TestProject doesn’t provide, we’re going to start coding, which it’s going to be more difficult to adapt the code generated by TestProject and adapt it to our necessities.
Anyhow, TestProject comes with an SDK for Java and Python, which easily (there’s almost none of the documentation) to integrate with our code to avoid using Appium and UIAutomator.
- We need to register in TestProject Web Page at https://testproject.io/ and Download the TestProject Agent.
TestProject Agent is available for Windows, Mac OS X and Linux (It’s also available in DockerHub). 2. To be able to run the Agent, we need to get our “Developer Token”, to get it, go to “https://app.testproject.io/#/integrations/sdk”, save this token for later.
3. In a Maven Project, let’s add these new dependencies, “io.testproject”, “org.slf4j” and “org.seleniumhq.selenium”. It’s also important to use the last version of Appium, there’re some libraries problems if the last version of Appium is not used.
This are all the dependencies used in this project. 4. In the class we create our old driver, in this case, it’s “Setup”, let’s remove Appium import and replace it with “io.testproject.sdk.drivers.android.AndroidDriver.
**Modify the Driver.
5. It’s important to add an environment variable called “TP_DEV_TOKEN” with the obtained token in Step 2, under Environment Variables > New System Variable.
6. Let run the TestProject Agent, by clicking on TestAgent.exe.
7. Now let’s run our test and see the performance improvement!. (Don’t forget to change the type of the new Driver in all classes.
In this basic example, there’s no much improvement on the performance and speed of the test, but for complex Apps and Test, the increseace of speed can go up to 50 %. For further information on how to use TestProject consult: “https://testproject.io“.
Links of interest:
Automating with Appium – Selenium and TestNG
The Agile Team Approach
What Scrum Master Certification to Choose?These are some recommended books to learn more:
Any help is welcome to help us keeping this effort alive! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF
Angélica Viridiana Rebolloza
Computing Engineer specialized in Automation, working with different tools for Mobile and Web, using languages, tools, and platforms like JAVA, VBScript, JavaScript, C#, Appium, Protractor, UFT (QTP), Selenium, WinAppDriver, Jenkins among others.
Viridiana also has been working using practices like TDD & BDD under Cascade and Agile approaches.
Some certifications include: ISTQB Foundations Certification, SeU Selenium Certified, ITIL Foundations Certification.
No Comment
Nowadays Automation has grown so much, that even working in an environment of just ‘Manual Testing‘, it’s really important to ensure and improve the testing process to include a percentage of ‘Automation‘.
It’s important to mention that there’s impossible to cover 100 % of Automated Test Cases because automation has its limits like the abilities and knowledge about coding in a language programming of the Testers, the most used are Java, Python, and JavaScript, which not all actual Testers have.
Another important key is that not all the types of testing are able to automate like look and feel test.
So to keep it simple, if you want to automate a test you have to take the following points at least to start automating:
1. There are Regression Test Cases that you need to run always before a release.
2. There are flows that are just too large but also repetitive.
3. The scope of the Company is implement Continuous Integration (CI).
There are a lot of automation tools for different platforms like Android, IOS, and Web, but also for different scopes like Selenium, Mocha, Jazmine and Espresso.
Let’s start with Mobile (Android & IOS) using Selenium and TestNG with Java.
Create a Maven Project in Eclipse
For the next example, we’ll be using Eclipse as IDE and Maven of libraries management.
1. Create a Maven Project, it’ll look something like this.
2. In Folder “src/main/java“, create the packages “example.enviroment“, “example.pages” “example.test.base” and “example.pages.base“. This packages will contain our code.
3. Now let’s create the class “Setup” for the package “example.environment“, the class “BasePage” for the package “example.pages.base” and the class “BaseTest” for the package “example.test.base”.
4. It’s necessary to add de dependencies to the “pom.xml” file.
5. In Setup class we create de AppiumDriver that will interact with the device and our test.
To Appium to been able to connect your device is necessary to define the next capabilities: - udid = The ID of the device.
- device_Name = Generic name of the device usually just “My Phone”.
- appPackage = Is the name of the application’s package.
- appActivity = Is the name of the main activity (First Page) that the app loads when the app it’s launch.
- noReset = It’s an extra capability to avoid the information of the app got wiped out each time we run a test.
6. Let’s use ADB to obtain the previous capabilities.
By executing “adb devices” we obtain the UDID of the devices and emulator connected to our computer, in this case, is just one device “7MLNW18B29001109”.
To be able to see the device we must enable de “Developer Mode” and the “USB DEBUGGER”.
For the “appPackage” and “appActivity“, let’s type “adb shell” and then “dumpsys window windows | grep -E ‘mCurrentFocus‘”. It’s important to mention that the app to automate needs to be open on the device when we type the last command.
“com.huawei.android.FMRadio“: is the “appPackage” of the app.
“com.huawei.android.FMRadio.FMRadioMainActivity“: is the “appActivity” of the app.Create our First Test using TestNg
1. In class “BaseTest” we are going to call our driver (Setup class) each time a test is executed that’s why it is going to be called in BaseTest is going to be base for all the tests. With the tag @BeforeMethod, we assure that the Setup class and its method are always called before our tests. Also with the tag @AfterMethod we are going to set the close of the objects open, each time a test finishes. The tag @Parameters is going to help us to send the values from the xml file of TestNG.
2. Now let’s run Appium to inspect the elements of our app.
The host is our computer it can be assigned as 0.0.0.0 or 127.0.0.1 is the local host.
The port can be changed if it’s occupied or we want to run tests in parallel (I recommend separate the ports at least 10 units to avoid conflicts).
Now we have Appium Service running, we can use this console to debbug or use the Eclipse console. 3. Let’s click “Start inspection Session“.
4. Insert the next capabilities, click the button “Start Session“, and then we’ll see the app main activity, in this example the “Radio app“.
5. This main activity it’s going to be the “Principal Page“.
We are going to use “Page object Model” (POM) and “Page Factory” for the implementation of the test.
POM is a framework to organize the elements of an application in a way that it’s easier to understand and to maintain via “Pages”, in each page (Class) it’s defined the elements of only that page, in this example, we are only going to have two pages, the “Principal Page” and the “Radio Channels Page“.6. Let’s inspect and get the locators of the elements of “Principal Page“.
The most common locators are “ID” and “XPath“.
The ID locator is a unique locator that avoids having issues like duplicate elements if it is available de ID locator is much better to use it always.
The XPath locator depends on the DOM of the app source, so it’s not recommended to use it because it can change and also affects the performance because it has to go through all the DOM to find an element.
There are other locators like “name“, “class” and “text“, this locator it’s better to use them as a complement of each other because it’s possible that two or more elements have the same name, class, and text.
In this example:
The previous buttons ID is: “com.huawei.android.FMRadio:id/iv_prev“.
The next button ID is: “
com.huawei.android.FMRadio:id/iv_next“.
The Power button ID is: “com.huawei.android.FMRadio:id/btnPower”. 
The stations button menu ID is: “com.huawei.android.FMRadio:id/action_stations“. 7. Now let’s create our methods in the class “PrincipalPage“, create a package called “example.pages.java” and the class “PrincipalPage“.
The first part of the PrincipalPage consists of the following: - This class extends BasePage that will have the methods used by all the pages.
- In the Class’s Constructor it’s defined the “driver” that we create in Setup.
- PageFactory.initElements: Initialize the elements of the page, this is the main function of Page Factory, at the moment it’s instantiated the class PrincipalPage all the elements of the page are initialized.
- The structure to create these page elements are by the tag @FindBy and the type of locator to use like id, XPath, class, name etcetera; and the value of the locator.
Finally, it only needs the name of the element in our case a WebElement.
The last part is the definition of the methods aka actions of the elements.
In these examples the actions of each element are just clicks, this “Click” method/action is defined by Selenium as other many actions like sendKeys, clear, getText, getLocation, and many others.
The failedMethod and staticWait are not declared on this page because it comes from BasePage.8. Let’s define the actions in BasePage.
In this class is defined the methods “failedMethod” that prints the exceptions encountered on each method of the pages, and the method “staticWait” it converts from miliseconds to seconds, is a static wait to see the execution of the test, without it it’s not possible to see the actions. 9. Let’s create the last package where our Test Suites will be called as package “example.test.java” and class “FirstTest“.
10. The main test script resides in FirstTest.
This is the script of the test, where are just called the methods to make the actions. 11. Finally, let’s create the “PossitiveTests.xml” that TestNG will use to execute the tests and also is where the input parameters are defined.
The parameters are the input data of the test in Setup.
The class name is composed: package_name.class_name.
The methods include name is composed : method_name_of_FirstTest_class12. Lets just run it!
Right click on “PossitiveTests.xml“, select “Run As” and then “TestNG Suite”.
If there’s a problem finding this option be sure to have installed TestNG on the IDE, for more information about the installation of TestNG refers to https://testng.org/doc/download.html.
These are the result displayed in TestNG.
Links of interest:
Speed up Android Testing with TestProject Agent
Upload a File With HTML5
The Agile Team Approach
What Scrum Master Certification to Choose?These are some recommended books to learn more:
Any help is welcome to help us keeping this effort alive! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF
Angélica Viridiana Rebolloza
Computing Engineer specialized in Automation, working with different tools for Mobile and Web, using languages, tools, and platforms like JAVA, VBScript, JavaScript, C#, Appium, Protractor, UFT (QTP), Selenium, WinAppDriver, Jenkins among others.
Viridiana also has been working using practices like TDD & BDD under Cascade and Agile approaches.
Some certifications include: ISTQB Foundations Certification, SeU Selenium Certified, ITIL Foundations Certification.
2 Comments
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured / Scrum
Size matters?
This is a very old question, but in this blog, we only will answer that question from the project management point of view (disappointed people please go to another kind of blogs). This time we will see what are and what is the purpose of the famous User Stories and how they differ from traditional requirements in a project.
When I was a kid I spent a lot of time playing on the beach with my cousins, and in some of those games, I found myself digging, transporting and piling sand from one point to another (my tools were a shovel and a plastic bucket) after about 10 minutes my youngest cousin asked me how long it had taken me to gather all that sand, to which I replied: “about 30 laps”. After that, both my cousin and I assumed that with his own bucket he could double the amount of sand, doubled in another 30 laps. It wasn’t like that, it took a lot longer for my little cousin because we both failed to evaluate the capacity of his bucket and appreciating that Gabriel (my cousin) being very young (maybe 6 years old) he still had to strain to load a bucket of different size completely filled and finish in only 30 laps.
As simple and obvious as this anecdote may seem, the reality is surprising, since many work teams responsible for projects of all sizes continue to fall into this same error. They are not yet fully aware of their capacity or speed, nor are they clear about the difference between size and distance in a project, and therefore, they fail from the beginning in their estimates.
Not taking care of trying to measure the size of what you are going to do is an error, therefore the size does matter, and before measuring times and distances you should know the answer to questions like, what is the size of your bucket and shovel? How many buckets and shovels do you have? Are there enough people for each shovel and bucket?
What are the User Stories?
For ease, the concept is often oversimplified, saying that User Stories are the requirements of a system or a product, but they have serious differences with other common approaches such as use cases, IEEE 830 software requirements specifications, and design and interaction scenarios.
User stories are short, simple descriptions of a feature told from the perspective of the person who wants the new functionality, usually a user or customer of the product that they want to create. In general, they follow a simple template:
As <user type>, I want <some goal> so that <some reason>.
User stories are often written on chips or sticky notes, stored in a box and organized on walls, boards or tables to facilitate planning and discussion. As such, they strongly change the approach of writing about characteristics, to discussing them. In fact, these discussions are more important than any text that is written.
This is a simple definition about what a User Story is, but believe me, there is much more behind, writing good User Stories can be a challenge, and to create good stories you have to understand more about their purpose.
Assign Value (points) to User Stories
Eventually, when I became involved in project management and later Agile, I discovered that one way to estimate the size of what is needed is to use the User Stories. To explain what they are I will continue using the analogies.
When was the last time you went to a restaurant and ordered a soup or a drink in milliliters? … That’s right, we usually don’t do that, we usually order a soup or a drink with a relative measure like “small, medium or large”. User stories are also relative, they are used to express size, they don’t have a standardized value, but the values must be relative to each other, that is, a User Story that has value 2 is twice the size of one User Story that it’s worth 1.
To assign values or points to different sizes there are those who use shirt sizes, dog breeds, Fibonacci values (my favorite values) or other representations, no matter what you prefer, you should eventually use relative values. Take the following table as an example, with a possible assignment of points:
Tamaño Camisa Puntos XS 1 S 2 M 3 L 5 XL 8 XLL 12 In an Agile project, it is not uncommon to start an iteration with requirements that are NOT fully specified, the details will be discovered later during the iteration. However, we must associate an estimate with each story that we can see at the moment, even those that are not completely defined.
And where are the details?
Those used to the detail added in advance into traditional requirements will immediately come up with this question. The detail can be added to User Stories in two ways:
- Dividing a User Story into multiple User Stories and smaller ones.
- Adding “conditions of satisfaction”.
When a relatively large story is divided into Agile and multiple User Stories, it’s normal to assume that details have been added. After all, more has been written.
Conditions of Satisfaction are simply high-level acceptance tests that must be met after the User Story is completed. Consider the following as another example of an Agile User Story:
As a marketing director, I want to select a period of time so that I can review the past performance of advertising campaigns in that period.
The detail could be added to this User Story example by adding the following satisfaction conditions:
- Make sure it works with the data of the main retailers: Oxxo, Seven Eleven, Extra.
- It must support the data for the last three years.
- The periods are chosen in intervals of months (not days, nor weeks).
Who writes User Stories?
Anyone can write User Stories. However, it is the responsibility of the product owner to ensure that there is an accumulated backlog of Agile User Story products, but that does not necessarily mean that the owner of the product is the one who writes them. In the course of a good Agile project, you must have examples of User Story written by each member of the team.
Also, keep in mind that who writes a User Story is much less important than who is involved in the discussions of it.
When are User Stories written?
The User Stories are written throughout an Agile project. Overall, a story writing workshop is held near the start of the Agile project, each release and/or at the beginning of each iteration (I personally take some of the first options, depending on the length of the project, and I only do refinement in each iteration). Everyone on the team participates with the goal of creating an “order list” or Product Backlog that fully describes the functionality that will be added during the course of the project, or in a release cycle of three to six months.
Some of these Agile User Stories will undoubtedly be Epics (are not called Epics because they are dramatic…well sometimes 😄). Epics are very large stories that by their size will later decompose into smaller stories that fit more easily into a single iteration. In addition, new stories can be written and added to the “order list” of the product at any time and by anyone.
Velocity
I will not delve too much into this topic because it gives to write another post dedicated entirely to it, but to understand how estimation can work with Story Points that we assign in the table we showed above, it’s necessary to introduce a new concept: Velocity. Velocity is a measure of a team’s progress rate. It’s calculated by adding the number of Story Points assigned to each User Story that the team completed during the iteration.
If the team completes three stories, each estimated at five story points, its velocity is fifteen. If the team completes two stories of five points, its velocity is ten.
If a team completed ten points of work the last iteration, our best calculation is that this iteration will complete ten points. Because the story points are estimates of relative size, this will be true whether they work on two five-point stories or five two-point stories.
As can you see, in order to make estimations, and after knowing the sizes It’s very important to calculate an estimate for the end of the project, or for a release (the distance).
Do User Stories replace a requirements document?
Agile projects, especially Scrum projects, use a product backlog, which is a prioritized list of functionalities that will be developed in a product or service. Although product backlog items may be what the team wants, User Stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be considered as a replacement for the requirements document of a traditional project and perhaps even a WBS, it’s important to remember that the written part of an Agile User Story (“As a user, I want …” ) is incomplete until the discussions about that story take place.
It’s often better to think of the written part as an indicator of the actual requirement. User Stories can point to a diagram that represents a workflow, a spreadsheet that shows how to perform a calculation or any other artifact that the Product Owner or team wants.
Until here I leave the User Stories topic, for now, let me know if you want to know more 😉.
Links of interest:
Without users (User Proxies)
The Agile Team Approach
What Scrum Master Certification to Choose?These are some recommended books to learn more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured / ScrumMuch has been said about the Scrum team size or Agile team size, almost every client, boss, and collaborator with whom I have worked asks this question at some point: how many people do we include in the teams? The Scrum Guide sheds very little light on this, suggesting 10 or fewer members per team in its latest update, but giving us no context or reasons for these numbers.
The Scrum Team Size is More Than a Number
The truth is that there is no universally correct number of members to ensure optimal performance in a team, but what we know is that a Scrum team must consider certain factors that should include, beyond numbers:
- Cross-Functional team. Sufficient skills and capabilities to build the product,
- Dedicated team members. Dedicated members to one, and only one, team,
- Consistent membership. Stable and long-term membership within the team[1],
- Diversity of thought. A reasonable wide range of attitudes, beliefs, genders, and thinking patterns[2].
Now, the above points already represent a challenge for some organizations, but at least they enjoy an important consensus, however, they are not the only ones. Once the team is formed, there are other important factors that high-performance teams must address, among others:
- Psychological safety. A safe environment to share ideas and take risks[3].
- Equal communication. The most expressive member should not communicate more than twice as much information as the quietest[4].
- An open mind and willingness to learn[5].
- Shared vision. Everyone knows and agrees on objectives[6].
- Clear roles. Everyone knows their responsibilities and the expectations of their work[7].
- External advice (coaching). In Scrum, this is done by the Scrum Master[8].
And what does all this have to do with the size of the teams? Well, these factors don’t live isolated in a vacuum and just because I say so, so let’s explore the evidence so that together we discover what matters most to your team. After all, there is no universal answer 🙂
Many Numbers Everywhere
When we talk about the size of the teams within various organizations, the topic seems much more controversial and narrow to say the least. In the worst cases, staffing leaders respond by building teams guided by assumptions and even based on the burden caused by unrealistic dates and budgets and inadequate time horizons, thus harming the performance of teams and the organization itself in the medium and long term.
In the early days of Agile, the XP and Scrum texts suggested that the optimal size of members was 7 ± 2, applying George A. Miller’s number, later it was adjusted to 6 ± 3, today the suggested number is 10 or less according to the Scrum Guide.
The original support for the position of seven people, plus or minus two (7±2), comes from a well-known psychology study by research psychologist George A. Miller published in the 1950s, where according to the results of this study, there are limits on the amount of information we can process and retain in our heads.
More recently in 2010, Nelson Cowan claimed that Miller was too ambitious and that the ideal limit was only four and not seven[9].
Also, Ikujiro Nonaka and Hirotaka Takeuchi were formulating the ideal team size after conducting research and creating new products at technology companies such as Fuji-Xerox, Canon, Honda, Epson, Brother, 3M, and Hewlett-Packard[10].
Many others cite historical examples dating back to the Roman army, which used small military units of around 8 people. Others watch bonobos, one of the closest genetic relatives to humans, often splitting into groups of 6-7 to forage for a day. Both conveniently support the number 7±2, but since neither example is about teams doing knowledge work, the relevance of this to agility is limited.
As you can see, the topic has been discussed for some time and can be somewhat confusing, but thanks to this we have some clues, but it is worth having more sources to help us support our decision.
What Happens to Relationships When Teams Grow?
Within a team, each individual will have a connection with another individual, thereby creating a unique relationship; the bigger the team, the more the relationships. The equation that describes this is N(N-1)/2; but what does this mean? and how can it help us? To find out, let’s remember math problems from school and turn it into something we can use in real life.
The above equation tells us how many different relationships will exist within a team of a certain size, where N = the number of people in the team. So, in the first example graph of a team of 5 people, where N=5 we have 10 relationships: 10 different combinations of team members who are related to other members of the same team.
In the second example, where N=7, you have 21 relationships, and where N=9 in the third graph you have 36 relationships. Each pair of people represents a relationship, and that relationship defines how they collaborate. High-performance teams, by their nature, must have strong relationships between each of the team members in order to collaborate effectively.
Knowing this is important for you and your team because it’s true that each new person adds some individual productivity to the team, but it also increases communication overhead in the form of an exponentially growing number of relationships. To grow a team from 5 to 7 people, you need to more than double the number of relationships. To go from 7 to 9, it doesn’t quite double, but the jump is still big.
How expensive is it to maintain these relationships? Anecdotally, after studying the interactions of the members of several of my teams, I can say that in teams of 7 or 8 people, each day more than 90 minutes per person are spent interacting with other team members[11]. This excludes time spent on techniques like pair programming. Part of the interaction is talking about work, but she also spends time socializing. This is good and important because it is the combination of work and socializing that builds resilience and the ability of a team to handle challenges effectively.
A general rule of thumb suggests that people typically have 3½ to 5 hours of productive time at work each day. As a team grows, we lose productivity or, more often, begin to withdraw socially rather than sacrifice productive time to interact with our peers because communication costs for each team member are becoming too high. We need strong relationships to become a high-performing team, but as the size of the group grows, we begin to avoid the interactions that build those relationships.
Therefore, the number of relationships between team members and the time investment they require should be a factor when choosing team size because it will influence productivity.
More People Make Lighter Work…But Only to a Point
What everyone wants to believe is if we go from 1 person to 2 people, or from 2 people to 4 people, we will get double the work done, even top managers of transnational organizations have raised this with me. But even so, we intuitively know that this is not true, but why?
In 1967, Amdahl’s Law was presented for the first time, which for those who are not systems or electronics engineers, tries to estimate how much speed gain can be obtained by executing computational tasks by running them in parallel parts. This means that sometimes there are computer programs that are viable to be worked on by multiple processors at the same time (e.g. parallel processing), but other parts must be taken care of one by one (e.g. serial programming).
The formula derived from Amdahl’s Law may seem intimidating, but it is much simpler than it seems:
If we take the 5 units of work and apply 3 processors to the parts that can be done concurrently (in parallel), it doesn’t take 1 and 2/3 units of time (5 divided by 3) to complete. Instead, 3 units are needed because 2 of the units of work can only be done by one (serial) processor. It’s certainly an improvement over time, but not as much as you’d expect at first glance.
Teamwork works in much the same way. In fact, if we convert everything to a graph we can get an idea of how efficient the increase in team members can be:
Let’s focus for now on the 80% line (the blue one, at the top) of the graph. Let’s be optimistic (and unrealistic) and assume that 80% of the work can be done by working in parallel. This suggests that the more people do it, the faster it will be over, right? Oh but wait. If we go from 1 person to 2 people, we don’t do twice as much work. To get an improvement of 2x the work completed, we actually need 3 people. 7 people only create a 3.2x improvement over 1 person. To do 4 times as much work as 1 person does, we would need 16 people!
What if even less work can be done at the same time (parallel)? What if 50% of the work needs to be done serially (green line on the graph)? Then with 9 people we still have only 1.8x speedup.
What is the solution? There is no easy solution, but there are things you can do to mitigate the effect of Amdahl’s Law:
- Make as much of the work as possible can be done in parallel. This may mean increasing cross skills and collaboration.
- Reduce dependencies between teams, so there are no bottlenecks or delays.
- Increase the speed of the overall work process by improving quality and practices.
Speed doesn’t come from sending more people to work and building bigger teams. It’s about building a high-performing team that is optimally sized for effectiveness, communication, and quality.
Research-Backed Evidence
American Sociological Association
The American Sociological Association published a study by Hackman JR, Vidmar NJ called “Effects of size and task type on group performance and member reactions”[12].
In this study, they had participants complete a series of tasks: a combination of production (writing), discussion, and problem-solving. Participants were placed into different groups of 2 to 7. After completing each task, the volunteers were asked a series of questions, including two shown in this graphic: “was your group too small?” your group was too big? As you can see from the graph, groups around 4-5 in size seemed to have the least negative reaction. The frequently touched number is 4.6. The participants were college students, the tasks were cognitively loaded but not related to technology, development, etc., and the groups were not together long enough for a true “sense of team” to form. Nevertheless, it is an interesting fact.
In those days Hackman wrote the book Leading Teams, his rule of thumb for team size was 6[13].
Social and Developmental Psychology Researcher Jennifer S. Mueller
Research psychologist Jennifer S. Mueller, academic, author, and research collaborator, was quoted in the article “Is Your Team Too Big? Too small? What is the correct number?:”
If companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is optimal?’ that correlates to a team of six. “Above and beyond five, and you begin to see diminishing motivation,” says Mueller. “After the fifth person, you look for cliques. And the number of people who speak at any one time? That’s harder to manage in a group of five or more.”
From the Scrum Creators…nothing less
Based on studies by George A. Miller, and later work, Scrum creators Jeff Sutherland and Ken Schwaber showed the following levels of productivity creating their own research on team size:
Agile Team Productivity NO Agile Team Productivity < 7 members 300 / 400% < 7 members 100% max > 7 members 400% > 7 members < 90% And they added:
A small team from three to four people can be very autonomous when it follows guidelines, has a well-defined focus, and everyone is physically in the same space. His work is often consistent, responsible, aligned and well directed, and communication is fluid. Things are relatively easy when there are only a few people on the team. The problems seem to increase along with the number of team members.
Brook’s Law and Lawrence Putnam
The mythical Frederick Brooks to whom we owe the famous “Brooks’ Law” establishes that “adding manpower to a late software project makes it even later”. This is due to the learning curve, that is, you must train each person new to the product or technology, and you must learn all the related non-technical knowledge, including the business strategies that the product or software addresses [14].
According to important studies by renowned researchers such as Lawrence Putnam:
Miembros Esfuerzo < 9 miembros 25% menos esfuerzo > 9 miembros 25% más esfuerzo With an Agile Team:
Miembros Productividad 1 25% más 5 125% más 9 225% más In summary, if we have an optimal team, we can have productivity from 300 to 400%.
Putnam and Myers Hard Facts
Beyond our personal opinions, those of clients, bosses, and team members, we also have objective statistics. Putnam and Myers examined data from 491 software projects from a large corporation as reported in their article “Familiar Metric Management: Small is Beautiful Once Again“. These were projects with 35,000 – 90,000 lines of source code. They divided the projects into groups called buckets based on the number of people involved in the project: 1.5-3, 3-5, 5-7, 9-11, and 15-20. On average, the smaller groups (3-5, 5-7) took much less time (11.9 and 11.6 months, respectively) than the larger groups (17.1 and 16.29 months) to complete projects of similar size.
When you multiply the number of team members by the number of months, you get a graph that is even more impressive:
A team of 9 to 11 people took 2.5 to 3.5 times as long as teams of 5 to 7 and 3 to 5 to complete projects of a similar size. That suggests that the seven-plus teams in this dataset were just a way to spend money faster due to increased team size but reduced net return.
Evidence of Agile projects
Larry Maccherone, in his work through Rally, Tasktop and AgileCraft exposed in “Impact of Agile Quantified” in late 2014, has helped build large datasets on Agile team practices. His data shows:
Based on Larry’s data, it would appear that 1-3 teams are more productive but have lower quality. 3-5 teams are marginally more productive than 5-9 teams, although they may still be of slightly lower quality – the difference is small. Larry’s notes suggest that he thinks the entire range of 3 to 9 is fine [16]. The reason for the lower quality in the smaller teams is not obvious. Perhaps due to a lack of stability? Lack of diversity of thought and experience? Reduced cross-functionality? We cannot know, but it deserves consideration.
My experience
When clients, managers, etc. ask me how big Scrum teams should be, I don’t have a “correct” answer. But I try to share the above data, my personal opinions, and suggestions based on years of experience. And I won’t lie to you, there are organizations where bad habits are so ingrained that it’s hard to get that information across in a practical way (they don’t listen to it, they don’t take it into account enough, etc.). But I certainly try to make my suggestions based on evidence, simple logic, and common sense.
For example, larger teams spend more time building, more time normalizing, and therefore more time reaching high performance. Why? Because there are more relationships to negotiate. As we saw before, in a team of 5, there are 10 relationships that need to be formed, a team of 7 has 21 relationships, and so on. More relationships take more time to build and establish trust, so that should be taken into account when deciding on team size.
Assuming all else is equal (skills needed to get the job done, diversity of thought, etc.), the existing evidence supports the idea that teams of 4 to 6 work well in most situations. They take less time to train and are just as productive as larger teams. Also, teams of 5-7 can usually combine abilities enough to cover the loss of a team member.
Personally, I would only pick a team of 8 if other pressures, like the breadth of skills required, forced it to happen. I don’t recommend teams with more members, because the overhead costs outweigh the value of the additional person.
With teams of 10 or more, I recommend splitting into 2 teams. My own experience and that of other agile colleagues with scaling experience: Separate teams of 4 and 5 do more than their original large team.
With teams of 9 or more, I recommend splitting into 2 teams. My own experience mirrors that of other agilists using Scrum: separate teams of 4 and 5 do more than their original big team.
Why not 3 or less? Because it would result in very little diversity of thought and it would probably be very difficult to find 3 people with enough skills to get the job done on a complex project. There will also be very little collaboration, which correlates with the reduction in quality shown in Figure #2 (“Impact of Agile Quantified” data). And don’t forget the obvious 2v1 power issues that can make the journey more challenging for one team member.
All the focus has been on the number of people on the team, but the bigger question should be this: does the team have the ability to get to “Done” or “Done” at the end of each Sprint? If not, you’ll want to re-examine and reconfigure to achieve a more effective team size and most likely do a re-analysis to break down work into requirements, user stories, or the like.
[1] “The Impact of Lean and Agile Quantified” – Larry Maccherone showed that dedicated team members doubled productivity and stable teams (no turnover) improved productivity by 60%. https://www.infoq.com/presentations/agile-quantify
[2] Wilkinson, David. Group decision-making. What he said in The Oxford Review, Diciembre 2019
[3] “What Google Learned From Its Quest to Build the Perfect Team”: https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html
[4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland https://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr and also “Evidence for a Collective Intelligence Factor in the Performance of Human Groups“
[5] The Wisdom of Teams: Creating the High-Performance Organization – Jon Katzenbach and Douglas Smith – indicates that potential skills are as important as the skills people currently have in predicting effectiveness.
[6] [7] [8] Wilkinson, David. Group decision-making. What he said in The Oxford Review, Diciembre 2019
[9] “The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?” – Nelson Cowan – https://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory
[10] Knowledge management https://en.wikipedia.org/wiki/Knowledge_management
[11] These are informal observations that anyone can get, but one of the most well-known investigations was done by the English magazine Nature Human Behavior in 2017.
[12] Stable reference: https://www.jstor.org/stable/2786271
[13] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam and Ware Myers https://hbswk.hbs.edu/archive/2996.html
[14] The Mythical Man-Month: Essays on Software Engineering – Frederick Brooks https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Related links:
Agile’s Origins and Values
The Agile Team Approach
What Scrum Master Certification to Choose?
Too Big to Scale – Optimal Scrum Team Size GuideSome books to know more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured / ScrumMucho se ha hablado sobre el tamaño del equipo Scrum, Agile y casi cada cliente, jefe y colaborador con los que he trabajado hacen esta pregunta en algún momento ¿cuántas personas incluimos en los equipos?. La Guía Scrum ofrece muy poco luz al respecto, sugiriendo 10 o menos miembros por equipo en su última actualización, pero sin darnos contexto o razones para estos números.
El Tamaño del Equipo Scrum no es Sólo un Número
La verdad es que no existe un número universalmente correcto para asegurar un óptimo rendimiento en un equipo, pero sí sabemos que un equipo Scrum debe considerar ciertos factores que debería incluir, más allá de lo números:
- Equipo multifuncional. Habilidades y capacidades suficientes para construir el producto,
- Miembros dedicados al equipo. Miembros dedicados a uno, y sólo un, equipo,
- Miembros estables. Membresía consistente y de largo plazo dentro del equipo[1],
- Diversidad de pensamiento. Un suficientemente amplio rango de actitudes, creencias, generos y patrones de pensamiento[2].
Ahora bien, los puntos anteriores ya por sí mismos representan reto para algunas organizaciones, pero al menos gozan de un consenso importante, sin embargo, no son las únicos. Una vez que el equipo está formado, hay otros factores importantes que deben atacar los equipos de alto rendimiento, entre otros se pueden mencionar:
- Seguridad psicológica. Ambiente seguro para compartir ideas y tomar riesgos[3].
- Comunicación igualitaria. El miembro más expresivo no debería comunicar más del doble de información que el más callado[4].
- Mente abierta y disponibilidad para aprender[5].
- Visión compartida. Todos conocen y acuerdan objetivos[6].
- Roles claros. Todos conocen sus responsabilidades y las espectativas de su labor[7].
- Asesoramiento externo (coaching). En Scrum esto lo lleva a cabo el Scrum Master[8].
¿Y todo esto que tiene que ver con el tamaño de los equipos? Bueno, estos factores no viven aislados en el vacío y sólo porque yo lo digo, así que exploremos la evidencia para que juntos descubramos que es lo más importante para su equipo. Después de todo, no hay una respuesta universal 🙂
Muchos Números por Todos Lados
Cuando hablamos del tamaño de los equipos a los adentros de varias organizaciones, el tema parece mucho más controversial y poco acotado por decir lo menos. En el peor de los casos, los líderez encargados de asignación de personal responden armando equipos guiados por supuestos e incluso en función del agobio causado por fechas y presupuestos poco realistas y de horizontes inadecuados, perjudicando así al rendimiento de equipos y la misma organización a mediano y largo plazo.
En lo días tempranos del agilismo, los textos XP y Scrum sugerían que el tamaño óptimo de miembros era 7±2, aplicando el número de George A. Miller, posteriormente se ajustó a 6±3, hoy en dia el número sugeridos es 10 o menos de acuerdo con la Guía Scrum.
El sustento original para la postura de siete personas, más o menos dos (7±2), proviene de una investigación de psicología muy nombrada del psicólogo investigador George A. Miller publicada en los años 50s, donde según los resultados de este estudio, hay límites en la cantidad de información que podemos procesar y retener en nuestras cabezas.
Más recientemente en 2010, Nelson Cowan afirmó que Miller era demasiado ambicioso y que el límite ideal era solo de cuatro y no de de siete[9].
También, Ikujiro Nonaka y Hirotaka Takeuchi estaban formulando el tamaño ideal del equipo después de realizar investigaciones y crear nuevos productos en compañías de tecnología como Fuji-Xerox, Canon, Honda, Epson, Brother, 3M y Hewlett-Packard[10] .
Muchos otros citan ejemplos históricos que se remontan al ejército romano, que utilizaba pequeñas unidades militares de alrededor de 8 personas. Otros observan a los bonobos, uno de los parientes genéticos más cercanos a los humanos, a menudo divididos en grupos de 6 a 7 para buscar alimento durante un día. Ambos admiten convenientemente el número 7±2, pero dado que ninguno de los ejemplos se trata de equipos que realizan trabajo de conocimiento, la relevancia de esto para el agilismo es limitada.
Como puede ver el tema ya tiene tiempo discutiéndose y puede ser algo confuso, pero gracias a ello tenemos algunas pistas, pero vale la pena tener más fuentes que nos ayuden a sustentar nuestra desición.
¿Qué Pasa a las Relaciones Cuando los Equipos Crecen?
A los adentros de un equipo, cada individuo tendrá conexión con otro individuo creando con ello un relación única; entre más grande el equipo, más relaciones. La ecuación que describe esto es N(N-1)/2; pero ¿qué significa esto? y ¿cómo puede ayudarnos? para averiguarlo recordemos problemas de matémáticas de escuela y convirtámoslo en algo que podamos usar en la vida real.
La ecuación anterior nos dice cuántas relaciones diferentes existirán dentro de un equipo de cierto tamaño, siendo N = el número de personas en el equipo. Entonces, en el primer gráfico ejemplo de un equipo de 5 personas, donde N=5 tenemos 10 relaciones: 10 combinaciones diferentes de miembros del equipo que se relacionan con otros miembros del mismo equipo.
En el segundo ejemplo, donde N=7, tiene 21 relaciones y en donde N=9 en el tercer gráfico tienen 36 relaciones. Cada par de personas representa una relación, y esa relación define la forma en que colaboran. Los equipos de alto rendimiento, por su naturaleza, deben tener relaciones sólidas entre cada uno de los miembros del equipo para colaborar de manera efectiva.
Saber esto es importantes para usted y su equipo, porque es cierto que cada nueva persona agrega algo de productividad individual al equipo, pero también aumenta los gastos generales de comunicación en forma de un número de relaciones que crece exponencialmente. Para aumentar un equipo de 5 a 7 personas, hay que duplicar con creces el número de relaciones. Para pasar de 7 a 9, no se duplica del todo, pero el salto sigue siendo grande.
¿Qué tan costoso es mantener estas relaciones? Como anécdota, después de haber estudiado las interacciones de los miembros de varios de mis equipos, puedo decir que en equipos de 7 u 8 personas, cada día se dedican más de 90 minutos por persona a interactuar con otros miembros del equipo[11]. Esto excluye el tiempo dedicado a técnicas como pair programming. Parte de la interacción es hablar sobre el trabajo, pero también se dedica a socializar. Esto es bueno e importante porque es la combinación de trabajo y socialización lo que desarrolla la resiliencia y la capacidad de un equipo para manejar los desafíos de manera efectiva.
Una regla general sugiere que las personas suelen tener de 3½ a 5 horas de tiempo productivo en el trabajo cada día. A medida que un equipo crece, perdemos productividad o, más a menudo, comenzamos a retraernos socialmente en lugar de sacrificar tiempo productivo para interactuar con nuestros compañeros porque los costos de comunicación para cada miembro del equipo se están volviendo demasiado altos. Necesitamos relaciones sólidas para convertirnos en un equipo de alto rendimiento pero, a medida que crece el tamaño del grupo, comenzamos a evitar las interacciones que construyen esas relaciones.
Por lo tanto, la cantidad de relaciones entre los miembros del equipo y la inversión de tiempo que requieren deben ser un factor considerado al elegir el tamaño del equipo porque influirá en la productividad.
Más Personas Hacen el Trabajo Más Ligero… Pero Solo Hasta Cierto Punto
Lo que todos quieren creer es que si vamos de 1 persona a 2 personas, o de 2 personas a 4 personas, obtendremos el doble de trabajo realizado, incluso altos directivos de organizaciones transnacionales me lo han planteado. Pero incluso así, intuitivamente sabemos que esto no es verdad, pero ¿por qué?
En 1967 se presentó por primera vez la Ley de Amdahl, que para los que no sean ingenieros en sistemas o electrónica, trata de estimar cuanta ganancia de velocidad se puede obtener ejecutando tareas de computo corriédolas en partes de manera paralela. Esto significa que a veces hay programas de cómputo que son viables de trabajarse por múltiples procesadores al mismo tiempo (ej. procesamiento paralelo), pero otras partes deben ser atendidas una por una (ej. programación serial).
La fórmula que se deriva de la Ley de Amdahl pude parecer intimidante, pero es mucho más simple de lo que parece:
Esta imagen plantea trabajo realizado por un procesador el cual le toma 5 unidades de tiempo para completar.
Si tomamos las 5 unidades de trabajo y aplicamos 3 procesadores a las partes que se pueden hacer concurrentemente (en paralelo), no se necesitan 1 y 2/3 unidades de tiempo (5 dividido por 3) para completarse. En cambio, se necesitan 3 unidades porque 2 de las unidades de trabajo solo pueden ser realizadas por un procesador (serie). Ciertamente es una mejora en el tiempo, pero no tanto como cabría esperar al primer vistazo.
El trabajo en equipos funciona de manera muy similar. De hecho, si con convertimos todo a un gráfico podemos darnos idea de que tan eficiente puede ser el incremento en miembros de un equipo:
Enfoquémonos por ahora en la línea del 80% (la azul, en la parte superior) del gráfico. Seamos optimistas (y poco realistas) y supongamos que el 80% del trabajo se puede hacer trabajando en paralelo. Esto sugiere que cuanta más gente lo haga, más rápido se terminará, ¿cierto? Ah, pero espera. Si pasamos de 1 persona a 2 personas, no hacemos el doble de trabajo. Para obtener una mejora de 2 veces el trabajo completado, en realidad necesitamos 3 personas. 7 personas sólo crean una mejora de 3.2 veces sobre 1 persona. Para hacer 4 veces más trabajo del que hace 1 persona, ¡necesitaríamos 16 personas!
¿Qué sucede si se puede hacer incluso menos trabajo al mismo tiempo (paralelo)? ¿Qué pasa si el 50% del trabajo debe hacerse en serie (línea verde en el gráfico)? Luego, con 9 personas, todavía tenemos solo una aceleración de 1.8 veces.
¿Cual es la solución? No hay una solución fácil, pero hay cosas que puede hacer para mitigar el efecto de la Ley de Amdahl:
- Haga que la mayor parte del trabajo posible se pueda hacer en paralelo. Esto puede significar aumentar las habilidades cruzadas y la colaboración.
- Reduzca las dependencias entre equipos, para que no haya cuellos de botella ni retrasos.
- Aumente la velocidad del proceso de trabajo en general mejorando la calidad y las prácticas.
La velocidad no proviene de enviar a más personas al trabajo y formar equipos más grandes. Se trata de construir un equipo de alto rendimiento que tenga un tamaño óptimo para la eficacia, la comunicación y la calidad.
Evidencia respaldada por investigaciones
American Sociological Association
La American Sociological Association publicó un estudio de Hackman JR, Vidmar NJ llamado “Effects of size and task type on group performance and member reactions.” algó así como “Efectos del tamaño y el tipo de tarea en el desempeño del grupo y las reacciones de sus miembros“[12].
En este estudio, hicieron que los participantes completaran una serie de tareas: una combinación de producción (escritura), discusión y resolución de problemas. Los participantes se colocaron en diferentes grupos de 2 a 7. Después de completar cada tarea, se les hizo una serie de preguntas a los voluntarios, incluidas dos que se muestran en este gráfico: “¿su grupo era demasiado pequeño?”, “¿su grupo era demasiado grande?”. Como puede ver en el gráfico, los grupos de alrededor de 4-5 de tamaño parecían tener la reacción menos negativa. El número frecuentemente tocado es 4.6. Los participantes eran estudiantes universitarios, las tareas tenían una carga cognitiva pero no estaban relacionadas con tennología, desarrollo, etc., y los grupos no estuvieron juntos el tiempo suficiente para que se formara un verdadero “sentido de equipo”. No obstante, es un dato interesante.
Por aquellos días Hackman escribió el libro Leading Teams, su regla general para el tamaño del equipo era 6[13].
Social and Developmental Psychology Researcher Jennifer S. Mueller
La Psicóloga-Invetigadora Jennifer S. Mueller académica, autora y colaboradora de varias investigaciones fue citada en el artículo “Is Your Team Too Big? Too Small? What’s the Right Number?:”
Si las empresas están lidiando con tareas de coordinación y problemas de motivación, y usted pregunta: “¿Cuál es el tamaño de su equipo y cuál es el óptimo?”, eso corresponde a un equipo de seis. “Más allá de los cinco, comienzas a ver una disminución de la motivación”, dice Mueller. “Después de la quinta persona, buscas camarillas. ¿Y el número de personas que hablan en un momento dado? Eso es más difícil de manejar en un grupo de cinco o más”.
De Los creadores de Scrum…ni más ni menos
A partir de los estudios de George A. Miller, y trabajos posteriores, lo creadores de Scrum Jeff Sutherland y Ken Schwaber mostraron los siguientes niveles de productividad basados en su propia investigación sobre el tamaño del equipo:
Equipo Agile Productividad Equipo NO Agile Productividad < 7 miembros 300 / 400 % < 7 miembros 100% max > 7 miembros 400 % > 7 miembros < 90% Y agregaron:
Un pequeño equipo de tres a cuatro personas puede ser muy autónomo cuando sigue pautas, tiene un enfoque bien definido, y todos están físicamente en el mismo espacio. Su trabajo es a menudo consistente, responsable, alineado y bien dirigido, y la comunicación es fluida. Las cosas son relativamente fáciles cuando solo hay unas pocas personas en el equipo. Los problemas parecen aumentar junto con el número de miembros del equipo.
Ley de Brooks y Lawrence Putnam
El mítico Frederick Brooks al cual se le debe la famosa “La Ley de Brooks” establece que “agregar mano de obra a un proyecto de software tardío lo hace incluso más tardío”. Esto es debido a la curva de aprendezaje, es decir, debe capacitar a cada persona nueva en el producto o tecnología, y debe aprender todo el conocimiento no técnico relacionado, incluidas las estrategias comerciales que aborda el producto o el software [14].
Según importantes estudios realizados por investigadores de renombre como Lawrence Putnam:
Miembros Esfuerzo < 9 miembros 25% menos esfuerzo > 9 miembros 25% más esfuerzo Con un Equipo Agile:
Miembros Productividad 1 25% más 5 125% más 9 225% más En resumen, si tenemos un equipo óptimo, podemos llegar a tener una productividad del 300 al 400%.
Datos duros de Putman y Mayers
Más allá de nuestras opiniones personales, las de los clientes, jefes, miembros del equipo, también tenemos estadísticas objetivas. Putnam y Myers examinaron datos de 491 proyectos de software en una gran corporación como publicaron en su aritículo “Familiar Metric Management: Small is Beautiful Once Again“. Estos fueron proyectos con 35,000 – 90,000 líneas fuente de código. Dividieron los proyectos en grupos que llamaron buckets según la cantidad de personas involucradas en el proyecto: 1.5-3, 3-5, 5-7, 9-11 y 15-20. En promedio, los grupos más pequeños (3-5, 5-7) tardaron mucho menos tiempo (11.9 y 11.6 meses, respectivamente) que los grupos más grandes (17.1 y 16.29 meses) para completar proyectos de tamaño similar.
Cuando multiplicas el número de miembros del equipo por el número de meses, obtienes un gráfico que es aún más impactante:
Un equipo de 9 a 11 personas tardó entre 2.5 y 3.5 veces más tiempo que los equipos de 5 a 7 y de 3 a 5 para completar proyectos de un tamaño similar. Eso sugiere que los equipos de más de siete en este conjunto de datos eran solo una forma de gastar dinero más rápido debido al aumento del tamaño del equipo pero con rendimiento neto reducido.
Evidencia de proyectos Agile
Larry Maccherone, en su trabajo a través de Rally, Tasktop y AgileCraft expuestos en “Impact of Agile Quantified” a finales del 2014″, ha ayudado a construir grandes conjuntos de datos sobre prácticas en equipos Agile . Sus datos muestran:
Enlarge
Relacion Tamaño-Rendimiento Maccherone Según los datos de Larry, parecería que los equipos de 1-3 son más productivos pero tienen menor calidad. Los equipos de 3-5 son marginalmente más productivos que los de 5-9, aunque aún pueden tener una calidad ligeramente inferior: la diferencia es pequeña. Las notas de Larry sugieren que piensa que todo el rango de 3 a 9 está bien[16]. La razón de la menor calidad en los equipos más pequeños no es evidente. ¿Quizás por falta de estabilidad? ¿Falta de diversidad de pensamiento y experiencia? ¿Funcionalidad cruzada reducida? No podemos saberlo, pero merece consideración.
Mi Experiencia
Cuando los clientes, jefes, etc., me preguntan qué tamaño deberían tener los equipos Scrum, no tengo una respuesta “correcta”. Pero trato de compartir los datos anteriores, mis opiniones personales y sugerencias basadas en años de experiencia. Y no les mentiré, hay organizaciones donde los malos hábitos está tan arraigados que cuesta trabajo permear de manera práctica esa información (no la escuchan, lo toman suficientemente en cuenta, etc.). Pero sin lugar a dudas procuro que mis sugerencia se basen en la evidencia, en la lógica simple y el sentido común.
Por ejemplo, los equipos más grandes pasan más tiempo formándose, más tiempo normalizándose y, por lo tanto, más tiempo para alcanzar un alto rendimiento. ¿Por qué? Porque hay más relaciones que negociar. Como vimos antes, en un equipo de 5, hay 10 relaciones que deben formarse, un equipo de 7 tiene 21 relaciones, y así sucesivamente. Más relaciones toman más tiempo para construir y establecer la confianza, por lo que debe tenerse en cuenta a la hora de decidir el tamaño del equipo.
Suponiendo que todo lo demás sea igual (las habilidades necesarias para realizar el trabajo, la diversidad de pensamiento, etc.), la evidencia existente respalda la idea de que los equipos de 4 a 6 funcionan bien en la mayoría de las situaciones. Toman menos tiempo para formarse y son tan productivos como los equipos más grandes. Además, los equipos de 5-7 normalmente pueden combinar habilidades lo suficiente como para cubrir la pérdida de un miembro del equipo.
Personalmente, solo elegiría un equipo de 8 si otras presiones, como la amplitud de habilidades requerida, lo obligaran a suceder. No recomiendo equipos de más miembros, porque los gastos generales superan el valor de la persona adicional.
Con equipos de 10 o más, recomiendo dividirse en 2 equipos. Mi propia experiencia y la de otros colegas agilistas con experiencia en escalamiento: los equipos separados de 4 y 5 hacen más que su numeroso equipo original.
Con equipos de 9 o más, recomiendo dividirse en 2 equipos. Mi propia experiencia refleja la de otros agilistas utilizando Scrum: los equipos separados de 4 y 5 hacen más que su gran equipo original.
¿Por qué no 3 o menos? Porque daría como resultado muy poca diversidad de pensamiento y probablemente sería muy difícil encontrar 3 personas con suficientes habilidades para hacer el trabajo en un proyecto complejo. También habrá muy poca colaboración, lo que se correlaciona con la reducción en la calidad que muestra la Figura n.º 2 (datos de “Impact of Agile Quantified”). Y no olvide los problemas obvios de energía 2 contra 1 que pueden hacer que el viaje sea más desafiante para un miembro del equipo.
Todo el enfoque se ha centrado en la cantidad de personas en el equipo, pero la pregunta más importante debería ser esta: ¿tiene el equipo la capacidad de llegar a “Done” o “Terminado” al final de cada Sprint? Si no es así, querrá volver a examinar y reconfigurar para lograr un tamaño de equipo más efectivo y hacer muy probablemente un re-análisis al desglose de trabajo en requerimientos, historias de usario o similares.
[1] “The Impact of Lean and Agile Quantified” – Larry Maccherone demostró que miembros dedicados a un sólo equipo duplicaron la productividad y los equipos estables (sin rotación) mejoraron la productividad en un 60%. https://www.infoq.com/presentations/agile-quantify
[2] Wilkinson, David. Group decision-making. Lo que dice la última investigación. The Oxford Review, Diciembre 2019
[3] “What Google Learned From Its Quest to Build the Perfect Team”: https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html
[4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland https://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr y también “Evidence for a Collective Intelligence Factor in the Performance of Human Groups“
[5] The Wisdom of Teams: Creating the High-Performance Organization – Jon Katzenbach and Douglas Smith – indica que las habilidades potenciales son tan importantes como las habilidades que la gente tiene actualmente para predecir efectividad.
[6] [7] [8] Wilkinson, David. Group decision-making. Lo que dice la última investigación, The Oxford Review, Diciembre 2019
[9] “The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?” – Nelson Cowan – https://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory
[10] Knowledge management https://en.wikipedia.org/wiki/Knowledge_management
[11] Estas son observaciones informales que cualquiera puede hacer, pero una de las investigaciones más conocidas la hizo la revista inglesa Nature Human Behavior en 2017.
[12] Stable reference: https://www.jstor.org/stable/2786271
[13] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam y Ware Myers https://hbswk.hbs.edu/archive/2996.html
[14] The Mythical Man-Month: Essays on Software Engineering – Frederick Brooks https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Enlaces de interés:
El Enfoque Agile De La Planeacion
Planeación, Cono de Incertidumbre y Estimaciones en IT
¿Qué Certificación Elegir como Scrum MasterEstos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
2 Comments
Probablemente usted o su organización ya tienen muy claro la Meta y los Objetivos que desea para su proyecto, si es así déjeme felicitarlo porque no siempre es fácil, si por el contrario aún no ha dedicado tiempo a esa tarea o sigue luchando para definir sus metas y objetivos quizá quiere echar un vistazo a nuestro video anterior Definiendo Metas y Objetivos.
Ahora bien, suponiendo que sus metas y objetivos están establecidos, es probable que usted tenga algunas ideas para poder cumplirlos, aquí es donde la participación de los miembros del equipo con el cual usted trabaja se vuelve importante, ya que las perspectivas de diferentes integrantes llega a la creación, fusión o discriminacón de ideas. Todas esta interacción que puede ser impulsado por prácticas de design thinking provoca una lluvia de ideas que se convertirán eventualmente en estrategias de ejecución.
Cuando obtenga muchas ideas y/o estrategias el siguiente paso consistirá en evaluar cuales respaldan de mejor manera a sus objetivos, en el video de este post, llamado Eligiendo Una Estrategia, puede obtner una referancia rápida de como evaluar el grado de cumplimiento de sus ideas y estrategias a los objetivos que persigue:
- Lluvia de ideas
- Matriz de evaluación
- ¿La estrategia satisface los objetivos?
- ¿La estrategia es factible?
- ¿Los riesgos de la estrategia son aceptables?
- ¿La estrategia es compatible con la cultura de la organización?
Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.
También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Eligiendo Una Estrategia:
Eligiendo Una EstrategiaAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
¿Qué es una VPN?
El Wi-Fi público gratuito en la cafetería podría no ser tan seguro como parece. Si te unes a la red, podría interceptar e inspeccionar todo tu tráfico web, enviando esa información a fuerzas malévolas. Su ISP, o el ISP conectado a esa red Wi-Fi pública, también desea espiar sus actividades web para vender esa información a los anunciantes. Es por eso que necesitas una VPN o Red Privada Virtual (Virtual Private Network) si desea evitar esos riesgos.
Cuando su VPN está activa, su tráfico web viaja a través de un túnel encriptado a un servidor administrado por el servicio VPN. Eso mantiene su información a salvo de los ladrones de datos con redes falsas. También ayuda a protegerse contra los ISP que venden metadatos anónimos sobre sus hábitos web. Cuando su tráfico sale a la web a través del servidor VPN, parece que tiene una dirección IP en la ubicación de ese servidor. Esto protege su identidad real mientras navega por la Web.
Las VPN a menudo son utilizadas por periodistas o personas que viven en países con políticas restrictivas hacia Internet. También son una forma útil de suplantar su ubicación para necesidades menos serias. El contenido bloqueado por región, como los eventos deportivos o las películas de Netflix que están disponibles en algunos países, pero no en otros, se pueden ver con una VPN porque el servicio suplanta su ubicación. Netflix y otros servicios de transmisión de video pueden ser bastante agresivos para bloquear el uso de VPN como resultado.
Precios y características
TunnelBear es uno de los pocos proveedores que he revisado que ofrece un servicio de VPN gratuito. Sin embargo, el nivel TunnelBear gratuito lo restringe a solo 500 MB de datos por mes. Puede ganar más datos al tuitear sobre la empresa, lo que puede aumentar su límite a un total de 1 GB por un mes. La versión gratuita de HotSpot Shield Elite le sirve anuncios en su lugar, pero no restringe el uso de datos.
Puede pagar TunnelBear utilizando las principales tarjetas de crédito o transacciones BitCoin anónimas.
Con una cuenta gratuita o una cuenta de pago, puede usar hasta cinco dispositivos en una sola cuenta TunnelBear. Eso es promedio para VPN, aunque NordVPN ofrece seis, de fábrica. Tanto TorGuard VPN como KeepSolid VPN Unlimited ofrecen ranuras adicionales para más dispositivos a tarifas mensuales.
TunnelBear tiene software de cliente para Windows, macOS, iOS y dispositivos Android. También ofrece complementos de navegador para Chrome y Opera. También me gustaría ver una extensión para Firefox, pero no tuve tanta suerte hasta ahora. El uso de un complemento de navegador VPN solo ejecuta los datos de su navegador a través del servicio VPN, permitiendo que sus otras aplicaciones funcionen sin restricciones, pero también sin protección. Es una característica que me gusta, ya que ofrece protección para casi cualquier dispositivo que pueda ejecutar un navegador. No es, sin embargo, un sustituto de la protección VPN completa del servicio, que es lo que probé.
Protocolos VPN
Las VPN han existido por mucho tiempo y, como resultado, hay una gran cantidad de formas de crear una conexión VPN. TunnelBear protege su conexión con el protocolo OpenVPN para Android, macOS y Windows. Este es mi protocolo preferido, ya que es más nuevo, más rápido, más seguro y de código abierto.
La aplicación TunnelBear iPhone, mientras tanto, usa el protocolo IKEv2, que es una buena opción para esa plataforma. No puede cambiar qué protocolo utiliza TunnelBear en su aplicación, pero eso está bien para la mayoría de los usuarios.
Servidores y ubicaciones de servidores
Cuando reviso las VPN, considero cuántos servidores ofrece, dónde están ubicados esos servidores y cuántos de esos servidores son virtuales. El primer punto es simplemente un reflejo de la solidez del servicio VPN. Es cierto que una empresa más grande que haga más negocios probablemente tendrá más servidores, y también es cierto, que las empresas harán girar los servidores hacia arriba y hacia abajo según sea necesario. Pero mientras más servidores proporcione una empresa, es menos probable que tenga que compartir ancho de banda con muchos otros usuarios en el mismo servidor.
La distribución de servidores de una VPN también es importante. Cuantas más ubicaciones de servidor tenga un servicio, más opciones tendrá para suplantar su ubicación. Una gran diversidad geográfica también significa que es más probable que encuentre un servidor cercano al viajar al extranjero, que probablemente será más rápido y resistente que uno distante.
Los servidores virtuales son servidores definidos por software. Eso significa que varios servidores virtuales pueden ejecutarse en un solo servidor físico. También significa que un servidor virtual puede configurarse para comportarse como si estuviera ubicado en un país, cuando en realidad está en otro. Si le preocupa qué países específicos manejan sus datos, desea saber cuántos servidores virtuales usa una VPN y dónde se encuentran realmente.
Su privacidad con TunnelBear
La mayor fortaleza de TunnelBear, además de sus poderosos usos, es su postura sobre la privacidad. Tiene una de las mejores políticas de privacidad que he visto, explicando en gran detalle y con un lenguaje sencillo, exactamente lo que recopila y por qué. También incluye secciones de discusión, donde la compañía explica cómo llegó a una decisión en particular. Por ejemplo, una sección de extracción explica cómo la compañía solía reunir los nombres de los usuarios para personalizar las comunicaciones, pero decidió que no era necesario recopilar o almacenar esta información y que su pérdida podía poner en riesgo a los clientes.
La política de privacidad de TunnelBear también establece claramente que no almacena las direcciones IP de quienes visitan el sitio web de la compañía, la dirección IP de los usuarios al conectarse, las consultas DNS de los usuarios mientras están conectadas o cualquier información relacionada con otras actividades de los usuarios mientras usan TunnelBear. Esto incluye otras aplicaciones que pueda estar ejecutando u otros sitios que pueda visitar. Al no tener esta información en primer lugar, no se puede obligar a la compañía a entregarla a la policía, o perder el control de la misma en una violación de datos.
Notablemente, TunnelBear dice que no divulgará, venderá o intercambiará información personal con compañías de terceros. Ese es un compromiso notable que no todas las compañías VPN hacen. TunnelBear utiliza terceros para el procesamiento de pagos, pero esto no es inusual. Además, un representante de la compañía me confirmó que la única fuente de ingresos de TunnelBear son las suscripciones, no la minería de datos o la reorientación de anuncios.
La compañía tiene su sede en Canadá, y un representante de la compañía explicó que no está sujeta a ninguna ley obligatoria de retención de datos.
TunnelBear tiene la notable distinción de haber completado una auditoría de código independiente y publicado públicamente los resultados. El objetivo de una auditoría de código es encontrar fallas potenciales en el diseño de la aplicación, por lo que esta es una buena noticia. Este tipo de evaluaciones de terceros no siempre se llevan a cabo o se hacen públicas, y me alegra ver que TunnelBear considera que la privacidad y seguridad son lo suficientemente serias como para tomarse el tiempo de someterse a la auditoría.
Manos a la obra con TunnelBear
Anteriormente, la aplicación TunnelBear utilizaba una interfaz útil pero anticuada que dependía en gran medida de metáforas visuales antiguas como conmutadores y diales. La compañía se ha alejado de este enfoque y me gusta el resultado. El nuevo cliente es elegante y sutil, construido alrededor de un mapa central del mundo que muestra las ubicaciones de servidores de la compañía. Seleccione la ubicación que desee desde el menú de arriba, active la protección y recibirá una animación sorprendentemente suave de un oso que se aleja de su ubicación actual. Las aplicaciones móviles usan el mismo diseño, por lo que tendrás una experiencia familiar sin importar a dónde vayas con TunnelBear.
A diferencia de otras aplicaciones Windows VPN, TunnelBear incluye un modo minimizado. Esto es más funcional que el atajo de la barra de tareas pero menos gráfico que la aplicación en toda regla.
TunnelBear tiene una actitud irónica que aporta a todos los aspectos de su aplicación. Es encantador y colorido, sin ser dominante ni empalagoso. Por ejemplo, cada vez que se conecta a un servidor VPN, aparece una notificación con un oso con un sombrero representante de ese país.
TunnelBear no tiene muchas ubicaciones entre las que elegir, pero un cuadro de búsqueda de ubicación sería una excelente adición, como lo sería una lista de servidores, con información básica, como carga y tiempo de ping. NordVPN hace un excelente trabajo al transmitir estadísticas vitales sobre sus servidores VPN, y ofrece servidores especializados para conectarse a Tor, transmitir video y más.
La aplicación TunnelBear incluye algunas características avanzadas, como el Modo Vigilant. Esto evita que los datos se escapen a través de su conexión a Internet durante los segundos que demora TunnelBear en volverse a conectar en caso de que se desconecte. GhostBear tiene como objetivo eludir el bloqueo de VPN al disfrazar el tráfico VPN como tráfico HTTPS normal.
Otra característica de seguridad importante es Trusted Networks. Esto es básicamente una lista blanca de redes Wi-Fi en las que confías. Cuando esta función está activada, TunnelBear se conectará automáticamente si la red Wi-Fi en la que se encuentra no es una de las redes en su lista blanca. Me gusta esta característica, pero otras compañías que incluyen una característica similar la enmarcan más claramente al decir que la VPN se conectará en redes que no son de confianza. Aún así, hace el trabajo.
TunnelBear y Netflix
Si bien nadie puede saber que eres un perro en línea, las empresas de transmisión como Netflix sí toman nota de tu ubicación. Eso se debe a que las empresas a menudo tienen que respetar las restricciones geográficas con el contenido que proporcionan. Por ejemplo, si vive en los EE. UU., Debe pagar una suscripción a CBS All Access para ver Star Trek: Discovery. Si vives fuera de EE. UU., Puedes mirar el programa a través de Netflix. Esta es la razón por la que Netflix en particular ha sido tan agresivo al bloquear usuarios de VPN.
Afortunadamente, no tendrás esos problemas con TunnelBear. No tuve problemas para acceder a Netflix desde mi teléfono Android mientras la VPN se estaba ejecutando. También funcionó sin problemas en una computadora que utilizaba el complemento Chrome VPN de TunnelBear.
Después de leer los Términos de uso de Netflix, no tengo claro si la compañía considera que es una violación usar una VPN para cualquier propósito. La sección 6c de los Términos de uso dice que Netflix intentará verificar su ubicación y que solo se le garantiza el acceso al contenido dentro de su país de residencia principal. Lo que está claro es que a Netflix no le gustan las VPN.
Más allá de VPN
Cuando la mayoría de las compañías VPN incluyen bloqueo de anuncios, tienden a hacerlo a nivel de red, bloqueando los anuncios incluso antes de que lleguen a su computadora. TunnelBear no hace esto. En cambio, la compañía lanzó discretamente un complemento de navegador independiente llamado Blocker. Conserva los osos y el encanto de la marca TunnelBear, y está sorprendentemente bien pulido para un plugin de Chrome.
Cuando visita un sitio, la cantidad de anuncios bloqueados aparece en la boca del icono del pequeño oso, como si los hubiera arrancado del cuerpo aún caliente del sitio web. Al hacer clic en la flecha al lado de la sección Bloqueo, se expande una lista de todos los elementos bloqueados. Me gusta esto, ya que te permite bloquear algunos elementos en un sitio web, pero no todos. Podría, por ejemplo, bloquear rastreadores que desafían la privacidad y, al mismo tiempo, permitir la publicación de anuncios. TunnelBear Blocker también maneja elementos más complejos, como etiquetas ultrasónicas. Estos son tonos de alta frecuencia que se reproducen durante los anuncios y que las aplicaciones reciben para indicarles a los anunciantes que se está viendo su anuncio.
Los controles finos, como las listas blancas del sitio, son especialmente importantes con los bloqueadores de anuncios. Algunos bloqueadores rompen elementos en los sitios, lo que los hace prácticamente inutilizables. A veces, aguantar algunos anuncios es el precio a pagar para ver un sitio en funcionamiento.
Del mismo modo, TunnelBear lanzó un administrador de contraseñas llamado RememBear. Actualmente, la compañía ofrece clientes RememBear para Android, iOS, macOS y Windows. Es gratis para usar en un dispositivo, pero si desea la conveniencia de sincronizar en todos sus dispositivos. Descubrimos que es un buen servicio que maneja los conceptos básicos de una manera divertida y caprichosa, con muchos osos animados. Sin embargo, carece de funciones avanzadas de administración de contraseñas, como autentificación de dos factores, uso compartido seguro y herencia de contraseñas.
Prueba de velocidad
No importa la VPN que elija, verá un impacto en su experiencia de navegación web. Eso es porque estás agregando algunos aros adicionales para que tu tráfico salte. Las velocidades son una preocupación perenne para los consumidores, pero procuro y desanimo a cualquiera de usar solo los resultados de velocidad como un punto de referencia para elegir un servicio VPN.
En el mundo a menudo osificado y excesivamente técnico de los productos de seguridad, es alegre y simpático. La compañía siempre ha puesto especial énfasis en el diseño y la experiencia del usuario, que es muy necesario en el mundo de las VPN específicamente y en general en la seguridad digital en general. TunnelBear hace todo eso sin dejar de ofrecer un producto seguro y simple con una red troncal robusta. Es una gran compra, y una que se ha vuelto más convincente desde la última vez que la evaluamos. Lo que es más importante, tiene una política de privacidad clara y sólida (puede estar seguro de que no se cansará de estos osos).
Sin embargo, no es un producto perfecto. El servicio carece del tipo de diversidad geográfica amplia que nos gusta ver. Tampoco tiene servidores especializados, aunque podría argumentarse que evita estos a favor de la simplicidad. Y aunque no creemos que los puntajes de las pruebas de velocidad sean la mejor medida del valor de un servicio VPN, los resultados de las pruebas de TunnelBear están significativamente por debajo del promedio en algunas categorías.
Lo que TunnelBear hace bien es crear un producto de seguridad que realmente usará. Es un producto potente y asequible.
Otras ligas de interés:
Ponte Trebel, la app que compite con torrents
Google Wallet y Android Pay Son Uno, son Google Pay
🙂
No Comment
Descrubriendo Trebel
En 2015, en un viaje relámpago a EU, tuve oportunidad de probar un poco Trebel Music, la cual a primera vista, parecía similar a la versión gratuita de Spotify. Mi primera impresión fue que en un mundo dominado por Apple Music, Play Music y Spotify a este jugador no le esperaba un vida tan larga.
Casi al final de ese viaje me topé con un grupo de estudiantes norteamericanos de entre 16 y 18 años de edad y noté que muchos de ellos usaban la misma app. Mi curiosidad creció suficiente como para acercarme un grupo de algunos de esos estudiantes y preguntar porque usaban esa app, y los muchachos me dijeron:
Oh! se llama Trebel, esta buena porque no tienes que pagar suscripción y puedes escuchar la música offline.
Esa respuesta llamó mi atención y de inmediato comencé a probarla, lo malo es que en ese momento sólo pude probarla algunos minutos, pero lo suficiente para notar que la app utilizaba publicidad para permitir la descarga de música, también me encantó percibir mucho elementos de Gamifición.
Desafortunadamente como la aplicación solo estaba disponible en EU y yo ya de regreso en mi país, no la seguí utilizando y eventualmente la olvidé. Pero en 2018, tuve la sorpresa de enterarme que la app ya estaba disponible en mi país México, y aparentemente con planes de expandirse a otros lugares, así que ahora sí tu ve la oportunidad de probar más a fondo esta app.
Un modelo de negocio diferente
Como mencioné, usted podría pensar que esta app compite directamente con Apple Music, Play Music, TuneIn u otras, y eso puede ser cierto, sin embargó Gary Mekikian, CEO de M&M Media, quienes crearon Trebel, dice lo siguiente:
Competimos con sitios de torrents. Trebel no es un servicio de streaming… No somos un servicio de radio. Somos un servicio de descarga y reproducción.
Con Trebel, un usuario puede descargar cualquier canción del catálogo de la aplicación y luego reproducir esa canción sin hacer streaming. De esta manera, los usuarios tienen la libertad de reproducir cualquier canción que quieran pero sin tener que pagar una tarifa regularmente. De esta manera, Trebel Music imita a los sitios de torrents, pero con esta aplicación, los artistas son recompensados por su trabajo.
Trebel compensa a los artistas llenando la aplicación con publicidad, eso quizá sea de esperarse, pero lo interesante es que cada vez que el usuario ve un anuncio, obtiene una moneda digital o T-Coins, lo que le permite descargar y escuchar más canciones. Esta moneda digital es el insentivo para los usuarios que a su vez ayuda a pagar a los artistas por su música.
El usuario también pude obtener monedas solo por registrarse en la aplicación, por invitar a otros a registrarse, ver videos promocionales y hacer check-in en comercios afiliados, o bien, también puede pagar para no exponerse a toda esta publicidad (¿alguien dijo Gamificación? 🙂 ).
M&M Media trae una solución interesante, debido a que si bien pensaron principalmente en jóvenes que aún no están percibiendo un ingreso, y que son atraidos a descargar música ilegalmente, la verdad es que en paises de economía emergente como el mio, hay mucha gente que no es necesariamente joven pero tampoco quiere o puede pagar por un servicio premium.
Le doy 3.5 de 5
En general, mi experiencia con Trebel Music ha sido positiva, pero ciertamente no perfecta. El concepto único de la aplicación permite a los usuarios escuchar música sin invertir en un costoso plan de datos o esperar por buffering. Sin embargo, al usar la aplicación, la sentí como si se hubieran dedicado más esfuerzos a las características sociales y cosméticas que al factor real de venta de la aplicación, por supuesto esto pude deberse también a que estoy demasiado viejo para estar en el nicho principal de esta app. 😀
Una bonita característica de la aplicación es que cuando tocas una canción, la portada del álbum gira como un disco. Incluso puede interactuar con el disco virtual girándolo hacia adelante para saltar adelante en la canción, o girando hacia atrás para rebobinar.
Esta característica es efectiva, pero hubiera sido bueno tener más interactividad. En un disco real, escuchas un cierto efecto de sonido cuando giras el vinilo manualmente. La falta de este sonido como retroalimentación en la aplicación hace que parezca que falta algo, pero es un detalle perdonable.
En términos de características sociales, Trebel toma nota de otras aplicaciones. El usuario puede seguir a otros usuarios, compartir listas de reproducción con sus contactos dentro de la app e incluso enviarles monedas virtuales, compartir en redes sociales, y todo lo que esperaría a ese respecto. Pero Trebel intenta llevar el tema social un paso más allá, conectándolo con sus compañeros de colegio con la opción Campus. Los estudiantes pueden ver las canciones principales reproducidas y descargadas en su colegio, aunque esta opción por ahora no incluye escuelas Mexicanas ni Latinas, ignoro cual sea el proceso para incluir más colegios.
Este tema de la edad es aun más claro al ver el catálogo disponible, ya que es fácil encontrar los éxitos pop del momento, pero si el usuario desea algo más exquisito de décadas pasadas las opciones no serán tantas, aunque muchas veces el mensaje “próximamente” aparece, y como la app solo tienes unos meses en México, mis esperanzas aún no mueren…de lo contrario siempre está Radio Universal (chiste reservado para habitante de la Ciudad de México).
La aplicación funciona bien la mayor parte del tiempo, pero ocasionalmente se encuentra con un error donde el hacer clic en una canción no la reproduce. También me encontré con el problema de que la descarga se cuelga (no avanza) incluso por WI-FI.
La verdad sea dicha, aún sigo prefiriendo mi stock personal de música guardada en mi teléfono de manera tradicional y el amplio catálogo de Spotify, pero Trebel es útil para álbumes en los que no quiero gastar dinero o que todavía estoy valorando.
Sin embargo, hay que tener en cuenta que Trebel es un competidor nuevo, y seguramente mejorará en el futuro cercano. Los inconvenientes son comunes en cualquier iniciativa nueva, pero me parece que el concepto y el diseño de Trebel hacen que valga la pena la descarga la cual está diponible en la App Store de Apple y Google Play Store.
Otras entradas que pueden ser de su interés:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Desarrollo / Development / Destacadas / Featured / Experiencia de Usuario / UX / Gamificación / Gamification / IdeasGamification Success Case
Previously, I spoke about the generalities of gamification, I expressed the definition and the objectives that gamification pursues, if you aren’t familiar with the subject before to continue reading, I recommend you that you go and read the previous post.
As part of a project in which I participated recently, I was analyzing how some organizations and their web solutions were using the gamification concept, and one of these solutions which it seems to one of the most interesting and outstanding using this concept is LinkedIn. As many already know, LinkedIn is a social network oriented to professional relationships, and as part of its operation, this social network uses a set of elements that integrate the gamification idea in its design. Now we’ll take a look on some of them, we’ll find out how they work and what is the purpose of the Gamification strategy and LinkedIn.
Profile
To make this network of professionals valuable, as much as for LinkedIn as for its users, the information from each member is required. The more information is provided by the user the greater the benefit which the network gets overall. When a new user signs in, tend to provide only the minimum information, usually doubting about how much information should provide, this apparently due mainly to distrust about sharing personal data, lack of time or laziness from network users.
LinkedIn, using gamification and UX (User Experience) elements, implemented a progress bar that appealed to the “sense of finishing something incomplete” to gently suggest and motivate to achieve a better percentage and thus obtain more information from the user, using a strategy where the percentage increase was easy to obtain at the beginning, but gradually it required more effort to reach 100% which added a touch of fun and challenge that invited to provide more data.
Eventually and very intelligently, LinkedIn realized that a disadvantage about just use a simple progress bar is that other data that arise as a consequence of changes in users’ working life, such as new job positions, new responsibilities, new certifications and academic progress, didn’t obtain relevance.
With the foregoing in mind, the percentage bar scheme was changed to a sphere that fills up as a cup with water, which is known as profile strength. Depending on how much the circle is filled, names are assigned to the “efficiency levels”, thus gauging ALL the data that is provided and also making LinkedIn members more willing to provide and update the information provided. it asks for them with a little invasive method and in addition without giving a foot to notice that the users are being “gameficated”.
Trying to improve even more their interface LinkedIn implemented some kind of mashup between their previous progress bar and the sphere ‘s efficiency levels, and currently is using a new progress bar.
But even with the previous gamification elements, with which the design encourages users to provide information and thus increase the strength of their profiles, what is obtained is a self-description of the user qualities, which should be verifiable by other means. To solve this, the skills and expertise were devised, which, taking advantage of the social network inherent advantages, allow other users to validate the skills and experience, which creates a more accurate view of the user of interest.
Views
No profile makes much sense if it’s not being seen. The social network provides statistics to its members about how many times their profiles have been seen in recent days.
It also shows who have been the last person to see the profile. This not only stimulates the motivator of being the “center of attention”, but also encourages clicking on the profile of those people to potentially connect with them.
Updates
The LinkedIn users not just share personal and professional information, the network’s mechanic encourages them to share their articles, events, job opportunities and other types of related information with its members’ labor life; offering with it, the number of visits, their respective likes and the possibility of following other users or interesting groups, which are gamification techniques already tested by the social network habitual users.
Groups
Belonging to a group, contributing with posts and answers can increase the potential influence of a user as an expert within a community. The number of members is an indicator for the group owner about how successful are the actions derived from organizing a group of people around a certain topic.
Others
During my research about LinkedIn and its gamification strategies, I found mentions of some that I have not been able to corroborate, but I have seen mentioned in different places. Apparently there have been mailings and messages with congratulations to some members for a variety of “achievements”, such as being one of the most viewed profiles according to certain criteria of time and views or being a prominent member with a number of shared articles and views obtained to them, as well as some other similar motivators that pretend to be fun.
Do you know some other gamification techniques used on other sites? do you currently use gamification or do you intend to do it? do you think it’s worth use gamification? share it with us.
Other links that could be interesting for you:
How Gamification Motivates the Masses
Top 10 Groundbreaking Gamification Examples
Some interesting publications:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Puede pensar que la principal responsabilidad de alguien a cargo de un proyecto es entregarlo a tiempo y dentro del presupuesto, de hecho, es una manera muy común de pensar de organizacione, pero estan equivocados. Como parte de un cuerpo estratégico de alto nivel o como un independiente, los responsables de la administración de proyectos, en primer lugar, ayudan a impulsar, guiar y ejecutar acciones para lograr los objetivos de valor agregado identificados de cualquier organización.
Cuando las organizaciones maduran eventualmente crean cosas como las oficinas de gestión de proyectos (PMO) y las buenas prácticas de gestión de proyectos tienen más probabilidades de ser bien recibidas por los ejecutivos y partes interesadas de la organización como elementos tácticos indispensables una vez que reconocen su verdadero valor estratégico.
Muchas organizaciones hoy ya saben que contratado y capacitado a los pensadores estratégicos, aumenta la probabilidad de ejecutar proyectos de alto impacto. Este alto impacto, entre otras cosas, se logra identificando metas y objetivos de largo, mediano y corto plazo con el que los posteriores esfuerzos se deben alinear. Cada involucrado en un proyecto debe poder tener una comprensión clara de la línea directa desde las tareas de un proyecto hasta la visión estratégica de alto nivel.
En el video de este post, llamado Definiendo Metas Y Objetivos, puede aprender las bases para poder crear metas y objetivos apropiados para sus proyectos. En este video se hablamos de :
- Definición de una meta
- Definición de objetivo
- Tipos de objetivos
- Elementos a tomar en cuenta para crear y redactar objetivos
Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.
También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Definiendo Metas Y Objetivos:
Definiendo Metas Y ObjetivosAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured¿El tamaño importa?
Esta es una pregunta muy vieja, pero en este blog solo contestaremos a esa interrogante desde el punto de vista de la administración de proyectos (descepcionad@s dirigirse a blogs de otro tipo). En esta ocasión veremos que son y cuál es el propósito de las famosas historias de usario o user stories y en que se diferencían con los requerimientos tradicionales en un proyecto.
Cuando era niño pasé mucho tiempo jugando en la playa con mis primas y primos, y en algunos de esos juegos, me encontré escarbando, transportando y apilando arena de un punto a otro (mis herramientas eran una pala y una cubeta de plástico) después de unos 10 minutos mi primo más pequeño me preguntó cuanto me había tardado en juntar toda esa arena, a lo cual contesté: “como unas 30 vueltas”. Después de eso tanto mi primo y como yo supusimos que con su propia cubeta podría duplicar la cantidad de arena en otras 30 vueltas. No fue así, mi primo pequeño todavía, se tardó bastante más debido a ambos fallamos en evaluar la capacidad de su cubeta y en apreciar que Gabriel (mi primo) al ser muy pequeñito (quizá 6 años) aún tenía que esforzarse para cargar una cubeta de diferente tamaño completamente llena y terminar en sólo 30 vueltas.
Por simple y obvia que parezca esta anécdota, la realidad sorprende, ya que muchos equipos de trabajo encargados de proyectos de todos tamaños siguen cayendo en este mismo error. Aún no están completamente al tanto de su capacidad o su velocidad, tampoco tienen claro la diferencia entre tamaño y distancia en un proyecto, y por lo tanto, fallan desde el principio en sus estimaciones.
No ocuparse de tratar de medir el tamaño de lo que se va a hacer es un error, por lo tanto el tamaño, SÍ importa, y antes de medir tiempos y distancias usted debe saber la respuesta a preguntas como ¿cuál es el tamaño de su cubeta y su pala? ¿cuántas cubetas y palas tiene? ¿existe la cantidad de personas suficiente para cada pala y cubeta?
¿Que son las historias de usuario?
Por facilidad muchas veces se sobre simplifica, diciendo que las historias de usuario o user stories son los requerimientos de un sistema o un producto, pero tienen serias diferencias con otras aproximaciones comunes como son los casos de uso, especificaciones de requisitos de software IEEE 830 y escenarios de diseño e interacción.
Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva funcionalidad, generalmente un usuario o cliente del producto que se desea crear. Por lo general, siguen una plantilla simple:
Como <tipo de usuario>, quiero <algún objetivo> para que <algún motivo>.
Las historias de usuario a menudo se escriben en fichas o notas adhesivas, se almacenan en una caja y se organizan en paredes, pizarrones o mesas para facilitar la planificación y el debate. Como tales, cambian fuertemente el enfoque de escribir sobre las características, a discutirlas. De hecho, estas discusiones son más importantes que cualquier texto que se escriba.
Esta es una definición simple de que es una historia de usuario, pero créame, hay mucho más detrás, redactar buenas historias de usuario puede ser un reto, y para lograr hacer buenas historias hay que entender más acerca de su propósito.
Asigna Valor (puntos) a las historias de usuario
Eventualmente, cuando me involucré en la gestión de proyectos y más tarde Agile, descubrí que una manera de estimar el tamaño de lo que se necesita es utilizar las historias de usuario. Para explicar lo que son seguiré echando mano de las analogías.
¿Cuándo fue la última vez que fue a un restaurante y pidió una sopa o una bebida en mililitros?…..así es, normalmente no hacemos eso, solemos pedir una sopa o una bebida con una medida relativa como “chica, mediana o grande”. Las historias de usuario son relativas también, se usan para expresar tamaño, no cuentan con un valor estandarizado, pero los valores deben ser relativos uno de otro, es decir, una historia de usuario que tenga valor 2 es del doble de tamaña de una que vale 1.
Para asignar valores o puntos a diferentes tamaños hay quienes usan tallas de camisa, razas de perros, valores Fibonacci (mis valores favoritos) u otras representaciones, no importa que prefiera, eventualmente debe usar valores relativos. Tome como ejemplo la siguiente tabla, con una posible asignación de puntos:
Tamaño Camisa Puntos XS 1 S 2 M 3 L 5 XL 8 XLL 12 En un proyecto Agile no es raro comenzar una iteración con requisitos que NO son completamente especificados, los detalles se descubrirán más tarde durante la iteración. Sin embargo, debemos asociar un estimado con cada historia que podamos visualizar en el momento, incluso a aquellas que no están completamente definidas.
¿Y en dónde están los detalles?
Aquellos acostumbrado a el detalle que se agrega de antemano a los requerimientos tradicionales, de inmediato les surgirá esta pregunta. El detalle se puede agregar a las historias de usuario de dos maneras:
- Dividiendo una historia de usuario en múltiples historias de usuarios y más pequeñas.
- Agregando “condiciones de satisfacción”.
Cuando una historia relativamente grande se divide en historias de usuarios ágiles y múltiples, es natural suponer que se han agregado detalles. Después de todo, se ha escrito más.
Las condiciones de satisfacción son simplemente pruebas de aceptación de alto nivel que deberán cumplirse después de que se complete la historia del usuario. Considere lo siguiente como otro ejemplo de historia de usuario ágil:
Como director de marketing, quiero seleccionar un periodo de tiempo para que yo pueda revisar el rendimiento pasado de campañas publicitarias en ese periodo.
El detalle podría agregarse a este ejemplo de historia de usuario al agregar las siguientes condiciones de satisfacción:
- Asegúrese de que funcione con los datos de los principales minoristas: Oxxo, Seven Eleven, Extra.
- Debe soportar los datos de los últimos tres años.
- Los periodos se eligen en intervalos de meses (no días, ni semanas).
¿Quién escribe historias de usuarios?
Cualquiera puede escribir historias de usuario. Sin embargo, es responsabilidad del propietario del producto o product owner asegurarse de que exista un retraso acumulado de productos de historias de usuario ágiles, pero eso no significa necesariamente que el propietario del producto es quien los escribe. En el transcurso de un buen proyecto Agile, debe contar con ejemplos de historia de usuario escritos por cada miembro del equipo.
Además, tenga en cuenta que quién escribe una historia de usuario es mucho menos importante que quién está involucrado en las discusiones de la misma.
¿Cuándo se escriben las historias de los usuarios?
Las historias de usuario se escriben a lo largo de un proyecto ágil. Por lo general, se lleva a cabo un taller de redacción de historias cerca del inicio del proyecto ágil, de cada relese y/o al inicio de cada iteración (personalmente tomo algunas de las primeras opciones, según la longitud del proyecto, y solo hago grooming en cada iteración). Todos en el equipo participan con el objetivo de crear una “lista de pedidos” o Product Backlog que describa por completo la funcionalidad que se agregará durante el transcurso del proyecto o en un ciclo de lanzamiento o release de tres a seis meses.
Algunas de estas historias de usuarios ágiles serán, sin duda, épicas o epics (no se llaman épicas por que se dramáticas 😄). Las épicas son historias muy grandes que por su tamaño se descompondrán más tarde en historias más pequeñas que quepan más fácilmente en una sola iteración. Además, las historias nuevas se pueden escribir y agregar a la “lista de pedidos” del producto en cualquier momento y por cualquier persona.
Velocidad (Velocity)
No profundizaré tanto en este tema porque da para escribir otra entrada dedicada por completo a ello, pero para comprender cómo puede funcionar la estimación con puntos de historia que asignamos en la tabla que mostramos anteriormente, es necesario introducir un nuevo concepto: Velocidad o Velocity. La velocidad es una medida de la tasa de progreso de un equipo. Se calcula sumando la cantidad de puntos de historia asignados a cada historia de usuario que el equipo completó durante la iteración.
Si el equipo completa tres historias, cada una estimada en cinco puntos de historia, su velocidad es de quince. Si el equipo completa dos historias de cinco puntos, su velocidad es diez.
Si un equipo completó diez puntos de trabajo la última iteración, nuestro mejor cálculo es que completarán diez puntos esta iteración. Debido a que los puntos de la historia son estimaciones del tamaño relativo, esto será cierto ya sea que trabajen en dos historias de cinco puntos o cinco historias de dos puntos.
Cómo puede ver esto es muy importante para hacer una estimacion y despúes de conocer el tamaño, para después proceder a calcular una estimación para el final del proyecto o de un release (la distancia).
¿Las historias de usuario reemplazan un documento de requisitos?
Los proyectos ágiles, especialmente los de Scrum, usan un product backlog, que es una lista priorizada de las funcionalidades que se desarrollarán en un producto o servicio. Aunque los product backlog items pueden ser lo que el equipo desee, las historias de usuario han surgido como la mejor y más popular forma de product backlog items.
Si bien un product backlog, puede considerarse como un reemplazo de el documento de requisitos de un proyecto tradicional e incluso quizá de un WBS, es importante recordar que la parte escrita de una historia de usuario ágil (“Como usuario, quiero …”) está incompleta hasta que las discusiones sobre esa historia tienen lugar.
A menudo es mejor pensar en la parte escrita como un indicador del requisito real. Las historias de usuario pueden apuntar a un diagrama que representa un flujo de trabajo, una hoja de cálculo que muestra cómo realizar un cálculo o cualquier otro artefacto que el propietario del producto o equipo deseen.
Hasta aquí dejo las user stories, déjeme saber si quiere saber más 😉.
Enlaces de interés:
El Enfoque Agile De La Planeacion
Planeación, Cono de Incertidumbre y Estimaciones en IT
Introduction to User StoriesEstos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Desarrollo / Development / Destacadas / Featured / Diseño Web / Experiencia de Usuario / UX / Gamificación / Gamification / Ideas / Programación / ProgrammingPlaying while working, studying, exercising or using the web
Those of us who have been or are gamers know that the idea or concept of gamification has been hovering around forever (at least, about 3 decades). Remember old phrases like, learn by playing! lose weight while having fun! etc. Now, although the concept is old, the term was coined thanks to a computer programmer named Nick Pelling in 2002, but in reality, the concept has begun to attract attention only in recent years.
Lately, I have met many people who use dazzling terms such as “game mechanics”, “game dynamics” or aims to establish as something complex and laborious the implementation of the concept, confusing the basic idea of gamification with complex marketing campaigns and big data. Certainly, you can create a sophisticated gamification implementation, but based on my experience involved in multimedia development teams since 1998, I can say that a lot about implementing gamification is just common sense.
Without being or pretending to be an expert in gamification, below I share some ideas, terms, and approaches that I’ve learned over time:
What is gamification?
There are lots of sites where you can get nice definitions about what gamification is, but to save the trip to Wikipedia, this is its definition:
Gamification is the application of game-design elements and game principles in non-game contexts. Gamification commonly employs game design elements to improve user engagement, organizational productivity, flow, learning, crowdsourcing, employee recruitment and evaluation, ease of use, usefulness of systems, physical exercise, traffic violations, voter apathy, and more. A collection of research on gamification shows that a majority of studies on gamification find it has positive effects on individuals. However, individual and contextual differences exist. Gamification can also improve an individual’s ability to comprehend digital content and understand a certain area of study such as music.
Did you understand that? Basically, it means, turns a task into something more interesting by adopting the logic of a game. The simplest way would be giving some sort of reward for doing some activity. The prize can be as obvious as a trophy or as vague and subjective as simply seeking to offer fun while doing a specific task. But of course, there’s much more that can be done, especially when human behavior is considered.
But to meet the cliché, this is my personal definition:
Gamification is the application of the metaphor of gaming to common or compulsory tasks to influence behavior, giving more motivation and increasing involvement, preference or loyalty.
Are video games useful?
For some years I was a World of Warcraft player, a very popular video game with millions of users, which I think is a great example of how these games can be related to the real world. Within World of Warcraft, one of the objectives is to make money. This money can be obtained in several ways, but most of it is completing quests (missions). As a result of solving the missions you get gold, which the player uses to obtain different things like buying clothes, weapons, materials, improvements, information for new missions, etc. (Does this sound familiar?), this is the basics of any business and an important part of life. Day by day World of Warcraft players spend their time making goods, offering services and fulfilling missions. In the real world, we do the same, we earn money to obtain some achievement; We spend that money on buying new things or we invest in something that allows us to earn more money or do something more efficiently or comfortably.
Enlarge
Blizzard Entertainment
A valid question would be why these players are so willing to spend so much time doing what they could do in real life? The answer is easy: because it’s fun.
Adopting the idea
At this point It’s important to clarify that not everything is about video games, we will not see in the immediate future someone willing to play the latest game of Microsoft Project or Word (although, you never know 😉). What we are trying to do is take ideas from games and insert them into some routine task, so these tasks don’t have to be boring to death.
With all the above in mind I have to be honest, despite the relatively recent popularity of the idea of gamification, not everyone knows what it is, not everyone is interested, it seems that to get hear and understand the term is required of some curiosity, wanting to know what is in vogue about developing, UX, etc., or just having a little bit of geekness. All this makes selling the idea to or in an organization is not as easy as it might seem (at least not here in the third world).
Recently I participated in a project where customer asked my team, to propose “innovative” ideas (another oversold term) to improve the technological proposal of an organization, as part of this I eventually proposed the idea of incorporating some initial and modest strategy of gamification, giving some overall but concrete examples including just enough detail, not exactly as something “innovative” but as something that only intended to “update” the technological solution implemented at the time. Surprisingly, although the organization which I was working with, develops technological solutions, 90% of those involved did not know what the hell I was talking about (shame on you Infotec); I had to explain the idea to business analysts, deputy directors, directors, contractors and developers without much success (nobody is a prophet in his own land, but I like to think I threw some light on lost souls).
I have to add that the word gamification is weird English and the translations into Spanish sound even worse, so the word doesn’t help too much to sell the concept, as a result of this experience I came up to the conclusion that in order to adopt the idea more easily, we must use words such as Productivity, Behavior Changes, Motivation and Preference (or engagement if you prefer the marketing jargon).
Points, Medals, Trophies, Position Tables
As responsible for a project some time ago, I needed to make a quality assurance in a series of contents for courses, with a lot of information to review and very little time, I told the members of my team, that the two people who found more errors would earn a big coffee every day for the next week. Suddenly a game was on.
Fortunately, we do not always need to resort to real physical awards in all cases. The management of information that users provide their organization, website or mobile application can be used to award prizes in different ways, the most common are:
- Points
- Medals
- Trophies
- Levels
- Position Tables
- Challenges
- Achievements
En un sitio o sistema web, por ejemplo, el concepto es utilizado ampliamente para que sus usuarios hagan más dentro del sitio o estén más tiempo expuestos a determinada información. Algún sitio donde se hacen trámites, puede hacer del llenado de sus formularios algo más ameno dando alguna especie de puntaje o jerarquía relacionada con un progreso por cada paso completado. Un sitio de ventas puede dar trofeos o medallas por las reseñas que un usuario coloca acerca de algún producto.
These examples are certainly very simple since only seek to motivate more users to carry out a task, and of course, they leave much more to exploit the concept, but they’re a good starting point to explore the benefits of gamification.
Not everything is about money
A strange and limited argument that I came across when I proposed gamification, is that accordingly with someone’s assumption, gamification was about giving economic incentives in the form of cash, coupons or discounts, which of course is not necessarily true, and falling into that assumption usually creates concern and even rejection from the sponsors of any project or production chain. Money is a good motivator for a user (it always is), but there is a word that you will find very often in blogs and books about gamification and also I already mentioned, this is engagement, this means that money will always motivate you doing some task but won’t necessarily “hook” you to it nor will make the activity enjoyable.
What else?
If you start to delve deeper into gamification issues, you will eventually realize that there is much more than just depending on incentives and certainly much more than relying on money. You will be using human behavior and the famous reptilian brain, that is, use in your favor something that is within human nature itself, play. Using gamification you will be appealing to feelings of pride and need for recognition, with which you could achieve even more than offering money in exchange.
In conclusion
I’ll share with you a couple of videos about some educational projects where I was involved and I used gamification (they’re old but still valid to understand the concept) and some bibliographies that I found useful and interesting:
Books:
- Why we do what we do: understanding self-motivation
- For the Win: How Game Thinking Can Revolutionize Your Business
- A Theory of Fun for Game Design
Videos:
Risk Prevention
Mexico’s Economic Development
English Learning Card Game
Thanks to @Mordred77M for the English translation, he’s not a natural English speaker and he´s still learning so don’t be grumpy and help him to improve 🙂
Related links:
Mint (Empresa con aplicaciones fintech que utiliza gamification para las finanzas personales)
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / FeaturedWithout Users (User Proxies)
Ideally, when we pretend to develop a software, we need to talk with one or more real users who are part of the customer team. But, the reality has the bad habit of punching Dilbert and us right in the nose and continuously we found our selves in one of two situations:
- We have as primary contacts, people who pretend to guess how a final user wants the software behaves when only the real user actually knows it, and yet we have limited or no access at all to them.
- The product is so innovating that we actually don’t have a real user in advance.
Unfortunately, very often is difficult to get the users that we need. For example, we could be developing a product with user all over the country, but we can’t bring one (or more) of them with us, to write requirements or user stories. Or maybe we could be writing software that will be used inside our company, but somebody says that we can’t talk directly with the users.
When we can’t get as many users as we’d like us to represent the different perspectives to the product, we have to resort to people or intermediary resources, also known as user proxies, who maybe are not users, but we need to include them in the project in order to represent the users and so deal with the two mentioned situations.
Warning
What I going say in rest of this post can be controversial and is subject to my personal experience but is also based on publications (that I always put at the end). This time I will focus on what characterizes each type of user proxy.
The user proxies selection can be critical to achieving the success of a project. The experience, motivations and possible agenda of a proxy must be considered. A user proxy involved in sales will have a completely different perspective from a domain expert’s. It’s important to be aware of these differences, that is why I’ll try to provide a synthesis of what characterizes some of them.
Proxies:
Final users supervisors
When we try to create internal use applications is common that middle management to be reluctant about to give full access to final users for a variety of reasons, so is very likely that you as a requirements engineer, business analyst, product owner, etc., end up dealing with supervisors and managers of the users on what you’re interested in.
We must be very careful when we dealing with those proxies, especially in public institutions that are very bureaucratic, because this they tend to fall in bad practices that try to minimize, dissimulate or hide during their process and operations.
On other occasions, the users’ supervisors intercede and want to represent the role of a user because they think they know more than the real users. But usually, the managers or supervisors have different usage pattern. You should be skilled enough to “turn around” that proxy and reach the final users as much as you can without offending the supervisor. In the section, What to do without users (or almost)? you can read what to do in those cases.
Development managers, development supervisors, development directors, development leaders and similar
This type of proxy is one the worst options unless you are writing software specifically for this type of user. Even when the intentions of this type of user sometimes are good, it’s likely this type of leader has his/her own interests and prioritize in a different way the requirements or user stories than a final user would.
This happens because this role tends to accelerate the introduction of new technologies, or in the worst case scenario, when there is too much technical debt or a disorganized operation, s/he will try to reduce her/his workload at the slightest opportunity.
Finally, the development managers usually don’t have experience as final users of the solution that is being built and they aren’t domain experts of interest. If a development supervisor es a real final user then you can consider him an appropriate domain expert, otherwise I advise you to avoid using her/him as a proxy if possible.
People involved in sales
The danger of use people involved in sales as proxies is that they usually tend to want to close a sale quickly and no matter what, which leads to a distorted vision about how a product should be built.
If the person in sales, lost the last sale due the lack of a specific characteristic, you can be sure that those people in sales instantly will include as a high priority requirement that characteristic or functionality. Another common situation is people in sales, according to the potential sale earning or commission tends to promise too much even with a small knowledge about other domains, with short-term benefit vision.
A company that places too much emphasis on lost sales or short-term profits may lose track of its vision and long-term strategies.
However, the people in sales can be a great conduct to reach final users and we should use them in that way. Ask to them introduce you to customers, join them in sales visits, in sales shows and promotion events, learn about how the products or services of your organization are exhibited and then talk to the users.
Domain experts
The domain experts are those who give us what we call experts’ domain and can be very important due to the knowledge that they have in the field of our product. Of course, some domains are more complex than others.
The domain experts can be great resources, but their usefulness is very dependent on whether they are current users or former users of the type of solution that we are creating. Knowing this we must be aware that this kind of proxies can make us create products aimed to their domain level, and if we are not careful we could end creating a too much complex software for the real users level.
Marketing groups
People or groups focused on marketing tend to focus more on the market or in niches themselves, rather than on individual users, so the result is that they concentrate more on quantities of functionalities than on the quality of them.
But do not dismiss our marketing friends, in many cases, they can provide us with valuable high-level information that can help us to establish relative priorities, but we shouldn’t expect a detailed vision for our requirements or user stories.
Former users
A former user can be a great proxy if their experience is recent. However, as with other proxies, we must be careful and consider that the objectives and incentives of our proxy are aligned with those of the current final user.
Customers
Customers are the ones who make the purchasing decision; they aren’t necessarily final users of the product. It’s important to consider the wishes of your customers because they, not your users, are the ones who sign the check to buy the solution unless of course, the final users and the clients are the same people.
The features of a product like this should be enough so that the end users do not shout too loudly; but they must also be those that attract the customer who makes the purchasing decision.
Trainers and technical support
Trainers and technical support personnel may seem like logical options to use as user proxies. They spend their days talking to real users, so they must surely know what the users themselves want, right? Well, unfortunately, if you use a trainer as your user proxy, you will end up with a system, that is, easy to train.
Similarly, if you use someone from technical support, you will end up with a system that is very compatible and easy for supporting. For example, someone from technical support can assign a low priority to advanced features that he anticipates will increase support work.
While ease of training and compatibility are good objectives, it’s most likely that they aren’t what a true final user would prioritize.
System analysts and business analysts
Many business analysts and systems analysts make good user proxies because they have a foot in the world of technology and the other one in the processes and operation domain. An analyst who can balance this background and who strives to talk to real users is often an excellent proxy user.
A problem that some analysts present is that they prefer to think about a detected problem instead of research about it to solve it. Another problem that I’ve encountered occasionally is they tend to spend too much time on project’s upfront tasks.
What to do without users (or almost)?
When access to users is limited
When the team needs it to work with a proxy, it’s important to be very quick and establish with the sponsors, the proxy and management with sufficient authority, the fact that it’s necessary to establish a small “advanced post” group formed by real users, in order to evaluate any initiative, theory or assumption, and achieve validated knowledge as soon as possible.
Be efficient and transparent by scheduling constant meetings of maximum established duration and at a constant pace to facilitate meetings and minimize external obstacles, making it clear from the beginning that the objective is to identify, write and prioritize user stories or requirements.
If there are really no users available
When a user is not really available and must use a user proxy, a valuable technique is using more than one user proxy. This helps to reduce the likelihood of building a system that only satisfies one person’s needs. When you use more than one user proxy, make sure use different types of proxy. For example, combine a domain expert with someone from marketing instead of using two domain experts.
If you are developing software that competes with other commercial products, you can use the competitive products as a source of some user stories or requirements. What features of the products of the competition are mentioned in the reviews? What features are discussed in the online newsgroups? Are the features discussed because they are too complex to use or because they are very useful?
Another technique that you can use when you’re working with a user proxy instead of real users, is releasing the product as soon as possible. Even whether you call it preliminary version, beta, early, etc., try to put it in the hand of the users as soon as possible and identify inconsistencies between the user proxy thoughts and the actual real users, so you also get validated knowledge. Even better, once the software is in the hand of one or more of the first users, you now have a communications path to these real users and can use that to talk with them about upcoming features.
Can you do it your self?
When you can’t find or access to a real user, don’t fall into the trap of thinking you know the users’ mind and you don’t need or you can ignore a user proxy. Even if each type of user proxy has some kind of inconvenience that makes her/him less desirable than a real user, most developers have even more deficiencies to pretend to be a real user.
In general, developers don’t have marketing knowledge that allows them to understand the features’ relative value, they don’t have the same amount of contact with the customer as the salespeople, they are not domain experts, etc.
Do you know another type of user? Do you have a different opinion about the proxies presented here?
*Sorry about my English, I’m not natural speaker :p. Don’t be grumpy and help me to improve 😀
Other links of interest:
Agile’s Origins and Values
The Agile Team ApproachIf you want to know more, these are some recommended books:
Any help is welcome to help us keeping this effort alive! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
