🥇Como trabalhamos com ideias e como o LANBIX nasceu

Na "LANIT-Integrações" há muitos colaboradores criativos. As ideias para novos produtos e projetos estão literalmente no ar. Identificar as mais interessantes às vezes é muito difícil. Por isso, desenvolvemos, juntos, nossa própria metodologia. Como selecionar os melhores projetos e implementá-los, leia neste artigo.

Na Rússia, e até mesmo no mundo, uma série de processos está ocorrendo que está transformando o mercado de TI. Devido ao aumento do poder computacional e ao surgimento de tecnologias de virtualização de servidores, redes e outros, o mercado deixou de necessitar de grandes quantidades de "hardware". Os fornecedores preferem cada vez mais trabalhar diretamente com os clientes. No mercado de TI, o outsourcing está em plena expansão em todas as suas formas, desde o outsourcing clássico até os novos fornecedores da "nuvem". Os sistemas e elementos de infraestrutura tornaram-se significativamente mais fáceis de manter e configurar. A qualidade do software cresce a cada ano e as tarefas do integrador se transformam.

Como trabalhamos com ideias

A direção de startups de produtos em "LANIT-Integrações" existe há mais de um ano. Nosso principal objetivo é criar novos produtos e lançá-los no mercado. A primeira coisa que fizemos foi organizar o próprio processo de criação de produtos. Estudamos diversas metodologias, desde as clássicas até as mais modernas. No entanto, nenhuma delas atendia às nossas necessidades. Então, decidimos adotar a metodologia Lean Startup como base e adaptá-la para nossas demandas. "Lean Startup" é uma teoria de empreendedorismo criada por Eric Ries. Ela se baseia em princípios, abordagens e práticas de conceitos como produção enxuta, desenvolvimento de clientes e metodologias ágeis de desenvolvimento.

No que diz respeito especificamente à abordagem de gerenciamento do desenvolvimento do produto: não quisemos reinventar a roda, mas aplicamos uma metodologia de desenvolvimento já existente SCRUM, adicionando criatividade, e agora pode ser chamada ousadamente de SCRUM-WATERFALL-BAN. O SCRUM, apesar de sua flexibilidade, é um sistema muito rígido e adequado para a gestão de equipes responsáveis por apenas um produto/projeto. Como você deve entender, o clássico negócio de
Antes de chegar ao mercado, um produto passa por 5 etapas: ideia, seleção, conceito, MVP (mais detalhes abaixo) e produção.

Ideia

Nesta fase, há algo efêmero - a ideia. Idealmente, é a ideia de resolver um problema ou uma tarefa do cliente. Não nos faltam ideias. Inicialmente, elas devem ser geradas pelos colaboradores das áreas técnicas. Para que a ideia seja aceita para desenvolvimento posterior, o autor deve preencher o 'Modelo de Apresentação da Ideia'. Existem apenas quatro perguntas: O quê? Para quê? Quem precisa disso? E se não for nosso produto, o que será?

Fonte

Seleção

Assim que o modelo preenchido chega até nós, inicia-se o processo de tratamento e seleção. A fase de seleção é a mais trabalhosa. Neste estágio, ocorre a formação de hipóteses sobre problemas (não foi à toa que mencionei no parágrafo anterior que, idealmente, a ideia deve resolver um problema do cliente) e o valor do produto. Forma-se uma hipótese de escala, ou seja, como nosso negócio pretende crescer e prosperar. Realizam-se entrevistas problemáticas e de especialistas com potenciais clientes para a confirmação preliminar de que estamos prestes a produzir algo necessário. São necessárias pelo menos 10-15 entrevistas para tirar conclusões sobre a necessidade do produto.

Se as hipóteses são confirmadas, realiza-se uma análise financeira preliminar, avaliando o volume estimado de investimentos e possíveis ganhos do investidor. Como resultado desta etapa, nasce um documento chamado Lean Canvas, que é apresentado à gerência.

Conceito

