Como traballamos as ideas e como naceu LANBIX

Hai moitos empregados creativos en LANIT-Integration. As ideas para novos produtos e proxectos están literalmente colgando no aire. Ás veces pode ser moi difícil identificar os máis interesantes. Por iso, xuntos desenvolvemos a nosa propia metodoloxía. Lea este artigo sobre como seleccionar os mellores proxectos e implementalos.

En Rusia, e no mundo enteiro, están a producirse unha serie de procesos que levan á transformación do mercado das TI. Grazas ao aumento da potencia de cómputo e á aparición de tecnoloxías de virtualización de servidores, redes e outras, o mercado xa non necesita unha gran cantidade de hardware. Os provedores prefiren cada vez máis traballar directamente cos clientes. O mercado de TI está a experimentar un boom na subcontratación en todas as súas formas, desde a externalización clásica ata a nova onda de subcontratistas: "proveedores de nube". Os sistemas e elementos de infraestrutura fanse moito máis fáciles de manter e configurar. A calidade do software medra cada ano e as tarefas do integrador vanse transformando.

Como traballamos coas ideas

Dirección de inicio do produto "LANIT-Integración" leva máis dun ano. O noso principal obxectivo é crear novos produtos e traelos ao mercado. O primeiro que comezamos foi organizar o proceso de creación de produtos. Estudamos moitas metodoloxías, dende o clásico ata o hype. Porén, ningún deles cumpriu as nosas necesidades. Entón decidimos tomar como base a metodoloxía Lean Startup e adaptala ás nosas tarefas. O Lean Startup é unha teoría do emprendemento creada por Eric Ries. Baséase nos principios, enfoques e prácticas de conceptos como a manufactura esbelta, o desenvolvemento do cliente e a metodoloxía de desenvolvemento flexible.

En canto ao enfoque directo da xestión do desenvolvemento de produtos: non reinventamos a roda, senón que aplicamos unha metodoloxía de desenvolvemento xa existente. SCRUM, engadindo creatividade, e agora pódese chamar con seguridade SCRUM-WATERFALL-BAN. SCRUM, a pesar da súa flexibilidade, é un sistema moi ríxido e é adecuado para xestionar un equipo responsable dun só produto/proxecto. Como entendes, o negocio clásico de "integración" non implica asignar especialistas técnicos a tempo completo para traballar nun proxecto (hai excepcións, pero moi raramente), xa que ademais de traballar en produtos, todos están ocupados cos proxectos actuais. Desde SCRUM tomamos a división do traballo en sprints, reportaxes diarios, retrospectivas e roles. Eliximos Kanban para o noso fluxo de tarefas e integrouse ben no noso sistema de seguimento de tarefas existente. Estruturamos o noso traballo integrándonos perfectamente na orde de cousas existente.
Antes de entrar no mercado, un produto pasa por 5 etapas: idea, selección, concepto, MVP (máis detalles a continuación) e produción.

Idea

Nesta fase hai algo efémero: unha idea. Idealmente, unha idea para resolver un problema existente ou problema do cliente. Non nos faltan ideas. Segundo o plan inicial, deberían ser xerados por empregados das áreas técnicas. Para que unha idea sexa aceptada para o desenvolvemento posterior, o autor debe cubrir o "Modelo de deseño de ideas". Só hai catro preguntas: que? Para qué? Quen precisa isto? E se non é o noso produto, que?

Orixe

Selección

En canto nos chega o modelo cuberto, comeza o procedemento de tramitación e selección. A fase de selección é a máis intensiva en man de obra. Nesta fase fórmanse hipóteses de problemas (non foi en balde o que mencionei no parágrafo anterior que idealmente unha idea debería resolver o problema dun cliente) e o valor do produto. Fórmase unha hipótese de escala, é dicir. como o noso negocio vai crecer e prosperar. Realízanse entrevistas de problemas e expertos con clientes potenciais para proporcionar unha confirmación preliminar de que imos producir algo necesario. Son necesarios polo menos 10-15 entrevistas para sacar unha conclusión sobre a necesidade do produto.

