Parcours d’apprentissage : responsable produit

La section responsable produit traite de la façon dont ce rôle s’intègre dans InnerSource.

Ouverture

La gestion intermédiaire est difficile

Les principaux avantages sont intégrés au processus InnerSource

Nouveaux rôles et responsabilités

Recap et à emporter

Clôture

Manuel

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

Manque de développeurs compétents en raison de la forte concurrence sur le marché pour les salariés
Manque de reconnaissance du rôle du gestionnaire dans la réussite du projet
Manque de participation à la vision de l’organisation
Manque de clarté dans l’affectation des fonds

Pourquoi 1 est incorrect: La concurrence pour le personnel de développement qualifié est certainement un problème dans le domaine informatique à l’heure actuelle, mais InnerSource ne peut pas traiter avec cela. Il ne fait pas les développeurs jaillir du sol.

Pourquoi 2 est correct : La vidéo a mis en évidence l’invisibilité de nombreuses activités de la gestion intermédiaire. InnerSource donne à ces gestionnaires l’occasion de participer davantage aux discussions qui traversent les limites de l’organisation, et son parcours historique conserve des preuves de leur contribution.

Pourquoi 3 est correct : les cadres moyens estiment qu’ils sont responsables de l’exécution des choix faits par la haute direction, mais ne peuvent pas influencer ces choix. En revanche, InnerSource met les gestionnaires en communication avec d’autres équipes, offrant ainsi la possibilité d’élargir leur propre influence et de participer plus activement à l’élaboration des objectifs et de la vision de leurs projets.

Pourquoi 4 est inexact : InnerSource n’a pas d’incidence directe sur le financement, donc le financement n’est pas discuté dans ce segment vidéo. Cependant, l’adoption de InnerSource a un impact indirect sur le financement, car maintenant les travaux sur un projet sont partagés par plusieurs équipes, et la direction doit reconnaître que les ressources sont dépensées différemment. Plus précisément, la quantité de codage par membre de l’équipe diminuera légèrement en faveur de la communication et de la documentation, tandis que la production globale du projet devrait augmenter grâce à la collaboration.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

Un retard dans la mise en œuvre d’une caractéristique importante parce que l’équipe responsable lui attribue une faible priorité
Intégration lente des corrections de bogues soumises par des tiers
Ne pas reconnaître la valeur des contributions des cadres intermédiaires
Connaissances limitées à quelques développeurs clés

Pourquoi 1 et 2 sont corrects : Dans les organisations traditionnelles, seule l’équipe hôte peut changer son code. D’autres équipes doivent soumettre des demandes et attendre que leur importance soit reconnue. Avec InnerSource, une équipe extérieure qui a besoin d’urgence d’un changement peut le coder elle-même, avec les conseils de l’équipe hôte.

Pourquoi 3 est correct : Comme InnerSource nécessite des contributions de nombreuses équipes différentes, les plans devraient être publiés et partagés. Cela permet non seulement la coordination, mais met en lumière les contributions d’une gestionnaire et de son équipe à l’ensemble de l’organisation.

Pourquoi 4 est correct : InnerSource appelle à la documentation et à la transparence dans le code et les lignes directrices. Si un développeur clé quitte ou est occupé, les connaissances seront mises à la disposition des autres.

Normes générales
Processus
Documentation
Crédit pour réalisations

Pourquoi 1, 2 et 3 sont corrects : Les normes, les processus et la documentation sont des éléments importants de collaboration qui permettent à plusieurs équipes de produire du code pour un projet partagé. Le partage des normes, des processus et de la documentation avec le code lui-même les rend explicites, ainsi que faciles à consommer et à entretenir.

Pourquoi 4 est correct : le contrôle de la version, les panneaux de messages et d’autres outils conservent un enregistrement de ce qui s’est passé et qui a contribué. La transparence et l’accès ouvert qu’ils créent assurent la visibilité et permettent ainsi un crédit approprié pour les réalisations des projets InnerSource.