Nesta etapa, cerca de 70% das ideias são filtradas. Se o conceito for aprovado, inicia-se a fase de desenvolvimento da ideia. As funcionalidades do futuro produto são definidas, caminhos de implementação e soluções técnicas ótimas são identificados, e o plano de negócios é atualizado. O resultado desta etapa é um termo de referência para desenvolvimento e um detalhado business case. Em caso de sucesso, avançamos para a fase de MVP.

MVP

MVP é o produto minimamente viável. Ou seja, um produto que ainda não está totalmente finalizado, mas já pode agregar valor e cumprir suas funcionalidades. É essencial que nesta etapa de desenvolvimento colhemos feedback de usuários reais e implementemos as mudanças necessárias.

Produção

E a última etapa é a produção. Nesta fase, apenas 5% dos produtos alcançam a conclusão. Esses 5% incluem apenas os produtos mais importantes, necessários, viáveis e funcionais.

Temos muitas ideias e já acumulamos um portfólio considerável. Analisamos cada ideia e fazemos o possível para que ela chegue à fase final. É muito gratificante que os colegas estejam engajados em nosso setor de P&D e participem ativamente no desenvolvimento e na implementação de produtos e soluções.

Como fizemos o LANBIX

Vamos examinar a criação de um produto através de um exemplo real — o produto LANBIX. Trata-se de um complexo de hardware e software 'embarcado', destinado ao monitoramento de pequenas infraestruturas de TI e à notificação imediata de responsáveis e usuários de negócios sobre falhas, com gestão via chatbot. Além da função de monitoramento, o LANBIX inclui funcionalidades de Help Desk. Este produto é exclusivo para o segmento de mercado que estamos visando. Isso é tanto uma vantagem quanto uma dor para nós. Mas, vamos por partes. Quero destacar que o LANBIX é um produto em desenvolvimento (ou seja, não é definitivo em sua evolução e está em mais uma rodada de MVP).

Então, a primeira etapa é a ideia. Para que uma ideia nasça, é necessário ter problemas, e nós os tivemos, ou melhor, nossos conhecidos os tiveram. A seguir, veremos algumas situações reais que ocorreram em diferentes áreas de negócios.

Uma pequena empresa de gestão cuida de dois prédios na região de Moscovo. A equipe de colaboradores com computadores é de cerca de 15 pessoas. O administrador de sistemas é um freelancer ocasional (o filho esperto de um dos moradores interessados). À primeira vista, a atividade da empresa parece pouco dependente da TI, mas a particularidade deste negócio é que todos os meses precisa prestar contas a várias instâncias. No disco rígido do gerente da empresa (que, como sempre, acumula diversas funções), o espaço livre se esgotou. Naturalmente, isso não aconteceu de repente; havia um aviso pendurado por cerca de 2 meses que foi constantemente ignorado. Mas acabou vindo uma atualização, o sistema foi atualizado e, para piorar, travou no meio da atualização, reclamando antes de “morrer” sobre o disco ocupado. O computador entrou em um ciclo de reinicialização. Enquanto se tentava resolver o problema e recuperar os relatórios, perderam o prazo para a entrega das contas. Uma falha aparentemente insignificante acabou gerando diversos problemas: desde prejuízos até litígios e responsabilidade administrativa.

Fonte

Um caso semelhante ocorreu em um grande grupo empresarial que reúne várias pequenas empresas, com um único serviço de suporte técnico para todo o escritório. Em um dos departamentos, o computador do contador chefe quebrou. Já se sabia há tempos que ele poderia quebrar (o computador estava extremamente lento e superaqueceu), mas o contador nunca encontrou tempo para enviar um pedido de suporte. Naturalmente, ele quebrou exatamente no dia do pagamento, e os funcionários do departamento ficaram alguns dias sem dinheiro.

Uma pequena empresa de comércio atacadista leve teve seu site de vendas fora do ar, que era hospedado em uma plataforma externa. Eles foram informados sobre a indisponibilidade por telefone de um cliente regular. No momento da chamada, o site já estava fora do ar há cerca de três horas. A busca pela pessoa responsável pelo site levou mais algumas horas, e a resolução do problema levou mais duas. Consequentemente, praticamente todo o dia de trabalho o site esteve indisponível. Segundo o diretor comercial da empresa, essa paralisação custou-lhes cerca de 1 milhão de rublos.

