¿Por qué un programador tiene una pasantía en la cocina? Una conversación con Dodo Pizza sobre gemba, .NET y apertura.



Ya se sabe mucho sobre Dodo Pizza. El negocio de la compañía está entrelazado con una red de servicios tecnológicos, escribieron un libro sobre su historia, la pila de tecnología y la arquitectura del sistema están pintadas en el sitio, a un par de clics de la página principal. Con calma y abiertamente, discuten incluso la fakapy más desagradable para el público.

Todo esto es genial y se crea un toque romántico: parece que, por defecto, es genial trabajar con Dodo Pizza. Pero estábamos interesados ​​en entender si esto es realmente así.

¿Hay apertura en los excesos y dificultades? ¿Cómo se relacionan las personas con las cámaras abiertas en las cocinas? ¿Son las tecnologías solo un adorno de marketing? Al final, mientras los gigantes de TI solicitan a los desarrolladores un suministro de galletas y cafeteras personales de por vida, Dodo promueve el trabajo periódico en la cocina para sentir el dolor de los clientes y empleados comunes.
Dodo Pizza recibió una calificación promedio de 4.7 de sus empleados en My Circle y una recomendación promedio de 98%. La empresa es valorada por tareas interesantes, crecimiento profesional y excelentes relaciones con colegas.

Le preguntamos a fillpackart sobre todo esto, y Alexander Andronov, STO Dodo Pizza nos respondió.



¿Por qué la tecnología de pizzerías?


- ¿Cómo abrió Fedor una pizzería tan rápido después de trabajar como cajera ordinaria?

- No hay nada complicado. Él tomó y lo hizo. Para esto, no se necesita preparación adicional ni dinero extra.

- Pero en mi opinión es bastante caro.

- Es caro si abres una pizzería en algún lugar de Moscú, dentro del tercer anillo de transporte. Allí necesita 15-20 millones de inversiones. Y la primera "Dodo Pizza" se abrió en las profundidades de Syktyvkar, en el sótano. No había restaurante, solo funcionaba para la entrega y la inversión era pequeña.

Esto no es nada complicado. Tenemos historias cuando los socios recolectaron tarjetas de crédito de todos los bancos, cobraron, y con este dinero fueron a construir una pizzería.


Fedor Ovchinnikov, fundador de Dodo Pizza.

- ¿Fue la idea enfocarse en la tecnología de inmediato?

- Sí, el desarrollo comenzó aproximadamente un mes después de la apertura de la primera pizzería. El propio Fedor no es desarrollador: encontró a dos tipos que leyeron su blog y respondieron a la idea. Hubo un ciclo de desarrollo muy corto para llevar todo inmediatamente a la producción. Esto lo sobornó y comenzaron a trabajar juntos.

- Cuando las personas se sienten atraídas por la tecnología, la industria alimentaria, el negocio de los restaurantes a menudo están lejos de la vanguardia entre sus intereses. ¿Por qué pizza?

- La pizza es un producto bastante simple y comprensible. Donde quiera que esté, en cualquier país diga la palabra "pizza", y todos sabrán de qué se trata. Este es un producto bien preparado desde el punto de vista comercial. Está claro cómo hacerlo, hay mucha experiencia de otras compañías, un montón de modelos de desarrollo. Solo tómalo y hazlo.

Pero el énfasis en la tecnología comienza a obtener ganancias, no cuando tienes una o dos pizzerías, sino cuando habrá miles de ellas. Luego, puede crear personalización, puede administrar una red de pizzerías en línea, descubrir al instante qué salió mal y solucionarlo.

- Entonces, ¿todavía no obtienes ganancias de la tecnología?

Hablando globalmente, las ganancias apenas comienzan a emerger. Por ejemplo, consolidamos todos los canales de venta, tenemos un único sistema de centro de llamadas. Ni Dominos ni Papa John's tienen esto. Allí debe llamar a una pizzería específica que le traiga su pedido.

"Pero eso no es así".

Eso es asi. Solo tienen una orden en un teléfono común. Pero luego le devuelven la llamada de una pizzería específica si, por ejemplo, no hay ingredientes para su pedido. Tenemos el mismo sistema, cuando recibimos una llamada al centro de llamadas, sabemos con certeza qué pizzería cumplirá el pedido, qué tiene con el resto, los correos. Toda la información de los empleados en línea.


Oficina de Dodo Pizza en Syktyvkar.

- Ok ¿Qué es más importante para usted: pizza o tecnología?

- Son inextricables. Sin pizza, la tecnología no tiene sentido. Pero sin tecnología, simplemente habría otra pizzería, y probablemente no podríamos escalar así.

