Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
ARCH-NOTIFIER por Mind Map: ARCH-NOTIFIER

1. ① Estratégia do produto

1.1. O que é, do que se trata o produto

1.1.1. Aplicação de envio de notificações em aplicações terceiras, dos clientes que comprarem o produto. Poderá atender inúmeras aplicações diferentes em diversos tipos de devices. Deve suportar a evolução futura para envio de Whatsapp, Telegram entre outros.

1.2. Como será monetizado

1.2.1. Venda de pacotes de assinatura para envio de mensagem, por tipo de destino e por volume de mensagens

1.3. Para quem será desenvolvido

1.3.1. Persona digital

1.3.1.1. B2B, empresas que desejam automatizar o envio de notificações e mensagens em uma plataforma simples, estável, segura e aderente a LGPD

1.3.1.2. Dores

1.3.1.2.1. Custos de ferramentas como esta no mercado são elevadas

1.3.1.2.2. As melhores são internacionais cobradas em dolares

1.3.1.2.3. Em geral não suportam pagamento por tipo de mensagem enviada

1.3.1.3. Preocupações

1.3.1.3.1. Mensagens perdidas ou não entregues

1.3.1.3.2. Envio de mensagens para usuários (clientes do cliente) que não tenham aprovado a recepção

1.3.1.4. Desejos

1.3.1.4.1. Ferramenta simples de manusear

1.3.1.4.2. Fácil de implantar

1.3.1.4.3. Suporte a várias formas de integração

1.3.1.4.4. Custo baixo

1.3.1.4.5. Pagar um preço justo pelo tipo e volume de mensagens que vai utilizar

1.4. Como será disponibilizado

1.4.1. O portal de configuração deverá rodar em um portal WEB, suportando PWA para devices Google que suportem a tecnologia, de 2019 em diante. O destino final poderá ser devices antigos que suportem SMS ou Push notification

1.5. Volume de usuários simultâneos estimado

1.5.1. Indefinido, o cliente pode customizar

1.6. Tempestividade de usuários simultâneos estimado

1.6.1. Não há limites quanto mais melhor, entretanto o custo deve ser elástico, ou seja, caso haja a perda de clientes é desejo que os custos sejam também reduzidos

1.7. Como será mantido

1.7.1. Por quem?

1.7.1.1. Equipe Interna

1.7.2. SLAs de suporte

1.7.2.1. Até 24 horas úteis

1.8. Principais preocupações

1.8.1. Garantir que as mensagens sejam entregues

1.8.2. A operação de um cliente não deve impactar a de outro

1.8.3. O Vazamento de informações pode acabar com o negócio (branding e financeiro)

1.8.4. Um cliente jamais deve ter acesso a dados de outro cliente

1.9. Principais desejos

1.9.1. Ser uma ferramenta segura, simples e intuitiva

1.9.2. Entregar mensagens rapidamente, mesmo para grandes volumes de usuários

1.9.3. Possibilidade de aumentar os destinos de envio

1.9.4. Interfaces e mensagens customizadas por cliente

2. ② RAs

2.1. 🔴 (p32) RA 01 - Disponibilidade

2.1.1. Nota entre: 12

2.1.2. Pesos

2.1.2.1. Estratégico | Produtos

2.1.2.1.1. 4

2.1.2.2. Desenvolvimento

2.1.2.2.1. 2

2.1.2.3. QA

2.1.2.3.1. 4

2.1.2.4. Segurança

2.1.2.4.1. 2

2.1.2.5. Infraestrutura

2.1.2.5.1. 4

2.1.2.6. Dados

2.1.2.6.1. 4

2.1.2.7. Total

2.1.2.7.1. 20

2.1.3. Pontos a serem atendidos

2.1.3.1. ◉ Alto impacto financeiro caso o sistema fique offline na ponta

2.1.3.2. ◉ Front-ends críticos não podem ficar indisponíveis

2.1.3.3. ◉ Versões antigas precisam ser mantidas

2.1.3.4. ◉ A operação de um cliente não deve impactar a de outro

2.2. 🔴 (p30) RA 02 - Elasticidade

2.2.1. Nota entre: 10

2.2.2. Pesos

2.2.2.1. Estratégico | Produtos

2.2.2.1.1. 4

2.2.2.2. Desenvolvimento

2.2.2.2.1. 4

2.2.2.3. QA

2.2.2.3.1. 4

2.2.2.4. Segurança

