Cómo trabajamos con ideas, y cómo nació LANBIX

En «LANIT-Integraciones» hay muchos empleados creativos. Las ideas para nuevos productos y proyectos literalmente están en el aire. A veces, es muy difícil identificar las más interesantes. Por eso, hemos desarrollado conjuntamente nuestra propia metodología. Descubre cómo seleccionar los mejores proyectos y llevarlos a cabo en este artículo.

En Rusia, y también en el mundo en general, hay una serie de procesos que están transformando el mercado de TI. Gracias al aumento de la potencia de cálculo y la aparición de tecnologías de virtualización de servidores, redes y otros, el mercado ha dejado de necesitar una gran cantidad de 'hardware'. Los proveedores prefieren cada vez más trabajar directamente con los clientes. En el mercado de TI está floreciendo la externalización en todas sus formas, desde la externalización clásica hasta la nueva ola de proveedores de 'nube'. Los sistemas de infraestructura y sus elementos se están volviendo significativamente más simples de mantener y configurar. La calidad del software mejora cada año y las tareas del integrador se están transformando.

Cómo trabajamos con ideas

La dirección de startups de productos en «LANIT-Integraciones» existe desde hace más de un año. Nuestro objetivo principal es crear nuevos productos y llevarlos al mercado. Lo primero que hicimos fue organizar el propio proceso de creación de productos. Estudiamos múltiples metodologías, desde las clásicas hasta las más novedosas. Sin embargo, ninguna de ellas se ajustaba a nuestras necesidades. Entonces decidimos basarnos en la metodología Lean Startup y adaptarla a nuestras tareas. El 'Lean Startup' es una teoría empresarial propuesta por Eric Ries. Se basa en los principios, enfoques y prácticas de conceptos como producción ajustada, desarrollo de clientes y metodologías de desarrollo ágil.

En lo que respecta al enfoque de gestión del desarrollo del producto: no reinventamos la rueda, sino que aplicamos una metodología de desarrollo existente SCRUM, añadiendo creatividad, y ahora se puede nombrar con confianza como SCRUM-WATERFALL-BAN. SCRUM, a pesar de su flexibilidad, es un sistema muy riguroso y es adecuado para gestionar un equipo que se encarga de un solo producto/proyecto. Como comprenderá, el negocio clásico de «integración» no contempla la asignación de especialistas técnicos a tiempo completo para trabajar en un solo proyecto (hay excepciones, pero son muy raras), ya que, además de trabajar en productos, todos están ocupados en proyectos actuales. En SCRUM, tomamos la división del trabajo en sprints, la rendición de cuentas diaria, las retrospectivas y los roles. Para trabajar con el flujo de tareas elegimos Kanban, y se integró a la perfección en nuestro sistema de seguimiento de tareas ya existente. Hemos estructurado el trabajo, integrándonos suavemente en el orden de cosas ya establecido.
Antes de salir al mercado, un producto pasa por 5 etapas: idea, selección, concepto, MЖП (más detalles a continuación) y producción.

La idea

En esta etapa hay algo etéreo: la idea. Idealmente, una solución a un problema o tarea existente del cliente. No nos faltan ideas. Según el concepto inicial, deberían ser generadas por empleados de áreas técnicas. Para que la idea sea aceptada para el desarrollo posterior, el autor debe rellenar el «Plantilla de presentación de ideas». Allí hay solo cuatro preguntas: ¿Qué? ¿Para qué? ¿A quién le interesa? Si no es nuestro producto, ¿qué es?

Fuente

Selección

Tan pronto como la plantilla completada llega a nosotros, comienza el procedimiento de procesamiento y selección. La etapa de selección es la más laboriosa. En este momento se forman hipótesis de problemas (no mencioné en el párrafo anterior que, idealmente, la idea debe resolver un problema del cliente) y el valor del producto. Se formula una hipótesis de escala, es decir, cómo nuestro negocio planea crecer y prosperar. Se llevan a cabo entrevistas problemáticas y de expertos con clientes potenciales para confirmar previamente que estamos a punto de producir algo necesario. Se requieren al menos 10-15 entrevistas para llegar a la conclusión sobre la necesidad del producto.

