Acest set de declarații este destinat managerilor care trebuiau să se ocupe de noua lor afacere - să gestioneze un anumit proiect "de program" (crearea unui sistem informatic al unei întreprinderi, dezvoltarea unui site etc.).
Cu toate acestea, managerii de software pentru începători deseori nu cunosc cele mai simple lucruri - de exemplu, simplul fapt că nu se poate crede termenii numiți programatori. Regulamentele militare și regulile de circulație arată, de asemenea, simple, dar sunt "scrise în sânge".
De multe ori am văzut eșecul termenelor, eșecul proiectelor. Am văzut oameni de afaceri dispuși să investească bani în noi tehnologii, imaginație uimitoare - fără a înțelege piața, planurile de afaceri și chiar rezultatele aproximative și termenii de muncă. Eu însumi am făcut multe greșeli similare în 15 ani de activitate în industria software.
Acestea sunt cele mai simple lucruri și sunt colectate aici sub forma unui set de reguli. Iată primul dintre acestea:
Prima regulă este Ashmanov. Nu există probleme tehnice. Există doar oameni, adică organizaționali.
Nu acord aici consultanță tehnică privind managementul de proiect, regulile de planificare și documentare, testarea și procedurile de eliberare. Despre toți acești munți scrisi de literatură specială, inclusiv cartea clasică a lui Frederick Brooks "Omul-lună mitic".
Cu toate acestea, descrierile postului și procedurile corecte sunt departe de a fi toate. Când proiectul este lansat, managerul intră în primul rând în relațiile umane cu colegii, executorii, subordonații. Aceste relații sunt complexe, neobișnuite și pot fi adesea stumate dacă nu cunoașteți doar câteva reguli simple.
Despre managementul programatorilor
Eu personal respect și iubesc dezvoltatorii de software - programatori, dar în manipularea lor trebuie să fii atent și anumite reguli.
Gestionarea programatorilor nu este magică. Gestionarea proiectului software poate chiar și umaniste. Dar pentru aceasta este absolut necesar să poți gestiona oamenii și proiectele. Ca și în orice industrie, managerul trebuie să cunoască unele dintre caracteristicile procesului tehnologic și să nu cedeze "miturilor industriei". Tot restul depinde de capacitatea obișnuită a managerului de a-și face treaba.
Mituri. Gestionarea programatorilor are caracteristici complicate de mituri și iluzii în jurul programării. Aceste mituri sunt susținute cu ușurință de dezvoltatorii și vânzătorii de servicii informatice. Motivul principal al miturilor este contradicția dintre intelectualitatea evidentă și complexitatea muncii, pe de o parte, și caracteristicile complet normale ale personalului și ale proiectelor - pe de altă parte. Independența de mituri vine cu experiență și cunoștințe.
Mituri comune despre dezvoltarea de software
Mitul despre specificul unic al software-ului. Producția de software nu este o afacere specială, indiferent de ce spun ei înșiși dezvoltatorii sau vânzătorii de sisteme informatice. Nu este mai special decât industria alimentară sau cosmetologia. Legile de dezvoltare și de rambursare a proiectelor la dezvoltarea software-ului, a site-urilor de internet și a sistemelor de informații corporative sunt aceleași ca și oriunde în lume.
Prin urmare, vorbim despre unicitatea dezvoltatorilor de software, despre specificul de a gestiona un proiect de program, modalități speciale de a face afaceri sunt întotdeauna foarte suspecte.
Mitul măreției programatorului. Dezvoltatorul de software nu este un oracol, al cărui profețesc omul de afaceri ar trebui să asculte cu admirație. Într-adevăr, apariția oricărei, chiar programator mediu arata ca un adult, persoană inteligentă și responsabilă - el este foarte educat, implicat în activitatea mentală complexă, deține terminologia, se poate pune problema și justifică cererea de alocare a resurselor. În acest caz, de fapt, el apare întotdeauna ca un Învinși minore - nu spun povestea completă, calendarul este greșit proiecte, rupere, de cotitură de la calea cea dreaptă și să se distreze pe cheltuiala angajatorului.
Dacă dezvoltatorii vor juca prima fiddlă în proiect, probabilitatea unei colapsuri a proiectului este mare. Un semn sigur al acestei situații - atunci când un manager de nivel înalt, un non-programator, cu o incertitudine notabilă ne spune că totul merge bine și stadiul actual al proiectului este un important îmbunătățiri tehnice interne, care vor permite următoarele etape ale unui progres.
Trebuie să ne amintim că dezvoltatorul de software este un inginer, iar în domeniul tehnologiilor avansate, nu inginerii, ci oamenii de afaceri și managerii câștigă. Ca și în alte părți.
Mitul puterii magice a tehnologiei. O tehnologie nouă, complexă și impresionantă nu va duce neapărat la succes. Din fericire, astăzi nu mai este necesar să se dovedească în mod special nimănui. Orice tehnologie poate deveni un produs de succes sau poate duce pur și simplu la pierderea banilor investitorilor. Sursele succesului proiectului se află întotdeauna în afara sferei tehnologiei - în afaceri.
În plus, trebuie să ne amintim că o tehnologie cu adevărat unic sunt foarte rare, și foarte probabil în acest moment este exact tehnologia este deja discutate, dezvoltate sau vândute oriunde altundeva.
Reguli care sunt utile pentru manager
Regula 2. Jargonul tehnic nu înseamnă nimic.
Programatorii utilizează un jargon tehnic foarte dezvoltat, inclusiv la întâlniri și în memorandumuri. Se știe că orice lingo servește pentru a-și recunoaște propria persoană și a le confunda pe alții. Jargonul programatorilor nu este o excepție, iar gazda este adesea ostilă programatorului pentru programator.
Regula 3. Dezvoltatorii numesc întotdeauna timpul greșit.
Nu poți să crezi termenii pe care îi apelează programatorii. De obicei, acestea ar trebui să fie înmulțite cu Pi. Uneori (rar) - împărțiți pe Pi. Alegerea acțiunii corecte a managerului asupra termenilor numiți depinde de identitatea dezvoltatorului. Aceste cunoștințe ajung la manager doar după mai multe experimente cu acest dezvoltator.
Norma 4. Dezvoltatorii optimism inerent innate.
Un semn tipic al unui dezvoltator optimist neîntrerupt este încrederea în sine și ardorul, dorința de a merge și de a face, și nu așeza și planifica.
Regula 5. Programatorul are o pasiune pentru generalizare.
Programatorul încearcă întotdeauna cu toată puterea să facă lucrarea în modul cel mai general, apoi doar pentru a ajusta și adapta sistemul finit. Aceasta este esența programării și puterea ei.
Și în același timp - o amenințare gravă pentru afaceri. Dacă dai dezvoltatorului voința, dezvoltarea unei platforme comune va dura 100% din timp și bani, iar produsul nu va intra niciodată pe piață.
Echilibrul dintre generalizare și cerințele actuale ale pieței se realizează prin experiență și considerente de afaceri. Programatorii care au încredere aici absolut nu are nici un sens cât de lipsit de sens să discute cu bețivatul bugetul familiei.
Regula 6. Nu poți face "într-un mod bun".
Fiecare programator își justifică pasiunea pentru generalizare cu o dorință lăudabilă de a face totul într-un mod amiabil. În mod similar, administratorul de sistem cere întotdeauna bani pentru cel mai bun hardware și cel mai scump software de la Oracle. A face bine este teoretic greșită și aproape dăunătoare pentru afaceri. Este necesar să se facă astfel încât totul să funcționeze, clienții mulțumiți (exact la nivelul prețurilor produsului) și afacerea să se dezvolte.
Un semn sigur al stilului de muncă „pe cale amiabilă“ - munca grea cu „miezul“, întârzierea în punerea în aplicare a funcționalității specifice planificate și termenele ratate randament.
Norma 7. Grava ierbii poate dura orice timp.
Programatorul se străduiește mereu să-și satisfacă nevoia de armament - să echipeze la maxim locul de muncă, adică să creeze unelte, să instaleze cel mai recent software și cea mai avansată tehnologie. Dacă îi dai voința, el va cheltui 100% din timpul de lucru și va putea să-i dovedească superiorilor necesitatea unei astfel de activități.
Un semn sigur al unui astfel de aranjament permanent este computerele pe jumătate dezasamblate la locul de muncă și programe neobișnuite, non-standard pe aceste computere.
Dezvoltatorul nu aspiră, în medie, să organizeze și să dezvolte o afacere, de aceea nu-i place testarea, consideră utilizatorii drept idioți, deci este dificil să-l forțeze să documenteze și să susțină sistemele și programele deja făcute.
Este necesar să lucrați cu ceea ce este. Din ceea ce sa spus, rezultă că este practic imposibilă reeducarea dezvoltatorilor, a administratorilor de sistem și a managerilor tehnici medii într-un spirit de afaceri. Acest lucru nu este necesar. În loc de reeducare, este nevoie de o înțelegere a motivelor și obiceiurilor și a procedurilor de lucru pentru planificare, execuție și control, care păstrează libertatea de gândire și lasă loc creativității.
cerere
Învață să înțelegi programatorii. "Ei bine, nu știu, lucrez la mașină!" "Planificarea dezvoltării este lipsită de sens, viața este încă mai bogată!" "Nu vom fi gata până vineri, dar luni, sigur, sau marți!" - "Programul este bine documentat în C".
Pentru ca proiectul să reușească, este necesar să cunoaștem și să executăm o serie de reguli simple. Cu toate acestea, mulți manageri speră că o vor purta.
Proiectele potrivite și ceea ce aveți nevoie pentru acest lucru. Proiecte greșite și cum să le tratezi.
Urmăriți știrile noastre
Încercați din nou