2.2.2.4.1. 2

2.2.2.5. Infraestrutura

2.2.2.5.1. 4

2.2.2.6. Dados

2.2.2.6.1. 2

2.2.2.7. Total

2.2.2.7.1. 20

2.3. 🔴 (p29) RA 03 - Segurança

2.3.1. Nota entre: 09

2.3.2. Pesos

2.3.2.1. Estratégico | Produtos

2.3.2.1.1. 4

2.3.2.2. Desenvolvimento

2.3.2.2.1. 3

2.3.2.3. QA

2.3.2.3.1. 3

2.3.2.4. Segurança

2.3.2.4.1. 4

2.3.2.5. Infraestrutura

2.3.2.5.1. 3

2.3.2.6. Dados

2.3.2.6.1. 3

2.3.2.7. Total

2.3.2.7.1. 20

2.4. 🔴 (p28) RA 04 - Escalabilidade

2.4.1. Nota entre: 11

2.4.2. Pesos

2.4.2.1. Estratégico | Produtos

2.4.2.1.1. 4

2.4.2.2. Desenvolvimento

2.4.2.2.1. 4

2.4.2.3. QA

2.4.2.3.1. 2

2.4.2.4. Segurança

2.4.2.4.1. 1

2.4.2.5. Infraestrutura

2.4.2.5.1. 4

2.4.2.6. Dados

2.4.2.6.1. 2

2.4.2.7. Total

2.4.2.7.1. 17

2.5. 🔵 (p25) RA 05 - Time To Market

2.5.1. Nota entre: 08

2.5.2. Pesos

2.5.2.1. Estratégico | Produtos

2.5.2.1.1. 3

2.5.2.2. Desenvolvimento

2.5.2.2.1. 4

2.5.2.3. QA

2.5.2.3.1. 1

2.5.2.4. Segurança

2.5.2.4.1. 1

2.5.2.5. Infraestrutura

2.5.2.5.1. 4

2.5.2.6. Dados

2.5.2.6.1. 4

2.5.2.7. Total

2.5.2.7.1. 17

2.6. 🟡 (p23) RA 06 - Manutenabilidade

2.6.1. Nota entre: 05

2.6.2. Pesos

2.6.2.1. Estratégico | Produtos

2.6.2.1.1. 3

2.6.2.2. Desenvolvimento

2.6.2.2.1. 4

2.6.2.3. QA

2.6.2.3.1. 2

2.6.2.4. Segurança

2.6.2.4.1. 2

2.6.2.5. Infraestrutura

2.6.2.5.1. 4

2.6.2.6. Dados

2.6.2.6.1. 2

2.6.2.7. Total

2.6.2.7.1. 18

2.7. 🔴 (p22) RA 07 - User Experience

2.7.1. Nota entre: 07

2.7.2. Pesos

2.7.2.1. Estratégico | Produtos

2.7.2.1.1. 4

2.7.2.2. Desenvolvimento

2.7.2.2.1. 4

2.7.2.3. QA

2.7.2.3.1. 4

2.7.2.4. Segurança

2.7.2.4.1. 1

2.7.2.5. Infraestrutura

2.7.2.5.1. 1

2.7.2.6. Dados

2.7.2.6.1. 1

2.7.2.7. Total

2.7.2.7.1. 15

2.8. 🔵 (p21) RA 08 - Performance

2.8.1. Nota entre: 06

2.8.2. Pesos

2.8.2.1. Estratégico | Produtos

2.8.2.1.1. 2

2.8.2.2. Desenvolvimento

2.8.2.2.1. 4

2.8.2.3. QA

2.8.2.3.1. 4

2.8.2.4. Segurança

2.8.2.4.1. 1

2.8.2.5. Infraestrutura

2.8.2.5.1. 3

2.8.2.6. Dados

2.8.2.6.1. 1

2.8.2.7. Total

2.8.2.7.1. 15

2.9. 🟡 (p18) RA 09 - Observabilidade

2.9.1. Nota entre: 04

2.9.2. Pesos

2.9.2.1. Estratégico | Produtos

2.9.2.1.1. 3

2.9.2.2. Desenvolvimento

2.9.2.2.1. 3

2.9.2.3. QA

2.9.2.3.1. 3

2.9.2.4. Segurança

2.9.2.4.1. 1

2.9.2.5. Infraestrutura

2.9.2.5.1. 3

2.9.2.6. Dados

