Чем заняться в Дубае?
Подняться на Бурдж-Халифа? Посетить Дубай Молл? Покататься на верблюдах? Поплавать в Персидском заливе?
Нет, это всё не важно! Важно, что теперь разные бьюти нищтяки можно заказать онлайн в Золотом Яблоке, потому что сегодня мы открылись в Арабских Эмиратах!
iOS / android / goldapple.ae
P.S.: Если вы любите всё потрогать, пощупать, понюхать, то офлайн магазин тоже скоро будет.
Подняться на Бурдж-Халифа? Посетить Дубай Молл? Покататься на верблюдах? Поплавать в Персидском заливе?
Нет, это всё не важно! Важно, что теперь разные бьюти нищтяки можно заказать онлайн в Золотом Яблоке, потому что сегодня мы открылись в Арабских Эмиратах!
iOS / android / goldapple.ae
P.S.: Если вы любите всё потрогать, пощупать, понюхать, то офлайн магазин тоже скоро будет.
🔥14😁5❤4🎉1
Telegram — плохой мессенджер для корпоративной работы.
Давно пытался подойти к этой теме, но каждый раз не получалось. Совсем недавно вышла новость, и кажется, тема снова стала актуальной.
У меня большой опыт использования различных корп инструментов и мессенджеров. Помню, что все начиналось со Skype, потом был Google Talk, затем появилась Telegram и уже где-то в 2014 — Slack. Пять лет я пользовался Slack и был в восторге от его функциональности и ботов. Потом, при смене работы, пришлось перейти на весь стек MS 365, в том числе на MS Teams. Как мессенджер, Teams, конечно, слабоват по сравнению со Slack, но его интеграция календарь + звонки + чат — это кайф!
Я всегда (после опыта slack) был противником использования любых общих мессенджеров типа Telegram для корп работы. Причин этому множество, и некоторые вполне понятны и лежат на поверхности:
- безопасность,
- логин по корпоративной учетной записи,
- поиск любого сотрудника внутри мессенджера по ФИО.
Некоторые скрыты, т.к. без опыта использования корп мессенджеров их не понять:
- теги: команд, руководителей, гильдий,
- стандартизация в организации чатов/каналов и их именовании,
- тесная интеграция с другими корпоративными инструментами,
- права на публикацию сообщений в каналы,
- орг структура,
- готовый набор ботов для автоматизации.
И, пожалуй, главное — это принцип публичности информации и способов массовой коммуникации. В любом некорпоративном мессенджере нет возможности делать HBC (high bandwidth communication). Нет возможности написать что-то куда-то, чтобы эта информация была донесена до каждого сотрудника компании. Эта проблема порождает создание множества мелких чатов каждый раз с разным составом. Все общие чаты в Telegram, где больше ста человек, сразу замьючиваются, так как там, как правило, начинается бардак и флуд. Про отсутствие тредов я вообще молчу, топики не в счёт.
Сейчас, на мой субъективный взгляд, рынок в РФ поделился на две части. Первые — это те, кто раньше сидели на Slack и сами перешли на Mattermost или купил Mattermost, обернутый в собственный продукт (loop, time). Вторые — это те, кто не может по тем или иным причинам использовать Mattermost, и их обязывают пересаживаться на решения, которые получили какую-либо сертификацию от государства (express, squadus, ...). Есть ещё, конечно, что-то между, типа pachca и VK Teams, но о них я совсем ничего не знаю.
К чему я это всё? Slack и MS Teams ушли из России или навсегда, или на очень долгое время. Исходя из закреплённой новости, использование Telegram для корпоративного общения также может быть под вопросом (и я этому рад). Видимо, следующие два года будут крайне интересными в плане конкуренции за рынок корпоративных мессенджеров в РФ.
Давно пытался подойти к этой теме, но каждый раз не получалось. Совсем недавно вышла новость, и кажется, тема снова стала актуальной.
У меня большой опыт использования различных корп инструментов и мессенджеров. Помню, что все начиналось со Skype, потом был Google Talk, затем появилась Telegram и уже где-то в 2014 — Slack. Пять лет я пользовался Slack и был в восторге от его функциональности и ботов. Потом, при смене работы, пришлось перейти на весь стек MS 365, в том числе на MS Teams. Как мессенджер, Teams, конечно, слабоват по сравнению со Slack, но его интеграция календарь + звонки + чат — это кайф!
Я всегда (после опыта slack) был противником использования любых общих мессенджеров типа Telegram для корп работы. Причин этому множество, и некоторые вполне понятны и лежат на поверхности:
- безопасность,
- логин по корпоративной учетной записи,
- поиск любого сотрудника внутри мессенджера по ФИО.
Некоторые скрыты, т.к. без опыта использования корп мессенджеров их не понять:
- теги: команд, руководителей, гильдий,
- стандартизация в организации чатов/каналов и их именовании,
- тесная интеграция с другими корпоративными инструментами,
- права на публикацию сообщений в каналы,
- орг структура,
- готовый набор ботов для автоматизации.
И, пожалуй, главное — это принцип публичности информации и способов массовой коммуникации. В любом некорпоративном мессенджере нет возможности делать HBC (high bandwidth communication). Нет возможности написать что-то куда-то, чтобы эта информация была донесена до каждого сотрудника компании. Эта проблема порождает создание множества мелких чатов каждый раз с разным составом. Все общие чаты в Telegram, где больше ста человек, сразу замьючиваются, так как там, как правило, начинается бардак и флуд. Про отсутствие тредов я вообще молчу, топики не в счёт.
Сейчас, на мой субъективный взгляд, рынок в РФ поделился на две части. Первые — это те, кто раньше сидели на Slack и сами перешли на Mattermost или купил Mattermost, обернутый в собственный продукт (loop, time). Вторые — это те, кто не может по тем или иным причинам использовать Mattermost, и их обязывают пересаживаться на решения, которые получили какую-либо сертификацию от государства (express, squadus, ...). Есть ещё, конечно, что-то между, типа pachca и VK Teams, но о них я совсем ничего не знаю.
К чему я это всё? Slack и MS Teams ушли из России или навсегда, или на очень долгое время. Исходя из закреплённой новости, использование Telegram для корпоративного общения также может быть под вопросом (и я этому рад). Видимо, следующие два года будут крайне интересными в плане конкуренции за рынок корпоративных мессенджеров в РФ.
Интерфакс
Минцифры предложило ограничить использование иностранных мессенджеров в рабочих целях
Предлагается запретить это сотрудникам маркетплейсов, доставки, банков, ЦБ, операторов связи и госслужащим
👍8💯3
Пост про мобильную платформу, как продолжение этого поста.
Наконец-то закрепил мысли о мобильной платформе в своем playbook.
Помните, где-то в середине 2010-х появился термин Mobile First? Я впервые услышал его на одном из AllHands в Островке. СЕО говорил, что вскоре более половины заказов будет делаться на мобильных платформах, и веб будет отодвинут на второй план. В целом сейчас так и есть. В ЗЯ веб занимает достаточно небольшую долю Ecom заказов относительно iOS+Android. При этом он критически необходим в рамках общего продуктового ландшафта для клиентов. Почему Mobile стал First, думаю, понятно. А что дальше? Как поддерживать близкие или одинаковые подходы для iOS/Android, чтобы условным QA было легче тестировать, а бэку не приходилось разрываться между хотелками разных платформ? Как делать BDUI? Как внедрять APM? Как выстраивать единые подходы к релизным циклам? Разные компании решают эти вопросы по-разному, но как будто все в итоге приходят к мобильным платформенным командам.
#playbook
Наконец-то закрепил мысли о мобильной платформе в своем playbook.
Общая цель мобильной платформы — это обеспечение высокого DevExp для любого разработчика iOS/Android с целью повышения общего качества и стабильности разработки для последующего ускорения time-to-market в продуктовых командах.
Помните, где-то в середине 2010-х появился термин Mobile First? Я впервые услышал его на одном из AllHands в Островке. СЕО говорил, что вскоре более половины заказов будет делаться на мобильных платформах, и веб будет отодвинут на второй план. В целом сейчас так и есть. В ЗЯ веб занимает достаточно небольшую долю Ecom заказов относительно iOS+Android. При этом он критически необходим в рамках общего продуктового ландшафта для клиентов. Почему Mobile стал First, думаю, понятно. А что дальше? Как поддерживать близкие или одинаковые подходы для iOS/Android, чтобы условным QA было легче тестировать, а бэку не приходилось разрываться между хотелками разных платформ? Как делать BDUI? Как внедрять APM? Как выстраивать единые подходы к релизным циклам? Разные компании решают эти вопросы по-разному, но как будто все в итоге приходят к мобильным платформенным командам.
#playbook
👍3❤2
Пост про благотворительность.
В уже более-менее зрелом возрасте, когда появились свои дети и какая-то осознанность о происходящем в мире, я начал интересоваться благотворительностью.
Явным триггером стала жуткая трагедия в ТЦ "Зимняя вишня" в городе Кемерово. Помню, что мне очень хотелось как-то помочь, но я не понимал, как это сделать. Это желание трансформировалось в поиск удобного способа помогать детям с какими-либо заболеваниями типа рака или чего-то аутоиммунного. Сначала я пользовался сервисом Добро от Mail.ru. Но сейчас, как мне кажется, существует значительно более удобный и простой способ жертвовать на благотворительность — это настроить в своем банке перевод кэшбэка в любой из благотворительных фондов. Мне этот вариант нравится тем, что чем больше я трачу, тем больше помогаю, а чтобы больше тратить, надо больше зарабатывать. Таким образом, изначально чувство алчности и условное желание купить новый автомобиль в итоге приводит к тому, что я больше трачу на благотворительность.
Я ни к чему не призываю, но если у вас есть такая возможность, то рекомендую настроить перевод кэшбэка в какой-нибудь фонд. К счастью, в банках эти фонды уже проверены за вас, и нужно лишь выбрать тот, который вам более близок по духу.
К чему я все это. Люблю, когда грамотные IT-решения помогают решать такие тонкие психологически-моральные вопросы.
В уже более-менее зрелом возрасте, когда появились свои дети и какая-то осознанность о происходящем в мире, я начал интересоваться благотворительностью.
Явным триггером стала жуткая трагедия в ТЦ "Зимняя вишня" в городе Кемерово. Помню, что мне очень хотелось как-то помочь, но я не понимал, как это сделать. Это желание трансформировалось в поиск удобного способа помогать детям с какими-либо заболеваниями типа рака или чего-то аутоиммунного. Сначала я пользовался сервисом Добро от Mail.ru. Но сейчас, как мне кажется, существует значительно более удобный и простой способ жертвовать на благотворительность — это настроить в своем банке перевод кэшбэка в любой из благотворительных фондов. Мне этот вариант нравится тем, что чем больше я трачу, тем больше помогаю, а чтобы больше тратить, надо больше зарабатывать. Таким образом, изначально чувство алчности и условное желание купить новый автомобиль в итоге приводит к тому, что я больше трачу на благотворительность.
Я ни к чему не призываю, но если у вас есть такая возможность, то рекомендую настроить перевод кэшбэка в какой-нибудь фонд. К счастью, в банках эти фонды уже проверены за вас, и нужно лишь выбрать тот, который вам более близок по духу.
К чему я все это. Люблю, когда грамотные IT-решения помогают решать такие тонкие психологически-моральные вопросы.
❤11👍4🙏1
С наступающим новым годом, инженеры!
Помните Stadia от Google?
Есть отличная фраза, хорошо отражающая один из принципов нашей индустрии: "Кто не падал, тот не поднимался!". Не важно, как сильно ты упал, важно, как быстро ты поднялся и какой урок ты извлек из этого.
Желаю всем нам, чтобы в следующем году мы как можно меньше падали, а уж если упали, то быстро поднялись и ... (ну вы поняли)
Всем мир, любовь и отсутствия инцидентов на предстоящих праздниках!
Помните Stadia от Google?
Stadia была анонсирована в марте 2019 года и запущена уже в ноябре. Идея облачного гейминга была не нова, и многие игроки на рынке уже имели свои платформы для этого, такие как GeForce Now от Nvidia, но интеграция Stadia с YouTube выглядела действительно инновационно. Уже в сентябре 2022 года Google официально объявила о прекращении работы Stadia, и в январе 2023 года платформа была окончательно закрыта.
Есть отличная фраза, хорошо отражающая один из принципов нашей индустрии: "Кто не падал, тот не поднимался!". Не важно, как сильно ты упал, важно, как быстро ты поднялся и какой урок ты извлек из этого.
Желаю всем нам, чтобы в следующем году мы как можно меньше падали, а уж если упали, то быстро поднялись и ... (ну вы поняли)
Всем мир, любовь и отсутствия инцидентов на предстоящих праздниках!
🎄21🍾6❤3
Про аутстафф.
Ниже размышления исключительно на основе своего личного опыта работы с аутстафф-сотрудниками.
Во-первых. При привлечении аутстафф-сотрудника кандидат должен проходить те же этапы собеседования, что и кандидат при найме в штат, т.е. это как минимум технический этап и этап проверки soft skills. Полагаться на веру в то, что вам сразу дадут технически сильных кандидатов, которые умеют работать в команде, не стоит. Всегда надо проверять.
Во-вторых. Это способ оплаты time-to-material, т.е. когда аутстафф-сотрудник полностью вовлечён в работу вашей команды, не отвлекается на сторонние проекты и, в идеале, не трекает нигде время, т.к. и так понятно, что он занят каждый день задачами вашей команды.
В-третьих. Аутстафф-сотрудник после онбординга должен обладать правами, практически равными штатному сотруднику, чтобы он чувствовал себя частью команды, понимал общие цели, задачи и метрики команды. Он должен чувствовать, что его наняли не просто тупо делать то, что ему скажут, а как специалиста, который имеет свою точку зрения, экспертизу и может влиять на принятие решений в рамках зоны своей ответственности и экспертности.
В-четвёртых. Ваш тимлид должен работать с аутстафф-сотрудником практически так же, как если бы это был его штатный сотрудник. С одной стороны, спорный тезис, так как для тимлида это, возможно, будет работа "в стол" — ведь аутстафф-сотрудник может по разным, не зависящим от тимлида причинам, покинуть проект. Но это необходимо, т.к. иначе сложно будет добиться качества работы аутстафф-сотрудника такого же, как от штатного сотрудника.
В-пятых. Привлечение аутстафф-сотрудников стоит сопровождать параллельным поиском штатных сотрудников, т.к. на постоянной основе иметь в штате большое количество аутстаффа может быть слишком рискованным подходом для ваших команд разработки.
В целом аутстафф — нормальная тема, если уметь его правильно применять и не преувеличивать с количеством.
Ниже размышления исключительно на основе своего личного опыта работы с аутстафф-сотрудниками.
Во-первых. При привлечении аутстафф-сотрудника кандидат должен проходить те же этапы собеседования, что и кандидат при найме в штат, т.е. это как минимум технический этап и этап проверки soft skills. Полагаться на веру в то, что вам сразу дадут технически сильных кандидатов, которые умеют работать в команде, не стоит. Всегда надо проверять.
Во-вторых. Это способ оплаты time-to-material, т.е. когда аутстафф-сотрудник полностью вовлечён в работу вашей команды, не отвлекается на сторонние проекты и, в идеале, не трекает нигде время, т.к. и так понятно, что он занят каждый день задачами вашей команды.
В-третьих. Аутстафф-сотрудник после онбординга должен обладать правами, практически равными штатному сотруднику, чтобы он чувствовал себя частью команды, понимал общие цели, задачи и метрики команды. Он должен чувствовать, что его наняли не просто тупо делать то, что ему скажут, а как специалиста, который имеет свою точку зрения, экспертизу и может влиять на принятие решений в рамках зоны своей ответственности и экспертности.
В-четвёртых. Ваш тимлид должен работать с аутстафф-сотрудником практически так же, как если бы это был его штатный сотрудник. С одной стороны, спорный тезис, так как для тимлида это, возможно, будет работа "в стол" — ведь аутстафф-сотрудник может по разным, не зависящим от тимлида причинам, покинуть проект. Но это необходимо, т.к. иначе сложно будет добиться качества работы аутстафф-сотрудника такого же, как от штатного сотрудника.
В-пятых. Привлечение аутстафф-сотрудников стоит сопровождать параллельным поиском штатных сотрудников, т.к. на постоянной основе иметь в штате большое количество аутстаффа может быть слишком рискованным подходом для ваших команд разработки.
В целом аутстафф — нормальная тема, если уметь его правильно применять и не преувеличивать с количеством.
👍13🔥5❤3💩2
Про управленческую ёмкость у руководителя руководителей.
Выше в этом посте я размышлял про максимальный размер команды. Сейчас хочется подумать о количестве прямых репортов у руководителя департамента/отдела/управления, те не о руководителе команды.
Скажем, у нас есть тимлид тимлидов. Сколько у него может быть в прямом подчинении тимлидов, те команд? За сколько команд он может нести ответственность как руководитель домена?
Если отталкиваться от «Кошелек Миллера», то это 7 ± 2. На мой взгляд, это не совсем верно именно для данного вопроса, верно что-то типа 4 ± 1. Две команды — вроде бы слишком мало, чтобы формировать домен, а шесть — уже как будто бы слишком много, чтобы держать в фокусе все цели всех команд и строить долгосрочное целеполагание и систему метрик для тимлидов этих команд. Понятно, что это зависит от множества факторов и условий, но, на мой взгляд, должно быть примерно так.
Если спросить у gpt, то
Что думаете?
Выше в этом посте я размышлял про максимальный размер команды. Сейчас хочется подумать о количестве прямых репортов у руководителя департамента/отдела/управления, те не о руководителе команды.
Скажем, у нас есть тимлид тимлидов. Сколько у него может быть в прямом подчинении тимлидов, те команд? За сколько команд он может нести ответственность как руководитель домена?
Если отталкиваться от «Кошелек Миллера», то это 7 ± 2. На мой взгляд, это не совсем верно именно для данного вопроса, верно что-то типа 4 ± 1. Две команды — вроде бы слишком мало, чтобы формировать домен, а шесть — уже как будто бы слишком много, чтобы держать в фокусе все цели всех команд и строить долгосрочное целеполагание и систему метрик для тимлидов этих команд. Понятно, что это зависит от множества факторов и условий, но, на мой взгляд, должно быть примерно так.
Если спросить у gpt, то
3–5 команд. Подходит для отделов, требующих высокой координации и персонального внимания (например, научные исследования, продуктовые команды в IT).
5–8 команд. Стандарт для крупных отделов, где требуется умеренный уровень координации.
Более 8 команд. Это редко, так как высокая нагрузка на руководителя снижает управление. В таких случаях создаются дополнительные уровни управления (например, подотделы с руководителями групп).
Что думаете?
❤7👍3💩2
Должен ли СТО хантить сам?
Когда я работал в Магнит, рядом с нами, скажем так, на одной улице, расформировывалась одна из самых крупных (или самая крупная) IT-компаний РФ в сфере доставки продуктов и еды из ресторанов. Благодаря проактивным действиям и нетворкингу нам удалось привлечь в свои команды топовых инженеров. Этим занимался не рекрутмент, этим занимался наш СТО и все СТО-1.
Сейчас ЗЯ находится на этапе активного роста, мы расширяем команду, приглашая новых инженеров. Я лично вовлечён в этот процесс и причина не в нехватке сотрудников в отделе рекрутинга. Я глубоко убеждён, что СТО обязан играть значимую роль в привлечении, оценке и собеседовании специалистов для ключевых направлений, которые имеют решающее значение для компании на определённых этапах ее развития.
Думаю, вы слышали, что, начиная с декабря 2024 года, в IT-инфополе начали появляться новости о череде сокращений у крупных IT-гигантов. Это продолжается и на текущий момент, новостей становится больше и касается это большего числа компаний. Понимаю, что аудитория этого канала является достаточно узким кругом моих знакомств, но всё же, если вы сейчас находитесь в поиске, напишите мне (@arxell). Или откликайтесь на наш лендинг. Сейчас в первую очередь нужны сильные C# backend-разработчики для развития своей программы лояльности/биллинга и запуска разных рекламных штук =)
Когда я работал в Магнит, рядом с нами, скажем так, на одной улице, расформировывалась одна из самых крупных (или самая крупная) IT-компаний РФ в сфере доставки продуктов и еды из ресторанов. Благодаря проактивным действиям и нетворкингу нам удалось привлечь в свои команды топовых инженеров. Этим занимался не рекрутмент, этим занимался наш СТО и все СТО-1.
Сейчас ЗЯ находится на этапе активного роста, мы расширяем команду, приглашая новых инженеров. Я лично вовлечён в этот процесс и причина не в нехватке сотрудников в отделе рекрутинга. Я глубоко убеждён, что СТО обязан играть значимую роль в привлечении, оценке и собеседовании специалистов для ключевых направлений, которые имеют решающее значение для компании на определённых этапах ее развития.
Думаю, вы слышали, что, начиная с декабря 2024 года, в IT-инфополе начали появляться новости о череде сокращений у крупных IT-гигантов. Это продолжается и на текущий момент, новостей становится больше и касается это большего числа компаний. Понимаю, что аудитория этого канала является достаточно узким кругом моих знакомств, но всё же, если вы сейчас находитесь в поиске, напишите мне (@arxell). Или откликайтесь на наш лендинг. Сейчас в первую очередь нужны сильные C# backend-разработчики для развития своей программы лояльности/биллинга и запуска разных рекламных штук =)
👍11❤8❤🔥2
Банального вопроса пост.
Должен ли TeamLead писать код?
Вопрос, которым задается каждый TeamLead команды, когда становится её руководителем. Именно в такой формулировке правильного ответа на него нет. Нет, потому что вопрос задан неверно: в нём не раскрыто, о какой именно команде идет речь. Правильная формулировка, например, может быть такой:
Или такой:
В целом всё просто. Чем больше в команде инженеров разных специальностей, тем меньше TeamLead должен уделять времени написанию кода. Его фокус смещается на people-менеджмент, процессы, архитектуру, документацию, метрики и планирование. На самом деле, на все то, что описано на Teamlead Roadmap.
Сейчас это встречается реже, но раньше в вакансиях на TeamLead'а часто писали про "играющего тренера" при команде из ±10 человек. Это жуткий антипаттерн. Если вы хотите полноценного "играющего тренера", который будет хотя бы 50% времени писать код, то это точно про функциональные команды (команды одного стека разработки) с составом ±5 человек.
Моя точка зрения такая: Не важно, пишет ли ваш TeamLead код, важно, чтобы он "программировал" своих сотрудников и свою команду на успех!
Набор статей на эту тему для составления собственного мнения:
- Должен ли тимлид писать код?
- Почему тимлид может писать код?
- От джуна до тимлида. Должен ли тимлид писать хороший код, чем хорош planning poker и другие интересности
- Уже не программист, но еще не менеджер
- Руководитель, который навсегда в вашем сердечке, — какой он? И что делает его таким крутым? ❤️
Должен ли TeamLead писать код?
Вопрос, которым задается каждый TeamLead команды, когда становится её руководителем. Именно в такой формулировке правильного ответа на него нет. Нет, потому что вопрос задан неверно: в нём не раскрыто, о какой именно команде идет речь. Правильная формулировка, например, может быть такой:
Должен ли TeamLead писать код в команде, состоящей из трёх backend-разработчиков?
Или такой:
Должен ли TeamLead писать код в команде, состоящей из десяти инженеров разных стеков разработки/тестирования/аналитики?
В целом всё просто. Чем больше в команде инженеров разных специальностей, тем меньше TeamLead должен уделять времени написанию кода. Его фокус смещается на people-менеджмент, процессы, архитектуру, документацию, метрики и планирование. На самом деле, на все то, что описано на Teamlead Roadmap.
Сейчас это встречается реже, но раньше в вакансиях на TeamLead'а часто писали про "играющего тренера" при команде из ±10 человек. Это жуткий антипаттерн. Если вы хотите полноценного "играющего тренера", который будет хотя бы 50% времени писать код, то это точно про функциональные команды (команды одного стека разработки) с составом ±5 человек.
Моя точка зрения такая: Не важно, пишет ли ваш TeamLead код, важно, чтобы он "программировал" своих сотрудников и свою команду на успех!
Набор статей на эту тему для составления собственного мнения:
- Должен ли тимлид писать код?
- Почему тимлид может писать код?
- От джуна до тимлида. Должен ли тимлид писать хороший код, чем хорош planning poker и другие интересности
- Уже не программист, но еще не менеджер
- Руководитель, который навсегда в вашем сердечке, — какой он? И что делает его таким крутым? ❤️
👍15😁4❤2
Крутое исследование от JetBrains - State of Developer Ecosystem Report 2024
Вот что я для себя отметил:
- JS, как всегда, на первом месте. Python тоже не отстает, видимо, благодаря ML/DS и прочим математическим задачам.
- Радует, что PostgreSQL потихоньку отжимает аудиторию у MySQL, а MongoDB/SQLite/Redis внезапно для меня стабильно находятся на +- третьем месте.
- GoLang немного сдал позиции, но, видимо, за пределами РФ. В РФ все же Go остается крайне популярным.
- Rust потихоньку растет и все еще надеется заменить C/C++.
- Yandex Cloud занял 1% аудитории облачных сервисов, что приятно.
- 28% респондентов ответили, что компания измеряет их development experience и продуктивность. При этом за эти метрики в 68% случаев отвечает TeamLead, а в 17% случаев — платформенные команды. Однако! =)
- Самое сложное в работе: 38% — понять, чего хочет клиент, 34% — коммуникации по рабочим вопросам c коллегами, 32% — понимание чужого кода.
- И самое интересное и волнующее для меня — это размер команды: 71% опрошенных работают в командах до 12 человек.
Вот что я для себя отметил:
- JS, как всегда, на первом месте. Python тоже не отстает, видимо, благодаря ML/DS и прочим математическим задачам.
- Радует, что PostgreSQL потихоньку отжимает аудиторию у MySQL, а MongoDB/SQLite/Redis внезапно для меня стабильно находятся на +- третьем месте.
- GoLang немного сдал позиции, но, видимо, за пределами РФ. В РФ все же Go остается крайне популярным.
- Rust потихоньку растет и все еще надеется заменить C/C++.
- Yandex Cloud занял 1% аудитории облачных сервисов, что приятно.
- 28% респондентов ответили, что компания измеряет их development experience и продуктивность. При этом за эти метрики в 68% случаев отвечает TeamLead, а в 17% случаев — платформенные команды. Однако! =)
- Самое сложное в работе: 38% — понять, чего хочет клиент, 34% — коммуникации по рабочим вопросам c коллегами, 32% — понимание чужого кода.
- И самое интересное и волнующее для меня — это размер команды: 71% опрошенных работают в командах до 12 человек.
👍5❤2🔥1
Метрики эффективности спринта.
Летом 2024 года, когда все были в отпусках, у меня выдалось две относительно свободные недели. Передо мной стояла задача подумать над тем, как можно оценить работу команд, которые делают Ecom в ЗЯ. Не с целью найти слабых, а скорее понять, что где как поломано, работает плохо или не работает вообще. Не помню как, но сначала я наткнулся на этот плагин для grafana, а затем на эту статью от Skyeng на Habr. И понеслось...
Я загорелся идеей на основе непосредственных данных из базы Jira построить ряд дешбордов для оценки как классических метрик типа TimeToMarket / LeadTime / CycleTime, так и метрик эффективности спринта.
Что такое вообще метрики эффективности спринта? Опять же, есть множество способов измерить спринт. На эту тему мне очень нравится вот этот доклад на PodlodkaTeamLeadCrew#12 от Avito. Но если не погружаться в академические тонкости, и строить что-то свое на коленке, то это % того, что команда сделала относительно того, что она обещала сделать.
Что значит «сделала»? Что значит «обещала сделать»? Сейчас постепенно команды переходят на планирование спринта в сторях, где каждая сторя — это некая цель спринта. Все, что не сторя, менее важно. Процент выполненных сторей и является той эффективностью спринта, которую мы ищем. Я прекрасно понимаю, что любую метрику можно «похачить», например, декомпозировав эпик на стори так, что они будут закрываться, но при этом фича не будет двигаться к завершению. Считаем, что осознанно «хачить» никто не будет, если будет, то нам с такими не по пути.
На скрине спринт одной из команд, где я ВРИО тимлида, команда запланировала 12 сторей (целей), закрыла за сам спринт 9, то есть 75%. Уже чуть позже, в самом начале следующего спринта, еще 2 стори, то есть 91%. Но итоговый результат мы считаем 75%.
Если говорить о каких-то выводах, то основное, и, наверное, в чем-то стыдное и банальное, — это фокусировка команды на целях спринта, оформленных так, чтобы это было визуально максимально понятно и прозрачно видно на Scrum-доске, например, в виде swimlane'ов.
Летом 2024 года, когда все были в отпусках, у меня выдалось две относительно свободные недели. Передо мной стояла задача подумать над тем, как можно оценить работу команд, которые делают Ecom в ЗЯ. Не с целью найти слабых, а скорее понять, что где как поломано, работает плохо или не работает вообще. Не помню как, но сначала я наткнулся на этот плагин для grafana, а затем на эту статью от Skyeng на Habr. И понеслось...
Я загорелся идеей на основе непосредственных данных из базы Jira построить ряд дешбордов для оценки как классических метрик типа TimeToMarket / LeadTime / CycleTime, так и метрик эффективности спринта.
Что такое вообще метрики эффективности спринта? Опять же, есть множество способов измерить спринт. На эту тему мне очень нравится вот этот доклад на PodlodkaTeamLeadCrew#12 от Avito. Но если не погружаться в академические тонкости, и строить что-то свое на коленке, то это % того, что команда сделала относительно того, что она обещала сделать.
Что значит «сделала»? Что значит «обещала сделать»? Сейчас постепенно команды переходят на планирование спринта в сторях, где каждая сторя — это некая цель спринта. Все, что не сторя, менее важно. Процент выполненных сторей и является той эффективностью спринта, которую мы ищем. Я прекрасно понимаю, что любую метрику можно «похачить», например, декомпозировав эпик на стори так, что они будут закрываться, но при этом фича не будет двигаться к завершению. Считаем, что осознанно «хачить» никто не будет, если будет, то нам с такими не по пути.
На скрине спринт одной из команд, где я ВРИО тимлида, команда запланировала 12 сторей (целей), закрыла за сам спринт 9, то есть 75%. Уже чуть позже, в самом начале следующего спринта, еще 2 стори, то есть 91%. Но итоговый результат мы считаем 75%.
Если говорить о каких-то выводах, то основное, и, наверное, в чем-то стыдное и банальное, — это фокусировка команды на целях спринта, оформленных так, чтобы это было визуально максимально понятно и прозрачно видно на Scrum-доске, например, в виде swimlane'ов.
👍8❤2👌2
Нашел в своих старых заметках опросник, через который я прогонял кандидатов в свою команду во время работы в ostrovok.ru. Спустя 8 лет некоторые вопросы всё ещё кажутся актуальными.
Что ты будешь делать, если задача, поставленная перед тобой, плохо описана?
1. спрошу у лида
2. верну задачу обратно в пул со статусом need info
3. отвечу на свои вопросы сам и сделаю так, как считаю правильным
Ожидаемый ответ: 1 или 1/3
Что ты будешь делать, если у тебя кончатся задачи в спринте?
1. ничего
2. займусь самообучением/самообразованием
3. возьму сам задачи из бэклога
4. спрошу у лида
5. посмотрю, что у нас с техническим долгом, и постараюсь закрыть его
Ожидаемый ответ: 3 или 4 или 5
Если тебе что-то непонятно, то ты спросишь у лида или попробуешь разобраться сам?
1. буду стараться разобраться сам, пока не сдамся
2. попробую быстро разобраться сам, если не получится, спрошу у лида
3. сразу спрошу у лида, тк это будет быстро и эффективно
Ожидаемый ответ: 1 или 2
Для разработки фичи нужна помощь разработчика из другой команды. Сегодня он работает удаленно, а фичу хочется начать делать уже сегодня. Что делать?
1. постараюсь четко сформулировать свой вопрос и задать его в корпоративном мессенджере. Буду надеяться, что получу полный ответ
2. предложу пообщаться с коллегой голосом в Skype
3. дождусь завтра, когда он будет в офисе, а пока займусь другими задачами
4. спрошу у лида
Ожидаемый ответ: 1 или 2
Собрали релиз, в который вошло множество фич, багфиксов и рефакторинга. Поняли, что в релизе есть новый баг, который затрагивает менее 1% пользователей. Что делать?
1. будем фиксить, снова все тестировать, в итоге отложим релиз на 1–2 дня, а возможно и больше
2. катим, но сразу фиксим и готовим новый релиз
Ожидаемый ответ: 2
Как лучше поступить при написании новой фичи в текущем большом проекте?
1. начну сразу делать фичу, после ее разработки/внедрения буду рефакторить проект
2. проведу небольшой рефакторинг, потом сразу буду делать фичу
3. буду рефакторить, пока не пойму, что код новой фичи хорошо ложится в текущий проект
Ожидаемый ответ: 2 или 3
Микросервис, с которым взаимодействует твой проект, изменил что-то в текущей интеграции по API, тем самым сломав ее. Изменения небольшие, и ты можешь сам пофиксить проблему на своей стороне. Что делать?
1. напишу ребятам, что они все сломали, и пусть чинят
2. напишу ребятам, что они все сломали, но починю у себя, тк это быстрее
Ожидаемый ответ: 2
Буквально вчера вышла новая версия языка, на котором написан твой проект. В ней есть множество киллер-фич, которые тебе очень нужны, но просто так обновиться нельзя, так как есть легаси-библиотеки, которые ее не поддерживают. Что делать?
1. всё, пора! Хватит это терпеть! Буду просить у лида время на обновление до новой версии
2. 5 лет терпели и еще 5 потерпим, а потом уже и работу сменю
Ожидаемый ответ: 1
Что ты будешь делать, если задача, поставленная перед тобой, плохо описана?
1. спрошу у лида
2. верну задачу обратно в пул со статусом need info
3. отвечу на свои вопросы сам и сделаю так, как считаю правильным
Что ты будешь делать, если у тебя кончатся задачи в спринте?
1. ничего
2. займусь самообучением/самообразованием
3. возьму сам задачи из бэклога
4. спрошу у лида
5. посмотрю, что у нас с техническим долгом, и постараюсь закрыть его
Если тебе что-то непонятно, то ты спросишь у лида или попробуешь разобраться сам?
1. буду стараться разобраться сам, пока не сдамся
2. попробую быстро разобраться сам, если не получится, спрошу у лида
3. сразу спрошу у лида, тк это будет быстро и эффективно
Для разработки фичи нужна помощь разработчика из другой команды. Сегодня он работает удаленно, а фичу хочется начать делать уже сегодня. Что делать?
1. постараюсь четко сформулировать свой вопрос и задать его в корпоративном мессенджере. Буду надеяться, что получу полный ответ
2. предложу пообщаться с коллегой голосом в Skype
3. дождусь завтра, когда он будет в офисе, а пока займусь другими задачами
4. спрошу у лида
Собрали релиз, в который вошло множество фич, багфиксов и рефакторинга. Поняли, что в релизе есть новый баг, который затрагивает менее 1% пользователей. Что делать?
1. будем фиксить, снова все тестировать, в итоге отложим релиз на 1–2 дня, а возможно и больше
2. катим, но сразу фиксим и готовим новый релиз
Как лучше поступить при написании новой фичи в текущем большом проекте?
1. начну сразу делать фичу, после ее разработки/внедрения буду рефакторить проект
2. проведу небольшой рефакторинг, потом сразу буду делать фичу
3. буду рефакторить, пока не пойму, что код новой фичи хорошо ложится в текущий проект
Микросервис, с которым взаимодействует твой проект, изменил что-то в текущей интеграции по API, тем самым сломав ее. Изменения небольшие, и ты можешь сам пофиксить проблему на своей стороне. Что делать?
1. напишу ребятам, что они все сломали, и пусть чинят
2. напишу ребятам, что они все сломали, но починю у себя, тк это быстрее
Буквально вчера вышла новая версия языка, на котором написан твой проект. В ней есть множество киллер-фич, которые тебе очень нужны, но просто так обновиться нельзя, так как есть легаси-библиотеки, которые ее не поддерживают. Что делать?
1. всё, пора! Хватит это терпеть! Буду просить у лида время на обновление до новой версии
2. 5 лет терпели и еще 5 потерпим, а потом уже и работу сменю
👍9❤1🔥1👌1
Пока кто-то сокращает, мы нанимаем, открываем новые направления и рынки для бизнеса.
Новости на этой неделе.
- На рынке говорят о том, что крупные компании сокращают штат IT-шников. А ритейлер «Золотое Яблоко», наоборот, рассказал о планах нарастить пул таких специалистов.
- С массовыми сокращениями не всё так плохо — обнаружил, что в Золотом Яблоке открыто 30 вакансий, на которые планируют нанять 150 (!) человек.
- "Золотое Яблоко" планирует расширить штат IT-специалистов на 25%. Кажется, ритейлер готовится к серьёзному усилению в диджитале.
- «Золотое Яблоко» расширяет ИТ-штат на 25%
- «Золотое Яблоко» на четверть увеличит штат IT-специалистов
Чтобы вам было проще, вот мои вакансии в Ecom или пишите мне (@arxell) c ссылкой или c файлом на ваш CV, я перешлю кому надо.
- ios / android
- Middle .NET developer / Senior .Net developer
- Middle Fullstack QA / Senior Fullstack QA
- Системный аналитик
- Frontend developer Vue
Также ищем TeamLead'ов команд разработки, которые отвечают за delivery-процесс в своей команде по доставке ценностей для клиентов, метрики, планирование т.д. и т.п. что описано тут.
Новости на этой неделе.
- На рынке говорят о том, что крупные компании сокращают штат IT-шников. А ритейлер «Золотое Яблоко», наоборот, рассказал о планах нарастить пул таких специалистов.
- С массовыми сокращениями не всё так плохо — обнаружил, что в Золотом Яблоке открыто 30 вакансий, на которые планируют нанять 150 (!) человек.
- "Золотое Яблоко" планирует расширить штат IT-специалистов на 25%. Кажется, ритейлер готовится к серьёзному усилению в диджитале.
- «Золотое Яблоко» расширяет ИТ-штат на 25%
- «Золотое Яблоко» на четверть увеличит штат IT-специалистов
Чтобы вам было проще, вот мои вакансии в Ecom или пишите мне (@arxell) c ссылкой или c файлом на ваш CV, я перешлю кому надо.
- ios / android
- Middle .NET developer / Senior .Net developer
- Middle Fullstack QA / Senior Fullstack QA
- Системный аналитик
- Frontend developer Vue
Также ищем TeamLead'ов команд разработки, которые отвечают за delivery-процесс в своей команде по доставке ценностей для клиентов, метрики, планирование т.д. и т.п. что описано тут.
🔥7❤5💅4✍2🤡2😍2🎉1
Про гигиенический минимум.
Мне раньше было смешно, когда я видел в резюме у кандидатов среди навыков пункты Jira/Confluence. Что же такого особенного надо уметь, чтобы заявлять это как навыки в своём резюме, — думал я.
Прошло время, и мне стало грустно, тк сейчас мне начинает казаться, что работу с таск-трекером как навык надо внести в гигиенический минимум при найме в IT-компании.
Не понимаю, как можно не уметь делать простейшие вещи в Jira, типа создания Story и привязки к ней задач или хотя бы просто сделать существующую задачу подзадачей (сабтаской) у Story. Это же база!
Сейчас, на фоне сокращений в РФ, я точно убеждён, что время кодеров прошло — они никому не нужны, как те самые валенки в углу. Нужны инженеры, которые умеют ставить себе задачи, описывать их, программировать их, писать к ним тесты, оставлять в каком-то виде после себя документацию, проверять, что happy-кейсы проходят, и релизить в prod.
Принцип «Швейцарского ножа» актуален как никогда.
Мне раньше было смешно, когда я видел в резюме у кандидатов среди навыков пункты Jira/Confluence. Что же такого особенного надо уметь, чтобы заявлять это как навыки в своём резюме, — думал я.
Прошло время, и мне стало грустно, тк сейчас мне начинает казаться, что работу с таск-трекером как навык надо внести в гигиенический минимум при найме в IT-компании.
Не понимаю, как можно не уметь делать простейшие вещи в Jira, типа создания Story и привязки к ней задач или хотя бы просто сделать существующую задачу подзадачей (сабтаской) у Story. Это же база!
Сейчас, на фоне сокращений в РФ, я точно убеждён, что время кодеров прошло — они никому не нужны, как те самые валенки в углу. Нужны инженеры, которые умеют ставить себе задачи, описывать их, программировать их, писать к ним тесты, оставлять в каком-то виде после себя документацию, проверять, что happy-кейсы проходят, и релизить в prod.
Принцип «Швейцарского ножа» актуален как никогда.
GitHub
arxell/playbook/engineering_culture.md at main · arxell/arxell
Contribute to arxell/arxell development by creating an account on GitHub.
🤡12💯12👍8🔥3❤2
Небольшой красоты пост.
Впереди гендерные праздники: 14/23 февраля и 8 марта.
Порадовать свою вторую половину, маму, папу, брата или сестру можно, подарив электронную подарочную карту ЗЯ с уникальным дизайном, созданным непосредственно вами с помощью нейросети.
Пример запроса
Сам запрос, кстати, можно тоже сгенерировать через AI (chatgpt). Я запросил так:
и получил то, что выше. Вот такой вот круговорот AI запросов в природе.
P.S.: ограничение 3 дизайна за 2 часа, будьте аккуратны в своих запросах =)
Впереди гендерные праздники: 14/23 февраля и 8 марта.
Порадовать свою вторую половину, маму, папу, брата или сестру можно, подарив электронную подарочную карту ЗЯ с уникальным дизайном, созданным непосредственно вами с помощью нейросети.
Пример запроса
молодая пара держится за руки в красивом парке, вокруг цветущие деревья с сердечными листьями. На переднем плане корзинка с цветами и открытками в форме сердец. Небо окрашено в розово-фиолетовые оттенки захода солнца, сверху летят маленькие купидоны с луками
Сам запрос, кстати, можно тоже сгенерировать через AI (chatgpt). Я запросил так:
Напиши запрос для генерации картинки для 14 февраля
и получил то, что выше. Вот такой вот круговорот AI запросов в природе.
P.S.: ограничение 3 дизайна за 2 часа, будьте аккуратны в своих запросах =)
🔥7❤5👍5
Гибко или строго?
Вроде бы простой вопрос. В такой формулировке гибкость звучит как очевидный правильный ответ, тк гибкость подразумевает скорость. Так ли это? Всегда ли гибкость дает скорость, а строгость замедляет?
Если задуматься об этом вопросе на примере конфигурации backend-сервисов, где есть скажем два варианта:
A) динамическое конфигурирование сервисов в runtime
B) конфигурирование через YAML-конфиги с последующим деплоем
то кажется, что динамическая конфигурация в runtime будет быстрее.
Да, если речь идет о разовом изменении, то вариант A будет быстрее, но дьявол, как всегда, кроется в деталях. Я строго убежден, что варианты типа A в том или ином виде накапливают большой технический долг по сравнению с вариантами типа B, что в итоге на длительной дистанции приводит к драматическому замедлению скорости разработки.
Попробую, попытаюсь объяснить. В IT уже давно решён вопрос хранения кода. Кстати, вот отличная статья на эту тему. Сейчас разработчик всегда может посмотреть историю жизни каждой строчки кода в своем проекте, так как git всё помнит. Всегда можно откатиться к предыдущей версии, понять, что было тогда, что было где-то посередине, и как всё выглядит сейчас. Понятно кто/что/как/когда изменил, есть связь с задачей в таск-трекером, а CI/CD обеспечивает проверку каждого этапа изменения и связи изменения с номером сборки и релиза. Это в совокупе дает максимальную прозрачность и явность в изменениях. Конфигурация — это такой же "код", как и код, написанный на условном Python/Golang/C#/Java/..., если к конфигурации относиться как к коду, то на долгой дистанции это уменьшает количество тупых багов, инцидентов и неконтролируемых изменений, которые съедают кучу времени у команды разработки.
Другое дело, что если CI/CD медленный или нет возможности самостоятельно раскатывать свои backend-релизы, то разработчики по пути наименьшего сопротивления будут искать лазейки, чтобы менять конфиги динамически, без изменения их в YAML-файлах. Это уже вопросы к зрелости инфраструктуры, DevOps-процессов и качеству CI/CD. Иными словами, если у меня, как у разработчика, от мержа ветки с изменениями в master до раскатки на prod-стенд проходит 3–5 минут, то о динамической конфигурации мне и думать нет смысла.
P.S.: фичефлаги и АБтесты это не конфигурация!
Вроде бы простой вопрос. В такой формулировке гибкость звучит как очевидный правильный ответ, тк гибкость подразумевает скорость. Так ли это? Всегда ли гибкость дает скорость, а строгость замедляет?
Если задуматься об этом вопросе на примере конфигурации backend-сервисов, где есть скажем два варианта:
A) динамическое конфигурирование сервисов в runtime
B) конфигурирование через YAML-конфиги с последующим деплоем
то кажется, что динамическая конфигурация в runtime будет быстрее.
Да, если речь идет о разовом изменении, то вариант A будет быстрее, но дьявол, как всегда, кроется в деталях. Я строго убежден, что варианты типа A в том или ином виде накапливают большой технический долг по сравнению с вариантами типа B, что в итоге на длительной дистанции приводит к драматическому замедлению скорости разработки.
Попробую, попытаюсь объяснить. В IT уже давно решён вопрос хранения кода. Кстати, вот отличная статья на эту тему. Сейчас разработчик всегда может посмотреть историю жизни каждой строчки кода в своем проекте, так как git всё помнит. Всегда можно откатиться к предыдущей версии, понять, что было тогда, что было где-то посередине, и как всё выглядит сейчас. Понятно кто/что/как/когда изменил, есть связь с задачей в таск-трекером, а CI/CD обеспечивает проверку каждого этапа изменения и связи изменения с номером сборки и релиза. Это в совокупе дает максимальную прозрачность и явность в изменениях. Конфигурация — это такой же "код", как и код, написанный на условном Python/Golang/C#/Java/..., если к конфигурации относиться как к коду, то на долгой дистанции это уменьшает количество тупых багов, инцидентов и неконтролируемых изменений, которые съедают кучу времени у команды разработки.
Другое дело, что если CI/CD медленный или нет возможности самостоятельно раскатывать свои backend-релизы, то разработчики по пути наименьшего сопротивления будут искать лазейки, чтобы менять конфиги динамически, без изменения их в YAML-файлах. Это уже вопросы к зрелости инфраструктуры, DevOps-процессов и качеству CI/CD. Иными словами, если у меня, как у разработчика, от мержа ветки с изменениями в master до раскатки на prod-стенд проходит 3–5 минут, то о динамической конфигурации мне и думать нет смысла.
P.S.: фичефлаги и АБтесты это не конфигурация!
Хабр
История систем управления версиями
В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список): Первое поколение SCCS (Source Code Control System) RCS (Revision...
👍3
6 месяцев с iPhone
Так получилось, что я всегда пользовался Android: HTC Hero -> HTC Legend -> Nexus 5/5X -> Samsung S19/S20/S22. Наверное, было что-то еще, но я уже не вспомню, а история с iPhone у меня как-то не завелась еще с ВУЗа. Я давно хотел iPhone, но отсутствие USB-C мне не давало покоя, и я ждал. Дождался, этим летом (2024) мне подарили iPhone 15 Pro Max, и это стало разочарованием.
Если отбросить весь текущий контекст санкций и отсутствие удобного способа установки банковских приложений, VPN и Apple Pay, мне все равно непонятны две вещи: нет нормальной кнопки «Назад» и долгие анимации там, где они не нужны. Еще я так и не смог разобраться с заменой клавиатуры Apple на Gboard, она вроде как работает, но периодически все равно открывается стандартная клавиатура Apple, которая меня жутко бесит (субъективно, конечно, но все же).
В итоге я вернулся на новый Samsung S25 и бесконечно этому рад. Видимо, это как вопрос кошек и собак, яблок и груш, красного и белого, темного и светлого, те каждому свое.
Так получилось, что я всегда пользовался Android: HTC Hero -> HTC Legend -> Nexus 5/5X -> Samsung S19/S20/S22. Наверное, было что-то еще, но я уже не вспомню, а история с iPhone у меня как-то не завелась еще с ВУЗа. Я давно хотел iPhone, но отсутствие USB-C мне не давало покоя, и я ждал. Дождался, этим летом (2024) мне подарили iPhone 15 Pro Max, и это стало разочарованием.
Если отбросить весь текущий контекст санкций и отсутствие удобного способа установки банковских приложений, VPN и Apple Pay, мне все равно непонятны две вещи: нет нормальной кнопки «Назад» и долгие анимации там, где они не нужны. Еще я так и не смог разобраться с заменой клавиатуры Apple на Gboard, она вроде как работает, но периодически все равно открывается стандартная клавиатура Apple, которая меня жутко бесит (субъективно, конечно, но все же).
В итоге я вернулся на новый Samsung S25 и бесконечно этому рад. Видимо, это как вопрос кошек и собак, яблок и груш, красного и белого, темного и светлого, те каждому свое.
💯10🤝9👍6
Про выбор адреса.
Решил, что пора понемногу освещать технологические проблемы, которые мы решаем в ЗЯ. Сегодня расскажу про вопрос выбора адреса. Вроде бы простой вопрос, но на самом деле нет, когда вы международная компания, представленная в разных регионах мира.
Легко ли выбрать адрес? Спроси меня об этом год назад, я бы с уверенностью ответил «да», но сейчас я скажу «нет».
Мы работаем с разными провайдерами адресов: Yandex, Google, Dadata, Mappable. Обусловлено это тем, что в разных регионах и странах разные провайдеры имеют разное качество геоданных, и нельзя условно везде использовать Google. Все усложняется, когда для клиента в стране мы используем Google, тк считаем, что он дает лучшее качество адреса, а курьеры используют Yandex просто потому, что привыкли.
Особенности между геопровайдерами
- разные форматы ID;
- разные ID ведут к одному адресу (например, в саджесте и геокоде);
- разная детализация адреса;
- разное тегирование элементов адреса (в Yandex много промежуточных компонентов между регионом и населенным пунктом обозначается как district. У Google больше возможностей показать детали адреса с различающимися тегами).
В зависимости от региона – разное качество данных
- МЕ: у некоторых адресов в раскладке отсутствует населенный пункт, т.е. здания принадлежат уровню выше (например, региону), также из-за специфики региона;
- KZ (Google): многие дома не определяются, некорректная нумерация домов (на других картах адрес ведет в другое место), старые данные в наименованиях (с 2006 года уже есть новые сведения);
- АЕ (Google): новые районы города (Дубай) не определяются по подсказкам, обратному геокодированию;
- SA (Google): по некоторым областям со спутника видны пустыри в чертах населенного пункта, но на схеме оказывается район с домами. Медленная скорость актуализации геоданных;
- SA (Mappable): по тем же областям с пустырями есть соответствие спутника и схемы, т.е. зданий реально нет, там пусто;
- РФ (Dadata): точность ФИАС до улицы при наличии дома и координат до дома (при этом адрес реально существует) – по ФИАСу адреса восстановиться может только до улицы; можно придумывать названия домов, строений, корпусов – Dadata выводит такое как реальную подсказку, однако точность координат и ФИАСа падает уже, например, до улицы; в Dadata один тип улицы, в Яндексе другой (например, станция против улицы). У Dadata источником являются местные органы самоуправления, предоставляющие адресную информацию.
Лично для меня было новостью, что в AE, в частности в Дубае, у домов может не быть названий улиц, и это совершенно нормально. Все в основном ориентируются по номерам домов.
Решил, что пора понемногу освещать технологические проблемы, которые мы решаем в ЗЯ. Сегодня расскажу про вопрос выбора адреса. Вроде бы простой вопрос, но на самом деле нет, когда вы международная компания, представленная в разных регионах мира.
Легко ли выбрать адрес? Спроси меня об этом год назад, я бы с уверенностью ответил «да», но сейчас я скажу «нет».
Мы работаем с разными провайдерами адресов: Yandex, Google, Dadata, Mappable. Обусловлено это тем, что в разных регионах и странах разные провайдеры имеют разное качество геоданных, и нельзя условно везде использовать Google. Все усложняется, когда для клиента в стране мы используем Google, тк считаем, что он дает лучшее качество адреса, а курьеры используют Yandex просто потому, что привыкли.
Особенности между геопровайдерами
- разные форматы ID;
- разные ID ведут к одному адресу (например, в саджесте и геокоде);
- разная детализация адреса;
- разное тегирование элементов адреса (в Yandex много промежуточных компонентов между регионом и населенным пунктом обозначается как district. У Google больше возможностей показать детали адреса с различающимися тегами).
В зависимости от региона – разное качество данных
- МЕ: у некоторых адресов в раскладке отсутствует населенный пункт, т.е. здания принадлежат уровню выше (например, региону), также из-за специфики региона;
- KZ (Google): многие дома не определяются, некорректная нумерация домов (на других картах адрес ведет в другое место), старые данные в наименованиях (с 2006 года уже есть новые сведения);
- АЕ (Google): новые районы города (Дубай) не определяются по подсказкам, обратному геокодированию;
- SA (Google): по некоторым областям со спутника видны пустыри в чертах населенного пункта, но на схеме оказывается район с домами. Медленная скорость актуализации геоданных;
- SA (Mappable): по тем же областям с пустырями есть соответствие спутника и схемы, т.е. зданий реально нет, там пусто;
- РФ (Dadata): точность ФИАС до улицы при наличии дома и координат до дома (при этом адрес реально существует) – по ФИАСу адреса восстановиться может только до улицы; можно придумывать названия домов, строений, корпусов – Dadata выводит такое как реальную подсказку, однако точность координат и ФИАСа падает уже, например, до улицы; в Dadata один тип улицы, в Яндексе другой (например, станция против улицы). У Dadata источником являются местные органы самоуправления, предоставляющие адресную информацию.
Лично для меня было новостью, что в AE, в частности в Дубае, у домов может не быть названий улиц, и это совершенно нормально. Все в основном ориентируются по номерам домов.
👍9😁3🔥2🤔1