Примерна длъжностна характеристика и коментари по нея
Днес копирах от сайта на HR агенция една макетна длъжностна характеристика за длъжността “Java software engineer”. Ето как изглежда тя:
- Participate in the design and development of the company product
- Take part of the project planning and coordination with the other company teams
- Define and ensure adherence to architecture/design principles and best practices
- Ensure high quality of the development process
- Dedicate one’s self to defining the product features and vision
- Drive continuous improvement activities
- Maintain a close relationship with stakeholders and customers
- Analyze the competitors, research and innovate
- Contribute actively to open-source projects
- Mentor and/or provide guidance to programmers in the company products area
Доколкото преди няколко седмици бях хвърлил един поглед, мисля, че агенцията е откраднала тази ДХ от SAP, но не бих си заложил живота на това.
Ето коментарите ми по тази ДХ:
Participate in the design and development of the company product — Абсолютно да.
Take part of the project planning and coordination with the other company teams — Абсолютно не. Ако компанията не знае как да си планира производството на продукция, това не е мой проблем. Аз кандидатствам за разработчик, а не за плановик или мениджър. Но, ако това е един прекалено официален начин да се каже, че се очаква от мен да инициирам диалози с други екипи, за да разрешим технически проблем или неразбирателство, тогава нямам проблем с това, и ще го правя.
Define and ensure adherence to architecture/design principles and best practices — Тотално съм съгласен, естествено че ще се стремя да правя това. Аз искам да впрегна всичките си възможности, за да бъде продуктът качествен, за да използвам уменията си на максимум (което е приятно, но забележете, казвам “уменията на максимум”, а не казвам “енергията на максимум” — много различни неща са тези две изказвания), а също така и да се самоусъвършенствам в хода на тези процеси. А и в днешно време акцентът не е върху това колко технологии знаеш — акцентът е върху това можеш ли да научаваш новите технологии, да се адаптираш, и — при равни други условия — да го правиш бързо. Аз — да.
Ensure high quality of the development process — Имам нужда от пояснение. Аз ли ще контролирам процеса на разработка? Но аз не се кандидатирам за водач на екип или управител на проект. Не съм съгласен, ако това е случаят. Но ако се има предвид да не се мотая по порно сайтове или да приказвам по ICQ половината ден, може да се разчита на мен — когато имам работа и я харесвам, я върша добре и с удоволствие, и не се отклонявам системно.
Dedicate one’s self to defining the product features and vision — Никакъв шанс. Аз не съм този, който решава какво има във вашият продукт, дами и господа. Тази длъжност се нарича продуктов мениджър и е много далеч от програмирането.
Drive continuous improvement activities — Нямате никакви грижи! Но само да не стане така, че когато вкарам ново API за работа с XML, което ускорява с двуцифрено число процент работата на определени операции в продукта, после да получа кавга от мениджъра защо ползвам технология, която никой програмист в екипа не знае! Ако има кой да ме чуе, когато излъчвам нови идеи, този някой ще спечели. А и както съм казал в предишната си доста агресивна статия — мениджъри, не отрязвайте иновативните идеи на програмистите, защото най-много след втория случай ги губите като ефективни кадри.
Maintain a close relationship with stakeholders and customers — Това вече е абсурдно. Това се нарича “Customer Support”, а Stakeholders Management длъжността има такова неясно име, че никога не успях да го запомня. Никоя от тези двете няма никакво отношение към програмирането.
Analyze the competitors, research and innovate — Обожавам конкуренцията и с удоволствие бих правел тези неща, стига да не се очаква от мен да правя Reverse Engineering на конкурентни продукти. Повече или по-малко, това си е незаконно. Но извън това ми е приятно да видя къде нашият продукт е по-назад, да предприема стъпки да го подобря, после да проверя резултата, и накрая да се похваля, че вече сме по-конкурентни. Това е приятна, макар и тежка, дейност.
Contribute actively to open-source projects — Това ми е отдавнашна мечта. Ако работодателят ми я сбъдне, впоследствие ще трябва да злоупотреби сериозно с търпението ми, за да го напусна. Но, това ми съгласяване идва с условие — не искам да имам 5 успоредни задачи, като техните приоритети се менят по 2 пъти на ден. Мениджъри, водачи на екипи, продуктови мениджъри — разберете се кое е по-приоритетно от кое и ми дайте списъка. Оттам нататък поемам аз.
Mentor and/or provide guidance to programmers in the company products area — С удоволствие, стига обучаването на нови кадри да не ми стане главна заетост. Плюс, тук долавям двусмислие, т.е. може би се има друго предвид — че аз трябва да съм спец по това какво правят всички продукти на компанията и да обучавам клиенти или нови колеги на това как да свършим работата X с програмата Y. Не, това няма да стане. Това влиза в Customer Support и в писането на User Guides.
Post a comment