En cada uno de nuestros seis equipos de desarrollo, la cartera de pedidos está programada para unos dos años, teniendo en cuenta la casi inevitable refactorización, arreglos, características y productólogos de la lista de deseos. En el interior, todo puede ir de acuerdo con las prioridades, y algunos bloques grandes se vuelven más importantes, luego se eliminan y luego se agrega algo nuevo allí. Pero siempre hay un entendimiento de dónde cavar en los próximos meses.
Además de un montón de ventajas, este sistema tiene dos desventajas obvias:
- Esto es cursi y aburrido, y el aburrimiento no es lo que nos motiva a escribir código.
- Se están acumulando muchas hipótesis que, de acuerdo con el proceso habitual, caen en algún lugar al final del trabajo atrasado, pero cada una de ellas puede dar un resultado rápido. O tal vez no. Algunos de ellos son interesantes.
En modo normal, es difícil analizar estas hipótesis, porque necesita la interacción de un científico de producto, una persona de negocios (generalmente un gerente de línea) y un par de personas más de otros equipos de desarrollo. Es decir, cuando tiene dos horas libres, aún no puede hacerlo. Y dado que a menudo hacemos dinero pisoteando el camino en los negocios hacia nuevas interfaces y nuevas características, la prueba de hipótesis es la vida.
Primero, reservamos tiempo dentro de la oficina e hicimos el flujo de trabajo general. Resultó que si verificas lo más rápido posible, obtienes soluciones promedio. Para mejorar la calidad, debe salir de la rutina general.
Por lo tanto, ya hemos viajado tres veces a una ciudad extranjera y hemos trabajado allí.
¿Por qué se necesita esto?
Si ya ha leído publicaciones sobre cómo acumulamos
deuda técnica y qué hacemos con ella, y sobre lo que el
desarrollador necesita saber
sobre los negocios , sabrá que de vez en cuando tenemos docenas de hipótesis sobre qué para hacer Aproximadamente la mitad son de desarrolladores, en parte de historias de otros departamentos y experiencia cambiante para uno mismo, en parte de un científico de producto, fundador, o simplemente debido a la fase de la luna.
A continuación, determinamos la lista de personas que se necesitan para resolver la mayoría de estas tareas. Como regla general, este es un equipo de desarrollo específico (direcciones aéreas, ferroviarias, recorridos, trenes, aventuras o análisis), un ingeniero de infraestructura, un par de personas de una empresa (para obtener una imagen general y una evaluación de la consistencia financiera), un analista para transferir de aquí para allá, personas de otros equipos .
El proceso básico se veía así: tome un vendedor, desarrolladores, diseñadores, analistas y líderes. Justo en la oficina, una vez a la semana organizamos una discusión del sprint sobre hipótesis. Se asigna un día cuando el trabajo se realiza solo bajo hipótesis. Si la solución de un problema sale en seis horas, entonces se interrumpe y deja este proceso. La tarea es lanzar la beta oblicua en seis horas. Se prueban diez hipótesis por semana para todos los equipos.
Esto funciona bien, pero las limitaciones que viste anteriormente.
El desarrollo completo toma lo que el gerente de proyecto está contento con base en los resultados beta.
Consultamos con el gurú de la gestión de proyectos, y varias personas diferentes dijeron a la vez que deberían establecerse fuerzas especiales dentro de la empresa, es decir, aquellos que están específicamente involucrados en la promoción de hipótesis rápidas. En algún lugar esto se llama un grupo de desarrollo, en otro lugar. El punto es un hackathon permanente para un equipo.
Suena lógico, pero no se implementa rápidamente: es necesario reunir expertos en seis áreas diferentes del negocio y privar a los principales equipos de los más interesantes, porque todas las pasas del pan son recogidas por estas "fuerzas especiales".
Se necesitan "Fuerzas especiales" porque si no se asigna el 100% del tiempo del desarrollador para resolver el problema, resulta peor. A juzgar por la experiencia. Pero no pudimos hacer eso.
Tomamos TRIZ y sugerimos que debemos centrarnos una parte del tiempo en hipótesis, a tiempo parcial en el trabajo principal "a largo plazo". ¿Qué nos impide hacer esto, como hicimos en la oficina? Contexto, distracciones y regulaciones constantes, empleo constante de los miembros del equipo y comentarios largos.
Así es como la gente ideó hackatones. Eliminan todas las restricciones de oficina y dan tiempo para concentrarse. Solo un hackathon es una historia voluntaria gratuita, y generalmente se trata de capacitación. Los desarrolladores pasan el sábado porque pueden aprender algo nuevo y no es mejor hacer su trabajo.
Por lo tanto, decidimos realizar un experimento e ir a Estambul con un equipo de 14 personas.
Experimento de Estambul
¿Por qué Estambul? Necesitábamos una ciudad que cumpliera con los requisitos alimentarios:
- Obtenga un vuelo rápidamente sin retrasos frecuentes (el otro lado del planeta no encaja, las islas con un clima impredecible no encajan).
- El acceso es relativamente económico (Islandia generalmente no es adecuada).
- La ciudad es más atractiva que Moscú en esta época del año (no a todos les gusta salir de la oficina por el simple hecho de viajar, Omsk no es adecuado, pero los habitantes de esta ciudad me perdonarán).
- Hay muchas cosas interesantes por las que no tienes que viajar lejos (Noruega no es adecuada).
- El equipo unánimemente quiere ir a esta ciudad.
Hicimos una lista de ciudades adecuadas y discutimos con todos. Era importante que todo fuera revisado a la vez, y este no era un deber terrible.
Decidimos que tendríamos una gran reunión en Estambul a cambio de dos días libres (pagados), pero compramos los boletos nosotros mismos. Esta lógica se adapta a todos, porque esta es una oportunidad para acoplar estos dos días libres los fines de semana y obtener unas mini vacaciones a mediados de año.
Bueno, al final, seguimos siendo personas apasionadas por los viajes.
En el lugar alquilaron una casa grande cerca del centro.
Quien hizo Uno de los desarrolladores pasó su tiempo personal organizando todo esto. No estoy seguro de si fue porque quería estudiar el proceso de los viajes de negocios (simplemente lo promocionamos) o simplemente porque quería ayudar a todos.
Durante una semana advirtieron a la
cocina que necesitábamos bocadillos en el camino, pero la carga de alimentos disminuiría en los próximos días.
Trabajamos el viernes por la mañana, como siempre, a las 12:30 nos fuimos al aeropuerto, a eso de las 15 en punto - salida, a las 18 en punto estábamos allí.
Llegamos a la casa, ya había Wi-Fi desplegado allí, tenía material impreso conmigo. Todo con laptops corporativas. Comimos, nos sentamos y discutimos las cosas principales. De hecho, fue un debate sobre qué y cómo hacer en el producto. Es decir, decidimos qué debería incluir en la cartera de pedidos. Quería discutir hipótesis "rápidas", y el destino, y las prioridades de las tareas a largo plazo.
Al día siguiente llegamos a este formato: el jueves apareció una lista de problemas problemáticos (además de los que ya se conocían), así que hablamos de ellos casi todo el viernes. Se encontraron dos lados: uno era para la hipótesis, el otro estaba en contra. Luego organizaron un duelo, que todos los demás juzgaron. Es decir, casi como un juicio de hipótesis: el fiscal tira por lo que no necesita hacer, y el abogado tira por el éxito y la alegría. Es cierto, entonces no pensaron en cambiar al fiscal y al abogado, y este es un procedimiento estándar en tales debates.
El horario de trabajo era este: elegimos el peor momento para caminar (en Estambul es la mitad del día), ponemos la reunión allí. Mañana y tarde son gratis, pero almorzamos juntos, esta es una oportunidad para comunicarnos. En ese viaje, algunas personas aún lograron pequeñas tareas, es decir, no pudieron apagar por completo el proceso habitual. Por otro lado, no diría que tomó un tiempo considerable.
Un ejemplo de hipótesis de rodaje
Los autobuses no tienen un boleto electrónico legalmente aprobado. Esto nos entristece increíblemente, porque los pasajeros deben imprimir el formulario en casa o imprimirlo en una impresora en la estación de autobuses (lo que a veces se convierte en un problema y otras veces es banal por una tarifa). Russian Railways ha aceptado durante mucho tiempo el registro electrónico en casi todas partes, los aviones le imprimen en el aeropuerto sin preguntas en las terminales o en la recepción (y en algunos lugares no necesita imprimir). Y en los autobuses en algunos lugares todavía los años 70 de la URSS.
En la práctica, hay estaciones progresivas que solo muestran el ticket desde el teléfono. Todavía tienen estos datos en la declaración por su parte, y solo necesita mirar allí y ver el documento de la persona. Pero hay estaciones conservadoras y aquellas que simplemente están "en contra de Baba Yaga". Y todas las estaciones tienen sus propias formas de tales formas.
Desde el punto de vista de la estación, un boleto electrónico es un desarrollo. La seguridad de la estación aumenta, es más conveniente para el controlador y el conductor, las operaciones se aceleran, se ahorra papel y los jóvenes no hacen preguntas.
De todos modos, en un autobús, uno o dos pasajeros olvidan los boletos y, en cualquier caso, se restauran de los datos de la estación. Pero en algunos lugares encuentran muchas fallas. La práctica ha demostrado que si un pasajero comienza a escandalosamente, lo deja entrar. Si se va en silencio (la mayoría de las veces pensionistas), ya tenemos que entender la situación.
Lo primero que hicimos fue asignar estaciones conservadoras y, al comprar boletos, notificamos por separado al pasajero que es necesario imprimir un boleto: no se les permitirá sin él.
Luego decidimos hacer una "lista blanca" de las estaciones de autobuses donde funciona el registro electrónico. Verificación triple: retiro de pasajeros, llamada de nuestro cliente secreto, pregunta directa a la gerencia de la estación.
Si la legislación va a la zaga de la realidad en términos de permitir boletos electrónicos, pero hay una solución alternativa a través de la recuperación de boletos de acuerdo con la estación, entonces ¿por qué no automatizar y hacer su propia muleta rápida y conveniente?
En general, encontramos tales estaciones y etiquetas marcadas en el sitio.
La verificación se repite de vez en cuando.
En el proceso, resultó que hay estaciones que llegaron a tal esquema, pero en realidad no se lo contaron a los pasajeros. Los integradores de esto también van con alegría.
Luego dimos pequeños bonos en el sistema a aquellas estaciones que tienen esa marca para que haya un incentivo económico para hacerlo.
Como resultado, resultó que combinamos rápidamente (bueno, en realidad no a nosotros, pero ellos mismos combinaron, en particular, con nuestra herramienta) un buen número de estaciones y operadores que ya realizan el registro electrónico.
Es decir, no puede simplemente sentarse y esperar hasta que todo aparezca legislativamente, sino descubrir cómo hacerlo mediante programación. Y eso es todo. Necesitábamos un grupo de desarrolladores, gerentes, una persona en comunicación con socios y un diseñador.
Cual es el resultado?
Pérdidas de la primera experiencia:
- Menos entradas y alojamiento.
Beneficios:
- Casi como unas vacaciones a mediados de año.
- Durante los siguientes seis meses, decidieron todas las preguntas a la vez.
- Pudieron comunicarse específicamente con el equipo. Por alguna razón, la oficina no funciona de esa manera.
- Cosas difíciles de medir a nivel de sensaciones: las relaciones en el equipo han cambiado.
- Observamos nuestro propio producto desde el exterior: después de todo, utilizamos nuestras herramientas (y otros equipos) todo el tiempo, presentamos varias características "sobre la marcha".
- Simplemente condujeron en un viaje, lo cual es lógico para una empresa que se trata de viajes.
- Los camaradas "superiores" enseñaron a los "Junees" a pensar racionalmente, no solo en el desarrollo, sino también en la planificación del día. Esto es muy insignificante, pero se siente la transferencia de experiencia.
- Pudieron atraer a los desarrolladores remotos a la comunicación, lo que generalmente no era suficiente.
Nezhdanchiki:- Aprendimos que las dos chicas tenían problemas catastróficos con la orientación al área: estaban perdidas, las encontramos, nunca las soltamos. Esto casi interrumpió la sesión de trabajo.
- El desarrollador que asumió la organización mostró una manifestación de liderazgo situacional. No muy esperado, eychar y el líder estaban sorprendidos.
- Descubrimos que nuestra colega Misha toma buenas fotos. Tomó la cámara, se quitó todo y luego presentó impresiones en papel. Por la memoria.
Es muy difícil sincronizar en viajes, y esto aún no se ha convertido en un proceso. Pero creo que lo hará, porque los beneficios son obvios. Ahora usamos ambos enfoques: asignamos el tiempo de los equipos en la oficina para analizar hipótesis y ocasionalmente salir. Se necesitan más salidas para determinar la visión y las diferentes tareas, y "no molestar" en la oficina para romper las hipótesis en el modo de hackathon personal.
Se seleccionaron y probaron siete hipótesis en la primera iteración, de las cuales tres mostraron resultados. Por ejemplo, en dirección a los autobuses.
En la etapa de entrada de datos, los pasajeros comenzaron a mostrar una placa con la inscripción "Última compra de boletos para este vuelo hace N minutos". En la versión móvil, A / B mostró + N% en ventas, en el escritorio no hay resultados significativos. Ampliamos el formulario de búsqueda en la versión móvil de las páginas con el cronograma; como resultado, obtuvimos + NN% en ventas. Recibimos datos de los clientes para poder devolverlos. En asuntos vacíos, comenzaron a recopilar correos electrónicos de usuarios para enviar autobuses, si aparecen en la dirección, hay cientos de ellos por semana. Según las preferencias del usuario, recopilamos ofertas en el boletín. Los resultados Impacto: 91–93%. Ventas de quienes abrieron la carta: + NN, 3% (significativo). Pero! La gente viaja en autobuses en las mismas direcciones, lo que significa que las predicciones son las mismas. Hasta ahora, resulta que los correos siempre serán los mismos. Pensaremos cómo diversificar.
En ese momento, había tareas típicas en la cartera de pedidos, por ejemplo, una rutina de este tipo:
- Ejecute dos integraciones con estaciones de autobuses.
- Actualiza tres integraciones actuales.
- Integrar los transportistas de autobuses lituanos.
- Haga conectores para su cuenta de 16 operadores.
En general, funciona, pero nos encantaría escuchar su experiencia de trabajar "aislado" desde la oficina y viajar a algún lugar si los tuviera.