“За” и “против” дистанционната работа

Posted on July 12th, 2008 in Uncategorized by admin

Опитвах се да разсъждавам по темата “За и против отдалечена работа от вкъщи/кафенето/масажния салон”. Сега ще опитам да дам аргументи “за” и “против”. Имайте предвид — не съм нито специалист ТРЗ, нито счетоводител, нито работодател. Опитвам се да дам разсъждения на базата на студена логика и някакво количество практически опит. Искайте пояснения, ако не съм се изразил добре. Уточнявам: аз съм програмист и целя разсъжденията си най-вече към кадри, които имат същата професия.

Защо бих гласувал “против”, ако самият аз бях работодател:

  1. Синдромът на тълпата. Ако аз днес разреша на един човек да работи отдалечено за мен, на ненормирано работно време и гъвкаво заплащане (т.е. за свършена задача или за сума на час/ден), това значи, че все някой от фирмата ще научи. Това неминуемо ще доведе до две неща: първо, хората ще недоволстват защо и те не работят на тази “по-свободна система”, и второ, някои от по-старшите кадри директно ще поискат да работят по този начин. Така че проблемът е този — няколко души, на които съм преценил, че мога да се доверя (или те не приемат работа на пълно работно време, а аз имам нужда от опита им), ще работят така, но останалите, за които преценям, че няма да работят ефикасно по този начин, остават недоволни. Това разваля стабилността на фирмата ми. Никой не иска високо текучество на персонала.
  2. Гъвкавост. Аз съм убеден, че когато разполагам с кадрите си по осем часа на ден, винаги мога да сменя нарежданията си към тях, ако приоритетите на фирмата се променят динамично. По този начин пренасочването на енергия към важните за мен дела става много бързо. От друга страна, хората на свободна практика биват наемани за конкретна задача. Развалянето на договор рядко е вариант, защото би могло да донесе лоша репутация на фирмата ми, а ако не мога да разваля договора, това означава да плащам за труда на този човек, докато той/тя приключи, което в крайна сметка може да се окаже напразен разход.
  3. Ефективност. Хората не работят ефикасно, когато са в офиса. Склонни са да се разсейват с телевизия, интернет, компютърни игри, чат, форуми, новини и т.н. Осем часа вкъщи никога не са равни на осем часа в офиса.
  4. Усложняване на документалната работа. Ако имам 50 души персонал и всички са на безсрочен трудов договор, то тогава ТРЗ работата, която моите счетоводители имат да вършат, е много, но е монотонна — редовно начисляване на заплати със съответното отчисляване на данъци и осигуровки. Ако имам 10 души на свободна практика, това означава или граждански договор, или устна уговорка (второто води до “черна каса”, каквато аз не искам да имам). Гражданските договори се гледат под лупа от данъчни инспектори, макар че аз не зная защо. Шансът нещо да се обърка в документалната работа на фирмата се увеличава, а при някоя грешка аз мога да отнеса глоба само заради факта, че не работя с някого на трудов договор. От моя гледна точка аз не съм “злият работодател” — аз минимизирам риска за фирмата си.

Всичко това неминуемо ме води до извода, че да имам персонал на трудов договор е най-добрият вариант за мен, който ми дава едновременно гъвкавост и сигурност.

В качеството си на служител аз не смятам, че е изключено да се работи на пълно работно време. Ето защо:

  1. За програмиста може да не е възможно да отсъства по девет-десет часа на ден от вкъщи. Има хора, които трябва да се грижат за болни стари хора, има и хора, които не са добре със собственото си здраве. Има и хора, които могат да понасят само ограничено количество стрес на работа. Смятам, че от гледна точка на мениджърите, съобразяването с тези характеристики не означава да придадем на някой кадър по-голяма важност, отколкото на другите, а по-скоро да оптимизираме употребата на кадрите си. Да извлечем максималното, което е възможно, от текущия си човешки ресурс.
  2. Тези програмисти могат да притежават дялове от други компании. Запознат съм, че в трудовите договори на някои фирми това е изрично забранено, което съответно блокира сделка във формат “пълен работен ден”.
  3. Програмистът може да е по-тесен специалист в област, която при вас не би могла да заеме 100% от работното му време. Логично, това би довело до работа от класа “непълен работен ден” (която вместо това би могла да бъде и три от пет работни дни на седмица, също).
  4. Програмистът може да има още много други причини да не иска да работи по 40 часа на седмица, вкл. и такива, които не е длъжен да съобщава на интервюиращия го, защото могат да са от по-личен характер. Важният въпрос е защо това е пречка за трудови взаимоотношения.
  5. И накрая, но не и на последно място — нищо от горе-изброените причини всъщност не означава, че този човек не ви трябва. Той може да е много добър, но просто да не съвпада на 100% с вашите условия за времева заетост.