Se se confirman as hipóteses, realízase unha análise financeira preliminar, avalíase o volume aproximado de investimento e as posibles ganancias do investidor. Froito desta etapa nace e preséntase á dirección un documento denominado Lean Canvas.

Concepto

Nesta fase, preto do 70% das ideas son eliminadas. Se o concepto é aprobado, comeza a fase de desenvolvemento da idea. Fórmase a funcionalidade do futuro produto, determínanse camiños de implementación e solucións técnicas óptimas e actualízase o plan de negocio. O resultado desta etapa é unha especificación técnica para o desenvolvemento e un caso de negocio detallado. Se ten éxito, pasamos á fase de MVP ou MVP.

MVP ou MVP

MVP é un produto mínimo viable. Eses. un produto que non está totalmente desenvolvido, pero que xa pode aportar valor e realiza a súa funcionalidade. É imprescindible que nesta fase de desenvolvemento recompilemos comentarios de usuarios reais e fagamos cambios.

Produción

E a última etapa é a produción. Non máis do 5% dos produtos chegan a esta fase. Este 5% inclúe só os produtos máis importantes, necesarios, viables e funcionais.

Temos moitas ideas e xa montamos unha carteira voluminosa. Analizamos cada idea e facemos todo para asegurarnos de que chegue á fase final. É moi grato que os nosos compañeiros non se manteñan indiferentes á nosa dirección de I+D e participen activamente no desenvolvemento e implantación de produtos e solucións.

Como fixemos LANBIX

Vexamos a creación dun produto usando un exemplo real: o produto LANBIX. Este é un sistema de software e hardware "en caixa" deseñado para supervisar pequenas infraestruturas informáticas e alertar rapidamente aos responsables da toma de decisións e aos usuarios empresariais sobre avarías controladas a través dun chatbot. Ademais da función de seguimento, LANBIX inclúe a funcionalidade de Help Desk. Este produto é exclusivo do segmento de mercado ao que nos diriximos. Esta é a nosa vantaxe e a nosa dor. Pero primeiro o primeiro. Direi de inmediato que LANBIX é un produto vivo (é dicir, non é definitivo no seu desenvolvemento e está na seguinte rolda de MVP).

Entón, a primeira etapa é a idea. Para que naza unha idea, necesitas problemas, e nós os tivemos, ou mellor non nós, senón os nosos amigos. A continuación analizaremos varias situacións reais que se produciron en diferentes áreas de negocio.

Unha pequena empresa de xestión mantén dúas casas na rexión de Moscova. O persoal con ordenadores é dunhas 15 persoas. O administrador do sistema é un autónomo visitante (o fillo intelixente dun dos residentes coidadosos). Parece que as actividades da empresa de xestión dependen débilmente da TI, pero a peculiaridade deste negocio é informar mensualmente a moitas autoridades. O disco do sistema do xefe da empresa (que, como é habitual, combina moitos roles) quedou sen espazo libre. Por suposto, isto non ocorreu de súpeto; a advertencia permaneceu durante uns 2 meses e foi ignorada constantemente. Pero chegou unha actualización, o SO actualizouse e, por sorte, conxelouse no medio da actualización, queixándose antes da "morte" dun disco ocupado. O ordenador entrou nun reinicio cíclico. Mentres resolvíamos o problema e recibimos informes, perdemos o prazo de presentación de informes. Parece que un mal funcionamento trivial causou varios problemas: desde perdas ata litixios e responsabilidade administrativa.

Orixe   

Un incidente semellante ocorreu nun gran holding, que unía moitas pequenas empresas, cun único servizo de soporte técnico para toda a oficina. Nun dos departamentos, o ordenador do xefe de contabilidade avariaba. Había tempo que se sabía que podía romperse (o ordenador estaba a diminuír e quentarse desesperadamente), pero o xefe de contabilidade nunca chegou a enviar unha solicitude ao soporte técnico. Por suposto, avariaba exactamente o día de pagamento e os empregados do departamento estiveron sen diñeiro durante varios días.

