ИТ фирми и пракси во Скопје

[Amaterasu]

На хартија би требало да е така како што викаш.
Работам во продуктна компанија која што има свој продукт и си има клиенти корпорации/фирми како и да е. практично b2b.
Е сега, во реалноста нештата функционираат вака - кај клиенот се пројавила потреба да се прикажува нешто на апликација филтрирано по лупам - азбучен ред.
И они го прелеваат тоа барање на PM/PO, овие пишуваат feature/enhancement за истото и после тоа што е напишано од ПМ/ПО се дискутира на ниво на тим. 99% од ова е прилично катастрофално и поминува многу лошо, секако, бидејќи ПМ/ПО нема поим како нештата функционираат технички или имаат доста површно знаење.
Убаво и идилично ова звучи демек ПМ/ПО прати трендови па иновира нешто, кога во најголемиот број од случаите, само го преведува барањето на клиентот/корисникот во jira или што и да е и тоа се дискутира на една сесија на која најголем инпут имаат пак - девелоперите и QAs.

ПО и ПМ ги ставам на исто рамниште како дечкото погоре што напиша за scrum master.
Тотално бенигна позиција.

Интересно ми е што самиот се некако демантираш со муабетот подолу, со кој тотално се согласувам. На исто рамниште ги ставам ПМ/ПО бидејќи на крај од ден се еден ист департмент, само scope-ot и временската рамка им е различна (едни се повеќе деталисти, другиве генералисти).

Ако видиш подетално, lead/senior/principal исто менаџира, дури и повеќе од овие класично менаџерски позиции.

Епа тука ни е разликата во сфаќањето на ПМ/ПО позициите.
Сум работел и јас нешто слично како тебе, b2b "продукт", имавме 5-6 клиенти и 99% од барањата ни доаѓаа од клиентите. И таму ПО не правеше ништо, само ги делегираше барањата. Уште ако беше некој од поголемите клиенти, директно на нас нивното барање ни го праќаше.
Ама еве, фирмава кај што работам е b2c. Имаме милиони корисници, не можеме нивните барања да ги имплементираме. Нашиот ПО е прво ветеран во нашата индустрија. Нема процес што не го разбира (не на техничко ниво, туку на доменско ниво). Цело време прати што прави нашата конкуреција. Оди по конференции, запознава луѓе и така веќе нашол неколку tools што ни помогнале да си ја подобриме услугата. Секогаш е тука да помогне ако ти треба некое знаење од индустријата. Врз основа на сето ова ни ја креира road-мапата. Ова е скроз различно од претходното искуство што сум го имал, слично како што викаш ти, ПО-то да е само прокси.

 

[LustingVertigo]

Пред година ипол работевме на DeFi продукт, имавме Scrum Master во тимот, се прашувавме сите devs во тимот што прави по цел ден и зошто се појавува само 10мин и после цел ден ништо не прави. По useless позиција немам досега затекнато.

 

[Aries89]

Мислење некој за Bestway Solutions?

 

[LustingVertigo]

Мислење некој за Bestway Solutions?

Today's subject: Slavery

 

[zmej gorjanin]

 

[arsars701]

Product Owner е човекот кој треба да одреди што треба да содржи продуктот. Ако продуктот е online продавница, да каже кои продукти треба да стојат најгоре, какви начини на плаќање треба да се имплементираат, какви попусти да имаш итн.

Тоа е sales.

 

[jamajka]

Работно место: Махараџа.

 

[Емкаа]

Не сте наишле на лош ПО за да видите која разлика е од добро поткован ПО кој го познава домејнот и пазарот, знае да приоритизира, и знае да каже не на стејлхолдерс.
И најдобар тим од сениори не може да деливира ако нема добар ПО.
Најстресни периоди на работа ми биле тие кога ПО-то беше на боловање, замената беше нова, не го познаваше домејнот, не знаеше да каже не, па бевме до гуша во лајна. Почни нов фичр, на пола прекини го, почни друго, па дошло нешо поприоритетно…одма се осеќа разлика во работната атмосфера.

 

[jamey jasta]