Enfrentei uma situação semelhante quando fui a uma clínica e precisava ir ao setor de atendimento do DMS. Não puderam me enviar ao médico por um motivo simples: pela manhã houve uma queda de tensão, e após o acidente, o serviço de e-mails deles e um serviço de comunicação com a seguradora não estavam funcionando. Quando perguntei onde estavam os administradores, disseram que eles tinham um administrador que só ia até lá uma vez por semana. E naquele momento (já era 16h) ele não atendia. A clínica ficou isolada do mundo exterior por, no mínimo, 7 horas e não pôde prestar serviços pagos.

O que une todos esses casos? Todos os problemas poderiam ter sido prevenidos antecipadamente. Com uma resposta oportuna da parte das pessoas que cuidam da TI, o dano causado poderia ter sido reduzido. Isso seria possível também com a interpretação correta dos primeiros sintomas por parte dos usuários.

Identificamos as hipóteses dos problemas:

perdas significativas financeiras e de reputação devido à baixa velocidade de resposta a falhas na infraestrutura de TI;
interpretação incorreta dos primeiros sintomas de falha pelos usuários.

O que o cliente pode fazer a respeito, e como evitar situações semelhantes no futuro? As opções não são muitas:

contratar um administrador de sistema altamente qualificado e fazê-lo trabalhar com responsabilidade;
transferir a manutenção de TI para uma empresa de serviços especializada;
implementar por conta própria um sistema de monitoramento e alerta para falhas;
oferecer treinamento aos usuários/pessoal de negócios sobre noções básicas de informática.

Vamos nos concentrar na terceira opção. Vamos propor um sistema de monitoramento para aqueles que não o utilizam por diversas razões.

Um desvio lírico. Diferentes sistemas de monitoramento de serviços de TI no mercado corporativo já estão em uso há muito tempo, e os seus benefícios são inegáveis. Conversei com representantes de grandes empresas e observei como são estabelecidas as relações entre negócios e TI. O diretor técnico de uma grande empresa de engenharia optou por terceirizar a manutenção da infraestrutura de TI, mas ainda permanece informado sobre todas as atividades. Em seu escritório, há uma grande tela do sistema de monitoramento com indicadores sobre o estado dos serviços de TI. O sistema registra os mais críticos. A qualquer momento, o diretor técnico pode saber qual é a condição da infraestrutura, o que está acontecendo, onde está o problema, se as pessoas responsáveis foram notificadas e se a questão está sendo resolvida.

As histórias mencionadas levaram nossa equipe a refletir sobre como criar um sistema de monitoramento ideal para pequenas empresas. O resultado foi o LANBIX — um sistema de monitoramento que pode ser instalado por qualquer pessoa, mesmo sem conhecimento em TI. A principal tarefa do sistema é simples, como a de todos os sistemas voltados para aumentar a continuidade e a disponibilidade: reduzir perdas financeiras e outras em caso de paradas inesperadas. O dispositivo tem como objetivo minimizar o tempo entre "algo quebrou" e "o problema foi resolvido".

Para validar as hipóteses, foram realizadas entrevistas problemáticas. Eu não conseguia imaginar quanta informação as pessoas estão dispostas a compartilhar se não tentarmos vendê-las algo. Cada conversa durou pelo menos 1,5 horas, e obtivemos uma enorme quantidade de informações úteis para o desenvolvimento futuro.

Resumindo o resultado desta etapa:

entendimento do problema — sim,
entendimento do valor — sim,
ideia para a solução — sim.

A segunda etapa foi mais detalhada. Como resultado, deveríamos apresentar à gerência, que na verdade desempenha o papel de investidor, um business case (o famoso Lean Canvas) para a tomada de decisão sobre o futuro do produto.

Começamos com uma pesquisa de mercado e uma análise competitiva com o objetivo de descobrir quem, o que e, principalmente, como está sendo feito neste mercado.

Descobriu-se o seguinte.

