---
title: retrospettiva 24 gennaio
tags: retrospettiva
---

1:
*X alcune conoscenze su servizi AWS specifici: code...etc (pipeline, star), o EB, che quando capitano quei ticket è sempre un casino e si rischia di fare danni pushando modifiche che lanciano pipeline
*X alcuni progetti sono driftati (Verisure, buddybank...) e quindi sono sempre molto restio a fare le cose con tranquillità
*X la documentazione per alcuni progetti è ancora un po' abbozzata (vedi verisure, che non si sa se resta o se le cose sono realmente driftate o meno)
*X scalare verso L2 non è sempre possibile ma è molto migliorato
* si potrebbe pensare ad una procedura da fare sempre in caso di aggiornamento di risorse su cloudformation (drift + changeset) e metterla per iscritto nei contratti, Così che se rispettata alcuni down non siano a colpa nostra o se questo è già così, forse è meglio scriverlo.

2:
*X poca esperienza
*X poca conoscenza dei progetti

3:
*X mancanza di voglia
*X difficoltà sui clienti progetti nuovi

4:
*X conoscenza: non ho la conoscenza di tutti i servizi e tool utilizzati, piano piano ho preso confidenza, ma ce n'è voluto... un vero processo di onboarding non c'è mai stato. Inoltre non ho un backgroud da sistemista, quindi per me è ancora molto difficile
*X esperienza: su questa non ci si può fare molto...ma ovviamente la mia aspirazione non è quella di diventare il massimo esperto MS
*X knowledge transfer: è normale che alcuni di noi si skillano su alcuni progetti MS, ma ritengo opportuno che sugli altri in cui si deficita o ci siano dei buchi, la persona di riferimento per quei problemi riesca a trasferire la conoscenza, magari in pair . La KB aiuta molto, ma non si può pensare di inserire ogni più piccolo problema lì dentro

Riassunto:
* poca esperienza AWS e sistemistica
* poco o nessun onboarding di managed service
* poca knowledge transfer, anche con L2
* documentazione poco curata
* mancanza di voglia. non è una cosa che voglio fare nella vita
* difficoltà sui progetti nuovi, poca conoscenza su quelli in essere
* disallineamento codice infrastruttura (colpa interna ed esterna)
* [ded] assegnazione problematica: deve sempre essere il master ad assegnare

###### Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

###### Indipendentemente da ciò che scopriamo, dobbiamo capire e credere davvero che ognuno fa del suo meglio, rispetto alle conoscenze attuali, alle sue competenze e abilità, le risorse disponibili e la situazione corrente.

## Minute

### mancanza di voglia. non è una cosa che voglio fare nella vita
non è stimolante,
serve per farsi le ossa è vero, ma deve durare meno di un anno
scrivere processo (ad oggi fa acqua), nessuna rotazione. Simone è sempre stato nel team core e non ci sono state rotazioni
ovviamente nessuno lo fa di sua spontanea volontà
-> rotazione più veloce: rotazione tra tutti, indipendentemente dal livello. ok per incidents ma anche per CR
è semplice ruotare tra 18 persone?
ACTION: cambiare organizzazione. mettiamo 2 persone al giorno (jr e sr). alle persone + jr serve 'per farsi le ossa' (almeno 4 mesi) (Owners dell'action: Paolo, )

voti
soluzione 1 (diego) : X X X X X X X <--- soluzione vincente
soluzione 2 (daniel): X X X
soluzione 3 (attual): X X

### recruiting team core