Une plus grande dépendance à l’égard des autres équipes pour la mise en œuvre des caractéristiques requises
Approches plus souples de la gestion du cycle de vie des applications
Plus de discussions entre propriétaires de produits sur différentes équipes
Vues divergentes du produit parmi les différentes équipes

Pourquoi 1 est incorrect : chaque équipe devrait avoir le personnel et les ressources dont elle a besoin pour répondre à ses besoins. Lorsque vous vous engagez dans InnerSource, une équipe externe peut implémenter une fonctionnalité ou un bug nécessaire à l’équipe d’hébergement. Cependant, il devrait être considéré comme une coïncidence de chance plutôt qu’une partie du plan produit de l’équipe d’accueil.

Pourquoi 2 est incorrect : la définition des exigences, le développement de code, les tests, le contrôle de code et le déploiement – les différentes parties du cycle de vie de l’application – sont toujours aussi importants qu’ils l’étaient. Les intervenants fiables veillent à ce que les étrangers respectent le cycle de vie et respectent les normes de l’équipe pour assurer la qualité.

Pourquoi 3 est correct : les contributeurs, les commiteurs de confiance et les propriétaires de produits ont tous plus de discussions sur les projets InnerSource afin de collaborer à la recherche de solutions. L’apport d’autres propriétaires de produits incarne des connaissances précieuses sur leurs utilisateurs, l’histoire de leurs projets, les obstacles à surveiller et d’autres choses. Cela rend la communication supplémentaire très utile.

Pourquoi 4 est incorrect : InnerSource favorise la communication entre les équipes afin que chacun ait une vision cohérente de ce qui doit être fait. Bien que les équipes puissent avoir des objectifs différents et travailler sur un projet pour atteindre ces objectifs, elles devraient être unifiées selon leur point de vue sur le produit.

Est moins nécessaire parce que les équipes partagent une base de code
Peut nécessiter une formation et un mentorat afin que les chefs de projet collaborent efficacement
Conduire à une plus grande autonomisation des cadres intermédiaires
Doit être écrit autant que possible

Pourquoi 1 est incorrect : La collaboration et la négociation deviennent plus importantes que jamais dans InnerSource. Les intervenants expliquent ce qu’ils veulent changer et pourquoi. Les commiteurs de confiance travaillent avec eux pour s’assurer que le projet est réussi et fonctionne bien dans la base de codes.

Pourquoi 2 est correct : le personnel technique sort généralement des programmes de formation collégiale ou d’autres avec des compétences en programmation, et peut-être en ingénierie et en gestion de projet. Mais ces programmes reconnaissent ou enseignent rarement la valeur de la formation et du mentorat, qui sont la clé de InnerSource. Les entreprises devraient envisager de combler cette lacune par leur propre formation.

Pourquoi 3 est correct : Parce que les cadres moyens peuvent participer à la décision d’autres équipes et aider à la mode, ils peuvent atteindre plus facilement leurs propres objectifs.

Pourquoi 4 est correct : les gens ne peuvent pas participer à un objectif commun s’ils n’ont pas les mêmes vues sur les objectifs clés et les moyens de procéder. La documentation permet de s’assurer que tout le monde s’accorde avant de commencer les tâches et procédures importantes.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

Faire savoir aux contributeurs sur quoi ils devraient travailler.
S’assurer que toutes les demandes de contributeur entrent dans le produit.
S’assurer que votre équipe utilise les mêmes processus que les autres équipes.
Inviter les contributeurs externes à rédiger des normes de codage et des normes UI/UX.

Pourquoi 1 est incorrect : InnerSource compte sur les contributeurs pour décider sur quoi ils travaillent en fonction de leurs propres besoins. Bien que le propriétaire du produit puisse décider pour sa propre équipe sur quoi travailler ensuite, les contributeurs de InnerSource choisissent eux-mêmes de travailler selon leurs propres critères. Les donateurs fiables peuvent encourager les contributeurs à travailler sur des projets particuliers, mais la décision de le faire incombe au contributeur.

