Confessioni di un consulente IT

Perché mi rallegro #11

Posted in P.M.R. by pigreco314 on 30 marzo, 2009

Superato anche il terzo esame per la certificazione BACP: Writing and Managing Requirements Documents.

Punteggio: 30/30

A maggio il quarto e ultimo corso: Business Process Modeling.

Come scrivere un Performance Improvement Plan #2

Posted in Management by pigreco314 on 25 marzo, 2009

(La prima parte la trovate qui)

Il concetto chiave per formulare un Performance Improvement Plan è che deve essere possibile documentare un deficit di performance di Alice o Bruno (i nostri ipotetici collaboratori della prima parte) rispetto ai precetti di un ben definito e condiviso standard aziendale come ad esempio:

  • la job description della mansione occupata da Bruno o Alice
  • gli obiettivi individuali fissati nell’anno in corso per Alice o Bruno (nel caso l’azienda adotti un sistema di Goal Setting)
  • un complesso di valori o fattori di successo facenti parte della cultura aziendale
  • l’adesione a normative industriali, di qualità, di sicurezza ecc. (ad esempio legge 626 o regolamentazione Sarbanes & Oxley)

In generale non dovrebbe essere difficile riferire il gap di performance a uno di questi standard ma è fondamentale (soprattutto nel caso di PIP formale) che il riferimento sia un documento aziendale ufficiale noto e compreso sia da Alice sia da Bruno.

Un altro aspetto importante è la registrazione dei cosiddetti “data points”, ovvero la descrizione circostanziata delle situazioni che hanno evidenziato il deficit di performance: è assai opportuno che ogniqualvolta rileviate un comportamento anomalo da parte dei vostri collaboratori prendiate nota dell’accadimento nel vostro libro nero diario del bravo manager (non tenete un diario? Vi consiglio di cominciare: io mi trovo bene con un pratico Moleskine). E’ sufficiente l’indicazione della data e una descrizione narrativa dell’accaduto.

Una volta individuato il riferimento e avendo a disposizione i data points, l’analisi procede in modo strutturato come segue:

  • l’attuale stato delle cose mostra che Alice o Bruno esibiscono performance al di sotto delle aspettative per quanto riguarda [riferimento allo standard aziendale]
  • le situazioni in cui questo deficit si è manifestato sono documentate di seguito [data, luogo, accadimento, persone]
  • l’obiettivo da raggiungere per correggere la situazione è [comportamento desiderato]
  • l’insieme dettagliato di azioni da intraprendere è [elenco di attività che Alice o Bruno devono portare a termine]
  • la metrica per misurare il progresso delle performance è [in che modo misurerete i miglioramenti]
  • la data in cui terminerà l’osservazione è [la data in cui porterete a termine il monitoraggio per la specifica manchevole performance ]

Un banale foglio Excel servirà allo scopo.

Esempio

  • “STATO ATTUALE”: scarso coinvolgimento nelle attività di prevendita previste dalla job description
  • “SITUAZIONI”: in diverse occasioni è stata assegnata bassa priorità alle attività di prevendita privilegiando invece attività di sviluppo software. Ciò ha contribuito all’esclusione dalla fase finale di vendita per i prospetti A e B
  • “OBIETTIVO”: ribilanciamento delle attività di prevendita rispetto alle altre mansioni previste dalla job description
  • “AZIONI”: attività di coordinamento nella realizzazione delle demo X, Y e Z e conduzione di almeno una delle tre
  • “METRICA”: quantificazione delle ore dedicate alle attività di prevendita rilevate dalla scorecard e verifica diretta (assisterete alla demo)
  • “DATA DI COMPLETAMENTO”: 30 giugno 2009

Sottoporrete il frutto delle vostre ponderazioni al supportante HR per approvazione che avrete cura di richiedere per iscritto (una mail va bene).

E’ giunto quindi il momento di informare Alice o Bruno di una certa faccenda che li riguarda per la qual cosa è assai opportuno (direi quasi obbligatorio in caso di PIP formale) organizzare un incontro faccia a faccia, preferibilmente in presenza del rappresentante HR che può supportarvi nel caso Alice o Bruno pongano legittime domande circa le implicazioni del PIP, specie in caso di insuccesso. Se il rappresentante HR non può presenziare a causa dei soliti  inderogabili impegni, riflettete su quali domande porreste voi stessi davanti alla prospettiva di un PIP, inviatele al collega HR e chiedete per iscritto indicazioni riguardo le possibili risposte.