Si las hipótesis se confirman, se realiza un análisis financiero preliminar, se evalúa el volumen aproximado de inversiones y la posible ganancia del inversor. Como resultado de esta etapa, se genera un documento llamado Lean Canvas y se presenta a la dirección.

Concepto

En esta etapa se filtran alrededor del 70% de las ideas. Si el concepto es aprobado, comienza la fase de desarrollo de la idea. Se formulan las funcionalidades del futuro producto, se determinan las vías de realización y las soluciones técnicas óptimas, y se actualiza el plan de negocio. El resultado de esta etapa es un documento técnico para el desarrollo y un detallado caso de negocio. En caso de éxito, pasamos a la etapa de MVP.

MVP

El MVP es el producto mínimo viable. Es decir, un producto que no está completamente desarrollado, pero que ya puede aportar valor y cumplir con su funcionalidad. En esta etapa del desarrollo, recopilamos comentarios de usuarios reales y hacemos cambios.

Producción

Y la etapa final es la producción. A esta etapa no llegan más del 5% de los productos. En este 5% se incluyen únicamente los productos más importantes, necesarios, viables y funcionales.

Tenemos muchas ideas y ya hemos reunido una amplia cartera. Analizamos cada idea y hacemos todo lo posible para que llegue a la etapa final. Es gratificante que los colegas no se hayan mostrado indiferentes a nuestra dirección de I+D y participen activamente en el desarrollo y la implementación de productos y soluciones.

Cómo hicimos LANBIX

Consideremos la creación del producto a través de un ejemplo real: el producto LANBIX. Este es un complejo software y hardware 'en caja' diseñado para monitorear pequeñas infraestructuras de TI y notificar de forma operativa a los responsables y a los usuarios empresariales sobre fallos, gestionando todo a través de un chatbot. Además de la función de monitoreo, LANBIX incluye funcionalidad de Help Desk. Este producto es exclusivo para el segmento de mercado al que nos dirigimos. Esta es tanto nuestra ventaja como nuestra preocupación. Pero esto es solo el comienzo. Diré de inmediato que LANBIX es un producto vivo (es decir, no es definitivo en su desarrollo y se encuentra en otra fase del MVP).

Así que la primera etapa es la idea. Para que surja una idea, se necesitan problemas, y los teníamos, más exactamente no nosotros, sino nuestros conocidos. A continuación, consideraremos algunas situaciones reales que han ocurrido en diferentes áreas de negocios.

Una pequeña empresa administradora gestiona dos casas en los alrededores de Moscú. El personal que tiene computadoras es de alrededor de 15 personas. El administrador del sistema es un freelancer ocasional (el ingenioso hijo de uno de los residentes preocupados). A primera vista, la actividad de la empresa administradora parece depender poco de la tecnología, pero una característica de este negocio es la presentación mensual de informes a múltiples instancias. En el disco duro del director de la empresa (que, como suele ser, combina múltiples roles) se acabó el espacio libre. Naturalmente, esto no ocurrió de repente; la advertencia estuvo presente durante aproximadamente 2 meses y fue ignorada constantemente. Pero llegó una actualización, el sistema operativo se actualizó y, como por arte de magia, se colgó a mitad de la actualización, quejándose antes de su 'muerte' por el disco lleno. La computadora entró en un bucle de reinicio. Mientras se resolvía el problema y se recuperaban los informes, se perdió la fecha límite para presentar los informes. Aparentemente, un problema menor se convirtió en la causa de diversos inconvenientes: desde pérdidas hasta disputas judiciales y responsabilidad administrativa.

Fuente   

Un caso similar ocurrió en un gran holding que agrupa a numerosas pequeñas empresas, con un único servicio de soporte técnico para toda la oficina. En uno de los departamentos, se averió la computadora del contador jefe. Desde hace tiempo se sabía que podría fallar (la computadora estaba desesperadamente lenta y se calentaba), pero el contador nunca encontrara el momento para enviar una solicitud al soporte técnico. Naturalmente, se averió justo el día de pago, y los empleados del departamento estuvieron varios días sin recibir su salario.

