Ce proiecte preferati? (referitor la bani si satisfactie tehnica)
Aplicatii mici/medii (3-6 luni) sau enterprise (1an+) ?
In cazul meu, proiecte mici medii, dar pe viitor, m-as baga pe unul de mai durata. La cele mici pe care am lucrat, am avut posibilitatea s fac eu research-ul de tehnologii ceea ce mi-a placut. 
In martie am preluat un proiect care trebuia sa fie gata la sf lunii, dar s-a intns pe inca 6 luni. Intarzieri si altele. de la celelalte parti implicate.
Am fost tentat să zic „termen scurt” dar îmi dau seama că majoritatea proiectelor la care am lucrat s-au întins pe cel puțin jumătate de an.
Mentenanța (bugfixing, adăugare de features) se include în proiect sau e ceva separat? În cazul în care se include, pot spune că am proiecte de 5+ ani 
1 Like
srict dezvoltare 
nu mentenanta (bug-fixes si adaugare de features mici si rare)
Ce proiecte am inceput in 2006 nici astazi nu au fost terminate. Doar proprietarii s-au schimbat.
Nu vad rostul sa-ti cauti la fiecare 6 luni alte proiecte decat daca stii 100% ca vei primi de munca. Plus ca la fiecare proiect dureaza o luna, doua pana te pui la curent cu ce se intampla acolo.
1 Like
Prefer mici/medii dar nu stiu cum mama naibii ca doar de de-alea mari am parte
Exceptie, bineinteles, cele pe care le fac open source, alea-s mici, sub 10000 loc.
1 Like
eu am observat ca la cele mici/medii banii sunt mai multi dar sunt pe stilul MVP (multe features intr-un termen scurt -> business in detrimentul implementarii tehnice cu gandire pe termen lung)
iar la cele enterprise se aloca mai mult timp dar mai putini bani (se gandesc foarte bine bazele platformei/aplicatiei d.p.d.v. tehnic si dupa este mult mai usor sa adaugi/extinzi cu features)
pe scurt, daca vrei bani mai multi: proiecte mici/medii
daca vrei mai multa experienta tehnica si sa vezi cum evolueaza o platforma/framework: proiecte enterprise
1 Like
Ce inseamna “bani multi”?
diferenta de 10-20 $ la ora
Termen lung unde sa ai control asupra deciziilor tehnice si posibilitatea de imbunatati proiectul pe parcurs. Vad o paralela aici cu gradinaritul, faci un plan initial dupa care peste 1-2 ani schimbi, mai refactorizezi, schimbi una alta, tot asa si codul e un organism viu care necesita atentie continua.
2 Likes
Prefer sa am 2 in paralel sau macar sa alternez, fiecare necesita alta abordare:
-
e mai greu sa lucrezi la un MVP/proiect mic pentru ca ai presiunea timpului si bugetului f mare, de multe ori mai trebuie sa mai si inveti rapid un framework, n utilitare, sau si un limbaj nou
-
la “enterprise” ai foarte mult de invatat pe partea de business, trebuie dupa aia sa intelegi tot proiectul, arhitectura, abordarile preferate ale echipei, cutumele cum s-ar zice plus echipa mare cu care trebuie sa interactionezi, DAR prin faptul ca ai constrangeri mai mici de timp si bani poti sa faci solutii mai elegante, optimizari mai multe, etc.
2 Likes
Acelasi lucru l-am observat si eu.
Sa zicem ca in 1000 de ore as avea de ales intre un proiect mare (pentru mine) si 40 de proiecte mici. Lucrand pe varianta cu proiecte mici, strict financiar si la prima vedere, ar iesi mai bine.
Dintre avantajele proiectelor mari ar fi satisfactia de a face ceva mai complex, ca are durata de viata mai mare si ca de obicei mai implica si mentenanta, care iti da un venit oarecum sigur o perioada de timp.
Totusi varianta cea mai buna mi se pare un mix intre cele doua. (cateodata mi se face dor de o noapte nedormita ca “maine trebuie sa inceapa” 
)
Depinde de banii cu care rămâi în mână, de echipă. Dacă nu ai echipă e greu în amândouă cazurile.
La proiecte mari ai CI/CD, code coverage minim, monorepo, design system, triburi/guild-uri, super standup-uri cu 20 de echipe, dependințe. Faci același lucru mult și bine. (Lucrezi pe un singur feature jumătate de an, abia după 2-3 luni înțelegi ce cum se leagă, poți lungi estimările in limitele bunului simț ca să nu faci crunching și de ai probleme cu ceva)
La un proiect mic atingi multe feature-uri, înțelegi rapid cum se leagă componentele. Dezavantajul major e ca o sa ai nevoie de crunching frecvent, iei mult în sprint să ai ce arătă la demo, e ușor să dai de un feature mai dificil de făcut decât ai estimat.
Ce să nu faci e sa nu accepți proiecte mici care sunt de fapt mari dar n-are buget clientul. O să iasă o mămăligă care rămâne fără buget și nu se poate vinde și tu o sa fii de vina.
1 Like
??? Mi-e frica sa intreb…dar totusi intreb: si devii asista la asa ceva? Mi-e usor sa critic dar sunt curios de context.
Da, un om din fiecare echipă trebuie să fie constient de ce se face în celelalte echipe în fiecare zi. Desigur se face cu rotație și durează 15-20 min.
As lua-o razna 
Ieri am avut un daily de 5 minute si am fost fericit ca in acele 5 minute s-a zis tot ce este nevoie.
2 Likes