♠️ 📟 🤩 Startup dentro de la corporación 👩🏾‍🤝‍👨🏼 🎥 🍑

Hola, mi nombre es Andrey Vanin y estoy desarrollando y lanzando productos de corretaje y fintech. Hoy es exactamente un año desde que trabajo en BCS, donde en un equipo de ocho personas estamos desarrollando el proyecto fintarget.ru.

A continuación se muestra una (no) gran historia sobre cómo implementar una startup en una gran empresa, lanzarla al mercado y, al mismo tiempo, no agotarse entre toneladas de memorandos y aprobaciones.

imagen

Introducción

Olvídate de todos los manifiestos ágiles y crea un ambiente de trabajo cómodo si quieres lograr resultados. En la gestión de proyectos desesperados, no es la presencia de la oficina de PlayStation y los rituales obligatorios de scrum lo que se destaca, sino las ambiciones y la motivación personal del equipo.

Si su desarrollador quiere ser el mejor, no jugará air hockey y no le importa si hay un baño en la oficina (hay un spoiler). Si su proyecto quiere lograr respeto, aprenderá a caminar sobre su cabeza y resolver cualquier problema, ya sea otro trabajo inconcebible de reemplazar una silla rota o la necesidad de coordinar un proceso que no está allí.

Si el proveedor front-end tiene una hipoteca pendiente, ofrézcale una opción, ya sea PS4, o más un bono por la misma cantidad. Su tarea no es ser una niñera en el proyecto, sino garantizar el resultado de tal manera que tanto el equipo como el cliente estén satisfechos. Incluso si no es posible.

En sus marcas

Me uní a la empresa a principios de abril de 2019. Dos desarrolladores se sentaron en la oficina, un cliente y medio gerente de proyectos que nunca antes habían estado involucrados en proyectos de desarrollo. Tuvimos que desarrollar rápidamente un sistema desde cero, que intentaron hacer tres o cuatro veces antes, pero en cinco años nadie pudo llevar al mercado un producto sensato y fácil de usar.

En mi escritorio había una impresión de una presentación de cinco diapositivas: cómo estará todo bien, cómo se verá, arquitectura teórica, cuánto dinero debería traer y cuánto dinero costará. Y ni una palabra sobre el producto, ni una sola mención de unidades relacionadas, ni un solo proceso y comprender cómo debería despegar todo esto.

Pero se anunció el plazo, que se lanzará en septiembre. Y nos sentamos a trabajar.

Doble pivote

La primera versión del producto implicaba la creación de una infraestructura interna sin su propia solución front-end. Se asumió que el producto se presentará en el estante de la aplicación móvil, y mis dos desarrolladores solo admitirán el backend y la logística de los flujos de información. Este enfoque garantizó el fracaso del proyecto ya en junio, ya que en la dirección comercial paralela, el equipo de aplicación comenzó a sufrir cambios significativos y su cartera de pedidos hasta el final del año fue muy nebulosa. Y decidimos hacer un producto MVP en el frente web actual de la empresa. Este fue el primer turno.

La solución más simple en esta situación es externalizar el diseñador UX y el diseñador de diseño, dibujar diseños de lápiz, obtener el diseño y entregarlo al desarrollo. Pero solo las startups independientes pueden hacerlo. Somos una startup dentro de una gran empresa, donde el diseñador no puede pagar en efectivo, y todo el trabajo frontal debe hacerse a través de la coordinación con el marketing y los abogados. Fue más difícil, pero no detuvo el desarrollo del núcleo, por lo que entramos en marketing.

imagen

Casi de inmediato, surgió el problema de la estratificación de la imagen general: el marketing no sabía lo que estábamos haciendo técnicamente, y los desarrolladores no entendieron cómo debería haber sido todo. Antes de las vacaciones de mayo, abrimos confluencia y nos sentamos a describir las pantallas.

Hasta mediados de mayo, una comprensión detallada de cómo debería funcionar el producto solo existía en mi cabeza y en unas cincuenta páginas que describían los algoritmos y las pantallas. Fue un gran riesgo (¡el truco fue hecho por profesionales! No repitas, ¡es peligroso!), Pero al mismo tiempo, cada miembro del equipo sabía qué hacer y estaba cargado de trabajo con dos meses de anticipación.

