Recomendaciones en Linkedin para un perfil técnico

Recomendaciones en Linkedin para un perfil Técnico

linkedin

Un compañero me dijo que a penas tenía tiempo  que si le podía ayudar a recomendarme lo haría con gusto.

Para ayudarle he escrito estos cinco pasos. En los pasos 1-3 describo qué escribir y en el paso 0 y 4 cómo acceder a recomendar en Linkedin:

Paso 0: Abrir en otra pestaña/ventana Linkedin:

Tan solo debes hacer click en este link y seguir los pasos que adjunto en la captura de pantalla:

https://es.linkedin.com/in/navasantonio

Pasos a seguir para recomendar en Linkedin

Pasos a seguir para recomendar en Linkedin

Paso 1 – Relación profesional

Comienza comentando brevemente qué relación profesional has tenido. Si has sido compañero, jefe…

Paso 2 – Comentar cualidades positivas

A continuación lanza algunas de las cualidades que has observado en el tiempo que has compartido con él. A continuación lanzo una lista en español e inglés de posibles virtudes para decir en una recomendación de Linkedin:

  • Experiencia comercial en productos técnicos.
  • Resolvió con soltura incidencias de diferentes tecnologías (.Net, WPF, Android, Agresso).
  • Desarrolló con soltura la creación de nuevas funcionalidades en los productos en los que tuvo que trabajar (C#, MVC . Net, WPF, Android, Agresso).
  • Proactivo, se gestiona él mismo las tareas y prioriza la resolución de las mismas.
  • Transmite una positividad que facilita el crear un ambiente de equipo positivo que contribuye a que seamos más productivos.
  • Con muchas ganas de trabajar como miembro del equipo y arrimar el hombro para asegurarse de que el equipo tiene éxito con sus compromisos.
  • Actitud proactiva positiva, dispuesto a meterle mano a cualquier problema y dispuesto a resolver las cosas incluso cuando están fuera de su área de experiencia directa.
  • Interés intenso por expandir sus propios horizontes y aprender nuevas habilidades tanto como tener cuidado por hacer las cosas bien.
  • Trabaja duro para acabar sus tareas dentro del plazo estimado.
  • Probada experiencia siendo proactivo, independiente, y siendo capaz de trabajar en equipo eficientemente.
  • Buena disposición para adquirir nuevas habilidades incluso fuera de las esperadas.
  • Le gusta trabajar con metodologías ágiles Scrum y sus herramientas Bitbucket, Sourcetree, Jira..

Y ahora las mismas recomendaciones pero en inglés por si queréis poner la recomendación en inglés:

  • Excellent written and verbal communication, problem solving, multi-tasking, and analytical skills
  • Skilled individual with full software development life-cycle experience, and excellent knowledge of both .Net fundamentals and C#, Android…
  • Positive proactive attitude, willing to turn their hand to any problem, and willing to work things out when they fall outside their area of direct expertise
  • Eager to work as a member of a team and pitch in to ensure the team succeeds with its commitments
  • Interested in expanding own horizons and learning new skills as well as caring about doing things well
  • Proven experience of working to deadlines
  • Experience of Incident, Problem, and Change Management
  • Proven experience of being proactive, independent, and being able to work effectively within teams.
  • You like work with Agile methods like Scrum, and tools Bitbucket, Sourcetree, Jira…

Paso 3 – Despedida positiva

El mundo es muy pequeño. Lo más seguro es que os toparéis más de una vez en alguna relación de negocios o profesional. Finaliza con una despedida positiva de deseos en su futuro profesional. Es mucho más agradable crear buen karma en tu vida y recuerda que si es un friki cuidado, algún día puede ser tu jefe que estamos en su era ;-).

Paso 4: Imprescindible. Recomiéndame:

Ahora no tienes excusa quien quiera escribirme una recomendación en Linkedin se lo agradeceré.

Tan solo debes hacer click en este link y seguir los pasos que adjunto en la captura de pantalla:

https://es.linkedin.com/in/navasantonio

Pasos a seguir para recomendar en Linkedin

Pasos a seguir para recomendar en Linkedin

Un abrazo y nos vemos en el camino compañeros.

Antonio Navas

Requerimientos en el Software IX-iv – Requerimientos escritos – Story maps

Story Maps

Los Story Maps son usados para organizar los requerimientos y ayudar la estructura del proyecto. Presenta el product backlog de una manera visual con la historias de usuario agrupadas dentro de específicas categorías funcionales. Priorizando las historias de usuario a través de múltiples categorías proveyendo una visión de lo que está siendo desarrollado.