Не сте наишле на лош ПО за да видите која разлика е од добро поткован ПО кој го познава домејнот и пазарот, знае да приоритизира, и знае да каже не на стејлхолдерс.
И најдобар тим од сениори не може да деливира ако нема добар ПО.
Најстресни периоди на работа ми биле тие кога ПО-то беше на боловање, замената беше нова, не го познаваше домејнот, не знаеше да каже не, па бевме до гуша во лајна. Почни нов фичр, на пола прекини го, почни друго, па дошло нешо поприоритетно…одма се осеќа разлика во работната атмосфера.

Што знам, зависи...
Мора да има тимска приоретизација на старт од месец/квартал или како и да е внатрешната организација.
Секако, излегуваат и некои други проблеми у меѓувреме. Сепак и вие како тим од девс + тестери треба да сте спремни да кажете не, а не да го оставате целото "кажување не" на друг.
Ако така ноншалантно на вас како тим ви доаѓаat и ви убацуваat багови или ви мења приоритети среде спринт или квартал, ондак и вие не знаете да кажете не.
Мора да има етаблирани правила кога прекинуваме девелопмент среде спринт/квартал... y принцип мора тоа да е некој пресериозен баг или краш. Ако имате вакви сценарија често, мора да имате екстра простор во еден квартал за "недај боже".
Лупам - Не може да се прекинува голем фичр ако на клиентот му прднало дека наместо Cancel треба да стои Close на некое копче на UI.

Овие професии се изнедрени поради тоа што има премногу "тимови" кои што функционираат како "група на индивидуалци" или "група на фриленсери" + целиот сектор е нестабилен во поглед на кадар(вработени си идат, нови доаѓаат и тн). Позицииве се уште повеќе контроверзни во зрели екипи кои работат Х години заедно и се well oiled machine. Често пати во зрели тимови кај што тимскиот дух е навистина на високо ниво, овие ликови се само лево сметало, инсистираат да бидат повикани на повици, на кои се на mute цело време. И така им поминува денот веројатно.
За жал, од Х причини постојат премногу фирми каде што тимовите функционираат по принцип - "секој за себе, си имам ја свој таск, ми е гајле што колегата е заглавен до гуша", 0 тимски дух, 0 комуникација и затоа ИТ секторот после одредено време се соочи со претеран микроменаџмент и скроз бенигни позиции од типот "менаџер на менаџер на менаџерот".
Деливери-то/естимациите е сепак зависно од договор меѓу нас и тестерите, другиве(ПО/ПМ итн) само го пренесуваат кон стејкхолдерите - ок ви се естимациите или не ви се ок естимациите, фали ова фали она. Верувам дека често има доста пинг-понг играње од таа страна. Реалистично, со или без ПО, не можеме ние да естимираме 6 месеци за нешто што апла се гледа дека не е толку обемно, и vice versa.

Имаш 10 години ПО и 10 години девелопер во една фирма. Што мислиш, кој повеќе го знае домејнот ? Одговорот е кристално чист и јасен.

Зависно од состојбата во фирмата и тимот они се повеќе или помалце "леви сметала". Има луѓе овде што се уште повеќе радикални од мене и ќе речат дека се скроз непотребни.
Да не заборавиме дека и девелоперите се посебна сорта на луѓе (тежок табиет што би рекол Лестер).

Не џабе голем дел од луѓево се тепаат да бидат у менаџмент и такви позиции, според мене, не толку пошто е поголема платата, туку ради тоа што драстично помалку работат и не им паѓа коса пошто не се изложени на код секојдневно, него спамаат по четови и скакаат од едно на друго бесмислено состаноче.

Мојот став е дека нема логика било кој од овие да заработува повеќе или приближно исто со еден девелопер. Далеку од тоа дека се непотребни или бесмислени.

 

[Amaterasu]

Тоа е sales.

Sales продава, не ти кажува што треба да имаш во продуктот за да го продадеш

 

[Lester Freamon]

Што знам, зависи...
Мора да има тимска приоретизација на старт од месец/квартал или како и да е внатрешната организација.
Секако, излегуваат и некои други проблеми у меѓувреме. Сепак и вие како тим од девс + тестери треба да сте спремни да кажете не, а не да го оставате целото "кажување не" на друг.
Ако така ноншалантно на вас како тим ви доаѓаat и ви убацуваat багови или ви мења приоритети среде спринт или квартал, ондак и вие не знаете да кажете не.
Мора да има етаблирани правила кога прекинуваме девелопмент среде спринт/квартал... y принцип мора тоа да е некој пресериозен баг или краш. Ако имате вакви сценарија често, мора да имате екстра простор во еден квартал за "недај боже".
Лупам - Не може да се прекинува голем фичр ако на клиентот му прднало дека наместо Cancel треба да стои Close на некое копче на UI.