Il PIP-meeting (o PIP-show, si fa per sdrammatizzare suvvia) dovrebbe svolgersi in un’atmosfera  rilassata: dovrete sforzarvi di mettere Alice e Bruno a loro agio. Il processo in sé non deve assolutamente essere percepito come un atto punitivo perché semplicemente non lo è.

E’ invece assai importante, nell’esposizione oggettiva e pacata del piano di miglioramento, assicurare che Alice e Bruno riconoscano il sussistere di un deficit di performance. Questo aspetto è talmente importante che il mio consiglio è di non procedere oltre se questo riconoscimento non avviene,  rimandando il meeting ad altra data qualora il collega HR non sia lì in quel momento a supportarvi.

Ovviamente, ogni altro dettaglio del piano deve essere adeguatamente illustrato e ai nostri amici va chiesta conferma della sua totale comprensione.

Se tutto procede come previsto, Alice e Bruno aderiranno al PIP con gioia (e forse qualche trepidazione) e firmeranno il documento senza problemi: una copia per loro, una per voi e una per HR che provvederà a espletare le relative questioni burocratiche (lettera formale, registrazione nell’incartamento del dipendente, vai a sapere che altro)

Da quel momento in poi procederete a monitorare i progressi di Alice e Bruno esattamente come descritto nel piano, preferibilmente tramite colloqui settimanali, documentando nei dettagli ogni osservazione in merito ai progressi (o mancanza dei medesimi) rilevati. Non sarebbe male ragguagliare periodicamente (diciamo ogni due settimane) HR circa l’evoluzione del piano.

Di seguito alcuni ulteriori suggeriment:

  • un PIP deve essere considerato l’estrema ratio: è un processo che assorbe moltissimo tempo (vostro e di chi lo subisce) sottraendolo alle attività principali delle risorse coinvolte. Pertanto, se osservate comportamenti anomali da parte di chi lavora con e per voi, non lasciate che la situazione degeneri e usate coaching, coaching e ancora coaching o un semplice ma spesso assai produttivo incontro chiarificatore.
  • durante l’esecuzione del piano, sottolineate con un plauso ogni miglioramento significativo in quanto ciò costituisce ulteriore motivazione per Alice e Bruno a proseguire sulla giusta strada
  • scrivete tutto: potreste un giorno essere costretti a produrre questi artefatti davanti a un rappresentante sindacale o a un giudice del lavoro
  • formulare un PIP è un’arte, deve essere congegnato in modo da innestarsi sulle mansioni caratteristiche del soggetto: non deve essere qualcosa di marginale rispetto agli standard aziendali previsti per quel ruolo specifico o verrebbe vissuto come un bieco tentativo di mettere in difficoltà il collaboratore e favorirne il deragliamento
  • dovete essere motivati voi stessi a concludere il PIP con esito positivo: se ciò accade avrete riportato una risorsa allo standard richiesto dalla vostra azienda e potrete contare di nuovo su Alice e Bruno per conseguire gli obiettivi organizzativi

Come si è concluso il PIP di Alice e Bruno?

Quello di Alice bene ma ero alla prima esperienza e per varie ragioni non posso dire di averlo gestito in maniera impeccabile.

Per quanto riguarda Bruno, vedremo. Speriamo bene.

La forma e il contenuto

Posted in Business Analysis, Cultura by pigreco314 on 24 marzo, 2009

Dato che mi piacciono le definizioni operative dirò che a mio parere lo scopo primario per cui qualunque tipo di scritto viene creato è di essere letto.

E dunque chi scrive, dovrebbe sforzarsi il più possibile di rimuovere ogni ostacolo incontrato dal lettore nell’accedere al contenuto.

Quando un contenuto arido, ostico, asettico è già di per sé un ostacolo alla lettura occorre agire sulla forma.

I signori di Infomap hanno alcuni brillanti consigli da darvi per presentare in forma quasi gradevole e invitante il vostro prossimo arido, ostico e asettico documento tecnico.

Guardate che differenza fa presentare un tema piuttosto indigesto come la conformità alle prescrizioni della Food&Drug Administration prima e dopo la cura Infomap: FDA Compliance.

Altri esempi sono disponibili sul sito Infomap qui insieme a un’interessantissima demo sull’importanza della forma e del formato quando si scrivono documenti tecnici (e non solo).

Come scrivere un Performance Improvement Plan #1