Unha pequena empresa do pequeno comercio por xunto tiña un sitio web de vendas, que estaba aloxado nunha plataforma externa. Un cliente habitual soubemos por teléfono da súa non dispoñibilidade. No momento da chamada, o sitio levaba unhas tres horas inactivo. Tardaron un par de horas máis en atopar o responsable do sitio e outras dúas en solucionar o problema. En consecuencia, o sitio non estivo dispoñible durante case toda a xornada laboral. Segundo o director comercial da compañía, este tempo de inactividade custoulles preto de 1 millón de rublos.

Eu mesmo atopeime cunha situación semellante cando acudín a unha cita na clínica e tiven que acudir á matrícula do VHI. Non puideron enviarme ao médico por unha razón trivial: houbo un aumento de enerxía pola mañá e, despois do accidente, o seu servizo postal e un determinado servizo para comunicarse coa compañía de seguros non funcionaron. En resposta á miña pregunta, onde están os teus administradores, dixéronme que o seu administrador vén e os visita unha vez por semana. E agora (daquela xa eran as 16:00 horas) non colle o teléfono. Durante polo menos 7 horas, a clínica estivo aislada do mundo exterior e non puido ofrecer servizos de pago.

Que teñen en común todos estes casos? Absolutamente todos os problemas poderían terse evitado con antelación. Coa resposta oportuna do persoal informático, os danos poderían ter reducido. Isto sería posible se os primeiros síntomas fosen interpretados correctamente polos usuarios.

Identificamos hipóteses problemáticas:

• importantes perdas monetarias e reputacionais debido á baixa velocidade de resposta aos fallos na infraestrutura informática;
• interpretación errónea dos primeiros síntomas dun mal funcionamento por parte dos usuarios.

Que pode facer o cliente con eles e como evitar situacións similares no futuro? Non hai moitas opcións:

1. contratar un administrador de sistemas altamente cualificado e facelo traballar a conciencia;
2. externalizar o mantemento de TI a unha empresa de servizos especializada;
3. implementar de forma independente un sistema de seguimento e notificación de fallos;
4. proporcionar formación a usuarios/persoal empresarial en conceptos básicos de alfabetización informática.

Imos instalar a terceira opción. Imos ofrecer un sistema de vixilancia a quen non o utilice por diversos motivos.

Digresión lírica. Varios sistemas para supervisar os servizos de TI no mercado empresarial utilizáronse durante moito tempo e os seus beneficios non están en disputa. Falei con representantes de grandes empresas, observei como se construíu a relación entre empresas e TI. O director técnico dunha gran empresa de construción de máquinas subcontratou o mantemento da infraestrutura de TI a unha empresa externa, pero el mesmo está ao tanto de todos os asuntos. No seu despacho colga unha gran pantalla do sistema de vixilancia con indicadores do estado dos servizos informáticos. Os máis críticos están incluídos no sistema. En calquera momento, o director técnico pode saber cal é o estado da infraestrutura, que está a suceder, onde está o problema, se se avisou aos responsables e se o problema se está solucionando.

As historias enumeradas anteriormente fixeron que o noso equipo pensara sobre como crear un sistema de seguimento óptimo para pequenas empresas. Como resultado, naceu LANBIX, un sistema de vixilancia que pode ser implementado por calquera persoa sen ningún coñecemento de TI. O obxectivo principal do sistema é sinxelo, como todos os sistemas destinados a aumentar a continuidade e a dispoñibilidade, reducindo as perdas monetarias e doutro tipo en caso de inactividade non planificada. O dispositivo está deseñado para reducir ao mínimo o tempo entre "algo está roto" e "o problema foi solucionado".

Para confirmar as hipóteses realizáronse entrevistas de problemas. Non podía imaxinar o que a xente estaría disposta a contar sen tentar venderlles. Cada conversa durou polo menos 1,5 horas e recibimos moita información útil para o desenvolvemento.

Sintetizamos os resultados desta etapa:

1. hai unha comprensión do problema,
2. comprensión do valor - hai,
3. Hai unha idea para unha solución.

A segunda etapa foi máis detallada. En función dos seus resultados, tivemos que presentar á dirección, que esencialmente desempeña o papel de investidor, un caso de negocio (o mesmo Lean Canvas) para tomar unha decisión sobre o destino futuro do produto.