No mercado, não há sistemas de monitoramento prontos para o nosso segmento (pequenas empresas), exceto por um ou dois, dos quais não posso falar por motivos óbvios.
Nossos principais concorrentes, curiosamente, são administradores de sistemas com scripts próprios e ‘melhorias’ em sistemas de monitoramento de código aberto.
Há um problema claro com o uso de sistemas de monitoramento de código aberto. Existe um sistema, há uma enorme quantidade de informações sobre o funcionamento e os ajustes necessários para atender às próprias necessidades. Muitos dos administradores com quem conversei admitiram que não têm as competências necessárias para realizar suas ideias sozinhos. E admitir isso ao gerenciamento é algo que não podem fazer por medo de demissão. Assim, forma-se um ciclo vicioso.

Em seguida, passamos a analisar as necessidades de nossos potenciais clientes. Identificamos um segmento de pequenas organizações que, por algum motivo, não possuem um departamento de TI, onde a responsabilidade de TI recai sobre um administrador de sistemas temporário, um freelancer ou uma empresa de serviços. Decidimos abordar a situação não do lado de TI, mas do lado dos negócios, oferecendo aos fundadores e proprietários uma ferramenta para melhorar a qualidade do suporte à infraestrutura de TI. Um produto que deve ajudar os proprietários a proteger seus negócios, mas que, ao mesmo tempo, aumentará a carga de trabalho das pessoas responsáveis pela TI. Um produto que forneça à empresa uma ferramenta para controlar a qualidade do suporte de TI.

Como resultado do processamento dos dados obtidos, nasceu a primeira lista de requisitos (um esboço de backlog) para o futuro produto:

o sistema de monitoramento deve ser baseado em uma solução de código aberto e, como consequência, ser barata;
deve ser simples e rápida de instalar;
não deve exigir conhecimentos específicos em TI, até mesmo um contador (de forma alguma gostaria de ofender os representantes dessa profissão) deve ser capaz de implementar e configurar o sistema;
deve detectar automaticamente os objetos a serem monitorados na rede;
deve instalar automaticamente (ou idealmente, de forma autônoma) os agentes de monitoramento;
deve ter a capacidade de monitorar serviços externos, pelo menos um sistema CRM e um site de vendas;
deve notificar tanto a empresa quanto o administrador de sistemas sobre falhas;
o nível de profundidade e a ‘linguagem’ das notificações devem ser diferentes para o administrador e para a empresa;
o sistema deve ser fornecido em hardware próprio;
o hardware deve ser o mais acessível possível;
o sistema deve ser o mais independente possível de fatores externos.

Em seguida, foram calculados os investimentos para o desenvolvimento do produto (incluindo o tempo de trabalho dos funcionários do departamento técnico). Um esboço do modelo de negócio foi preparado e a economia de unidade do produto foi calculada.

Resultado da fase:

backlog de produto de alto nível;
modelo de negócio formulado ou hipótese de escala, que ainda precisa ser verificada na prática.

Vamos para a próxima fase — a concepção. Aqui, como engenheiros, nos sentimos em casa. Há "desejos" que são decompostos em componentes/subsistemas/recursos, depois se transformam em requisitos técnicos/histórias de usuários, depois em projeto, e assim por diante. Não vou entrar em detalhes sobre o processo de preparação de um conjunto de alternativas, vamos direto aos requisitos e às formas escolhidas para sua implementação.

Requisito
Solução

Deve ser um sistema de monitoramento aberto;

Vamos pegar um sistema de monitoramento de código aberto.

O sistema deve ser simples e rápido de instalar;
não deve exigir conhecimentos específicos em TI. Até um contador deve ser capaz de implementar e configurar o sistema.

Oferecemos um sistema pré-instalado, para que o usuário só precise ligá-lo e ajustar um pouco, semelhante a um roteador.

Vamos restringir a interação com o dispositivo a algo simples e compreensível para todos.

Vamos escrever nosso próprio chatbot para um dos mensageiros conhecidos e direcionar toda a interação com o sistema para ele.

O sistema deve:

descobrir automaticamente os objetos que precisam ser monitorados na rede;
instalar automaticamente agentes de monitoramento;
Ter a capacidade de monitorar serviços externos, pelo menos sistemas CRM e sites de vendas.

Escrevemos complementos para o sistema de monitoramento sobre:

detecção automática de objetos;
instalação automática de agentes;
monitoramento da disponibilidade de serviços externos.

O sistema deve:

aviso sobre falhas tanto para o negócio quanto para o administrador do sistema;
ter a capacidade de monitorar serviços externos, pelo menos sistemas CRM e sites de vendas. O nível de profundidade e a "linguagem" de avisos devem ser diferentes para o administrador e para o negócio.
O sistema não deve exigir conhecimentos específicos em TI, até um contador deve ser capaz de implementar e configurar o sistema.

Adicionaremos diferentes tipos de notificações para diferentes categorias de usuários. Eles variam na forma de apresentação e profundidade. O usuário empresarial receberá notificações do tipo "tudo está bem, mas o computador de Ivanov logo irá falhar". O administrador receberá uma mensagem completa sobre o erro, identificando quem, como e o que ocorreu ou pode ocorrer.
Adicionaremos a possibilidade de utilizar o e-mail de um responsável adicional, para que, em caso de falha, ele receba uma notificação.
Implementaremos a interação com fornecedores de serviços externos por meio do envio de e-mails com texto pré-preparado, pois é exatamente o e-mail que fundamenta a abertura de um incidente.
Toda a interação com o sistema será centralizada em um chatbot, facilitando a comunicação em estilo de diálogo.

Adicional:

Adicionaremos a funcionalidade de "chat com o administrador", permitindo que o usuário envie uma mensagem ao administrador com a descrição do problema diretamente.

O sistema deve ser fornecido em hardware próprio.
O hardware deve ser acessível.
O sistema deve ser o mais independente possível do ambiente.

Usaremos um computador Raspberry PI barato e pronto.
Projetaremos uma placa de fornecimento ininterrupto de energia.
Adicionaremos um modem para independência do estado da rede local.
Projetaremos uma caixa bonita.

Temos três subsistemas com suas próprias exigências e visões de implementação:

subsistema de hardware;
subsistema de monitoramento;
subsistema de interação com o usuário.

Para o subsistema de hardware, desenvolvemos um projeto preliminar. Sim, sim! Ignorando todas as regras de agilidade, elaboramos um documento, porque as fábricas operam exatamente com documentos. Para os outros subsistemas, definimos os usuários (personas), preparamos histórias de usuários e redigimos tarefas para desenvolvimento.

Aqui termina a fase de conceito, e seus resultados foram:

um projeto para a plataforma de hardware;
uma visão formulada na forma de histórias de usuários para os outros dois subsistemas;
um protótipo da parte de software, realizado na forma de uma máquina virtual;
um protótipo da parte de hardware, realizado na forma de um estande, onde as soluções de hardware foram testadas para resistência;
testes realizados por nossos administradores.

Os problemas nesta fase foram principalmente organizacionais e relacionados à falta de familiaridade da equipe de engenharia com os aspectos legais e contábeis das vendas. Ou seja, é uma coisa pensar sobre o que e como vender, e outra totalmente diferente enfrentar a implacável máquina jurídica: patentes, tarefas de desenvolvimento, registro de ativos, EULA e muitos outros fatores que nós, como pessoas criativas, não consideramos inicialmente.

Ainda não era um problema, mas sim uma dificuldade relacionada ao projeto das carcaças. Em nossa equipe, somos apenas engenheiros, então a primeira versão da carcaça foi 'esculpida' em acrílico pelo nosso especialista em eletrônica.

A carcaça parecia, para dizer o mínimo, controversa, especialmente para um público acostumado com a tecnologia moderna. Claro que surgiram alguns apreciadores entre os 'culibins' da velha geração — a carcaça lhes trouxe sentimentos de nostalgia. Decidimos fabricar e projetar uma nova carcaça, pois a antiga, além de deficiências estéticas, apresentava também problemas estruturais — o acrílico não suportava bem a montagem e desmontagem do dispositivo e tinha tendência a trincar. Sobre a produção da carcaça, falarei a seguir.