Un pequeño negocio de venta al por mayor experimentó la caída de su sitio web de ventas, que estaba alojado en una plataforma externa. Se enteraron de su inaccesibilidad por teléfono de un cliente habitual. En el momento de la llamada, el sitio llevaba caído alrededor de tres horas. La búsqueda de la persona responsable del sitio tomó un par de horas más, y la resolución del problema otros dos. Por lo tanto, prácticamente todo el día laboral el sitio estuvo fuera de servicio. Según el director comercial de la empresa, este tiempo de inactividad les costó aproximadamente 1 millón de rublos.

Yo mismo enfrenté una situación similar cuando fui a una cita en la clínica y debía ir a la recepción del DMS. No podían enviarme al médico por una razón banal: hubo un aumento de tensión en la mañana y después del fallo, su servicio de correo y un servicio de comunicación con la aseguradora no funcionaban. Ante mi pregunta de dónde estaban sus administradores, me dijeron que el administrador era externo y solo iba una vez a la semana. Y ahora (en ese momento eran ya las 16:00) no contestaba el teléfono. La clínica estuvo desconectada del mundo exterior durante al menos 7 horas y no pudo ofrecer servicios de pago.

¿Qué une todos estos casos? Todos los problemas podrían haberse prevenido con anticipación. Con una reacción oportuna por parte de quienes gestionan la TI, se podría haber reducido el daño causado. Esto también habría sido posible con una correcta interpretación de los síntomas tempranos por parte de los usuarios.

Hemos identificado las hipótesis de los problemas:

• pérdidas significativas de dinero y reputación debido a la baja velocidad de reacción ante fallos en la infraestructura de TI;
• interpretación incorrecta de los síntomas tempranos de fallo por parte de los usuarios.

¿Qué puede hacer el cliente con ellos y cómo evitar situaciones similares en el futuro? No hay muchas opciones:

1. contratar a un administrador de sistemas altamente calificado y exigirle que trabaje con responsabilidad;
2. externalizar el mantenimiento de TI a una empresa de servicios especializada;
3. implementar de forma autónoma un sistema de monitoreo y alerta sobre fallos;
4. capacitar a los usuarios/personal de negocio en los fundamentos de la alfabetización informática.

Nos detenemos en la tercera opción. Propongamos un sistema de monitoreo a aquellos que no lo utilizan por diversas razones.

Una digresión lírica. Diversos sistemas de monitoreo de servicios de TI en el mercado empresarial se han utilizado durante mucho tiempo y su utilidad es indiscutible. He hablado con representantes de grandes empresas y he observado cómo se establecen las relaciones entre los negocios y TI. El director técnico de una importante empresa de ingeniería mecánica externalizó el mantenimiento de la infraestructura de TI a una empresa externa, pero sigue manteniéndose informado sobre todo. En su oficina, hay una gran pantalla del sistema de monitoreo con indicadores del estado de los servicios de TI. Se han introducido los más críticos en el sistema. En cualquier momento, el director técnico puede saber en qué estado se encuentra la infraestructura, qué está sucediendo, en qué área hay un problema, si se ha informado a las personas responsables y si se está solucionando el problema.

Las historias mencionadas llevaron a nuestro equipo a reflexionar sobre cómo crear un sistema de monitoreo óptimo para pequeñas empresas. Como resultado, nació LANBIX: un sistema de monitoreo que cualquiera puede implementar sin conocimientos en TI. La tarea principal del sistema es tan sencilla como la de todos los sistemas destinados a aumentar la continuidad y disponibilidad: reducir las pérdidas monetarias y de otro tipo en caso de interrupciones no programadas. El dispositivo tiene como objetivo minimizar el tiempo entre "tengo algo roto" y "el problema ha sido solucionado".

Para validar las hipótesis, se realizaron entrevistas problemáticas. No podía imaginar cuánto estaban dispuestas a contar las personas si no intentábamos venderles nada. Cada conversación duró al menos 1.5 horas y obtuvimos una gran cantidad de información útil para el desarrollo posterior.

Resumiendo el resultado de esta etapa:

1. comprensión del problema - existe,
2. comprensión del valor - existe,
3. idea para la solución - existe.

La segunda etapa fue más detallada. En base a sus resultados, debíamos presentar a la dirección, que en esencia actúa como inversor, un caso de negocio (ese mismo Lean Canvas) para tomar una decisión sobre el futuro del producto.

Comenzamos con un estudio de mercado y un análisis competitivo con el objetivo de averiguar quién, qué y, lo más importante, cómo se está haciendo en este mercado.