Esto es lo mismo que preguntar: los desarrolladores o los ingenieros de control de calidad son más importantes.

- (Phil fillpackart ) Desarrolladores, por supuesto

"Estás equivocado". La pregunta no puede responderse sin ambigüedades. Todo depende de la hora que sea. Cuando todo ya está desarrollado, ¿quién es más importante? Llorarás si no tienes suficientes ingenieros de control de calidad. Se verán obligados a convertirse en desarrolladores.

Y exactamente la misma tecnología y pizza no existen sin la otra.

- ¿Las tecnologías no funcionan aquí, como una máquina Goldberg? Media hora, varios mecanismos hacen todo tipo de milagros, de modo que al final el martillo cae y rompe una nuez.

- Puede parecer a primera vista. A veces, explicar a los desarrolladores lo que hacemos es un problema. Su primera reacción: “¿Qué hay allí, un sitio para vender pizza para hacer? 1C para configurar? "

Desde el punto de vista de trabajar con un cliente y administrar pizzerías, todo esto generará ganancias con el crecimiento global. En el negocio clásico, existen factores estrictamente definidos que afectan el éxito de cada pizzería: el costo de la mano de obra, el costo de los ingredientes, los ingresos, los gastos para atraer clientes y la retención. Debe mantener exactamente tantos ingredientes para vender con precisión todo el menú para que nada salga mal y no tenga que ser engañado.

Los costos laborales están relacionados con los pronósticos de demanda. Si comprende que en algunas horas tendrá algunas ventas, y en otras horas, otras, puede crear un horario automático para que la gente cambie. En su mayor parte, esto es lo que está sucediendo con nosotros, pero hasta ahora estamos pronosticando esto en modo semi-manual. Pasemos a la automatización completa con el tiempo.

Los sistemas de información están comenzando a ayudar en cada etapa, se están optimizando a tal punto que sin tecnología se vuelve imposible.

- En el caso de Zume Pizza , ¿no es un exceso de tecnología?

Esta parece ser la primera experiencia cuando un robot hace pizza. Tal industria está al comienzo del desarrollo. Los primeros autos también fueron muy caros.

Cuando la tecnología se desarrolle con el tiempo, cuando los robots sean lo suficientemente confiables, cuando las piezas se vuelvan baratas (si esto sucede), se verá. No sé cuántos años llevará un proyecto piloto. Pero sí, bien puede desarrollarse. O tal vez no.



Dodo es


Pocos meses después de la apertura de la primera pizzería, apareció Dodo IS, el sistema de información en el que se basa el trabajo de toda la empresa. Este es un conjunto de microservicios recopilados en una infraestructura. Es utilizado por gerentes, clientes, cajeros, cocineros, compradores misteriosos, empleados de centros de atención telefónica, eso es todo.

Convencionalmente, Dodo IS se divide en dos partes. El primero es para clientes. Esto incluye un sitio web, una aplicación móvil, un centro de llamadas. El segundo está dirigido a socios franquiciados. Ella ayuda a administrar pizzerías. A través del sistema pasa facturas de proveedores, gestión de personal, turno de personas, nómina automática, capacitación en línea para el personal, certificación de gerentes, sistema de control de calidad y compradores misteriosos.

Es decir, es un sistema grande desde la oscuridad de herramientas y servicios completamente diferentes. A medida que el sistema creció y se desarrolló junto con la red Dodo, es difícil creer que su arquitectura resistiera todos los desafíos de la escala.

- (Phil) El sistema es complicado. ¿Hubo muchos errores de cálculo en la arquitectura realizados desde el principio?

Todo comenzó con un monolito. Ahora hemos llegado al hecho de que debemos verlo gradualmente, no soporta la carga.

En general, esta es una pregunta compleja y doble. Nunca se sabe lo que habría pasado si no hubiera permitido un error de cálculo incorregible al principio. Luego hiciste algo más rápido, lo llevaste al mercado más rápido, eliminaste una característica banal y nunca sabrás la respuesta, ¿cómo hubieran sucedido las cosas sin ella?

Teníamos un viejo sitio web de Dodo Pizza. Fue muy difícil hacer cambios en él, y aparecieron dos opciones: desarrollar evolutivamente la existente o reconstruir su arquitectura. Como resultado, el sitio fue completamente descartado y se escribió uno nuevo. La semana pasada, todos los países fueron transferidos por completo.

Pero no puedo llamar al antiguo sitio un error de cálculo. Si no se hubiera hecho rápidamente, quizás la Dodo Pizza simplemente no hubiera existido.


