1. Входит. Но цель этого «мероприятия» не оценить, как сотрудник грузит коробки или обслуживает покупателей, а погрузить нового сотрудника в контекст работы розницы, которую, как верно указано в одном из комментов, ему потом придется автоматизировать и делать жизнь сотрудников магазинов лучше. Все это заранее обговаривается на собеседованиях. Поэтому «отказников» нет. Если потенциального сотрудника это в корне не устраивает (крайне редкий кейс), то он к нам не идет. Глобальных выводов по итогам интеграции в магазине тоже, конечно же, никто не делает. Если только новичок по полной там не «отличится». Как было написано в статье, у меня была интеграция почти 4 месяца. И окончание своего исп. срока я встретил в магазине :-)
2. Ответил в предыдущем пункте. Добавлю, что всю ответственность за сотрудника, проходящего интеграцию в магазине, берет на себя сам магазин. Конечно, никто ему потом не выставляет «счет» за разбитую банку с краской или недовольного клиента.
3. Тут пусть лучше ответят коллеги, которые больше погружены в эту тему. Но, если я не ошибаюсь, мед. книжки оформляются только в случае торговли продуктами. Мы продукты не продаем, и мед. книжки не оформляем. У меня ее, по крайней мере, нет.
4. Учитываются все особенности каждого сотрудника. Если человек не может таскать тяжести, никто его не будет заставлять это делать. Если ему вообще запрещено работать в магазинах (не уверен, что такое вообще возможно), мы найдем другой способ погружения в контекст.
5. Я не знаю, что такое «коллективный договор мат ответственности». Оставлю это для более компетентных коллег :-)
Точно знаю, что тему с InnerSource еще двигают ребята из одного сервиса доставки еды с зеленым логотипом. Сдается мне, логотип российского InnerSource-сообщества должен быть зеленым ;-)
Нет, мы сами его не разрабатываем. Но описанный процесс точно не является ограничением кассового ПО. Оно позволяет пропикивать товары в произвольном порядке по одному, пропикивать один товар и вводить количество, совмещать эти варианты и т.д.
Сейчас, в основном, разработчики каждого бизнес-юнита пишут для себя. Но у нас есть амбиции делать это для всей группы ADEO. И именно поэтому мы совместно с Францией и Бразилией запустили переход к InnerSource, который и позволит нам делать приложения, которые можно будет использовать (адаптировать, дописывать свой код) в других странах. Но, конечно, InnerSource — это всего лишь один из шагов. Сейчас мы очень много внимания уделяем этому вопросу.
Такая проблема, конечно, существует. И существует везде, вне зависимости от структуры команд и организации. Приложения, которые долго не меняются, оказываются «забыты» командой. Но при этом оно не является брошенным. Любое приложение относится к одной из программ (горизонтальные стримы на картинке со структурой нашей дирекции ИТ). Таким образом всегда есть кто-то, кто отвечает за работоспособность любого приложения. К тому же у нас довольна маленькая текучка, и найти разработчика, который это разрабатывал, как правило, удаётся.
Сейчас нет 200 разрабов, это наша цель. Как раз, чтоб была возможность исправить все, что сейчас работает не так, как мы хотим. Ссылка на вакансию для тех, кто хочет помочь.
Да, мы привлекаем и архитекторов. Более того, они всегда есть в команде. Но они отвечают больше за энтерпрайз архитектуру в целом, как раз те самые подходы, стили и видение. А техническая архитектура в ответственности команды разработки. И т.к. команда полностью отвечает за свое приложение (you build it, you run it), она и несёт ответственность за это решение даже с привлечением «арбитра». Т.е. потом сказать, дескать, «Это не я предложил, это он, все вопросы к нему» — не получится.
Раньше было именно так. Сейчас — нет. Сейчас очень много ПО мы используем своего.
Пока разработчики в каждом бизнес-юните по большей части пишут для себя. Кроме разработчиков ADEO, которые как раз пишут для всех БЮ. Но мы идём (на самом деле, уже бежим вприпрыжку) в сторону InnerSource, что позволит без напрягов шарить код между всеми разработчиками группы.
Конечно, для ERP и бухгалтерии используются подобные приложения. Но ими занимаются другие отделы и/или (реже) подрядчики. И мы пока не уверены, что хотим (способны?) забрать разработку этих «монстров» к себе в Фабрику разработки.
Вариант с привязкой к cookies, конечно, город в анонимайзере не сохранит, но решит проблему при переходе из поисковиков. Попрошу команду, занимающейся этой фичей, поскорее её зарелизить.
Задача не такая простая, как может показаться на первый взгляд, возможно, даже напишем приключенческий пост, как мы это решаем. Нельзя просто поставить редирект с основного домена на домен региона, нужно учитывать много факторов. Был основной вариант смотреть на куку и редиректить только в этом случае, скорее всего так и поступим в ближайших релизах.
В любом случае буду рад, если поделитесь своей экспертизой в этом вопросе.
2. Ответил в предыдущем пункте. Добавлю, что всю ответственность за сотрудника, проходящего интеграцию в магазине, берет на себя сам магазин. Конечно, никто ему потом не выставляет «счет» за разбитую банку с краской или недовольного клиента.
3. Тут пусть лучше ответят коллеги, которые больше погружены в эту тему. Но, если я не ошибаюсь, мед. книжки оформляются только в случае торговли продуктами. Мы продукты не продаем, и мед. книжки не оформляем. У меня ее, по крайней мере, нет.
4. Учитываются все особенности каждого сотрудника. Если человек не может таскать тяжести, никто его не будет заставлять это делать. Если ему вообще запрещено работать в магазинах (не уверен, что такое вообще возможно), мы найдем другой способ погружения в контекст.
5. Я не знаю, что такое «коллективный договор мат ответственности». Оставлю это для более компетентных коллег :-)
Точно знаю, что тему с InnerSource еще двигают ребята из одного сервиса доставки еды с зеленым логотипом. Сдается мне, логотип российского InnerSource-сообщества должен быть зеленым ;-)
1-2 месяца.
В любом случае буду рад, если поделитесь своей экспертизой в этом вопросе.