Pourquoi 2 est incorrect : les contributeurs InnerSource possèdent leur propre destin en ce qui concerne le travail terminé. Bien que le propriétaire du produit puisse s’entendre sur le travail qui doit être fait, il appartient en fin de compte au contributeur de faire le temps, de faire le travail et de répondre à toute rétroaction de commiteur de confiance afin que le travail puisse devenir une partie du produit de l’équipe hôte.

Pourquoi 3 est incorrect : les équipes DIfferent peuvent utiliser différents processus parce que leurs produits l’exigent, parce qu’ils ont choisi différents outils ou langages de programmation, ou pour des raisons historiques ou culturelles. Les différences dans les processus n’empêchent pas les équipes de travailler ensemble de manière InnerSource. Cependant, chaque équipe devrait documenter ses processus et apprendre les processus d’une autre équipe lorsqu’elle travaille sur le code de cette équipe. Les externes peuvent également aider à documenter les processus d’une équipe, les normes de codage et les normes UI/UX.

Pourquoi 4 est correct : les étrangers apportent souvent des perspectives importantes, à la fois sur les besoins des utilisateurs et sur des méthodes robustes pour répondre à ces besoins. Ils peuvent revoir les normes de votre équipe, et peuvent même y contribuer. Les propriétaires de produits et les intervenants de confiance devraient solliciter des contributions aux normes.

Aider à estimer les besoins en ressources et les délais
Créer une interface utilisateur ou une documentation d’expérience utilisateur (UI/UX)
Dupliquer le travail effectué dans d ‘ autres équipes
Ecrivez leurs conseils lors de la formation des collaborateurs

Pourquoi 1 est incorrect : les commiteurs de confiance peuvent fournir une contribution précieuse pour déterminer les besoins en ressources et les échéances, parce qu’ils comprennent bien l’état du code et des capacités des contributeurs.

Pourquoi 2 est incorrect : les commiteurs de confiance devraient également comprendre les besoins de l’utilisateur final afin de créer un code qui répond à ces besoins. Par conséquent, il peut être raisonnable pour les engagés de confiance de travailler sur la documentation UI/UX.

Pourquoi 3 est correct : le point de InnerSource est de rassembler tous ceux qui sont intéressés par une fonctionnalité, afin qu’ils puissent collaborer à la création du code nécessaire en un seul endroit. La duplication est une mauvaise architecture et un gaspillage.

Pourquoi 4 est incorrect : La plupart des communications entre les commiteurs de confiance et les contributeurs sont écrites et asynchrones, parce qu’elles sont souvent à différents endroits. De plus, la communication écrite reste un enregistrement de ce qui a été fait et pourquoi. Il peut être utile pour la formation des futurs contributeurs. Il y a beaucoup de façons en plus de l’email pour enregistrer des communications écrites, mais l’email reste un moyen populaire et utile.

Haute direction.
Contributions extérieures.
Maîtres de Scrum.
Des commiteurs de confiance.

Pourquoi 1 est inexact : la haute direction peut fixer des priorités stratégiques pour l’entreprise, mais elle n’est généralement pas impliquée dans la mise en oeuvre sur le terrain par l’intermédiaire de InnerSource.

Pourquoi 2 est incorrect : Une fois qu’un contributeur est trouvé, l’auteur de l’engagement de confiance a la responsabilité première de les aider à apporter une contribution réussie au projet.

Pourquoi 3 est incorrect : Scrum peut être utilisé ou non sur les projets InnerSource, et peut ne pas fonctionner bien entre les équipes (en particulier les équipes géographiquement éloignées). Le processus critique InnerSource implique le soutien de personnes motivées, et non un effort d’équipe comme Scrum.

Pourquoi 4 est correct : les commiteurs fiables font fonctionner InnerSource sur le terrain. Ils sont essentiels pour faciliter les changements que d’autres équipes apportent à la base de codes d’une manière qui fonctionne pour les deux équipes.