Posted in Management by pigreco314 on 24 marzo, 2009

Quando le vostre strabilianti doti di coaching non bastano più a modificare il comportamento di uno o più componenti del team (non tutti, altrimenti parliamo di ammutinamento e il problema non è il team bensì voi stessi) e il richiamo agli obiettivi delle performance individuali non serve più a nulla, occorre collocare il soggetto in un ambiente controllato nel quale svolga azioni mirate a conseguire obiettivi strettamente collegati al proprio ruolo, finalizzate a colmare documentate lacune tecniche o comportamentali, entro un intervallo di tempo prestabilito normalmente di breve durata (direi al massimo tre mesi)

Giunti a questa situazione il primo impulso è quello di sbarazzarsi nel minor tempo possibile di un fastidioso elemento di disturbo, specialmente quando si tratta di un collaboratore nel cui processo di assunzione non avete avuto parte, il ché comporta il fatto che avrete una risorsa in meno su cui contare per portare avanti gli obiettivi del vostro team.

Resistete altresì la tentazione di fare in modo che il piano di miglioramento delle performance (in cui voi svolgerete il ruolo di arbitro molto parziale) si concluda con un fallimento. Prima di tutto perché non sarebbe eticamente corretto. In secondo luogo, non dovete permettere che l’atteggiamento precostituito che avete nei confronti di un collaboratore ne offuschi completamente il bagaglio di capacità che qualcuno (voi stessi, il vostro predecessore, l’amministratore delegato della società) ha visto in lui (Bruno) o lei (Alice) durante il processo di assunzione.

Il Performance Improvement Plan (PIP, orrendo acronimo) quindi deve essere vissuto non come una punizione da infliggere (o subire) bensì come una esperienza di apprendimento avente come obiettivo minimo la comprensione delle motivazioni per cui Bruno o Alice non conseguono risultati all’altezza delle aspettative e come obiettivo massimo la correzione del comportamento e il ripristino di un livello di performance stabile e adeguato.

Possiamo fondamentalmente distinguere due tipi di PIP: informale e formale.

Il primo solitamente viene avviato per fronteggiare lacune non gravi, che tuttavia si manifestano con una certa frequenza e che pur non avendo un impatto serio sulle performance del collaboratore, possono comprometterne il futuro sviluppo professionale. Esempio: scarse capacità di esposizione.

L’esito di questo tipo di PIP è frequentemente positivo in quanto il livello di stress a cui è sottoposto il soggetto è moderato (in caso di fallimento non vi sono immediate conseguenza disciplinari ma potrebbe iniziare un PIP formale) e il coinvolgimento elevato.

Il PIP formale invece mira a correggere lacune più gravi che hanno un impatto diretto sulle performance, evidenziano una discrepanza significativa tra il comportamento atteso (formalizzato nel documento di  “job description”) e quello osservato e possono essere in contrasto con i valori, la visione e la missione dell’azienda. Esempio: gravi incomprensioni del processo di vendita e frequente mancata osservanza delle scadenze per l’invio dei documenti di partecipazione a una gara.

In alcuni Paesi il fallimento di un PIP formale comporta quasi automaticamente il licenziamento, in altri dà luogo a un richiamo scritto e come minimo permette di ridiscutere il ruolo del soggetto e deciderne il collocamento in altra posizione.

In entrambi i casi è fondamentale coinvolgere sin dall’inizio un rappresentante Human Resources che vi fornisca il necessario supporto legale (per ciò che riguarda le implicazioni del contratto di lavoro del collaboratore), vi aiuti nell’analisi psicologica  e comportamentale (per comprendere motivazioni, reazioni, aspettative del soggetto) e metta a vostra disposizione il proprio bagaglio di esperienza soprattutto se è il vostro primo PIP (il primo PIP non si scorda mai) oppure  se Bruno o Alice risultino essere individui piuttosto difficili da trattare.

Prima di giungere al Performance Improvement Plan si assume che abbiate già svolto alcuni ovvi passaggi preliminari come discutere delle vostre osservazioni con l’interessato o interessata, raccogliere una serie di motivazioni del comportamento rilevato, svolgere attività di coaching possibilmente nelle medesime situazioni in cui avete rilevato le mancanze (per esempio visitare insieme un Cliente), avere chiesto un intervento preliminare da parte di HR, ecc.

Nella seconda parte, illustrerò alcune possibili linee guida per la formulazione di un Piano di Miglioramento delle Performance.