Se descubrió lo siguiente.

1. En el mercado no hay sistemas de monitoreo empaquetados listos para nuestro segmento (pequeñas empresas), excepto un par de ellos, sobre los cuales por razones evidentes no hablaré.
2. Nuestros principales competidores, sorprendentemente, son los administradores de sistemas con scripts personalizados y 'ajustes' en sistemas de monitoreo de código abierto.
3. Hay un evidente problema con el uso de sistemas de monitoreo de código abierto. Existe un sistema, hay una gran cantidad de información sobre su funcionamiento y ajustes para adaptarlo a las necesidades. Muchos de los administradores que entrevisté admitieron que carecen de las competencias para realizar sus ideas por sí mismos. Y no pueden confesar esto a la dirección por miedo a ser despedidos. Se convierte en un círculo vicioso.

Luego pasamos al análisis de las necesidades de nuestros potenciales clientes. Identificamos un segmento de pequeñas organizaciones que, por algún motivo, no tienen su propio departamento de TI, donde la responsabilidad de TI recae ya sea en un administrador de sistemas externo, un freelancer o una empresa de servicios. Decidimos abordar el tema no desde el lado de TI, sino desde el lado del negocio, ofreciendo a los fundadores y propietarios de negocios una herramienta para mejorar la calidad del servicio de la infraestructura de TI. Un producto que debe ayudar a los propietarios a proteger su negocio, aunque al mismo tiempo, aumentará el trabajo para quienes están a cargo de TI. Un producto que brinda a las empresas una herramienta para controlar la calidad del soporte de TI.

A raíz del análisis de los datos obtenidos, nació la primera lista de requisitos (una especie de backlog inicial) para el futuro producto:

• el sistema de monitoreo debe estar basado en una solución de código abierto y, por lo tanto, ser económica;
• debe ser fácil y rápida de instalar;
• no debe requerir conocimientos específicos en TI, incluso un contable (de ninguna manera pretendo ofender a los representantes de esta profesión) debe ser capaz de desplegar y configurar el sistema;
• debe detectar automáticamente los objetos para monitorizar en la red;
• debe instalar automáticamente (y en ideal, de forma automática) los agentes de monitoreo;
• debe tener la capacidad de monitorear servicios externos, al menos un sistema CRM y un sitio web de ventas;
• debe notificar sobre fallos tanto al negocio como al administrador de sistemas;
• la profundidad y el 'lenguaje' de las notificaciones deben ser diferentes para el administrador y el negocio;
• el sistema debe ser entregado en hardware propio;
• el hardware debe ser lo más accesible posible;
• el sistema debe ser lo más independiente posible de factores externos.

A continuación, se calcularon las inversiones para el desarrollo del producto (incluyendo los esfuerzos laborales del personal del departamento técnico). Se preparó un esbozo del modelo de negocio y se calculó la unidad económica del producto.

Resultado de la etapa:

• un backlog de producto de alto nivel;
• un modelo de negocio formulado o una hipótesis de escalabilidad que aún debe ser validada en la práctica.

Pasemos a la siguiente etapa: la conceptualización. Aquí es donde, como ingenieros, nos movemos en nuestro terreno. Hay 'deseos' que se descomponen en componentes/subsistemas/características, luego se convierten en requisitos técnicos/historias de usuario, luego en proyectos, etc. No me detendré en el proceso de preparación de un conjunto de alternativas, pasemos directamente a los requisitos y los métodos elegidos para su implementación.

Requisito
Solución

• Debe ser un sistema de monitoreo abierto;

Tomamos un sistema de monitoreo de código abierto.

• El sistema debe ser simple y rápido de instalar;
• no debe requerir conocimientos específicos en TI. Incluso un contable debería poder desplegar y configurar el sistema.

Ofrecemos un sistema preinstalado, para que solo le quede al usuario encender el dispositivo y configurarlo un poco, similar a un router.

Cerramos la interacción con el dispositivo en algo simple y comprensible para todos.

Desarrollaremos nuestro propio chatbot para uno de los mensajeros conocidos y centralizaremos toda la interacción con el sistema en él.

El sistema debe:

