Ciao, Habr! L'articolo è in parte corretto, e non solo mi ha toccato e attirato la mia attenzione, ma letteralmente calpestato i calli malati della mia anima manageriale. In generale, 10 anni fa, quando ho iniziato a lavorare nel settore IT, ho pensato allo stesso modo dell'autore dell'articolo. Ti parlerò di forchette, rastrelli e nuvole paradisiache di questo approccio.
Percorso: manager - tecnico collaudatore - responsabile
Così, nel 2007, sono venuto a lavorare per una grande azienda di telecomunicazioni e ho subito riscontrato seri problemi nella comunicazione con i programmatori e la divisione Sistemi di controllo automatizzati. I ragazzi sul nostro TK ci ha preparato per caricare i dati, di cui abbiamo trattato in Excel e Access e quindi utilizzato per le esigenze aziendali standard quali mailing list, lo sviluppo di piani tariffari di nicchia e di ricerca di venditori senza scrupoli della nostra connessione a pacchetto simchatyh. I programmatori odiano i nostri termini di riferimento - il commento più innocua è stata una sfida per lui e gettando un foglio stampato con le parole "sufficiente per produrre essenzialmente scrivere ciò che si vuole, questo non è tutto." Sono stato male, perché ogni TK ho dipinto l'on-laurea con attenzione: chi è il cliente, per qualsiasi scopo, qualsiasi campo, le date, le scadenze, le approvazioni, ecc
Durante un'altra cena con gli sviluppatori è venuto da me la consapevolezza che tutto questo è perché sto da nessuna parte si adatta con la sua formazione economica e di imparare a comunicare con i programmatori, è necessario ... per diventare uno di loro. Così sono andato a una corporate university di Nizhny Novgorod, dove per due anni in tutta serietà masterizzato (ciao, NIIT!): Algoritmi e strutture dati, C, C ++, Java (come sparare), il Python (lo amava teneramente) un piccolo assemblatore (e Java non è niente) e persino diagrammi UML e gestione dei progetti IT. Abbiamo avuto un corso di grande e profondo UNIX in cui ho imparato a lavorare con la console, la compilazione di gcc, grep-amb, scrivendo espressioni regolari, incontrati con vim, etc.
I miei compiti tecnici sono cambiati: sono diventati quasi degli script pronti per il campionamento e ... hanno dissipato ancora di più l'ACS-shnikov. Cosa è successo?
C'era la certezza della propria correttezza e scelta, mentre i programmatori erano più esperti. Il gestore di groping, che può modificare i file in vim e leggermente secante in SQL, è diventato un mal di testa per sette persone.
Le abilità sono state trasmesse su sistemi completamente diversi. Ad esempio, la mia conoscenza di Python non si trova nel fraintendimento di SQL.
Sono cresciuto in modo significativo rispetto ai miei colleghi-manager, che hanno causato malintesi. Ma i rapporti con il servizio di sicurezza erano eccellenti - ora sapevo che la frode non viene catturata con l'aiuto della magia, ma con l'aiuto di script, rimozione, analisi e controllo del traffico. Abbiamo implementato progetti interessanti e l'universalità era giusta.
L'accuratezza del calcolo del tempo e dei costi per l'implementazione del prossimo progetto non è aumentata, perché una cosa è progettare tutto e un'altra è implementarla. Dovevo andare in testing e rendermi conto che i diagrammi UML non risolvono nulla. Alcuni sviluppatori non ne erano nemmeno a conoscenza, ma avevano calcolato il codice con velocità furiosa e sapevano come gestire il loro tempo all'interno del progetto, mentre altri sapevano tutto, ma non codificano molto - semplicemente non avevano le competenze. I teorici.
La cosa più importante - capire il codice dei prodotti e il codice dietro ai servizi, non ha dato quella conoscenza approfondita del prodotto, che appare in diretta interazione diretta con lo sviluppo nel ruolo dell'utente. Eccolo: il gestore è il ponte tra lo sviluppatore e l'utente finale. E, per migliorare qualcosa, è necessario capire cosa manca al cliente e ai suoi dipendenti, e non perché il modulo funzioni in 0,15 ms, e non dopo 0,11 ms. Lo giuro, l'utente non se ne accorge. Ma il fatto che non ci sia croce, che chiude il programma, anche note (il vero bug di una delle uscite del cabinet personale dell'abbonato).
In generale, ho iniziato a capire che essere un manager non è un onore ed è andato agli ingegneri dei test in azienda, sviluppatore di sistemi di comunicazione e commutazione. Cosa intendi? Correttamente - era dall'altra parte delle barricate e ora è il mio turno di essere frustrato alla vista del project manager o, peggio ancora, del marketer o del venditore. "Il blocco del bug cliente", "kicker da parte del cliente", "Richiesta di funzione, peredaom in fase di sviluppo" - oh, queste persone in generale capire come allenarsi e che non siamo fino a nuove funzionalità?! Come potresti assegnare un critico a un bug minore? Perché i responsabili di progetto in modo impropriamente utilizzano le parole: Backlog, Sprint, commettere, bug tracker, perché sono confusi e Bugzilla di Mozilla di Firefox, il che significa l'espressione "zadevelop funzione, quindi posso tenere una riunione con l'account', non è vero non parli? In effetti,
Dietro le spalle del manager ci sono i soldi. E tutto il lavoro di programmazione, il lavoro del tester e dell'ingegnere è il denaro della compagnia a cui esiste e da cui ci viene pagato uno stipendio. E se il manager nel suo orario di lavoro "getta l'architettura" e scava nelle discariche di Wireshark, per svelarsi al programmatore in tutta la sua gloria, perde proprio questo denaro.
Regole del manager Jedi
Come già sapevi, dai tecnici di collaudo, sono tornato ai dirigenti, già rinato e cosciente. Ahimè, non posso parlare dei dettagli della gestione del progetto RegionSoft Developer, Studio , dal momento che è uno sviluppo chiuso e l'introduzione, la storia di cui è necessario negoziare con i clienti, ma dopo una doppia trasformazione quali sono felice di condividere le regole con cui si può essere responsabile veramente successo.
È necessario conoscere il prodotto a livello di codice (più precisamente, l'architettura), ma non codificarlo.Conoscenza del prodotto da e per - la prima abilità di qualsiasi manager (progetto, prodotto, vendita, marketing). Se non si capisce come e perché si può utilizzare, non si vede il rapporto di moduli ed entità che non sono a conoscenza di ciò che la modifica avrà effetto su una particolare funzionalità, non si può mai fare un prodotto di successo sul mercato. Una profonda comprensione del funzionamento e dei principi del lavoro aiuta il manager a essere esigente e esperto, ma non un cliente interno stravagante. Ahimè, le persone PR e i marketer con rare eccezioni non lo capiscono, quindi tutta la speranza è su di noi.
Il principio è semplice: non offrire nuove funzionalità solo per il gusto di essere; Non cancellare da un concorrente senza guardare; Non andare avanti sui cambiamenti folli del cliente. Se conosci l'architettura del prodotto, non dirai mai al programmatore: "Beh, per te è difficile svitare uno stampo semplice, il cliente dice che sono due ore." Semplicemente perché capisci perfettamente dove verranno fuori i cambiamenti e quanto lavoro avranno bisogno gli sviluppatori e i tester. Giuro, è più facile dissuadere dal modulo del cliente.
Il tuo lavoro, i programmatori e gli ingegneri faranno il loro.Essere in grado di analizzare il codice, il traffico, utilizzare il debugger nel browser - ottime capacità di lavoro analitico. Ma per il tempo di comunicazione con i programmatori, tienili a te stesso. La questione è che gli sviluppatori in ogni caso controlleranno le informazioni e rimuoveranno i loro dump, portar via e analizzare i log. E lo faranno molto più professionalmente rispetto al manager, che ha risolto le informazioni tra il caso.
Un manager con competenze di programmazione (più accurata progettazione e sviluppo di software) è un dono del destino. Il manager, perdere tempo per imparare la riga di comando e vim-a è un'imitazione inefficiente.
Impara a scrivere TK e traduci dalla lingua del cliente nella lingua dell'attività.Questa è un'abilità molto importante. Impara a stare dalla parte del cliente, analizzare i suoi requisiti, raccoglierli e organizzarli in un compito tecnico chiaro, che può essere concordato, firmato e andare al lavoro. Questo è di nuovo il blocco di attività del manager, dove deve mostrare la sua comprensione dello sviluppo e della conoscenza del prodotto. Le descrizioni dovrebbero corrispondere alle essenze dell'architettura, i requisiti - per non andare oltre i limiti della realtà, i prezzi e i termini - sono correlati alla capacità del team di sviluppo che tiene conto dell'intero carico di lavoro. In caso contrario, dovrà negoziare una scadenza differita e lavorare a discapito dell'azienda, e questo non è l'obiettivo per il quale il project manager esiste.
Impara a comunicare con il cliente.Il più delle volte, i clienti sono lontani dalla sfera dello sviluppo del software e del design, non è chiaro il motivo per cui non è possibile aggiungere una "piccola finestra" o "una piccola funzione, poco costoso e di breve durata lo stesso" (così, ad esempio, come questo: collegare al sistema di lettura camere della vettura all'ingresso, la prescrizione logica di riconoscimento del marchio sulla targhetta e riconoscimento del numero dello stato). Un manager è un buffer tra i desideri del cliente e le capacità del programmatore, che sa come eliminare le fantasie inutili dalle richieste. Un buon manager studierà attentamente l'attività del cliente, considererà tutti i requisiti e sarà in grado di identificare quelli che sono veramente necessari, giustificare la scelta e convincere il cliente che lo ritiene.
Pianificare all'interno della squadra.In generale, il piano di lavoro del team con l'orizzonte per un mese o più è letteralmente il principale trucchetto del manager. Nessuna decisione dovrebbe essere presa senza analizzare l'utilizzo delle risorse. E solo a prima vista sembra che il download sia facile da prevedere. Nelle stesse implementazioni di CRM o di qualsiasi altro software, diverse persone sono impiegate contemporaneamente in diversi progetti e tali progetti avvengono per un anno a venire. È importante non solo dare la priorità, ma anche farlo, tenendo conto della fattibilità economica, della criticità del compito, della dimensione del progetto. Oh sì, e tenendo conto del programma delle vacanze :-)
Impara a comprendere i rischi, a vederli e gestirli.Un buon manager predice, analizza e sopprime il rischio prima che diventi un rischio. Il gestore dovrebbe disporre di un intero sistema di gestione dei rischi, una tabella che elenca potenziali minacce, indicatori di rischio e modi di rispondere. E qui il manager ha un altro mal di testa: il rischio può andare alla testa, non particolarmente interessato al segno. Colpevole di conseguenza, ci sarà ancora una squadra, ma è sicuramente necessario essere pronti per questo scenario.
Gestisci il tuo budget.I bilanci per il progetto alcuni: la prima - è il costo della sua attuazione, la seconda - il costo del cliente per l'acquisto, il terzo - i costi reali di attuazione. Se non gestisci il budget, il terzo si trasformerà in un mostro che divorerà tutti i benefici commerciali. Pertanto, il manager deve conoscere esattamente punto di salvataggio, arretrati costi aumentati, che dovrebbero essere controllati, e capire come gestire tutti i tre aspetti che il cliente era soddisfatto e l'azienda ha partecipato al nero. Le deviazioni a prezzo scontato, le multe per un ritardo di mezza giornata e le clausole imprudenti del contratto riguardano esclusivamente il budget, quindi non dimenticare che questo è il tuo compito.
Sai come pensare in modo critico.Ogni manager dovrebbe avere una serie di caratteristiche del progetto: prezzo, tempistica, risorse, strumenti necessari, ecc. Se avete domande o problemi, dovreste valutare i pro ei contro, capire il grado di influenza sull'intero compito nel suo insieme. Ad esempio, se vi viene offerto da utilizzare per lo sviluppo di una versione beta della più recente quadro, come project manager, non si dovrebbe correre a leggere tutti i manuali, ma dovrebbe riflettere: quanto la versione grezza di che tipo di sostegno sarà, come molti bug in qualsiasi versione beta, etc. Sebbene in questo esempio si tratti più di thymlide, ma la situazione è molto comune.
Per formare un pensiero critico, è necessario raccogliere autonomamente strumenti e approcci che ci consentano di analizzare logicamente e sistematicamente il cambiamento di ciascun fattore. Quindi le decisioni saranno ponderate, non "WOW, guidato!"
Impara a coordinare la squadra in base alla situazione, non agile. La vostra azienda può lavorare in modo agile, mischia e implementare gamification, aderire alla kanban, ma tutto cade a parte la prima inadeguata, esigente, e ancora meglio lo stato del cliente che acquista un sacco di costosi e comincia a dettare le sue condizioni. In un mercato competitivo, è sciocco rinunciare ai soldi per il gusto delle metodologie. Un buon manager dovrebbe essere in grado di combinare la metodologia preferita degli sviluppatori con la necessità di fare brainstorming, applicare il modello a cascata su una superficie piana, assicurando al tempo stesso il coordinamento del team.
E poi il manager dovrebbe essere in grado di articolare, possiedono i mezzi di comunicazione e la collaborazione, per essere pronti a prendere il file dal server e per capire lo schema del progetto - per scopi fulminei, una comunicazione chiara ed inequivocabile (invece di inutili incontri di 5 ore).
Impara a motivare. È possibile trovare l'idea che una squadra forte e intelligente di ottima samomotiviruetsya e si organizza. No, non lo è. C'è sempre qualcuno che a) la motivazione su base continuativa e si interessa di avanzamento dei lavori; b) motiva i risultati del lavoro e comunica con la gestione (non sempre compreso, e non sempre dal programmatore); c) la motivazione in una situazione di crisi, per mantenere la squadra e la sostenibilità del progetto.
Il project manager è un motore che deve guidare l'intero sistema, garantire la coerenza di tutti gli elementi e massimizzare l'efficienza. Non dovrebbe essere uno Shiva o Janus bifronte, non dovrebbe essere una persona istruita - deve essere una persona competente che sa chi, quando, a quali condizioni e per quali soldi risolverà parte del problema. Se il manager vuole imparare UNIX o imparare la programmazione, è encomiabile e aiuterà il lavoro, aiuterà a capire le sfumature tecniche. Ma questo non dovrebbe essere fatto dal direttore dell'orchestra umana. Questo stato di cose dissiperà solo la professionalità, perché è meglio capire una cosa, ma è più fredda che in tutti i gradi C. L'aritmetica media sarà comunque di livello C. In generale, cari manager, non essere così pessimo, che non ti dà riposo - pensa con la testa e tutto si trasformerà come dovrebbe.
Nessun commento:
Posta un commento