Story Maps se compone de un conjunto de columnas. Cada una de ellas representa una categoría agrupando historias de usuario. Dentro de cada columna las historias de usuario son priorizadas de la más a la menos importante. Esta estructura intenta mostrar la prioritaria historia de usuario para todo el proyecto.

Storymap

Ejemplo:

ejemploStorymap

Requerimientos en el Software IX-iii – Requerimientos escritos – Product Backlog

Product Backlog

El product Backlog es un conjunto de funcionalidades del software que el product manager planea desarrollar para un producto a lo largo del proyecto. Es una forma de organizar el trabajo priorizando y planeando las tareas dentro del proyecto.

Para crear el product backlog:

  1. Después de realizar las historias de uso, las funcionalidades deberán ser plasmadas en una lista. A cada historia de usuario se le deberá asignar un único identificador simple como una secuencia de números o nombres.
  2. Priorizar las historias de uso y funcionalidades. Ayudará al cliente a identificar lo que quiere y sus necesidades. Y ayudará al equipo a identificar qué es lo más importante y a qué habrá que dedicarle más recursos conociendo cuál es el core del proyecto.
  3. Empezar a planificar el proyecto usando prioridades y puntos de referencias.
  4. Historias de usuario son agrupadas en Units of Works para ser completadas en un determinado intervalo de tiempo (sprints).
  5. Product Backlogs es flexible. Un sprint en proceso no debería cambiar pero una vez se le enseñe al cliente este debe evaluar el trabajo hecho y añadir o modificar historias de usuario o requerimientos o cambiar la prioridad de las historias de usuario o requerimientos.

Requerimientos en el Software IX-ii – Requerimientos escritos – Test de Aceptación

Test de Aceptación

Los test de aceptación son usados para verificar si un requerimiento ha sido alcanzado satisfactoriamente.

Ejemplo:

Como cliente quiero ser capaz de pagar con tarjeta de crédito así podré elegir el método más conveniente para realizar un pago.

Para dar como bueno el criterio de aceptación se debe fragmentar en varios pasos que se podrán chequear para dar como aceptable el criterio por ejemplo:

  1. Insertar la tarjeta en un lector de tarjetas.
  2. Insertar el PIN de la tarjeta.
  3. Confirmar que el pago ha sido aceptado.

Este criterio de aceptación será como válido si los tres puntos se cumplen.

Requerimientos en el Software IX-i – Requerimientos escritos – Historias de Uso

Historias de Uso

Las técnicas que hemos visto hasta ahora para expresar los requerimientos han sido las siguientes:

  • Casos de Uso.
  • Mockups.
  • Storyboards.
  • Historias de Uso.

Las Historias de Uso expresan los requerimientos siendo fácil escribir, leer y evaluar.

historiadeuso

Como cliente, quiero ser capaz de identificar qué restricciones tengo en mi dieta, así poder conocer qué puedo pedir cuando compro comida.

Product Management – Ahorrar y generar dinero en la empresa

La figura del product manager dentro de una startup o una multinacional

software product management

A continuación hago una reflexión de la figura del product manager dentro de una empresa.

Desde mi propia experiencia el product manager en el producto/s de una empresa lo:

  • Concibe
  • Planifica
  • Desarrolla
  • Testea
  • Lanza al mercado

Lleva al mercado productos para satisfacer a los clientes y alcanzar los objetivos de negocio. También quita del mercado los productos que no se ajusta al mercado o del que no puede conseguir beneficios.


  1. Ayuda a las ventas
    1. Esfuerzos en identificar oportunidades de mercado y aproximarse con estrategia y planes de acción.
    2. Adquiriendo clientes, conociéndoles y enfocándose en desarrollar productos orientados a cubrir las necesidades de éstos.
    3. Formando, coordinando y dirigiendo a los equipos de ventas apoyándoles en sus dudas técnicas y a llevar a cabo las tareas de disciplina en ventas para evitar la frustración y conseguir los objetivos a través de llevar a cabo con estrategia las tareas y planes de ventas.
  2. Reduce riesgos del fallo en el producto
    1. Lleva a cabo investigación de mercado y conocer al cliente para detectar sus necesidades antes del desarrollo del producto.
    2. Objetivo: Asegurar que el producto cubre las necesidades y no se desarrolla funciones innecesarias evitando desperdicios de tiempo-dinero en productos inservibles.
  3. Mejora la comunicación efectiva dentro de los departamentos de la compañía.
    1. Identificar problemas del mercado.
    2. Encontrar la mejor solución con el equipo técnico.
    3. Llevarla al mercado a tiempo.
    4. Colaborar entre los equipos (Técnico – Marketing – Ventas) mejorando la productividad y uso de recursos de la compañía.
  4. Calidad
    1. Analizar recogiendo datos en el uso del producto por cliente interno y externo.
    2. Testeo continuo para conseguir calidad.
    3. Mejorar productos y conseguir beneficios.
    4. Si el producto hace falta renovarlo irá soportado de suficiente información.
  5. Negociación con los clientes importantes.

