🥇Como trabalhamos com ideias e como nasceu a LANBIX

Existem muitos funcionários criativos na LANIT-Integration. Ideias para novos produtos e projetos estão literalmente pairando no ar. Às vezes pode ser muito difícil identificar os mais interessantes. Portanto, juntos desenvolvemos nossa própria metodologia. Leia este artigo sobre como selecionar os melhores projetos e implementá-los.

Na Rússia e no mundo como um todo, estão ocorrendo vários processos que levam à transformação do mercado de TI. Graças ao aumento do poder computacional e ao surgimento de servidores, redes e outras tecnologias de virtualização, o mercado não necessita mais de uma grande quantidade de hardware. Os fornecedores preferem cada vez mais trabalhar diretamente com os clientes. O mercado de TI está passando por um boom na terceirização em todas as suas formas, desde a terceirização clássica até a nova onda de terceirizadores – “provedores de nuvem”. Os sistemas e elementos de infraestrutura tornam-se muito mais fáceis de manter e configurar. A qualidade do software cresce a cada ano e as tarefas do integrador estão se transformando.

Como trabalhamos com ideias

Direção de inicialização do produto em "Integrações LANIT" existe há mais de um ano. Nosso principal objetivo é criar novos produtos e trazê-los ao mercado. A primeira coisa que começamos foi organizar o processo de criação dos produtos. Estudamos muitas metodologias, das clássicas às exageradas. No entanto, nenhum deles atendeu às nossas necessidades. Decidimos então tomar como base a metodologia Lean Startup e adaptá-la às nossas tarefas. A Lean Startup é uma teoria de empreendedorismo criada por Eric Ries. Baseia-se nos princípios, abordagens e práticas de conceitos como manufatura enxuta, desenvolvimento de clientes e metodologia de desenvolvimento flexível.

Quanto à abordagem direta à gestão do desenvolvimento de produtos: não reinventamos a roda, mas aplicamos uma metodologia de desenvolvimento já existente SCRUM, adicionando criatividade, e agora pode ser chamado com segurança de SCRUM-WATERFALL-BAN. O SCRUM, apesar de sua flexibilidade, é um sistema bastante rígido e adequado para gerenciar uma equipe responsável por apenas um produto/projeto. Como você entende, o clássico negócio de “integração” não envolve a atribuição de especialistas técnicos em tempo integral para trabalhar em um projeto (há exceções, mas extremamente raramente), pois além de trabalhar nos produtos, todos estão ocupados com os projetos atuais. Do SCRUM tiramos a divisão do trabalho em sprints, relatórios diários, retrospectivas e funções. Escolhemos Kanban para nosso fluxo de tarefas e ele se integrou bem ao nosso sistema existente de rastreamento de tarefas. Estruturamos nosso trabalho integrando-nos perfeitamente à ordem existente das coisas.
Antes de entrar no mercado, um produto passa por 5 etapas: ideia, seleção, conceito, MVP (mais detalhes abaixo) e produção.

Idéia

Nesta fase há algo efémero – uma ideia. Idealmente, uma ideia para resolver um problema existente ou um problema do cliente. Não nos faltam ideias. De acordo com o plano inicial, deveriam ser gerados por funcionários de áreas técnicas. Para que uma ideia seja aceita para posterior desenvolvimento, o autor deverá preencher o “Modelo de Design de Ideia”. Existem apenas quatro perguntas: O quê? Para que? Quem precisa disso? E se não for o nosso produto, então o quê?

Fonte

Seleção

Assim que o modelo preenchido chegar até nós, inicia-se o procedimento de processamento e seleção. A etapa de seleção é a mais trabalhosa. Nesta fase formam-se as hipóteses de problemas (não foi à toa que mencionei no parágrafo anterior que o ideal é que uma ideia resolva o problema de um cliente) e o valor do produto. Uma hipótese de escala é formada, ou seja, como nosso negócio vai crescer e prosperar. Entrevistas sobre problemas e especialistas são realizadas com clientes em potencial para fornecer uma confirmação preliminar de que produziremos algo necessário. São necessárias pelo menos 10 a 15 entrevistas para chegar a uma conclusão sobre a necessidade do produto.