2.9.2.6.1. 1

2.9.2.7. Total

2.9.2.7.1. 14

2.10. 🔵 (p16) RA 10 - Testabilidade

2.10.1. Nota entre: 03

2.10.2. Pesos

2.10.2.1. Estratégico | Produtos

2.10.2.1.1. 2

2.10.2.2. Desenvolvimento

2.10.2.2.1. 4

2.10.2.3. QA

2.10.2.3.1. 4

2.10.2.4. Segurança

2.10.2.4.1. 1

2.10.2.5. Infraestrutura

2.10.2.5.1. 1

2.10.2.6. Dados

2.10.2.6.1. 1

2.10.2.7. Total

2.10.2.7.1. 13

2.11. ⚪️ (p14) RA 11 - Integrabilidade

2.11.1. Nota entre: 02

2.11.2. Pesos

2.11.2.1. Estratégico | Produtos

2.11.2.1.1. 1

2.11.2.2. Desenvolvimento

2.11.2.2.1. 4

2.11.2.3. QA

2.11.2.3.1. 2

2.11.2.4. Segurança

2.11.2.4.1. 1

2.11.2.5. Infraestrutura

2.11.2.5.1. 3

2.11.2.6. Dados

2.11.2.6.1. 1

2.11.2.7. Total

2.11.2.7.1. 12

2.12. 🔴 (p12) RA 12 - Adaptabilidade

2.12.1. Nota entre: 01

2.12.2. Pesos

2.12.2.1. Estratégico | Produtos

2.12.2.1.1. 4

2.12.2.2. Desenvolvimento

2.12.2.2.1. 3

2.12.2.3. QA

2.12.2.3.1. 1

2.12.2.4. Segurança

2.12.2.4.1. 1

2.12.2.5. Infraestrutura

2.12.2.5.1. 1

2.12.2.6. Dados

2.12.2.6.1. 1

2.12.2.7. Total

2.12.2.7.1. 11

3. ③ VAs

3.1. 🔴 VA01 - Como são considerados

3.1.1. CURTO PRAZO: 1 ano

3.1.2. MÉDIO PRAZO: 2 anos

3.1.3. LONGO PRAZO: 3 anos

3.2. 🔴 VA02 - Em geral como a empresa deseja otimizar os custos com desenvolvimento de ativos de software?

3.2.1. RSP: Longo prazo

3.3. 🔴 VA03 - Em geral como a empresa deseja otimizar os custos com Infraestrutura?

3.3.1. RSP: Longo prazo

3.4. 🔴 VA04 - Em geral como a empresa deseja otimizar os custos com segurança da informação?

3.4.1. RSP: Médio prazo

3.5. 🔴 VA05 - Para os produtos novos em geral deve-se priorizar:

3.5.1. ⬜️ Qualidade | ✅ Time-To-Market

3.5.2. ⬜️ Segurança | ✅ Performance & UX

3.6. 🔴 VA06 - E para os produtos existentes, deve-se priorizar:

3.6.1. ✅ Qualidade | ⬜️ Time-To-Market

3.6.2. ⬜️ Segurança | ✅ Performance & UX

3.7. 🔴 VA07 - Deve-se Fazer lock-ins?

3.7.1. RSP: Não

3.8. 🟡 VA08 - Senioridade dos times

3.8.1. Predominantemente: Junior

3.9. 🟡 VA09 - Stack tecnologica

3.9.1. Node.JS

3.9.2. PostgreSQL

3.9.3. Angular.JS

3.10. 🟡 VA10 - Tecnologias ou padrões preferenciais

3.10.1. Preferir

3.10.1.1. Stack dos nosso profissionais

3.10.2. Sempre utilizar

3.10.2.1. N/A

3.11. 🟡 VA11 - Tecnologias ou padrões proibidos ou a serem evitadas

3.11.1. Evitar

3.11.1.1. N/A

3.11.2. Nunca utilizar

3.11.2.1. N/A

3.12. 🟡 VA12 - Aplicação web

3.12.1. suportada por dispositivos mobiles (recentes >= 2018)

3.13. 🔴 VA 13 - Compliance a LGPD

4. ④ Componentes Arquiteturais

4.1. Infraestrutura

4.1.1. Cloud

4.1.1.1. AWS para o ArcH-Notifier

4.1.1.2. Azure | AWS | DO | GCP para os clientes do ArcH-Notifier

4.1.2. IaC

4.1.2.1. Terraform