Овие професии се изнедрени поради тоа што има премногу "тимови" кои што функционираат како "група на индивидуалци" или "група на фриленсери" + целиот сектор е нестабилен во поглед на кадар(вработени си идат, нови доаѓаат и тн). Позицииве се уште повеќе контроверзни во зрели екипи кои работат Х години заедно и се well oiled machine. Често пати во зрели тимови кај што тимскиот дух е навистина на високо ниво, овие ликови се само лево сметало, инсистираат да бидат повикани на повици, на кои се на mute цело време. И така им поминува денот веројатно.
За жал, од Х причини постојат премногу фирми каде што тимовите функционираат по принцип - "секој за себе, си имам ја свој таск, ми е гајле што колегата е заглавен до гуша", 0 тимски дух, 0 комуникација и затоа ИТ секторот после одредено време се соочи со претеран микроменаџмент и скроз бенигни позиции од типот "менаџер на менаџер на менаџерот".
Деливери-то/естимациите е сепак зависно од договор меѓу нас и тестерите, другиве(ПО/ПМ итн) само го пренесуваат кон стејкхолдерите - ок ви се естимациите или не ви се ок естимациите, фали ова фали она. Верувам дека често има доста пинг-понг играње од таа страна. Реалистично, со или без ПО, не можеме ние да естимираме 6 месеци за нешто што апла се гледа дека не е толку обемно, и vice versa.

Имаш 10 години ПО и 10 години девелопер во една фирма. Што мислиш, кој повеќе го знае домејнот ? Одговорот е кристално чист и јасен.

Зависно од состојбата во фирмата и тимот они се повеќе или помалце "леви сметала". Има луѓе овде што се уште повеќе радикални од мене и ќе речат дека се скроз непотребни.
Да не заборавиме дека и девелоперите се посебна сорта на луѓе (тежок табиет што би рекол Лестер).

Не џабе голем дел од луѓево се тепаат да бидат у менаџмент и такви позиции, според мене, не толку пошто е поголема платата, туку ради тоа што драстично помалку работат и не им паѓа коса пошто не се изложени на код секојдневно, него спамаат по четови и скакаат од едно на друго бесмислено состаноче.

Мојот став е дека нема логика било кој од овие да заработува повеќе или приближно исто со еден девелопер. Далеку од тоа дека се непотребни или бесмислени.

Сите луѓе се тежок табиет, не само девелоперите, овие се само малку разгалени


Многу зависи и од самите клиенти, ПМ и ПО може да бидат и во апла незгодна ситуација ако имаш неразбран клиент. Имаме работено со неколку такви (да бидам искрен со повеќе такви, од нормални).

Пример кај еден од нив, на состанок доаѓаа 3-4 луѓе од кај клиентот и беа претставници на 3 сектори од таа фирма, кои требаше да добијат заеднички софтвер од нас со што ќе имаа чист систем за тикети, документирање на се што прават, интеграција со други постојни системи и тн. Меѓусекторски беа пепел, очи не сакаа да си видат, еден куп недефинирани работи и на состаноци ги слушаш како се натегаат по пола саат чија работа била и како да било во системот, сепак, добиваш инструкции и им кажуваш на твоите што да прават. Нареден состанок се слушаш само со дел од нив, ти викаат тури му пепел на тоа што правевме муабет вчера, седнавме во меѓувреме и нема да е така, туку тотално поинаку. Да ги отераш упм, никако, ќе си соберат парталите и ќе заминат, а не се фаќаат клиенти лесно. Да не ги отераш, пак никако, си го заебуваш расположението во тимот. Е во ваква ситуација, мора да ги отераш упм со фино, т.е да им пресметаш што е во цената, а што е по наша дефиниција change request (нормално ова мора да го направите апла нејасно и лабаво во иницијалната понуда/договор), и им барам да си добијат одобрување во нивните фирми дека ќе биде платено. Ако ми дадат на писмено дека им одобриле, ќе смени мојот тим по ново, ако не останува тоа што сме направиле. Е вака ја префрлаш топката на нивна страна, и треба тие да се заебаваат и правдаат со нивните за повеќе пари, што ретко кога сакаат, и често знаат да се договорат уште на состанокот дека и тековното е арно и ќе може да живеаат и без измена