Se as hipóteses se confirmarem, é realizada uma análise financeira preliminar, avaliado o volume aproximado de investimento e os possíveis ganhos do investidor. Como resultado desta etapa, nasce e é apresentado à gestão um documento chamado Lean Canvas.

Conceito

Nesta fase, cerca de 70% das ideias são eliminadas. Se o conceito for aprovado, inicia-se a etapa de desenvolvimento da ideia. A funcionalidade do futuro produto é formada, os caminhos de implementação e as soluções técnicas ideais são determinados e o plano de negócios é atualizado. O resultado desta etapa é uma especificação técnica para desenvolvimento e um business case detalhado. Se tiver sucesso, passamos para o estágio de MVP ou MVP.

MVP ou MVP

MVP é um produto mínimo viável. Aqueles. um produto que não está totalmente desenvolvido, mas que já pode agregar valor e cumprir sua funcionalidade. É imperativo que nesta fase de desenvolvimento coletemos feedback de usuários reais e façamos alterações.

fabrico

E a última etapa é a produção. Não mais que 5% dos produtos atingem esse estágio. Estes 5% incluem apenas os produtos mais importantes, necessários, viáveis e funcionais.

Temos muitas ideias e já montamos um volumoso portfólio. Analisamos cada ideia e fazemos tudo para que chegue à fase final. É muito agradável que os nossos colegas não tenham ficado indiferentes à nossa orientação de I&D e tenham participado ativamente no desenvolvimento e implementação de produtos e soluções.

Como fizemos LANBIX

Vejamos a criação de um produto usando um exemplo real - o produto LANBIX. Este é um sistema de software e hardware “embalado” projetado para monitorar pequenas infraestruturas de TI e alertar prontamente os tomadores de decisão e usuários empresariais sobre problemas de funcionamento controlados por meio de um chatbot. Além da função de monitoramento, LANBIX inclui funcionalidade de Help Desk. Este produto é exclusivo para o segmento de mercado que visamos. Esta é nossa vantagem e nossa dor. Mas primeiro as primeiras coisas. Direi desde já que LANBIX é um produto vivo (ou seja, não é definitivo em seu desenvolvimento e está na próxima rodada de MVP).

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

Uma pequena empresa de gestão mantém duas casas na região de Moscou. A equipe com PCs é de cerca de 15 pessoas. O administrador do sistema é um freelancer visitante (o filho inteligente de um dos residentes atenciosos). Parece que as atividades da sociedade gestora são pouco dependentes de TI, mas a peculiaridade deste negócio é o reporte mensal a muitas autoridades. O disco do sistema do chefe da empresa (que, como sempre, combina muitas funções) ficou sem espaço livre. Naturalmente, isso não aconteceu de repente: o aviso ficou suspenso por cerca de 2 meses e foi constantemente ignorado. Mas chegou uma atualização, o sistema operacional foi atualizado e, por sorte, travou no meio da atualização, reclamando antes da “morte” de um disco ocupado. O computador entrou em uma reinicialização cíclica. Enquanto resolvíamos o problema e recebíamos relatórios, perdemos o prazo de entrega do relatório. Parece que um mau funcionamento trivial causou vários problemas: desde perdas até litígios e responsabilidades administrativas.

Fonte

Incidente semelhante ocorreu em uma grande holding, que reúne muitas 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. Há muito se sabia que poderia quebrar (o computador ficava desesperadamente lento e esquentando), mas o contador-chefe nunca teve tempo de enviar uma solicitação ao suporte técnico. Naturalmente, ele quebrou exatamente no dia do pagamento e os funcionários do departamento ficaram vários dias sem dinheiro.