Ils ont besoin d’une mise à jour dans votre projet afin que leur propre projet puisse aller de l’avant.
Ils voient combien votre projet est important pour l’entreprise et veulent l’aider.
La contribution permet à leurs compétences en génie de mûrir en effectuant des travaux dans un nouveau domaine technique.
Leurs projets d’équipe se chevauchent avec le vôtre et leur contribution est un moyen de mettre en commun les ressources des deux équipes pour faire plus.

Pourquoi 1 est correct : lorsqu’une fonction de votre arriéré n’est pas importante pour le projet global mais très importante pour une équipe particulière, une contribution InnerSource est un excellent moyen pour cette équipe de sortir l’élément de votre arriéré et de votre projet.

Pourquoi 2 est incorrect: Tout le monde est occupé avec son propre travail. Même si le travail dans votre projet est essentiel à la réussite de l’entreprise, il est peu probable qu’il obtienne l’aide supplémentaire des autres par l’altruisme seul.

Pourquoi 3 est correct : travailler dans une nouvelle technologie est la meilleure façon de l’apprendre. Les ingénieurs doivent toujours apprendre de nouvelles compétences, et le faire via la contribution InnerSource est un excellent moyen d’aider l’entreprise en même temps.

Pourquoi 4 est correct : InnerSource économise les coûts de développement en permettant aux équipes ayant des projets redondants ou redondants de collaborer sur un seul code basé au lieu de silos d’ingénierie dupliqués.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

Placez la responsabilité de la sortie de votre équipe sur d’autres équipes
Plus de contrôle sur un projet
Réduire les interactions longues avec d’autres équipes
Accomplir plus de tâches, et les faire plus rapidement, en exploitant les contributions d’autres équipes

Pourquoi 1 est incorrect : Une équipe reste responsable des tâches qui lui sont assignées. InnerSource aide d’autres équipes à mettre à niveau votre base de code pour répondre à leurs besoins, mais elles ne prendront pas en charge vos tâches.

Pourquoi 2 est correct : lorsque votre équipe contribue à une autre base de code team, vous pouvez implémenter une fonctionnalité dont vous avez besoin dans le délai nécessaire, en investissant le temps nécessaire pour le développeur. Quand une autre équipe contribue à la vôtre, vous renoncez à un petit contrôle sur la façon dont une fonctionnalité est mise en œuvre, mais peut employer l’aide extérieure pour respecter les délais pour les besoins recoupements plus efficacement.

Pourquoi 3 est incorrect : les interactions avec d’autres équipes augmenteront considérablement après l’adoption de InnerSource. L’augmentation du temps consacré à l’interaction sera payante à mesure que les équipes répondront plus efficacement à leurs besoins.

Pourquoi 4 est correct : InnerSource donne une prise pour les équipes avec une demande pent-up ou du temps pour contribuer à votre projet d’une manière qui leur donne ce dont elles ont besoin tout en faisant avancer les fonctionnalités de votre projet.

Négocier avec d’autres propriétaires de produits.
Marchéz le projet de l’équipe à d’autres parties de l’entreprise.
Soutenir le rôle d’engagement de confiance.
Adopter des pratiques de planification ouvertes.

Pourquoi 1 est correct : InnerSource permet aux propriétaires de produits de négocier directement pour mettre en place des contributions d’une équipe à l’autre.

Pourquoi 2 est correct : les contributeurs ne se regroupent pas toujours à un projet juste parce qu’il est déclaré « open ». Allez trouver des gens qui pourraient être intéressés à contribuer et leur dire pourquoi ce serait une bonne idée de le faire.

Pourquoi 3 est correct : une fois qu’une contribution est alignée, le rôle de commiteur de confiance est essentiel pour s’assurer que le code soumis répond réellement aux besoins des équipes d’invités et d’hôte.

Pourquoi 4 est correct : la planification ouverte facilite la collaboration avec les autres. Puisque les décisions et l’information sont ouvertes, la politique organisationnelle est réduite et les gens peuvent se concentrer sur le travail qui doit être fait et sur la façon de l’accomplir.