Je pense que souvent, la tendance à se sentir comme si vous étiez allé dans un terrier de lapin avec des analyses exploratoires est due à la perte de vue des questions de fond que vous posez. Je le fais moi-même, à l'occasion, puis je dois me rappeler quel est mon objectif. Par exemple, est-ce que j'essaie de construire un modèle spécifique ou d'évaluer l'adéquation d'un modèle existant? Suis-je à la recherche de preuves de problèmes avec les données (c.-à-d., Analyse de données médico-légales)? Ou est-ce aux premiers stades de l'analyse, où j'étudie des questions spécifiques de manière informelle (par exemple, y a-t-il une relation entre deux variables?) Avant de passer à l'élaboration d'un modèle formel? En somme, si vous vous surprenez à lancer des graphiques et des tableaux mais que vous ne pouvez pas indiquer clairement quel est votre objectif immédiat ou pourquoi ce graphique / tableau est pertinent, alors vous savez que vous ''
J'essaie d'aborder l'analyse exploratoire des données comme j'écris, qu'il s'agisse d'écrire un programme ou d'écrire un article. Dans les deux cas, je ne commencerais pas sans faire d'abord un plan. Ce schéma peut changer (et change fréquemment), bien sûr, mais commencer à écrire sans un est inefficace et donne souvent un mauvais produit final.
En tant qu'organisation WRT, chaque analyste doit trouver un flux de travail qui fonctionne pour lui - il est plus important de le faire à l'OMI que d'essayer de suivre rigoureusement le flux de travail de quelqu'un d'autre (bien qu'il soit toujours utile d'obtenir des idées de ce que font les autres). Si vous travaillez par programme (c.-à-d., Écrivez du code qui peut être exécuté pour générer / régénérer un ensemble de résultats) et archivez votre travail dans git, alors vous avez déjà des kilomètres d'avance sur beaucoup à cet égard. Je soupçonne que vous pourriez avoir juste besoin de passer du temps à organiser votre code, et pour cela, je vous suggère de suivre votre plan. Par exemple, gardez vos fichiers d'analyse relativement courts et ciblés, afin que chacun réponde à une question spécifique (par exemple, les tracés de diagnostic pour un modèle de régression spécifique). Organisez-les en sous-répertoires à un ou deux niveaux, selon la taille et la complexité du projet. De cette façon, le projet devient auto-documenté; une vue de liste des répertoires, sous-répertoires et fichiers (avec le commentaire en haut de chaque fichier) devrait, en théorie, reproduire votre plan.
Bien sûr, dans un grand projet, vous pouvez également avoir du code qui effectue le nettoyage et la gestion des données, du code que vous avez écrit pour estimer un certain type de modèle, ou d'autres utilitaires que vous avez écrits, et ceux-ci ne rentreront pas dans le fond pour votre analyse des données, elles doivent donc être organisées dans une autre partie du dossier de votre projet.
Mise à jour: Après avoir posté cela, j'ai réalisé que je n'ai pas directement répondu à votre question sur les "impasses". Si vous décidez vraiment qu'un ensemble complet d'analyses n'a aucune valeur, alors si vous travaillez dans git, vous pouvez toujours supprimer le (s) fichier (s) correspondant (s) avec un message de validation comme "Abandonné cette ligne d'analyse parce qu'elle n'était pas productif." Contrairement à froisser ce que vous avez écrit et à le jeter à la poubelle, vous pouvez toujours revenir à ce que vous avez fait plus tard, si vous le souhaitez.
Cependant, je pense que vous constaterez que si vous procédez à partir d'un schéma auquel vous avez réfléchi, vous aurez moins de soi-disant impasses. Au lieu de cela, si vous passez du temps à enquêter sur une question utile et pertinente - même si cela conduit à une conclusion nulle ou ne se révèle pas comme vous l'aviez prévu - vous voulez probablement garder une trace de ce que vous avez fait et du résultat (à un minimum, pour ne pas faire l'erreur de répéter cela plus tard). Déplacez-les simplement au bas de votre plan, dans une sorte d '"Annexe".