# Meeting with client

## Communication

- Communication channels
- Are Slack and mobile phone (for emergencies) okay?
- Reunion frequency and terms
- Meeting minute validation

## Business

- Why does the company want this product?
- Examples of use cases

## Technical

- Is there an existing project in the area on the company's part?
- **Machine learning:** Should we integrate with some existing algorithm or just create the base to do so? What are we trying to improve? What might change to reach that improvement?
- With what kind of data will we be working with? What is the scope of the geographic data?
- Is there any existing data which we may work it?
- Are the proposed techonologies mandatory or might they be changed?

---

## Minutes

- Apresentações de todos
- Explicar ausências
- Esclarecer transição MIEIC - M.EIC

### Apresentação do cliente

- Foi professor e investigador na FEUP
- Já trabalha com o professor Gil há muito tempo
- Conhece muitos dos professores e foi aluno deles
- Já esta na empresa (DEUS.AI) há 6 meses
- Gere *data science* na empresa
- Fez doutoramento na FEUP e o profesosr Gil foi o seu orientador

### Apresentação do projeto

- Querem explorar a viabilidade da ideia: pode não ser possivel
- O cliente da DEUS.AI é a Shell Energy, subsidiária da Shell que pretende apostar em energias renováveis
- Vai falar do projeto e da Shell (os chefes da Shell vao estar ca para falar com a DEUS.AI e querem ver a nossa disponibilidade)
- Pode ajudar na questao de arranjar forma de validar MVP
- Pode ser útil para ver a relevancia do projeto
- "chutar a baliza"
- Sobre a empresa DEUS.AI
- O nome confunde os portugueses que passam a porta
- A empresa e holandesa
- O nome vem de enquadrar o antigo (da vinci)
- Juntar componente moderna (IA)
- Ligacao com o latim
- O nome dos projetos vem do latim
- Na holanda deus nao diz nada mas ca diz
- d de data sciene
- e de engineering
- a parte de informatica e importante
- u de ux/ui
- Tem artistas na empresa
- Pessoas que so pensam, que se focam na experiencia, nao tecnico
- s de strategy
- Dão direções para o futuro
- analisa o mercado
- ve a viabilidade, ethics, energia renovavel
- da os requisitos aos outros departamentos, "alimenta-os"
- **Três locais:** Amsterdão, Porto, La Coruña
- IA e importante na empresa
- Sereno interrompe e antonio sai
- Porque fazem isto? Querem beneficiar o ser humano
- Facilmente arranjam pessoas, querem projetos importantes
- Comenta a farfetch, o negócio deles nao lhes interesaa
- Trabalhar com o setor público
- Trabalham com a Google
- critica a google, a tecnologia devia estar disponivel para o publico
- parcerias com empresas publicas (na holanda (e ca?))
- exemplos de entidades com que trabalharam e como ajudaram as pessoas
- passando ao projeto
- nao vai para o mercado a menos que seja muito bom
- querem que experimentemos
- problemas tecnicos
- explicar o mvp a componente S
- energia
- perceber a motivacao do projeto
- o contexto
- taxa fixa da eletricidade
- para empresas nao ha taxa fixa
- os precos mudam muito, tem que ir a leilao para conseguir energia
- ha varios elementos no ciclo da energia
- gerador -> mercado -> supplier -> consumer
- tentar lidar melhor com imprevistos
- fluxos paralelos
- gerador -> trans grid -> dist grid -> consumer
- ajustam o fornecimento com o consumo
- metafora bob alice
- bob e produtor
- alice e utilizadora na perspetiva de empresas
- holanda e outros produzem muita energia renovavel
- bids para a energia
- definem valores maximos e minimos
- depende de quanto se vai fornecer/consumir
- exemplo empresa que produz garrafas
- energia tem que la estar porque nao pode falhar
- tanto podem trabalhar com forno a gas ou eletrico
- a grande motivacao e o que acontece quando o preço e fixado para o dia seguinte e algo de errado ocorre
- ter que pedir 1 MW para 15 minutos depois
- vattenfall e essent ainda nao sao clientes
- sympower esta mais do lado do demand
- Requisitos:
- Representação geográfica de *assets*
- Google Maps
- Permite adicionar, remover, editar e controlar dispositivos
- ver como estao solar farms, wind farms, etc
- smart meters
- saber como esta o consumo em tempo real
- painel de controlo para ver o que esta a acontecer com os assets
- isto e o pulmao da empresa
- pergunta do antonio: e suposto cada ator so ver os seus assets?
- resposta: sim
- Não é colaborativo, cada um só vê os seus
- Criar e gerir dispositivos
- criar e gerir farms, etc
- diferentes campos e fontes
- reposicionar dispositivos e assets
- ajustar campos e dados dos assets
- desenhar ligacoes entre assets a representar a rede eletrica
- desenhar no mapa o fluxo de energia
- como gmaps para rotas
- caixa no meio e um asset que faz somatorio
- indicar o total do que produz e consome
- ao ligar a caixa adiciona ou subtrai dpendendo se consome ou produz
- na caixa o valor de ser 0 (tudo o que entra sai)
- pergunta do joao costa: as ligacoes devem persisitir entre as sessoes?
- resposta: sim
- pode haver uma plataforma colaborativa mas nao e requisito
- pergunta de antonio: e suposto os locais estarem associado a locais fisicos ou e algo mais logico
- reposta: qunato mais fiel melhor, e da responsabilidae da pessoa ver se as ligacoes fazem sentido
- possibilidade grafica de desenhar, posicionar e resposabilidade do user
- notificacoes
- valores que mudam em real time (requisito 2)
- define boundaries (se o parametro for abaixo/acima de limites entao notifica o user)
- min/max e pronto
- dashboard com dados do mercado como preco e estados de regulacao
- uma para assets e outra para o mercado
- outros como dados do clima
- graficos com campos que mudam ao longo do tempo
- algo como grafana (UI para dados em DB)
- graficos que comparem solar farms (exemplo)
- vao nos dar informacoes do mercado
- Q flavia: como vamos ter acesso aos dados? ((nao foi bem isto que a flavia disse))
- A: pode nos dar bastantes dados, um servidor so para nos, etc
- aparte: day ahead market e spot market
- valores reais e previstos do mercado
- varias perspetivas da mesma coisa
- todos os requisitos antetriores constituem um mercado e deve ser possivel haver varios mercados
- Q antonio: ((nao tive tempo de escrever)) - Penso que era a pergunta sobre a fronteira dos mercados, ou seja, se a empresa deve conseguir criar mercados para cidades diferentes dentro do mesmo país, etc.
- A: entidade reguladora que faz isso - penso que o resumo era que o mercado só não pode é misturar os mercados reais (ibérico, etc, etc).
- Q flavia: escala?
- A: distribuidos pelo pais inteiro, depende da empresa
- mercados com assets so locais e outros com assets mais espalhados por uma grande area
- integrar dados de diferentes fontes
- apis externas
- solucoes ML
- se nos tivemos uma forma melhor de passar os dados para a plataforma
- os produtores mandam dados para o plataforma com api que vao para os custom fields e paara a gis
- solucoes cloud e pub-sub
- podemos pedir ideias, se tivermos uma melhor
- poder injetar dados vindos de modelos AI
- devemos ir dando URL e formato do pedido http paara ir testando
- what if scenarios
- a mesma representacao mas com dados simulados/hipoteticos
- projetar futuros assets
- basico, copia de assets, etc, se tiver tempo ajustar estatisticas
- Q eduardo: ao mostrar os dados devemos ter os dados simulados/ reais ou ambos?
- A: os reais e simulados sao mercados difentes, (os simulados podem ser replicas de reais)
- Q antonio: devemos continuar a atualziar os dados reais? (continuacao da Q anterior)
- A: sim, se quisermos fazer isso, pode haver problemas com os graficos da dashboard
- tentar fazer tudo com o minimo possivel
- Q antonio: quando deve haver sync nos cenario simulados? (continuacao)
- A: ((nao consegui apanhar a resposta)) - Ficava a nosso critério, aquilo que virmos que é mais simples fazer.
- Q eduardo: vao disponiblizar a apresentacao?
- A: sim
- estabelecer contactos
- [e-mail] (email do cliente)
- Q flavia: fazer so comunicacoes no AI, nao fazemos nos?
- A: sim
- Q flavia: podemos mudar tecnologias?
- A: podemos sugerir outras
- Q eduardo: three.js, precisamos mesmo de usar, visto que mostrou 2d?
- A: e so initial guess, nao temos que usar three.js
- Q flavia: na deus.ai ja ha projetos nesta area?
- A: software nao, AI ha
- Q eduardo: tambem nao ha nada grafico?
- A: nao ha
- mercado com natalie, ?? com ron
- sempre que ha release vai puxar 2 pessoas da holanda para ver a apresntacao
- pessoas da shell, dia 21, temos que falar sobre o projeto, apresentar a nossa visao do projeto
- tentar fazer perguntas a shell mas nao ha muito tempo
- isto faz sentido ou nao?
- e um projeto muito novo
- shell e um grande cliente e investidor na empresa
- visitar escritorios no dia 21 a tarde (3,4,5 da tare) e falar com shell
- alguns tem disponibilidae, outros podem chegar mais tarde a aula
- ter um mvp definido ate la e validar com eles
- no maximo uma visao do produto
- ter a experiencia de apresentar o produto a shell
- Q eu: como validar a ata?
- A: enviar por email, nao tem preferencia
- definir canais de comunicacao
- podemos enviar mensagens em emergencia ou ligar, msg, whatsapp, discord, etc
- Q flavia: periodicidade das reunioes
- A: esta disp. todas as semanas, numa fase inicial sem/sem 15/15 dias, sexta a tarde, podemos negociar dias da semana
- flavia vai enviar email com informacoes de disponibilidade etc
- podemos tirar duvidas para tomar decisoes a meio da semana, nao temos de esperar pela reuniao
- nao acumular tudo para a reuniao para nao ter uma reuniao muito longa
- marcar reuniao para proxima semana, confirmar com prof se pode ser na hora da aula
- e um produto interessante e desafiante
- a apresentacao ajudou muito
- e um tipo de plataforma pouco conhecido
- entrar na filosofia da empresa