• descubrir automáticamente los objetos a monitorear en la red;
• instalar automáticamente los agentes de monitoreo;
• Tener la capacidad de monitorear servicios externos, como mínimo un sistema CRM y un sitio de ventas.

Escribimos extensiones para el sistema de monitoreo sobre:

• descubrimiento automático de objetos;
• instalación automática de agentes;
• monitoreo de la disponibilidad de servicios externos.

El sistema debe:

• notificar sobre fallos tanto al negocio como al administrador del sistema;
• tener la capacidad de monitorear servicios externos, como mínimo un sistema CRM y un sitio de ventas. La profundidad y el 'lenguaje' de las notificaciones deben ser diferentes para el administrador y el negocio.
• El sistema no debe requerir conocimientos específicos en TI, incluso un contable debería poder desplegar y configurar el sistema.

• Añadiremos diferentes tipos de notificaciones para diferentes tipos de usuarios. Se diferencian en la presentación y profundidad. El usuario empresarial recibirá notificaciones del tipo 'todo bien, pero la computadora de Ivanov pronto se apagará'. El administrador recibirá un mensaje completo sobre el error, quién, cómo y qué sucedió o podría suceder.
• Añadiremos la posibilidad de usar el correo electrónico de una persona responsable adicional, para que en caso de falla reciba el mensaje.
• Añadiremos la interacción con proveedores externos de servicios basada en el envío de correos electrónicos con texto predefinido, ya que el correo electrónico proporciona una base para la creación de un incidente.
• Toda la interacción con el sistema se cerrará en un chat-bot, la comunicación se llevará a cabo en estilo de diálogo.

Adición:

• Añadiremos la funcionalidad de 'chat con el administrador', para que el usuario pueda enviar un mensaje directamente al administrador con una descripción del problema.

• El sistema debe ser proporcionado en hardware propio.
• El hardware debe ser accesible.
• El sistema debe ser lo más independiente posible del entorno.

• Tomaremos una computadora Raspberry PI preparada y económica.
• Diseñaremos un circuito de alimentación ininterrumpida.
• Añadiremos un módem para independizarnos del estado de la red local.
• Diseñaremos una carcasa atractiva.

Ahora tenemos tres subsistemas con sus propios requisitos y visiones de implementación:

• subsistema de hardware;
• subsistema de monitoreo;
• subsistema de interacción del usuario.

Para el subsistema de hardware, hemos desarrollado un proyecto preliminar. ¡Sí, sí! Rompiendo todas las reglas de la agilidad, hemos creado un documento, porque las fábricas trabajan precisamente con documentos. Para los otros subsistemas, hemos identificado usuarios (personas), preparado historias de usuario y redactado tareas para el desarrollo.

En esta etapa, el concepto concluye, y su resultado fueron:

• proyecto para la plataforma de hardware;
• visión formulada en forma de historias de usuario para los otros dos subsistemas;
• prototipo de la parte de software, implementado en forma de máquina virtual;
• prototipo de la parte de hardware, realizado en forma de un stand, donde, de hecho, se probaron las soluciones de hardware;
• pruebas realizadas por nuestros administradores.

Los problemas en esta etapa eran principalmente organizativos y estaban relacionados con la falta de conocimientos del equipo de ingenieros en aspectos legales y contables de las ventas. Es decir, es una cosa idear qué y cómo vender, y es completamente diferente enfrentar a la implacable máquina legal: patentes, tareas de desarrollo, contabilidad, EULA y muchas otras cosas que nosotros, como personas creativas, no habíamos considerado inicialmente.

No era un problema, sino más bien una dificultad relacionada con el diseño de las carcasas. En nuestro equipo solo hay ingenieros, por lo que la primera versión de la carcasa fue 'modelada' con acrílico por nuestro especialista en electrónica.

La carcasa se veía, por decirlo suavemente, controvertida, especialmente para un público acostumbrado a la tecnología moderna. Sin embargo, hubo algunos entusiastas entre los 'Kulikov' de la generación anterior, que sintieron nostalgia al verla. Se decidió fabricar y rediseñar la carcasa, ya que la antigua, además de sus defectos estéticos, tenía también problemas estructurales: el acrílico no soportaba bien el ensamblaje y desensamblaje del dispositivo y tendía a agrietarse. Hablaré más sobre la producción de la carcasa más adelante.

