Le schéma classique du département est le suivant - les gens s'assoient au bureau (enfin, ou comme c'est maintenant dans un endroit éloigné) pour un paiement en fonction du temps (8 heures par jour) ou dans des ateliers de carrosserie à l'heure. Mettez-vous au travail en 30 à 120 minutes. Une personne est embauchée via hh ou des sites similaires, le candidat passe par hr'a, sécurité technique où il tente de dresser une matrice de compétences. Il y a beaucoup de candidats à Moscou avec n'importe quel niveau de connaissances, dans les régions c'est un problème.S'il n'y a pas d'université technique à proximité, mais que vous souhaitez diriger une entreprise, rendez-vous chez le millionnaire le plus proche et payez les salaires locaux. Ce dernier est particulièrement désagréable pour une startup. C'est bien si sur le projet où la personne a été emmenée existe et qu'il y a de la documentation sur les solutions avec une description des modèles de flux de données, etc., mais je n'ai jamais rencontré cela. Il y a des bribes, des enregistrements chaotiques, des procès-verbaux de réunion avec les raisons des décisions prises, mais la documentation de développement systématique est comme une double éclipse de lune. Pourquoi avez-vous besoin d'une documentation avec des schémas et des justifications? Lorsqu'un architecte esquisse un modèle pour un futur projet, il est porteur de connaissances uniques que personne d'autre ne possède. C'est un problème grave, si un spécialiste tombe malade, meurt, s'en va, ses compétences disparaîtront également avec lui.La restauration des compétences sans documentation et sans support de connaissances est une tâche tellement non triviale qu'il est plus facile de tout réécrire (les deux sont très coûteux). Introduire un nouveau combattant ou un ancien d'un autre projet dans un projet, c'est six mois de mentorat et de distraction pour ceux qui travaillent déjà. Dans le même temps, la nouvelle unité est également d'une fonctionnalité limitée dans l'ensemble. Le système d'énoncé de problème peut créer des branches, se diviser en sous-tâches et fusionner à partir d'endroits inattendus. La tâche peut ne pas passer par des chefs de file ou des architectes, ce qui ajoute des déchets et de la frénésie dans les tentatives d'élargissement de l'architecture ou de pousser dans l'imparable.Dans le même temps, la nouvelle unité est également d'une fonctionnalité limitée dans l'ensemble. Le système d'énoncé de problème peut créer des branches, se diviser en sous-tâches et fusionner à partir d'endroits inattendus. La tâche peut ne pas passer par des chefs de file ou des architectes, ce qui ajoute des déchets et de la frénésie dans les tentatives d'élargissement de l'architecture ou de bourrage dans l'imparable.Dans le même temps, la nouvelle unité est également d'une fonctionnalité limitée dans l'ensemble. Le système d'énoncé de problème peut créer des branches, se diviser en sous-tâches et fusionner à partir d'endroits inattendus. La tâche peut ne pas passer par des chefs de file ou des architectes, ce qui ajoute des déchets et de la frénésie dans les tentatives d'élargissement de l'architecture ou de bourrage dans l'imparable.
Problèmes avec le schéma classique
Les ressources humaines sont limitées dans la disponibilité et ne sont pratiquement pas susceptibles de changement opérationnel. D'où le problème des temps d'arrêt et des heures supplémentaires.
Il n'est pas rentable de garder des spécialistes restreints. Ces spécialistes sont une source unique de connaissances, mais les coûts de maintenance sont élevés et les tâches sont rares. D'où le problème des temps d'arrêt et de la stagnation des compétences.
Les membres des équipes se spécialisent dans les tâches courantes et commencent à se dégrader s'ils ne font pas d'efforts sur eux-mêmes ou n'y sont pas contraints.
Trouver une personne possédant les compétences nécessaires est difficile, voire impossible, compte tenu de l'argent et du temps alloués.
Manque de documentation décrivant le projet pour une intégration rapide pour un débutant.
Le besoin de mentors.
Le problème de l'expansion de la fonctionnalité sans une analyse approfondie d'une telle possibilité, et une telle analyse n'est possible que par le détenteur de compétences générales dans le projet - un architecte.
Le problème du décrochage des détenteurs de connaissances uniques sur le projet.
Le problème de l'atmosphère morale de l'équipe et des relations personnelles qui influencent l'adoption de décisions importantes.
Le problème de la non-transparence des finances pour le client et les interprètes sur la rémunération.
Le problème de l'augmentation du statut de l'exécutant et du type de tâches effectuées.
Est-il possible de niveler ces problèmes d'une manière ou d'une autre sans changer le paradigme (modèle) de gestion du développement? La réponse courte est non! À l'avenir, un tel modèle ralentira le travail, et avec une augmentation des affaires et une bureaucratisation des processus, il peut généralement forcer le transfert du développement vers l'externalisation. Est-ce une bonne chose d'externaliser le développement? - La réponse courte est oui, si cela va accélérer et faciliter le développement de produits! L'externalisation peut-elle être interne à l'entreprise? - Facile. Et externe? - c'est plus dur ici, non, la sécurité est tout ... mais possible! Et qu'en est-il interne et externe? - Vous pouvez et voici comment faire.
Le service est
- Le système de communication du client et des interprètes.
- Fournit une connexion dynamique de spécialistes possédant les compétences requises.
- Effectue les règlements avec le client et les entrepreneurs.
- Montre rapidement l'état du projet et l'avancement des tâches.
- .
- .
- .
- .
- .
- . , , , .
- . . “, , , ” — . “ ” — , , , , . “” — , , , . “” — . “ ” — , , . “ ” — , , , .
- . . , . .
- . . , , .
Chacun des rôles de niveau supérieur forme un pool de sous-tâches décomposées pour les rôles de niveau inférieur, spécifie les critères d'exécution et le coût de réalisation de la tâche. Le rôle supérieur ne peut pas affecter directement un exécuteur testamentaire ou s’attribuer à une sous-tâche.
Lors de la décomposition d'une tâche, le rôle de niveau inférieur doit recevoir la confirmation de sa solution du rôle de niveau supérieur qui a défini la tâche d'origine.
Le rôle subordonné, après avoir reçu le problème, peut l'envoyer pour examen au directeur avec justification des erreurs ou inexactitudes constatées, ou ouvrir un litige avec arbitrage et vote.
Le rôle supérieur peut assumer n'importe quelle tâche subordonnée si ce n'est pas son (tâche) directeur.
La tâche terminée est dans un pool spécial pour examen et approbation. La tâche peut être revue par le rôle actuel (mais pas par l'interprète) ou par un rôle supérieur ou inférieur.
Pour la tâche terminée et approuvée, l'exécutant se voit facturer le paiement spécifié dans la tâche (moins la commission de service pour la transaction) et les points de notation.
Pour un examen terminé avec une indication raisonnable d'une erreur ou d'un écart par rapport aux critères d'examen, des points sont attribués et ils sont radiés de la personne examinée. Les litiges basés sur les résultats de l'examen sont résolus automatiquement par un vote général des rôles ayant participé à l'examen.
La transition vers un rôle supérieur se fait automatiquement dès que le performeur atteint un certain nombre de points. Ainsi, vous pouvez parcourir toute la hiérarchie jusqu'au manager sans résoudre un seul problème, mais en gagnant des points dans l'examen des problèmes des autres.
Chaque arbre de décomposition de tâches et de tâches s'accompagne de la création d'un ensemble de documents justifiant le choix d'une solution et la décrivant brièvement. Chaque tâche qui n'est pas une branche d'une existante, c'est-à-dire étendre la fonctionnalité, doit commencer par l'approbation du gestionnaire, puis passer par l'approbation par les rôles jusqu'à l'exécuteur final.
La tâche est automatiquement considérée comme non exécutée si elle a été prise en charge, mais le délai est dépassé et aucune justification n'a été envoyée par le contractant pour prolonger le délai.
La tâche inachevée est remise dans le pool de tâches pour exécution et l'exécuteur est condamné à une amende sous forme de radiation de points.
L'ensemble d'un certain niveau de points négatif conduit au blocage automatique de l'interprète pour la compétence sélectionnée.
Le manque de tâches terminées ou de revues dans un certain laps de temps conduit à une diminution automatique du score global.
Lorsque le score tombe en dessous du niveau de seuil du rôle, le statut de l'intervenant est transféré à un rôle inférieur.
Schéma de déplacement des commandes du client au produit fini
Le client démarre un projet dans le service décrivant une tâche métier (il s'agit de l'information principale). Contribue à son compte dans le service le montant minimum des fonds nécessaires à l'expertise économique et marketing, ou si elle existe déjà, alors à la préparation d'une tâche technique par le dirigeant (développement, architecte). L'expertise économique et la justification technique comprennent des avis d'experts sur la faisabilité économique de ce produit. La faisabilité économique est une étude des analogues, de la demande, des ressources disponibles, de la faisabilité pratique présentée sous la forme d'un document avec des recommandations. La tâche passe à l'étape suivante lorsqu'il y a suffisamment de fonds sur le compte du client dans le service. Le client peut apporter son expertise ou TK (mission technique, architecture de projet) pour approbation. Si l'accord n'est pas passé,alors la tâche (projet) ne peut pas être prise en développement. Le client peut quitter le service à n'importe quelle étape ou le geler dans le service moyennant des frais. Le client a accès en lecture à toute la documentation et aux codes sources du projet, aux assemblages du package applicatif ou des ressources, à l'avancement du projet et des tâches, aux fiches de paie aux interprètes.
Le développement est réalisé conformément aux règles établies au début du projet, cela concerne la langue de préparation des documents et des descriptions, un accord sur le formatage du code et des commentaires auto-documentés. La priorité dans l'écriture des classes et des fonctions est donnée au code le plus simple et le plus propre. Dans tous les cas, lorsque cela est possible, le code est couvert par des tests unitaires. En développement, il devrait y avoir des spécialistes qui assurent le travail de contrôle de version, d'assemblage automatique, de connexion à distance des artistes interprètes aux équipements nécessaires du côté du service ou du client.
L'introduction d'interprètes dans le service est possible après réception de la matrice de compétences. La matrice de compétences peut être obtenue dans les services spécialisés dans les tests en mode automatisé. Les services accrédités fournissent une API avec laquelle vous pouvez obtenir une matrice pour un candidat. En fonction des résultats obtenus, les rôles et compétences de départ pour lesquels des tâches spécialisées seront visibles sont définis pour le compte de l'interprète. Pour résumer, l'exécutant s'inscrit auprès du service et reçoit un lien vers le service de test de compétences et les transmet. Les résultats des tests remplissent la matrice de compétences et le compte a la possibilité de prendre des tâches, de mener des revues, de lire la documentation disponible pour son rôle.
Il est recommandé dans un premier temps d'introduire dans le service les exécuteurs exécutifs exécutés sur la base existante du «bureau». Vérifiez le travail avec le client dans des projets réels. Réaliser une campagne de publicité dans les communautés spécialisées et les réseaux sociaux avec des thèses - «Transparence et honnêteté complètes, pas de secrets. Travaillez sur ce que vous voulez, d'où vous voulez et quand vous voulez. Personne ne vous commande. Gagnez autant que vous pouvez porter, sans limite pour tout le monde et pour toujours. "
Questions nécessitant une étude séparée
- Sécurité.
- Paiement et règlements avec le client et les entrepreneurs.
- Problèmes juridiques avant contrats avec le client et paiement à la pièce aux artistes interprètes, transferts transfrontaliers.
- Protection du droit d'auteur.