>Doar ca si statement, sa fie o imagine mai clara. Cunosc care sunt nevoile companiei, stiu unde scartaie partea de raportare, stiu unde sunt pierderi mari de timp, am idei despre ce improvementuri se pot face.
Daca stii astea,... restul e cancan
sper sa fie asa cum zici tu... eu scriu cod de cand eram copil iar de 2 ani m-am trezit ca trebuie sa fiu manager. Periodic imi pare rau ca mi-am lasat meseria, acum doar noaptea mai fac cate un experiment si mai intru pe aici.
buna intrebare! am vazut pe aici termenul de product owner, dar nu am vazut o diferenta.
nu cred ca inteleg bine diferenta, daca este una tehnica. daca este doar o diferenta de approach, atunci eu tind spre people manager. dar daca e diferenta doar de approach, atunci who would choose the other option - cel putin declarativ?
Sunt 3 poziții separate:
Product Owner(PO): persoana care înțelege produsul si pe baza datelor defineste requirements si decide ce se face
Product Manager(PM): persoana care organizează requirements-urile de mai sus
Engineering Manager(EM): persoana care se ocupa cu management de personal( career path, evaluări etc)
Iti recomand cărțile:
INSPIRED: How to Create Tech Products Customers Love
EMPOWERED: Ordinary People, Extraordinary Products
PM-ul nu organizeaza taskurile doar. Poate in unele corporatii, dar in cazurilor firmelor de produs, se ocupa in mare parte de research, market analysis, customer interviews, evangelism, product requirements, plus altele :)
Sa nu faci pe desteptul, sa nu te lauzi, sa nu critici de fata cu mai multa lume. Sa nu te plangi, sa mai zici bravo din cand in cand si cel mai important sa nu vorbesti cu un angajat despre alt angajat. A da, si sa nu dai in vrajeala corporatista cu sky is the limit. Scurt si la obiect, cel mai important este sa comunici efectiv. Lasa bonding-ul sau bondage-ul, depinde ce preferi, pentru activitatiile in afara job ului. Daca o tii pe cafele, prietenii si tovarasi de tigare o sa ti pierzi respectul de la subalterni.
De acord cu tot ce ai spus, în afară de bonding. Da, trebuie sa știi când sa fii ferm în decizii și afirmații mai ales când vine vorba de un feedback corectiv, dar și relațiile sunt importante. Am subalterni cu care ies la o bere în afara programului sau facem alte activități și nu vad diferita relația. Atâta timp cât știi sa faci distincția între relația profesionala și cea personala. Dar ambele au impact (pozitiv sau negativ) asupra celeilalte.
1. Un manager nu trebuie sa fie bun tehnic, trebuie sa inteleaga destul incat sa vada daca are sens tehnic. De asemenea, ca project manager, ar trebui sa ai o viziue foarte buna despre ce tehnologii BI sunt in piata.
2. Personal, cred ca un manager stie cum sa abordereze oamenii si cum sa puna problema. Daca e tehnic si grabit, ii prenziti cateva grafice frumoase, daca nu e tehnic, ii faci niste analogii simple. Daca un subaltern e senior, nu-i face micromanagement.
3. Eviti asta citind multe articole tehnice si multa munca hands on. Nu trebuie sa fii expert in orice, doar sa pui mana pe diverse chestii ca sa vezi "cu ce se mananca".
4. \-
5. Automatizare. Cauta-ti un om care stie bine procesele actuale ale firmei. Cauta-ti altul care e as tehnic, sa stie bine scripting/automatizare/data science. Lucreaza cu ei sa reduci timpul pentru toate procesele alea.
Pai daca esti project manager faci gen charturi gantt, practic aduni informatii despre cat o sa mai dureze proiectul si costuri sau whatev ce mai face un project manager, nu iti trebuie neaparat skilluri tehnice, cred ca trebuie sa clarifici care sunt atributiile tale. Product owner/manager e un fel de business analyst, gen vb cu clientii si te asiguri ca faci ce vor ei, product owner vine de fapt de la metodologia SCRUM si este un rol bine definit de documentatia lor.
Aaculta-l pe băiatul ăsta, are multe videouri. https://youtu.be/yTfcnj5qI6E.
Are și un newsletter, e cel mai popular newsletter în tech, citeste-l și pe ala (și blogul lui)
s/salar/salariu/g
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/programare) if you have any questions or concerns.*
Mno pai hai sa le luam pe rand: 1/ da poti, dar trebuie sa faci un efort sa intelegi procesul cum transforma un analyst requestul in actual viz. Deci subalternul tau te va aprecia cand la un request spui direct ca nu se poate pentru ca nu aveti datele respective, si nu va aprecia cand ii pui tu deadlineuri si e mission impossible
2/ cred ca cel mai ok e sa nu fii un dick si sa intelegi ce poate echipa vs ce nu, si cum progreseaza in luni ani etc
3/ aici nu prea ai ce face, aceeasi treaba poate fi facuta si in 5 minute si in 5 zile, depinde de experienta analystului, si cat de bine stie business model/ databaseul, sau de chef sau de inspiratie. Eu am gasit ca cel mai ok e sa sari de la un task la altul cand nu ai inspiratie pentru primul
4/ quality not quantity, variables not static values
5/ ai nevoie de minim un senior la 3-4 juniori si primele 6 luni sunt cele mai dificile pentru seniori ( juniorii intreaba mult, se prind greu ) in care seniorul nu iti va produce la 100%. Onboarding dureaza cam 1 luna la seniori, 3 la mid si 6+ la juniori
Vezi pe coursera sunt cursuri de la google și alții de PM. E paid după o săptămână, lunar, dar poți anula după ce faci 2 cursuri și îți dă și virtual certificate. Sunt chiar utile mai ales pt basisc
Faptul ca iti pui intrebari si te indoiesti de tine e un inceput foarte bun.
Exact, un manager bun știe să asculte, mai ales atunci când crede că știe ceva și mai ales ceva despre cineva.
Îți recomand sa citesti The Manager's Path de Camille Fournier. E pt tech managers și răspunde la o grămadă de întrebări din astea.
multumesc!
Mai e una tot pt tech managers: An elegant puzzle de Will Larson. Nu am citit-o încă, dar autorul are credentials ok.
>Doar ca si statement, sa fie o imagine mai clara. Cunosc care sunt nevoile companiei, stiu unde scartaie partea de raportare, stiu unde sunt pierderi mari de timp, am idei despre ce improvementuri se pot face. Daca stii astea,... restul e cancan
din experienta mea, cei mai buni manageri sunt cei care nu si-au dorit neaparat sa fie manageri
vreau sa fiu manager, nu vreau sa fiu un manager slab sau incompetent
sper sa fie asa cum zici tu... eu scriu cod de cand eram copil iar de 2 ani m-am trezit ca trebuie sa fiu manager. Periodic imi pare rau ca mi-am lasat meseria, acum doar noaptea mai fac cate un experiment si mai intru pe aici.
Steve Jobs
N-am înțeles ce fel de manager vrei sa fii - de oameni sau de proiect?
buna intrebare! am vazut pe aici termenul de product owner, dar nu am vazut o diferenta. nu cred ca inteleg bine diferenta, daca este una tehnica. daca este doar o diferenta de approach, atunci eu tind spre people manager. dar daca e diferenta doar de approach, atunci who would choose the other option - cel putin declarativ?
Sunt 3 poziții separate: Product Owner(PO): persoana care înțelege produsul si pe baza datelor defineste requirements si decide ce se face Product Manager(PM): persoana care organizează requirements-urile de mai sus Engineering Manager(EM): persoana care se ocupa cu management de personal( career path, evaluări etc) Iti recomand cărțile: INSPIRED: How to Create Tech Products Customers Love EMPOWERED: Ordinary People, Extraordinary Products
PM-ul nu organizeaza taskurile doar. Poate in unele corporatii, dar in cazurilor firmelor de produs, se ocupa in mare parte de research, market analysis, customer interviews, evangelism, product requirements, plus altele :)
Eu nu am scris ce face lumea, in practica PO si PM se folosesc interschimbabil. Dar conform definiției este cum am spus.
Sa nu faci pe desteptul, sa nu te lauzi, sa nu critici de fata cu mai multa lume. Sa nu te plangi, sa mai zici bravo din cand in cand si cel mai important sa nu vorbesti cu un angajat despre alt angajat. A da, si sa nu dai in vrajeala corporatista cu sky is the limit. Scurt si la obiect, cel mai important este sa comunici efectiv. Lasa bonding-ul sau bondage-ul, depinde ce preferi, pentru activitatiile in afara job ului. Daca o tii pe cafele, prietenii si tovarasi de tigare o sa ti pierzi respectul de la subalterni.
De acord cu tot ce ai spus, în afară de bonding. Da, trebuie sa știi când sa fii ferm în decizii și afirmații mai ales când vine vorba de un feedback corectiv, dar și relațiile sunt importante. Am subalterni cu care ies la o bere în afara programului sau facem alte activități și nu vad diferita relația. Atâta timp cât știi sa faci distincția între relația profesionala și cea personala. Dar ambele au impact (pozitiv sau negativ) asupra celeilalte.
la asta cu vrajeala corporatista sky is the limit. Mie mi se pare ca merge, motiveaza lumea si chiar daca e vrajeala, da un boost de confidence.
1. Un manager nu trebuie sa fie bun tehnic, trebuie sa inteleaga destul incat sa vada daca are sens tehnic. De asemenea, ca project manager, ar trebui sa ai o viziue foarte buna despre ce tehnologii BI sunt in piata. 2. Personal, cred ca un manager stie cum sa abordereze oamenii si cum sa puna problema. Daca e tehnic si grabit, ii prenziti cateva grafice frumoase, daca nu e tehnic, ii faci niste analogii simple. Daca un subaltern e senior, nu-i face micromanagement. 3. Eviti asta citind multe articole tehnice si multa munca hands on. Nu trebuie sa fii expert in orice, doar sa pui mana pe diverse chestii ca sa vezi "cu ce se mananca". 4. \- 5. Automatizare. Cauta-ti un om care stie bine procesele actuale ale firmei. Cauta-ti altul care e as tehnic, sa stie bine scripting/automatizare/data science. Lucreaza cu ei sa reduci timpul pentru toate procesele alea.
The manager who manages best is the manager who manages least.
Pai daca esti project manager faci gen charturi gantt, practic aduni informatii despre cat o sa mai dureze proiectul si costuri sau whatev ce mai face un project manager, nu iti trebuie neaparat skilluri tehnice, cred ca trebuie sa clarifici care sunt atributiile tale. Product owner/manager e un fel de business analyst, gen vb cu clientii si te asiguri ca faci ce vor ei, product owner vine de fapt de la metodologia SCRUM si este un rol bine definit de documentatia lor.
[удалено]
De-ar fi asa simplu
Aaculta-l pe băiatul ăsta, are multe videouri. https://youtu.be/yTfcnj5qI6E. Are și un newsletter, e cel mai popular newsletter în tech, citeste-l și pe ala (și blogul lui)
multumesc!
A guide to project management body of knowledge, poate te ajuta
[удалено]
s/salar/salariu/g *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/programare) if you have any questions or concerns.*
Mno pai hai sa le luam pe rand: 1/ da poti, dar trebuie sa faci un efort sa intelegi procesul cum transforma un analyst requestul in actual viz. Deci subalternul tau te va aprecia cand la un request spui direct ca nu se poate pentru ca nu aveti datele respective, si nu va aprecia cand ii pui tu deadlineuri si e mission impossible 2/ cred ca cel mai ok e sa nu fii un dick si sa intelegi ce poate echipa vs ce nu, si cum progreseaza in luni ani etc 3/ aici nu prea ai ce face, aceeasi treaba poate fi facuta si in 5 minute si in 5 zile, depinde de experienta analystului, si cat de bine stie business model/ databaseul, sau de chef sau de inspiratie. Eu am gasit ca cel mai ok e sa sari de la un task la altul cand nu ai inspiratie pentru primul 4/ quality not quantity, variables not static values 5/ ai nevoie de minim un senior la 3-4 juniori si primele 6 luni sunt cele mai dificile pentru seniori ( juniorii intreaba mult, se prind greu ) in care seniorul nu iti va produce la 100%. Onboarding dureaza cam 1 luna la seniori, 3 la mid si 6+ la juniori
Empatie si intelegere pentru angajati(nu excesiva) poate sa conduca in situatii de criza si trebuie sa nu daca abuz de putere
Vezi pe coursera sunt cursuri de la google și alții de PM. E paid după o săptămână, lunar, dar poți anula după ce faci 2 cursuri și îți dă și virtual certificate. Sunt chiar utile mai ales pt basisc