Comezamos coa investigación de mercado e a análise competitiva para saber quen, que e, o máis importante, como están a facer neste mercado.

Resultou o seguinte.

1. Non hai no mercado sistemas de monitorización en caixa preparados para o noso segmento (pequenas empresas), a excepción dun par ou tres, dos que non vou falar por razóns obvias.
2. Os nosos principais competidores, curiosamente, son administradores de sistemas con guións escritos na casa e "complementos" para sistemas de monitorización de código aberto.
3. Hai un problema claro co uso de sistemas de vixilancia de código aberto. Hai un sistema, hai unha gran cantidade de información sobre como traballar e modificar o sistema para adaptalo ás túas necesidades. Dos administradores que entrevistei, moitos admitiron que non tiñan as competencias suficientes para implementar as súas ideas por si mesmos. Pero non poden admitilo ante a dirección por medo ao despedimento. Resulta que é un círculo vicioso.

Despois pasamos á análise das necesidades dos nosos potenciais clientes. Identificamos por nós mesmos un segmento de pequenas organizacións que por algún motivo non teñen o seu propio servizo de TI, onde un administrador do sistema entrante, un autónomo ou unha empresa de servizos é responsable da TI. Non foi a parte informática a que decidiu entrar, senón a parte empresarial, que ofrece aos fundadores e empresarios unha ferramenta para mellorar a calidade do servizo de infraestruturas informáticas. Un produto que debería axudar aos propietarios a asegurar o seu negocio, pero que ao mesmo tempo engadirá traballo aos responsables das TI. Un produto que ofrece ás empresas unha ferramenta para controlar a calidade do soporte informático.

Como resultado do procesamento dos datos recibidos, naceu a primeira lista de requisitos (unha especie de atraso aproximado) para o futuro produto:

• o sistema de vixilancia debe estar baseado nunha solución de código aberto e, como resultado, barato;
• fácil e rápido de instalar;
• non debería esixir coñecementos específicos en TI, mesmo un contable (de ningún xeito quería ofender aos representantes desta profesión) debería poder implantar e configurar o sistema;
• debería detectar automaticamente obxectos para monitorizar na rede;
• debería instalar automaticamente (e idealmente automaticamente) axentes de vixilancia;
• debe ser capaz de supervisar servizos externos, polo menos un sistema CRM e un sitio web de venda;
• debe notificar os problemas tanto á empresa como ao administrador do sistema;
• o grao de profundidade e "idioma" das alertas deben ser diferentes para o administrador e a empresa;
• o sistema debe ser subministrado no seu propio hardware;
• o ferro debe ser o máis accesible posible;
• o sistema debe ser o máis independente posible dos factores externos.

A continuación, calculáronse os investimentos no desenvolvemento de produtos (incluíndo os custos laborais dos empregados do departamento técnico). Elaborouse un esbozo do modelo de negocio e calculouse a economía unitaria do produto.

Resultado da etapa:

• carteira de produtos de alto nivel;
• un modelo de negocio formulado ou unha hipótese de escala que aínda non se proba na práctica.

Pasemos á seguinte fase: concepto. Aquí nós, como enxeñeiros, atopámonos no noso elemento nativo. Hai "listas de desexos" que se descompoñen en compoñentes/subsistemas/funcións, despois convértense en especificacións técnicas/historias de usuarios, despois nun proxecto, etc. Non me deterei en detalle no proceso de preparación dunha variedade de opcións alternativas; pasemos directamente aos requisitos e aos métodos escollidos para a súa implementación.

Demanda
decisión

• Debería ser un sistema de vixilancia aberto;

Tomamos un sistema de vixilancia de código aberto.

• O sistema debe ser sinxelo e rápido de instalar;
• non debe requirir coñecementos específicos de TI. Incluso un contable debería poder implementar e configurar o sistema.

Ofrecemos un sistema instalado para que o usuario só necesite acender o dispositivo e configuralo un pouco, de forma similar a un router.

Pechemos a interacción co dispositivo a algo sinxelo e comprensible para todos.

Escribamos o noso propio chatbot para un dos coñecidos mensaxeiros instantáneos e transfiramos a el todas as interaccións co sistema.