В качеството си на служител аз гласувам “за” дистанционна работа, защото:

  1. Личният ми служебен служебен опит изключва да давам твърде често отчет за свършената си работа. Ако имам ясна задача, мога да работя по нея цял месец, без да съобщавам никому детайлите, и въпреки това да доставям уговореният резултат с уговореното качество. Правил съм го успешно неведнъж. Ако искате, напълнете ме с критични коментари, но все пак ще си позволя да кажа, че това е мнение на МНОГО програмисти, мнение, многократно съобщавано по маси в пицарии. От моите наблюдения бих отсъдил, че това важи за повечето програмисти изобщо.
  2. Защо за мен е изключено да давам твърде често отчет за свършената си работа? Най-вече защото не съм забелязвал никъде, където съм работил на трудов договор или на свободна практика, планирането да е на добро ниво. Съставя се списък с желани възможности на крайния продукт, които безброй пъти се коригират в движение, впоследствие се уточняват и разбиват на технически задачи (понякога след този етап също има изменения на списъка възможности на продукта), след това се изпълняват или наведнъж, или итеративно. И това е направо идеалният вариант — обикновено всичко е просто пълен хаос, където постоянно пристигат клиентски желания, няма кой да дава приоритети на задачите, няма кой да контролира качеството, и т.н. Сами разбирате, че за мен всъщност никак не е трудно да давам отчет за работата си на редовни и чести интервали. Просто не виждам какво имам да докладвам при постоянно променящи се условия. “Свърших си работата от точка 7 до точка 11 тази седмица”. Това ли? Няма проблем. Стига срещите да не отнемат по час и половина, защото тогава мениджърът остава с впечатлението, че не съм свършил работата си за деня. Което е логично, имайки предвид, че съм имал време за работа с час и половина по-малко.
  3. Заради една много неформална причина — уважението. Ако един работодател се съгласи да работим заедно по тази система, това автоматично значи, че този човек уважава труда ми. Той (тя) е съгласен(на), че количеството време не гарантира нито количество, нито качество на продукта, и осъзнава това, предлагайки ми условия, в които аз мога да работя необезпокояван и фокусиран върху работата си. Този човек заслужава и моето уважение също, защото за него или нея евентуалните документални усложнения (или по-високото заплащане в сравнение с работа на пълен работен ден) не са приоритетният проблем. Този човек явно е заинтересуван от качеството на това, което неговата фирма ще предложи. Този човек ще има клиенти, и тези клиенти ще са доволни, и ще се задържат като клиенти на фирмата му/й. За мен този работодател е стабилен и аз ще го предпочета дори за 10-20% по-ниска заплата в сравнение с други предложения.