E assim nos aproximamos da reta final - o MVP. Claro, este ainda não é o produto final em série, mas já traz benefícios e representa valor. O principal objetivo desta fase é iniciar o ciclo 'criar-avaliar-aprender'. É exatamente nesta fase que o LANBIX se encontra.

Na fase de 'criação', criamos um dispositivo que executa a funcionalidade prometida. Sim, ainda não é perfeito, e continuamos a aprimorá-lo.

Retornamos à fabricação da carcaça, ou seja, à tarefa de transformar nosso dispositivo de algo que provoca sentimentos nostálgicos em algo moderno. Primeiro, pesquisei o mercado em busca de fabricantes de carcaças e serviços de design industrial. Em primeiro lugar, há poucas empresas que fabricam carcaças no mercado russo, e em segundo lugar, o custo do design industrial nesta fase é exorbitante, cerca de 1 milhão de rublos.

A design was developed by our marketing department, where a young designer was ready for creative experimentation. We presented our vision for the case (having first studied the best examples of case construction), and he transformed it into a work of art. All that was left was to manufacture it. Proud of our design, we approached our partners. Their CEO instantly shattered our dreams by pointing out the impossibilities of producing it the way we had chosen, completely free of charge. The case can be produced and will be no worse than Apple's, but the cost will be three to four times higher than all the electronic components combined. After a series of operations and approvals, we designed a case that can be manufactured. Yes, it’s not as beautiful as we had planned, but it is ideal for achieving our current goals.

Resultado da fase: o primeiro lote de dispositivos prontos para combate e testes.

E agora vem a parte mais difícil — a fase de ‘avaliar’, e com nosso produto estamos exatamente nesse ponto. Podemos avaliar apenas com base nos resultados do uso por clientes reais, e nenhuma suposição funciona aqui. Precisamos dos chamados ‘early adopters’ para fornecer feedback e implementar as mudanças necessárias no produto. Surge a pergunta: como conseguir clientes e convencê-los a participar do experimento?

Dentre todas as opções possíveis, escolhemos um conjunto clássico de ferramentas digitais: uma landing page e uma campanha publicitária nas redes sociais.

O processo já foi iniciado, mas ainda é cedo para falar sobre resultados, embora já tenhamos recebido feedback e confirmação de muitas de nossas hipóteses. Uma grata surpresa foi a reação de representantes de segmentos de negócios totalmente diferentes, muito maiores do que aqueles em que contávamos. Seria tolice ignorar essas novas informações, e com base nos resultados das entrevistas realizadas, decidimos lançar uma linha paralela LANBIX chamada LANBIX Enterprise. Adicionamos suporte para infraestruturas distribuídas, monitoramento de redes Wi-Fi com busca e localização de falhas, monitoramento da qualidade dos canais de comunicação. As empresas de serviços expressaram o maior interesse na solução. Ao mesmo tempo, os dispositivos que já desenvolvemos desempenham um papel importante na execução das soluções.

O que vem a seguir

O que acontecerá a seguir com o LANBIX original será compreendido após os resultados da campanha. Caso nossas hipóteses não se confirmem, de acordo com a metodologia Lean, iremos eliminá-lo sem piedade ou ele se transformará em algo novo, pois não há nada pior do que criar um produto que ninguém precisa. Mas já é possível afirmar que o trabalho realizado não foi em vão e, graças a isso, surgiu toda uma linha de produtos paralelos, sobre os quais estamos trabalhando ativamente. Em caso de sucesso, o LANBIX passará da fase de MVP para a fase final e se desenvolverá de acordo com as claras leis clássicas do marketing de produtos.

Reitero, agora queremos encontrar seguidores iniciais, empresas que possam instalar nosso produto com o objetivo de coletar feedback. Se você estiver interessado em testar o LANBIX, deixe um comentário ou envie uma mensagem privada.

Fonte

Fonte: habr.com

Como trabalhamos com ideias e como nasceu a LANBIX