O sistema debería:

• detectar automaticamente os obxectos necesarios para o seguimento na rede;
• instalar automaticamente axentes de vixilancia;
• Poder supervisar servizos externos, polo menos un sistema CRM e un sitio web de venda.

Escribimos complementos para o sistema de monitorización para:

• detección automática de obxectos;
• instalación automática de axentes;
• vixiar a dispoñibilidade de servizos externos.

O sistema debería:

• notificar os problemas tanto á empresa como ao administrador do sistema;
• poder supervisar servizos externos, polo menos un sistema CRM e un sitio web de venda. O grao de profundidade e o "idioma" das notificacións deberían ser diferentes para o administrador e a empresa.
• O sistema non debería requirir coñecementos informáticos específicos; mesmo un contable debería poder implementar e configurar o sistema.

• Engademos diferentes tipos de notificacións para distintos tipos de usuarios. Diferéncianse en altura e profundidade. Un usuario empresarial recibirá notificacións como "todo está ben, pero o ordenador de Ivanov morrerá pronto". O administrador recibirá unha mensaxe completa sobre o erro, quen, como e que pasou ou podería ocorrer.
• Agreguemos a posibilidade de utilizar o correo dunha persoa responsable adicional, para que en caso de avaría reciba unha mensaxe.
• Engademos interacción con provedores de servizos externos baseada no envío de correos electrónicos con texto preparado previamente, porque É o correo electrónico o que orixina o incidente.
• Toda interacción co sistema conectarase a un chatbot; a comunicación realízase nun estilo de diálogo.

Adición:

• Engademos a funcionalidade de "chatear co administrador" para que o usuario poida enviarlle ao administrador unha mensaxe describindo o problema directamente.

• O sistema debe ser subministrado no seu propio hardware.
• O ferro debe estar dispoñible.
• O sistema debe ser o máis independente posible do medio ambiente.

• Tomemos un ordenador Raspberry PI listo e barato.
• Deseñaremos unha placa de alimentación ininterrompida.
• Engademos un módem para que sexa independente do estado da rede local.
• Deseñaremos un fermoso edificio.

Agora temos tres subsistemas cos seus propios requisitos e visión para a súa implementación:

• subsistema de hardware;
• subsistema de vixilancia;
• subsistema de interacción do usuario.

Desenvolvemos un deseño preliminar para o subsistema de hardware. Si Si! Tras violar todas as regras de áxil, elaboramos un documento, porque as plantas de fabricación traballan con documentos. Para os subsistemas restantes, identificamos usuarios (persoas), preparamos historias de usuarios e escribimos tarefas para o desenvolvemento.

Conclúese a fase conceptual e o resultado é:

• proxecto para unha plataforma de hardware;
• visión formulada en forma de historias de usuario para os dous subsistemas restantes;
• un prototipo de software implementado como máquina virtual;
• un prototipo do hardware, implementado en forma de soporte, onde as solucións de hardware foron realmente probadas para a súa resistencia;
• probas realizadas polos nosos administradores.

Os problemas nesta fase foron maioritariamente organizativos e relacionados co descoñecemento do persoal de enxeñaría nos aspectos legais e contables das vendas. Eses. Unha cousa é descubrir que e como vender, e outra moi distinta é enfrontarse a unha máquina legal desapiadada: patentes, tarefas de desenvolvemento, rexistro, EULA e moito máis que nós, como persoas creativas, non tiñamos en conta inicialmente.

Aínda non houbo un problema, senón unha dificultade asociada ao deseño dos recintos. O noso equipo está formado só por enxeñeiros, polo que a primeira versión da caixa foi "construída" a partir de plexiglás polo noso especialista en electrónica.

O corpo parecía, por dicilo suavemente, polémico, especialmente para o público, estragado pola tecnoloxía moderna. Había, por suposto, coñecedores entre a xeración máis antiga de "Kulibins": o edificio evocaba sentimentos nostálxicos neles. Decidiuse fabricar e deseñar de novo a caixa, xa que a antiga, ademais de defectos estéticos, tamén tiña outras estruturais: o plexiglás non toleraba ben a montaxe e a desmontaxe do dispositivo e tendeu a racharse. Xa vos falarei sobre a produción do caso.

