A muchos les parece que Yandex es una gran corporación monolítica con procesos estrictamente regulados, pero esto no es así. Estamos constantemente buscando nuevas direcciones, comenzando nuevos proyectos y probando nuevos mercados. El servicio de consultas en línea con el médico Yandex.Health es una de las startups internas clásicas.
Llegué a liderar el desarrollo de Health en un momento en que el servicio todavía era una página con un resumen del wiki interno. En esta publicación quiero compartir los enfoques de desarrollo que hemos desarrollado durante dos años y medio de trabajo en el servicio.
Descargo de responsabilidad:Una startup tiene sus propias características. Nuestra tarea principal es hacer el número máximo de experimentos por unidad de tiempo y emitir características del producto a la mayor velocidad posible. Al mismo tiempo, debemos mantener la calidad del producto a un nivel tal que no sea una pena.
[Un lugar para una llama sobre la falta de conciencia de algunos] . Observo que una alta velocidad de entrega de características implica, entre otras cosas, mantener un código de bastante alta calidad. De lo contrario, el producto tarde o temprano se atraganta con errores.
Todos los puntos a continuación se ven afectados de alguna manera, casi todos tienen un caso de la vida real.
Código de Calidad y Arquitectura
- Minimizamos el tiempo para llevar características a producción mientras mantenemos una calidad aceptable.
- Cualquier tarea implica dos soluciones: rápida y correcta. Para cualquier característica, pensamos en ambas opciones para que sea posible actualizar la solución rápida a la correcta, haciendo que el trabajo innecesario de "eyección" sea mínimo. Después de lanzar una solución rápida, buscamos un momento y entendemos si se necesita la correcta.
- Críticamente A menudo, la diferencia horaria entre "resolver de la primera manera que obtienes al anotar una muleta" y "resolver de manera hermosa y precisa" es de diez minutos. Por eso, siempre pensamos antes de escribir.
- Si hay una opción entre optimización menor y legibilidad / arquitectura, elija el segundo. Dos milisegundos no resolverán nada, y con este código todavía tenemos que vivir y mantener.
- Estamos pensando en el futuro. El futuro cercano es más importante que las perspectivas distantes. Si la decisión puede hacerse difícil (leer "largo") y flexible, o simple, pero clavado, vale la pena hacerlo y luego refactorizarlo según sea necesario. Es mejor pasar un día en una solución simple ahora y un mes en una posible refactorización en un año, en lugar de dos semanas ahora (sí, esto es lo que se llama deuda técnica). Es importante que valga la pena discutir tales decisiones con el equipo. Solo, puede evaluar incorrectamente la probabilidad de expansión de esta función en un futuro próximo.
Nueva tecnología
Las nuevas tecnologías son geniales, usémoslas. Pero nuestro producto no es un campo de pruebas. Si desea aplicar un nuevo algoritmo o tecnología, esto puede hacerse bajo las siguientes condiciones:
- la tecnología tiene un beneficio tangible (optimización, calidad de la arquitectura, código, escalabilidad, y todo esto realmente debería ser necesario y no exagerado);
la tecnología se adapta normalmente a la pila actual (no es necesario que escriba parte de los servicios en Go si todo el código está escrito en Python); - la tecnología no degrada la calidad de la arquitectura y la legibilidad del código (esto es subjetivo, por lo tanto, se discute con el equipo);
- Implementar y soportar una nueva tecnología (incluida la búsqueda de nuevos desarrolladores) no lleva más tiempo que trabajar en el marco de la tecnología actual. Nuevamente, todo depende del beneficio esperado y se discute con el equipo;
- cualquier nueva tecnología se discute con el equipo: si es genial, entonces es correcto que todos la usen, si no realmente, entonces una discusión grupal le permite comprenderlo rápidamente;
no es necesario que implemente de forma independiente los algoritmos ya implementados en bibliotecas listas para usar (excepto en el caso de que se trate de una pequeña parte de un gran marco y no tenga sentido arrastrarlo todo para una solución). - Si hizo algo genial y conveniente, comparta la solución con el equipo (o mejor, dentro de Yandex).
Comunicación
- Discutimos la solución juntos. Cuanto más compleja y crítica sea la funcionalidad, más importante será dicha discusión. Si a alguien no le gusta la solución, nos convencemos hasta que se llegue a un acuerdo. O el tiempo de discusión no excederá un tiempo razonable.
- Si no fue posible ponerse de acuerdo, la última palabra depende de la cabeza. Tenemos una democracia razonable, no el Sejm polaco del siglo XVII . Al mismo tiempo, el líder recibe una gran desventaja en el karma y debe experimentar sufrimiento moral. Y ciertamente no usar este derecho con frecuencia.
- Una vez que hemos decidido, hacemos lo acordado. Incluso si estoy totalmente en desacuerdo. Ninguno "Sé mejor que todos estos expertos en productos cómo hacer un servicio, así que haré lo que creo que es necesario"
- "No en el producto, no hecho". Todos siguen sus propias tareas. Si la función está lista para la prueba, debe asegurarse de que se implemente en la prueba. Si está lista para su lanzamiento, debe asegurarse de que ingrese al producto lo antes posible. Las personas responsables de la formación del lanzamiento no siempre recuerdan cada característica. Siéntase libre de recordarla. [Un lugar para una llama sobre la distribución de la responsabilidad entre los roles en un equipo.] .
- Es necesario girar la cabeza. Si la tarea parece extraña, incomprensible o demasiado larga, esto se debe decir clara y en voz alta al gerente responsable. Y haga esto hasta que tenga una comprensión clara de por qué todo debería ser así. Sucede que las preguntas correctas formuladas en el momento adecuado ahorran semanas de desarrollo.
Gestión del tiempo
- Si la tarea no se ajusta dentro de un tiempo razonable, debemos hablar en voz alta. No debe sentarse y cortar la tarea durante varios meses con una evaluación de tres días. Si arrastra mucho, entonces algo va mal. Quizás haya un malentendido en la producción o hayamos subestimado la cantidad de trabajo. En cualquier caso, tales tareas deben volver a discutirse (y como resultado, a veces posponer o incluso enterrar).
- Los problemas que surgen deben resolverse de forma independiente. Pero si está claro que el proceso se está retrasando, asegúrese de hablar sobre ellos y pedir ayuda a sus colegas. Quedarse varios días en el estado "Tengo que hacer todo yo mismo y no distraer a mis camaradas" es muy malo.
- Nadie mira a qué hora llega y sale cada uno de nosotros hasta que tenemos éxito, y nuestro régimen no comienza a interferir con el trabajo del equipo. Pero no es necesario sentarse por la noche solo porque no tiene tiempo para hacer algo. Si esto se convierte en un hábito, entonces el problema es más profundo: planificar, reevaluar las propias habilidades, etc. Si bien el desarrollador trabaja horas extras por la noche (y como resultado, todo está a tiempo), las posibilidades de que alguien vea y resuelva este problema se reducen considerablemente.
- Sucede que necesitamos lanzar una función importante en la fecha acordada (o tan pronto como sea posible). En este caso, vamos a trabajar en horas extras. Además, el líder recibe una gran desventaja en el karma y debe experimentar sufrimiento moral. Y ciertamente no aprovechar esta oportunidad a menudo. Tal tiempo extra es compensado. [Un lugar para una llama sobre horas extras y compensación] .
Pecados mortales
Esta es una sección separada. Aquí intenté enumerar lo que creo que está mal y es perjudicial cuando trabajo en equipo. Cada uno de los artículos tiene su propio peso. Algunos hablan de problemas muy grandes, otros no son tan críticos. Entonces, lo que debe evitarse por todos los medios:
- Trabajo, sin incluir la cabeza: "Me dijeron que hiciera, lo hice". Cada miembro del equipo debe comprender la esencia de la función que realiza y su impacto en el producto.
- Lanza características que no se desinflan en el producto con las palabras "Hice todo". Lo que hacemos debería funcionar en la producción. Si bien la función no está en producción, no está lista.
- Acepta hacerlo de una manera, y luego hazlo en silencio a tu manera. Lo anterior ya era sobre "Sé mejor que nadie lo que es mejor". Pero una vez más, recordar que esto es malo no hará daño.
- Apriete las características importantes, profundizando en la discusión de problemas raros y poco realistas, pero potencialmente posibles. Si en un tiempo razonable no puede descubrir cómo solucionar un problema menor y rara vez reproducible , simplemente estamos de acuerdo en cómo vivir con él.
- No expreses los problemas a tiempo, tratando de resolverlo todo por ti mismo (generalmente de noche). Tal heroísmo solo conduce al fracaso de los términos, fatiga y un sentimiento de subestimación: "Estoy haciendo proezas aquí, ¡pero también me critican por mi lento trabajo!"
- Es doloroso reaccionar a las críticas al código y aclarar la relación. Incluso si un colega dice que el código es coprolit regular (“¡reescribamos todo!”), Trate esto con comprensión y discuta por qué piensa eso. Para usted personalmente, esto no es menos útil que para el servicio en su conjunto.
- Ve a la persona. Al criticar un código o solución, criticamos solo el código o la solución, pero en ningún caso la persona que lo escribió o sugirió. Dado el párrafo anterior, no tengas miedo de criticar. Es mejor un tiempo razonable para discutir con los colegas que enviar una decisión infructuosa de pinchar.
Total
Aquí puedes escribir más sobre un millón de cosas. Pero cuanto más corta es la publicación, más fácil es leerla
hasta el final , y realmente lo espero. Y sí, no tomo las críticas dolorosamente (con la condición de que no te vuelvas personal;). ¡Entonces hablemos!