Uma pequena empresa do pequeno comércio atacadista possuía um site de vendas, hospedado em uma plataforma externa. Aprendemos sobre sua indisponibilidade por telefone com um cliente regular. No momento da ligação, o site estava fora do ar há cerca de três horas. Demorou mais algumas horas para encontrar o responsável pelo site e outras duas para resolver o problema. Assim, o site ficou indisponível durante quase todo o dia útil. Segundo o diretor comercial da empresa, esse tempo de inatividade custou-lhes cerca de 1 milhão de rublos.

Eu mesmo me deparei com uma situação semelhante quando cheguei a uma consulta na clínica e tive que ir ao registro do VHI. Não puderam me mandar ao médico por um motivo banal - houve uma queda de energia pela manhã e depois do acidente o serviço postal e um determinado serviço de comunicação com a seguradora não funcionaram. Em resposta à minha pergunta, onde estão seus administradores, fui informado que o administrador deles vem visitá-los uma vez por semana. E agora (naquela hora já eram 16h) ele não atende o telefone. Durante pelo menos 00 horas, a clínica ficou isolada do mundo exterior e não pôde prestar serviços pagos.

O que todos esses casos têm em comum? Absolutamente todos os problemas poderiam ter sido evitados antecipadamente. Com uma resposta oportuna do pessoal de TI, os danos poderiam ter sido reduzidos. Isto seria possível se os primeiros sintomas fossem corretamente interpretados pelos usuários.

Identificamos hipóteses de problema:

perdas monetárias e reputacionais significativas devido à baixa velocidade de resposta a falhas na infraestrutura de TI;
interpretação errônea dos primeiros sintomas de mau funcionamento por parte dos usuários.

O que o cliente pode fazer com eles e como evitar situações semelhantes no futuro? Não há muitas opções:

contratar um administrador de sistema altamente qualificado e fazê-lo trabalhar com consciência;
terceirizar a manutenção de TI para uma empresa de serviços especializada;
implementar de forma independente um sistema de monitoramento e relatório de falhas;
fornecer treinamento aos usuários/pessoal de negócios nos fundamentos da alfabetização em informática.

Vamos decidir pela terceira opção. Vamos oferecer um sistema de monitoramento para quem não o utiliza por diversos motivos.

Digressão lírica. Vários sistemas de monitoramento de serviços de TI no mercado empresarial têm sido utilizados há muito tempo e seus benefícios não são contestados. Conversei com representantes de grandes empresas, observei como foi construída a relação entre negócios e TI. O diretor técnico de uma grande empresa de construção de máquinas terceirizou a manutenção da infraestrutura de TI para uma empresa externa, mas ele próprio permanece informado sobre todos os assuntos. Em seu escritório há uma grande tela do sistema de monitoramento com indicadores do status dos serviços de TI. Os mais críticos estão incluídos no sistema. A qualquer momento, o diretor técnico pode saber qual é o estado da infraestrutura, o que está acontecendo, onde está o problema, se os responsáveis foram notificados e se o problema está sendo resolvido.

As histórias listadas acima fizeram nossa equipe pensar em como criar um sistema de monitoramento ideal para pequenas empresas. Como resultado, nasceu o LANBIX - um sistema de monitoramento que pode ser implantado por qualquer pessoa sem nenhum conhecimento de TI. O principal objetivo do sistema é simples, como todos os sistemas que visam aumentar a continuidade e a disponibilidade - reduzindo perdas monetárias e outras em caso de paralisação não planejada. O dispositivo foi projetado para reduzir ao mínimo o tempo entre “algo está quebrado” e “o problema foi resolvido”.

Para confirmar as hipóteses, foram realizadas entrevistas problema. Eu não conseguia imaginar o quanto as pessoas estariam dispostas a contar sem tentar vender para elas. Cada conversa durou pelo menos 1,5 horas e recebemos muitas informações úteis para um maior desenvolvimento.

Vamos resumir os resultados desta etapa:

há uma compreensão do problema,
compreensão do valor - existe,
Existe uma ideia para uma solução.

