Bon après-midi Je voudrais raconter une histoire courte qui m'est arrivée il n'y a pas si longtemps et qui est liée à la fois aux attentes de carrière et à une perception erronée de ce qui se passe dans la réalité. Comment un employeur peut induire en erreur ou nuire inconsciemment à la motivation de l'équipe.
En arrivant dans une ville provinciale de Moscou, j'allais trouver un emploi en tant que chef du département informatique d'une entreprise. Après avoir terminé le développement professionnel à Moscou et toutes les étapes du travail de la première à la troisième, réalisant que j'aime la gestion et la gestion des personnes / des processus et que je peux le faire, j'ai commencé à chercher un poste vacant.
Détails sous la coupe.
Je n'ai pas été spécifiquement distrait par les postes vacants des transformateurs lorsque la société avait besoin de "spécial, moissonneur et joueur" (c'est quand une personne a besoin de souder des cartes et d'écrire des configurations 1C), j'ai patiemment attendu une bonne offre. Au bout de 2 mois, l'administrateur général du ministère est venu me voir avec une proposition qu'il était difficile de ne pas accepter. La direction vient d'apparaître, une entreprise d'envergure fédérale, créant un département d'accompagnement et de développement dans la région, les plans étaient grandioses et pleinement conformes à mes attentes. Il a été possible de constituer une équipe et des processus à partir de zéro, de les optimiser et de les intégrer dans les processus existants. Tout le monde a appelé le poste avec les fonctions de «coordinateur / chef du support technique». Eh bien, j'étais prêt pour la bataille.
Objectifs initiaux:
- Support en première et deuxième lignes.
- Création d'une base de connaissances
- Création de documentation utilisateur
- Plonger dans le processus métier pour la mise en place des "consultations entreprises"
- Préparer les règles d'interactions entre les unités dans le cadre de la méthodologie ITIL Service Desk (je prévoyais de ne reprendre que le processus de passage des applications et des incidents + rédaction du SLA, car je sais que personne ne donnera une implémentation ennuyeuse d'un processus entièrement formalisé, et ça ne marchera pas)
- Embaucher du personnel de soutien.
Création de documentation
Ce que je voulais: comme je devais maintenir le système d'information acheté, et que je m'occupais plus de l'infrastructure matérielle, j'ai décidé de m'engager progressivement et du côté le plus évident pour moi - j'ai demandé les règles des processus automatisés par le système et la documentation pour elle. Et je suis tombé sur la première surprise - il n'y avait aucune documentation pour le système acheté pour «de l'argent». Il y avait des diapositives esquissées par le développeur sur le genou, comment certains rôles sont impliqués dans le processus, et c'est tout. La société avait encore 4 mois de support contractuel, quand elle a pu être contactée pour des questions sur le fonctionnement du système. Il n'y avait pas de projet interne pour la mise en œuvre du système, les délais ont été fixés par accord et un document Excel, qui indiquait les dates de mise en œuvre de certaines améliorations. Oui, après mon embauche, le système a été complété pour 5 mois supplémentaires.
Ce qui s'est passé: Avec un péché en deux, plusieurs processus sont décrits sous forme de diagrammes Visio. Modules système partiellement décrits. En raison de la date limite, la communication avec les développeurs du système acheté est devenue encore pire. Si je comprends bien, la documentation n'était pas obligatoire lors de l'achat.
Conclusion: Un système non documenté non fini est mal décrit sans l'aide des développeurs. Essayez d'établir un processus de communication.Création d'une base de connaissances
Ce que je voulais: le support sur la première ligne était censé collecter un certain pool de questions auprès des utilisateurs, on supposait que les managers avaient déjà ce pool, au moins partiellement. Mais après des négociations avec le chef du service commercial, il est devenu clair qu'il n'y avait pas de pool et le processus ressemblerait à ceci: l'utilisateur appelle, s'il est connecté à la partie technique, nous aidons, si avec la partie commerciale, nous rappelons. Étant donné que la partie commerciale des réponses n'était pas du tout, les premiers utilisateurs n'auraient pas dû être très chanceux. Encore une fois, au cours de la conversation, j'ai réalisé que l'entreprise ne valorise pas vraiment les nouveaux utilisateurs et est prête à prendre ces risques.
Pour clarifier, avec de telles sources, l'image semblait plutôt vague, mais je l'ai prise comme un défi.
Ce qui s'est passé: Un document a été créé pour couvrir le volume initial de consultations commerciales. La procédure de collaboration avec l'entreprise n'a pas pu être réglementée. L'entreprise pourrait oublier de répondre à une nouvelle question «hors de la liste». J'ai dû faire une nouvelle demande, garder le contrôle. Une base de connaissances a été créée sur la base de docuwiki avec une description des problèmes, de l'architecture du système, des actions de base de la deuxième ligne de support et des administrateurs. Il n'a pas été possible de décrire la configuration pour créer un nouveau produit dans le système, car il a été créé de manière semi-programmable et il était nécessaire de le décrire avec les programmeurs.
Conclusion: La création d'une base de connaissances sacrifiant la fidélité des clients n'est pas la bonne étape. Si l'entreprise le fait, une charge supplémentaire incombe au support sous la forme d'excuses pour les défauts et le confinement de clients négatifs supplémentaires.Recrutement de personnel
Ce que je voulais: Pour sélectionner les employés, je suis allé méthodiquement dans mon équipe: j'ai sélectionné une liste de compétences et composé des questions pour un entretien téléphonique sur ces compétences. Au début, toutes les questions avaient le même poids, et après quelques entretiens, j'ai réalisé que tous les candidats étaient également adaptés au poste vacant et à un tel rythme, vous pouvez embaucher des personnes pendant longtemps. Toutes les compétences ont reçu un poids et le processus est devenu plus amusant.
Tableau des compétences de première ligne:
Ce modèle a été envoyé pour approbation par la direction, mais la réponse «appliquer-ne pas appliquer» n'est pas revenue.
J'ai pris la première personne sur la recommandation d'un ancien collègue sans gabarit (j'ai travaillé une semaine). Le prochain patron a pris. Les trois autres (filles) ont été recrutées en partie avec ma participation, mais sans demander mes recommandations et sans être intéressées par les opinions. Admission à la motivation matérielle et aux budgets que je n'ai pas reçus.
Ce qui s'est passé: Un service amusant, mais ne répondant pas pleinement aux exigences, a été recruté, où les employés font un excellent travail avec la première ligne, mais pour une immersion plus profonde dans le système, un processus correctement structuré de formation et de transfert de connaissances est nécessaire. Avec moi, les personnes ayant des RFP supérieures à la moyenne du marché ont perdu la motivation intangible à leurs yeux en raison d'un processus de travail mal réglé.
Conclusion: préparer pour le nouvel employé motivé la quantité de travail. Sinon, cela affecte gravement la loyauté envers l'employeur et le système. Comprendre le processus de motivation du personnel - matériel et immatériel.Processus de travail
Ce que je voulais: Après le démarrage du système, nous avons commencé à rencontrer les premières difficultés: l'ancienne interface avait l'air horrible et fonctionnait contre tous les concepts conviviaux. Le flux principal d'appels est allé à l'insatisfaction avec l'interface, et non avec le processus métier. Les utilisateurs ne pouvaient tout simplement pas faire de demande. Les principales erreurs ont été immédiatement signalées à l'équipe de développement nouvellement recrutée, mais ici nous avons été confrontés à un deuxième problème: il n'y avait pas de communication non seulement avec ceux qui soutenaient le système de l'extérieur, mais il n'y avait pas de priorité pour réparer le système - tous les efforts étaient consacrés à l'écriture de nouveaux fonctions et produits, il n'a pas été possible d'affecter une personne pour corriger les erreurs élémentaires qui diviseraient par deux le nombre d'appels.
Ce qui s'est passé: Après avoir à nouveau signalé les problèmes à la direction, celle-ci a quand même autorisé à apporter des corrections et le flux d'appels a triplé.
Conclusion: établir le processus de priorisation des tâches, discuter de l'ordre d'interaction avec l'équipe de développement.Face à chacune des tâches ci-dessus, je suis venu à la direction à chaque fois avec des suggestions pour rationaliser les processus et essayer de coordonner ma vision avec la vision de l'entreprise, mais je suis toujours tombé sur l'emploi du manager (un problème système) ou j'ai reçu la réponse «jusqu'à présent» et «nous ne voulons pas formaliser trop ". Je savais également qu'il était prévu d'étendre le service à 5 personnes et j'ai vu qu'il était nécessaire de comprendre comment le processus de soutien et les ressources seraient gérés. J'ai déjà commencé à soupçonner que les autorités avaient changé de plan pour moi en raison de mes efforts constants pour mettre en œuvre les changements. Je n'étais plus appelé coordinateur ou patron, je ne participais pas aux rassemblements liés au développement du système.
Après cela, j'ai décidé de préparer une stratégie et de comprendre si je le fais du tout. Parce que le patron n'a pas du tout communiqué avec moi en termes de stratégie. La stratégie a été dirigée immédiatement vers une personne supérieure en informatique à Moscou et, pour moi, l'image de mon travail a changé. Ensuite, la stratégie a été dirigée de Moscou vers mes patrons directs et je suis tombé dans une confrontation avec le patron local.
Conclusion: Analyser la stratégie de l'unité. Définissez des plans à court et à long terme. Discutez de la vision avec le leadership.La deuxième partie du "Ballet Marleson"
Après l'épisode décrit ci-dessus, le patron direct a pratiquement cessé de me parler. Et j'ai commencé à penser à partir. Au départ, j'ai vu un projet intéressant qui, après avoir surmonté certaines difficultés avec l'interaction correcte de tous les participants au processus, pourrait être mené à bien, après avoir reçu un département de support fortement motivé avec les bons KPI et des indicateurs de sortie clairs et compréhensibles pour l'entreprise. Maintenant, j'ai vu que le ministère tombait dans la routine sans vraiment la développer. Deux tâches sont devenues une priorité - répondre aux appels et décrire les bogues (et non les améliorations) du système à l'aide de gitlab, que les développeurs ont corrigés.
Une autre histoire est le processus de «test», comme l'a dit le manager, que nous avons également proposé de réaliser. Personne n'avait une compréhension de ces procédures, ni un testeur séparé. Test fonctionnel de la «boîte noire» sans aucun indicateur de performance par toute l'équipe avant sa sortie. Aucune autre méthode n'a été utilisée. Le personnel recruté n'a pas pu participer efficacement aux tests en raison du manque de connaissances dans le domaine du développement et d'un manque de formation. Les dates de sortie ont constamment échoué ou les versions ont été déployées sans test.
Conclusion: le ministère ne peut pas traiter efficacement deux grands processus en parallèle. Il y aura en quelque sorte deux processus.
La confrontation s'est poursuivie. Le gestionnaire a réussi à inverser tous les éléments de gestion que je considérais importants:
- vision stratégique
- contrôle
- gestion
- motivation
Des points magiques tels que «la fidélité à l'entreprise sous la forme de venir travailler plus tôt et de partir plus tard» ont également été exprimés.
Ayant finalement perdu ma motivation, j'ai invité le patron à parler de mon futur poste dans l'entreprise et de la décision de le quitter, où on m'a dit que le département dans sa forme actuelle convient à tout le monde et qu'il n'est pas prévu de développer des éléments individuels. En conséquence, j'ai quitté l'entreprise, ayant acquis une expérience pratique en essayant de réaliser ma vision du travail du service d'assistance.
Ce qui s'est passé: expérience, expérience et encore expérience.
Conclusion: quelles erreurs j'ai enregistrées par moi-même:
- Afin de ne pas perdre de temps - fixer et coordonner les plans à l'avance
- Définissez clairement votre stratégie. S'il y a des omissions - résolvez les problèmes immédiatement
- Choisissez vous-même un flux de travail confortable. Trouvez un compromis entre votre motivation matérielle et immatérielle
- J'ai peut-être passé trop de temps à comprendre ces choses. Beaucoup gisaient en surface
Je voudrais également entendre de la part de mes collègues vos histoires et nuances de mise en œuvre, auxquelles, par manque d'expérience, je n'ai pas prêté attention.