Get best of the week

Cómo se organiza Amazon

Al igual que muchas otras empresas estadounidenses, la organización de flujo de trabajo de Amazon se basa en principios básicos cuyo objetivo principal es ayudar a los empleados a tomar la decisión correcta en función de los valores de la empresa. Hablamos con un gerente de producto en Amazon, quien habló sobre qué principios sigue la compañía, cómo ayudan con las tareas y qué procesos atraviesa el equipo cuando desarrolla un nuevo producto. A continuación, dejamos un enlace a un video con una entrevista completa.

Misión amazónica, visión y principios


Según tengo entendido, la misión de Amazon es ser la empresa más orientada al cliente del mundo. Todos los productos en los que trabaja la corporación se desarrollan con el objetivo de hacer primero el producto para el cliente y luego aumentar sus ventas.

Hay 14 principios en los que vive una empresa y se utilizan en todos los procesos de trabajo. Estos principios son bastante básicos, no son nada especial. Se guían por el lanzamiento de un nuevo producto, durante las entrevistas o al dar retroalimentación a un colega. No están obligados a memorizar, pero cuando trabajas en una empresa, si quieres, no quieres, comienzas a seguir estos principios.

Muchos de ellos se separan entre sí. Por ejemplo, como Think Big y Bias for Action. Uno dice: "Piensa globalmente" y el otro dice: "Actúa, no planificas". De hecho, hay muchos principios que entran en conflicto entre sí. Pero este es todo el punto. Si los empleados estuvieran obsesionados con el principio Think Big, entonces todos extenderían los plazos. Y si solo se cumpliera el Bias for Action, rápidamente llevarían a cabo proyectos pequeños y no pensarían en proyectos grandes.

Muchos dicen que la cultura amazónica es más exigente. La gente viene aquí para trabajar, estudiar y desarrollarse. Y cuando se cansen, ve a Microsoft.

Esto se debe a que Amazon es una empresa más dinámica y de rápido crecimiento. Estamos tratando de crecer en diferentes direcciones. Pero el modelo de negocio de Boeing y Microsoft no ha cambiado en muchos años. Google tiene lo mismo: el motor de búsqueda sigue siendo su principal fuente de ingresos.

Se alienta a Amazon a generar constantemente nuevas ideas. Siempre hay muchos proyectos en el proceso de desarrollo. Cuando termina el trabajo en un producto, inmediatamente todos cambian a otro. Y al mismo tiempo, los objetivos altos para cada proyecto siempre se establecen dentro de los departamentos.



Proceso de desarrollo de producto


Lo primero que debe hacer antes de establecer la tarea es probar la hipótesis. Para esto, se utiliza MVP o MLP. En base a estos conceptos, se compila un documento grande, que luego es considerado por todo el equipo. Dos cosas deben destacarse en el documento:

¿Cómo resolverá el proyecto el problema de los clientes? El documento tiene 1 página para explicar sucintamente la idea y transmitir su valor.

¿Qué preguntas pueden hacer los consumidores sobre el producto? Y preguntas técnicas: ¿cómo vamos a monetizar? ¿Dónde comprar equipos técnicos? ¿Quién será el contratista? Todo debe describirse en el documento en el formato de preguntas y respuestas.

Si entendemos que a todos les gustó la idea, se desarrolla. El gerente de producto compila una lista de requisitos, desglosándolos en la etapa de lanzamiento de Agile. Todo está organizado de tal manera para probar paso a paso una cosa y obtener retroalimentación.

Lo más importante en el equipo es no esperar las instrucciones. Si viene a la cabeza con algún tipo de problema, entonces ya debería tener una solución. Y el gerente solo puede dar retroalimentación, ya sea que haya encontrado una buena solución o no.

El equipo siempre tiene un horario para los días en que se completará. Cada semana, los empleados se reúnen para discutir tareas. Los mostramos en un tablero con los estados: verde, amarillo y rojo.