Защо бих гласувал “за”, ако самият аз бях работодател:

  1. Лошо качество на съвременните ИТ кадри. Искате ли да погледнете тази статия? — [Какъв искам да стана като порасна голям]. Да не мислите, че само децата смятат, че трябва да станат програмисти, защото те взимали много и не правели нищо? Нищо подобно. Чувал съм десетки пъти, случайно подминавайки разни кафененца, следното — “ай бе копеле, дай станем ини пруграмисти, тея зимат ебати яките пари, а по цял ден само си лафят с мацки”. Ако аз съм работодател, бих осъзнал реалността на българския ИТ сектор към днешна дата — ТРАГИЧНА. Всякакви кретенки и кретени инвестират в кариерата си с два костюма, чаровна усмивка и добро бюстие (за момичетата) или сериозна физиономия и имитиране на внимателно слушане (за момчетата) и… хайде да ставаме програмисти. Дават им се задачи, с които те нямат и най-малката представа как да се справят, но понеже са учили C++ или Java (или C#, PHP, ASP .NET и така нататък) един семестър в университета, се смята, че всичко е окей. Много неприятната за работадателите истина в момента е, че добри програмисти ИМА, но не стигат за нуждите на бранша.
  2. Проява на уважение с цел задържане на персонала и намаляване на текучеството. Тъй като всички работим с ХОРА, трябва да мислим за човешките им нужди. Когато имате насреща си самоуверен и опитен специалист, това е човек, който не се интересува дали вашата HR мадама му се усмихва чаровно или го уверява колко е велика фирмата ви. Такъв човек се интересува от условията. Предложете му по-свободна система на работа и сте го спечелили наполовина. Защо? Това е проява на уважение, признание, че той е специалист. Забравете факта, че може от предишните му работодатели да сте чули нещо лошо за него. Работните условия са доста относителни спрямо конкретната фирма (да не забравяме и такива безкрайно субективни елементи като атмосфера между колегите и отношенията с мениджърския състав), и като всяко толкова относително и субективно нещо е разумно да се третират с добра доза резервираност, когато се включват в преценката ви. Плюс това, опитайте този съвет — първо вие дайте доверие, после поискайте нещо в замяна. Повечето български работодатели правят обратното. Не приемайте от самото начало, че той или тя е дошъл на работа, за да ви прекара!
  3. Искам да имам доверени хора. Това е свързано с предишната точка. Хората с повече опит не страдат от прекалена лоялност — това впрочем е причината много работодатели да предпочитат студентите и въобще по-младите кадри — лесно биват шашкани и много по-лесно контролирани. Опитните хора изобщо не ги интересува историята на фирмата ви, ако ще да датира от 12-ти век или да е започната от извънземните (това е една също грамадна грешка при интервюта на опитни хора — на тях им е БЕЗУМНО досадно да слушат фирмена история). Тези хора са практични — искат да чуят работните условия — заплата, работно време, отпуски, евентуално “социални придобивки” (за мен съчетанието “безплатни стоки/услуги” е по-правилно) и т.н. Така че логичният извод за доста хора би бил този — не искам твърде опитни хора, защото те са лоялни на този, който дава най-хубавите условия и пари. Това е заплаха за текучеството на фирмата ми, да не говорим за бъдещето на някой сериозен проект, който моята фирма разработва. Грешите! Ако мотивирате един добър специалист с предложение за дистанционна работа, вие (отново) показвате уважение — нещо, което е много напред в списъка ценности на опитния специалист. Ето ТАКА той ще ви бъде лоялен, всъщност.

Не претендирам за завършеност на тезата си, но пък и статията стана прекалено дълга.

Много съм любопитен за вашето мнение.

За “вредата” от блоговете

Posted on July 12th, 2008 in Uncategorized by admin

Преди време бях чел в Tech News разни плашещи неща за блоговете и всички форми на социален интернет — например, че ако шефът ти разбере какви глупости плещиш в блога си, или ако имаш някоя “неморална” снимка във Facebook, едва ли не ще те уволни (или няма да те вземе на работа, ако сега кандидатстваш). Защо? На работа можеш да се държиш професионално, но личното ти изразяване е част от твоя ЛИЧЕН живот. Шефът ми е мой шеф само в рамките на работното ми място, той или тя не е шеф на целия ми живот.

[ Лична информация в Интернет може да съсипе кариерата ]

Кофти номер. Лично за мен това е висша степен на нахалство. Хората живеем живот, в който сме в различни роли и контексти във всеки отделен момент. Когато ходим да пазаруваме, сме недоволни клиенти.  Когато сме на работа, обикновено ние сме обслужващите и трябва да мислим за нуждите на клиентите. Когато ръководим хора, мислим по един начин. Когато ние сме ръководените, мислим по друг. Същото важи и за нашето изразяване.

  • Ако в извънработно време пийна повечко и имам затруднения с ходенето по права линия, това не значи, че съм лош кадър в рамките на работното си време.
  • Не съм расист, но това не ме прави добър кадър.
  • Ако не съм християнин, това не ме прави некадърник в работата.
  • Ако редовно си изхвърлям боклука и чистя тоалетната на котките си, това също не ме прави по-кадърен на работното ми място.
  • Ако някой приятел ме е снимал да танцувам на пилон в дискотека, това не значи, че няма да изкарам няколко десетки хиляди евро за фирмата, в която работя.

Моето отношение винаги е било доста грубо и цинично към хора, чиято преценка намирам повърхностна. Сега няма да бъде изключение: смятам, че хората, приложили такива критерии в преценката си дали да се вземе на работа (или уволни вече работещ) определен човек на база на факти от личния му живот, са смешни и жалки, а още по-смешни и жалки са интелектите им.

Една минута мълчание за смъртта на здравия разум!

Примерна длъжностна характеристика и коментари по нея

Posted on July 12th, 2008 in Uncategorized by admin

Днес копирах от сайта на 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.