Product assortment / Feature Flags #1525
Replies: 2 comments
-
|
Muito boa tua pergunta! Vou trazer alguns pontos para a discussão.
Na experiência que eu tive, o mais vantajoso é sempre pensar em extensões do produto em si. Por exemplo, se um cliente precisa de uma tela com o botão azul. Ao invés de fazer a funcionalidade tela com botão azul, tentamos fazer a funcionalidade parametrização da cor do botão. A vantagem disso é que além de resolvermos o problema do cliente, o produto passa a ganhar uma nova funcionalidade que pode ser útil para outros clientes. Me parece que no caso do teu time (produto mais enterprise, como tu mesmo disse) pode fazer sentido esse tipo de pensamento.
Talvez nos lugares que tu tenha lido as pessoas podem ter usado o termo feature flag como algo experimental (já li uns posts da Uber chamando de experimentation para esses casos) e que serve para algumas tomadas de decisão (teste A/B, por exemplo). Sendo bem prático, tu pode usar sim um conjunto de feature flags (ou feature toggles) para customizar a experiência dos teus clientes. Isso vai desde habilitar funcionalidades inteiras até coisas mais beta e por aí vai. Acho que a parte mais difícil é dar os nomes corretos para cada coisa. Por exemplo: features para o conjunto de funciondalidades, experimentation para coisas que ainda estão incertas, customizations para parametrizações e aí vai. Teus clientes podem "nascer" com as features mais básicas e, conforme os critérios de vocês, terem as outras features habilitadas (seja por pagar um plano, seja algo promocional, aí vai).
Trabalho hoje em um produto que é mexido por vários times diferentes. Porém, sempre tínhamos dor de cabeça para fazermos os deployments (ficávamos fazendo um malabarismo de branches para poder fechar nossas releases). Sempre dava confusão pois tinham coisas que ainda não estavam prontas indo para produção. Passamos a usar feature flags para resolver alguns desses problemas. Tudo que ainda não está pronto ou ainda está sendo testado (em produção também) é controlado por uma feature flag. Posteriormente, podemos habilitar para alguns dos nossos clientes ou escolher habilitar para todos. Se der algum problema em produção, desabilitamos. Se a feature virar oficial, podemos remover a condição para exibí-la posteriormente (habilitando por padrão na aplicação). Usamos um sisteminha feito "em casa" para esse controle. Mas existem algumas soluções por aí que podem te ajudar. Particularmente, acho bem interessante esse projeto aqui, porém, nunca coloquei o mesmo em produção: https://github.com/checkr/flagr Acabei escrevendo um textão hahaha. Se tiver alguma dúvida, só comenta aqui! |
Beta Was this translation helpful? Give feedback.
-
|
@wmartins Cara, excelente resposta! Obrigado. Complementando a discussão. Eu vi mais de um exemplo de SaaS desse tipo de solução e algumas soluções enterprise. Pelo menos no meu ponto de vista, o ideal é um sistema que tenha uma boa segmentação. Para que a gente possa criar diferentes tipos de grupos e assim as features serem entregues para os clientes certos. Acho que irei fazer uma POC com o LaunchDarkly e ver como ele se sai. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Pessoal, como vocês gerenciam product assortment / feature flags na empresa de vocês? Estamos com uma demanda para construir funcionalidades específicas para cada cliente (trabalho em um produto mais enterprise) e estou bem perdido em como gerenciar essas features.
O objetivo é que o produto não fique complexo e cheio de funcionalidade na tela para clientes mais "básicos". Não sei se feature flags é um bom caminho também, pois li que o ideal é que elas fiquem ativas somente por um tempo.
Já implementaram esse tipo de coisa no produto onde trabalham?
Beta Was this translation helpful? Give feedback.
All reactions