Verde significa que todo está bien, no se requiere atención a la tarea. Amarillo: algo salió mal, pero sabemos cómo solucionarlo. Por ejemplo, planearon terminar el proyecto antes del 1 de mayo, pero hubo un problema que intentaremos resolver antes del 1 de mayo. Y rojo: algo salió mal y todavía no sabemos cómo cumplir los plazos.

Después de eso, cada desarrollador muestra demos con el trabajo realizado. Durante tales reuniones, el gerente de producto tiene la oportunidad de dar su opinión y cambiar la ruta de la tarea. Por lo demás, la oportunidad de pedir consejo a sus colegas, si no está claro cómo resolver uno de los problemas. Los informes semanales del equipo respaldan la cultura ágil cuando todos intentan lanzar algo para liberar, en lugar de intentarlo durante todo un año.

Cuando el proyecto está listo, es aprobado por el gerente de producto y enviado a la siguiente etapa: prueba. La compañía tiene probadores internos que verifican si la función se rompe, y un grupo de probadores beta, que a su vez dan su opinión. Después de sus pruebas, el desarrollo se lanza en un par de días. Y aquí es donde termina el trabajo en la tarea.



Organización de los procesos de trabajo en la empresa.


Scrum, un método para priorizar tareas durante las próximas 2-3 semanas, para un sprint.

Sprint es una ejecución tan corta en la que usted dice: "Bien, las próximas diez semanas haremos estas 10 tareas. Y trabajaremos solo en ellos y nada más ". Esto tiene sus pros y sus contras. Por un lado, no te distraen otras tareas. Pero tienes que hacer adiciones constantemente, y van a correr bastante.

No existe tal cosa en la programación que simplemente se sentó y comenzó a escribir código. Primero, el gerente de producto recopila todos los requisitos, describe las funciones del nuevo producto. Entonces todo va al diseño. Los programadores se sientan y describen lo que deberán hacer en función de los requisitos, por ejemplo, integrarse con el sistema, crear un marco específico, etc. La tercera etapa es el código en progreso, donde el empleado ya está sentado y comienza a escribir código. Luego prueba. Y la última etapa es el lanzamiento.

Y aquí Kanban es una metodología en la que establece límites para cada etapa. Un grupo de "requisitos" no puede tener más de 3 funciones. Hasta que transfiera cualquiera de los requisitos al diseño, no puedo agregar nuevas tareas.

Es decir, el flujo de tareas está regulado. Si tiene más desarrolladores, puede ampliar las tareas. Las ventajas de la metodología es que es flexible. Menos: la priorización puede cambiar constantemente a diferencia de Scrum. En cualquier momento, puede incluir una tarea que no existía antes.

Ambos enfoques se relacionan con la metodología ágil. Su significado es que siempre se divide un lanzamiento grande en pedazos pequeños y se libera con la mayor frecuencia posible para no hacer lo que el usuario no necesita.

En Scrum, evaluamos cada tarea en puntos. No puedes medirlos con nada, es más un valor relativo. Por ejemplo, una tarea es 4 puntos más que la tarea estimada en 2. Dichos puntos le permiten ver cuánto ha cerrado el desarrollador su tarea.
En Kanban, esto es más complicado.

Nuestra otra regla es llevar solo 3 tareas al trabajo. Si el equipo tiene 10 desarrolladores, entonces todos están trabajando en estas tareas, nadie puede tomar una nueva. Porque si cada desarrollador asume una tarea, que lleva 2 meses de tiempo de desarrollo, entonces solo habrá 2 lanzamientos por mes, respectivamente.

Es por eso que hay restricciones en al menos 3 tareas, cada una de las cuales tiene 3 desarrolladores. Además, si alguien es liberado, entonces no puede asumir un nuevo proyecto. Debería ayudar a sus colegas a completar el resto de las tareas establecidas para el sprint. Y solo después de que se lanzó el proyecto, puede tomar nuevas tareas.

More articles:


All Articles