Сепак зависи каква е фирмата, кај еден од клиентите едвај чекаат да не работат, и правеа дури и намерни опструкции на системот, ни сами не знаеме колку код искуцавме за QC и исклучоци кои не треба да им дозволи да ги внесат (utilities фирма, нешто налик АД во структура, еден куп од вработените нишаат врата и земаат плата, ако им го воведат системот ќе сфатат дека многумина се вишок, е со такви со среќа на ПМ/ПО, освен маани и негативности, не очекувај ништо друго).


Ако ве остават програмерите да се расправате директно со клиентот, ниту ќе завршите работа, ниту ќе останете на работа, е вака како змејот ќе ставате секој ден пораки како нема смисла тоа што го бара клиентот. Какви глупости имам видено со клиенти, може да напишам цела книга...а може и треба, се има кеш во тоа, само уште да бев добар писар

 

[Dani]

Ако ве остават програмерите да се расправате директно со клиентот, ниту ќе завршите работа, ниту ќе останете на работа, е вака како змејот ќе ставате секој ден пораки како нема смисла тоа што го бара клиентот.

Подобро сум се разбрал кога сум имал директна комуникација со клиентот, него ли преку ПМ кога оди комуникацијата.

 

[Lester Freamon]

Подобро сум се разбрал кога сум имал директна комуникација со клиентот, него ли преку ПМ кога оди комуникацијата.

Во таков случај поарно барајте да ви го тргнат тој ПМ. Не гледам зошто да се носи некој на грб, и да го кочи процесот, ако не си ја знае работата.


Инаку на муабетот:

 

[jamajka]

Во таков случај поарно барајте да ви го тргнат тој ПМ. Не гледам зошто да се носи некој на грб, и да го кочи процесот, ако не си ја знае работата.

Што пм може да се разбере околу бизнис побарувања. Тоа ти е бетер од расипан телефон. Си има аналисти за тоа. Идеално би имале девелоперско или QA искуство. Кога работев, претежно јас ги анализирав побарувањата. Пошто работевме за ентерпрајс клиент ги имавме истите проблеми со нивната координација и препукавање. Секогаш сум успевал да најдам заедничко решение… добро скоро секогаш. Само проблемот беше дека после тоа ме чекаше од архитектура преку лид, па и девелопнент, па се до бејбисит и оддржување.

Али ете тие скилови се покажаа клучни за следниот чекор… греота е да се пожалам.

 

[Lester Freamon]

Што пм може да се разбере околу бизнис побарувања. Тоа ти е бетер од расипан телефон. Си има аналисти за тоа. Идеално би имале девелоперско или QA искуство. Кога работев, претежно јас ги анализирав побарувањата. Пошто работевме за ентерпрајс клиент ги имавме истите проблеми со нивната координација и препукавање. Секогаш сум успевал да најдам заедничко решение… добро скоро секогаш. Само проблемот беше дека после тоа ме чекаше од архитектура преку лид, па и девелопнент, па се до бејбисит и оддржување.

Али ете тие скилови се покажаа клучни за следниот чекор… греота е да се пожалам.

Идеалното е да биде искусно техничко лице кое има преминато во менаџирање, и од таму доаѓа дека платата треба да биде висока со оглед на тоа што имаш некој кој знае како функционира техничкиот аспект, но има и вештини за преговарање и менаџирање. Сепак, не мора да значи дека нема да функционира поинаку, се додека има добра комуникација и поддршка од тим лидовите.

Доколку се работи со нови технологии и на нешто што е ново, често е подобро да имаш некој без програмерско искуство. Добро е да е техничко лице, но да ја нема бариерата во глава што е можно, а што не од поглед на програмирање (многу често границата е во главата, ако не ми фаќа главата мене, не значи дека нема да успее некој друг). Ваков, ќе го извади тимот од зона на комфор и може да ти донесат иновација.