Y así nos acercamos a la línea de meta: el MVP. Por supuesto, aún no es el producto final en serie, pero ya está proporcionando beneficios y representa un valor. El objetivo principal de esta etapa es iniciar el ciclo 'crear-evaluar-aprender'. Es en esta etapa donde se encuentra LANBIX.

En la etapa de 'crear', hemos fabricado un dispositivo que cumple con las funciones anunciadas. Sí, aún no es perfecto, y continuamos trabajando en él.

Volvamos a la fabricación de la carcasa, es decir, a la tarea de transformar nuestro dispositivo de algo que evoca sentimientos nostálgicos a uno moderno. Al principio, investigué el mercado en busca de fabricantes de carcasas y proveedores de servicios de diseño industrial. En primer lugar, hay muy pocas empresas que fabrican carcasas en el mercado ruso, y en segundo lugar, el costo del diseño industrial en esta etapa es exorbitante, alrededor de 1 millón de rublos.

Nos dirigimos a nuestro departamento de marketing para el diseño, donde un joven diseñador estaba listo para experimentos creativos. Exponemos nuestra visión del chasis (habiendo estudiado previamente los mejores ejemplos de diseño de chasis), y él, a su vez, lo transformó en una obra de arte. Solo quedaba producirlo. Orgullosos de nuestro diseño, contactamos a nuestros socios. Su director general destruyó de inmediato nuestras fantasías, señalando de manera gratuita cosas que no se podían producir de la forma que habíamos elegido. Se puede fabricar el chasis, y será tan bueno como el de Apple, pero el costo del chasis será de tres a cuatro veces más caro que toda la electrónica. Después de una serie de operaciones y aprobaciones, proyectamos un chasis que puede ser producido. Sí, ya no es tan hermoso como planeábamos, pero es ideal para lograr los objetivos actuales.

Resultado de la etapa: el primer lote de dispositivos, listos para la batalla y pruebas.

Y ahora lo más difícil: la etapa de "evaluar", y con nuestro producto nos encontramos justo en este punto. Solo podemos evaluar con base en los resultados del uso por parte de clientes reales, y ninguna suposición aquí funciona. Necesitamos esos "early adopters" para proporcionar comentarios y realizar los cambios en el producto que realmente son necesarios. Surge la pregunta: ¿dónde conseguir clientes y cómo convencerlos para que participen en el experimento?

De todas las opciones posibles, elegimos un conjunto clásico de herramientas digitales: una landing page y una campaña publicitaria en redes sociales.

El proceso ya ha comenzado, pero es demasiado pronto para hablar de resultados, aunque ya hay comentarios y hemos recibido confirmación de muchas de nuestras hipótesis. Una grata sorpresa fue la reacción de representantes de otros segmentos del negocio, mucho más grandes de lo que esperábamos. Sería tonto ignorar estas nuevas ideas, y como resultado de las entrevistas realizadas, se tomó la decisión de lanzar una línea paralela llamada LANBIX Enterprise. Agregamos soporte para infraestructuras distribuidas, monitoreo de redes Wi-Fi con búsqueda y localización de fallas, y monitoreo de la calidad de los canales de comunicación. El mayor interés en la solución fue expresado por empresas de servicios. Al mismo tiempo, nuestros dispositivos ya desarrollados desempeñan un papel importante en el trabajo de las soluciones.

¿Qué viene después?

Lo que sucederá con LANBIX se aclarará con los resultados de la campaña. Si nuestras hipótesis no se confirman, de acuerdo con la metodología Lean, lo eliminaremos sin piedad o se transformará en algo nuevo, porque no hay nada peor que crear un producto que no le interesa a nadie. Pero ya se puede decir que el trabajo realizado no ha sido en vano y gracias a él ha surgido toda una línea de productos paralelos en la que estamos trabajando activamente. Si tenemos éxito, LANBIX pasará de la fase MVP a la fase final y se desarrollará según las leyes clásicas del marketing de productos.

Reitero, actualmente queremos encontrar a los primeros seguidores, empresas a las que podamos instalar nuestro producto con el objetivo de recopilar comentarios. Si estás interesado en probar LANBIX, deja un comentario o envíanos un mensaje privado.

Fuente

Fuente: habr.com