Comments 23
>> (у меня не поднималась рука говорить что-то на эту тему человеку, который вчера ушел с работы в 11)
У вас гибкий график работает в одни ворота - т,е, уйти можно (разрешают - гибкий же график) в 23:00, но придти нужно в 9:00?
А вы именно в частном порядке решали не ругать за опоздание?
Ага. А потом думают, почему люди к нам работать не хотят идти)
Вообще, следуя вашей логике, для того чтобы не захотеть пойти к нам работать по этой причине, нужно узнать, что наш «гибкий» график работает «неправильно». Но пока не выйдешь к нам и не попробуешь - не узнаешь.
Так что вряд ли это является блокером, а если серьезно, то по сути я ответил в соседнем комментарии.
Привет!
В этот момент истории я был в другой компании, нежели сейчас, но не суть.
У нас был гибкий график, но с нюансом: если от тебя зависят другие члены команды (например, у нас дейлики в 10:30, и ты там нужен), то поздний приход надо согласовать с ними (в кейсе из статьи - со мной). Ну и вот ребята в зафиксированное время опаздывали, а я малодушничал и об этом с ними просто не говорил (хотя стоило поработать и над переработками тоже, но до меня это тогда не доходило как-то).
Сейчас с этим проще, в плане того что чтобы не опоздать на митинг достаточно одной минуты для входа в meet, но я все равно за несложную дисциплину: мне легче работать в команде, когда я в знаю когда нужный мне человек доступен, поэтому прошу ребят фиксировать время старта дня. Спросить совета, узнать информацию, сроки, обсудить реализацию: иногда перевод такой коммуникации в последовательный режим может сильно растягивать решение простых вопросов. Иногда нет: очень зависит от личной загрузки.
У нас был гибкий график, но с нюансом
То есть у вас не было гибкого графика. Потому что "согласовывать" можно в куче компаний. Но при этом они не заявляют что у них гибкий график.
Для кого как, видимо. Для меня если я не могу отклонится от дефолтного времени - это не гибко, как раз на первом месте у нас это контролилось по СКУДу и всем было пофиг на обстоятельства.
А если я могу прийти когда угодно, главное об этом сообщить коллегам - это гибко. Для некоторых ролей в некоторых командах у нас сейчас можно и не сообщать - это уж как они сами у себя настроят, вышестоящее руководство вмешиваться не будет в общем случае.
Но у всех своя рабочая среда, я допускаю, что для кого то это может считаться не гибким, не вижу тут ничего страшного.
А если я могу прийти когда угодно, главное об этом сообщить коллегам — это гибко.
Так "согласовать" это что означает у вас на фирме? Просто "сообщить коллегам"? Или всё-таки получить разрешение на это от коллег/тимлида?
Ну давайте подробно, если это принципиально.
В кейсе из статьи, в той компании где я на тот момент работал, формально обязательно было получить апрув от тимлида и менеджера и зафиксировать в почте с руководством. Де-факто это почти никак не контролировалось, только инцидентно (например менеджеру/кому-то понадобился разработчик, его не оказалось, менеджер/кто-то нажаловался - следуют разборки почему нет официального согласования; альтернатива - рп/кто-то обсудил это с тимлидом или разработчиком без эскалации - решили сами)
в текущей компании (AGIMA) много команд, везде может быть настроено по разному, в зависимости от решений самой команды.
Есть общий дефолт - работа с 10 до 19, чтобы все работали в одно время. Можно сместить начало работы как угодно, если это не принесет вреда команде, для этого достаточно договориться с командой.
Если у тебя роль с более широким потенциальным кругом коммуникаций (например, как у меня - ко мне может в теории обратиться любой из членов наших команд, hr, бухгалтерия, администрация и т.д. по какому-нибудь вопросу), то согласовать мне надо будет с моим руководством, уведомть об этом всех и настроить рабочее время в календаре. Если с этим будут возникать проблемы (я буду долго отсутствовать и за меня всегда придется решать вопросы кому-то другому), надо будет решить как это пофиксить (смещением графика, переносом части вопросов на кого-то, тюнингом процессов и т.д.)
Мои разработчики/любые члены команд могут договориться о гибком начале рабочего дня (без привязки к определенному времени), я об этом могу не знать (и мне это не надо).
Надеюсь, прояснил, если есть еще вопросы или уточнения - welcome.
В кейсе из статьи, в той компании где я на тот момент работал, формально обязательно было получить апрув от тимлида и менеджера и зафиксировать в почте с руководством.
То есть тимлид/менеджер могли и отказать? Тогда это не гибкий график. Как впрочем и все остальные описанные вами варианты.
Ок :)
Вообще есть вполне однозначные дефиниции:
1) График поменять нельзя, или практически нельзя — обычный нормированный рабочий день.
2) График поменять можно, для этого требуются определенные ручные действия, от согласований до составления расписания — плавающий график.
3) График поменять можно по велению своей левой пятки — график гибкий.
Есть довольно существенное количество компаний, которые формально заявляют №3, при этом их гибкий график выглядит примерно так: 7-7.5 часов будьте добры находиться на рабочем месте в строго определенные часы, а оставшиеся 0.5-1 часа — так уж и быть, можете отработать когда угодно. И ни в чём себе не отказывайте! Что, конечно, по факту не является гибким графиком, а обычным жонглированием терминами и попыткой манипуляции.
Всегда думал, что «плавающий график» это когда у тебя два через два (или вроде того, когда выходные плавающие), ну или когда график зависит не от меня (как работника), а его мне навязывает работодатель.
А когда я сам могу выбирать время прихода и ухода - «свободный».
А когда могу подвигать время влево-вправо - «гибкий».
Вроде в wiki ровно так (проверил только «гибкий» вариант): «Гибкое рабочее время (ГРВ) — форма организации рабочего времени, при которой в определённых пределах работник может самостоятельно определять часы работы в смену. ... В фиксированное время работник должен находиться на рабочем месте»
Но судя по откликам на хабре или у меня проблема с восприятием, или одно из двух. Покурю доки на досуге.
Покурил доки, все-таки вы ошибаетесь:
Гибкий график работы — "это режим труда, при котором сотрудник может определить самостоятельно начало и окончание рабочего дня по договоренности с работодателем" (пруфы: wiki, consultant.ru ст. 102 ТК РФ, kontur.ru, klerk.ru), левая пятка тут может участвовать только как аргумент для в процессе согласования с работодателем :)
Плавающий (на самом деле - скользящий) график — "...при котором выходные дни могут смещаться и выпадать на любые дни недели" или "... это предоставление выходных дней по меняющемуся графику (ст. 100 ТК РФ). То есть выходные в разные недели приходятся на разные дни" (пруфы: pro-personal.ru, kdelo.ru, kontur.ru), кажется больше подходит розничным магазинам или саппорт-отделам и т.д.
У нас в компании именно гибкий график работы.
Спасибо за ответ.
Я предложил бы рассмотреть вопрос несколько с другой стороны.
Вы описываете ситуацию и ее развитие сугубо с технической стороны: "начало дня", "календарь", "расписание", "дейли в 10:30", "ушли в 23:00" и тд.
И далее описываете, как обнаружив, что система не работает, сугубо техническими подстройками пытаетесь достичь условий, когда система все-таки будет работать.
Чего не хватает в "ИТ", так это общегуманитарного и естественнонаучного подхода/бекграунда, где все эти проблемы известны, как и их решения, и не нужно заново изобретать велосипеды.
Вот смотрите:
Вы договорились, что дейли у команды в 10:30.
Договорились, что если человек на нем нужен, но вынужден пропустить, то предупреждает/согласовывает это.
Теперь внимание: происходит ситуация, когда сотрудники вынуждены регулярно уходить в 23:00. Вы продолжаете считать, что они должны быть на месте в 10:30 (да, не сообщаете им об этом, но продолжаете так считать). В "обычном" мире это называется что-то вроде "существенным изменением условий, когда договор или его часть теряют силу" - а для вас это как будто уникальная ситуация. (Причем в вашем случае изменение условий столь сильно, что, в общем, недействительность договора даже не нужно как-то специальгно фиксировать/подтверждать - это происходит явочным порядком.)
Т.е., ситуация, которая у вас возникла, вовсе не уникальная. Если знать несколько больше, чем "аджайл", то вы будете знать и про класс таких проблем, и как предупреждать их появление, а если появились, то как их решать на принципиально ином уровне, нежели наущупь пытаясь подстроить технические параметры и тд.
Так что предложил бы посмотреть в этом направлении.
Мы с моими ребятами из команды часто сидели допоздна, пытаясь разгрести весь тот вал задач, который у нас копился, попутно стараясь гасить техдолг и пробовать новые подходы.
Стало очевидно, что надо что-то менять, иначе я рискую выжечь всю команду и себя в придачу.
Такие вещи нужно понимать уже на должности программиста. А тим-лид обязан это знать, потому что иначе он начинает требовать невозможного от своих подчиненных, а если и они неопытные и не могут тим-лида поставить на место - в их жизни начнутся проблемы со здоровьем и личной жизнью.
Меня всегда удивляло, почему, если человек с миллионом рублей зайдет в автосалон мерседеса, и скажет "хочу дорого и богато", его мягко, а может и не мягко отправят в автосалон ВАЗ.
А когда заказчик с небольшой командой (читай с маленьким бюджетом) хочет быстро и качественно (читай дорого и богато) - ему не говорят, что желания должны соответствовать возможностям, а если не соответствуют - нужно засовывать желания в одно место, а не напрягать окружающих невозможными задачами.
Здесь я постарался агрегировать самые эффективные (с точки зрения трудозатрат и выхлопа) приемы, которые сам применяю. Надеюсь, кому-то они покажутся интересными и помогут подтюнить найм в своей команде.
Давайте будем честны - самый эффективный способ повысить шансы и ускорить найм нужного кандидата - повышать ставку. Но если тим-лид не умеет себя ценить (а из статьи складывается именно такое впечатление), то разумеется, 90% кандидатов на рынке будут восприниматься как "ничего не умеют, а хотят зарплату больше, чем у меня".
И опытные руководители не только не требуют от своих подчиненных невозможного, но и повышают желаемую зарплату тем, кто себя не ценит. Потому что если бизнес сегодня получил одного гения с заниженной самооценкой, то завтра он будет хотеть именно таких еще десяток.
О том и речь, ровно так в моем опыте несколько лет назад и произошло: я требовал невозможного, люди горели и уходили. Собственно, это все и описано.
К сожалению, у меня тогда не было мудрого наставника который бы мне это подсветил недожидаясь негативного развития событий, поэтому пришлось пройти через такой вот опыт. Но по своему я за него тоже благодарен, в альтернативной мультивселенной я бы возможно не стал бы столько дотошным в этом вопросе.
А по поводу бюджетов и возможностей: мне кажется тут самый дьявол кроется в том, что технаря очень легко поймать на слове, на «слабо», на «небольшом» изменении требований и т.д. Как правило «бизнес» больше чем технари привык играть в игру «кто кого прожмет», и зачастую пользуется этим преимуществом чтобы получить согласие на желаемые сроки.
В результате, правда, проигрывают все (технари горят и переживают из за вынужденных костылей, бизнес вынужден корректировать сроки и уменьшать хотелки). Правда, частенько бизнес все равно будет считать это «победой», мотивируя тем, что если бы не так - то mvp вообще бы не выпустили.
Поэтому мне кажется очень важно чтобы среди бизнеса был человек который бы мог вникнуть во все что ему говорят технари и на основе этого самому придумать как быть, или среди технарей был человек который сможет выявить недосказанное и отстоять несдвигаемое.
Статья проваливается на теме. В мире нет ничего идеального: мудрость жизни в том, чтобы принимать от людей все лучшее и быть терпимым к худшему. Рассуждения об идеальном - это попытка не взять ответственность за ошибку или бездействие, но похвалить себя за стремление к лучшему... в других. Как будто люди думают об идеалах не перманентно, а по призыву из статьи. Вот и получается, что неидеальные ищут идеальных и, как придирчивые невесты, радуются, что сберегли место для "того самого".
Коллеги, вопрос ко всем. Что здесь и во многих статьях понимается под термином "разработчик"? Почему "PHP-разработчик", а не "PHP-программист"?
И, соответственно, что такое "разработка"?
В моем понимании вот уже четверть века разработка ПО - это длительный процесс от формирования требований до сдачи продукта в эксплуатацию. Соответственно и разработчики - это специалисты разных компетенций. А "PHP-разработчик" - это или неаккуратное выражение или вообще абсурд.
Смотря "разработчик" и "разработка" чего, зависит от контекста.
В вашем примере это разработчик систем, что, кстати, подтверждается и информацией в вашем профиле.
Когда же говорят "разработчик" применительно к программированию, то имеется в виду "разработчик ПО", еще точнее, "инженер-разработчик ПО".
Формально более правильно употреблять термин "инженер-программист", но, к сожалению, упомятутый вами термин программист несколько дискредитирован последние лет 20 (когда программистами кого только ни называли).
Кроме того, когда говорят "разработчик", имеет место и калька с английского Software Development Engineer - инженер по разработке ПО, что в обыденной речи редуцируется до "разработчика".
Как тимлиду найти идеального кандидата, и что делать с неидеальными