4.2. Log

4.2.1. ELK

4.3. Fila

4.3.1. RabbitMQ

4.4. RDBMS

4.4.1. PostgreSQL

4.5. Monitoring

4.5.1. Istio, Kibana e CloudWatch

4.6. Orquestrador de container

4.6.1. Kubernetes com Istio

5. ⑤ Principais funcionalidades

5.1. Contratação de plano

5.1.1. Funcionais

5.1.1.1. Permitir que o cliente possa escolher entre contratação única ou recorrente (assinatura mensal, semestral, anual, ou por volume)

5.1.1.2. Permitir a gravação de dados de pagamento (exceto CVV) do cliente para cobranças recorrentes, quando contratação recorrente

5.1.2. Não funcionais

5.1.2.1. Operar sob SSL para garantir segurança durante a transação de pagamento

5.2. Cancelamento de plano

5.2.1. Funcionais

5.2.1.1. Permitir ao cliente que continue utilizando a ferramenta enquanto houver saldo remanescente no pacote contratado

5.2.2. Não funcionais

5.2.2.1. Não se aplica

5.3. Troca de plano

5.3.1. Funcionais

5.3.1.1. Acrescentar saldo remanescente do plano anterior ao saldo do novo plano contratado. Caso haja incompatibilidade entre os planos, permitir que o cliente consuma o saldo do plano anterior paralelamente ao saldo do novo plano

5.3.2. Não funcionais

5.3.2.1. Não se aplica

5.4. Configuração do plano

5.4.1. Funcionais

5.4.1.1. Suporte a SMS, Push, Email e [ou] Webhook

5.4.2. Não funcionais

5.4.2.1. Não se aplica

5.5. Cadastro

5.5.1. Usuários

5.5.1.1. Funcionais

5.5.1.1.1. Não se aplica

5.5.1.2. Não funcionais

5.5.1.2.1. Não se aplica

5.5.2. Configurações de usuarios

5.5.2.1. Funcionais

5.5.2.1.1. Permitir ao usuário decidir quais tipos de notificações deseja receber

5.5.2.2. Não funcionais

5.5.2.2.1. Não se aplica

5.5.3. Mensagens

5.5.3.1. Funcionais

5.5.3.1.1. Reallizar spellcheck das mensagens, a fim de evitar erros gramaticais

5.5.3.1.2. Permitir inclusão de "emojis", e imagens para campanhas de marketing

5.5.3.2. Não funcionais

5.5.3.2.1. Não se aplica

5.5.4. Apps (envio de notificação)

5.5.4.1. Funcionais

5.5.4.1.1. Não se aplica

5.5.4.2. Não funcionais

5.5.4.2.1. Protocolo de comunicação encriptado de ponta a ponta

5.6. Consultas

5.6.1. Mensagens enviadas

5.6.1.1. Funcionais

5.6.1.1.1. Suporte a consultas de mensagens enviadas através de extração de dados para acompanhamento comercial e financeiro

5.6.1.2. Não funcionais

5.6.1.2.1. Interoperabilidade com o pacote Office

5.6.2. Mensagens lidas vs não lidas

5.6.2.1. Funcionais

5.6.2.1.1. Suporte a consultas de mensagens lidas vs não lidas através de extração de dados para acompanhamento de marketing e relacionamento com o usuário

5.6.2.2. Não funcionais

5.6.2.2.1. Interoperabilidade com o pacote Office

5.6.3. Erros de envio

5.6.3.1. Funcionais

5.6.3.1.1. Suporte a consultas de erros de envio através de extração de dados para acompanhamento da área técnica

5.6.3.2. Não funcionais

5.6.3.2.1. Interoperabilidade com o pacote Office

5.7. Monitoramento da plataforma como um todo

5.7.1. Para o time técnico

5.7.1.1. Funcionais

5.7.1.1.1. Acompanhamento de número de clientes ativos na ferramenta, quantidade de envios de mensagens e performance de serviços e infraestrutura

5.7.1.1.2. Acompanhamento de falhas do sistema, categorizando-as de acordo com a criticidade

5.7.1.2. Não funcionais

5.7.1.2.1. Não se aplica

5.7.2. Para o cliente

5.7.2.1. Funcionais

5.7.2.1.1. Acompanhamento de mensagens enviadas e mensagens lidas vs não lidas

5.7.2.2. Não funcionais

5.7.2.2.1. Não se aplica