Oficina de Dodo Pizza en Syktyvkar.

- (Phil) ¿Quedan las decisiones equivocadas que actualmente están interfiriendo?

- Tomamos periódicamente tales decisiones, y a veces tenemos que cortarlas. Por ejemplo, teníamos nuestro propio bus para enviar mensajes entre diferentes sistemas. Su segunda reencarnación ahora ha terminado. Hicieron uno, no funcionó, decidieron rehacerlo, hicieron el segundo. Ahora todo está bien. Todo lo que nos molesta, cambiamos bastante rápido.

- (Phil) Cualquier cambio en las grandes empresas lleva una eternidad. Y dices que todo es rápido contigo. ¿Cómo se hace esto?

Hay muchos factores. Nuestro desarrollo está al alcance de la mano del cliente. Cuando hay un problema, es muy fácil para nosotros llegar al negocio y obtener todas las respuestas. La clave es la comunicación.

Por otro lado, si los socios comienzan a escribir masivamente que necesitan tal o cual cosa en el sistema, y ​​si escriben no uno o dos, sino muchos socios grandes, es muy probable que esto ingrese rápidamente en la cartera de pedidos. Tal vez incluso mover todas las demás tareas e ir a la cima. Tal ejemplo fue la apertura de una pizzería en Bielorrusia. Esta tarea apareció y cambió a todas las demás. Es decir, tenemos una gestión rápida de prioridades y existe la capacidad de mover tareas.

- (Phil) Todos dicen que la comunicación es muy importante para ellos, que el desarrollo se comunica estrechamente con las empresas. Pero, de hecho, incluso cambiar la inscripción en el sitio lleva tres meses. Y hay más ejemplos de este tipo.

Aquí debemos hacernos la pregunta de por qué no funciona, por dónde no pasan las comunicaciones. Mucho puede depender del tamaño de la empresa. Si necesita pasar por veinte aprobaciones con diferentes gerentes, y ninguno de ellos quiere tomar una decisión, entonces será lento. Nuestras decisiones se toman rápidamente.

Si hay una solicitud de cambio en una dirección determinada, la persona simplemente va inmediatamente al producto, allí toma una decisión y comienza a tomarla. Habla con la persona y comprende que puede cambiar completamente las prioridades de la aplicación móvil.

Otro punto está relacionado con las prioridades. Quizás cambiar la inscripción en el sitio no sea tan importante como cómo lidiar con las tareas de recibir facturas de los proveedores. Y luego parece que cambiar la inscripción lleva tres meses. No, ella no lo acepta, podemos donarle para otras tareas.


Oficina de Dodo Pizza en Syktyvkar.

- (Phil) ¿Por qué no tienes miedo de asumir tanta responsabilidad?

Las personas que se responsabilizan, nadie las castigará. Y cuando no tienes miedo, cuando confían en ti, te permites correr riesgos.

En las grandes empresas, a pesar de que todos dicen "somos amigos", existe una rivalidad entre los departamentos. Para nosotros, cualquiera señala calmadamente cualquier deficiencia, todos darán su opinión, se lo dirán. Todo se hace con el apoyo de la comunidad interna.



¿Qué tecnologías hay detrás de las pizzerías?


- (Phil) En 2011, .NET no era una opción obvia. ¿Por qué lo elegiste a él?

- Nuestros chicos solo sabían .NET

- (Phil) Exhaustivamente. ¿Cómo te cambiaste a .NET Core?

Todos los nuevos servicios se realizan en Core. Veinticinco por ciento fueron transferidos de los viejos. Combinamos la transferencia con el corte del monolito, y esto se hace en varias etapas. La primera es una llamada a ASP.NET Core con un marco completo. Allí ya será más fácil migrar a Core, pero este sigue siendo un marco completo que funciona en IIS. Todo está separado con su base, y ahora tienes instancias físicamente separadas. Luego traduzca a .NET Core

El siguiente paso, traducimos esto en Kestrel. Y luego contenedores a Coober. Pero ahora, con nosotros, Coober no está listo para una implementación completa, lanzamos solo los servicios menos críticos allí. Si algo sale mal y se caen, sobreviviremos. Pero la API móvil aún no se puede incluir en Coober, todavía no nos hemos preparado para esto.

- (Phil) En la pila, parece que estás tratando específicamente de estar a la moda. ¿Por qué necesitas esto?

- Esto no es solo una tendencia por el bien de la tendencia. Hay dos factores Cuando escribes sobre nuevas tecnologías, siempre es más fácil para ti atraer personas, porque las personas quieren trabajar con cosas nuevas. El segundo factor es una economía banal. Los servidores Linux son más baratos, Kestrel soporta más carga que IIS, trabaja con mayor precisión con subprocesos.