A segunda etapa foi mais detalhada. Com base nos seus resultados, tivemos que apresentar à gestão, que desempenha essencialmente o papel de investidor, um business case (o mesmo Lean Canvas) para tomar uma decisão sobre o destino futuro do produto.

Começamos com pesquisas de mercado e análises competitivas para saber quem, o que e, o mais importante, como estão se saindo neste mercado.

Aconteceu o seguinte.

Não existem no mercado sistemas de monitoramento in a box prontos para o nosso segmento (pequenas empresas), com exceção de alguns ou três, dos quais não falarei por motivos óbvios.
Nossos principais concorrentes, curiosamente, são administradores de sistemas com scripts escritos em casa e “complementos” para sistemas de monitoramento de código aberto.
Há um problema claro no uso de sistemas de monitoramento de código aberto. Existe um sistema, existe uma enorme quantidade de informações sobre como trabalhar e modificar o sistema para atender às suas necessidades. Dos administradores que entrevistei, muitos admitiram que não tinham competências suficientes para implementar as suas ideias por si próprios. Mas eles não podem admitir isso à administração por medo de serem demitidos. Acontece que é um círculo vicioso.

Passamos então a analisar as necessidades de nossos clientes potenciais. Identificamos para nós mesmos um segmento de pequenas organizações que, por algum motivo, não possuem seu próprio serviço de TI, onde um novo administrador de sistema, um freelancer ou uma empresa de serviços é responsável pela TI. Não foi o lado de TI que decidiu entrar, mas sim o lado empresarial, oferecendo aos fundadores e empresários uma ferramenta para melhorar a qualidade do serviço de infraestrutura de TI. Um produto que deve ajudar os proprietários a proteger seus negócios, mas ao mesmo tempo agregará trabalho aos responsáveis pela TI. Um produto que fornece às empresas uma ferramenta para monitorar a qualidade do suporte de TI.

Como resultado do processamento dos dados recebidos, nasceu a primeira lista de requisitos (uma espécie de backlog aproximado) para o futuro produto:

o sistema de monitoramento deve ser baseado em uma solução de código aberto e, consequentemente, barata;
fácil e rápido de instalar;
não deveria exigir conhecimentos específicos em TI, mesmo um contador (de forma alguma quis ofender os representantes desta profissão) deveria ser capaz de implantar e configurar o sistema;
deve detectar automaticamente objetos para monitoramento na rede;
deve instalar automaticamente (e idealmente automaticamente) agentes de monitoramento;
deve ser capaz de monitorar serviços externos, pelo menos um sistema de CRM e um site de vendas;
deve notificar tanto a empresa quanto o administrador do sistema sobre problemas;
o grau de profundidade e “linguagem” dos alertas deve ser diferente para o administrador e para a empresa;
o sistema deve ser fornecido em hardware próprio;
o ferro deve ser o mais acessível possível;
o sistema deve ser tão independente quanto possível de fatores externos.

Em seguida, foram calculados os investimentos em desenvolvimento de produtos (incluindo custos trabalhistas para funcionários do departamento técnico). Foi elaborado um esboço do modelo de negócios e calculada a economia unitária do produto.

Resultado da etapa:

backlog de produtos de alto nível;
um modelo de negócios formulado ou hipótese de escala que ainda não foi testada na prática.

Vamos para a próxima etapa - conceito. Aqui nós, como engenheiros, nos encontramos em nosso elemento nativo. Existem “listas de desejos” que são decompostas em componentes/subsistemas/recursos, depois transformadas em especificações técnicas/histórias de usuários, depois em um projeto, etc. Não me deterei em detalhes sobre o processo de preparação de um conjunto de opções alternativas; passaremos diretamente aos requisitos e aos métodos escolhidos para a sua implementação.

Requisito
Solução

Deveria ser um sistema de monitorização aberto;

Adotamos 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 de TI. Até mesmo um contador deve ser capaz de implantar e configurar o sistema.