El proyecto se desarrolló, coordinando la próxima versión de la arquitectura y la interacción de los sistemas, el líder del equipo entró y comenzó a elegir el código, y el tercer desarrollador (contratado conmigo el mismo día) había estado entendiendo los mecanismos de integración durante casi un mes. Y esa fue la parte más difícil. La compañía tiene dos docenas de sistemas, de los cuales seis necesitamos integrar.
En algún momento, quedó claro que el líder del equipo designado no encajaba en el ritmo del equipo y tenía que ser reemplazado. El segundo desarrollador ocupó su lugar, y para la vacante vacante tomamos un programador con antecedentes de un candidato de ciencias físicas. Mirando hacia el futuro, diré que nos salvó.

Sin embargo, casi de inmediato se hizo evidente que tampoco podremos encajar en el circuito web interno, y el cliente acordó la única solución de ahorro en ese momento: creamos nuestro propio frente de producto basado en la web con nuestro equipo de marca y soporte. Dentro del departamento, anunciamos apresuradamente una competencia por el nombre del producto y finalmente elegimos la opción que fue expresada por el primero, ya que había un buen dominio en mi alcancía personal, y no había nada mejor para que todos votaran y fueran creativos. Entonces apareció la marca fintarget.ru. Y ese fue el segundo giro de llave.

Acerca del equipo

Millones de libros sobre gestión del desarrollo le ofrecen plantillas estándar de trabajo en equipo y procesos estándar, olvidando que cada equipo es único y requiere un enfoque individual.

Muchos factores pueden influir en el trabajo y la comunicación en un equipo: edad, estado civil e incluso preferencias musicales. Sin embargo, casi nunca los productos prestan atención a esto y, por regla general, se centran en factores secundarios: la ubicación y el tamaño de la mesa, las persianas de las ventanas, los auriculares con ventilación y otras pequeñas cosas que "no son molestas".

Las estrellas se unieron y logramos encontrar una cadena de relaciones en la que todos y cada uno siempre tenían algo de qué hablar además del trabajo. Y cuando ha establecido comunicación, puede lidiar con calma con la distribución de roles.

En la etapa de depuración de los procesos del equipo, hemos formado un esquema tan híbrido que no cabe en ninguna de las plantillas existentes.

Primero , abandonamos al analista. Absolutamente. El rol del analista se distribuye entre el líder del equipo y el propietario del producto, y los detalles de los procesos se modernizan y arreglan durante la prueba del servicio. Esta es la mejora continua del producto del que a los defensores de Edge les encanta hablar.

En segundo lugar, hemos borrado la línea entre los poderes del gerente de producto en la persona del cliente y el propietario del producto. Dos empleados realizan dos funciones en línea, sin delimitar la autoridad y sin temer la responsabilidad en la toma de decisiones. Fue especialmente interesante ver a los desarrolladores que vieron cómo el propietario y el gerente discutían con voz ronca sobre CJM o el diseño de la página. Esto, por cierto, influyó mucho en la participación del equipo.

En tercer lugar , en la etapa de desarrollo del kernel, abandonamos por completo los sprints con una acumulación de trabajo dura y utilizamos un enfoque iterativo basado en el refinamiento y la adición de funcionalidad durante el desarrollo. ¿Recuerdas cómo se cargaron las imágenes JPEG en el navegador a principios de siglo? Esa es la misma forma en que desarrollamos el núcleo del producto.

Cuarto, delimitamos (a la fuerza) estrictamente la funcionalidad de los desarrolladores. Se asignó un desarrollador de microservicios separado para cada sector, que era responsable solo de su segmento. Tenemos cinco segmentos de este tipo en el proyecto: integración con sistemas internos, integración con sistemas de intercambio, algoritmos de productos de kernel, OpenAPI y el frente.

Y quinto , todos los recursos del gerente de proyecto de nuestro departamento que teníamos estaban destinados únicamente a administrar equipos externos responsables de finalizar los sistemas con los que necesitábamos integrar, e implementar todos los procedimientos para coordinar e integrar una startup en la infraestructura de la compañía.

Durante tres meses, este héroe del proyecto gastó más de mil quinientos servicios diferentes, describió y documentó una docena de nuevos procesos, y fue él quien en la práctica refutó la teoría popular de la imposibilidad de hacer nuevas empresas dentro de grandes empresas.