# Markdown used to generate pdf

<!---->
# Kick-off Meeting
**Date:** 11/03/2022\
**Location:** B343 - FEUP\
**Participants:**\
António Bezerra: Supervisor Interface Manager\
Eduardo Correia: Implementation Manager / Design Manager\
Flávia Carvalhido: Customer Interface Manager / Planning Manager\
Jéssica Nascimento: Design Manager\
João Costa: Process Manager\
João Fernandes: Test Manager\
João Matos: Process Manager\
João Reis: Customer from DEUS.AI
___
## Meeting started around 16:00 and the following topics were discussed:
### **1. Introductions**
#### 1.1. Team Introduction
The members of the teams introduce themselves.
#### 1.2. Customer Introduction
The customer introduces himself and explains his connection to the course and the faculty.
### **2. Overview of DEUS.AI**
#### 2.1. Company name origin
The customer explains the meaning behind the work DEUS and how each letter represents a major component of the company.
#### 2.2. Company mission and vision
The company aims to use interesting AI projects to benefit human beings.
### **3. Context behind the project**
The power supply chain used by companies is very complex and the project should improve the way unforeseen problems are handled after the price has been set for a particular day.
### **4. Project Requirements**
#### 4.1. GIS showcasing assets
The application should offer a geographical representation of assets and show real time data about them.
##### Interventions:
- António asks if each user's assets are private and only visible to them, the customer replies positively.
#### 4.2. Asset creation and management
The application should allow the creation of assets which can also be managed, this includes asset repositioning, addition and removal of data fields and other adjustments.
#### 4.3. Asset connection and grid representation
A user should be able to draw the energy flow and use an asset that keeps track of all the energy being produced and consumed.
##### Interventions:
- João Costa asks if the connections should persist between sessions, the customer replies positively.
- António asks if the representation shown should correpond to physical locations, the customer replies that the more faithful the representation the better but it's up to the user to determine if the asset placement and connections make sense.
#### 4.4. Notifications
The system should notify the user when certain fields' values cross previously defined boundaries.
#### 4.5. Dashboard with asset and market data
The user should have access to a dashboard with market data and another one with asset data. These dashboard should have graphs with real time and predicted data about several elements like the weather and market price, it should allow for comparisons to be made between values.
##### Interventions
- Flávia asks if the company can give us access to this type of data, the customer replies that the team can be provided with a substantial amount of data.
#### 4.6. Multiple markets
The previous requirements form a market and the system should support several of them.
##### Interventions
- António asks if the system should allow a user to create different markets for different cities in the same country, the customer says that can be done but a market must not mix different real markets.
- Flávia asks about the geographical scale of the project, the customer replies that depending on the company the assets can be distributed over an entire country or a smaller area.
#### 4.7. Integrating data from different sources
The system should offer a way for external applications (like AI models) to provide it with data. The customer suggests the use of an API but the team can try to come up with a better way. The data being sent to the system should be visible in the geographical representation.
#### 4.8. Hypothetical scenarios
The system should be able to function with data that isn't real, allowing for the analysis of hypothetical scenarios. The simulated assets can be copies of real assets.
##### Interventions
- Eduardo asks if the system should show real and simulated data together or separately, the customer says they should be in different markets.
- António asks if the real data should continue to be updated when showing simulated data, the customer says the team can do that, should they choose to, but it can cause problems in the dashboard.
- António asks when the data should be synchronized in simulated scenarios, the customer replies that the team should choose to do what is simpler.
### **5. Contact information and general questions**
The team and the customer exchange contact information. The customer invites the team to visit the company's headquarters on 21/03/2022 and talk with Shell employees. The team should define an MVP until then to request validation. Finally, the team can clear any doubts in the middle of the week to avoid overloading the meeting and Flávia will contact the customer to provide further contact and meeting information.
##### Interventions
- Eduardo asks if the team will have access to the presentation, the customer answers positively.
- Flávia confirms with the customer that the team is not supposed to implement its own AI models.
- Flávia asks if the team can use a different technology stack, the customer says the team can suggest different technologies.
- Eduardo asks if the team has to use Three.js, the customer says something else can be used.
- Flávia asks if the company already offers similar solutions, the customer replies that DEUS does not offer software like this but develops AI software related to this.
- Eduardo asks if the company does not offer graphical tools related to the project's topic, the customer replies negatively.
- João Matos asks how the the minute should be validated, the customer says it can be done through email but does not have a particular preference for validation methodologies.
- Flávia asks how often the meetings should be held, the customer says he's available every week and initially, the frequency of the meetings should be higher.

## Meeting ended around 17:30.