Es decir, la elección de la tecnología está económicamente justificada.

Cuando se decidió crear un nuevo sitio, se organizó una gran batalla entre React y Angular. Fue muy largo, pero ganó React. En la oficina administrativa, la historia es más triste y antigua. Sigue habiendo gachas de diferentes versiones de Angular: había la primera, la segunda y, en algún lugar, incluso la cuarta. Y entre la primera y la segunda diferencia hay cielo y tierra. Si la migración del segundo al cuarto es relativamente simple, entonces la migración del primero al segundo es cómo descartar y reescribir todo.

Todavía había jQuery y aún permanece. Pero básicamente decidimos que estamos haciendo todas las cosas nuevas en React. Estamos tratando de arrastrar lentamente a los viejos también.

Gradualmente, todo el back office se cubrirá de React. Angular se ha ido por completo, jQuery también.


Oficina de Dodo Pizza en Syktyvkar.

- (Phil) ¿Tienes JavaScript o TypeScript?

TypeScript Fue más fácil para el equipo trabajar con tipeo estático.

- (Phil) ¿La elección de .NET estaba justificada estratégicamente?

Cada vez que me hago esta pregunta, y cada vez que no sé la respuesta. Nada nos impide hacer nuevos servicios en otra pila. En la arquitectura de microservicios, esto funciona bien. Naturalmente, todo el aprendizaje automático, por ejemplo, se basa en Python.

Por otro lado, entiendo que .NET (especialmente .NET Core) es una tecnología tal que es hora de invertir en ella. En primer lugar, es relativamente nuevo. En segundo lugar, digamos que Microsoft ahora está pagando deudas. Hace lo que se suponía que debía hacer hace diez años, pero todo salió mal.

Y desde el punto de vista del lenguaje en sí, C # es hermoso, maravilloso e impresionante. Hay una gran cantidad de azúcar sintáctico y construcciones claras que se pueden explicar de una manera lógica normal.

Hay dificultades para buscar desarrolladores. La industria sigue siendo muy negativa sobre .NET. Probablemente, si estuviéramos en la pila de Java, habría muchos más desarrolladores.

- (Phil) Cita de tu vacante, “y sí, no tenemos WCF. Para nada. ¿Por qué no vino a ti así?

Solo recuerdo casos muy raros cuando una persona trabajaba con WCF no muy profundamente y estaba bien. Pero sé, y yo mismo me encontré en la práctica, cuando el WCF fue solo un disparo en la pierna, ni siquiera desde una escopeta, sino desde un lanzagranadas. WCF es una tecnología increíblemente increíble, cuando necesitas soportar un montón de protocolos diferentes, cuando no tienes suficiente http, cuando no tienes suficiente intercambio REST json, WCF pasará y te dará un montón de opciones sobre qué hacer.

Pero en nuestro caso, es como un cañón en gorriones. Y es bastante complicado de configurar, el más mínimo descuido en las configuraciones, y se obtienen errores del nivel "en algún lugar de los modelos algo no se aguantó, descifre".

- (Phil) Si Microsoft desaparece y deja de admitir su tecnología, ¿cuánto le costará? Todo: sin .NET, sin Azure.

- Sobre Azure. Nuestra dirección global es la contenedorización en Coober, y de hecho no importa dónde comience. La recuperación de emergencia y el cambio a otra plataforma lleva unas cinco horas. Desde el punto de vista del sistema operativo, perderemos de cuatro a cinco horas de trabajo.

Y si .NET desaparece repentinamente, los desarrolladores no irán a ninguna parte. Pasar a otra pila, por supuesto, nos ralentizará, pero no creo que tenga un impacto significativo. Entendemos que los nuevos servicios deben hacerse en alguna otra pila (Java, Go, Python, no importa), solo comenzamos a rehacer gradualmente y respaldar el trabajo operativo de lo que es ahora. Quizás esto ralentizará el desarrollo en algunos países, porque habrá menos tiempo para los nuevos.

El problema es que todo se vendrá abajo, no. Todo continuará funcionando, pero se desarrollará más lentamente. No creo que otras compañías tengan esto de manera diferente.



Qué hacer en la oficina, qué es remoto y cómo comunicarse con la empresa


- ¿Dónde está tu oficina de desarrollo?