Este enfoque nos permitió planificar el grupo de tareas, fijar todos los requisitos para MVP y, en general, cuando quedó claro que el mecanismo funcionaba, yo, como oununer, me fui de vacaciones casi con calma. Era julio, y como está escrito en una famosa novela de gestión de proyectos, cuando se definen todos los procesos, se conocen las tareas y los plazos, solo hay que mirar.

El 1 de agosto tuvimos el núcleo del sistema ensamblado, se realizó casi todo el trabajo preparatorio, se ensambló la versión beta de OpenAPI, se dibujó el frente y se inventó y aún quedaba una semana para pulir los algoritmos y esperar a que el front-end funcionara, que era "solo para" recolectar todo Este es un MVP que funciona.

Árboles de eventos

Es posible recopilar la infraestructura del proyecto de inicio en un ciclo de prueba cerrado tanto como lo desee, pero el proyecto nunca despegará sin la integración con los sistemas clave de la compañía. Este es el principal problema de trabajo de las startups dentro de las corporaciones: más del 80% de los proyectos mueren sin encontrar la oportunidad de integrarse y cumplir con todos los requisitos y regulaciones corporativas.

Existen varios sistemas de este tipo en el negocio de corretaje: sistemas de comercio y contabilidad, buses de integración, CRM, un catálogo de servicios y una docena más de sistemas y mecanismos que están estrictamente regulados y controlados por los servicios de seguridad de la información.
La integración sin exageración fue la prueba más seria para el proyecto y el equipo, y tuvimos que matar un total de aproximadamente tres meses-hombre de trabajo en él.

Un papel clave en este proceso fue jugado por la regla "primero rompa todas las reglas". Iniciamos varios escenarios de integración paralela a la vez, desde el más oficial (a través del Proyecto Pasaporte, coordinando la arquitectura, creando un circuito de prueba y transfiriendo todas las instrucciones para la política de lanzamiento y soporte) al más no oficial: desarrollamos en el circuito de combate, cerramos desde el exterior y probamos el sistema por nuestra cuenta. cuentas de corretaje.

Los detalles de esta historia merecen un artículo separado, pero la clave que se ha logrado consiste en varios puntos:

. « – – crm– – – – », , ,
- « - », « » .
El enfoque de prueba "preprod" ha aumentado en gran medida la participación de los desarrolladores, hizo posible probar UX en la práctica antes de lanzar el producto al mundo exterior y, lo más importante para el proyecto, depurar el funcionamiento correcto de los algoritmos del sistema en el mercado real y los datos del cliente.

Y lo más importante: nunca considere el tiempo perdido en procesos paralelos durante la integración. Al igual que en los presupuestos publicitarios, nunca se sabe qué mitad del presupuesto gastó en vano. Simplemente construya un árbol de opciones y comience los procesos: algunas ramas desaparecerán por sí solas como inútiles, algunas se fusionarán en una sola, y cuando una de ellas lo lleve al resultado, será solo su Ruta de Campeón. Porque en otro proyecto, el mismo escenario puede no funcionar.

imagen

Cual es el resultado

El MVP de trabajo del proyecto se ensambló a fines de agosto, en paralelo, se implementó una versión del emulador para acreditar el programa en NAUFOR y se escribieron ciento cincuenta páginas de documentación de respaldo para registrar el software. Las primeras transacciones reales en el sistema con los alegres gritos del equipo tuvieron lugar el 31 de agosto. Los cambios legales a los documentos de la compañía y las regulaciones del cliente entraron en vigor el 1 de septiembre, y antes de que el sistema fuera acreditado, tuvimos tiempo de depurar y lamer las interfaces.

En MVP, no teníamos cuentas de divisas, ni futuros, ni siquiera nuestra propia cuenta de corretaje, pero la tarea clave se completó: se implementó la infraestructura, el preprod se convirtió en un prod, se implementó el servicio para los clientes.

El 17 de septiembre, el software Fintarget se agregó al registro de programas de seguimiento automático acreditados, y al día siguiente vimos a los primeros clientes que se conectaban al sistema. Todavía había mucho trabajo para expandir la funcionalidad y llevar el MVP al estado de un producto completo y autosuficiente, pero esta es una historia completamente diferente y menos interesante: lanzamientos, sprints, retrasos y análisis de clientes sin fin.