Conclusión: El product manager deberá combinar con sus esfuerzos el engrasar la maquinaria de los equipos de la compañía, equipos de Ventas, Marketing, desarrollo técnico y managers, combinando sus esfuerzos para reducir gastos innecesarios y generar el mayor beneficio con los productos a la compañía.

Requerimientos en el Software VIII – Storyboards

Storyboards

Storyboards en software son representaciones visuales de una interacción con el producto software.

Existen dos tipos de storyboards ambos sirven de ayuda para discutir e indagar requerimientos entre los clientes y entre el equipo de desarrollo para comprender qué se pretende crear.

Storyboards tipo 1

Tipo comic, describe paso a paso los distintos momentos en los que se interactúa con el producto.

requerimientos8 Storyboards

Usos potenciales:

  • Asegura que todo el equipo de desarrollo sepa de qué se está hablando, centra la atención.
  • Estimula el identificar posibles features que mejoran al producto.
  • Asegura la claridad del objeto de uso del producto.
  • Se puede usar en las demos de marketing.

Storyboards tipo 2

Este segundo tipo de storyboards combina los mockups con el flujo básico de los casos de uso con objeto de mostrar cómo el usuario final interactúa con el interfaz de usuario del producto en detalle.

requerimientos8 Storyboards 2

Usos potenciales:

  • Ayuda al equipo de desarrollo a diseñar los requerimientos.
  • Ayuda a identificar qué podría complicarse en exceso.
  • Asegura al equipo de desarrollo estar atentos a las funcionalidades y el sentir del producto.
  • Sirve de ayuda a la hora de crear los manuales de usuario.

requerimientos8 Storyboards 2b

 

Requerimientos en el Software IV – Comprendiendo al cliente para redactar los requisitos

Comprendiendo al cliente para redactar los requisitos

Eschuchar al cliente

Comprender al cliente realizándole las preguntas adecuadas y escucharle es de vital importancia para poder obtener las verdaderas necesidades del cliente y redactar con ello correctamente los requisitos.

Otras fuentes para obtener requisitos son:

  • Entrevistas con los usuarios finales.
  • Estudios de mercado para ver la viabilidad del producto.
  • Observar cómo un usuario final interactúa con el producto o un mock-up de este.
  • Viendo otros productos similares (estudio de la competencia).

En reuniones con el cliente se le debe ayudar a gestionar las expectativas transmitiéndole:

  • Los objetivos realistas del producto.
  • Tiempos de ejecución.
  • Qué se hará y qué no se hará en el producto.
  • Priorizar los requerimientos. Qué se hará antes y qué después.

En la reunión con el cliente se debe ser asertivo:

  • Abierto a las ideas y perspectivas del cliente.
  • No aceptar las ideas pasivamente, también hay que sugerir ideas y perspectivas pero no forzar agresivamente nuestro punto de vista.
  • Se debe proporcionar al cliente una estructura en la conversación sobre los requerimientos para ayudarle a organizar sus pensamientos.
  • El cliente puede tener un conjunto de ideas pero no conocer qué es técnicamente factible o ser de difícil comprensión para los usuarios finales. Para ello debemos ser capaces de captar el porqué el cliente tiene ese conjunto de ideas y la mejor manera de comprenderlo es preguntar al cliente cómo ven ellos a un usuario final interactuando con el producto y por qué. Para posteriormente proponerles ideas y explicarles porqué ciertas ideas pueden no funcionar explorando las posibles limitaciones en diferentes escenarios.
  • Es de vital importancia que el cliente esté informado y que comprenda sus opciones. Pero al final es él el que debe tomar la decisión de los requisitos que desea que sean cumplidos.

Después de la primera reunión con el cliente:

  • Mostrarle Mock-ups y prototipos producidos desde la primera reunión.
  • Mostrarle la lista de requerimientos con un identificador único para facilitar el hablar de ellos.
  • Preguntarle qué le gusta del producto, qué no le gusta y qué quieren.
  • Revisar con el cliente de nuevo los requerimientos.
  • Preguntarle por la elección del diseño.
  • Que diga abiertamente todo el feedback que desee.