Oferecemos um sistema instalado para que o usuário só precise ligar o aparelho e configurá-lo um pouco, semelhante a um roteador.

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

Vamos escrever nosso próprio chatbot para um dos conhecidos mensageiros instantâneos e transferir para ele todas as interações com o sistema.

O sistema deve:

detectar automaticamente objetos necessários para monitoramento na rede;
instalar automaticamente agentes de monitoramento;
Ser capaz de monitorar serviços externos, pelo menos um sistema de CRM e um site de vendas.

Escrevemos complementos para o sistema de monitoramento para:

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

O sistema deve:

notificar a empresa e o administrador do sistema sobre problemas;
ser capaz de monitorar serviços externos, pelo menos um sistema de CRM e um site de vendas. O grau de profundidade e “linguagem” das notificações deve ser diferente para o administrador e para a empresa.
O sistema não deve exigir conhecimentos específicos de TI; até mesmo um contador deve ser capaz de implantar e configurar o sistema.

Vamos adicionar diferentes tipos de notificações para diferentes tipos de usuários. Eles diferem em tom e profundidade. Um usuário empresarial receberá notificações como “está tudo bem, mas o computador de Ivanov irá morrer em breve”. O administrador receberá uma mensagem completa sobre o erro, quem, como e o que aconteceu ou pode acontecer.
Vamos adicionar a possibilidade de utilizar o correio de um responsável adicional, para que em caso de avaria ele receba uma mensagem.
Vamos agregar interação com prestadores de serviços externos a partir do envio de e-mails com texto pré-preparado, pois É o e-mail que dá origem ao incidente.
Toda a interação com o sistema será conectada a um chatbot; a comunicação é realizada em estilo de diálogo.

Adição:

Vamos adicionar a funcionalidade de “bate-papo com o administrador” para que o usuário possa enviar ao administrador uma mensagem descrevendo o problema diretamente.

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

Vamos pegar um computador Raspberry PI barato e pronto.
Projetaremos uma placa de fonte de alimentação ininterrupta.
Vamos adicionar um modem que seja independente do estado da rede local.
Vamos projetar um lindo edifício.

Temos agora três subsistemas com requisitos e visão próprios para a sua implementação:

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

Desenvolvemos um projeto preliminar para o subsistema de hardware. Sim Sim! Tendo violado todas as regras do ágil, desenvolvemos um documento, pois as fábricas trabalham com documentos. Para os demais subsistemas, identificamos usuários (pessoas), preparamos histórias de usuários e escrevemos tarefas para desenvolvimento.

Isso conclui a fase de conceito e o resultado é:

projeto de plataforma de hardware;
visão formulada na forma de histórias de usuários para os dois subsistemas restantes;
um protótipo de software implementado como máquina virtual;
um protótipo do hardware, implementado em forma de estande, onde as soluções de hardware foram efetivamente testadas quanto à resistência;
testes realizados por nossos administradores.

Os problemas nesta fase foram maioritariamente organizacionais e relacionados com a falta de conhecimento do pessoal de engenharia nos aspectos jurídicos e contabilísticos das vendas. Aqueles. Uma coisa é descobrir o que e como vender, e outra bem diferente é enfrentar uma máquina legal implacável: patentes, tarefas de desenvolvimento, registro, EULA e muito mais que nós, como pessoas criativas, não levamos inicialmente em consideração.

Ainda não havia um problema, mas sim uma dificuldade associada ao desenho dos recintos. Nossa equipe é formada apenas por engenheiros, então a primeira versão do case foi “construída” em plexiglass pelo nosso especialista em eletrônica.

O corpo parecia, para dizer o mínimo, controverso, principalmente para o público, estragado pela tecnologia moderna. É claro que havia conhecedores entre a geração mais velha de “Kulibins” - o edifício evocava neles sentimentos nostálgicos. Optou-se por fabricar e projetar o case novamente, já que o antigo, além das falhas estéticas, também apresentava falhas estruturais - o plexiglass não tolerava bem a montagem e desmontagem do aparelho e tendia a rachar. Vou falar mais sobre a produção do case.