Perché mi rallegro #10

Posted in Email, P.M.R., Persone, R.B., S.B. by pigreco314 on 18 marzo, 2009

Sarà pure un motivo di rallegramento alquanto puerile ma una cazziata a Cicciopasticcio (alias R.B., alias il nostro Project Management Officer) da parte del capo non è cosa da tutti i giorni.

Il Nostro è freneticamente impegnato nella fase di upgrade del nostro Microsoft Project alla versione 2007. In quale ruolo non è dato sapere. Sulla carta è il Project Manager (nonché Amministratore del Sistema, mah). Come già detto in altro post, l’impresa potrebbe costituire la base per un manuale su come non si dovrebbero gestire i progetti IT.

L’altro giorno Cicciopasticcio ci comunica che il server non sarà disponibile causa manutenzione il tal giorno tra le 6 e le 7 della mattina (Central European Time) e ci chiede di astenerci dall’ utilizzarlo per non compromettere l’operazione.

Ieri, ecco giungere il flame cazziante da un adiratissimo R.B.:

[In grassetto] Nonostante avessi informato tutti della manutenzione blah blah qualcuno tra le 6 e le 7 stava registrando le proprie ore nel sistema blah blah ha compromesso la manutenzione blah blah ho dovuto riavviare la coda dei job (coda dei job? boh!) blah blah [in rosso] considero la disponibilità di Microsoft Project importante blah blah leggete gli email!!!!

Un classico esempio di come, sparando nel mucchio, si colpevolizzano tutti quanti e non si raggiunge lo scopo di sensibilizzare le persone. Anzi, riesci solo a farti dei nemici.

Sulle prime tuttavia, non ho prestato attenzione all’ennesima manifestazione di arroganza del Ciccio avendo cose più importanti a cui dedicarmi.

S.B. invece l’ha preso molto sul serio e ha risposto qualcosa del tipo:

Il tono del tuo email non mi piace, evidentemente chi stava lavorando alle 6 del mattino aveva delle buone ragioni per farlo, in questo modo crei solo stress e frustrazione, se hai il nome dell’individuo e appartiene al mio team fammelo sapere che ci penso io

Il capo (suo, mio e di R.B.) in copia.

A questo punto mi sono inzigato e dopo 24 ore rincaro la dose:

Ciccio, dovresti rivedere il tuo stile di comunicazione, non aiuta a sensibilizzare le persone e serve solo a demotivare coloro i quali tra le 6 e le 7 stavano dormendo, avrei preferito un’ispezione attenta dei file di log per risalire al nome dell’utente ed effettuare un’azione repressiva mirata

Anch’io metto il capo in copia. Pochi minuti dopo mi giunge un messaggio di Ciccio-bofonchiatore (di nuovo il capo in copia) che dice:

Se ho offeso qualcuno, faccio le mie scuse

Come a sottointendere che la mia reazione fosse dovuta a lamentele di gente del mio team e io avessi semplicemente dato voce alle proteste. Caro il mio Cicciopasticcio, non hai proprio capito un kakkio.

Ma dopo due ore giunge il memo del capo, diretto a me, S.B. e un nostro collega team leader d’oltreoceano, M.E.

Ho già avuto modo di commentare a Cicciopasticcio che il tono del suo mail ha probabilmente avuto l’effetto contrario a quello voluto, il grassetto e il colore rosso equivalgono a strillare, avrò un ulteriore chiarimento con lui in seguito, facciamo in modo che questo incidente non danneggi la nostra relazione di lavoro (sic!)  con R.B., ha svolto e sta svolgendo un bel lavoro per il team.

Grazie per la vostra pazienza

E’ la prima volta che il capo presenta il Ciccio come un accessorio di supporto (seppure importante) alle attività del gruppo dei Professional Services, quasi chiedendo di sopportarlo e portare pazienza…

Che goduria!

Project Premortem Analysis

Posted in Business Analysis, Progetti, Risk Management by pigreco314 on 18 marzo, 2009

In questo articolo del 1989 (“Back to the Future: Temporal Perspective in the Explanation of Events”)  Mitchell, Russo e Pennington riportano i risultati di una ricerca secondo la quale immaginare che un evento sia già accaduto consente di incrementare del 30% la capacità di prevederne future conseguenze.

Su questa scoperta si basa l’idea dell’analisi pre-mortem, un metodo per aiutare la valutazione dei rischi in un progetto, descritto in questo articolo pubblicato nel numero di Settembre 2007 della Harvard Business Review.

