Je suis en train de concevoir une fonctionnalité pour Basecamp 4 qui ajoute une dimension temporelle aux projets. Mon écran d’accueil Basecamp est aujourd’hui un mélange désordonné de certains projets en cours et de nombreux projets obsolètes. Il n’y a jamais de bon moment pour faire le ménage nécessaire à l’archivage d’anciens projets. Une partie de l’idée de cette fonctionnalité est de définir des dates de fin sur les projets, afin que nous puissions automatiquement filtrer les choses qui ne sont plus pertinentes et augmenter le signal sur l’écran d’accueil.
Il y a une partie délicate à cela. Nous voulons masquer les projets antérieurs afin qu’ils n’encombrent pas l’écran. Mais la réalité est que les projets se déroulent presque toujours au-delà de la date exacte à laquelle ils sont dus. Alors, quel est le bon moment pour cacher un projet ? Quelqu’un essaiera-t-il de naviguer vers un projet un jour après sa fin supposée et ne pourra-t-il pas le trouver ? Quand un projet est-il « passé » ? Comment pouvons-nous à la fois montrer des projets passés et ne pas les montrer ? Comment les gens prolongent-ils les projets, quand et où leur demandons-nous de le faire, et qu’est-ce qui ne va pas s’ils ne le font pas ?
Je ne connais pas la meilleure réponse à ces questions. Mais j’ai quelques réponses différentes assez bonnes.
C’est là que le travail de mise en forme est différent du travail normal. À l’intérieur d’une boîte de temps fixe, les concepteurs et les programmeurs doivent décider de la direction spécifique à construire. Mais avant d’être dans la timebox, avant de parier du temps et des gens sur le projet, la question est différente. Je n’ai pas besoin de savoir quelle est la meilleure solution. J’ai besoin de savoir qu’une solution existe.
Il y a une grande différence entre aucune solution, certaines solutions et la meilleure solution. S’il n’y a pas de solution à cette question particulière, et que la question compte, le projet mourra dessus. S’il existe des solutions qui fonctionnent toutes, alors nous pouvons aller de l’avant. Ce qui est important, c’est que nous obtenons ce résultat plus important que nous voulons lorsque toutes les parties du projet s’intègrent ensemble.
Dans ce cas particulier, j’ai au moins trois solutions différentes esquissées. Certains impliquent de demander explicitement aux gens de déplacer la date de fin. D’autres révèlent des projets passés pendant une période de grâce plus longue afin qu’ils ne disparaissent pas. Je ne sais pas lequel a raison. Je ne sais pas lequel est le meilleur. Mais je suis convaincu que le projet ne mourra pas sur cette question. N’importe lequel d’entre eux fonctionnera. Une solution existe dans le temps que nous sommes prêts à accorder à l’équipe.
Ceci est un autre exemple de plafonnement des baisses au lieu de rechercher la hausse la plus élevée. L’équipe travaillant dans la boîte à temps pourrait trouver une solution meilleure que toutes celles que je suis en train de façonner. Mais s’ils ne le font pas, au moins je sais qu’il existe une solution suffisante pour maintenir le projet ensemble.
