Отвечу за Вики по поводу тегов: у нас в компании нет хорошо настроенной практики работы с тегами в wiki.
Мы используем Confluence, а отсюда вытекает, что теги сотрудники могут ставить какие им захочется. И казалось бы это очевидная проблема, ожидается хаос и многообразие тегов, но нет: их вообще никто не ставит :)
У нас есть теги, которые мы используем для обозначения принадлежности регламента/раздела/статьи к системе ("outsource-CRM") или роли ("helpfull-for-PM"), но где-то они есть, где то нет. Так что теги - это большая точка роста для нас.
Пока самое полезное из тегов, что у нас есть (как я считаю), это метка/тег "актуализировать", по которой можно посмотреть и запланировать в работу исправления.
Согласен, что тема с защитой данных важна, для этого нужен хороший DLP. Он же может применяться и в связке с wiki (на уровне распределения доступов, например) - но это прямо совсем другая история, в этой статье все-таки про наш опыт структурирования знаний. Могу сказать только, что сейчас учетки ко всем системам у нас управляется из единой точки, а условно-секретные документы/разделы в wiki по умолчанию закрыты и доступ выдается вручную.
По поводу несоответствий регламентов и реальных процессов - у нас как то принято писать комментарием к статье или ее части, что "тут не актуально, поправьте пожалуйста" и мы правим :) Статьи устаревают и их надо периодически ревьювить, иногда мы просто ставим тег "актуализировать" (например времени прямщас поправить статью нет, а упускать не хочется) и по нему потом отсматриваем, что устарело: назначаем задачи сотруднкам или себе актуализировать такие вещи.
Врут они про битрикс, его невозможно было допилить, он годами пилился)
Не, ну он и сейчас активно пилится: и беклог растет уж точно не медленее, чем задачи релизятся :) Но основную свою функцию - наладить учет в онлайне с таким юзабилити чтобы людям не хотелось взять в руки вместо него excel мне кажется мы уже давно сделали.
А как я радовался когда вы наконец с гитолайта на гитлаб переехали...
Ага, хотел про это написать тоже, но места не хватило :)
На работе полыхает АД, очень хочу к вам на тусу, но надо тушить.
Так вечеринка с 18 до упаду! Приходи вечерком хоть на часик - перевидаться!
Конечно, PHP у нас самый большой "подцех" из всех. Тому я вижу несколько причин:
историческая (у нас изначально много клиентов было именно на нем)
коньюктура на рынке заказных проектов
низкий порог входа (-> больше специалистов/компаний субподрядчиков->легче масштабировать)
И сам иногда к станку встаёшь или уже не тянет?
Ну что ты сразу по больному :) Тянет, бывает, но для компании это было бы не целесообразно, поэтому коммерческие проекты точно никогда не пилю, из того что могу покодить - это только автоматизации на уровне PHP, JS или когда мы связывали нашу Jira & Finplan - немного покодил в Java / Groovy, но не более того.
Реально получается увольнять? Это же очень непростой вопрос если по КзоТ идти.
На моей памяти у меня был всего один случай когда дело доходило до разговора в плоскости ТК, но даже тогда мы как-то договорились. А так у меня не бывает "жестких" увольнений, обычно мы много разговариваем с теми кто "не тянет", и стараемся все исправить, ну и в итоге для обеих сторон становится очевидно, что не так, и все расстаются по взаимному.
Ну а в целом — поздравления! Успехов в работе и оторвитесь как следует на празднике.
Самый первый набор я не застал - компания существует с 2006 года. Тех, кто работает дольше меня - человек 8-10. Тех, с кем я работал с момента прихода и которые остались до сих пор - человек 20 плюс-минус.
Из "моих" разработчиков (изначально человек 5 вроде) со мной до сих пор осталось двое (один из них ушел и вернулся позже), еще с одним до сих пор хорошо дружим, с двумя другими почти нет - но вот на наш AGIMA XV ДР обещали прийти, вспомним прошлое :)
Текучка есть, ее не может не быть. Я имею ввиду, что любая компания, которая растет и развивается нанимает людей и увольняет людей, и сами люди неизбежно увольняются - так происходит естесственный отбор: остаются те, кто/кому подходит и уходят те, кому нужна другая компания/условия/стек/зп/локация/etc.
У нас очень много "возвращенцев": людей, которые однажды ушли, но потом поработав где-то еще вновь пришли к нам в компанию, смею надеятся, что это позитивный маркер :)
Гибкий график работы — "это режим труда, при котором сотрудник может определить самостоятельно начало и окончание рабочего дня по договоренности с работодателем" (пруфы: wiki, consultant.ru ст. 102 ТК РФ, kontur.ru, klerk.ru), левая пятка тут может участвовать только как аргумент для в процессе согласования с работодателем :)
Плавающий (на самом деле - скользящий) график — "...при котором выходные дни могут смещаться и выпадать на любые дни недели" или "... это предоставление выходных дней по меняющемуся графику (ст. 100 ТК РФ). То есть выходные в разные недели приходятся на разные дни" (пруфы: pro-personal.ru, kdelo.ru, kontur.ru), кажется больше подходит розничным магазинам или саппорт-отделам и т.д.
Всегда думал, что «плавающий график» это когда у тебя два через два (или вроде того, когда выходные плавающие), ну или когда график зависит не от меня (как работника), а его мне навязывает работодатель.
А когда я сам могу выбирать время прихода и ухода - «свободный».
А когда могу подвигать время влево-вправо - «гибкий».
Вроде в wiki ровно так (проверил только «гибкий» вариант): «Гибкое рабочее время (ГРВ) — форма организации рабочего времени, при которой в определённых пределах работник может самостоятельно определять часы работы в смену. ... В фиксированное время работник должен находиться на рабочем месте»
Но судя по откликам на хабре или у меня проблема с восприятием, или одно из двух. Покурю доки на досуге.
В кейсе из статьи, в той компании где я на тот момент работал, формально обязательно было получить апрув от тимлида и менеджера и зафиксировать в почте с руководством. Де-факто это почти никак не контролировалось, только инцидентно (например менеджеру/кому-то понадобился разработчик, его не оказалось, менеджер/кто-то нажаловался - следуют разборки почему нет официального согласования; альтернатива - рп/кто-то обсудил это с тимлидом или разработчиком без эскалации - решили сами)
в текущей компании (AGIMA) много команд, везде может быть настроено по разному, в зависимости от решений самой команды.
Есть общий дефолт - работа с 10 до 19, чтобы все работали в одно время. Можно сместить начало работы как угодно, если это не принесет вреда команде, для этого достаточно договориться с командой.
Если у тебя роль с более широким потенциальным кругом коммуникаций (например, как у меня - ко мне может в теории обратиться любой из членов наших команд, hr, бухгалтерия, администрация и т.д. по какому-нибудь вопросу), то согласовать мне надо будет с моим руководством, уведомть об этом всех и настроить рабочее время в календаре. Если с этим будут возникать проблемы (я буду долго отсутствовать и за меня всегда придется решать вопросы кому-то другому), надо будет решить как это пофиксить (смещением графика, переносом части вопросов на кого-то, тюнингом процессов и т.д.)
Мои разработчики/любые члены команд могут договориться о гибком начале рабочего дня (без привязки к определенному времени), я об этом могу не знать (и мне это не надо).
Надеюсь, прояснил, если есть еще вопросы или уточнения - welcome.
Для кого как, видимо. Для меня если я не могу отклонится от дефолтного времени - это не гибко, как раз на первом месте у нас это контролилось по СКУДу и всем было пофиг на обстоятельства.
А если я могу прийти когда угодно, главное об этом сообщить коллегам - это гибко. Для некоторых ролей в некоторых командах у нас сейчас можно и не сообщать - это уж как они сами у себя настроят, вышестоящее руководство вмешиваться не будет в общем случае.
Но у всех своя рабочая среда, я допускаю, что для кого то это может считаться не гибким, не вижу тут ничего страшного.
О том и речь, ровно так в моем опыте несколько лет назад и произошло: я требовал невозможного, люди горели и уходили. Собственно, это все и описано.
К сожалению, у меня тогда не было мудрого наставника который бы мне это подсветил недожидаясь негативного развития событий, поэтому пришлось пройти через такой вот опыт. Но по своему я за него тоже благодарен, в альтернативной мультивселенной я бы возможно не стал бы столько дотошным в этом вопросе.
А по поводу бюджетов и возможностей: мне кажется тут самый дьявол кроется в том, что технаря очень легко поймать на слове, на «слабо», на «небольшом» изменении требований и т.д. Как правило «бизнес» больше чем технари привык играть в игру «кто кого прожмет», и зачастую пользуется этим преимуществом чтобы получить согласие на желаемые сроки.
В результате, правда, проигрывают все (технари горят и переживают из за вынужденных костылей, бизнес вынужден корректировать сроки и уменьшать хотелки). Правда, частенько бизнес все равно будет считать это «победой», мотивируя тем, что если бы не так - то mvp вообще бы не выпустили.
Поэтому мне кажется очень важно чтобы среди бизнеса был человек который бы мог вникнуть во все что ему говорят технари и на основе этого самому придумать как быть, или среди технарей был человек который сможет выявить недосказанное и отстоять несдвигаемое.
Вообще, следуя вашей логике, для того чтобы не захотеть пойти к нам работать по этой причине, нужно узнать, что наш «гибкий» график работает «неправильно». Но пока не выйдешь к нам и не попробуешь - не узнаешь.
Так что вряд ли это является блокером, а если серьезно, то по сути я ответил в соседнем комментарии.
В этот момент истории я был в другой компании, нежели сейчас, но не суть.
У нас был гибкий график, но с нюансом: если от тебя зависят другие члены команды (например, у нас дейлики в 10:30, и ты там нужен), то поздний приход надо согласовать с ними (в кейсе из статьи - со мной). Ну и вот ребята в зафиксированное время опаздывали, а я малодушничал и об этом с ними просто не говорил (хотя стоило поработать и над переработками тоже, но до меня это тогда не доходило как-то).
Сейчас с этим проще, в плане того что чтобы не опоздать на митинг достаточно одной минуты для входа в meet, но я все равно за несложную дисциплину: мне легче работать в команде, когда я в знаю когда нужный мне человек доступен, поэтому прошу ребят фиксировать время старта дня. Спросить совета, узнать информацию, сроки, обсудить реализацию: иногда перевод такой коммуникации в последовательный режим может сильно растягивать решение простых вопросов. Иногда нет: очень зависит от личной загрузки.
Отвечу за Вики по поводу тегов: у нас в компании нет хорошо настроенной практики работы с тегами в wiki.
Мы используем Confluence, а отсюда вытекает, что теги сотрудники могут ставить какие им захочется. И казалось бы это очевидная проблема, ожидается хаос и многообразие тегов, но нет: их вообще никто не ставит :)
У нас есть теги, которые мы используем для обозначения принадлежности регламента/раздела/статьи к системе ("outsource-CRM") или роли ("helpfull-for-PM"), но где-то они есть, где то нет. Так что теги - это большая точка роста для нас.
Пока самое полезное из тегов, что у нас есть (как я считаю), это метка/тег "актуализировать", по которой можно посмотреть и запланировать в работу исправления.
Согласен, что тема с защитой данных важна, для этого нужен хороший DLP. Он же может применяться и в связке с wiki (на уровне распределения доступов, например) - но это прямо совсем другая история, в этой статье все-таки про наш опыт структурирования знаний. Могу сказать только, что сейчас учетки ко всем системам у нас управляется из единой точки, а условно-секретные документы/разделы в wiki по умолчанию закрыты и доступ выдается вручную.
По поводу несоответствий регламентов и реальных процессов - у нас как то принято писать комментарием к статье или ее части, что "тут не актуально, поправьте пожалуйста" и мы правим :) Статьи устаревают и их надо периодически ревьювить, иногда мы просто ставим тег "актуализировать" (например времени прямщас поправить статью нет, а упускать не хочется) и по нему потом отсматриваем, что устарело: назначаем задачи сотруднкам или себе актуализировать такие вещи.
Спасибо большое за теплые слова, очень рад, что оказалось полезно :)
И еще отдельно рад встретить тут тех, кто побывал на нашем курсе!
Привет, Лех!
Не, ну он и сейчас активно пилится: и беклог растет уж точно не медленее, чем задачи релизятся :) Но основную свою функцию - наладить учет в онлайне с таким юзабилити чтобы людям не хотелось взять в руки вместо него excel мне кажется мы уже давно сделали.
Ага, хотел про это написать тоже, но места не хватило :)
Так вечеринка с 18 до упаду! Приходи вечерком хоть на часик - перевидаться!
Конечно, PHP у нас самый большой "подцех" из всех. Тому я вижу несколько причин:
историческая (у нас изначально много клиентов было именно на нем)
коньюктура на рынке заказных проектов
низкий порог входа (-> больше специалистов/компаний субподрядчиков->легче масштабировать)
Ну что ты сразу по больному :) Тянет, бывает, но для компании это было бы не целесообразно, поэтому коммерческие проекты точно никогда не пилю, из того что могу покодить - это только автоматизации на уровне PHP, JS или когда мы связывали нашу Jira & Finplan - немного покодил в Java / Groovy, но не более того.
На моей памяти у меня был всего один случай когда дело доходило до разговора в плоскости ТК, но даже тогда мы как-то договорились. А так у меня не бывает "жестких" увольнений, обычно мы много разговариваем с теми кто "не тянет", и стараемся все исправить, ну и в итоге для обеих сторон становится очевидно, что не так, и все расстаются по взаимному.
Спасибо большоe
:)
Самый первый набор я не застал - компания существует с 2006 года. Тех, кто работает дольше меня - человек 8-10. Тех, с кем я работал с момента прихода и которые остались до сих пор - человек 20 плюс-минус.
Из "моих" разработчиков (изначально человек 5 вроде) со мной до сих пор осталось двое (один из них ушел и вернулся позже), еще с одним до сих пор хорошо дружим, с двумя другими почти нет - но вот на наш AGIMA XV ДР обещали прийти, вспомним прошлое :)
Текучка есть, ее не может не быть. Я имею ввиду, что любая компания, которая растет и развивается нанимает людей и увольняет людей, и сами люди неизбежно увольняются - так происходит естесственный отбор: остаются те, кто/кому подходит и уходят те, кому нужна другая компания/условия/стек/зп/локация/etc.
У нас очень много "возвращенцев": людей, которые однажды ушли, но потом поработав где-то еще вновь пришли к нам в компанию, смею надеятся, что это позитивный маркер :)
Да, главное не застрять на этапе 3.
Конечно, круче было бы нам использовать какие-нибудь HADI-циклы, но почему-то с большими изменениями все происходит как-то по другому :)
Покурил доки, все-таки вы ошибаетесь:
Гибкий график работы — "это режим труда, при котором сотрудник может определить самостоятельно начало и окончание рабочего дня по договоренности с работодателем" (пруфы: wiki, consultant.ru ст. 102 ТК РФ, kontur.ru, klerk.ru), левая пятка тут может участвовать только как аргумент для в процессе согласования с работодателем :)
Плавающий (на самом деле - скользящий) график — "...при котором выходные дни могут смещаться и выпадать на любые дни недели" или "... это предоставление выходных дней по меняющемуся графику (ст. 100 ТК РФ). То есть выходные в разные недели приходятся на разные дни" (пруфы: pro-personal.ru, kdelo.ru, kontur.ru), кажется больше подходит розничным магазинам или саппорт-отделам и т.д.
У нас в компании именно гибкий график работы.
Всегда думал, что «плавающий график» это когда у тебя два через два (или вроде того, когда выходные плавающие), ну или когда график зависит не от меня (как работника), а его мне навязывает работодатель.
А когда я сам могу выбирать время прихода и ухода - «свободный».
А когда могу подвигать время влево-вправо - «гибкий».
Вроде в wiki ровно так (проверил только «гибкий» вариант): «Гибкое рабочее время (ГРВ) — форма организации рабочего времени, при которой в определённых пределах работник может самостоятельно определять часы работы в смену. ... В фиксированное время работник должен находиться на рабочем месте»
Но судя по откликам на хабре или у меня проблема с восприятием, или одно из двух. Покурю доки на досуге.
Ок :)
Ну давайте подробно, если это принципиально.
В кейсе из статьи, в той компании где я на тот момент работал, формально обязательно было получить апрув от тимлида и менеджера и зафиксировать в почте с руководством. Де-факто это почти никак не контролировалось, только инцидентно (например менеджеру/кому-то понадобился разработчик, его не оказалось, менеджер/кто-то нажаловался - следуют разборки почему нет официального согласования; альтернатива - рп/кто-то обсудил это с тимлидом или разработчиком без эскалации - решили сами)
в текущей компании (AGIMA) много команд, везде может быть настроено по разному, в зависимости от решений самой команды.
Есть общий дефолт - работа с 10 до 19, чтобы все работали в одно время. Можно сместить начало работы как угодно, если это не принесет вреда команде, для этого достаточно договориться с командой.
Если у тебя роль с более широким потенциальным кругом коммуникаций (например, как у меня - ко мне может в теории обратиться любой из членов наших команд, hr, бухгалтерия, администрация и т.д. по какому-нибудь вопросу), то согласовать мне надо будет с моим руководством, уведомть об этом всех и настроить рабочее время в календаре. Если с этим будут возникать проблемы (я буду долго отсутствовать и за меня всегда придется решать вопросы кому-то другому), надо будет решить как это пофиксить (смещением графика, переносом части вопросов на кого-то, тюнингом процессов и т.д.)
Мои разработчики/любые члены команд могут договориться о гибком начале рабочего дня (без привязки к определенному времени), я об этом могу не знать (и мне это не надо).
Надеюсь, прояснил, если есть еще вопросы или уточнения - welcome.
Для кого как, видимо. Для меня если я не могу отклонится от дефолтного времени - это не гибко, как раз на первом месте у нас это контролилось по СКУДу и всем было пофиг на обстоятельства.
А если я могу прийти когда угодно, главное об этом сообщить коллегам - это гибко. Для некоторых ролей в некоторых командах у нас сейчас можно и не сообщать - это уж как они сами у себя настроят, вышестоящее руководство вмешиваться не будет в общем случае.
Но у всех своя рабочая среда, я допускаю, что для кого то это может считаться не гибким, не вижу тут ничего страшного.
О том и речь, ровно так в моем опыте несколько лет назад и произошло: я требовал невозможного, люди горели и уходили. Собственно, это все и описано.
К сожалению, у меня тогда не было мудрого наставника который бы мне это подсветил недожидаясь негативного развития событий, поэтому пришлось пройти через такой вот опыт. Но по своему я за него тоже благодарен, в альтернативной мультивселенной я бы возможно не стал бы столько дотошным в этом вопросе.
А по поводу бюджетов и возможностей: мне кажется тут самый дьявол кроется в том, что технаря очень легко поймать на слове, на «слабо», на «небольшом» изменении требований и т.д. Как правило «бизнес» больше чем технари привык играть в игру «кто кого прожмет», и зачастую пользуется этим преимуществом чтобы получить согласие на желаемые сроки.
В результате, правда, проигрывают все (технари горят и переживают из за вынужденных костылей, бизнес вынужден корректировать сроки и уменьшать хотелки). Правда, частенько бизнес все равно будет считать это «победой», мотивируя тем, что если бы не так - то mvp вообще бы не выпустили.
Поэтому мне кажется очень важно чтобы среди бизнеса был человек который бы мог вникнуть во все что ему говорят технари и на основе этого самому придумать как быть, или среди технарей был человек который сможет выявить недосказанное и отстоять несдвигаемое.
Глубокая мысль, спасибо, пойду думать про мудрость жизни и идеалы.
Вообще, следуя вашей логике, для того чтобы не захотеть пойти к нам работать по этой причине, нужно узнать, что наш «гибкий» график работает «неправильно». Но пока не выйдешь к нам и не попробуешь - не узнаешь.
Так что вряд ли это является блокером, а если серьезно, то по сути я ответил в соседнем комментарии.
Привет!
В этот момент истории я был в другой компании, нежели сейчас, но не суть.
У нас был гибкий график, но с нюансом: если от тебя зависят другие члены команды (например, у нас дейлики в 10:30, и ты там нужен), то поздний приход надо согласовать с ними (в кейсе из статьи - со мной). Ну и вот ребята в зафиксированное время опаздывали, а я малодушничал и об этом с ними просто не говорил (хотя стоило поработать и над переработками тоже, но до меня это тогда не доходило как-то).
Сейчас с этим проще, в плане того что чтобы не опоздать на митинг достаточно одной минуты для входа в meet, но я все равно за несложную дисциплину: мне легче работать в команде, когда я в знаю когда нужный мне человек доступен, поэтому прошу ребят фиксировать время старта дня. Спросить совета, узнать информацию, сроки, обсудить реализацию: иногда перевод такой коммуникации в последовательный режим может сильно растягивать решение простых вопросов. Иногда нет: очень зависит от личной загрузки.
Привет!
Жаль, что ничего полезного для себя не нашли в статье. Тем не менее спасибо, что нашли время прочитать и, тем более, оставить комментарий.