- La oficina principal en Moscú. Hay una oficina en Syktyvkar, una pequeña oficina en Nizhny Novgorod, y varias personas a distancia en diferentes ciudades. Son ingenieros que tenemos 57 personas, pero hay un entendimiento de que no son suficientes, y planeamos crecer hasta 250 personas.


Oficina de Dodo Pizza en Syktyvkar.

- ¿Te importa, en la oficina o remotamente?

- El proceso principal responsable del desarrollo empresarial es LeSS. Implica que todas las personas deben estar ubicadas en un solo lugar. Pero entendemos que este proceso no será el único para nosotros.

Donde hay un alto grado de incertidumbre, por ejemplo, en China, debe realizar un experimento tras otro e intentar encontrar un modelo de negocio que funcione. Y hay un equipo dedicado que hace esto. Se compone de desarrolladores en Moscú, Nizhny Novgorod y Wuhan (China).

Por lo tanto, queremos reunir gente en Moscú para una parte del trabajo, de modo que todos estén ubicados físicamente aquí, y podamos entregar la otra parte de forma segura al control remoto, e incluso a equipos externos. Según las estimaciones generales, el 60-70 por ciento del trabajo se realizará en Moscú.

- ¿Qué puedo darle al control remoto?

- Por ejemplo, un sistema de control de calidad es un proyecto relacionado con un cronograma de inspección de restaurantes. Existe un bajo grado de incertidumbre, el proceso se resuelve y puede entregar el proyecto a equipos externos.

O ahora existe la aplicación móvil principal para realizar pedidos, pero los chicos del desarrollo móvil aún tienen algunas solicitudes diferentes. Por ejemplo, no hace mucho tiempo estábamos haciendo una impresora de marcado. Cuando los empleados cortan, por ejemplo, tomates en una pizzería, deben ser etiquetados. La vida útil es de 24 horas, y después de eso no se pueden usar.

Anteriormente, las marcas eran manuales. Pegaste una pegatina, escribiste con un bolígrafo (¡bolígrafo!) A qué hora lo hiciste, pero siempre son imposibles de leer. Esto condujo a errores de marcado permanentes. Y esto es un desastre.

¡Te cansarás de etiquetar estos tomates! Y solo cuando el desarrollador mismo vaya a la pizzería, sentirá y comprenderá todo por su cuenta. Fui realmente malo cuando etiqueté ocho Lexans de tomate. Confundido rápidamente.



Los chicos del desarrollo móvil también fueron a trabajar a una pizzería y sintieron todo el dolor. Hicieron una impresora con una aplicación móvil, que automáticamente te marca cuando finaliza la fecha de vencimiento, solo pégala y tómala. La cultura de proximidad al cliente funcionó muy bien.

Pero este proyecto no es la clave para el equipo de desarrollo móvil. Solo se puede hacer en una breve pausa entre los proyectos principales. También podemos dar tales cosas al control remoto y a equipos externos.

- ¿Cómo distribuyen estas 57 personas la montaña del trabajo entre ellas?

- Básicamente, tenemos equipos de características, es decir, equipos que pueden tomar casi cualquier parte del sistema. No tienen apego a ciertas cosas. Solía ​​haber, y esto condujo a problemas de falta de competencias.

— , Azure, .

— ?

— . , , , - , .

— -. . , ( — ) .

, , .

, . , , .


« » .

— ? .

, . . . , , .




— , ?

— , . , , .

IT — . - .

— ?

— . , . , . , — . .

, . , , , , , . — .



— , ?

— - « ». , . , .

?

, . , . , « , - », , , .

, : « . , ». . , , .

— ?

— . , , — , . , . , , , .




— ?

— - , , , , . , , .


« » .

— , ?

— , . , . . , , .

, .NET. . . , — . , , , — , , «».

, — . - , , , . , , .

— () ?

— . — , QA , , . .

. , . , , .

, , .

— () , , ?

— , . 99% - . , , .

, . , , . , .

— , , ?

— — . , . . , , .

. , «», , . , , , , .

, , : «, ». . , , -.


« » .

— , ?

- si.

— , .

— . , . , : « Google Facebook ». . , , . .

— ?

- No




— ?

— .

— ?

- por supuesto! — , . , , , . , — . — . , .

. , .

— , , , ?

— ?

— .

- si. .

— ? .

— ? , «, , , ». . - , .

, . - , . . , , , .


« » .

— — . ? , , , , .

— , . , , - . — . - , , , .

. - , . - -. . . , , . .

, . . , , « , ». , . . .

-2. , , .

, , . , , . , — , — ?


« » .

— ?

- No : « » « -» . .

. , -, , . , .

, — . , .

Source: https://habr.com/ru/post/es433168/


All Articles