A differenza di una tipica sessione di risk assessment nella quale i convenuti si chiedono che cosa potrebbe andare storto, nell’analisi pre-mortem l’assunto è che il paziente è morto e l’obiettivo è spiegare che cosa è andato storto.

Il compito dei membri del team è generare un insieme di ragioni plausibili per il fallimento del progetto.

Una sessione premortem tipica si potrebbe svolgere in questo modo: dopo aver ragguagliato il team circa il piano di progetto, il facilitatore  informa che il progetto è fallito. Nei minuti seguenti, ciascun componente del team indipendentemente dagli altri elenca una lista di ragioni che spieghino il fallimento.

Nella fase di revisione, il facilitatore chiede a ciascun membro del team, a cominciare dal project manager, di elencare una ragione differente sino a che non siano state registrate tutte le opinioni.

Una volta raccolti tutti i contributi, il project manager passa in rassegna la lista e riflette su come rafforzare il piano di progetto.

Anche quest’ultima fase può essere svolta coinvolgendo il team e utilizzando tecniche quali per esempio il brainstorming.

Coincidenze

Posted in Storie Aziendali by pigreco314 on 17 marzo, 2009

Dal  giorno 1 Gennaio 2003, i contenuti della Worker Adjustment and Retraining Notification (WARN) sono diventati una legge dello Stato della California. Questa legge  impone alle aziende la pubblicazione con congruo anticipo (almeno 60 giorni) di ogni notizia relativa a licenziamenti di massa o chiusura di stabilimenti, impianti, centri direzionali ecc.

Sul sito dello Stato della California vengono pubblicati gli elenchi aggiornati delle aziende interessate con l’indicazione di quante persone verranno licenziate, a partire da che data e il giorno in cui è stata recapitata la notifica al Dipartimento del Lavoro.

Il link è qui: http://www.edd.ca.gov/Jobs_and_Training/Layoff_Services_WARN.htm

Guarda caso, negli elenchi del 2009 compare il nome della nostra società con accanto la data di previsto licenziamento: un giorno d’estate prossima ventura.

Notifica avvenuta nel dicembre 2008.

Numero dei licenziamenti comunicati: diciamo X, con X compreso tra 30 e 50.

Ho appena controllato quante persone lavorano nella nostra business unit a libro paga del quartier generale californiano.

Esattamente X.

Business Analysis Certification Program: Facilitation Skills

Posted in Business Analysis by pigreco314 on 17 marzo, 2009
iiba_member1

IIBA® is a registered trademark owned by International Institute of Business Analysis.

Ho dato ieri il secondo esame della serie, quello relativo al corso denominato “Facilitation Skills for Business Analyst” (superato con un bel 45/45, punteggio in cui non speravo, data l’abbondanza di domande situazionali e deduttive).

E poiché mi sono iscritto all’IIBA® sono ora autorizzato a utilizzarne il logo.

Questo secondo corso della serie di quattro (ho parlato qui del primo “Business Analysis Fundamentals”) verte principalmente sulla Knowledge Area denominata “Requirements Communication” e mira a sviluppare nel Business Analyst le capacità di facilitazione di tutte le dinamiche del processo di sviluppo del prodotto (Product Life Cycle) che si articolano nelle altre 5 aree di conoscenza della BABOK®.

Si trattano quindi argomenti come:

  • fondamenti del processo di comunicazione, ciò che lo ostacola, ciò che lo facilita
  • lo sviluppo di un requirements communication plan
  • le tre principali categorie in cui cadono le tecniche di raccolta dei requisiti (Requirements Elicitation), ovvero: mirate (targeted elicitation come interviste, job shadowing, survey), di gruppo (group elicitation ossia brainstorming, workshop, focus group, sessioni di prototipizzazione), fisiche (physical elicitation ovvero analisi documentale, reverse engineering e analisi delle interfacce)
  • best practices nella conduzione di meeting
  • principi di negoziazione e mediazione

Un aspetto fondamentale nella preparazione di un requirements communication plan è la conduzione della cosiddetta “stakeholder analysis” o “analisi dei portatori di interesse”. Ricordo che uno stakeholder è definito come un individuo o categoria di individui che ha un interesse in un’attività economica, organizzazione d’impresa o progetto e ha modo di influenzarli positivamente o negativamente. Esempi tipici sono gli utenti finali, i clienti, i vari livelli di management, gli appartenenti all’organizzazione IT, gli sponsor del progetto, i “subject matter expert” (SME) o “esperti in materia”, ecc.