E agora estamos preto da meta - MVP. Por suposto, este aínda non é un produto de produción final, pero xa é útil e valioso. O obxectivo principal desta etapa é poñer en marcha o ciclo “crear-avaliar-aprender”. Este é exactamente o escenario no que se atopa LANBIX.

Na fase de "crear", creamos un dispositivo que realiza a funcionalidade indicada. Si, aínda non é perfecto, e seguimos traballando niso.

Volvamos á fabricación do corpo, é dicir. á tarefa de transformar o noso dispositivo de nostálxico a moderno. Ao principio, busquei o mercado de fabricantes de armarios e servizos de deseño industrial. En primeiro lugar, non hai moitas empresas que producen casos no mercado ruso e, en segundo lugar, o custo do deseño industrial nesta fase é prohibitivamente alto, preto de 1 millón de rublos.

Puxéronse en contacto co noso departamento de marketing para o deseño; o mozo deseñador estaba preparado para experimentos creativos. Esbozamos a nosa visión do casco (tendo estudado previamente os mellores exemplos de construción do casco), e el, á súa vez, converteuno nunha obra de arte. Só queda producilo. Nós, orgullosos do noso deseño, recorremos aos nosos socios. O seu CEO de inmediato esmagou as nosas fantasías sinalando, de forma totalmente gratuíta, cousas que non se podían producir na nosa forma escollida. O caso pódese producir, e non será peor que o de Apple, pero o custo do caso será de tres a catro veces máis caro que todos os compoñentes electrónicos. Despois dunha serie de operacións e homologacións, deseñamos unha carcasa que se pode fabricar. Si, non é tan bonito como tiñamos previsto, pero é ideal para acadar os obxectivos actuais.

Resultado da etapa: o primeiro lote de dispositivos listos para o combate e as probas.

E agora o máis difícil é a fase de "avaliar", e co noso produto estamos exactamente neste punto. Só podemos avaliar en función dos resultados do uso de clientes reais e aquí non funciona ningunha suposición. Necesitamos que eses "early adopters" ofrezcan comentarios e fagan os cambios que realmente se necesitan no produto. Xorde a pregunta: onde conseguir clientes e como convencelos de que participen no experimento?

De entre todas as opcións posibles, escollemos un conxunto clásico de ferramentas dixitais: páxina de destino e campaña publicitaria en redes sociais.

O proceso xa está en marcha, pero é moi pronto para falar de resultados, aínda que xa hai respostas e recibimos confirmación de moitas das nosas hipóteses. Unha agradable sorpresa foi a reacción de representantes de segmentos comerciais completamente diferentes, moito máis grandes dos que esperabamos. Sería unha tontería ignorar as novas presentacións e, en función dos resultados das entrevistas, decidiuse lanzar unha liña paralela LANBIX chamada LANBIX Enterprise. Engadimos soporte para infraestruturas distribuídas, monitorización de redes wifi con solución de problemas e localización e control da calidade das canles de comunicación. As empresas de servizos manifestaron o maior interese pola solución. Ao mesmo tempo, os dispositivos que xa desenvolvemos xogan un papel importante no funcionamento das solucións.

Que pasará despois

O que sucederá a continuación co LANBIX orixinal quedará claro en función dos resultados da campaña. Se non se confirman as nosas hipóteses, segundo a metodoloxía Lean, desfarémola despiadadamente ou transformarase en algo novo, porque non hai nada peor que facer un produto que ninguén precisa. Pero agora podemos dicir que o traballo feito non foi en balde e grazas a el apareceu toda unha rama de produtos paralelos na que estamos a traballar activamente. Se ten éxito, LANBIX pasará da fase de MVP á fase final e desenvolverase segundo as leis clásicas comprensibles do marketing de produtos.

Repito, agora queremos atopar primeiros adoptantes, empresas que poidan instalar o noso produto para recoller comentarios. Se estás interesado en probar LANBIX, escribe nos comentarios ou mensaxes privadas.

Orixe

Fonte: www.habr.com