E agora estamos perto da linha de chegada – MVP. Claro, este ainda não é um produto final de produção, mas já é útil e valioso. O principal objetivo desta etapa é lançar o ciclo “criar-avaliar-aprender”. Este é exatamente o estágio em que a LANBIX se encontra.

Na etapa “criar”, criamos um dispositivo que executa a funcionalidade declarada. Sim, ainda não está perfeito e continuamos a trabalhar nisso.

Voltemos à fabricação do corpo, ou seja, à tarefa de transformar nosso dispositivo de nostálgico em moderno. No início, vasculhei o mercado em busca de fabricantes de gabinetes e serviços de design industrial. Em primeiro lugar, não existem muitas empresas que produzem caixas no mercado russo e, em segundo lugar, o custo do desenho industrial nesta fase é proibitivamente elevado, cerca de 1 milhão de rublos.

Eles contataram nosso departamento de marketing para o design; o jovem designer estava pronto para experiências criativas. Delineamos a nossa visão do casco (tendo previamente estudado os melhores exemplos de construção de casco), e ele, por sua vez, transformou-o numa obra de arte. Resta apenas produzi-lo. Nós, orgulhosos do nosso design, recorremos aos nossos parceiros. O CEO deles imediatamente esmagou nossas fantasias ao apontar, de forma totalmente gratuita, coisas que não poderiam ser produzidas da maneira que escolhemos. O case pode ser produzido e não será pior que o da Apple, mas o custo do case será três a quatro vezes mais caro do que todos os componentes eletrônicos. Após uma série de operações e aprovações, projetamos uma carcaça que pode ser fabricada. Sim, não é tão bonito quanto planejamos, mas é ideal para atingir os objetivos atuais.

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

E agora o mais difícil é a etapa de “avaliar”, e com o nosso produto estamos exatamente neste ponto. Só podemos avaliar com base nos resultados do uso por clientes reais e nenhuma suposição funciona aqui. Precisamos que esses “pioneiros” forneçam feedback e façam as alterações realmente necessárias no produto. Surge a pergunta: onde conseguir clientes e como convencê-los a participar do experimento?

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

O processo já foi lançado, mas ainda é cedo para falar em resultados, embora já haja respostas e tenhamos recebido a confirmação de muitas das nossas hipóteses. Uma agradável surpresa foi a reação de representantes de segmentos de negócios completamente diferentes, muito maiores do que esperávamos. Seria tolice ignorar as novas introduções e, com base nos resultados das entrevistas, decidiu-se lançar uma linha LANBIX paralela chamada LANBIX Enterprise. Adicionamos suporte para infraestruturas distribuídas, monitoramento de redes Wi-Fi com solução de problemas e localização e monitoramento da qualidade dos canais de comunicação. As empresas de serviços manifestaram o maior interesse na solução. Ao mesmo tempo, os dispositivos que já desenvolvemos desempenham um papel importante no funcionamento das soluções.

O que acontecerá depois?

O que acontecerá a seguir com o LANBIX original ficará claro com base nos resultados da campanha. Se nossas hipóteses não se confirmarem, segundo a metodologia Lean, nos livraremos dele implacavelmente ou se transformará em algo novo, pois não há nada pior do que fazer um produto que ninguém precisa. Mas agora podemos dizer que o trabalho realizado não foi em vão e graças a ele surgiu todo um ramo de produtos paralelos, nos quais estamos trabalhando ativamente. Se for bem-sucedido, o LANBIX passará do estágio MVP para o estágio final e se desenvolverá de acordo com as leis clássicas compreensíveis do marketing de produto.

Repito, agora queremos encontrar pioneiros, empresas que possam instalar nosso produto para coletar feedback. Se você estiver interessado em testar o LANBIX, escreva nos comentários ou mensagens privadas.

Fonte

Fonte: habr.com

Como trabalhamos com ideias e como nasceu a LANBIX