Nella nostra organizzazione siamo soliti riconoscerne un ristretto sottoinsieme che spesso e volentieri comprende solo il project manager presso il cliente (ossia la controparte del nostro PM) e gli utenti finali.

La stakeholder analysis si articola in una serie di passaggi che mirano a identificare tutti i portatori di interesse rilevanti ai fini della conduzione del progetto:

  1. Identificare tutti i possibili stakeholder
  2. Tracciare le rispettive attitudini nei confronti del progetto
  3. Selezionare gli stakeholder chiave (key stakeholders)
  4. Analizzare le fonti di preoccupazione degli stakeholder
  5. Identificarne i fattori di successo
  6. Sviluppare strategie di comunicazione con i key stakeholders
  7. Documentare il tutto nel Requirements Communication Plan

A tal fine risultano particolarmente utili alcuni strumenti tramite i quali rappresentare in forma graficai passaggi chiave della stakeholder analysis.

Per quanto riguarda la rappresentazione delle attitudini degli stakeholder nei confronti del progetto, si può utilizzare la Stakeholder Attitude Chart:

Nome, Posizione 100% contrario Moderatam. contrario Neutrale Moderat. a favore 100% a favore
Mario Rossi,

Finance

Ο

χ

Piero Bianchi,

Marketing

Ο

χ

Il simbolo “Ο” indica la posizione in cui attualmente si trova lo stakeholder mentre “χ” indica dove abbiamo necessità che si sposti per assicurare il successo del progetto.

La selezione degli stakeholder chiave avviene attraverso una matrice 2×2 nella quale i portatori di interesse vengono posizionati sulla base della loro influenza/potere/autorità (ordinate) e del loro livello di attenzione/preoccupazione nei confronti del progetto (ascisse).

Ne risultano quattro quadranti associati alle combinazioni: elevata influenza / scarsa preoccupazione, scarsa influenza / elevata preoccupazione, scarsa influenza/scarsa preoccupazione, elevata influenza / elevata preoccupazione: gli individui o le categorie che ricadono in quest’ultimo quadrante sono i key stakeholders.

L’analisi delle fonti di preoccupazione si può effettuare tramite una tabella come quella riportata qui sotto che consente di identificare l’impatto del progetto su diverse aree di interesse e sui relativi stakeholders.

In questa fase, per ciascuna area di interesse sulla quale il progetto ha impatto significativo, è necessario abbozzare una strategia di risposta o mitigazione del rischio corrispondente.

Aree di Preoccupazione Modesto impatto Moderato impatto Elevato impatto Stakeholder interessati
Struttura organizzativa X Mario Rossi,

Giorgio Verdi

Misura delle performance X Piero Bianchi
Competenze acquisite X Piero Bianchi

Infine, nella cosiddetta Stakeholder Solution Matrix è possibile combinare le informazioni raccolte nei passaggi precedenti e schematizzare possibili strategie per il comportamento da tenere con ciascuno degli stakeholders:

Stakeholder Preoccupazioni Fattori di successo Come influenzarlo Chi può influenzarlo
Mario Rossi,Finance Inadeguatezza ai nuovi compiti Training Illustrazione del programma di training e crescita professionale Responsabile formazione

Backup

Posted in IT by pigreco314 on 15 marzo, 2009

La strategia di backup per il mio laptop è organizzata così.

Utilizzo un solo archivio sia per i backup settimanali sia per quelli giornalieri.

Ogni domenica mattina alle 6 l’archivio viene re-inizializzato e viene effettuato un backup completo di tutti i file critici del mio computer (circa 20 Gb).

Ogni giorno alle 18.20 l’archivio viene aggiornato con il backup incrementale dei file creati o modificati dall’ultimo backup.

I programmi utilizzati sono quelli disponibili in Windows Xp, ossia ntbackup e task scheduler.

iPod Touch: sincronizzazione interminabile

Posted in Geek Corner by pigreco314 on 11 marzo, 2009

Se anche a voi capita che la sincronizzazione dell’iPod Touch con iTunes duri parecchi minuti,

iPod Touch Cake © ccyhan

iPod Touch Cake © ccyhan

provate a cancellare il contenuto della directory:

C:\Documents and Settings\<user>\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\<nome ipod>

nota bene: lasciate la directory, cancellate solo il contenuto