В какие города можно улететь из парижа paris и сколько времени это займет sql

Какие города мира сравнимы с качеством и цифровизацией сервиса в Москве?

Давайте попробуем обсудить и собрать какими сервисами и в каких городах можно гордится с точки зрения удобства и мобильности.

Кто жил в Москве последние годы, тот знает, что она соблязняла гостей и жителей тем, что можно было пешком или на такси добраться круглосуточно до ресторана или супермаркета в любой день недели. Лавка за пять минут приносила мороженку в 3 часа ночи в понедельник.

Я понял, что при выборе города, который я хочу сделать своим домом, мне важно какие удобства он предоставляет. Чтобы в идеале вообще не надо было шевелиться, а тебе всё в рот на серебряной ложечке клали.

Вот сферы, которые я вспомнил. Напомню, что оцениваем по удобству (скорость, время работы, дизайн, UX, CX) и цифровизации.

• Медицина и анализы
• Страхование
• Еда нерегулярная
• Еда регулярная
• Продукты
• Аптеки и лекарства
• Деньги и банковские продукты
• Тревел
• Каршеринг
• Такси
• Доставка документов и посылок
• Переезд и хранение вещей
• Аренда двухколесных средств передвижения
• Ивенты и концерты
• Нетворкинг и дейтинг

Пишите лучший город с этой точки зрения, его сервисы и примеры сервисов отдельных в других местах.

Евгений Зубак 8 апреля 2022

Связанные посты

Soslan Chekhov Product lead 9 апреля 2022

А может кто-то рассказать про азиатские города в таком же формате ? Например, Сингапур или Бангкок

p.s. @zubak , буквально вчера вечером меня посещали ровно такие же мысли и я думал запилить такой же пост. Спасибо 🙂

Катерина учу машины 8 апреля 2022

Давно хотела развенчать вредный миф, распространённый, судя по всему, жителями Германии, о том, что в Европах нет цифровизации 😀

Итак, я живу в Хельсинки, и тут:

• Абсолютно всё, связанное с государством, делается в один клик и почти без посещений бюрократов. Когда я переехала, я оформила все документы за полтора месяца, причём из этого времени большую часть я ждала пока моя запись подойдёт. Пару вопросов решила вообще по телефону. Ходила куда вроде три раза, из которых один раз был в банк.
• Во все государственные сервисы есть единый вход, привязанный к банковскому аккаунту. Не в половину, не в треть, как с госуслугами, а во все: почта, магистрат, запись на вакцинацию, запись ко врачу, что угодно ещё.
• Я пользуюсь ОП-банком и после последнего обновления, прости господи, Тинькова, он мне нравится даже больше. Инвестиции, страхование — всё внутри приложения. Есть минусы, например, нельзя вклад без похода в офис (вроде бы) открыть (возможно, что можно в финноязычной версии приложения, у меня-то на английском), но в целом банк почти на уровне российского сервиса.
• Две доставки еды (готовой и из супермаркета). Дороговато, бесплатных доставок в принципе нет, но я раз-два в неделю пользуюсь.
• Я не пользуюсь обычной медициной, к сожалению, у меня occupational 🙁 Но он есть почти у всех, а у айтишников совершенно точно у всех. Запись ко врачу в один клик в тот же день. К специалисту напрямую не запишешься, надо через терапевта, это минус, да.
• Аптеки и лекарства, опять же, большого опыта не было, но коллеги объясняют так: до 50€ в месяц за выписанные (!) лекарства платишь сам. Дальше платит Кела (государство). В аптеку приходишь, показываешь айдишник, и они видят что тебе прописали. Все рецепты, прививки, посещения врача и т.д. хранятся в специальном сервисе, куда заходишь через тот единый вход, привязанный к айдишнику. Не-прописанные лекарства я редко покупаю, но от укачивания и головной боли продают без проблем 🙂
• Аренда. Я арендую квартиру от Lumo, всё онлайн. Просто бронишь хату на сайте, оплачивешь месяц вперёд (без залога, если ты у них уже снимал, с минимальным залогом ~300€, если нет), приходишь смотреть. Нравится — заезжаешь, не нравится — оплата возвращается. Вызов сантехника через их сайт опять же. Но Lumo из-за такого сервиса дороже среднего по больнице.

И т.д. и т.п., по уровню комфорта Хельсинки просто небо и земля по сравнению с Москвой (я три года там прожила). Я в страшном сне себе жизнь московскую вспоминаю после такого ��

Развернуть 1 комментарий

@tamamolis, я называю этот вредный миф «обобщать немецкие реалии на всю невероятно разнообразную Европу (ну или Евросоюз)»

Развернуть 1 комментарий

@tamamolis, даже боюсь спросить, что такого страшного было в Мск, что в страшном сне вспоминаете.
p.s. с Хельсинки не был, но уже хочу побывать.

Развернуть 1 комментарий

@roma_ds, ну, основная проблема в том, что у меня не было дохода в 300 какосеков 😀 У меня была хорошая зарплата, но на квартиру в Хамовниках никак не хватало (при желании откладывать хотя бы 20% зп). А жить за пределами ЦАО и комьютить в офис на Арбате на перекладных — это пиздец, и никакие доставки Яндекс.Еды этого не перекрывают.

При этом в Хельсинки я тоже жила на окраине (в предыдущей квартире), но такой жопной боли 40-минутные поездки в офис не вызывали по очень простым причинам: отсутствие турникетов, отсутствие рек из людей на вход-выход из метро, отсутствие ебучих рамочек, господи, как я их ненавидела. Отсутствие ебаных подземных переходов через восьмиполосное Садовое. Я пока не переехала, даже не думала о том, как много это приносит боли и стресса и сколько времени пожирает.

Я с радостью тусуюсь в Москве во время поездок домой, гоняю там на такси из одного конца города в другой за 10€ и т.д., а потом с такой же радостью оттуда сматываюсь 😀 Ни за что не вернусь, уж лучше в Казань или в Питер.

Развернуть 1 комментарий

@roma_ds, у меня есть история про Москву. Хотел я налоги заплатить, пошёл в налоговую, отстоял очередь (минут 40).
Мне говорят есть на выбор, можно прям ща заплатить или сделать кабинет налогоплательщика. Ну я думаю чего уж, заплачу сейчас, а заодно и кабинет сделаю. Стою 40 минут в другое окно где платить, там мне говорят надо кабинет, здесь нельзя заплатить сейчас, идите в другое окно кабинет заводить. Само собой опять номерок взял, стою. В том окне сидит мужик, говорит, а кабинет уже месяц не работает и показывает мне на мониторе SQL ошибки, вот вам номер (бумажка размером с большой палец), регулярно звоните и спрашивайте не заработал ли кабинет.
В общем так я и не заплатил налоги и не завел кабинет никогда, просто в налоговой целый день просидел зазря.
И такие вещи того или иного уровня происходили довольно часто.
Я уж не говорю про то что даже когда всё получается у всех такие рожи как-будто ты им должен абсолютно всё и ещё чуть-чуть.

Развернуть 1 комментарий

@tamamolis, спасибо за мнение.
никогда бы не подумал, что такие простые вещи могут превращать город в страшный сон

Развернуть 1 комментарий

@roma_ds, для меня Москва тоже страшный сон, сравнительно с Берлином. Вообще в Москве, когда я возвращалась из отпуска, я примерно неделю ещё приходила в себя и первые дни было очень депрессивное настроение. В Берлине наоборот — откуда бы ни вернулась, все время улыбка и радость. Но зависит конечно от района, где конкретно жить в Берлине.

Развернуть 1 комментарий

@tdurova, О, а в каком районе в Берлине лучше жить?

Развернуть 1 комментарий
Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий
Развернуть 1 комментарий

@rybnikov, все зависит от того, что тебе/вам надо. Еще очень сильно экспиренс зависит от дома / улицы / соседей. В целом я обычно смотрю на количество парков и спортивных объектов / Verein в пешей доступности.

Развернуть 1 комментарий

@tamamolis, «При этом в Хельсинки я тоже жила на окраине (в предыдущей квартире), но такой жопной боли 40-минутные поездки в офис не вызывали по очень простым причинам»

Похоже, что причины немного в другом :
Площадь Хельсинки : 213.8 km² (сопоставимо с Ярославлем :))
Площадь Москвы : 2,511 km²
Население Москвы : 12 млн (2012)
Население Хельсинки : 630 тыс (2016)

Развернуть 1 комментарий

@buloshnik, Хорошая попытка, но нет 🙂

Итак, во-первых в вашей статистике из википедии речь именно про Хельсинки. Но, вообще говоря, под Хельсинки часто подразумевают всю метрополию Хельсинки-Эспоо-Вантаа (т.к. жители пригородов тоже едут в центр работать), а это уже намноо-о-го большая площадь и больше миллиона жителей. Под окраиной Хельсинки я имела в виду как раз Вантаа, но не стала про это писать, чтобы не плодить сущностей. Под Москвой же как раз мало кто подразумевает всю Москву, включая Новую, скорее имеют в виду площадь внутри МКАДа, ну мне так кажется, по крайней мере.

Во-вторых, хорошо, давайте предметно. Какое-то время я жила в Москве в Долгопрудном (как раз у МКАДа), а работала на Владыкино, что хорошо сравнивается с домом на Тиккуриле и работой в Аалто по времени, более того, до Аалто ехать даже дальше и с пересадкой. Если посмотреть на карту, то от Новодачной до Окружной буквально 20 минут на электричке. На деле это 40 минут следующего пиздеца:

• Дойти от дома до платформы Новодачная по грязи в любое время года, кроме зимы, отстоять в очереди, купить билет на платформе. Почему так, почему не купить проездной? Потому что какого-то хрена студенческую скидку на билет можно получить только покупая одноразовые билеты, а автоматов на станции нет (не было раньше), только кассир. Поэтому стой в очереди и приплясывай при приближении электрички. Хорошо хоть турникетов там тоже нет (не было раньше) и сразу при получении билета можно бежать в закрывающуюся дверь вагона.
• Электрички ходят дай Бог каждые 10-15 минут в час пик и битком забиты. Вне часа пик 20-30.
• После прибытия на Окружную надо отстоять огромную очередь на выход, потому что там есть турникет и всем туда надо.
• Потом самое интересное — попытка дойти от Окружной до офиса, не нарушая правил и только на зелёный. Спойлер — это невозможно, тротуары кончаются в случайных местах и перетекают в газоны, пешеходных переходов просто нет в нужных местах. А сейчас там ещё и монструозную хорду строят, пиздец
• Самое бесячее — в Москве нет транспортных зон, но почти везде есть турникеты. Поэтому, если у тебя есть билет до Новодачной, тебе нельзя выйти на Долгопрудной, хотя билеты и стоят одинаково — турникет просто не откроется. Так что когда ты с утра стоишь в очереди за билетом с Новодачной на Окружную, ты не можешь купить билет туда-обратно на день, ведь на Новодачной останавливается только каждая третья электричка. И если ты обратишься к контролёру с просьбой открыть тебе турникет, ведь ты заплатил за билет, он скажет: ‘плати 200₽ за штрафной билет или прыгай с платформы’. И я щас не шучу, если что, мне так говорили много раз. Поэтому, идя домой из офиса, ты опять стоишь в очереди за билетом! Бинго!

Я могу ещё много чего вспомнить, причём про центр Москвы тоже. И не надо мне говорить, что это в МО, в Москве всё не так, потому что турникетов, рамочек, отсутствия проработки краевых случаев (как в случае со студенческими скидками на билеты) и прочего идиотизма в Москве хватает. Да и сравнение с Вантаа валидное.

Теперь посмотрим на мой комьют из Тиккурилы (Вантаа) в Аалто (Эспоо), через Хельсинки, который тоже включает в себя электричку:

• Выходишь из дома, по нормальной дорожке доходишь до платформы. На платформе нет крыс! Вау!
• Электрички ходят примерно каждые 5-10 минут, в час пик 5-8 (это хорошо ложится на вашу статистику по числу жителей). Вне часа пик 10-15.
• НИГДЕ НЕТ РАМОЧЕК И ТУРНИКЕТОВ
• ПЛАТФОРМА ВРОВЕНЬ С ЗЕМЛЁЙ, НЕ НАДО БЕЖАТЬ ПО ЛЕСТНИЦАМ/ЭСКАЛАТОРАМ/ETC
• Приходишь на платформу, видишь поезд, а билета нет? Не беда, просто покупаешь билет в приложении! Можешь это делать прямо в поезде перед контролёрами, им не важно когда был куплен билет, важно, чтобы он просто был.
• Билет не надо никуда прикладывать, просто показываешь в приложении, если спрашивают контролёры. Приложение топ, кстати говоря.
• Поезда свободные, даже в час пик я всегда сидела (сейчас корона типа кончилась, стало поплотнее, но всё равно сижу).
• Доезжая до вокзала, совершаешь подземный переход в метро без рамочек, без обходных путей, просто идёшь прямо в метро, вау, так что, можно было. Садишься на поезд и едешь. Другой билет тебе не нужен, ведь ты купил проездной на зоны и можешь пользоваться любым видом транспорта (Москва всё ещё до этого не дошла, да)!

Ну и так далее. Могу ещё много чего рассказать, но я и так сочинение уже накатала 🙂

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@tamamolis, по-моему Вам привели логическое объяснение описанной Вами ситуации.
«это уже намноо-о-го большая площадь и больше миллиона жителей» — в любом случае это мало меняет ситуацию. Берём Москву и её пригород и получаем более значимый прирост. Тут на глаза проблема «больших компаний», всё тоже самое, но в разрезе города. Если бы условным центром была бы Калуга, а не Москва — то и все работало бы куда лучше, потому что проще обслуживать/управлять/контролировать.
На мой скромный взгляд напрашивается такое объяснение Вашего представления о Москве: «ну, основная проблема в том, что у меня не было дохода в 300 какосеков :D» Если бы были — то и город показался другим 🙂
Я за несколько лет жизни в мск не столкнулся ни с одной из перечисленных Вами проблем. И я не говорю, что проблем нет, я говорю, что к ситуациям можно относиться по разному 🙂

Развернуть 1 комментарий

@buloshnik, Требование 300 какосеков для хорошей жизни означает, что в Москве постоянно сталкиваешься с людьми, которым неуютно, плохо, тяжело жить: уставшими, мрачными, отчаявшимися.

Это подавляет, и это никак меняется, пока полностью не изолируешься от социума, а в этом случае жизнь в Москве уже не нужна.

Развернуть 1 комментарий

@dottedmag, эм, я даже специально сейчас загуглил — 300кк/сек (произносится «какосек») — единица зарплаты айтишника.
Это не про людей, а про деньги)

Развернуть 1 комментарий

@buloshnik, Значит я плохо объяснил. Попробую ещё раз.

Пусть у нас есть город, в котором для комфортной жизни нужно 300 какосеков, и пусть эти 300 какосеков сильно выше медианной зарплаты (для Москвы выполняется).

Это будет означать, что больше половины жителей города не живут комфортно: им тяжело и неуютно, и это видно.

Если не замыкаться в своём маленьком пузыре, то придётся постоянно общаться с несчастными людьми (хотя бы потому, что сфера услуг будет наполнена ими). Это подавляет. Если замыкаться, то непонятно, зачем жить именно в Москве.

Личный пример: для меня самой большой неожиданностью в Осло (ничем не отличающегося от Хельсинки) стало то, что в нём водители автобусов и продавцы в супермаркетах — а у этих профессий низкие зарплаты — не выглядят несчастными. У них нет проблем, описанных @tamamolis выше. Город комфортен и для них.

Развернуть 1 комментарий

@dottedmag, да ты просто общайся с тем с кем комфортно. если тебе нравится с бомжами тусоваться — это отлично, не нравится — ходи в большой театр за 70к билет.
не можешь позволить? так это не проблема города.

живя в европейской дереве — ты замкнут. Только в большом городе у тебя есть выбор куда пойти. зарабатываешь 30кк или 1000кк выбор мест есть. А в деревне нет, там все одинаково бедные.

Развернуть 1 комментарий

@dottedmag, слушайте, ну Вот я был в Варшаве и количество недовольных ебальников в городе просто зашкаливало. Это не значит, что город не комфортный 🙂 и возьмем условный Брянск — столицу хиспстеров 😀 Где каждый второй рассекает по песочку в домашних тапочках и рваных трекошках с улыбкой до ушей.

Развернуть 1 комментарий

@roma_ds, вот уж с чем-чем, а с тем, что Хельсинки (если вы о нём) — деревня, я совершенно не согласна. Здесь на миллион жителей скалодромов больше, чем в Москве на десять миллионов, и по площади они все огромные, куча парков, два нацпарка в шаговой доступности, паромы в центре города и огромный аэропорт в 20 минутах от центра (здесь следует вспомнить о том куда сейчас и во время короны можно было улететь из Москвы). Про театры ничего не могу сказать, т.к. они на финском, но есть и шведский театр, и русский, музеев много, и они тоже ничего. Кстати говоря, мой самый любимый в России камерный театр и театральный фестиваль находятся в Воронеже, он по вашей классификации деревня или нет? Образование для резидентов на английском бесплатное, университеты известные, пиши мотивационное и поступай, а в России я своё однократное право на бесплатное образование уже истратила. Теннис, каякинг, яхтинг, сапы, конный спорт, whatever else, и всё это в нормальной доступности. Для себя я здесь вижу куда больше путей для развития, извините уж 🙂

Я не понимаю как можно делить города на ‘деревня/не деревня’ по уровню заёбанности жителя и баблу.

Развернуть 1 комментарий

@tamamolis, мне понравилась ваша фишка со скалодромами )))

вы простите, но если кататься на такси или своё авто, и ходить в приличные места — у людей нет заёбнности на лицах.
ну, а если по вокзалам бегать и в метро в час пик, то наверное. К счастью, давно там не был.

Развернуть 1 комментарий

@tamamolis, Катерина, Вы просто не видите как похорошела Москва при Собянине 😀
«каякинг, яхтинг, сапы, конный спорт» зачем все это, если есть плитка на дорогах и можно спокойной пешком добраться до работы?

Развернуть 1 комментарий

Если посмотреть на карту, то от Новодачной до Окружной буквально 20 минут на электричке.

Выглядит как МЦД-1. То есть весь головняк с оплатой и транспортными зонами по идее должен остаться только в воспоминаниях.

У меня была хорошая зарплата, но на квартиру в Хамовниках никак не хватало (при желании откладывать хотя бы 20% зп). А жить за пределами ЦАО и комьютить в офис на Арбате на перекладных — это пиздец

Хамовники переоценены и захайпованы. Но это не повод не жить в ЦАО 🙂 Я снимал однушку в 2018-2019 за 35т.р. рядом с Таганским парком, годный район, кольцевая ветка метро, час пешком до Кремля!

Развернуть 1 комментарий

@tamamolis, интересный текст про сравнение качества транспорта! Попытаюсь сравнить с городом, где живу — с Мюнхеном.

1. «Выходишь из дома, по нормальной дорожке. » Это есть, +.
2. «Электрички ходят примерно каждые 5-10 минут. «

Увы. S-Bahn, то есть аналог городских электричек, ходит раз в 20 минут (в т.ч. в час пик) и периодически опаздывает. Движение электричек можно видеть онлайн, но это не помогает тем, кто живёт далеко от платформы и уже доехал до неё на автобусе, а теперь смотрит в приложении, как задерживается поезд. Если же живёшь рядом, то да, можно выйти на конкретную электричку и не ждать.

В праздники, выходные не работают даже некоторые линии U-Bahn, то есть метро в core, основной части Мюнхена. Кроме того, некоторые ветки периодически ходят с интервалами 15-20 минут даже и без праздников, это зависит от ветки.

В соотношении с количеством жителей: реальный Мюнхен намного больше, чем формальные, сильно устаревшие границы города. Город плавно и незаметно перетекает в пригород, где есть только S-Bahn. Точно не помню цифры, но вроде получается примерно 1,5 млн города плюс 1,5 млн пригорода (поправьте, кто знает лучше).

1. «НИГДЕ НЕТ РАМОЧЕК И ТУРНИКЕТОВ» Здесь +

Считаю, что это в этом есть и минусы, потому что можно купить неправильный билет и обнаружить это только во время проверки контролёрами (они ходят регулярно).

Да и вообще, тут кому как — у меня например стресс от контролёров намного больше, чем от турникетов.

1. «ПЛАТФОРМА ВРОВЕНЬ С ЗЕМЛЁЙ» Нет, этого нет. Здесь обычные платформы, как в России. Присутствуют лифты, на которые часто очередь. Кстати до недавних пор даже в черте города были некоторые платформы без лифтов.
2. «Приходишь на платформу, видишь поезд, а билета нет? Не беда, просто покупаешь билет в приложении Можешь это делать прямо в поезде перед контролёрами, им не важно когда был куплен билет, важно, чтобы он просто был.»

Перед контролёрами вряд ли прокатит, хотя не пробовала. В целом да, тоже можно купить билет в приложении.

Что касается мск, то там в метро можно было оплачивать поездку банковской картой — это по сути то же самое, что оплата в приложении, даже быстрее. Но в электричках, мне кажется, такой возможности не было.

1. «Поезда свободные, даже в час пик я всегда сидела» Здесь не могу сказать, потому что Германия пока ещё не вышла полностью из коронавируса (ремоута), а я здесь не так давно живу.
2. «Доезжая до вокзала, совершаешь подземный переход в метро без рамочек, без обходных путей, просто идёшь прямо в метро, вау, так что, можно было. » См. пункт 3.
3. «Садишься на поезд и едешь. Другой билет тебе не нужен, ведь ты купил проездной на зоны и можешь пользоваться любым видом транспорта (Москва всё ещё до этого не дошла, да)!»

В Мюнхене тоже покупка билетов по зонам, здесь +.

Не уверена, что это принципиальное преимущество, потому что покупка билетов по зонам — это по сути покупка разных билетов. У меня ресурса затрачивается не меньше, чем покупка 2 отдельных билетов. Потому что я должна подумать, к каким зонам относятся мои точки назначения, и как вообще устроены зоны в этом городе (здесь например есть смешанные зоны). И исходя из этого, я покупаю билет в приложении.

Если бы мне нужно было два отдельных билета, я бы точно так же анализировала, к каким зонам они относятся, и просто делала бы не 1, а 2 покупки. Если можно покупать в приложении\оплачивать картой, то проблема больше в анализе местности, а не в нажатии кнопки «купить», ну это для меня так работает) Но если нужно физически покупать и стоять в очередях, то, разумеется, разница очевидна(((

PS А так вообще все слухи о недостатке цифровизации в Германии, на мой взгляд, полностью подтверждают себя, по крайней мере в Мюнхене.

Развернуть 1 комментарий

@tamamolis, мне нравится, как зональность работает в Лондоне.

зная, из какой зоны в какую едешь, знаешь заранее и стоимость, в которую тебе обойдется поездка. при этом никакого билета не покупаешь — прижимаешь телефон/проездной на входе и на выходе. ночью следующего дня с тебя спишут все, что нужно, причем могут применить и caps — «не заплатишь в день больше чем X при условии, что весь день ездил между зонами N и M». при этом взаимная интеграция различных видов транспорта (оверграунд/метро/электрички) очень высокая, пересадки и навигация супер изи.

при расчете твоей платы адекватно учтется даже если вдруг тебе пришлось выходить на улицу для пересадки — примерно как работал тариф на 90 минут в Москве.

а, ну и важно сказать, что, в отличие от Москвы и ее Тройки, стоимость оплаты картой/Apple Pay/Google/etc не отличается от проездного — как ни странно, одним из частных следствий из этого мне видится снижение очередей на вход/выход в транспорт, поскольку оплата и контроль упрощаются, нет ситуаций, когда вспоминаешь внезапно, что денег-то на тройке нету, и не тратишь время на очередь в кассу/автомат

отдельно обнимаю за РАМОЧКИ, господи, как же они бесили.

Развернуть 1 комментарий

@tamamolis, перечисленные сложности с электричками, пересадками и тротуарами — это проблема конкретно вашего маршрута. И похоже, что давно не пользовались. Потому что сейчас многое поменялось, например, интервалы в часы пик сейчас 5 мин. На моей линии ходят новые поезда Иволга и двухэтажные Аэроэкспрессы по цене обычной электрички. Почти всегда есть свободные места. Билет также можно купить в прилоении Яндекс.Электрички. Да, надо сканировать и проходить через Турникеты. Но Москва всё-таки не Хельсинки по количеству людей и майндсету пользователей электричек. Даже при наличии турникетов «зайцами» ездят многие.
Про автобусы тут тоже надо отметить — турникеты там убрали и теперь тоже свободный вход, оплачиваешь сам в терминале в автобусе.

Развернуть 1 комментарий

@tamamolis, классно, захотелось в Хельсинки =)

Развернуть 1 комментарий

@tamamolis, все подтверждаю. Только гос. медицинская страховка отстой полный, пробиться на прием очень сложно.

Развернуть 1 комментарий
Развернуть 1 комментарий

Лондон

NHS крайне противоречив (мое мнение: пиздец уровня «будете умирать, приходите», диагностика и превентивная медицина отсутствует, сходить «проверить спину» просто так нельзя, но если прийти к ним с пиздецом, то шансы хорошие). Но есть модные Thriva, телемеды и подобное.

Какие-то медстраховки дают работодатели, но они тоже завязаны на NHS зачастую. Вроде можно обойти как-то через телемед некоторые случаи, но все равно не близко к «алло запишите меня через час к неврологу в районе Хамовников».

Если есть деньги — все очень хорошо. Если есть много денег — лучше, чем в Москве.

Если про кафешки «на каждый день», то в среднем плохо. Есть неплохие места (мне нравились турецко-сирийско-иранские), но это все гораздо уступает Московскому Изобилию (с).

Отдельная грусть с кофейными сетями: на выбор Costa, Nero, Starbucks и Joe & Juice. По сравнению с ABC/Скуратов/Даблби/Surf это все как нескафе голд 3-в-1.

Ну и мне кажется в Лондоне у простого человека нет запроса на вкусную еду, норм навернуть фиш-н-чипс или пообедать холодным сандвичем из Теско.

В среднем очень хорошо, есть некоторые локальные моменты (типо отсутствие вкусного творога или доступных в супермаркетах стейков), но в среднем заметно лучше, чем в Москве. Правда и дороже.

NHS (при условии, что он сработает) дает все условно-бесплатно. В аптеках можно купить условный колдрекс и хлоргексидин. Антибиотики покупать нельзя.

Есть много необанков, но до покрытия Тинькофф им как до луны в известной позе.

Деньги я бы рекомендовал хранить/получать в банки-пердуны типо Lloyds, которые выглядят как Сбер в 2007, но свою работу выполняют.

Улететь можно куда угодно, Хитроу огромен, но надо учитывать, что британская рабочая виза не дает права путешествовать в Европу без виз.

Понятия не имею, мне кажется, такого либо нет, либо оно в зачаточном состоянии.

Есть дорогие кэбы, есть чуть менее дорогой Uber. Как в Москве кататься не получится, но до аэропорта можно спокойно доехать.

Доставка документов и посылок

Есть чудесный DPD, лучшая служба доставки в моей жизни. Есть червь-пидор Hermes, который обсирается в 4 случаях из 5. Как обычно, зависит.

Royal Mail после того, что сделали с Почтой России за последние 5 лет воспринимается как что-то из прошлого. Некоторые Post Office больше похожи на Африку. Но все возится/доставляется, не быстро, не всегда с первого раза, но терпимо.

Хз, я с чемоданом приехал. Увозил все через какую-то мутную компанию с сайтом на русском.

Аренда двухколесных средств передвижения

БОРИС БАЙКИ. Не пользовался, но стоят на каждом углу, выглядят примерно как ВТБ БАЙКИ в Москве.

Это же Лондон. Лучше только в Нью-Йорке может быть (и то для меня было бы хуже).

Зависит от окружности лица.

Развернуть 1 комментарий

@begor, Если будет фонд золотых цитат, то там точно будет — «Главное не быть круглолицым Ваньком» ��

Развернуть 1 комментарий

Евгений Зубак 8 апреля 2022 автор

@begor, если не лень будет, очень много пользы принеси, перечислив сервисы

Развернуть 1 комментарий

@begor, добавлю таки, что в Москве доступность докторов сильно нивелируется качеством тех самых докторов.

Я со своими проблемами с животом порядочно оббегал гастроэнтерологов, и почти все из них (из платных клиник, конечно же) ставили диагнозы и назначали лечение мало совместимые с современной медициной (диеты по певзнеру). Пришлось самому разбираться с взглядом современной медицины на мои проблемы и искать соответствующих врачей в Москве. К ним как раз запись была за неделю в лучшем случае, а то и за месяц 🙂

И ладно с обычным лечением, но что если будет серьезная пиздецома и придется вызывать скорую? Боюсь в таком случае выбирать не придется и тут уж как повезет.

Развернуть 1 комментарий

Я со своими проблемами с животом порядочно оббегал гастроэнтерологов, и почти все из них

Ну видишь, у тебя была возможность оббегать, а в Лондоне все закончится на терапевте, который попросит не есть острое и побольше двигаться, если ты вдруг не назовешь слова в том порядке, что у него в методичке (читай — не сгустишь тучи, прикинувшись полуживым, прям как в школе, когда выбивали освобождение) или просто ему покажется, что с тобой все ок и до пиздецомы лет 20.

А про качество докторов — вокруг меня были GP с индийскими, пакистанским и прочими дипломами. Я не думаю, что тут можно что-то говорить о качестве.

Недавно еще читал у @kureev очередную охуительную историю, как он за деньги, в частной лондонской клинике, чуть не лишился зрения в одном глазу. Представить себе такое в Москве я не могу со всем воображением.

Развернуть 1 комментарий

@begor, калшеринг в Лондоне есть и он ок, но у него немного своя специфика и он не так уж сильно заполнил улицы, как в Москве. Но это следствие того, что Лондон не выглядит сплошной парковкой, как Москва

Развернуть 1 комментарий

@Kirk, да, кстати, с машинами в Лондоне все сильно лучше, чем в Москве.

Развернуть 1 комментарий

@begor, с частной страховкой есть лайфхак, страховщики, конечно, просят referral от GP, но его не проверяют выдавая pre-authorisation («тут то мне карта и пошла»).
Самым честным это можно делать параллельно. GP первым делом надо сказать, что тебе нужен open referral for private insurance. У GP обычно немного времени на прием, после таких слов мне удавалось получать referral всегда.
Я правда, и стопу по NHS успел проверить по реферралу от GP. Получил совет поменять обувь, что и правда помогло 🙂

Развернуть 1 комментарий

Недавно открыл для себя Roasting Plant Coffee, их всего кажется 3 и расположены они не оч удобно, но есть один не оч далек от сити, там кофе правда максимально приближен по качеству к москвским кофейням, ещё и большой выбор зёрен и всё так очень фэнси

Развернуть 1 комментарий

@kirizhik, круто, обязательно зайду следующий раз в Лондоне!

Мне еще недавно посоветовали Omotesando Koffee, эти прям в W1.

Развернуть 1 комментарий

@kirizhik, (как хорошо что есть сабтред по кофе) максимум рекомендасьон black sheep coffee, а если просто цепануть эспрессо по дороге на работу, то и pret сойдет (распространенность уровня шоколадницы)

Развернуть 1 комментарий

@kotyakott, @kirizhik а не подскажете, где вкусный фильтр кофе или всякие из v60 попить в Лондоне? Я находил какой-то гайд по спешалти, но не дошел пока до мест. Black Sheep норм по flat white и другим с молоком. Pret не нравится
Спасибо за Roasting Plant — он у меня был отмечен на карте на посетить
Ну и куда ни заходил с улицы, пока чего-то особо вкусного не нашел

Развернуть 1 комментарий

@VladShubin, вопрос не мне адресован, но мне есть что сказать)
Мне нравится Ozone Coffee Roasters, Watchhouse (тут не только кофе, а весь стиль. Очень современно), Monmouth, Rosslyn

Развернуть 1 комментарий

@ybeltrikov, посетил по рекомендации Watchhouse, что на территории Somerset House. Реально классное место и вкусный кофе, разных способов приготовления. Thanks mate, appreciate it
Roasting Plant тоже понравился!
Полезные комментарии.

Развернуть 1 комментарий

@VladShubin, тогда тебе, возможно, тоже надо на London Coffee Festival 🙂 Будет 20-23 апреля в Old Truman Brewery

Развернуть 1 комментарий

уже не актуальны. Сейчас все гоняют на электрических lime велах, после которых не сидишь в офисе потный как мразь, и которые можно кидать где угодно. Очень кайфово.

Развернуть 1 комментарий

В Берлине что-то из вышеперечисленного нет и надо шевелиться, но люди вокруг более-менее достойно живут + многие плюшки вообще все недостатки перекрывают.

На такси например тут никто в здравом уме не будет каждый день ездить, но оно и не хочется.

Какой-нибудь шеринг самокатов или велосипедов в Москве просто жестокий и беспощадный после Берлина (начиная от качества самих самокатов, заканчивая местам где и как человеку придётся ездить + очень малый охват, мало точек, мало провайдеров).

Общественный транспорт, велосипедная инфраструктура, отсутствие грязи на дорогах (на подошве); кафе и рестораны в самых глухих деревнях;

По-поводу круглосотчной доступности —это зло и изнанка экономического расслоения общества, явный хинт какие страны избегать, чтобы не вляпаться в ещё одно схожее с российском общество.

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@tdurova, «По-поводу круглосотчной доступности —это зло и изнанка экономического расслоения общества» Вы имеете ввиду, что если что-то работает круглосуточно, то это значит, что есть очень бедные слои, кто готов делать это ночью (доставка например), правильно я вас понял?

Развернуть 1 комментарий

@N1Hy1ePNewlpLps8, а ещё и тебе, как ит специалисту, свои проблемы надо решать во вне рабочее время и быть готовым работать 8+ часов в сутки, быть огурцом и тд. На загнивающем Западе силен work life balance в сторону life. Надо к врачу или на курс физиотерапии, но врач работает только с 10 до 17:00, или ребёнка ежедневно в 16:00 из садика забирать и прочее — no problem, главное, чтобы ты задачки двигал. Естественно, есть предприятия со сменами, пропусками и тд — там ситуация может отличаться.

Развернуть 1 комментарий

@tdurova, всё от мотивации зависит. Кому-то задачки двигать, кому-то 80 часов на работе мало, чтобы мир сделать лучше.

Развернуть 1 комментарий

@roma_ds, делайте свои проекты или берите контракты, там и зарплата больше. Как вариант, можно одну фуллтайм и пет проект либо дополнительный контракт.

Развернуть 1 комментарий

@tdurova, про зарплату большие вопросы.
в РФ НДФЛ в 13% (+ льготы для ИТ) и усн под 6% открывает огромное количество возможностей.
как я писал уже, многим людям заходит доставка еды в 23.30 ночи или поход в супермаркет в это время.

Развернуть 1 комментарий

@roma_ds, в западной Европе aka Германия многим заходит ложиться спать в 21-00 и вставать в 5 утра, супермаркеты открываются в 6 утра. Тем не менее для ночных жителей есть ночные магазинчик, забеголовки и почти круглосуточные заведения на вокзалах.

Про зарплату на поняла, какие вопросы, можно пожалуйста подробнее?

Развернуть 1 комментарий

@roma_ds, прикинуть доход и размер налогов можно с помощью множества онлайн калькуляторов, они есть почти для любой страны, вот популярный немецкий https://www.brutto-netto-rechner.info/gehalt/gross_net_calculator_germany.php

Развернуть 1 комментарий

@tdurova, 47% получилось.
Спасибо, лучше в Мск работать с 13%

Развернуть 1 комментарий

@roma_ds, ну не 13%, почитайте сколько за вас налогов платит работодатель еще
просто они у нас скрытые

Развернуть 1 комментарий

@roma_ds, суммарная налоговая нагрузка в России 47.5% против в Германии 48.9 ( на 2018 год)

Развернуть 1 комментарий

@tdurova, это на работодателя. А сотрудник всё равно торгуется офферами как это принято на локальном рынке: в Европе надо сбрасывать со всех цифр 40-50%, в РФ надо сбрасывать 13-15%. Торговаться с аргументами «ну там же у вас налоги выше» уже сложнее, чем просто попросить сравнить цифры.

Развернуть 1 комментарий

@yeputons, про торг зарплаты оно мне понятно, но комментарии в стиле останусь в РФ, потому что 13% сильно противоречат моему выбору / мнению.

Развернуть 1 комментарий

@tdurova, плюсую. — рассуждения «буду жить там, где % ниже» — это супернаивно. Вопрос ведь не в %, а в том, какой уровень жизни ты можешь себе позволить на оставшиеся.

@roma_ds — в современной России действительно после уплаты налогов может оставаться «на два айфона» — как и в Европе. Плюс сервисы 24/7.

Только вот два айфона каждый месяц не нужны, а в возможности побриться в модном барбершопе в 2 часа ночи нет никакого кайфа, если у тебя с утра могут отжать бизнес, посадить на бутылку за то, что перешел дорогу каким-то илитам или бандитам, если тебе надо постоянно как-то выкручиваться, чтобы выйти в интернет, получать визы для поездок, придумывать что-то для переводов денег и так далее и тому подобное.

Конкретно в Швейцарии ограничивается круглосуточная работа по многим соображениям, в том числе из-за заботы о здоровье людей: работать ночью — это нездорово. На такую работу подписываются люди не от хорошей жизни. Из-за этого у них осложняются взаимоотношения в семье, растёт уровень стресса и нервных болезней, они больше курят и пьют кофе и энергетиков — что в долгосроке повышает нагрузку на систему здравоохранения. Лечение таких людей обходится дороже и субсидируется теми, кто ночью спит нормально.

Вдобавок, от круглосуточного ритма бизнеса растёт уровень шума, выделяется больше тепла и светового загрязнения, потрубляется больше энергии (ночью нужно включать больше света и отопителей).

В Швейцарии были случаи, когжа жители деревни протестовали против автозаправки с магазином, которая работала до 22 часов все дни, включая выходные. Требовали ограничить время работы до 20 часов, чтобы меньше машин ездило по улицам.

Комфорт — это ведь не только когда едулечку в 3 часа ночи привозят. Это и когда в 3 часа ночи ты можешь просто спать.

Развернуть 1 комментарий

@zahhar, спасибо, прямо с языка снял, я никак не могла нормально объяснить это всё без ухода в эмоции

Развернуть 1 комментарий

@tdurova, @yeputons, я 2 раза посчитал.
при зп синьёра в $5000 ставка налога сверх НДФЛ в ИТ компании 2,782% в год.

как вы столько набрали. или это где-то в интернетах такие цифры?

Развернуть 1 комментарий

@zahhar, привет.
ты сильно сгущаешь тучи над тем что происходит в РФ.
Приезжай в Мск на недельку летом, покажу тебе реальность. Можем даже в МВД сходить — спросим, где тут на бутылку сажают, уверен, что будет о чём посмеяться с сотрудниками.

на самом про бутылки — это уже не вызывает улыбку даже. у меня сотни предпринимателей знакомых. Никто бутылок не видел, только в интернетах пишут почему-то про них. Были те кто посидел даже, но там реально есть за что.

я бы сам рад жить в Швейцарии, только я не смогу там обеспечить себе аналогичный уровень жизни как в РФ, поэтому пока есть возможность, буду тут

Развернуть 1 комментарий

@roma_ds, это традиционный метод «складываем два числа без контекста», широко применимый в налогосрачах в интернетах.

Я когда вижу эти «НА САМОМ ДЕЛЕ в России 40. 80. 146%» (и ей Богу, каждый раз цифры разные), сразу понимаю, что дальше в диалог лучше не идти.

Развернуть 1 комментарий
Развернуть 1 комментарий

@roma_ds, в 2022 я в Россию не планирую. Мне и раньше виза была нужна, а теперь т.к. я гражданин враждебно настроенного государства, да ещё с активной антивоенной и антироссийской позицией в соцсеточках — баз шансов.

Понятное дело, что обычным законопослушным людям, кто живет себе потихоньку и не отсвечивает, власть в России не угрожает.

Но вот когда ты говоришь за всех 50 000 ментов в Москве что прям там все зайчики, тут я начинаю сомневаться.

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@roma_ds, мы видимо в разных городах живём 🙂 В моей Москве людей задерживают за желто-синий значок или «молчаливую поддержку митинга», за пустой плакат или плакат со звёздочками,или просто за то, что оказались в месте предполагаемого проведения митинга и выглядели слишком подозрительно, пытают девушек в ОВД Братеево, угрожают активистам и разрисовывают им двери, хватают людей у подъездов и увозят, недопускают адвокатов к задержанным, раздают уголовку за безобидный стрит-арт. Перечислять в принципе довольно долго можно 🙂 Ну и по поводу бутылок — они сейчас не в тренде, новый писк моды — это швабры.

Развернуть 1 комментарий

@dottedmag, а ещё сайт-то не русский и сервера держит в недружественном государстве 🙂

Развернуть 1 комментарий

@nickkryloff, наверное в разных городах.
Был я пу шкинской в неудачное время. За час три раза проверили документы и посмотрели портфель. Каждый раз представлялись и говорили спасибо, что показал.
про швабры вам, видимо, виднее

Развернуть 1 комментарий

@roma_ds, “maybe if I close my eyes it will go away”? Отвратительно.

Развернуть 1 комментарий

@roma_ds, вас не задержали и были вежливы , это отлично:)но то что я перечислил — вы считаете, что это в порядке вещей и не вызывает тревогу?

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@roma_ds, я про Минск в своё время точно так же утверждал. Пока под окнами светошумовые рваться не начали, а некоторых друзей и коллег в тюрягу не загребли. Кое-кого не выпустили до сих пор.
Но зато налоги были 9%, это да. Но безопасность и своя совесть стоит дороже.

Развернуть 1 комментарий

обычным законопослушным людям, кто живет себе потихоньку и не отсвечивает, власть . не угрожает

как показал опыт, рамки законопослушности очень быстро начинают сужаться, и мысль «не ну за это то точно не могут привлечь к отвественности» очень быстро разбивается о реальность. Коробки от телевизора и трусы не того цвета вряд ли тянут на две недели в тюремной камере, однако же.

Развернуть 1 комментарий

@YuliaQA, посадить детей в автозак за цветы у посольства — это был для меня просто какой-то новый уровень сюрреалистического кошмара

Развернуть 1 комментарий

@Stenopolz, об том и речь. Если власть примет закон всем носить зеленые штаны, приседать при виде мента и говорить два раза «Ку» любому чиновнику — то придётся выполнять. Такие правила игры и всем норм.

Развернуть 1 комментарий

@zahhar, слушайте, но в европе же точно так же -начали короновирусную истерию, закрыли все к чертям, и людей из дома не выпускали. С дронов следили, чтобы никто никуда не ходил. Штрафовали тех, кто гулял в одиночестве на природе и т.д.

Т.е. по факту это те же приседания перед ментами, хоть и по другому поводу.

Я против творящейся дичи, но не нужно выставлять европейские страны супер-белыми и пушистыми.

Развернуть 1 комментарий

Разница в том, что коронавирус — это ситуация, которая в мировой практике впервые случилась и никто не знал как её адресовать. В Китае тоже был жёсткий карантин, в Сингапуре, в Израиле — не только в Европе. Даже в России какие-то там перчатки требовалось надевать по правилам.

При всём при этом в Европе и в Америке ты мог протестовать против правил — и как максимум тебя могли погонять менты за несоблюдение дистанции и отсутствие маски на несанкционированном мероприятии. Миллионы людей по всему миру выходили на митинги, а опиздюливали только там и преимущественно тех, кто под эту лавочку начинал агрессию проявлять или превращал анти-ковидные митинги в политические (как раз-таки ультраправые обычно).

Штрафы за нарушение короновирусных мер тоже были весьма скромными: все эти законопроекты про штрафы на 5000 евро за нарушение карантина / отсутствие маски или вакцинации либо не прошли в парламентах, либо не применялись на деле. Штрафовали там на какие-то смешные 60-100 евро в реальности, за редким исключением.

Обязательная вакцинация для всего населения была введена только в некоторых странных странах типа Таджикистана и Эквадора. Большинство же стран обязывали прививаться только ограниченный круг людей, как правило работающих на государство или с большим числом людей (Москва вроде бы тоже так делала).

В США так и вообще некоторые штаты смягчили короновирусные ограничения — обычно там где республиканцы были у власти и они услышали голос своих избирателей.

А ещё были забастовки из-за короновирусных ограничений и много чего ещё.

То есть да — приседания перед властью всегда были, есть и будут везде в мире. Законы несовершенны нигде и всегда найдутся какие-то идиотские законы, которые приходится соблюдать.

Но такого количества идиотских законов, которые с начала войны штампует Гордура нигде в Европах нет.

Развернуть 1 комментарий

@zahhar, блин, мне не очень нравится выступать за россию, но
я всегда считал, что европа это место, где уважается свобода граждан.

А по факту, как только это захотелось властям, ВСЕХ посадили под домашний арест просто, «чтобы чего не случилось». Сколько там говорят процентов спас локдаун? вроде 0.2%?

При этом меры были совершенно неадекватные — у меня знакомых мужа и жену, которые вместе живут, в Испании оштрафовали за то, что они вместе ехали в машите (т.к. в машинах в то время можно было ехать только по одному).
Ну и подобные истории, когда европейские менты просто не включают свои мозги, а «действуют по инструкции», не задумываясь о адекватности своих действий.

При этом в россии особых проблем не было, всегда можно отойти подальше, уехать на природу, не маячить перед ментами и никто тебя не тронет. Ну или договориться. Ну и довольно быстро на ограничения забивали много где. То есть фактически, свободы было намного больше (этот вопрос уже несколько раз обсуждался в клубе).

Т.е. в сухом остатке имеем, что в европе можно выйти на улицу побуянить, а в россии нельзя (особенности местных обычаев). Но когда дойдет до дела, то европейцы гайки могут закрутить еще покруче, т.к. территория у них значительно меньше, и в отличие от россии никуда не денешься.

Но такого количества идиотских законов, которые с начала войны штампует Гордура нигде в Европах нет.

Вопросов нет, но будут ли они надежно исполняться?

Давай на этом закончим, власти россии — гандоны, но и в европе у власти те еще мудилы. И если захотят, то приседать заставят и те и эти.

Развернуть 1 комментарий

@orbit, ты взял какой-то экстремальный случай — в Испании это правило про «только водитель в машине» действовало с 14 марта по 10 мая 2020 года, то есть меньше двух месяцев и в самом начале локдауна, когда никто не знал чё-как действовать вообще, масок не было, вакцин не было и каждое правительство бесилось как могло.

Это не значит, что вся Европа вот такая как ты описываешь.

Более того — сейчас Европа вот такая вот («у власте те ещё мудилы»), а через пару лет к власти придут какие-нибудь другие мудилы. Наверное, даже в Германии 🙂 И пусть они трижды будут мудилами, но они будут теми мудилами, которых можно заменить.

А в России же последние 20 лет одни и те же гандоны были и скорее всего останутся.

Да, лучше закончить конечно, а то нас забанят тут к чертям обоих 🙂

Развернуть 1 комментарий

не маячить перед ментами
«договориться»

Свобода уровня /b/

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@orbit, в Москве пенсионерам отключали проездные, по телефону проверяли что они не шляются, в метро штрафовали за отсутствие перчаток (абсолютно бессмысленная мера которой не было больше нигде в мире).
За свободой в Америку надо ехать наверное.

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@orbit, «побуянить»? Офигеть. В России нельзя выйти в Александровский сад с книжкой «Война и Мир» постоять в то время как Россия убивает сотни мирных жителей в соседнем государстве. О чем ты говоришь? Какой домашний арест из-за ковида? Неужели ты не видишь что делает твое государство, пока ты рассуждаешь о свободе?

Развернуть 1 комментарий

@lk4d, очень ждём отчёт о свободе в Америке )))

Развернуть 1 комментарий

@orbit, надо понимать, что ковид был новинкой для современного мира и никто не понимал что и как делать. Сейчас-то задним числом легко решать как было правильно, а как нет, но тогда это была одна сплошная неизвестность.

Вон Швеция решила пойти по иному пути и ничего хорошего у них не вышло.

Ковид и его ограничения это не прихоть кого-то у власти, просто обстоятельство непреодолимой силы, с которым приходилось как-то жить. Когда обстоятельство прошло — гайки раскрутили тоже. В великобритании например ковид уже отменен, маски нигде не нужно носить, анкет заполнять тоже.

А в России ситуация такова, что нет внешних обстоятельств, которые потом пройдут, есть просто данность от которой никуда не деться, переждать нельзя или очень долго, договориться не получится, изобрести вакцину тоже.

Развернуть 1 комментарий

Евгений Зубак 11 апреля 2022 автор

@I8n764heNEpPSwXa, закругляйтесь, ребят, в теме вопросы, которые вы обсуждаете не поднимались и близки к нарушению правил клуба

Развернуть 1 комментарий

@zubak, Опять я крайний. Тебя именно мой комментарий триггерит? Остальных ты решил не тегать? Я снова напомнил что-то неприятное?

Развернуть 1 комментарий

Евгений Зубак 11 апреля 2022 автор

@I8n764heNEpPSwXa, Мне лень всю ветку тегать. Относится не только к тебе.

Развернуть 1 комментарий

@zubak, Забавно получается. Пять человек спорят, я пишу один комментарий, ты затыкаешь мне рот. Лень, ясно.

Развернуть 1 комментарий

@Kirk, ещё раз кратко сформирую свои тезисы:

• ковид — новинка, но и Россия устроила новинку
• европейцы показали, что могут закрутить гайки покруче росии, и жёстко это контролировать
• в России в случае закручивания гаек проще избежать действия власти
• можно верить, что в Европе такого больше не случится, но ведь случилось

Развернуть 1 комментарий

@orbit, о чём речь? Прямо сейчас в России закручены гайки и их никак не избежать. Нельзя протестовать против войны, даже просто слово «война» говорить нельзя.
Как вы это собираетесь избежать?

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@orbit, в свободных странах смогут выбрать другую власть в таком случае.

Твой друг в Испании кстати тоже мог жену припрятать на заднем сидении или ехать ночью или из деревни в маске. Изи.

В общем спор явно зашёл в тупик как и во всех предыдущих тредах.

Развернуть 1 комментарий

@orbit, дык а что ты на правду триггеришься?

Я тебе написал «Такие правила игры и всем норм» — а ты мне «Как будто где-то не так«. Да много где не так!

Если мне не нравятся правила игры в моей стране — в Эстонии, я смогу максимум через 4 года (а по факту обычно даже менее, чем через 2 года, т.к. в зависимости от страны ЕС проходят до 4 выборов: муниципальные, президентские, парламентские, и европарламентские с разной каденцией) пойти проголосовать и знать, что мой голос будет учтён.

Твой голос учтён в России?

Развернуть 1 комментарий

Евгений Зубак 12 апреля 2022 автор

@I8n764heNEpPSwXa, Я рад, что ты сделал какие-то выводы. К остальным обращаюсь, если кто не понял, будьте внимательны к правилам клуба, я как автор поста помогаю с модерацией и с моей точки зрения данная дискуссия проваливается в политоту.

Развернуть 1 комментарий

@indi256, а в ЕС разве работодатель не платит тоже скрытые налоги? Например, здесь в Германии работодатель платит почти 1000 евро в месяц страховку за каждого сотрудника (зависит от зп, но с относительно высокой зп получается 900 с лишним евро). Не исключаю, что есть и другие налоги, взносы, которые платит работодатель.

Развернуть 1 комментарий

По-поводу круглосотчной доступности —это зло и изнанка экономического расслоения общества, явный хинт какие страны избегать, чтобы не вляпаться в ещё одно схожее с российском общество.

Забавно, когда это из страны c Amazon Prime пишут.

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@begor, тут согласен, в Германии неоднократно фиксировались нарушения рабочих условий по трудовому законодательству: как delivery market, так и стройка, на которую кидают болгар и румын за гроши и без техники безопасности (пруф)

субъективно, я обычно накидываю доставщику гор продуктов с Фреша евро-два на чай, если он не окажется грубым мудаком – хоть так поддержать ребят хочется

один из плюсов в Европе – культура забастовок и возможность прокачать свои права, не боясь получить п#зды от силовиков, считаю это базовым правом; пусть даже транспорт встанет на день, добьются повышения зарплаты и улучшения условий – отлично

хотя хз, с одной стороны у нас тоже были забастовки яркие типа анти-Платон, с другой стороны было подавление аналогичного протеста в 2016 с кубанскими фермерами – ну а про возможность отстоять свои права в 2022 и говорить не хочется

Развернуть 1 комментарий

@YuliaQA, там никто из крупных не брезгует. Ни один крупный бизнес не будет заботиться о работягах, которые заменяются на раз-два, особенно учитывая поток голодных и неумелых мигрантов в Европу и Москву. Максимум бутылочку дадут с горлышком побольше.

А вот ссать в уши про условия труда, зеленую повестку и все хорошее крупный бизнес будет, это они умеют.

субъективно, я обычно накидываю доставщику гор продуктов с Фреша евро-два на чай, если он не окажется грубым мудаком – хоть так поддержать ребят хочется

Самый разумный подход. Всегда стараюсь оставлять на чай курьерам (если они не тупят у домофона кек).

Развернуть 1 комментарий

@begor, амазон прайм за дополнительные деньги, и вроде бы трудовое право и уровень зарплат не ущемлен + в амазон много автоматизации. Тем не менее многие в Германии осознанно стараются покупать через амазон только в крайнем случае. Минимальная зарплата в Германии — 12 евро в час брутто.

Развернуть 1 комментарий

На такси например тут никто в здравом уме не будет каждый день ездить,

потому что дорого

а поэтому и не хочется

Развернуть 1 комментарий

�� Комментарий удален его автором.

Развернуть 1 комментарий

@ganqqwerty, деньги конечно тоже решают, но мы два спортивных айтишника без детей и животных. У нас был автомобиль первые два года после переезда по-привычке, но мы только 2-3 раза на нам съездили на море и один раз за техникой тяжёлой. Все остальное время с удовольствием гуляем пешком, на велосипедах,самокатах, в автобусах, метро.

Развернуть 1 комментарий

Andrey Bondarenko Senior System Engineer 12 апреля 2022

Непопулярное мнение: такая-то цифровизация в РФ не от хорошей жизни.

Непопулярное мнение 2: в Европе вся эта цифровизация подтянулась уже года 3 точно. Пишу про Чехию, которая «задворки восточной европы».

Банки: потому что кредиты дорогие, а клиента как-то надо привлекать. Банки в Европе уже подтянулись, в телефонных клиентах разве что отчеты «сколько потратил по категориям» все еще всратые. Тут сильнее чем в РФ развита и популярна оплата по QR-кодам, так как их удобно печатать на принтере. Например, стоит около деревни ящик с яблоками и термопот с глинтвейном, а код для оплаты лежит на столике.

Транспорт: он ходил по расписанию и был всегда очень развитым. Года 2-3 назад по крайней мере у нас появилась оплата SMS и картами прямо на входе (бесконтактные терминалы около дверей). Такси просто не так популярно, потому что дорого: не работают таксисты за еду по 14 часов в день! Такси в основном для туристов, местный доедет транспортом за то же время.

Правительство: мое личное мнение, что расцвет госуслуг в РФ связан со слежкой. В Чехии они тоже появились: налоги, рецепты, кадастр, штрафы, школьное расписание и дневник вот это все. Чего НЕТ в России: раз в год мне приходит PDF со списком всех запросов о моих данных во всех гос. базах. Где полиция штраф выписывала, где налоговая следила, где миграционная служба что-то смотрела — все видно! Как тебе такое, Герман Греф?

Путешествия по-моему сначала цифровизировались в ЕС и США, а потом пришли в РФ.

С ковидным локдауном все большие магазины стали досатвлять, да еще и со скидкой в 10% относительно офлайна.

Что есть, чего не видел в Москве: много где в ресторанах стол помечен NFC-меткой (и QR-кодом), по которому моментально виден чек и можно оплатить весь счет или отдельные позиции. Очень удобно, когда раздельный счет.

Чего еще из цифровизации? Самая подробная ГИС (OSM) поддерживается энтузиастами, есть Google Maps, есть Garmin и другие.

По списку из топика есть вообще все. И аренда ненавистных электросамокатов, и доставка, ивенты-фигенты. Только фокус сдвинут: тебе нерегулярная доставка еды не так нужна, потому что ресторанов как зубных клиник в Петербурге, велосипед свой (пять), машину тоже нет московских проблем содержать (очевидно, что своя машина гораздо лучше каршеринговой, единственным преимуществом которой обозначают некую твою ВЫГОДУ от того, что кто-то ее не только содержит, но и зарабатывает на ней, ага).

Развернуть 1 комментарий

@AndreyBondarenko, ещё про оплату в ресторанах — как правило можно включить чаевые в чек и не носиться с наличными

Развернуть 1 комментарий

@aponomarev, в Чехии это всегда можно было. Просто тебе говорят «95 крон» а ты отвечаешь: «120». Включат хоть наликом, хоть через терминал.

Развернуть 1 комментарий

@AndreyBondarenko, да, очень здравый аргумент. Помню, когда я переезжал в 2016 в Бельгию, то за голову хватался от местных банковских услуг. А сейчас — очень даже ничего. Оплата по QR, Payconiq, Apple Pay везде работает, Revolut доставляют.

Развернуть 1 комментарий

@AndreyBondarenko, а где можно такое настроить, чтоб pdf-ка с запросами приходила?

Развернуть 1 комментарий

Ростислав Теряев Software Engineer 26 октября 2022

Чет читаю и все ответы выглядят так:
Я живу в городе_европы_таком_то тут с диджитализацией в разыыы лучше, чем в мск!!
Врачи:
Запись обычно через месяцы
Еда:
Быстрой доставки нет, зато есть через день

Мне в европе было больно, что все закрывается рано. Я сейчас живу ночью и страдал бы. В мск на самом деле ночная доставка не супер развита: вкуссвилл в течении двух часов доставляет ночью и яндекс еда вроде может, но доставка бесплатная от 2к или что-то такое.

Если списком, где был (не жил, а именно был от недели до месяца):

1. Финляндия, Лаппеенранта 2019. Понимаю, что это деревня и не Хельсинки, но именно там ощущалось, что все закрывается рано! Банки днем, а в них еще записываться надо было для каких-то серьезных манипуляций, магазины до 10, а в выходны еще раньше.
2. Минск 2022. По уровню кафе и ресторанов сильнейше проигрывает Москве. Банк (МТбанк) — ностальгия, я как будто в 2000е попал, такие же ощущения от обстановки внутри и от самого тц, где был (Дана молл). Я субъективен т.к. оцениваю точечно, но все же. Про сам банк: сфивт только из отделения делается, пинкод только в банкомате менять (я сейчас не в РФ и страдаю от этого). Ну я конечно «зажрался» тинькофф и все остальное не такое крутое.
3. Сан-Франциско 2015. Помню ездили в 10 вечера на машине по всему городу, чтобы найти хоть что-то открытое.

Выше был комментарий, что в Азии это все еще круче, чем в мск. Мне тоже так кажется, хотелось бы услышать от тех, кто там, как оно на самом деле. Скоро сам еду в Бангкок жить, попробую, может допишу ответ

Развернуть 1 комментарий

@rostislaved, мне вот интересно, как врачи и доставка связаны с диджитализацией?
В условном Стокгольме запись к врачу на месяц вперед, но, онлайн созвон с врачом по поводу моей простуды — запись доступна через 20 минут, мои жалобы выслушают и онлайн выпишут лекарства по рецепту, которые я онлайн закажу в любой аптеке (они все интегрированы с сервисом рецептов) и их к вечеру привезут в шкафчик возле дома.
Выглядит довольно диджитализировано, нет?

Развернуть 1 комментарий

@Stenopolz, тогда нам надо договориться об определениях. Для меня диджитализация — то, как я могу делать что-то не выходя из дома, то есть через интернет.
Примеры:

1. Мне надо поесть. Обычно для этого люди ходят в магазин, покупают продукты и готовят. Диджитализируя этот момент мы исключаем стадию личного похода в магазин (продукты нам привозят и мы готовим) или сразу и вторую стадию готовки, то есть привозят сразу готовое.

Если срок доставки будет больше, чем время, за которое я сам схожу в магаз и приготовлю, то это не решает мою проблему.

1. Про врачей. Насколько помню из детства тут было 2 этапа: сходил в поликлинику записался и пришел по записи. Опять же, диджитализировать можно. Если только первый этап, то получаем возможность записи через сайт. Если и второй этап, то получаем что-то вроде яндекс.здоровья.

Сейчас я расписал и вижу, что да, я и онлайн могу записаться на «через месяц» или сам сходить и записаться на «через месяц», так что долгое время ожидания приема не отнести к отсутствию диджитализации — это другая проблема. Но все же саму возможность записаться удаленно к диджитализации отнести можно. Я не жил в европе давно и плохо знаком с этой ее стороной, но если можно записываться и даже онлайн получать консультации, то это очень круто.

Развернуть 1 комментарий

@rostislaved, важно еще Европу разделять, уровень диджитализации в Швеции и Германии очень разный.

Развернуть 1 комментарий

Павел Щорс Senior Android Developer 8 апреля 2022

• Медицина и анализы
  Медицина неторопливая в каких-то рядовых случаях, все делается через терапевта, сроки ожидания записи к врачам могут достигать нескольких месяцев. Наличие частной страховки позволяет сократить ожидание, но она не является чем-то стандартным. К счастью, для простых кейсов есть онлайн медицина, запись есть прям на сегодня, если вам надо порешать вопрос с простудой, рецептами на противозачаточные и чем-то еще такого плана — все делается недорого и быстро.
• Страхование
  Множество страховых, у шведов для всего есть страховка — квартира, машина, собака. Страховка на квартиру часто покрывает утерю багажа, кражу велосипедов и какие-то еще неочевидные вещи:) Делается онлайн в несколько кликов, деньги списываются автоматом с банковского счета, ничего не пропустите.
• Еда нерегулярная
  Есть несколько доставок на выбор, бывают как платные так и бесплатные варианты. Сроки доставки от 15 минут до полутора чаосв, зависит от близости кафе. Круглосуточные варианты не искал, обычно по графику работы кафе (то есть часов до 23). Ночью будет сложно.
• Еда регулярная
  Опять же, несколько сервисов еды по подписке на выбор, привозят как готовые блюда так и наборы для готовки. По цене доступно рядовому айтишнику.
• Продукты
  Супермаркеты всех сортов и размеров, у всех есть доставка (обычно на следующий день) или варианты «забрать собранный пакет продуктов самостоятельно из магазина». Для этого конечно же есть сайты и приложения с удобным выбором. Продукты вкусные везде:) Есть так же польские и русские магазины для любителей неместного.
• Аптеки и лекарства
  Все есть онлайн с доставкой сегодня на сегодня (часто бесплатной). Рецепты, которые вам выписывает врач, доступны онлайн аптекам. Потому можно позвонить врачу «по скайпу», получить рецепт и тут же заказать лекарство никуда не выходя. Принесут домой.
• Деньги и банковские продукты
  Банки отлично развиты, у всех есть мобильные приложения и веб сайты. Поддержка эпл, гугл, самсунг пэй и всяких экзотических «колец для оплаты». Прилаги нормально переведены на английский, есть учет категорий товаров, возможности инвестиций. Есть так же отдельные сервисы, чисто направленные на работу с инвестициями. Первый визит в банк придется сделать ногами, дальше все решается онлайн при помощи специального BankID, который заодно выступает логином вообще во все государственные и не только сервисы, где нужна авторизация вашей личности. Так же с этим банк айди можно потом онлайн переехать из одного банка в другой и перенести все деньги — за несколько кликов буквально.
• Тревел
  Не очень знаю, что тут оцифровывать — есть сайты и приложения у всех местных железных дорог и общественного транспорта. Есть два аэропорта с лоукостами на любой вкус.
• Каршеринг
  С классическим каршерингом напряженка — только один сервис — Aimo, в котором можно брать и оставлять машину в любом месте внутри home zone. Остальные сервисы работают по принципу «быстрая аренда машины с возвратом»: у вас возле дома есть хотспот, вы в нем берете машину(из приложения, можно заранее забронировать время), ездите по делам, и возвращаете туда, где взяли.
• Такси
  Такси недешевое, но вполне доступно. Моя обычная поездка обходится в 10-15 евро. Каждый день я на нем не езжу, но когда куда-то надо поехать срочно, никаких сомнений и боли не возникает. Есть варианты для перевозки собчек и премиум.
• Доставка документов и посылок
  С документами не сталкивался. Посылки привозят или в точку самовывоза в ближайшем магазине (часто бесплатно), либо в почтомат, либо к вам прямо домой (но дороже). Большинство магазинов не имеет своих курьеров и шлет либо почтой, либо одним из десятка частных сервисов на любой вкус — доставка электромобилями, велосипедами, ослами, чем угодно.
• Переезд и хранение вещей
  Для переездов проще всего взять в аренду грузовик или прицеп на ближайшей заправке. Можно сделать онлайн или через приложение. Есть так же множество сервисов для переезда, когда группа людей за вас все упакует и перевезет, но там про уровень сервисов не подскажу, не пробовал.
  Для хранения вещей по городу натыкано большое число складов-хранилищ, никогда не пользовался их услугами, но полагаю, что все должно быть удобно.
• Аренда двухколесных средств передвижения
  Сервисов аренды самокатов так много, что с этого года решили сократить их число, ибо задолбали:) Могу с ходу назвать: voi, bird, tier.

Отдельно еще раз остановлюсь на BankID — это реально волшебная штука, очень много куда интегрирована. В два клика вы подтверждаете свою личность и все данные о вас подтягиваются туда, куда надо. Это все гос услуги, магазины, банки, страховки.

Еще есть очень удобный платежный сервис Klarna, на многих сайтах вам достаточно ввести вашу почту, по ней автоматом подтянется ваш аккаунт с адресом. Останется подтвердить покупку в BankID и готово, больше никаких вбиваний номеров карты и адресов.

нетворкинг, дейтинг, ивенты и концерты были на паузе из-за ковида. Сейчас вроде оживает все, много движух, надо места знать.

Развернуть 1 комментарий

Евгений Зубак 12 апреля 2022 автор

@Stenopolz, все круто расписал, спасибо! А к айфону можно транспортную карту привязать? Или с помощью Apple Pay оплатить проезд? Про дейтинг и русских много приехало? А без шведского языка норм или лучше учить?

Развернуть 1 комментарий

@zubak,
Можно платить за транспорт бесконтактной платежной картой, соответственно и Apple Pay тоже.

Можно поставить приложение общественного транспорта — и показывать QR проездного с экрана, считыватели стоят и в метро и в автобусах.

Про дейтинг ничего внятного не подскажу, если честно. Россиян и белорусов тут довольно много, а еще сербов, поляков и прочих ребят с которыми у нас довольно много общего культурного кода:)

tl;dr: Без шведского языка норм, если не хочешь интегрироваться в общество.

Тебя везде поймут ну или хотя бы попытаются понять. Всякие госструктуры и даже случайные бомжи в лесу отлично общаются на английском. А вот какие-нибудь курьеры-эмигранты могут знать только свой родной язык и шведский, потому на английском бывают трудности, но без больших проблем.

Но, помимо вышеперечисленного, очень часто по телефону отвечают роботы, на шведском, без английских опций, это бывает прям больно. Это первое.

А второе, когда шведы сбиваются в кучку, они предпочитают общение на шведском, и тебя из контекста успешно выкидывает. На работе это решается правилами офиса, где всех обязывают говорить на английском, но вот на каких-то других массовых сборищах, типа соседи по дому собрались на барбекю, ты выбрался на массовую велопокатушку со случайными людьми и все в таком духе — там будет только шведский между людьми, и только время от времени к тебе на английском будут обращаться.

Так что, сюда отлично приехать и начать встраиваться с английским, но в долгосрочной перспективе я бы учил язык. Хотя многие люди здесь по 10 лет живут без шведского и не парятся, базовое понимание нужных тебе слов придет за пару лет, а остальное на английском обсудишь.

В какие города можно улететь из парижа paris и сколько времени это займет sql

Advertisement

Document details

tatler092020

Published on Sep 11, 2020

Follow this publisher

More from

expressgazeta372020

September 22, 2020

expert392020

September 22, 2020

rdio1990-01

September 22, 2020

ogonek372020

September 22, 2020

novagazeta1032020

September 22, 2020

popmeh102020

September 22, 2020

pitstop92020

September 21, 2020

podrujka082020

September 21, 2020

poisk382020

September 21, 2020

eda-dom-zagotovki082020

September 21, 2020

Read more

Advertisement

Advertisement

Advertisement

Advertisement

Advertisement

Advertisement

Create once. Share everywhere.

• Company — About us
• Company — Careers
• Company — Blog
• Company — Webinars
• Company — Press

Issuu Features

• Issuu Features — Fullscreen Sharing
• Issuu Features — Social Posts
• Issuu Features — Articles
• Issuu Features — Embed
• Issuu Features — Statistics
• Issuu Features — InDesign Integration
• Issuu Features — Cloud Storage Integration
• Issuu Features — GIFs
• Issuu Features — Canva Integration
• Issuu Features — Add Links
• Issuu Features — Teams
• Issuu Features — Video
• Issuu Features — Web-ready Fonts

• Solutions — Designers
• Solutions — Content Marketers
• Solutions — Social Media Managers
• Solutions — Publishers
• Solutions — Education
• Solutions — Salespeople
• Solutions — Use Cases

Industries

• Industries — Internal Communications
• Industries — Marketing and PR
• Industries — Publishing
• Industries — Real Estate
• Industries — Sports
• Industries — Travel

Products & Resources

• Products & Resources — Plans
• Products & Resources — Partnerships
• Products & Resources — Developers
• Products & Resources — Digital Sales
• Products & Resources — Elite Program
• Products & Resources — Publisher Directory
• Products & Resources — Redeem Code
• Products & Resources — Support

Explore Issuu Content

• • Explore — Arts & Entertainment
  • Explore — Business
  • Explore — Education
  • Explore — Family & Parenting
  • Explore — Food & Drink
  • Explore — Health & Fitness
  • Explore — Hobbies
  • Explore — Home & Garden
  • Explore — Pets
  • Explore — Religion & Spirituality
  • Explore — Science
  • Explore — Society
  • Explore — Sports
  • Explore — Style & Fashion
  • Explore — Technology & Computing
  • Explore — Travel
  • Explore — Vehicles

  specials

  7 неочевидных нарушений ПДД, за которые можно получить штраф (или остаться без прав)⁠ ⁠

  

  Даже если вы считаете себя добросовестным водителем и всегда соблюдаете правила, вам все равно может прийти штраф. Причем за нарушение, о котором вы даже не догадываетесь. И от таких не застрахован никто: ни водитель с 20-летним стажем, ни знающий назубок все правила выпускник автошколы. А все потому, что далеко не все нарушения так уж очевидны. Вместе с платежной системой «Мир», картой которой можно оплачивать автоштрафы без комиссии на портале «Госуслуги», рассказываем о не самых очевидных нарушениях ПДД.

  Нарушение № 1. Когда не выучил базовое правило про светофор

  Казалось бы, что тут сложного: красный свет — стой, желтый — готовься, зеленый — газуй. Но не все так однозначно со светофором. Например, водители нередко (читай «постоянно») забывают: желтый сигнал не только предупреждает, что скоро будет красный, но и запрещает движение. Поэтому ехать под него нельзя, иначе можно схлопотать штраф в 1000 рублей.

  В этом правиле есть только одно «но»: если желтый загорелся, а вы не можете остановиться, не прибегая к экстренному торможению, смело проезжайте — пункт 6.14 ПДД разрешает.

  Нарушение № 2. Когда оштрафовать могут за то, что вы едете слишком медленно

  О том, что нельзя превышать допустимую скорость, знают все. Однако в некоторых ситуациях можно получить штраф и за медленную езду, о чем многие забывают. Так, на автомагистралях запрещено движение на транспортном средстве, которое технически не способно развивать скорость выше 40 км/ч. Поэтому если из своего любимого и уже почти антикварного запорожца вы этого не выдавите, на автомагистраль лучше не соваться — грозит штрафом в 1000 рублей.

  

  Нарушение № 3. Когда за понты приходится платить

  Нелегко приходится поклонникам тюнинга — изменение в дизайн машины тоже карается штрафом. Причем касается это даже самых, на первый взгляд, безобидных обновлений и примочек. Запомните, чего не стоит делать своими силами: видоизменять кузов, переустанавливать фары и габариты, переоборудовать двигатель, тонировать лобовое и передние стекла больше чем на 20%, ставить габаритные шины и выпендриваться дополнительной подсветкой. Вы не в «Форсаже», побойтесь Вина Дизеля!

  Чтобы не совершить это совсем не очевидное нарушение, действуйте по трем правилам. Первое — почитайте Технический регламент Таможенного союза о безопасности ТС. Там подробно расписаны требования к компонентам авто и к изменениям в его конструкцию. Второе — все манипуляции с конструкцией авто проводите только на специальных станциях техобслуживания с лицензией. Третье — согласуйте все перемены в автоинспекции. Если где-то что-то нарушите, узнаете об этом сразу и успеете не нарваться на штраф. Он, к слову, составляет 500 рублей. Но есть примочки, за которые реально лишиться прав на целый год. Например, если вы решите установить красные фары.

  Нарушение № 4. Когда лучше подождать

  Представьте: загород, относительно глухая местность, старые железнодорожные пути, по которым крайне редко и очень медленно идут составы. Перед переездом нет ни светофора, ни шлагбаума. Именно в таких местах лихачами становятся даже те водители, которые обычно ездят аккуратно. И раздражаются, если кто-то перед ними тормозит — буквально и фигурально. Соблазн пойти на обгон в такой ситуации велик, но наказание за нарушение не заставит себя долго ждать.

  Кодекс об административных нарушениях уверяет, что объезжать машины перед переездом нельзя. Иначе ждите штрафную квитанцию на 1000 рублей!

  Eсли вы все же получили уведомление о штрафе, знайте, что теперь его можно оплатить без комиссии — с помощью карты «Мир» и портала «Госуслуги».

  

  Нарушение № 5. Когда один раз и «случайно» — считается

  Идеально вписаться в поворот налево на перекрестке бывает непросто даже опытному водителю. Признаемся: все мы хоть раз, но чуть-чуть наезжали на сплошные. И нарушать никто не собирался — просто слегка не вместился. Но для правил это аргументом считаться не будет.

  Если вы пересекли сплошную или парочку и при этом не объезжали препятствие, вам вполне могут выписать штраф на 5000 рублей. А в некоторых случаях лишают прав на 4–6 месяцев.

  Нарушение № 6. Когда есть шанс прокатить свою машину на эвакуаторе

  Одна из самых распространенных проблем, с которой сталкиваются все автомобилисты в больших городах — отсутствие парковочных мест. Причем проблема такая старая, что с ней успели столкнуться уже несколько поколений водителей. И каждый следующий все сильнее убеждается, что по всем правилам парковаться просто невозможно. Но законы и штрафы за их нарушение никто не отменял.

  Если вам кажется, что оставить машину в паре-тройке метров от пешеходного перехода в порядке вещей, ждите штраф в 1000 рублей во всех городах России, кроме Москвы и Санкт-Петербурга. Тут штрафуют сразу на 3000 рублей. Отдельный вид мазохизма — провожать взглядом эвакуатор, который увозит вашу машину.

  

  Нарушение № 7. Когда ГИБДД поздравит вас с новой машиной штрафом

  В законы постоянно вносят поправки. Так, отправляясь куда-то в новом, 2020 году на недавно купленной машине, вы рискуете нарваться на штраф. С 1 января ездить без номерных знаков будет запрещено, а за нарушение придется заплатить штраф — 5000 рублей. Или вовсе лишиться прав на срок до трех месяцев. Так и будет стоять ваш железный конь в стойле.

  Но не начинайте паниковать. У вас все еще есть 10 дней на то, чтобы подать заявление и получить номера. А вот выдавать номера помимо ГИБДД теперь будут и прямо на месте покупки авто. Правда, касается это только официальных дилеров. Для вторичного рынка правила пока прежние.

  От нарушений не застрахован ни один водитель. Зато есть возможность застраховаться от переплат при оплате автоштрафа. Платите картой «Мир» в мобильном приложении или на портале gosuslugi.ru без комиссии и получайте выгоду при каждой оплате, в том числе штрафов за парковку. Очевидный плюс для самого неочевидного штрафа!

  Lockdown у Європі та повернення з джунглів Болівії. Історії українських ІТ-спеціалістів, яких карантин наздогнав за кордоном

  Продовжуємо розповідати про українських IT-спеціалістів, які на час карантину залишилися за кордоном, — вимушено чи за власним бажанням. У першій частинібули історії тих, хто «застряг» у Кенії, Таїланді, Непалі та на Мадагаскарі. У цій частині про безпечне життя у В’єтнамі, повернення з джунглів Болівії, ситуацію в Португалії та Іспанії, пригоди з виселенням з готелів у М’янмі, а також про подовжений круїз у Південній Америці.

  Болівія

  Дарья Крутенюк, Consultant Delivery Manager в Infopulse

  Мое понимание слова «отдых» довольно специфично. Работать волонтером по шесть часов в день три недели подряд в условиях жары и высокой влажности in the middle of nowhere кажется мне отличной идеей. «Это будет классный опыт», — повторяла я, покупая билеты в Боливию. Тогда я еще не знала, что опыта я отгребу больше, чем могу себе представить.

  Цель моей поездки — небольшой центр спасения животных, который находится в джунглях Амазонки в Боливии, где я договорилась помогать. Долететь до города Ла-Пас, потом еще час на самолете в село Рурренабаке, потом 20 минут на лодке с бензиновым двигателем по реке — и я на месте.

  Три недели я работала со Spider monkey и с животными, которые находятся на карантине (не потому, что больные, а потому, что еще очень маленькие). В числе моих подопечных были коати, ленивец, squirrel monkey, странный грызун пакаи capuchin monkey. Наша цель была — адаптировать животных к самостоятельной жизни и «зарелизить» их в джунгли. Жили мы тут же, на территории центра в джунглях, в бамбуковых хижинах.

  

  На плече у Дарьи слева — коати, справа — squirrel monkey.

  Естественно, ни о каком вай-фае речь не шла. Мы знали одну пальму на берегу реки, до которой можно было прогуляться 20 минут, — под ней иногда ловил мобильный интернет. Таким образом, сидя под пальмой посередине джунглей, я узнала, что мой обратный рейс Ла-Пас — Мадрид — Киев отменили из-за неблагоприятной ситуации в Мадриде. Еще через несколько дней до нас дошел слух, что отменили авиасообщение между Рурренабаке и «большой землей», то есть по факту я оказалась заперта в небольшом селе.

  Когда я села на лодку и приехала в Рурренабаке в поисках жилья, интернета и решения своей проблемы — обнаружилось несколько неприятных фактов:

  • На каждом углу стоят военные с автоматами, которые проверяют документы.
  • На улицу можно выходить раз в неделю в зависимости от того, какая последняя цифра указана в паспорте. твой день понедельник, вторник и т. д. На улице можно находиться с 7 утра до 12 дня. Суббота и воскресенье закрыты для всех.
  • В большинстве своем местные не любят европейцев — можно услышать вслед крик «корона», когда идешь по улице. В хостел, где я нашла комнату, приходили почти каждый день с требованием «выселить этих больных». Были среди местных и нормальные ребята, которые хотели помочь, но в основном от нас шарахались несмотря на то, что в селе не было зарегистрировано ни одного случая вируса. Я понимала, что если будет зарегистрирован вирус, то я, вероятно, буду в беде. Что будет, если я заболею, я старалась не думать.
  • В Боливии тогда было всего два украинца, и второй находился максимально далеко от меня — на границе с Аргентиной.
  • Консул Боливии в Украине сказал, что шансов выбраться из Боливии нет, так как в Европу я не могу прилететь без билета в третью страну (то есть можно только транзитом), а авиасообщение с Украиной на тот момент было закрыто, как и все границы между европейскими странами.

  

  Получив от консульства рекомендацию почаще мыть руки, я поняла, что я тут надолго. Мой оптимистический прогноз был — до конца мая. Стала морально готовиться к двум месяцам заточения и анализировать хорошее:

  • Большинство гостиниц было закрыто, но несколько хостелов принимали «гринго» потому, что понимали, что нам некуда идти. И даже брали с нас меньшую оплату, чем в докоронавирусные времена.
  • Есть возможность делать большую закупку еды раз в неделю и можно давать небольшой список покупок соседям, которые выходят за едой в «свой» день. Есть кухня, чтобы готовить.
  • Есть внутренний дворик и соседи по хостелу. Можно быть на улице, можно перекинуться парой слов с соседями — это ведь лучше, чем сидеть одной в квартире в большом городе!
  • Есть быстрый интернет, а это значит, что я могу консультировать удаленно, зарабатывать деньги и наконец-то начать откладывать. Ведь тратить деньги тут некуда.
  • У меня с собой есть ноутбук! Да, я потащила в джунгли ноутбук «на всякий случай», предполагая, что буду смотреть кино по окончании рабочего дня. На самом деле ни разу его не открыла, но факт остается фактом: в этой глуши у меня есть компьютер!

  Через неделю бесконечного поедания манго (что очень скрасило мою жизнь) от украинцев, которые застряли в Непале, я узнала, что есть шанс выбраться через Европу, купив билет в Минск. Эта информация перевернула мое отношение к ситуации с ног на голову. Ведь одно дело сидеть в Боливии в глухом селе, зная, что ты не сможешь отсюда выбраться, а другое дело — знать, что где-то там летают самолеты, которые могут унести тебя домой.

  Я «включила менеджера», взяла телефон в руки и начала звонить. Действовать надо было быстро. Последний эвакуационный самолет улетал из Рурренабаке на следующий день после того, как я узнала, что могу покинуть страну.

  Мой путь домой:

  1. Рурренабаке — Ла-Паc на военном самолете, организованном Францией для эвакуации французов.
  2. Ночь в аэропорту Ла-Пас в надежде вписаться на один из рейсов (Лондон или Париж), которые отправлялись с этого аэропорта на следующий день.
  3. Чудом получила место на эвакуационный самолет в Париж несмотря на то, что меня не было в списках на посадку.
  4. Париж — Минск — регулярный рейс до Минска.
  5. Минск — Киев — блаблакар.
  6. Киев — Винница — такси.

  Организовать это все стоило мне немалых усилий и нервов, также мне очень повезло. Поддержка от консула была минимальная. Самое важное, что он должен был сделать — включить меня в списки на посадку на эвакуационные самолеты. Но по факту оказалось, что даже при наличии свободных мест меня не могут посадить на рейс, потому что меня в списках нет.

  Отдельная благодарность компании Infopulse за то, что не оставили меня в трудную минуту. Всю субботу и воскресенье, когда я организовывала себе обратный путь, была на связи со специалистами компании, которые бесконечно бронировали и перебронировали, оплачивали мне билеты «Париж — Минск», помогли организовать такси из Киева в Винницу, поддерживали морально и слушали мои сумбурные голосовые сообщения (извините, пожалуйста) 🙂 Также мне был перечислен доход за март намного раньше запланированного, чтобы у меня были средства на покупку билетов, если вдруг будет возможность улететь.

  Мое приключение завершилось хеппи-ендом, но я знаю, что много людей по-прежнему не могут добраться домой. Если есть вопросы, нужны детали, совет, моральная поддержка, помощь в коммуникациях — пожалуйста, пинганите меня. Может получится что-то придумать вместе, чтобы помочь вам вернуться в Украину.

  Круїзний лайнер. Південна Америка

  Настя Холодова, Software developer, кофаундер Vooptyи фаундер WOD Insight

  Я живу в Вашингтон ДС, США, с мужем, который тоже разработчик, родом из Запорожья. В конце декабря мой муж нашел круиз на корабле Celebrity Eclipse в Южную Америку: 1 марта сесть на корабль в Буэнос-Айресе, посетить Уругвай, дальше пингвины и самый юг Южной Америки Мыс Горн, проливы Дрейка и Магеллана, Чилийские фьорды. Финальная точка круиза — 15 марта в Сан-Антонио, Чили. В круизах мы никогда не бывали, как, собственно, и в Аргентине, Уругвае и Чили — решили, что эту ошибку надо срочно поправить.

  

  Национальный парк Аргентины Tierra del Fuego (Огненная Земля), южнее только Антарктида

  Когда мы улетали в конце февраля в Аргентину, коронавирус уже был на слуху, но Трамп все еще его называл «недогриппом», а вашингтонские бары были забиты людьми. Крузиная компания Celebrity предпринимала уже тогда меры безопасности и отказалась пускать на корабль всех, кто посещал Китай в последние 3 месяца. При посадке всем меряли температуру.

  Само путешествие было отличное, всем рекомендую, про его детали можете почитать у меня в инстаграм. Здесь я буду писать о том, что случилось 15 марта — в день, когда мы должны были высадиться в Сан-Антонио, Чили, уехать в Сантьяго, а оттуда улететь обратно в Вашингтон ДС.

  В 6 утра у всех в каютах раздалось обращение капитана корабля, который сообщил, что Чили в ночь на 15 марта отказалось принимать все круизники, независимо от того есть ли там люди с коронавирусом или нет. Такое решение правительство Чили приняло потому, что за день до этого другой круизник отправил в больницу Чили британского пенсионера с тяжелым случаем коронавируса. На борту же нашего корабля все были здоровы, со спаковаными чемоданами и готовы лететь домой.

  Большинство пассажиров были граждане или резиденты США. Два дня правительство Чили, США и руководство корабля безуспешно торговались о высадке. Чили дала четкий ответ «нет», как и все ближайшие страны Латинской Америки. Наш корабль согласились принять в Сан-Диего, Калифорния, куда плыть 10 дней. Чили нехотя согласилась нас заправить и загрузить еду, а также высадить пассажиров с чилийскими паспортами. Но в Сан-Антонио все равно не пустили, сказали плыть в Вальпараисо.

  Вот так наш круиз продлился еще на 2 недели, и мы поняли, что мы не только побываем в самой южной точке Америки, но и пересечем экватор на этом же корабле.

  Большинство пассажиров и команды к происходящему отнеслось по-философски: паники, ругани и мордобоев мы не видели. Мы читали новости из дома, где всех уже посадили на карантин, поэтому мы с мужем просто взяли свои лэптопы, нашли тихое место на корабле и начали работать. К тому же кроме очень медленного спутникового интернета, наши условия работы сильно не отличалась от домашних в худшую сторону.

  2 дня мы наблюдали прекрасные берега Вальпараисо, заправлялись, загружали еду и собирали список необходимых лекарств для продления вояжа (диабетики, сердечники и все, кто принимает жизненно необходимые лекарства ежедневно). На берег никому не разрешили выходить.

  19 марта (6 дней с последнего выхода на сушу) мы начали плыть на север. Вот с этого момента мне начали сниться кошмары: у COVID-19 инкубационный период 14 дней, что, если я им заболею, перезаражаю всех, и нас не пустят в Сан-Диего, будем там еще стоять, как «Принцесса» в Японии. Только стоять будем не так, как сейчас плывем — с открытыми бассейнами, ресторанами, театрами и тренажерным залом, — а будем сидеть по своим маленьким каютам, пока все не перестанем кашлять.

  В ночь на 24 марта (11 дней с последнего выхода на сушу) мы заправились еще раз в Эквадоре, а где-то в 10 утра гордо пересекли экватор.

  За исключением ночных кошмаров и медленного интернета, путь до Сан-Диего был очень даже ничего. Отличный ресторан «все включено», хороший и бесплатный алкоголь, никакого social distancing — пока во всем мире все закрывалось, мы отмечали день Святого Патрика. На корабле было человек 50 с украинскими паспортами, как пассажиры, так и ребята из команды. К концу вояжа мы все подружились и уже даже хотели поставить на самый большой стол в ресторане украинский флаг, чтобы никто не занимал.

  

  Слева — украинский стол на Celebrity Eclipse. Справа — экватор; никакой магии, порталов в параллельные миры и шлагбаума тоже нет. Просто вода, такая же, как 3 дня до него и 3 дня после

  30 марта (17 дней с последнего выхода на сушу) мы высадились в Сан-Диего и улетели домой в Вашингтон ДС. Все еще не температурим и не кашляем.

  P. S. На следующий день после прибытия в Вашингтон пришло письмо, что у нас на корабле таки были люди, позитивные на COVID-19. У женщины начали появляться симптомы в ночь на 26 марта, она с мужем просидела у себя в каюте, не выходя, до Сан-Диего, она сейчас находится в больнице.

  P. P. S. Я продолжаю переписываться с украинскими членами команды, они все еще на корабле. Отправить их домой не могут, потому что Украина отменила все авиасообщение. После того как мы причалили в Сан-Диего, среди них начали появляться заболевшие. Не совсем понятно — они заразились от женщины-пассажира или уже в порту Сан-Диего.

  Іспанія

  Константин Болотин, Project Manager в Sigma Software

  Мы с семьей (я, жена, дочка и теща) поехали в Испанию еще в феврале. Работаю удаленно и путешествую. Были две недели в Валенсии, затем неделю в Аликанте, неделю в Мадриде, неделю на Пальме-де-Майорке и вот последние четыре недели на карантине в Аликанте.

  Наш рейс в Киев на 26 марта отменили из-за карантина. Был спецрейс SkyUp из Аликанте, но дорогой — около 300 евро с человека, а нас здесь четверо, решили переждать. Купили билеты на 9 апреля, для справки, за 250 евро на всех с багажом — тогда они еще были, но и тот рейс отменили. SkyUp возвращать средства за отмененные рейсы не спешит и говорит, ждите ответа. Прошло уже 4 недели, ждем 🙂

  

  Находимся в Испании почти два месяца. Вариантов по возвращению сейчас нет. МИД призвало всех сидеть на местах и не ехать никуда до конца карантина. Также написали, что работают автомобильные пункты пропуска через Беларусь, но туда не добраться.

  Снимаем квартиру на Airbnb. Сейчас можно хорошо торговаться с хостами, так как им тоже любые деньги не помешают. Про сознательность испанцев: в первый день карантина хост квартиры отменил бронь с комментарием «with respect to the government» и написал, что извиняется, но он таким образом противостоит распространению вируса. Я на него не обиделся, а Airbnb довольно быстро вернул деньги.

  В Испании строгий карантин. Люди довольно сознательные, и их на улицах нет. Полиция патрулирует, чтобы не шлялись, и штрафует, если нарушают карантин. Можно выгуливать собаку и ходить за продуктами или в аптеку. Испанцы сдают собак в аренду за дорого 🙂 Полиция останавливает, если идем вдвоем с женой, но мы показываем купленные продукты, и они тут же отстают и просят держать дистанцию.

  При входе в супермаркет стоит специальный человек, который дает антисептик и протирает ручки тележек спиртовым раствором, что не может не радовать. Также в одном из супермаркетов организовали очередь на улице в полтора-два метра дистанцией и запускают всех порционно, чтобы люди не толпились в самом магазине и на кассах. Правильный подход. Продуктов в супермаркете валом любых. В первые дни карантина можно было увидеть полупустые полки с самой ходовой водой или самой выгодной туалетной бумагой, но всегда были альтернативы. Сейчас вообще нет никаких проблем с любыми видами продуктов.

  

  Каждый вечер в 20:00 начинается балкон-party. Местные выходят на балконы и шумят, аплодируют, свистят в поддержку работников медицины, полиции и продовольствия. Мы живем на этаже, обзор всего города, и видно, как весь город шумит. Сплоченные люди.

  МИД пока предлагает только консультационную помощь. Говорят сидеть там, где находимся, а особо нуждающимся обещают помогать даже материально. Из недавних новостей МИД проинформировал, что когда вернемся домой, то мы будем обязаны поехать на обсервацию куда-то, куда решит Киевская ОГА.

  Сейчас есть вариант только находиться в квартире, ждать окончания карантина и работать удаленно, как обычно.

  Португалія

  Сергій Дименко, Backend Developer

  В лютому я поїхав у тріп на 6 тижнів по Іспанії та Португалії. На початку березня біг Trans Gran Canaria Ultra Trail, після якого мав за два тижні проїхати Португалію і повернутися додому.

  За кілька днів після того як я перетнув кордон Португалії, Іспанія «ізолювалась» через пандемію, а це єдиний сухопутний кордон Португалії. За тиждень я відвідав південь та центр країни і заїхав на два дні до містечка Назаре, де щороку реєструють найбільші хвилі для серфінгу — до 20 метрів. Багато років мріяв сюди приїхати, бо люблю серфінг, і хотів побачити гігантські хвилі на власні очі. Далі планувався Порто, звідки я мав летіти до Кракова, але епідемія розпочалася на півночі, і Порто був очагом. На той час в Лісабоні почали закривати музеї, бари та нічні клуби, а на півночі вже вводили карантин. Аби не сидіти в готелі в Порто 5 днів, вирішив залишитися на узбережжі океану ще трохи.

  

  У цей час Польша закрила кордони для туристів і Ryanair скасував рейс. Почалися евакуаційні рейси Лісабон — Київ по €750 за квиток. Я вирішив залишитися, бо у квітні мав бігти трейловий стомильник у Хорватії, а Україна закривала кордони на 30 днів, і не було гарантій, що я зможу виїхати. За тиждень закрилася Хорватія і було скасовано старт, як і решту масових заходів у Європі.

  Вирішив, що я знаходжуся у суперовому місці, аби пережити світовий карантин, і вже третій тиждень живу у легендарному для серферів містечку на узбережжі Атлантичного океану. Карантинні заходи вводяться на регіональному, а не національному рівні, і у мене вони мінімальні, навіть частина кафе працює. З найжорсткіших обмежень — заборона купатися і засмагати на пляжі (серфінг заборонено також), але дозволено бігати і гуляти пляжами.

  Багато країн ЄС закрили готелі та хостели примусово, і це мій найбільший головний біль. Понад 10 днів я єдиний турист у готелі, і дуже хвилююся, аби його не закрили, бо ресепшн закритий вже 2 тижні, але я можу продовжувати проживання онлайн.

  Підрахував, що повернення до України обійдеться щонайменше $1500: $900 за авіа, якщо ціни залишать без змін, та $600 за найдешевшу обсервацію у безкоштовному готелі Козацький, де харчування коштує 1200 грн на день. Жаба давить, тому спробую пережити карантин у Європі, поки не закінчилися 90 днів безвізу. Уряд Португалії продовжив усі візи, що закінчилися після 24 лютого, до 30 червня, маю надію, те саме стосуватиметься безвізу. Крім того, уряд актом забезпечив нелегалів доступом до безкоштовної медицини, маю надію, що це стосується і туристів. Прочитав статтю, що українські страхові не покриватимуть лікування від коронавірусу після проголошення ВООЗ пандемії, бо це форс-мажор, досі в шоці, чекаю підтвердження.

  Щодня відслідковую ситуацію по епідемії, у радіусі 50 км від мене вже 20+ хворих. Кілька днів тому хворих в Португалії було 6500, з них 850 — медичний персонал. Будь ласка, подаруйте маску та перчатки сімейному лікарю в Україні, та донейтіть тих, хто забезпечує медиків захистом, бо за кілька тижнів Україну очікують такі самі цифри або гірші, бо лікарів було недостатньо, а стане ще менше. Медична система Португалії справляється. Наразі 8% хворих шпиталізовано, а 1,7% у реанімації.

  Зараз я ізолювався в готелі, працюю парт-тайм, благо, що є вид на океан з балкону. Раз на день бігаю або гуляю пляжем, мінімум 3 години марную з кавою на балконі, бо люблю океан, і можу дивитися вічно. Відчувається брак спілкування, вже почав розмовляти з чайками на дахах сусудніх будівель 🙂

  З останніх новин: на Пасхальні свята (5 днів) уряд запровадив драконівські обмеження: закрили аеропорти, перекрили хайвеї та виїзди з великих міст, зупинили більшість потягів на залізниці. Все це має обмежити пересування між областями. Власник закрив готель, де я був єдиним туристом останні 15 днів. Ще два тижні тому увесь персонал готелю відправили у відпустку, і я жив один у будівлі.

  За три тижні закінчується безвіз (90 днів), і я починаю панікувати, бо кордони ЄС закриті до 15 травня, і чи з’явиться хоч одна країна, відкрита для туристів зі сполученням з Лісабоном, невідомо.

  В’єтнам

  Ігор Семиженко, Product Consultant, Freelance

  10 січня я полетів зимувати в Таїланд з друзями. 29 лютого перебрався на острів Phu Quoc у В’єтнамі, де досі перебуваю.

  В Україну не поспішаю, оскільки В’єтнам — наразі найбезпечніша країна: на 8 квітня тут захворіла лише 251 людина з 97,34 млн населення. Серед них 126 одужали, і ніхто не помер. На моєму острові випадків вірусу не зафіксовано і сюди з 15 березня нікого не пускають. Планую залишитися тут, поки ситуація в Україні не стане безпечнішою.

  Була можливість повернутися останнім евакуаційним рейсом 29 березня, але відмовився. Не шкодую, бо бачив дикістьз виламуванням дверей в аеропорту. Крім того, це переліт на 12+ год з 260+ людей в одному літаку. І втратити 14 днів на примусову обсервацію після прибуття не кортить, коли ти ще здоровий.

  

  Я працюю як контрактор, займаючись R&D та валідацією нових бізнес-гіпотез. Окрім цього, почав валідувати власні ідеї, бо час змін = час можливостей. Віддалено працюю давно, і для мене мало що змінилося. Життя у В’єтнамі дешеве, тому витрачаю в кілька разів менше, ніж заробляю.

  Оскільки всі випадки вірусу зафіксовані на континенті, на острові всі лишаються розслабленими: ринки працюють, вулична їжа смажиться, поліцейських немає (та й не було наче). Тут зовсім інший світ, і вірус наче існує десь в паралельній реальності. Хіба що закрилися перукарні, спортзали, сувенірні лавки та деякі ресторани.

  Я орендую будинок у майже порожньому резорті. Перестав ходити на бокс, в бари, на побачення та інші місця з людьми. Вдома роблю йогу та функціональні вправи, придбав скакалку 🙂 На ринку купую овочі, фрукти, кокоси. Морепродукти також беру, прошу зварити в закладі поряд і везу все додому. Відчуваю, що тепер доведеться готувати вдома 🙁 Намагаюся зайвий раз не виходити з бункеру. Хіба що катаю на байку островом: порожні пляжі, джунглі, природа.

  Деякі правила, що дозволяють вижити:

  • Не виходити без маски та санітайзера для рук. Місцевих це дуже заспокоює.
  • Показувати всім, хто шугається, текст в’єтнамською: «Я живу на Фу Квоку з лютого і я не заражений». Як не дивно, працює 🙂
  • Їздити за їжею та покупками в одні й ті самі місця, подалі від скупчень народу. Власники впізнають мене і не лякаються. Ну і тримати дистанцію, хе-хе.

  В’єтнамці зреагували першими: з 17 березня закрили міжнародне авіасполучення, з 22 березня закрили кордони (крім надзвичайних випадків), робили експрес-тести. Якщо знаходять хворого, то одразу ізолюють контакти першого та другого рівнів, навіть за найменшої підозри. Маски всі тут носили й до вірусу через екологію, але з 15 березня це вже стало обов’язково для всіх.

  З 7 березня шлють інформаційні СМСки зі статусами. Є офіційний додаток з усією інфою, статистикою, інструкціями та апдейтами по вірусу в країні. Закрили в‘їзд до ізольованих місць — островів та гір та окремих провінцій — щоб вони такими і лишались. А всі, хто летить літаком, потрапляють у карантин на 14 діб про всяк випадок. З 1 квітня закрили міжміські сполучення, заборонили збиратися удвох і ввели повний lockdown. Обіцяють продовжити візи тим, в кого вони закінчуються.

  З огляду на швидкість змін у світі та заразність вірусу, вирішив лишитися поки тут. Як закінчиться віза, буду або подовжувати, або втечу у Таїланд, Камбоджу, Непал. Зараз ні в чому не можна бути впевненим, тому дивитимусь по ситуації.

  М’янма

  Евгений Голубев, Ex-CTO, Founder в SiteCraft Inc., Анна Голубева, Project Manager

  Преамбула. Когда мы вылетали из Киева, коронавируса ещё не было ни в Украине, ни в Тае, ни в Мьянме.

  Мы с женой решили оставить работу и сделать себе творческий отпуск на несколько месяцев. Все дела оставлены позади, куплены билеты в одну сторону, и мы начали своё путешествие с Таиланда. Планировали следующий маршрут: Бангкок -> Чиангмай и его окрестности -> Мае Хонг Сон -> Чиангмай и перелёт в Мьянму -> Сагаинг -> Мандалай -> Баган -> Инле -> Нгапали -> Янгон и перелёт в Бангкок -> острова Ко Чанг, Ко Мак и Ко Куд. Но в итоге наш план остановился на Нгапали (видео нашего путешествия есть также на YouTube).

  

  Мы прилетели в Мьянму марта. На тот момент там все так же не было ни одного случая коронавируса, но он уже начал распространяться по Украине и Таиланду.

  Первую неделю-две в Мьянме все было спокойно, никто не переживал из-за вируса, да и туристов почти не было. Самый экшен начался марта. В этот день мы приехали в Нгапали с озера Инле (где у нас не было интернета 3 дня!). Хозяйка отеля устроила нам допрос о том, где мы были, в каких городах, в каких конкретных числах и т. д. Как оказалось, в Мьянме коронавирус, в Таиланде эпидемия, границы закрыты и авиаперелеты отменены. И с тех пор каждый день происходил какой-то сюр.

  Сначала хозяйка отеля сказала, что, возможно, ей прийдется закрыть отель, но нас она, конечно, не выгонит. Потом сказала, что закроет в апреле, потом — что ей пришёл указ свыше закрыть отель марта. Указ пришёл, так как в 10 километрах от нас, в другом отеле у французских туристов нашли коронавирус. Поэтому весь Нгапали правительство решило закрыть для туристов. Уточню, Нгапали — это примерно как Шарм-эль-Шейх в Египте, но в Мьянме. Огромное побережье, кучи отелей разной ценовой категории и ресторанов.

  Туристы сначала были в шоке и не знали, что делать. Нас периодически закидывали фейковыми новостями о том, что начали убивать туристов, так как это они принесли вирус в эту страну. У нас образовалась компания «выживанцев», были мысли о том, чтобы снять виллу на 10 спален, но в итоге компания развалилась. Американцы, швейцарцы и россияне уехали в Янгон, а оттуда спецрейсами от их правительства домой. Нас осталось несколько человек, и мы начали судорожно искать хотя бы какой-то отель, который не закрылся.

  Хозяин одного гестхауса (Northern Star) разрешил нам с женой остаться у него. На тот момент у него уже жили три туриста — француз, американка и англичанин. Но они сидели на карантине, хозяин отеля запретил им покидать отель 14 дней. Мы решили что лучше уж этот вариант, чем ехать в Янгон (город с населением в 4,5 млн людей, загазованный, жаркий, без зелени) и пошли счастливые на пляж. На пляже мы случайно познакомились с туристкой из Америки, которая сказала, что живёт в отличном гестхаусе вместе с хозяевами, никаких ограничений по передвижению для туристов нет, и может договориться, чтобы нас приняли туда. Мы тут же пошли в этот гест (Power Guest House), хозяин подтвердил, что мы можем к нему переехать.

  В этот же день вечером туристы, которые сидели на карантине (Nothern Star), начали обвинять меня в том, что посещая пляж и гестхаусы, я разношу заразу и все люди в этом городе умрут только из-за меня (о-о). Мы приняли решение тут же переехать в Power Guest House. Ночью взяли вещи, такси, приехали. а заселять нас отказываются 🙂 Только благодаря нашей новой знакомой из Америки, которая 30 минут со слезами умоляла нас впустить, нас таки поселили. Перед тем как нам было разрешено зайти, нас и наши вещи облили хлоркой (дезинфекция), а также закрыли в отеле на карантин. Как оказалось, перед нашим приездом в Power Guest House приходили местные жители и настойчиво просили не пускать чужаков жить. Благо, что семья пошла нам навстречу.

  В итоге мы все ещё живем в этом гестхаусе, сдружились с семьей, они нас возят к разным достопримечательностям, кормят и развлекают общением каждый вечер. Вчера был последний день карантина, и мы теперь можем свободно перемещаться. Все остальные сотни отелей закрыты, всех туристов согнали в Янгон (в нем сейчас только три отеля принимают туристов).

  Больше случаев коронавируса за две недели в нашем регионе не было (всего в Мьянме на данный момент зарегистрировано 22 случая), местные люди выглядят дружелюбно. Мы с женой, наверное, — последние два иностранца на весь Нгапали.

  По поводу дороги домой — мы изначально и планировали путешествие на несколько месяцев, поэтому пока ещё не хотим домой. Тут сейчас безопаснее и комфортнее. Но надеемся, что через пару месяцев ситуация в мире станет лучше и мы сможем вернуться. Посольства Украины в Мьянме нет, но есть почетные консулы из местного населения. Они бесполезны. Единственная польза от них — написали официальное письмо для immigration office с просьбой продлить нам визу. Но это письмо оказалось бесполезным, так как правительство Мьянмы и так разрешило всем туристам продлевать визы на срок до 9 месяцев. Продлить визу (с штампом в паспорте) можно только в Янгоне. В местном офисе нам дали бумажный документ вместо визы, и мы не знаем, как много придётся заплатить при вылете из страны, так как информация поступает противоречивая.

  По поводу ситуации в стране в целом — тут все не так очевидно 🙂 Надо учитывать несколько факторов: у власти в стране находятся военные, скоро выборы. Правительство с целью не распространять фэйковые новости о короне ввела глобальный фаервол, который просто блокирует неугодные для власти сайты. Реальная картина: туризм закрыт до следующего года, мелкий бизнес и фабрики закрыты. Примерно то же самое, что и во всем мире. Картина на новостных сайтах Мьянмы: у нас все хорошо 🙂

  Как эффективно подготовить и провести ремоут-митинг

  April 13, 2020, 3:00 am

  Удаленная работа и работа в распределенной команде на сегодняшний день стали нормой — очень редко можно встретить ко-локейтед команду, которая может позволить себе роскошь проводить совещания в одном помещении. Более того, с повсеместным введением карантина личные встречи стали скорее исключением, чем правилом.

  Уже 9 лет я практически каждый день провожу распределенные митинги, когда участники находятся в разных локациях, при этом количество участников варьируется от 3 до 100 и более. За это время я понял, что такие митинги имеют ряд особенностей. И несмотря на то что об этом написаны уже сотни статей, некоторые из этих особенностей часто не учитываются. О них сегодня и поговорим.

  Для начала — несколько зарисовок, практически из реальной жизни.

  Митинг на карантине (или просто когда все работают из дома)

  Вы запланировали митинг с командой, скажем, для планирования спринта. Заранее отправили всем ссылку на Zoom, подготовили список тем для обсуждения. За пять минут до митинга вы пытаетесь стартовать конференцию и обнаруживаете, что связи нет. Вы проверяете свой ноутбук, затем роутер — всё вроде бы нормально, но соединение не устанавливается. Тут вы понимаете, что весь ваш подъезд тоже сидит на карантине и активно использует сеть, так что пропускной способности осталось совсем мало. Вы раздаете вайфай с телефона — и наконец подключаетесь. Но. прошло уже 5, а может, и 10 минут митинга.

  Ваши коллеги уже подключились и ждут вас. Вы начинаете митинг, рассказываете команде о цели спринта и приступаете к оценке элементов бэклога. Первым свою оценку высказывает ваш бекэнд-разработчик. Он детально объясняет, почему данная задача займет 16 часов его времени, но половину этого объяснения команда не слышит. На фоне постоянно слышен лай собаки с легким подвыванием — ведь другой ваш коллега, который на время карантина уехал в дом за городом, забыл выключить микрофон.

  

  Присоединяясь к митингу с улицы и используя внешний микрофон, вы рискуете добавить «лишних» участников

  После того как эта проблема решена, вы продолжаете обсуждение, и приходит очередь фронтэнд-разработчика. Он долго и в подробностях рассказывает о том, как собирается реализовать задачу — но его тоже практически не слышно. Причина — он использует внешний микрофон ноутбука, который передает звук, но очень нечетко — вместо речи вы слышите невнятное бубнение.

  Добавьте сюда людей, подключившихся с телефона и находящихся на улице, вездесущего соседа с перфоратором и детей, которые хотят поиграть с мамой/папой — и получите полную картину митинга.

  Встреча большой команды (townhall)

  У вас многочисленная команда, распределенная по нескольким городам, и вам нужно провести большую встречу и рассказать об итогах прошедшего года и планах на будущее. Карантина еще нет, так что вы, как обычно, собираетесь в офисе. В вашей самой большой локации есть зал человек на 70 — там поместится основная часть команды. Участники в других городах собрались по переговоркам, а кто-то подключился с места.

  Вы начинаете встречу. В своем вступительном слове благодарите команду за проделанную работу, говорите приятные и вдохновляющие слова. И в этот самый момент из динамиков доносится голос вашего коллеги, который просит жену купить хлеба: как это часто бывает, он не выключил микрофон и в самый неподходящий момент принял телефонный звонок.

  Вдоволь посмеявшись, вы продолжаете встречу и доходите до вопросов из аудитории. Ваши удаленные коллеги чувствуют себя обделенными: они не слышат вопросов, которые задают ребята из основной локации, ведь те находятся в одном зале, где «и так всё отлично слышно», так что они не используют микрофон. В результате удаленным коллегам приходится угадывать вопросы по вашим ответам.

  Более того, вы еще и забыли спросить, есть ли у них вопросы (либо не попросили написать их в чат) — в результате эффект от вашей встречи оказался намного меньше ожидаемого.

  Проблемы распределенных митингов

  Основные проблемы при проведении распределенных митингов чаще всего сводятся к таким:

  • участники плохо слышат друг друга;
  • участники слишком хорошо слышат фоновые шумы;
  • если одна из локаций представляет собой достаточно большое помещение, вопросы и реплики «из зала» обычно слышны только находящимся в этом зале, но не удаленным участникам;
  • если одна группа участников находится в одном помещении, а другие — удаленно, то последним, как правило, уделяется меньше внимания;
  • начало митинга затягивается из-за неработающего микрофона/динамика/камеры/экрана;
  • пропускной способности канала не хватает для видео и звука, в результате всё тормозит, а люди думают, что перебивают друг друга из-за задержек передачи голоса.

  Распределение участников по локациям

  Для начала необходимо понять, к какому типу относится ваш митинг:

  1. Рабочая встреча, в которой участники относительно равномерно распределены по локациям (и в каждой локации их немного — примерно до 3 человек). Этот же сценарий применим и для карантина — в этом случае каждый из участников находится у себя дома.
  2. Встреча, в которой участники также равномерно распределены, но их в локациях много (от 4 и более).
  3. Общее собрание большого коллектива (townhall), в котором основная группа находится в одной локации, а к ним присоединяется несколько удалённых участников.

  В первом случае имеет смысл проводить митинг целиком и полностью через средства конференц-связи, такие как Zoom, Google Meet и т. д. — таким образом вы создаете одно рабочее пространство и общий поток обсуждения на всех, каждый участник видит остальных (через видеотрансляцию или как аватары), не отвлекаясь на посторонние обсуждения с коллегами по переговорке.

  Если же участников в каждой локации много (второй случай), имеет смысл собрать каждую локацию в отдельной переговорке и организовать связь уже между комнатами. Такой формат позволит при необходимости разделиться на какое-то время (например, вы можете поручить каждой группе обсудить какой-то отдельный вопрос и затем представить его всем остальным). Побочный эффект такого варианта в том, что участники могут отвлекаться на разговоры с соседями по локации.

  В третьем случае (общее собрание) имеет смысл подключать удаленных участников непосредственно с рабочих мест, не собирая их по комнатам.

  Техническое обеспечение

  Вне зависимости от типа ремоут-митинга его техническое обеспечение имеет решающее значение. Опыт показывает, что следует обратить внимание на такие моменты:

  • Фасилитатор, или человек, отвечающий за техническое обеспечение, должен прийти в переговорку минут за до начала митинга, проверить оборудование и то, как оно работает в связке с выбранной системой для конференц-связи (Zoom, Google Meet, Skype и т.д.). Если вы используете оборудование или переговорку впервые, вам предстоит очень важный митинг либо вы еще не связывались ранее с какой-то из локаций, проверку имеет смысл провести не позднее чем за день — это даст вам возможность устранить технические недостатки либо придумать «план Б».
  • Если кто-нибудь из участников планирует демонстрировать что-то на экране (презентация, схемы и т. д.), нужно проверить также и режим демонстрации.
  • При этом важно помнить, что видеть вашу презентацию должны не только люди в вашей локации, но и все остальные (часто бывает, что демонстратор просто подключается к монитору в переговорке, вместо того чтобы использовать средства показа экрана в системе конференц-связи — так делать нельзя).
  • Говорить только в микрофон. Если это tawnhall, и у вас есть время для вопросов аудитории — позаботьтесь о том, чтобы найти отдельный микрофон, который участники будут передавать друг другу, задавая вопросы — иначе вопросы будут услышаны только в «центральной» локации, в то время как все остальные смогут лишь догадываться о том, что прозвучало.
  • Использовать качественные микрофоны в переговорках — чтобы всех участников, даже из дальнего угла, было слышно. Использование внешнего микрофона ноутбука в большинстве случаев — не вариант, так как они имеют узкую диаграмму направленности и подходят только для встреч Для более широкой аудитории нужно использовать отдельные микрофоны, подключаемые к ноутбукам (например, Jabra).
  • Если планируете рисовать что-то на доске, позаботьтесь о наличии камеры, которая будет смотреть на доску и картинка с которой будет видна всем удаленным участникам (можете взять отдельный ноутбук и поставить его так, чтобы камера «смотрела» на доску).
  • Если все работают из дома и доски нет, вы можете нарисовать что-то в блокноте и показать в камеру.
  • Удаленные участники, подключившиеся с рабочих мест, должны иметь хедсеты с микрофонами, закрепленными непосредственно на штативе, прикрепленном к хедсету — только так остальные будут слышать исключительно участника, без фоновых шумов из помещения, где он находится. Если же использовать хедсеты с микрофоном, размещенным на проводе или встроенным в наушники, то остальные будут слышать всё, что происходит на фоне, плюс звук трения микрофона об одежду участника. Вообще хедсеты — это отдельная тема. Многие компании в погоне за дешевизной покупают сотрудникам хедсеты, микрофоны в которых оставляют желать лучшего — пропускают фоновые шумы, искажают звук и т. д.
  • Использование внешнего микрофона ноутбука удаленным участником возможно, только если он в помещении один и там очень тихо, а кроме того, микрофон качественный и позволяет разобрать речь человека. В других случаях — только хедсет.

  

  Если все работают из дома и доски нет — можно воспользоваться блокнотом и ручкой и показать схему в камеру ноутбука

  Проведение митинга

  К удаленному митингу применяются все те же правила, что и к обычному: цель митинга, агенда и задачи участников должны быть четко определены, результаты митинга — хорошо задокументированы, фасилитатор должен обладать соответствующими навыками и т. д.

  Что касается специфики удаленных митингов, то проводя их, нужно помнить о следующем:

  • В начале митинга стоит спросить удаленных участников, хорошо ли им вас слышно, а также проверить, хорошо ли вы сами слышите их. Аналогично нужно спросить у них, видят ли они демонстрируемый вами материал.
  • При обсуждении какой-либо темы приоритет нужно отдавать удаленным участникам, всячески вовлекая их в беседу, так как им часто сложнее встроиться в диалог и вовремя задать вопрос/высказаться.
  • Следить за тем, чтобы обсуждение не превратилось в «разговор у доски» только одного-двух коллег — в этом случае вы теряете как удаленных участников, так и тех, кто в комнате. Кроме того, при таком развитии событий обсуждающие могут легко загородить обзор камере, направленной на доску.
  • Для визуализации текстовой информации лучше использовать средства коллективного редактирования документов (например, Google Docs) и демонстрацию экрана: картинка получается четче, чем на доске, а кроме того, участники могут редактировать документ совместно.
  • Те, кто в данный момент не говорит, должны отключать микрофон, чтобы избежать попадания фоновых шумов (звук от клавиатуры, голоса коллег) в общий эфир.
  • Не все участники будут готовы к тому, чтобы включить камеру — кто-то одет в домашнюю одежду, у кого-то в квартире беспорядок, кто-то просто не любит камеру. В этом случае не стоит заставлять людей включать видео — митинг должен быть комфортным для всех.

  

  Иногда вместо доски и камеры удобно использовать средства совместного редактирования документов (Google Docs и др.)

  Советы для участника митинга

  Если вы не занимаетесь организацией митинга, а просто участвуете в нём, вам также нужно помнить о некоторых правилах:

  • Если можете использовать хедсет — используйте его. Если нет — закажите в интернет-магазине. Из собственного опыта могу сказать, что хедсет — лучший вариант для распределенных встреч — вас будет четко и ясно слышно, а фоновые шумы не будут так сильно мешать. Есть замечательные беспроводные хедсеты, которые позволят вам ходить по комнате, обеспечивая при этом отличное качество звука для ваших собеседников.
  • Если хедсета у вас нет, то проверьте внешний микрофон ноутбука — сделайте тестовый звонок через скайп или с кем-то из коллег. Если вас слышно достаточно четко, можете использовать внешний микрофон. Но помните — многие внешние микрофоны имеют очень узкую диаграмму направленности: они заточены под то, что человек говорит «прямо в ноутбук», и как только вы немного повернете голову или захотите покрутиться в кресле, вас тут же станет плохо слышно.
  • Если и хедсета нет, и внешний микрофон работает плохо, у вас наверняка есть гарнитура для телефона — используйте её. Это лучше, чем ничего.
  • О фоновых шумах. Их быть не должно. Сделайте всё, чтобы их минимизировать (закройте окно и дверь в комнату, выключите фоновую музыку, найдите наиболее тихое помещение в доме, прогоните кота) — так вы проявите уважение к коллегам.
  • Еще один вид фонового шума, не всегда очевидный, возникает, когда человек неосознанно теребит микрофон на проводе хедсета или протирает поверхность ноутбука при использовании внешнего микрофона — не делайте так.
  • Выключайте микрофон, как только закончили говорить. Так вы избавите коллег от звука вашего тяжелого дыхания в стиле Дарта Вейдера. Также, если во время митинга вам нужно что-то печатать на клавиатуре, выключайте микрофон.
  • Не жуйте во время разговора. Это мешает четко произносить слова и попросту неприятно для окружающих.
  • Не перебивайте коллег. Даже офлайновая встреча становится невыносимой, когда говорит одновременно несколько людей. Что касается онлайна, то тут такое вообще недопустимо.
  • Помните, что иногда на линии могут возникать задержки — тогда люди могут думать, что их перебивают. В таком случае выдерживайте небольшую паузу перед началом своей реплики — так вы убедитесь, что собеседник закончил говорить.
  • Если позволяет пропускная способность, используйте видео — так вы сможете доносить невербальные сигналы своим собеседникам, максимально приближая формат встречи к офлайну.
  • Подключитесь к митингу минуты за три до начала — это позволит вам проверить все настройки.

  Выбор системы конференц-связи

  Систем для организации удаленных встреч сейчас более чем достаточно. Они отличаются по качеству передачи звука и картинки, возможности записать митинг, максимальному количеству участников, удобству работы и т. д. Кроме того, на выбор могут влиять внутренние политики безопасности компании.

  Мой личный рейтинг выглядит так:

  1. Zoom — однозначно лучшая, на мой взгляд, система. Имеет платные и бесплатные (с ограничением митингов до 40 минут) планы подписки, позволяет записывать митинги в облако и на локальный диск, отлично передает видео и звук даже при слабой связи.
  2. Google Meet — более требователен к каналу связи, однако удобен тем, что доступен всем, кто имеет Google-аккаунт (как персональный, так и бизнес-вариант). Запись митингов возможна только в одном из платных вариантов (наиболее дорогом).
  3. GoToMeeting — довольно старый продукт, обладает почти всеми возможностями, что и предыдущие две системы, но иногда имеет проблемы с качеством передачи звука и видео. Кроме того, менее удобный с точки зрения пользовательского интерфейса.
  4. Skype — по сути, не совсем система для конференц-связи, однако позволяет создавать групповые звонки и показывать экран. В моем личном опыте показывал худшие результаты на слабых каналах связи, однако может быть использован для удаленных митингов, если ничего другого под рукой нет.

  Заключение

  Все вышеизложенные рекомендации можно свести к нескольким основным принципам:

  • вас должны хорошо слышать;
  • вы должны хорошо слышать остальных;
  • время митинга не должно тратиться на подготовку и проверку связи, это нужно делать заранее;
  • эфир должен быть максимально чистым, без фоновых шумов;
  • культура проведения митинга в онлайновом режиме играет еще большую роль, чем в офлайне.

  Следование этим принципам поможет вам проводить митинги максимально комфортно и эффективно.

  Напоследок хотел бы выразить благодарность всем коллегам, давшим согласие на публикацию скриншотов со своим участием.

  5 книжок для QA — початківців та досвідчених, від Юлії Пилипенко, QA Lead в MEGOGO

  April 14, 2020, 12:00 am

  Від редакції: у рубриці DOU Booksспеціалісти розповідають про 5 своїх улюблених книжок — ті, які змінюють світогляд та корисні читачам-колегам.

  

  [Про автора: Юлія Пилипенко — QA-спеціаліст із досвідом. Активно проводить тренінги для тестувальників-початківців і координує інтернів у компанії]

  Книжками про тестування я почала цікавитися близько 12 років тому — стільки ж працюю в цій галузі. Саме ці книжки є хорошою базою і допомогли «виростити» чимало новачків. Вони підійдуть усім, хто хоче ознайомитися з професією тестувальника програмного забезпечення, збагатять світогляд і принесуть користь QA різного рівня: як джуніорам, так і досвідченим спеціалістам. Більшість рекомендованих видань не нові, проте їх важко назвати застарілими. Вони досі актуальні й популярні серед багатьох досвідчених QA. Поради, описані в цих книжках, достатньо прикладні та корисні. Думаю, про деякі книжки ви чули, але якщо раптом не читали — саме час це виправити.

  Усім новачкам у тестуванні рекомендую починати з першої книжки цього списку. Фахівцям Junior і Middle раджу спробувати практики кожної книжки зі списку. Саме так свого часу робила і я при підготовці тестів. А Senior-спеціалістам рекомендую ще раз переглянути ці книжки вже «іншим поглядом», адже аналізуючи, завжди можна знайти для себе щось нове.

  Роман Савин «Тестирование DOT COM, или Пособие по жестокому обращению с багами в интернет- стартапах»

  

  Це книжка, з якої варто почати знайомство. Вона підійде для тих, хто ще не чув про тестування і хоче ознайомитися з цим напрямком, а також для спеціалістів рівня Junior. На відміну від інших багатотомних та інколи нудних посібників, цей добре ілюстрований і живою, зрозумілою мовою розповідає про тестування програмного забезпечення та IT-технології. Автор подає інформацію досить лаконічно, просто і з гумором, ділиться власним досвідом, накопиченим під час роботи в американських компаніях.

  Книжка складається з чотирьох частин. Перша пояснює, що таке баги й Quality Assurance, розповідає про цикл розробки програмного забезпечення, підготовку тест-кейсів та інше. У другій частині читач дізнається детальніше про методи тестування. Третя розкриває етапи підготовки до тестування й описує етапи його виконання. Четверта частина відповідає на актуальні для новачків питання: як знайти роботу в IT-галузі, як поводити себе на співбесіді, як досягти бажаного в професії, як влаштуватися на хорошу роботу без досвіду та багато іншого. Особливістю книжки є те, що для закріплення матеріалу після кожного розділу зібрані додаткові завдання.

  Це мій перший посібник з тестування і, думаю, найвдаліший як для початківця. Поради та приклади в ньому розкладено по поличках — усе, що потрібно новачку. Книжку важко назвати художньою, але я читала її саме як таку — не могла відірватися. Єдиний мінус у тому, що видання орієнтоване на читачів початкового рівня, тому детальних інструкцій (наприклад, щодо складання тестової документації), ви там не знайдете.

  Святослав Куликов «Тестирование программного обеспечения. Базовый курс»

  

  Якщо ви вже прочитали попередню книжку, наступною точно має бути саме ця. Вона корисна спеціалістам рівня Junior і вище. Основою для книжки став багаторічний досвід автора у проведенні семінарів для QA У ній добре розкрито головні поняття, які необхідні для роботи тестувальника-початківця. Видання дає відповіді на багато питань, з якими часто стикаються саме новачки. Автор розглядає популярні міфи, помилки, припущення та способи розв’язання різних проблем. Важлива особливість книжки — її чітка й послідовна структура, велика кількість таблиць і класифікацій. Наприкінці кожного розділу є завдання, а також корисні посилання для більш поглибленого вивчення матеріалу. Ще кориснішою робить книжку історія автора про те, які особистісні риси (soft skills) повинен мати спеціаліст.

  Подекуди книжка дещо перевантажена додатковою інформацією, але це не можна назвати недоліком. На мою думку, вона також може бути корисною для досвідчених QA, адже допоможе систематизувати набуті знання, нагадає про деякі «детальки», що забуваються.

  До речі, книжка розповсюджується в електронному форматі, тому постійно доповнюється новою актуальною інформацією.

  Testing Computer Software, by Cem Kaner, Hung Q. Nguyen, Jack Falk

  

  Це книжка, яку варто прочитати всім спеціалістам, починаючи з рівня Junior. Проте, на мою думку, вона більше підійде не новачкам, а фахівцям з досвідом, які мінімум рік пропрацювали в професії і близько знайомі з тестуванням. Книжку без перебільшення можна назвати справжньою класикою. Дехто її відзначає як ключову для QA. Вона велика за обсягом, написана непростою мовою, але в жодному разі не застаріла. Від інших відрізняється передовсім прив’язкою до умов реального світу на прикладі відомих компаній-розробників Кремнієвої долини. Автори ґрунтовно розглядають широкий спектр питань: від організації процесу Quality Assurance до власне тестування документації, коду, проєкту тощо. Знаю, що мало хто долає цю книжку бодай до половини, але, хоч як голосно це звучить, викладена в ній теорія здатна підготувати фундаментальну базу знань.

  На мою думку, недоліками книжки є не зовсім послідовна структура тем і те, що автори не описали процесів тестування для agile-методів розробки. Проте в усьому іншому це справжній must read для кожного спеціаліста.

  Rapid Testing, by Robert Culbertson, Chris Brown, Gary Cobb

  

  Російською — Роберт Калбертсон, Крис Браун, Гэри Кобб «Быстрое тестирование»

  Ця книжка підійде для спеціалістів рівня Middle та вище. Доволі не нова, але тут зібрані найкорисніші приклади формального підходу. Книжка складається із трьох частин: перша розповідає про сам процес швидкого тестування, друга містить методи та поради з прикладами, а третя надає широкий список шаблонів тестової документації. У книжці розглянуто повний життєвий цикл тестування.

  Автори мають багаторічний досвід і сильний бекграунд, інформацію подають академічною мовою, тому часом її важко сприймати. Використовуючи власний практичний досвід, автори розповідають, як модернізувати процес Quality Assurance, не докладаючи додаткових часових зусиль. Коли я вперше побачила назву, подумала, що будуть банальні поради про те, як зробити все швидше, а виявилась чудова фундаментальна книга, з якої можна дізнатися, як робити і швидко, і якісно. Саме це потрібно в роботі QA.

  Хотілось би відмітити, що у книжці добре викладено матеріал про тестування вимог, але підходи до процесу описано радше для waterfall-моделі розробки. Та, зрештою, описаний метод швидкого тестування дає універсальні поради щодо виявлення основних проблем на ранніх стадіях розробки. Впевнена, що книга стане досить корисною для фахівців, які працюють як у великих, так і малих організаціях, що створюють програмне забезпечення.

  A Practitioner’s Guide to Software Test Design, by Lee Copeland

  

  Книжка буде корисною для QA-спеціалістів різного рівня. Книжка доволі вузькоспрямована: розповідає лише про дизайн тестів і не розглядає питань планування та організації процесу тестування. Проте тут ви можете знайти як нові методи, так і поглиблений опис уже відомих. Так, наприклад, у книжці описано сім підходів до тестування за методом «чорної скриньки» та декілька методів «білої скриньки». Тут нічого зайвого, лише корисні та практичні приклади з таблицями й діаграмами, зрозумілий опис технік і додаткові поради. Великим плюсом є наявність висновків та переліку робіт інших авторів з розглянутої теми. Можу порадити цю книжку як чудовий посібник для підготовки до проходження професійної сертифікації. Її однозначно має прочитати кожен спеціаліст.

  Наразі книжка представлена лише англійською, але завдяки цьому можна підтягнути свій рівень іноземної, насолодитись оригіналом, уникнувши неточностей перекладу.

  16-річний програміст із Черкащини – про те, як 11-класником влаштувався на роботу зі зарплатнею майже $1000

  April 14, 2020, 3:00 am

  У 9 класі Антон Вітренкоз міста Звенигородка на Черкащині зацікавився інформаційними технологіями, пройшовши курс основ програмування СS50. Після того впродовж року він самотужки та на курсах опановував JavaScript, інші технології — щоб зрештою в 11 класі стати фронтенд-розробником у компанії Preply. Про те, як вчився, проходив співбесіди та чому вибрав роботу замість університету, Антон Вітренко розповів нам у інтерв’ю.

  — Як ти зацікавився програмуванням? Які технології і як почав вивчати?

  

  Антон — зліва

  Я сам із Звенигородки, невеликого міста на Черкащині, де загальне уявлення про IT перебуває на рівні «це щось, пов’язане з комп’ютерами». Але два роки тому до нашої школи завітав Андрій Насадчук — він тут народився, потім поїхав навчатися до Києва, став програмістом. Разом із командою друзів він розробив проєкт, як перетворити Звенигородку на smart city. У його межах організував літній курс інформаційних технологій — курс основ програмування СS50 від Гарвардського університету, щоб навчити молодь програмувати.

  Сам Андрій допомагав вирішувати проблеми, які виникали під час виконання домашніх завдань. Хоча я тоді, окрім власне школи, займався ще бальними танцями, кікбоксингом, грою на фортепіано, все ж вирішив спробувати пройти ще й ці курси, бо цікавився ще й комп’ютерами загалом. Із кожним заняттям програмування затягувало мене все більше. Найкрутіше враження — коли з чистого редактора коду, з порожнечі можу створити щось своє, унікальне. Що далі просувався, то більше хотів щось робити.

  Після закінчення курсу Андрій запропонував мені, як студенту, що перебував у топі, більше заглибитися в практику, а саме — в Ruby on Rails, оскільки він сам рубіст. Мені сподобалася логіка фреймворку, почав ще більше вчитися. Нас збиралося троє хлопців, ми писали на Ruby on Rails: створили кілька додатків, телеграм-бота. Потроху я почав розуміти: не моє. Усвідомив, що більше приваблює фронтенд, частина роботи, яку бачить користувач. Не хотів верстати кнопки на HTML і CSS.

  Тоді Андрій познайомив мене зі своїм колегою, який на той час влаштувався фронтенд-девелопером до однієї компанії. Я почав спілкуватися з ним із приводу JavaScript та інших технологій. Він же розповів мені про Mate Academy. А поки що я вивчав JavaScript як міг. Двома моїми основними ресурсами були MDN і learn . javascript . ru. Також звертався по допомогу до Андрія, коли виникали якісь питання. За кілька місяців я вирішив, що готовий спробувати потрапити до Mate Academy, пройти тестове завдання, поспілкуватися.

  Тоді я навчався у 9 класі. Перша співбесіда з ейчаром не була успішною — я завалив лайв-кодінг. Загалом тоді я вважав, що дещо знаю, на практиці ж виявилося: не знаю нічого. Ейчар відправив мене розв’язувати алгоритмічні задачі. Так я ознайомився з Codewars і LeetCode, розв’язував на платформі. Тепер я не просто багато читав, а й міг розв’язувати задачі і розвивати логіку.

  Так я ходив до школи і вчив програмування. Восени вирішив податися на навчання ще раз, бо вирішив, що вже достатньо розвинув логіку. Цього разу склав кодінг і пройшов.

  — На якому етапі навчання ти почав шукати роботу?

  Вчитися було нелегко, особливо на початку. Я цілими днями сидів над завданнями, оскільки темп виявився шаленим. Розумів: щоб кудись потрапити, маю працювати більше, ніж будь-коли. У вересні, як зазвичай, ходив до школи, все було доволі розслаблено, а коли в жовтні стартувало навчання на курсах, почався «виніс мозку». До години треба було впоратися з завданнями курсу, а ще домашні завдання зі школи. Тоді батьки написали заяву про перехід на екстернат. Я мав писати контрольні роботи та складати заліки, без необхідності відвідувати всі уроки.

  Відтак я, можна сказати, на фултаймі зайнявся навчанням. Завжди хотів бути в топі — можливо, давався взнаки синдром відмінника, але як поставив собі за мету, так і перебував завжди на перших позиціях рейтингової таблиці. Напередодні Нового року ми почали складати резюме і подаватися на вакансії. У середині січня, після 3,5 місяців навчання, я влаштувався на роботу в Preply. Але цьому передувало ще кілька співбесід із іншими компаніями.

  У межах навчання є заняття, присвячені тому, як складати резюме та як підготуватися до технічної і ейчар-співбесіди. Але скільки б не готувався, доки сам не потрапиш на першу співбесіду, не зрозумієш, що це таке. Перша технічна співбесіда, яку я пройшов, була з компанією Tower IQ. Я доволі хвилювався. Прийшов до офісу, почав говорити — і на якомусь етапі зрозумів, що дечого не знаю. Спочатку питання були більш-менш простими, а потім почалися ті, відповіді на які не знав узагалі: як співпрацює клієнт із сервером, як відправляються дані. Тоді просто посипався.

  Та, з іншого боку, я зрозумів, як все відбувається. Пощастило, що ця компанія була першою, з якою я мав технічне інтерв’ю, бо фронтенд-девелопер, який проводив співбесіду, підказував, що і куди, коли я відповідав неправильно. На адреналіні, який я тоді переживав, матеріал запам’ятовувався швидко. Того ж дня, але пізніше, я мав технічну співбесіду до іншої компанії на Лівому березі. Уже з цим невеликим досвідом, щойно здобутим, поїхав до них.

  Порівняно з першою співбесідою, питання були вже суперлегкі: наприклад, що нового з’явилося в HTML5. Там у відповідях відірвався на повну. Після того пройшов ще кілька співбесід онлайн, але вони були приблизно однакові, на них уже мав відповіді. Та жодна компанія не відповіла позитивно — гадаю, здебільшого через мій вік. Це було перше питання, яке я чув, заледве переступивши поріг.

  — Як склалася історія з Preply, куди ти зрештою потрапив?

  Спершу мені написав ейчар з курсів: він сказав, що передав мої контакти одній компанії. Невдовзі після того мені написав ейчар із Preply: пропонував здзвонитися. Після того я пройшов телефонний скринінг, після цього виконав тестове завдання і отримав запрошення на об’єднану співбесіду (технічну та ейчар). Мене не запитували з порога, скільки мені років, але цього разу я сам першим спитав, як вони ставляться до юних працівників. Артем, ейчар, відповів, що жодного ейджизму в них нема, що в них працюють студенти Та все ж був трохи шокований, дізнавшись, скільки мені років.

  На технічній співбесіді я моментами дещо тупив, моментами, навпаки, розказував усе доволі гарно. Загалом залишилося враження, що в Preply були не такі каверзні питання, як в інших компаніях, — більше пов’язані з логікою, із тим, як я мислю, а не просто матеріал, який можна і так почитати у Вікіпедії. Компанія кілька днів не повідомляла результат, я провів цей час у напруженні. Коли сидів на занятті з фізики, зі мною зв’язався ейчар і запропонував офер. Після цього почалися підготовчі процеси.

  

  Хакатон в ІТ-школі

  — Як обумовлювали рівень зарплати?

  Коли на співбесіді ейчар запитав мене, на яку суму я претендую, озвучив дещо вищу, ніж планував на початку. Аргументував це тим, що належить платити ще відсотки за курси та за оренду житла. Після того ейчар перепитав, в яку суму оцінюю власне свою роботу, якщо не брати до уваги ці чинники. Зрештою, погодилися майже на 1000 доларів на місяць (точну суму не можу розголошувати) + поза тим компанія платить 17 відсотків щомісяця за мої курси.

  — Як складав резюме? Що написати в ньому, коли ти ще школяр?

  Передусім, я ніде не вказував вік. Почав із summary, написав, що я юний і вмотивований програміст, який завжди прагне дізнаватися щось нове. Вказав також свій рівень англійської, який у мене Upper-Intermediate, тому мав про що написати. Потім я склав табличку скілів, розписав усе, з чим працював або що знав: наприклад, вказував MySQL, SQL — з ними поглиблено не працював, але знав, як і що працює.

  Спершу я мав кілька версій, як оформити резюме. Склав у ньому портфоліо, куди виклав проєкти (всі, що робили на курсах), підписував, які технології для чого використовував, і створював лінки (один на GitHub, щоб подивитися код, інший — на gh-pages, щоб глянути результат). Але коли почав заповнювати портфоліо, і в ньому з’являлося все більше робіт (дійшло до 5), зрозумів, що треба створити окремий лінк на документ із портфоліо, бо в резюме все не вміщалося. Ще акцентував на самоосвіті: розписав, як і з чого почав вчитися, згадав курси, онлайн-ресурси.

  Тоді, за порадою рекрутерів однієї з компаній, до якої ходив на співбесіди, вказав досвід у двох напрямах: фронтенд-девелопер, learning to program. Навіть якщо я ніде не працював офіційно, такий досвід принаймні засвідчить, із якого часу я думав у напрямі IT. Крім того, я мав кілька місяців роботи на фрилансі — намагався практикуватися, не беручи за це грошей. Десь писав скрипт, десь міг заверстати кнопку — мав натхнення вечорами щось створювати. Рекрутерам відразу чесно казав, що це не суперзаняття, та все ж це мій фриланс.

  В останньому пункті Awards вказав, що маю сертифікат з англійської від Cambridge English, також зазначив, що вирішив понад 80 задач на code wars, згадав і про інші сертифікати, які хоч якось були пов’язані з IT. З усього разом склалося моє резюме.

  — Чи вистачало тобі технічних знань, коли проходив співбесіди?

  Вважаю, що так. Необхідного базису, «подушки» знань, якої мало бути достатньо, вистачало. Уже коли проходив співбесіди, зрозумів, чому коли на курсах нас готували до цього, акцентували на розумінні питань, а не просто заучуванні, та на основних моментах, які справді відіграють роль у роботі. Маленькі і каверзні питання, які ставили в компаніях, було доволі легко зрозуміти та довчити у процесі співбесід. Але основу, теоретичне розуміння браузера, JavaScript я мав — і, вважаю, це головне, що має бути.

  

  Чернівці, літній табір, в якому Антон робив перші кроки у програмуванні

  — Наскільки впевнено почувався на співбесідах?

  Не був супервпевненим у собі, бо знав, що з самого початку мої шанси нижчі, ніж у решти осіб із курсу: 16 років, ризик для компанії. Та з іншого боку, мав бажання всім (а перш за усе — собі) довести, що як мінімум спробую це зробити, що пройду десяток співбесід і не припинятиму, доки не досягну бодай якогось результату. Також мотиватором стало те, що хтось у групі влаштувався на роботу — отже, це реально, просто мені треба докласти більше зусиль.

  — Чи плануєш тепер здобувати вищу освіту? Вступатимеш до університету?

  Ще не вирішив точно. В університетській освіті як передумові для роботи наразі нема потреби. Ймовірно, вона може знадобитися, щоб більше розвинути алгоритмічну логіку. Та якщо порівняти технології, які використовуються на практиці та в університетах — останні, безумовно, відстають. Тож іти до університету на спеціальності IT конкретно за новими технологіями не бачу потреби.

  Я спілкувався з багатьма людьми, які працюють у цій сфері, і виробив таке уявлення: здобувати вищу освіту в українських реаліях в IT варто для того, щоб, імовірно, розвинути потужнішу логіку та підхід до розв’язання задач. Синтаксис розвивається, з’являється багато інструментів — це все можна вивчити самотужки. Але алгоритмічна логіка, яка відповідає за те, як розв’язати ту чи іншу задачу, пов’язану з даними, здобувається в університеті. Чи потрібен диплом як папірець з університету — цього я для себе ще не вирішив. Нікому, кого я запитував, диплом не знадобився. Хіба що при переїзді до іншої країни, наскільки мені відомо, наявність диплома відіграє важливу роль. Ще розмірковую над цим.

  Та й зараз мені подобається працювати, розв’язувати багато завдань — не хочу звільнятися з компанії заради того, щоб йти кудись вчитися. Якщо трапиться варіант знайти реально достойну освіту та буде нагода поєднувати навчання з роботою, щоб це не впливало на її якість — готовий на це. Можливо, піду на заочну форму навчання, та це один із ймовірних варіантів. Нині для мене пріоритетна робота — я пройшов такий довгий шлях не для того, щоб тепер просто все покинути задля навчання. Тим паче, робота прив’язує, гарна компанія і дружній колектив.

  — Як зреагували батьки на те, що ти фактично залишаєш школу і не збираєшся опісля до університету?

  Щоб вирішити для себе остаточно, йти на курси чи закінчити на стаціонарі школу, я взяв аркуш паперу, маркер і почав розписувати всі «за» і «проти». Батьки сприйняли це нормально. Гадаю, на мою користь спрацювало те, що коли мене не взяли з першого разу, я не забив, продовжив займатися, сидів усе літо і вчився. Саме це навчання переконало батьків у серйозності моїх намірів: я не покинув працювати, я готовий рухатися в цьому напрямку. Хоч і не з першого разу, але потрапив на курси, на які хотів, та знайшов роботу.

  — Чим тепер займаєшся у компанії, які твої обов’язки?

  У Preply цікава технологія розподілу на команди. Уся компанія поділена на команди, які виконують частину User Flow до того, як клієнт придбав пакет послуг. Зараз я у команді, яка займається inbound-процесами. Її мета — зробити життя користувача на перших кроках якомога привабливішим. Усе дуже подобається, я щодня готовий брати на себе більше: мені дають задачі, і я знаю, що в процесі роботи багато вчитимуся, розумітиму нові речі. Компанія використовує багато технологій, із якими я не був знайомий досі (такі як A/B тестування, GraphQL, Next.js). Також подобається команда: коли виникають якісь питання, допоможуть, підкажуть — це може бути хтось із моєї команди чи загалом із компанії. Так само маю простір для самостійної роботи і експериментів — таким чином розвиваюся.

  Не маю якихось труднощів через свій вік — навпаки, відчуваю себе достатньо дорослим для роботи тут. Здобув самостійність, якої прагнув раніше.

  — Ким бачиш себе в майбутньому, у яких напрямках хочеш розвиватися, де жити?

  Хочу розвиватися як у технічному плані, так і в алгоритмічному. Це те, що відрізняє синьйора від джуніора: що з більшою кількістю проблем він зіткнувся, то більше кваліфікації отримав. Так само хочу підвищувати свою кваліфікацію, виконуючи все складніші завдання. З місцем проживанням поки не визначився. Наразі мені хочеться залишатися в Україні, тут комфортно для IT-сфери.

  Какая техническая экспертиза нужна проджект-менеджеру сегодня

  April 15, 2020, 12:00 am

  Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

  За 5 лет в разработке я сталкивался как с чистыми гуманитариями в IT, так и с теми, кто перешел в PM’ы с технической позиции.

  И мне, как разработчику, оказалось легче договариваться с менеджерами, у которых есть хотя бы базовые технические знания. Тем более сегодня, когда все коммуникации серьезно просели в условиях удаленки. Если PM знает, как происходит процесс разработки, это экономит кучу времени и сил всей команде.

  В статье расскажу, что значит базовая техническая экспертиза в моем понимании. На практических примерах посмотрим, как знание процессов разработки помогает менеджеру эффективнее управлять проектом.

  Еще минутка мотивации: почему технические знания важны для PM’а

  

  Давайте сразу разведем технический бэкграунд и экспертизу. Технический бэкграунд — это когда человек пришел в PM’ы с технической должности. Например, был тестировщиком или писал код. Такой опыт может помогать, а может и мешать в работе, если менеджер путает роли и занимается не своим делом. Для PM’а ценится умение понимать, что делают разработчики, но не делать работу вместо них.

  Что точно важно для PM’а, так это техническая экспертиза — понимание, как работают технологии, которыми пользуется команда.

  Менеджер без технических знаний:

  • Не может понять эстимейт: отводит на задачу неоправданно много времени или, наоборот, эстимейтит слишком оптимистично — и команда срывает дедлайн.
  • Слабо различает зоны ответственности в команде, кто в чем виноват, кому адресовать задачу. Например, с кем говорить, если поплыл логотип на сайте? С дизайнером или веб-мастером?
  • Не может объяснить клиенту сложность или выгодуопределенных решений. Часто 80% работы бэкенда абсолютно не очевидны для пользователей (например, оптимизация компонентов системы), но без этой технической части продукт не будет работать нормально.

  Приведу пример, как технические знания помогают PM’у эстимейтить задачи и принимать решения. Допустим, команда выпустила в продакшн приложение с функцией загрузки картинок. В какой-то момент изображения перестали загружаться. PM советуется с разработчиком и выясняет, что есть два варианта решения: пофиксить все за три дня или решить быстрее, но в будущем могут появиться проблемы в работе приложения.

  Какой вариант правильнее выбрать? Учитывая, что приложение уже работает и люди им пользуются, три дня на исправление — это слишком много. Выгоднее внедрить быстрое решение, а потом постепенно «разруливать» технический долг.

  Менеджеру с технической экспертизой проще понять внутреннюю кухнюи ответить на вопросы заказчиков без дополнительных синхронов с разработчиками.

  Как распределяются роли в команде

  

  Разобраться, кто за что отвечает, — это базовый уровень технических знаний для PM’а. Дальше посмотрим на практическом примере, кому адресовать разные задачи, если что-то пошло не так.

  В создании любого приложения или сервиса задействованы 5 компонентов: Design, Backend, Frontend/Mobile, QA, SysAdmin/DevOps. За каждую составляющую в команде отвечают разные специалисты. Когда менеджер различает сферы ответственности, то не будет отвлекать фронтенда, если долго обрабатываются запросы.

  • Дизайнер (UX и UI Design) — создает дизайн и выделяет бизнес-требования, продумывает сценарий пользования. Несет ответственность за то, как будет выглядеть продукт и насколько удобно взаимодействовать с сайтом или приложением. Все должно быть продумано, расположение кнопок интуитивно понятно. От дизайна во многом зависят задачи фронтенда и бэкенда.
  • Backend — пишет логику и API (интерфейс приложения), чтобы с этим могли работать фронтенды или мобильные разработчики.
  • Frontend или Mobile — заботится о том, как работает видимая, клиентская часть сайта (Frontend) или приложения (Mobile).
  • QA (тестировщик)—тестирует продукт на соответствие оговоренным требованиям и стандартам качества. Самая важная цель тестировщика — это не количество выявленных багов на этапе тестирования, а чтобы пользователи не находили дефекты после релиза продукта.
  • SysAdmin/DevOps — следит за тем, чтобы все важные части приложения были доступны 24/7 и отлаженный процесс доставки кода происходил непрерывно. Это тихий наблюдатель, который работает параллельно со всеми процессами «в фоновом режиме». Чаще всего работу сисадминов или DevOps не замечают до тех пор, пока что-то не сломалось. Если все идет как надо, работа DevOps’а так и остается незаметной.

  Мы посмотрели на отдельные компоненты разработки, теперь давайте разберем, как распределяются зоны ответственности в команде на примере практической задачи.

  Игра: кому адресовать задачу

  Давайте представим, что от заказчика поступает ТЗ: создать MVP сайта по сокращению ссылок, на котором пользователь сможет:

  • регистрироваться/логиниться;
  • создавать сокращенные ссылки;
  • смотреть статистику по ссылкам.

  Логика в таком приложении очень простая: есть основная ссылка и то, до чего она сокращается. Когда запрашивают сокращенную версию — приложение отдает настоящую.

  Допустим, наш сервис по сокращению ссылок запустили в работу и посыпались первые баги от пользователей. Проблемы появляются разные, и хорошо, когда PM понимает, на кого ставить задачу исправить конкретный баг.

  Рассмотрим на примерах:

  • График переходов по ссылке не рисуется в Safari.А в Chrome все происходит как положено. С такой ошибкой нужно подходить к фронтенду, потому что разбираться с отображением данных в браузере — это его работа.
  • Не собирается статистика переходов по ссылкам.Пользователи переходят по созданным ссылкам, но обновления статистики в консоли не видно. Здесь сможет помочь бэкенд, так как подсчет переходов — задача, не связанная с отображением данных, это исключительно внутренняя логика, которая живет на бэкенде.
  • Ссылки долго открываются для пользователей из Латинской Америки.В Европе ссылка открывается за 300 миллисекунд, а в Латинской Америке — 1,5 секунды. Вероятнее всего, это задача для DevOps: надо либо настроить DNS, либо продублировать сервер приложения где-то в регионе Латинской Америки.
  • При попытке открыть сайт появляется ошибка 500.Это один из случаев, когда не получится сразу идентифицировать, чья проблема. Скорее всего, решать будут бэкенд вместе с DevOps’ом.
  • Не работает создание новых ссылок.Есть какая-то форма на сайте, ее надо заполнить, ввести длинную ссылку, нажать «сохранить» — и получить сокращенный аналог. В какой-то момент эта форма перестала работать.

  У такой ошибки может быть несколько причин:

  • бэкенд выдает 500 ошибку, и ссылка не формируется;
  • на фронтенде что-то сломали, поэтому не передается параметр, который показывает, что пользователь авторизован. Тогда ссылки не будут сокращаться, потому что бэкенд не считает пользователя авторизованным;
  • возможно, проблемы на стороне DevOps: упал один из серверов и сайт показывается, но вся логика заблокирована.

  Кому-то приведенные выше примеры покажутся элементарными, но без понимания этих элементарных вещей менеджер рискует неправильно адресовать задачи. Когда так происходит много раз, люди отвлекаются, нервничают, возникают ненужные конфликты.

  Даже с технической экспертизой найти решение бывает непросто, потому что есть много проблем, которые лежат на пересечении зон ответственности специалистов. Не всегда получится сразу идентифицировать источник проблемы, особенно если он связан с взаимодействием компонентов системы. На такой случай у PM’а есть самый важный инструмент — коммуникация. Всегда можно пообщаться и спросить.

  А вот чтобы коммуницировать правильно, менеджеру нужно иметь хотя бы верхнеуровневые представления о зонах ответственности каждого специалиста.

  Понимание основ разработки — это базовый уровень технических знаний PM’а. Следующий этап — прокачивать навыки оценивания вместе с командой.

  Понимание эстимейтов

  

  Без технической экспертизы менеджеру трудно адекватно заэстимейтить общее время работы даже над одной задачей. Всегда есть ситуации, когда разработчики либо преувеличивают сроки, либо, наоборот, говорят слишком оптимистичный эстимейт, и потом команда не успевает, потому что работа заняла не 5 запланированных часов, а 15.

  При оценивании количества часов на разработку PM’у важно уметь декомпозировать задачу, разбивать решение на небольшие пункты. Как только задача декомпозирована, становится яснее, о чем идет речь в эстимейтах, что предстоит делать разработчикам.

  Приведу такой пример. Бэкенд может быть написан на PHP, а может — на Java. PHP отрабатывает запросы быстро, а Java — это отдельное приложение, которое постоянно крутится в ожидании запросов. В зависимости от языка программирования, время на исправление ошибки будет разным. В случае с PHP, можно быстро запушить изменения с сервера, фактически незаметно для пользователя. В случае с Java, чтобы все заработало, надо пересобирать весь бэкенд сначала. Если РМ понимает разницу между языками, он не будет рассчитывать, что ошибку поправят быстро, не будет ругаться, что прошел уже целый час, а разработчик все еще не пофиксил проблему.

  Другой пример о разнице эстимейтов в работе фронтенда и мобайла. Код фронта для нового пользователя каждый раз запрашивается браузером с сервера. Поэтому, даже если где-то допустили ошибку, вопрос ее срочного исправления — дело одного часа. Мобильное же приложение пользователи загружают через App Store: не факт, что у них включено автообновление, плюс нужно учесть время, пока ваш билд пройдет аппрув. Поэтому стоимость ошибки получается совсем другая

  Как происходит оценка на практике

  Допустим, что в наше приложение для создания сокращенных ссылок нужно добавить оплату через PayPal.

  Сначала решаем, кто из команды понадобится:

  • дизайнер: создать дизайн страницы, модального окна или окна в мобильном приложении, на котором будет происходить оплата;
  • фронтенд и бэкенд, чтобы написать логику;
  • QA, чтобы протестировать весь процесс по итогу работы команды.

  Теперь PM’у нужно понять, за сколько времени можно достичь цели. Поставленную задачу заэстимейтили фронтенд и бэкенд.

  • Фронтендоценил работу в 4 часа, включив туда верстку, логику запрос/ответ на бэкенд — и все.
  • Бэкендоценил задачу в один месяц: написать новые таблицы в базе данных, логику запрос/ответ к серверам PayPal, API, с которыми будет работать фронтенд.

  Оценка фронтенда выглядит реалистично. Когда есть задача, например написать «модалку», чтобы можно было платить через PayPal, то 4 часа кажутся вполне подходящим сроком.

  Затем PM начинает декомпозировать задачу, и выясняется, что фронтенд учел не все пункты. То, что верстка должна быть адаптивной, адекватно выглядеть на мобильных устройствах и в разных браузерах.

  Когда PM с командой проговаривает составляющие задачи шаг за шагом, то приходит понимание пропущенных шагов: верстка может включать дополнительные опции, логика — тоже. Фронтенду надо будет обрабатывать ошибочные ответы от бэкенда.

  То же самое с бэкендом. Когда озвучены все части задачи, например создание новых таблиц базы данных, логика запрос/ответ, API, могут появиться граничные условия, которые могут пойти не по плану.

  Допустим, с новыми таблицами в базе данных вопросов нет, также как и с логикой запросов для фронтенда. У нас рабочее приложение и, скорее всего, ребята договорились, в каком формате принимают и отдают данные.

  Зато сложность появляется при работе с PayPal. Если на логику запросов к PayPal заэстимирован один месяц, безо всякого основания, то такая оценка будет нереалистичной и малопредсказуемой без достаточных данных.

  Прежде чем оценивать, надо собрать статистику по спринтам и, исходя из нее, выстраивать какие-то гипотезы.

  Из своего опыта могу сказать, что мы ведем статистику, как разработчики справляются в спринтах, и выявляем коэффициенты для каждого из них. На эти коэффициенты мы потом и умножаем эстимейты. Чаще всего средний коэффициент у разработчиков — 1,6. Ребята, у которых коэффициент — 1,5 и ниже, имеют хороший показатель, достаточно прогнозируемый.

  С абсолютной точностью оценить сложность задачи и время на выполнение не получится: как только появляется взаимодействие между людьми, все гарантии перестают быть чем-то вещественным. Но умение декомпозировать помогает PM’у лучше ориентироваться в сроках, адекватно оценивать как крупные фичи, так и весь проект в целом.

  Итоги

  

  PM с технической экспертизой:

  • различает зоны ответственности специалистов в команде;
  • понимает, к кому с какой проблемой обращаться;
  • умеет декомпозировать задачи и оценивать эстимейты вместе с командой;
  • может обосновать заказчику выгоду определенных решений или сложность задачи.

  Конечно, человек может прийти в PM’ы из абсолютно гуманитарной сферы, и я знаю вполне успешные примеры. Если компания согласится обучать нового специалиста, то знания придется нарабатывать в процессе руководства проектом. Учиться и одновременно решать задачи по проекту будет нелегко, поэтому лучше заранее понимать, кто чем занимается в команде, что делают разработчики, из чего состоит система.

  PM с технической экспертизойпонимает больше, умеет больше, а значит, у него больше шансов найти хорошую работу даже во времена кризиса.

  «Мене скоротили». Історії IT-спеціалістів, які залишилися без роботи через коронакризу

  April 15, 2020, 3:00 am

  На початку квітня редакція DOU опублікувала результати опитування щодо карантину. Тоді 30% ІТ-спеціалістів вказали, що їхні компанії вже почали втрачати клієнтів/проєкти, а 16% — що компанії стали скорочувати персонал. Ми поспілкувалися зі спеціалістами, яких уже скоротили, і дізналися, як керівництво пояснює звільнення, чи виплачують компенсації та як справи з пошуком нової роботи.

  Евгений, Senior Front-end Developer, Харьков

  

  Я занимаюсь программированием 10 лет и за это время сменил 3 компании. В последней успел поработать тимлидом чуть больше года. Мне все нравилось, был хороший проект, связанный с банками. Компания аутсорсинговая, в ней работают больше ста сотрудников. Когда начали появляться новости о коронавирусе, я думал, что меня сокращения не коснутся. Это же IT, суперстабильная сфера. Но оказалось не так.

  В конце марта нашему отделу сообщили, что клиент отменил все свои проекты. Соответственно, работы нет и всех, кроме 4 человек, среди которых был я, попросили уйти. 31 марта сообщили, что оставят только одного специалиста, который работает в компании больше 10 лет, на поддержку старых проектов.

  На прошлой неделе был релиз проекта, а 14 апреля — мой последний рабочий день. Я заканчиваю свои таски и передаю проект человеку, который его ни разу не видел. В 2015 году я работал в другой компании и там закрыли полностью remote-отдел, но тогда нам дали хорошую компенсацию и помогали вакансиями. Сейчас ситуация совершенно другая. В текущей компании нам, кроме зарплаты за последний отработанный месяц, выплатят отпускные, но только те, которые накапали с января 2020 года, то есть это Если ты не отгулял отпуск за 2019 год, его никто не компенсирует.

  У меня большой опыт в разработке, но все равно есть небольшая нервозность, поскольку возросла конкуренция на фоне того, что многие ищут работу. Но к ситуации с сокращением я отношусь спокойно. Меня уволили не потому, что я плохо работал, просто нет проекта, чтобы обеспечить мне занятость. Я активно ищу новое место, за последние три дня прошел 10 собеседований, есть пару офферов. Некоторые рекрутеры упоминали об остановке проектов, связанных с туризмом. Предлагают те, которые связаны с брокерскими системами, системами онлайн-обучения. Многие компании при общении говорят о том, что расширяются и набирают новых людей. Возникает диссонанс — одни сокращаются, другие расширяются. Как это работает?

  Тарас, Full Stack Developer, Львів

  

  Я працюю програмістом 10 років, маю досвід як бекенд і фулстек-розробник. Останні 9 місяців — у невеликій продуктовій компанії, безпосередньо з клієнтом з данської фірми. Вона працює у сфері консалтингу, мобільних технологій і зв’язку.

  З початком карантину ми отримали інформацію від нашого проджект-менеджера, що ситуація непроста не тільки для нашої компанії, а й для багатьох інших, і що нас триматимуть у курсі. Вже 25 березня менеджер повідомив: оскільки невідомо, що буде далі, фірма змушена припинити контракти з кількома фахівцями. Я працював над продуктом, який ще не був в активній фазі продажу, тож ніхто не знав, чи будуть у нього клієнти. Фірма не могла дати фінансових гарантій, і зі мною та моїм колегою припинили співпрацю.

  Я з розумінням ставлюся до цієї ситуації. До того ж у мене ще є час допрацювати до 25 квітня, а це місяць з моменту рішення. Додаткових компенсацій не передбачено. Також менеджери сказали, що, якщо проєкт відновиться, зі мною будуть раді продовжити співпрацю. Я уже маю кілька варіантів того, що робитиму далі. Можливо, з’явиться позиція на інших проєктах у нашій компанії, а може, буду фрилансити. Почав більше цікавитися UpWork, налаштував свій профайл. Співбесід поки не проходив. Думаю, до кінця квітня краще розумітиму, що робити далі. Жодних образ на компанію не тримаю. Ми не чужі люди, будемо зберігати гарні стосунки.

  Мария, проектный менеджер, Киев

  

  В проектном менеджменте у меня 2,5 года опыта. Последние полгода работала проджект-координатором в компании, которая специализируется на электронной коммерции, разработке и поддержке интернет-магазинов. В ней 400+ человек, в киевском офисе 100+, остальные работают в Польше, Швеции, Великобритании.

  Я обожала это рабочее место, меня устраивало здесь абсолютно все: коллектив, офис, проекты, инструменты, клиенты. 11 марта я еще ходила по офису, делала кофе, сидела в переговорках на митингах с клиентом. 12 марта нас собрали и объявили, что компания отправляется на карантин, а приблизительно через неделю начались проблемы. Я вела два проекта, оба — продажа дорогой одежды. Один из них заморозил работу до октября, по второму тоже непонятная ситуация. Понимая, что у меня не хватает загрузки, обратилась к эйчару: возможно, есть работа у других клиентов, например контент пописать, чтобы пережить кризис. К сожалению, такая ситуация у всех, загрузка упала.

  31 марта нам позвонил СЕО и объявил, что сегодня сократят энное количество человек. Я сама позвонила эйчару, так как догадывалась, что буду в их числе, и попросила дать знать как можно скорее. Мне сказали о сокращении 31 марта, моим коллегам — 1 апреля, что добавляло юмористическую нотку в данную ситуацию.

  Мне позвонили эйчар и директор киевского офиса, и было видно, что им самим непросто преподносить информацию о сокращении. Они объяснили, что, так как проекты заморожены, у них нет другого выбора. Мне дали хорошую компенсацию в виде отпускных и зарплаты за апрель, в котором я не работала ни дня.

  В LinkedIn я поменяла баннер, поставила статус Open for new opportunities и начала листать ленту. Последнее лучше вообще не делать, так как становится страшно. Появились посты от рекрутеров в стиле «Те, кто ищет работу, пожалуйста, не пишите в личку, вас очень много. Вот вам гугл-форма, вот вам Excel-таблица, вносите туда опыт, контакты, зарплатные ожидания, мы с вами свяжемся». Если неделю назад рекрутеры сами звонили-писали, вели какой-то диалог, то в пик кризиса «внесите данные в таблицу, не беспокойте».

  Отправив несколько резюме, я подумала о том, что сотни проектных менеджеров с таким же опытом и больше сейчас также рассылают резюме. Если программисты кормят компанию, то проджект-менеджеры, эйчары, маркетологи — это сопутствующий персонал, их урезают в первую очередь. Было реально страшно.

  Попадались рекрутеры, которые присылали документ с расписанным интервью, где нужно написать огромное письмо с техническим бэкграундом, причинами сокращения и всей информации о себе. Подразумевается, что рекрутер получит от всех кандидатов ответы и будет анализировать, кому отвечать, кому нет. Однако есть рекрутеры, в общении с которыми ничего не поменялось. Благодаря им у меня на выбор сейчас лежат два оффера, из которых я выберу новое место работы.

  Меня приглашали на собеседования либо крупные компании из ТОП-20 по Украине, потому что им размер позволяет держаться на плаву, либо аутсорсеры среднего размера. В основном предлагали работу над продуктами и мобильными приложениями. Когда я узнала, что сокращена, и оценила ситуацию в LinkedIn, думала, что буду искать работу где угодно по своей специальности и не перебирать. Ожидала, что придется снизить зарплатные ожидания, однако мои опасения не оправдались. В конечном итоге мне предложили проекты, с которыми я бы работала и вне кризиса, а в плане заработной платы я только выиграла.

  Денис, DevOps, Київ

  

  Я родом з Хмельницького, торік працював на швейцарську компанію. Коли ти граєш у нижчій лізі і відчуваєш, що зріс професійно, час переходити до вищої. В моєму місті не було перспектив, і 4 місяці я шукав роботу в інших регіонах України. У січні 2020 року разом із сім’єю переїхав до Києва і влаштувався у невелику компанію зі штатом до сотні людей. Замовником багатьох проєктів є держава — наприклад, працювали із системою електронного квитка. Я займався здебільшого моніторингом наявних проєктів та їхнім осучасненням.

  У березні мав закінчитися мій тримісячний випробувальний термін. Я розумів, що через карантин настає криза, і думав, що ми просто перейдемо на дистанційну роботу, максимум компанія скоротить зарплати. Коли надійшов лист від директора з проханням зібратися усією компанією, я на це й розраховував. Але замість того, щоб обговорити подальше працевлаштування, мені пояснили, що проєкти заморозили, компанія не може оплачувати роботу. Керівництво запропонувало відпустку за свій рахунок, але натякнуло: якщо я знайду іншу роботу, ніхто не образиться. Відпрацьовану зарплату виплатили в повному обсязі, але компенсацію не запропонували. Можливо, їхні бізнес-процеси не були готові до такої кризи.

  Зла на компанію я не тримаю, але розумію, що нову роботу потрібно знайти якнайшвидше, щоб мати змогу залишатись у Києві. Я шукав її восени, і сьогодні ситуація зовсім інша. Активність рекрутерів зросла в рази. В жовтні я писав пости, сам стукався до рекрутерів, а цього разу мені достатньо було написати один пост у LinkedIn. За 5 днів він набрав 41,5 тисячі переглядів, посипалися вакансії. Останні чотири дні я ходжу на співбесіди, як на роботу: поки з одним розмовляю, інший вже додається і надсилає пропозицію.

  Проблема в тому, що я досить специфічний кандидат. Для більшості вакансій треба мати досвід роботи з Cloud (AWS, Google Cloud Solution, Alibaba, DigitalOcean, OpenStack), а я з ним не працював. Доводиться відмовлятись від співбесід просто через те, що не підходжу за стеком. Поки шукаю роботу тільки через LinkedIn, восени користувався Djinni, але помітив, що вакансії там дублюються. Наразі є вірогідність 50/50, що я повернуся назад у компанію, коли закінчиться карантин і з’явиться проєкт для мене.

  Назарій, .NET-розробник, Львів

  

  Я працюю розробником приблизно два з половиною роки, планую розвиватись на full stack. За цей час попрацював у двох компаніях, в останній чотири місяці, якраз закінчував випробувальний термін. Компанія велика, 300+ співробітників, займається як аутсорсом, так і продуктами.

  Коронавірус скоротив бюджет компанії, і всіх новеньких, яких набрали на перспективу, відправили у вільне плавання. Я працював на проєкті, що орієнтований на офлайн-продажі. У нинішній ситуації клієнт вирішив відкласти його до червня. В компанії іншої роботи для мене не знайшли, але дали ще два оплачуваних тижні на пошук нового місця. Фактично, я вже не працюю, але звітую про те, що проходжу співбесіди.

  Звичайно, трошки образливо, бо я 4 місяці працював, спеціально вивчав специфічні саме для цього проєкту технології. Але така ситуація у світі та країні. Я вже мав п’ять інтерв’ю з ейчарами та дві технічні співбесіди. Щодня моніторю вакансії. Сьогодні на мою позицію величезна конкуренція. Чотири місяці тому, коли я шукав роботу, щодня з’являлося по дві нові вакансії з .NET. На початку минулого тижня я одразу знайшов але за цей тиждень не з’явилось жодної нової. Видно, на ринку зменшилася потреба в програмістах. Але все залежить від галузі. Наприклад, компанії, що мають орієнтир на онлайн-замовлення, музичні плеєри, онлайн-кіно тощо, продовжують набирати людей і працювати. У вакансіях, які я бачив, пропонують різні сфери: є медицина, є онлайн-продажі та багато інших. Рекрутери, як завжди, дуже привітні та комунікабельні.

  Андрій, Front-end Developer, Львів

  

  Я займаюся розробкою 4 роки, змінив 3 компанії. В першій у Тернополі працював трохи більше ніж півтора року, потім переїхав до Львова. На останньому робочому місці працював півтора року. Фірма аутсорсингова, в офісі близько 200 людей. Три місяці тому мій попередній проєкт закінчився. Я ніби на бенчі, хоч і працював над внутрішнім проєктом. Зважаючи на ситуацію у світі, я очікував, що мене можуть скоротити, оскільки робітники на бенчі не приносять грошей компанії.

  Один доволі великий проєкт заморозили, і на бенч потрапило ще більше людей. Це вдарило по компанії. Нас зібрали на груповий дзвінок і повідомили, що змушені всіх звільнити, оскільки з новими проєктами туго. Сказали, якщо щось з’явиться, то з нами сконтактують насамперед. Це все відбулось 10 квітня, як компенсацію мені виплатять повну зарплату за квітень.

  Не можу сказати, що я сильно засмучений, буду шукати щось нове. Повноцінні пошуки розпочну наступного тижня, поки що тільки оновив резюме та додався до таблиці, яку створив Роман Кушнарьов для тих, хто шукає роботу.

  Олексій, Front-end Developer, Київ

  

  Я займаюся розробкою понад 4 роки, на останньому робочому місці працював 3 місяці, якраз мав закінчитись випробувальний термін. У мене був проєкт, пов’язаний з обслуговуванням будинків, наприклад клінінгом. Наступного тижня буде реліз проєкту, і невідомо, чи буде клієнт його продовжувати, оскільки карантин не дає продукту працювати. Керівництво повідомило, що наступний місяць мені шукатимуть проєкт. Якщо його не знайдуть, доведеться розійтись. Фактично, мені продовжили випробувальний період і відправляють на бенч після релізу.

  Я думаю, що в такій ситуації будь-яка компанія робитиме щось схоже. Це такий превентивний метод, щоб не постраждати. Є майже фантастична версія, що мені знайдуть проєкт. Тоді я з радістю залишусь. Але в будь-який момент може піти ще якийсь клієнт й інший фронтенд-розробник компанії буде без роботи. Тому реальний варіант — це завершити тут роботу. Я вже сьогодні шукаю нові варіанти. Створюється враження, що вакансій утричі менше, ніж раніше. Раніше я відкривав Djinni й одразу було 15 пропозицій, тепер за тиждень у мене їх 6. А коли починаєш писати, може виявитися, що деякі з них уже на холді.

  «Буде обмежений бюджет і менше персоналу». ІТ-спеціалісти про те, як криза вплине на технології та індустрію

  April 16, 2020, 12:00 am

  Економічний спад, пришвидшений світовою пандемією, уже вніс корективи в ІТ-ринок. Крім того, що співробітники перейшли на дистанційну роботу, компанії почали скорочувати операційні витрати, заморожувати проєкти та найм спеціалістів, урізати зарплати й навіть звільняти працівників. Які ще зміни чекають ІТ-галузь у найближчому майбутньому?

  Редакція DOU запитала у досвідчених ІТ-фахівців різних напрямів про те, чи зміниться попит на технології; як криза вплине на бізнес, найм, компанії різної величини; до чого готуватись уже зараз.

  Валентин Кропов, Engineering Director у SoftServe

  

  Чтобы понять, что ждет всех нас в общем и IT-индустрию в частности в ближайшей и долгосрочной перспективе, нужно разобраться, что такое кризис и как он влияет на происходящее.

  У кризиса есть явное проявление. Это чаще негативные (например, рост безработицы), но иногда и позитивные последствия (улучшение экологии). Некоторые из них уже настали (закрытие магазинов), а некоторые еще впереди или настанут с высокой долей вероятности (замедление роста ВВП развитых и развивающихся стран). Есть и неявное проявление кризиса: это чудовищная неопределенность, которая не позволит сказать, что еще плохое (или хорошее) может произойти. Отличие ситуации, которая сложилась сейчас, от предыдущих кризисов заключается в том, что в этот раз мы наблюдаем невероятный рост неопределенности и неявных проявлений кризиса. О некоторых их них мы пока даже не догадываемся.

  IT-компании научились достаточно хорошо и эффективно справляться с явными проявлениями кризиса. Например, быстро уменьшают издержки, сокращая штат, арендные площади, вычислительные мощности в Cloud, отправляя сотрудников в бесплатные отпуска. Компании гораздо хуже подготовлены к неявным проявлениям кризиса и неопределенности. Я уверен, что именно фактор неопределенности является ключевым в принятии решений по существующим и новым IT-проектам. И именно работа с неопределенностью станет ключевым изменением ландшафта проектов и технологий, которые будут развиваться после подобного кризиса.

  В этом смысле стоит предположить, что наиболее востребованы будут проекты, которые позволят минимизировать неопределенность и максимально уменьшить издержки компаний во время тех или иных изменений.

  Из того, что уже явно происходит на рынке, можно предположить, какие следующие типы проектов, продуктов и технологий будут все больше набирать обороты.

  Проекты и технологии, позволяющие экономить. Бизнес в краткосрочной перспективе будет акцентировать внимание на проекты, которые позволяют сэкономить, причем быстро (Golang, Python, Kotlin, Scala). Например, RPA-проект, благодаря которому можно автоматизировать работу 10 сотрудников и уменьшить тем самым штат компании. Такого рода решения всегда были востребованы, но во время и после кризиса они могут стать ключевыми для выживания бизнеса.

  Динамическое масштабирование вычислительных систем и бизнеса. В условиях неопределенности важно оставаться гибким: уменьшать издержки во время спада и иметь возможность быстро восстановить «пропускную способность» бизнеса во время роста. Например, перенос вычислительных мощностей в Cloud однозначно ускорится, и такие гиганты, как AWS, GCP и Azure, однозначно от этого выиграют.

  Быстрый результат. Неопределенность не позволяет строить долгосрочные планы и проекты, рассчитанные на Они все больше остаются в прошлом. Компании хотят видеть быстрый результат в течение нескольких недель или месяцев. Технически это означает, что будут более востребованы технологии и языки программирования, благодаря которым прототипы, Proof-of-Concept и MVP можно создавать быстрее. Это даст бизнесу раннюю пользу и определенность, что в проект стоит инвестировать дальше. Это также означает, что на рынке Software Development Services будут более востребованы те компании, которые имеют внутренние наработки или продукты, способные ускорить получение результата. Ну и, конечно, продуктовые компании, которые могут точно и быстро решить определенную проблему.

  Ускоренная автоматизация физического мира, а не только цифрового. Многие из цифровых решений, которые были созданы за многие десятилетия, призваны создать отображение физического мира в цифровом. Классический пример — ERP или CRM-системы, которые отображают в цифровом виде то, что происходит физически в компании. Такие системы нужны для того, чтобы согласовать физический и цифровой мир. Но чем больше будет автоматизироваться физический мир, тем меньше такое согласование будет необходимо. Например, автоматизировав работу продуктового магазина (Amazon Go), отпадает необходимость в системе учета рабочего времени и планирование смен сотрудников. До сих пор количество проектов в цифровом мире значительно больше автоматизации физического мира. И это то, что будет существенно меняться после подобного кризиса. Такие технологии, как IoT, Robotics, XR, RPA, примененные к здравоохранению, розничной торговле, логистике и безопасности, станут ключевыми в ускорении автоматизации физического мира.

  Все сказанное выше есть исключительно моей собственной позицией и может не совпадать с позицией компании SoftServe.

  Володимир Рожков, Solutions Architect в Devlify

  

  Сьогодні ми спостерігаємо найбільший у світі експеримент із впровадження віддаленої форми роботи. Я сподіваюся, що компанії переглянуть своє ставлення до цього. Технології, які дають змогу людям працювати з будь-якого куточка світу, існують уже десяток років, але ми не бачимо відповідного прогресу в індустрії розробки. Найбільші гравці ринку (як вітчизняні, так і закордонні) досі вимагають від людей ходити в офіс та сидіти в душному опенспейсі. І далі розвивають цю лінію (маю на увазі, наприклад, будівництво нових офісів Apple/Amazon).

  Карантин змусить компанії переглянути методології та звернутися до досвіду тих, хто працює без офісів уже давно. Звісно, багатьом працівникам такий режим не підійде з різних причин. Як і деяким компаніям (особливо тим, що мають справу із «залізом»). Я сподіваюсь, що після карантину всі більш лояльно ставитимуться до віддаленої роботи. Відповідно зросте (та й він уже зріс) попит на якісні інструменти комунікації для координації роботи розподілених команд.

  Хоча, якщо бути чесним, нині і так багато людей працюють у розподілених мультинаціональних командах, просто чомусь сидять в офісах. Ще у 2009 році я займався проєктом, де вся команда та менеджмент були в різних офісах. А я ж у своєму був сам. Я працюю віддалено вже третій рік поспіль і вважаю, що за цим майбутнє. Просто воно настає дуже повільно.

  Щодо технологій розробки, розвитку фреймворків, мов тощо, то не думаю, що тут радикально щось зміниться. Багато серйозних опенсорс-продуктів і так розробляли розподілені команди в асинхронному режимі. Тому технічно для них нічого не зміниться.

  Віддалена робота — перший крок на шляху скидання кайданів традиційного восьмигодинного рабства. Закликаю всіх користуватися можливістю та робити висновки.

  Руслан Шевченко, Research & Development Consultant at Garuda . AI

  

  Технології та напрями розробки пов’язані із соціумом не прямо, а радше через типове використання їх у певній галузі. Думаю, тут можна говорити про, умовно кажучи, теоретичні та прикладні напрями.

  Щодо теоретичних напрямів (наприклад, мов програмування), то їхня популярність не сильно залежить від пандемії. Можливо, у більш вигідному становищі опинились академічні проєкти в розвинутих країнах, оскільки в університетах фінансування під час кризи зменшується не так відчутно, як у бізнесі. Також, напевно, замовники будуть менше ризикувати, а отже, рідше починатимуть нові проєкти на незвичних технологіях. Тож темпи змін можуть сповільнитись.

  У практичних напрямах усе залежить від галузі. Та основні тенденції більш-менш очевидні.

  Онлайн-взаємодія.У людей з’явилася примусова практика перенесення взаємодії в онлайн — від закупівель до перемовин і підписання документів. І ця практика частково залишиться після повернення до нормального життя після карантину.

  Однією з нерозв’язаних проблем онлайнової взаємодії є безпека: як упевнитися, що інша сторона є справді тією, з якою ми домовлялись. Технології на кшталт електронних підписів або сертифікатів документів ще перебувають на порозі масового впровадження. Тут проблема радше не в самих технологіях, а в тому, як їх представити у зручному вигляді.

  Як приклад можна навести стартап, з яким я зараз працюю. Він розробляє мобільний застосунок, що дає змогу користувачам у зручній формі приймати та віддавати сервісам підписані блоки інформації. Зокрема, посвідчення особи, дипломи, доступ до лікарняних даних тощо. Маючи щось схоже на Zaka-гаманець, можна уявити собі сценарії типу перевірки карти імунності під час придбання квитка на літак або автоматичного підтвердження особи при отриманні переказу.

  Роботизація.Якщо комерція почне враховувати ризики повторення пандемії і неможливість залучення людей у роботу, це може збільшити роботизацію процесів у офлайн-бізнесі. Якщо ще враховувати можливі труднощі з логістикою, то в деяких випадках локальне роботизоване виробництво в Європі чи США може виявитися більш вигідним, ніж виробництво в Азії.

  Обмеженість капіталу.У найближчій перспективі вільних грошей буде менше, традиційний бізнес скеровуватиме їх на відновлення. Отже, проєкти, що мають на меті технології без прямого зв’язку з монетизацією, з певною часткою імовірності матимуть труднощі.

  Олександр Майстренко, Technical Manager в IntellectTechnologies

  

  Будь-який прогноз зараз досить складний, оскільки він залежить від багатьох факторів. Майбутній розвиток технологій визначатиметься на основі тривалості пандемії (і, відповідно, кризи). Що довше триватиме карантин, то більше проєктів зазнають змін. Наприклад, один з наших партнерів орієнтується на відновлення роботи в нормальному режимі, починаючи з другої половини року. Моє очікування, що звичний режим відновиться не раніше від осені

  На сьогодні software-галузь перебуває в привілейованому стані, бо більшість інженерів має змогу продовжувати працювати (хоч і з дому). Звичайно, є компанії, де до карантину не зовсім уявляли можливість віддаленого доступу до «бойових» даних продукту. Особливо це стосується фінансових установ, що працюють з конфіденційними даними. Але навіть такі компанії вже створюють необхідну інфраструктуру для підтримки своєї повсякденної діяльності. Під час змін інфраструктури звичні інструменти на кшталт «дірявого» Zoom’у (що став забороненим у Googleта SpaceX) мають бути ретельно перевіреними.

  Розглянемо ринки, потреби яких задовольняють IT-компанії. Під найбільшою загрозою опиняться проєкти з галузей, які не стосуються першочергових потреб (наприклад, це предмети розкоші та автомобільна індустрія) і R&D. На компанії, що створюють програмне забезпечення для IT-індустрії, пандемія особливо не вплине. Інструменти потрібні всім і завжди.

  Компанії, що розробляють онлайн-платформи, не так сильно відчують кризу. Це, наприклад, онлайн-магазини, фінансові платформи (VISA, MasterCard, SWIFT, Ripple), ігрові, розважальні та соціальні платформи. Вони надають майданчик для роботи інших компаній. Навіть якщо частина учасників платформи перестане існувати, це істотно не вплине на схожі проєкти. Для них важлива масштабованість і гнучкість, тому наявна інтернет-інфраструктура буде адаптуватися під збільшені потреби.

  Ринок онлайн-ігор лише зростає. Розваги викликають залежність. Люди спробують нові для себе речі на карантині й залишаться «сидіти» на них і після нього. Окремим сегментом онлайн-ігор є розвиток проєктів у віртуальній реальності, зокрема віртуальні уроки. Загалом онлайн-навчання поступово повернеться до докарантинного рівня. Поточне збільшення зацікавленості таким видом навчання пов’язане з його тимчасовою безкоштовністю і певним страхом перед невизначеним майбутнім. У цьому контексті навчання — це спроба нівелювати страх через отримання нових знань і навичок. Після карантину це зміниться: для здобуття знань потрібно докладати зусиль, а працювати «про всяк випадок»нецікаво.

  Усе буде добре, продовжуйте працювати над поточними завданнями або спробуйте знайти роботу над глобальним проєктом, який не залежить від ситуації в конкретній країні.

  Антон Павлюшко, банківський аналітик з досвідом 10+ років у німецькій ІТ-галузі, автор блогу ITUADEпро українське IT

  

  Щоб робити якісь прогнози, треба знати, як довго триватиме ця криза. Якщо до літа поступово всі почнуть виходити з карантину, то, можливо, до кінця року ми ще зможемо повернутись у звичний режим.

  Інша річ, що карантин затягується і новини наразі не дуже оптимістичні: усе більше загиблих і безробітних — як у США, так і в Європі. Поступово виникне банкрутство. Видається, що нам не оминути економічної кризи.

  У такому разі ІТ-галузі буде не до нових технологій найближчим часом. Усі радше будуть прагнути вижити. Компанії оптимізуватимуть витрати, а отже, будуть скорочення. Некритичні проєкти закриватимуть, критичні — працюватимуть на старому багажі. Тобто холіварів на кшталт, що краще — Vue.js vs. React vs. Angular, вже не буде. Буде обмежений бюджет і менше персоналу. Роздуми, де б вставити у проєкт блокчейн чи ще якусь популярну технологію, теж відійдуть у минуле. Як ви працюватимете, особливо нікого не цікавитиме, головне, щоб вклалися в новий, зменшений бюджет.

  Простим рішенням у цьому випадку буде не брати джуніорів, яких доведеться довчати, і спробувати зменшити оплату досвідченим розробникам. «Роздуті» менеджерські кадри та велика кількість людей у керуванні проєктами з красивими назвами професій теж потраплять під ніж. Ну й тим, хто залишився, спробують зменшити зарплату, бо ж надворі криза.

  Стартапам буде ще важче переконати інвесторів викласти свої гроші. Відповідно, стартап-галузь як явище не буде так вабити інвесторів і спеціалістів.

  Поки взагалі не дуже зрозуміло, коли знову можна буде кудись поїхати. Тому на якийсь час про релокейт за кордон варто забути: там вистачатиме своїх безробітних.

  Вийшов дуже не оптимістичний сценарій. Але якщо все затягнеться, то десь так і буде.

  Однак є позитивний момент. Україна живе у стані перманентної кризи останні десятиріччя. Нас вже особливо нічим не здивуєш, тому кризу українці зможуть пройти спокійніше за західних колег. Своєю чергою, і вітчизняний менеджмент все життя працює під час кризи. Це шанс показати себе та вивести свою компанії на вищий рівень.

  Окремо хотілося б сказати про розмови в стилі «світ уже ніколи не буде таким, як колись». Робота з хоум-офісу зараз переживає свій зірковий час, і всі (вимушено) вихваляють її позитивні сторони. Компанії, пов’язані з цим явищем, переважно здаються нині переможцями діджиталізації, але й хайп із Zoom’ом, схоже, вже минає. Звичайно, багато що можна робити і з дому, але мені чомусь здається, що як тільки з’явиться можливість зібрати всіх в офіси, менеджери залюбки зроблять це. Адже так легше контролювати працівників.

  Іван Маламен, DevOps Team Lead в Allianz Gruppe

  

  Я DevOps, соответственно, опишу свое видение с этой стороны. Хочу сразу извиниться за большое количество аббревиатур и английских выражений, но такова специфика области.

  Особенность текущего кризиса — резкий рост решений по организации удаленного взаимодействия, телемедицины, ритейла и стриминговых платформ. Все эти решения хостятся в клаудах, что сильно повлияет на рост основных игроков на клауд-рынке. Также все больше компаний мигрируют в облака, включая даже большие концерны, обычно избегающие этого. Поэтому я вижу рост как основных игроков в этой области — AWS, GCP, Azure и набирающего обороты Alibaba Cloud, так и локальных провайдеров (Telekom Cloud или Hetzner Cloud) или специализированных клаудов — SAP Cloud, IBM Bluemix. Тем более в кризис компании стараются мигрировать в облака как можно больше, раньше и быстрее, так как в процессе миграции можно многие моменты оптимизировать и сильно сократить расходы, по сравнению с on-premise или арендой стоек в data-центрах. Соответственно, будет нужно больше DevOps-специалистов, на плечи которых ляжет основной груз по миграции, поддержке и разработке новых решений в облаках.

  По мере миграции/разработки перед компаниями и специалистами стоит множество интересных вызовов, связанных не только с чистыми технологиями по типу Kubernetes или NoSQL, но и с такими вещами, как SecOps и Legal. Очень интересно взаимодействовать со специалистами в этих областях, и я уверен, что их проникновение в DevOps будет все сильнее. При этом в миграциях и разработке новых решений все больше используются PaaS (Platform as a Service — Kubernetes в любом клауде хороший пример), CaaS (Container as a Service — Azure Container Service), FaaS (Function as a Service — serverless, AWS Lambda) и IaC (Infrastructure as Code — Google IaC). Также можно отметить рост managed-решений по типу Azure Postgre, которые предоставляют большую гибкость и надежность, по сравнению с self-owned. Для соответствия business continuity (обеспечение непрерывности работы бизнеса) внедряется подход Hybrid/Distributed Clouds — комбинация из on-premise и одного или нескольких клаудов. Многие компании уже обожглись на завязывании инфраструктуры на конкретном облаке (примеры из личного опыта — пропадание целого региона в GCP на несколько часов или отказ бэкапов в Azure Postgre) — и активно инвестируют в развитие мультиклаудов, создание cloud-agnostic решений и абстрагирование инфраструктуры.

  По мере развития и миграции в клауд, стоит ожидать также изменения в operations/support процессах. На данный момент для обеспечения 24/7 доступности активно идет разработка и исследование AI-ботов, которые позволят снять нагрузку с on-call команды и позволить 2/3 tier-инженерам спать спокойнее 🙂 Здесь необходимо развивать и внедрять data analytics и predictive modeling.

  Соответственно, хочется отметить еще одно интересное направление — DataOps, которое включает в себя аналитику, анализ и предсказание возможных узких мест и потенциальных решений в инфраструктуре, доступности сервиса, продуктивности, процессах разработки. В этой области необходимы уверенные знания как в классическом DevOps/Cloud, так и в ML, data pipelines, аналитике.

  Отдельно можно описать развитие IoT и ML. Большие корпорации (Intel, Apple, SAP, IBM) активно инвестируют в разработки и исследования по созданию IoT-mesh, используя AI/ML в комбинации с 5G. Это позволит различным IoT-устройствам практически в реальном времени выполнять и сильно подтолкнет такие сферы, как autonomous driving, emergency drones, drone-sharing и т. п. По личному опыту могу сказать, что это очень интересная сфера, и DevOps играет здесь одну из ключевых ролей 🙂

  Суммируя все вышенаписанное, могу сказать, что DevOps-специалистам не стоит расслабляться, списывая все на кризис, а нужно активно инвестировать в перспективу, изучая как PaaS/CaaS/FaaS, так и основы ML/Data science. Классические Jenkins, Git, ELK, Docker, whatever else, конечно же, никуда не денутся, но фокус постепенно сдвигается в сторону XaaS и managed-сервисов.

  Стоит ожидать, что с кризисом освободится некоторое количество хороших специалистов, на которых компании уже открыли охоту. К примеру я ищу в свою команду 5 DevOps специалистов 🙂

  Никита Галкин, System Architect

  

  Увеличение доли remote в разработке. Я не думаю, что кризис или пандемия сильно повлияет на технологии. Они пользуются популярностью довольно долго. Основные изменения мы увидим в людях и процессах их взаимодействия. Карантин подтолкнул многие бизнесы к remote. Естественно, это затронет и разработку.

  Возможно, будет расти количество прямых наймов из-за границы, без промежуточного звена в виде аутсорсера. Некоторые рекрутинг-агентства перепрофилируются только под remote-вакансии из Европы и Штатов. Это выгодно всем — и заказчику, и агентству, и инженеру. К сожалению, ограничителем будут английский и менталитет/культурный код/culture fit.

  Прототипы без разработки. Еще в прошлом году в стартап-среде начал набирать тренд создания прототипов не руками программистов, а с помощью конструкторов. Zapier, Аirtable, Wix, Notion и им подобные сервисы позволяют без бюджета на разработку создать прототип, с которым можно валидировать бизнес-идею. Финансовый кризис только усилит этот тренд: разработки самих прототипов будет меньше, а вот интеграций с подобными сервисами больше.

  Удешевление обслуживания процессов разработки. Новые технологические продукты от крупных вендоров имеет одну общую черту: удешевление обслуживания. Где за счет автоматизации, где за счет снижения требований к инженерам. Сильнее всего это заметно в Data Science (просто посмотрите релизы от AWS) и DevOps. GitHub Actions отличный пример снижения требований. Сравните требуемые знания при создании Workflow из готовых элементов Marketplaceи настройку Jenkins.

  Анна Лаврова, Agile Coach в Wemanity Belgium

  

  Сложно делать какие-либо прогнозы о том, какие технологии и тренды будут на пике после окончания карантинов, открытия границ и возвращения к обычной жизни. Потому что: а) обычной жизни в ее привычном понимании уже не будет; б) ситуация меняется каждый день.

  В той части Европы, где я живу (Бельгия), на удивление, много IT-консалтинговых компаний вынуждены были отправить своих сотрудников на unemployment период. Это подтвердило идею о том, что нет такой работы, которая «в безопасности». Тут это связано с тем, что большинство студий, фрилансеров и небольших сервисных организаций работают на «внутренний рынок», который как раз и пострадал.

  Можно попробовать предположить, что «недополученная прибыль» случится в виде заказов, которые не придут к тем, кто привык собирать лидов на конференциях и событиях лично. То же самое с инвестициями, партнерствами и возможностями для стартапов.

  В частности, Mobile World Congress (MWC), который должен был состояться февраля в Барселоне, был отменен из-за опасений по поводу вируса. MWC является «краеугольным» событием в индустрии соединений, так как объединяет наиболее важные компании в области сетевого взаимодействия, обмена инновациями и налаживания новых деловых партнерских отношений.

  Помимо MWC, Facebook отменил конференцию F8 для разработчиков и Global Marketing Summit, Google перенес свое мероприятие Google Cloud Next только на онлайн. IBM также пришлось транслировать онлайн конференцию для разработчиков, которая в прошлом году собрала более 30 000 посетителей. В целом, отмена основных технических событий принесла более миллиарда долларов прямых экономических потерь, согласно оценкам PredictHQ, приведенным Recode.

  Участники конференции не имеют таких же возможностей для общения через прямой эфир, как в личных мероприятиях. Например, маркетологам будет сложнее обмениваться передовым опытом в рамках Глобального маркетингового саммита Facebook, транслируемого в прямом эфире, чем, если бы событие действительно имело место. Хотя количественно оценить ценность этих случайных встреч или неформальных сетевых сессий сложно. Результаты, несомненно, будут ощущаться во всех затронутых отраслях.

  В моем представлении все это приведет к тому, что компании, затягивая ремешки, сосредоточатся на крепких, антихрупких доменах, где часто может не быть времени на развитие молодых специалистов и на «крутые технологии и проекты, о которых не стыдно будет рассказывать на конференциях». Учитывая, что мир получит меньше Apple-устройств (больше об этом тут) рынок для мобильных продуктов тоже уменьшится.

  С другой стороны, многие работодатели все больше полагаются на корпоративные средства телеконференций, такие как Microsoft Teams, Google Hangouts и Zoom. И при этом есть «официальное заявление» многих структур в Бельгии — не использовать подобные средства для передачи чувствительной информации. А значит, есть больше возможностей для тех, кто предоставляет решения по безопасности данных.

  Знаю, что в США компании уже определили VR как инструмент для улучшения обучения сотрудников, но коронавирус может оказаться стимулом для внедрения этой технологии и в других проектах. Согласно опросу Perkins Coie, почти половина (49%) респондентов хотят использовать VR и другие инструменты расширенной реальности для отражения реальных условий обучения. Такого тренда еще нет в Бельгии и Франции, например.

  Две крупные технологические компании — Amazon и IBM — объявили о программах, призванных побудить разработчиков находить решения для множества проблем, связанных с пандемией. Возможность того самого crowd-опыта, которого мы долго не получим в офлайне.

  Healthcare, мне кажется, как никогда, готовы к экспериментам. Например, Diligent Robotics хочет дать медсестрам помощника-дроида, который может бегать за ними по больнице. Роботы не могут быть носителями вирусов. А это значит, что они могут безопасно взаимодействовать с уязвимыми группами населения.

  Города во всем мире используют технологии умных городов в попытках смягчить воздействие коронавируса. Китайская полиция использует беспилотники с термодатчиками для выявления людей, находящихся на улице. Правительство Южной Кореи разработало приложение для смартфонов, которое позволяет лицам, находящимся на карантине, контактировать с сотрудниками, ведущими дела, что позволяет им сообщать о своем прогрессе и задавать любые возникающие вопросы. Правительство Австралии запустило чат-бота для решения вопросов граждан и подавления распространения дезинформации. В Бельгии власти начали внедрение подобных технологий с марта 2020. Если решения «умного города» окажутся эффективным инструментом для смягчения пандемии, правительства могут почувствовать еще большую уверенность в дальнейших инвестициях, что может ускорить темпы развертывания решений.

  Дмитрий Меньшиков, CTO в Aurora Technologies

  

  В вопросе влияния кризиса 2020 на IT, в контексте востребованности направлений и технологий, стоит понимать, что большая доля IT-компаний Украины закрывают потребности реального сектора экономики. У аутсорса и аутстафа множество проектов обслуживают не IT-бизнес. Торговля внедряет системы управления складами и заказами, компании и люди заказывают сайты, кинотеатры делают онлайн-оплату, даже АЗС и шиномонтаж уже запускают свои программы лояльности и онлайн-оплаты разного рода. Это огромный пласт заказчиков. При падении потребления у компаний, при их банкротстве или даже оптимизации расходов в сложный период они в первую очередь сокращают нецелевые расходы. Для многих из них IT-услуги и станут теми нецелевыми тратами, которые можно сократить. Многие компании будут уменьшать затраты на R&D и экспериментальные проекты. Кстати, недавно я проводил стрим на эту тему и интересующиеся могут посмотреть его запись.

  Это, безусловно, ударит по аутсорсу и аутстафу сильнее, нежели по продуктовым компаниям. Не зря же аутсорс применяли для уменьшения расходов и налоговых оптимизаций. Вот и в этот раз будут оптимизировать. Компании, что изначально строили онлайн-историю и полный цикл от маркетинга до саппорта и разработки, будут в меньшей зависимости от традиционного офлайн-бизнеса. Это применимо и к продуктам, и к аутсорсу с аутстафом. Речь не идет о том, что такие компании не чувствуют кризис, но у них есть больше шансов перестроится и выстоять. Возможно, с потерями, но выстоять.

  Я не вижу существенного влияния кризиса и пандемии на изменение популярности технологий или языков программирования. При выборе компании, с которой вы планируете связать часть своей жизни, я советую смотреть не так на технологии, как на ее бизнес-модель и организационную структуру. Если компания входит в перечень тех, которые ощутили удар от пандемии и кризиса, то это не будет лучшим вариантом в текущей ситуации. Да и не секрет, что smart-компании ищут не исполнителей со знаниями технологии X или языка программирования Y, а людей с навыками решения проблем бизнеса. Знает ли человек X и Y или нечто другое — это детали, ведь язык и технологии — всего лишь инструмент решения бизнес-задач. Инвестируйте в эти навыки и вы будете успешными всегда.

  На текущий момент уже есть ряд секторов, которые ощутили сильное падение: все, что связано с авиаперевозками, железнодорожным транспортом и туризмом, существенно упала реклама, проекты в сфере коммерческой и жилой недвижимости , проекты, связанные с рекрутментом, ресторанным бизнесом, индустрией оффлайн-развлечений. Продажи электроники, автомобилей и одежды тоже сократились. Образовательные платформы, как не парадоксально, испытывает серьезное давление, хотя распространено мнение, что они хайпуют.

  
  

  Пандемия подтолкнула людей к самоизоляции, и в краткосрочном периоде выиграют развлекательные и видеостриминговые платформы, сервисы заказа такси и доставки товаров, еды, онлайн-репетиторы и психологи. Проекты в сфере онлайн-образования будут только набирать обороты в долгосрочной перспективе. Не думаю, что обучение перейдет в онлайн, но пандемия многих научит, что получать знания можно в более удобной форме дома. Как по мне, челлендж состоит не столько в разработке таких платформ, ведь их немало и так, сколько в смене парадигмы в сторону удаленной работы и донесения информации среди самих носителей знаний, преподавателей и менторов. Люди активно учатся работать дистанционно, что вынудит компании перестроится на такое сотрудничество. Инструменты для организации удаленной работы точно будут востребованы для всех бизнесов без исключения.

  Никуда не денутся проекты, призванные автоматизировать процессы оффлайнового бизнеса: кризис закончится и прогресс снова возьмет свое. Под автоматизацией я имею в виду как автоматизацию прикладных систем, так и автоматизацию доставки товаров и продукции, диагностирования заболеваний у людей и назначения лечения, помощь нетрудоспособным, автоматизацию выращивания продуктов питания (как думаете, как дефицит трудовых мигрантов в сельском хозяйстве повлияет на урожайность этого года?). Особняком выделю проекты в сфере микробиологии, вирусологии, химии, защиты окружающей среды и подобных областей. Они на волне и сейчас, а с уменьшением биологической безопасности в мире будут расти еще больше.

  Поэтому еще раз советую вкладывать усилия в развитие коммуникативных навыков, навыков маркетинга и продаж, в понимание того, как работает экономика и бизнес. Об этом я пишу как на канале «Об IT без галстуков»с советами от лица топ-менеджмента компании, так и на канале проекта по финансовой грамотности «ФинВам». Буду рад видеть ваши вопросы!

  А що думаєте ви?

  Как организовать работу с требованиями в распределенной команде. План действий для BA

  April 16, 2020, 3:04 am

  Дистанционная работа — тренд последнего месяца (и, скорее всего, следующего тоже). Теперь не только IT, но и другие бизнесы имеют дело с распределенными командами — сотрудниками, каждый из которых работает из своего дома/локации. Я же начала работать в таком формате задолго до того, как это стало необходимостью, и сегодня хочу поделиться собственным опытом, как бизнес-аналитику организовать процесс сбора, анализа и обработки требований в распределенной команде с максимальным результатом.

  В статье я сконцентрируюсь на планировании взаимодействия бизнес-аналитика с заинтересованными лицами, а конкретнее — на коммуникациях, связанных с обменом знаниями о требованиях к решению.

  

  Требования никто не читает. Что делать

  До того, как попасть в Astound Commerce, я довольно долго проработала в компании, практикующей Scrum-подход к разработке. Как это принято на такого рода проектах, вся команда работала вместе в одной комнате, и живое, спонтанное общение было краеугольным камнем в процессе создания успешного решения.

  Разумеется, бывали и исключения: сотрудники могли время от времени работать из дома или из другой локации, подключаясь к общению по Skype. Но так как процесс не был адаптирован к удаленной работе, во время таких отлучек я отчетливо ощущала, как падает моя продуктивность, гора неотвеченных вопросов накапливалась, и после возвращения в офис я несколько дней тратила на то, чтобы ее разгрести.

  Здесь же все организовано иначе. У Astound только в Украине 5 центров разработки, а еще есть офисы в Колумбии, Словакии, Болгарии, Турции и Индии. Как правило, в проектах участвуют специалисты минимум из трех локаций, которые вдобавок часто расположены в разных часовых поясах. Поэтому подход к коммуникациям внутри команды и всех ее участников с внешним миром должен учитывать территориальную распределенность.

  Не секрет, что у бизнес-аналитиков, впервые попавших в распределенную команду (особенно у тех представителей профессии, кто, как и я, относит себя к закоренелым интровертам) часто возникает соблазн просто писать документацию, отдавая ее с некоторой периодичностью на согласование команде и клиенту. Сидишь себе спокойно в офисе, оттачиваешь мастерство слога и точных формулировок — идиллия! Однако у такого подхода есть существенный недостаток: прекрасную, точную, однозначную и непротиворечивую спецификацию никто не читает. Ну, может, кроме QA-специалистов. Да и они читают невнимательно.

  • Не читает команда разработки — как результат:
    • много новых вопросов после того, как документ официально утвердили;
    • много багов и переработок функциональности;
    • позднее выявление нереализуемой или сложной функциональности.

    В общем, из вышеописанного достаточно явно следует, что молча писать документацию, отвлекаясь только на короткие формальные синкапы, — плохая идея. Но и свободное, спонтанное общение в распределенной команде невозможно. Как же поступить?

    Решение простое: организовать регулярные встречи со всеми заинтересованными лицами. Разумеется, не одновременно со всеми. Во-первых, это будет неэффективно, так как уровень погружения в детали сильно отличается для разных категорий участников проекта, а во-вторых, это сложно реализуемо на практике, если учитывать загруженность и разницу в часовых поясах. В нашей компании для бизнес-аналитика не существует единого подхода к коммуникациям, на каждый проект он волен определять стратегию взаимодействия самостоятельно. Однако есть фреймворк, предложенный лидом нашего департамента, и, по моему мнению, в условиях распределенной команды он работает достаточно эффективно.

    Как и с кем вести коммуникацию

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

    Определим круг лиц, с которыми аналитику приходится общаться с разной степенью регулярности. Как правило, это:

    • менеджер проекта;
    • разработчики;
    • UX-специалист;
    • QA-инженеры;
    • архитектор решений (Solution Architect);
    • представители решений, с которыми мы интегрируемся;
    • представители заказчика.

    Как часто и о чем необходимо общаться с каждой категорией, чтобы знания не терялись в недрах документации? Давайте разберемся.

    Общение с менеджером проекта

    Как правило, мне достаточно ежедневной получасовой синхронизационной встречи (daily sync), на которой присутствует вся команда и все обмениваются статусами выполнения работы и планами на текущий день. Такую встречу наши проектные менеджеры стараются проводить в утреннее время (если это невозможно, то во время, которое считается утренним у большей части команды). Если же возникают какие-то внештатные ситуации, то тут же, на синке, можно договориться о личной встрече (или созвоне) с менеджером в ближайшее возможное время.

    Обычно эти дополнительные личные встречи длятся не больше да и необходимость в них возникает не часто. Как правило, на них мы согласовываем сроки поставки пакета требований или организационные моменты, например, необходимость подключить к решению задачи представителей других команд.

    Общение с разработчиками и UX-специалистом

    По мере написания требований у вас наверняка возникают вопросы вроде «А как именно работает форма, изображенная на прототипе?» или «Стоит ли сделать параметр настраиваемым?». В свою очередь, у разработчиков и UX-специалистов также могут быть вопросы по деталям функциональности, которую они в данный момент разрабатывают. Для ответов на эти и подобные вопросы у нас запланирована ежедневная встреча между бизнес-аналитиком, UX-специалистом и представителями команды разработки (обычно это лиды front-end- и back-end-команд). Конечно, одновременно собрать четырех человек бывает сложнее, чем переговорить с каждым с глазу на глаз. Однако пользу от такой встречи, когда собираются воедино «что?», «как?» и «зачем?», невозможно переоценить.

    На встрече, как правило, я показываю очередную порцию написанных требований. За день объем будет небольшим, и мы его все вместе разбираем. UX-специалист также может продемонстрировать особо сложный кусок прототипа. Остаток времени посвящаем ad hoc — вопросам. Средняя продолжительность встречи — Обычно такую встречу мы проводим сразу после дневного синка. Это удобно, так как команда не успела разбежаться по своим делам. При необходимости (например, очень сложная и спорная функциональность) количество встреч можно временно увеличить до двух в день, например, одна встреча утром и одна вечером для закрепления договоренностей и окончательного разрешения всех вопросов.

    Общение с QA-специалистом

    Вообще говоря, QA-инженера можно пригласить на встречу с разработчиками и UX-специалистом, о которой я писала выше. Но бывает, что из-за разницы часовых поясов это не очень удобно. Кроме того, QA-специалист часто работает на более глубоком уровне детализации, чем тот, который мы обсуждаем с UX-специалистом и разработчиками. В таком случае общение целесообразно разделить. С QA-специалистом мы также общаемся ежедневно. Как правило, я беру паузу в несколько часов после встречи с разработчиками, чтобы успеть внести правки в документацию и получить ответы на поставленные вопросы.

    На встрече с QA-специалистом я делаю мини-презентацию той части требований, которую мы обсудили с разработчиками, и получаю новую порцию уточняющих вопросов, ответы на которые вношу в документ. Обычная продолжительность встречи — около 15 минут.

    Чаще всего перечисленных встреч достаточно для того, чтобы формальное согласование требований командой прошло без проблем. По мере завершения документации к отдельному модулю, если функциональность сложная или было много переделок в процессе обсуждения, я могу сделать отдельную встречу для презентации требований. На этой встрече присутствуют все вышеупомянутые специалисты: лиды разработки, UX, QA, а также по желанию — проектный менеджер и все остальные участники команды. Конечно, спланировать такую встречу бывает достаточно сложно, но поскольку она случается не очень часто (обычно не чаще, чем раз за проект), то даже необходимость подключиться к встрече в нерабочее (плюс-минус час от обычного графика) время не вызывает дискомфорта.

    Общение с архитектором решений (Solution Architect)

    У бизнес-аналитика и разработчиков часто возникают вопросы, ответить на которые может только Solution Architect. Но привлекать его на ежедневной основе нецелесообразно, ведь такие специалисты нарасхват и их время стоит очень дорого. Отвлекать SA спонтанно по мере возникновения вопросов тоже не лучшая идея: без погружения в контекст человек вряд ли выдаст хорошее решение. Да и через несколько недель такого «выдергивания» он того и гляди заблокирует вас в корпоративном мессенджере. Вместо этого мы договорились созваниваться с архитектором два раза в неделю.

    На встрече всегда присутствуют собственно архитектор, бизнес-аналитик, лиды разработки и лид QA. В принципе, любой член команды, если у него есть вопросы именно к SA, тоже всегда может присоединиться. Вопросы для обсуждения к этим встречам мы готовили в общем файле. Если вопросов не было (редкое событие!), то SA, просматривая файл, понимал, что встречи не будет. Если вопросы были, он мог заранее их посмотреть, на что-то ответить там же, в файле, или же подготовиться к ответу. Средняя продолжительность встречи — минут в зависимости от фазы и сложности проекта.

    Общение с представителями других команд

    Бизнес-аналитик достаточно часто контактирует с бизнес-аналитиками или архитекторами продуктов, с которыми предполагается интеграция. Как правило, такие встречи носят нерегулярный, спонтанный характер, за исключением первой, на которой обсуждается старт работ по интеграции, и последней, на которой происходит презентация готовых требований. Все остальное общение планируется, только если есть вопросы, которые нужно решить.

    И наконец, общение с заказчиком

    Как я писала выше, не стоит рассчитывать, что представители бизнеса внимательно прочитают спецификацию требований. Поэтому все вопросы, которые вызывают сомнение, лучше обсуждать с заказчиком заранее. Обычно мы планируем одну-две еженедельные встречи длительностью минут для обсуждения открытых вопросов, которые я готовлю заранее (обычно в тикетах Jira). Таким образом, заказчик осведомлен, о чем мы собираемся его спрашивать, и может подготовиться.

    Обычно этих встреч достаточно для безболезненного утверждения документации и, что важнее, для относительно безболезненного прохождения приемочного тестирования. Впрочем, иногда по желанию клиента (а точнее, по нежеланию вникать в формальный текст спецификации) мы проводим ревью требований. Такое ревью осуществляется для наиболее важных модулей продукта. На встрече я достаточно бегло прохожусь по всем требованиям к модулю, концентрируясь на критичных для работы и настройки продукта моментах, и человеческим языком объясняю, что именно скрывается за сухим формальным текстом спецификации и что конкретно будет или не будет реализовано. Длительность таких встреч — не более часа, частота — примерно раз в две-три недели.

    Работающий функционал заказчик может увидеть на регулярном демо, которое команда проводит по мере завершения разработки каждого модуля.

    Результаты и выводы

    И напоследок немного статистики. Для примера я взяла несколько своих проектов приблизительно одинаковой сложности. На двух из них я работала без предварительно составленного плана вовлечения заинтересованных лиц, то есть фактически рассчитывая только на результаты ревью требований и на ad hoc обсуждение в личной переписке. На третьем проекте коммуникации были спланированы так, как описано в статье. Метрикой является количество комментариев команды и клиента, повлекших за собой правки функциональных требований, созданных после того, как документ уже был согласован.

    Проект	Тип коммуникации	Количество документов (общее)	Количество правок (общее)	Среднее количество правок на документ
    Проект № 1	Ad hoc + формальные синкапы	25	33	1,3
    Проект № 2		23	42	1,8
    Проект № 3	По плану	25	15	0,6

    Как видим, при грамотно спланированном графике коммуникаций территориальные преграды не мешают эффективной работе бизнес-аналитика в команде, а само общение не превращает рабочий день в хаос.

    Тем же, кто только начинает составлять подобный график, рекомендую выполнить следующие действия:

    1. Определите круг заинтересованных лиц. За основу можно взять всех перечисленных в этой статье (это необходимый минимум), а также добавить к списку тех, кто, по вашему мнению, должен предоставлять информацию на регулярной основе или же кого необходимо регулярно информировать. Это может быть, например, спонсор проекта, представители команды поддержки, представители юридического отдела и прочие специалисты.
    2. Подумайте, как часто и как долго вам нужно общаться с представителями каждой из категорий в течение недели. Можно начать с получасовых встреч раз в неделю, увеличивая их продолжительность и частоту, как только станет очевидно, что этого недостаточно.
    3. Совместно с участниками договоритесь о средствах общения и распределите встречи равномерно по рабочей неделе. Подумайте: возможно, ответы, полученные на одной встрече, могут стать входной информацией для другой? Тогда эти встречи стоит поставить поближе друг к другу.

    Вот и все! Планируйте правильно и общайтесь!

    Геолокаційні запити в PostgreSQL без важкої артилерії

    April 17, 2020, 12:00 am

    Привіт, мене звуть Павло Дмитрієв. Я працюю iOS-розробником у компанії Postindustria. Багаторічний Python-досвід подекуди дається взнаки, тож я часто беру участь і в «бекендних» завданнях, адже в нас таке заохочується. Саме тому сьогодні я хотів би розповісти про випадок, що допоміг мені ще раз переконатися в перевагах PostgreSQL і дізнатися, як за допомогою СКБД найлегше виконувати операції з геокоординатами. Звичайно, «зубри» DBA усе це знають, але, сподіваюся, стаття буде цікава для тих, хто ще не з’їв на цьому кількох собак.

    У повсякденній рутині програмування часто виникають завдання на кшталт «знайти всіх користувачів додатку поруч з містом X» або «відсортувати щось за віддаленістю від чогось». В одному старому проєкті це взагалі робили на рівні коду, тобто для пошуку вибирали точки, що потрапляють у заданий квадрат запитом на кшталт:

    WHERE lat > 10 AND lat < 20 AND lng >30 AND lng < 45

    А потім усе, що опинялося в цій «мережі», додатково фільтрувалося в Python-скриптi. Гадаю, зрозуміло, що продуктивність цього підходу швидко сповзала десь на рівень плінтуса, до того ж повсякчас лізли баги з обробленням граничних умов. Не те щоб їх неможливо було розв’язати, але ліпше подивімося, як це можна зробити на рівні БД. І ні, це не для того, щоб перекласти все зі своїх плечей на DBA.

    Востаннє подібне завдання цілком природно виникло під час створення проєкту Zin (dating-стартап з ухилом в безпеку), а для застосунків такого типу локацію користувача можна сміливо вважати за наріжний камінь. Коротко кажучи, нам треба було знаходити найближчі до користувача оголошення в нашій базі й сортувати їх за відстанню.

    Окремо зазначу, що нас цікавила відстань за дугою «великого кола», без поправок на рельєф, до того ж припустима похибка була доволі велика, тож головним критерієм стала саме простота реалізації. Забігаючи трохи наперед, скажу, що точність вийшла кращою, ніж ми сподівалися, і я це продемонструю.

    Тестові дані

    БД проєкту містить приватні дані, тож для прикладів я використовуватиму два інших датасети. Перший — велика таблиця міст і їхніх координат, узята звідси. Вона трохи надлишкова, бо містить не тільки «міста» в їхньому традиційному розумінні, а й райони міст, деякі туристичні принади й таке інше; але раз нам потрібна насамперед кількість, то це не стане проблемою. Тож ось структура нашої першої таблиці.

    CREATE TABLE cities ( id integer DEFAULT nextval('public.cities_seq'::regclass) NOT NULL, name character varying NOT NULL, region character varying NOT NULL, lat double precision NOT NULL, lng double precision NOT NULL ); ALTER TABLE ONLY cities ADD CONSTRAINT cities_pkey PRIMARY KEY (id); CREATE INDEX cities_name_low_idx ON cities USING btree (lower((name)::text)); CREATE INDEX cities_location_idx ON cities USING gist (ll_to_earth(lat, lng));

    Усе дуже просто: ім’я місця, код країни, до якої воно належить, і кілька атрибутів для зберігання широти й довготи. Додатково будуємо два індекси: BTREE для пошуку за назвою і той, що нам знадобиться для запитів по координатах. Останній використовує тип GIST (хвала розробникам PostgreSQL за цей чудовий механізм) і функцію ll_to_earth, про яку поговоримо пізніше.

    Зазвичай, у вас буде два основні способи зберегти локації: використовувати пару чисел в окремих стовпчиках для ширини та довжини або ж використати той чи інший специфічний тип з-поміж тих, про які ми поговоримо нижче (point, earth, cube, etc.). Великої різниці з погляду швидкості жоден з варіантів не дає, тому зазвичай використовують саме окремі стовпчики. Але тут уже треба аналізувати варіанти, виходячи з конкретики вашого завдання.

    Не наводитиму допоміжні Python-скрипти, які я використовував для збору даних і їх перевантаження в БД; якщо вони комусь цікаві, то ось посилання на GitHubз ними.

    Переносимо записи в БД і переконуємося, що цього досить, щоб показати всі особливості, пов’язані з продуктивністю.

    SELECT COUNT(*), pg_size_pretty(pg_relation_size('cities')) AS data, pg_size_pretty(pg_indexes_size('cities')) AS idxs FROM cities; count | data | idxs ----------+--------+--------- 12005938 | 848 MB | 1836 MB (1 row) Time: 2073.919 ms (00:02.074)

    Щоб наочніше продемонструвати складні запити, я також створив дві невеликі таблички: перша містить найбільші міста Чорногорії (15), а друга — найближчі до них піцерії (172); останні я брав з Foursquare, скрипт для цього також є на GitHub.

    Фух, це був довгий вступ, тож перейдімо до наявних опцій.

    PostGIS

    Це саме та «важка артилерія», без якої я обіцяв обійтися в назві цієї статті. Але ж не згадати його було б нелогічно, хоча б для того, щоб зрозуміти, чому саме ми вирішили його не використовувати.

    Так, звичайно, цей метод має величезні переваги: найвища точність і гнучкість, відсутність граничних умов, можливість змінити просторову прив’язку.

    Але все це дається досить великою ціною, починаючи з прірви залежностей (проста установка через homebrew має більше ніж 30 залежностей, зокрема GCC, Qt, Boost і таке інше) і закінчуючи підвищеною складністю (нестандартні типи даних, 5000+ рядків додаткових таблиць із довідниками).

    Тож цілком очевидно, що ми хотіли б використати щось простіше, і, на щастя, основна команда PostgreSQL розробила додаток earthdistance, що містить усе потрібне для нас. Установити його просто:

    CREATE EXTENSION earthdistance CASCADE;

    Цей додаток дає два способи роботи з координатами.

    Оператор

    Не знаю, як саме називати цю синтаксичну химеру (може, «око»?), та суть дуже проста: цей оператор приблизно розраховує ту саму big circle distance між двома точками на земній кулі. Для точок використовується вбудований тип даних point, але слід пам’ятати, що спочатку маємо вказувати довготу, а вже потім широту; це суперечить «звичному» порядку, але саме довгота відповідає координаті X, тому й іде першою. Друга особливість, про яку не слід забувати, це те, що результат повертається в статутних милях (тих, що мають 5280 футів або приблизно 1609 метрів), тож завжди треба ділити/множити на цю константу.

    Переваги цього методу очевидні: він легкий і використовує найпростіші типи даних. Але є в нього й недоліки: окрім точності (Земля вважається ідеальною сферою), граничних умов на полюсах і меридіані, він також не дуже добре працює з індексами. Хоча на невеликих обсягах даних його можна використовувати без проблем, звичайно, крім edge cases.

    Наведу приклад, як знайти місця, ближчі за 10 км до якоїсь точки (скажімо, до міста з поетичною назвою Бар), що має приблизно такі координати: 42.1° пн. ш., 19.1° сх. д.

    SELECT *, (point(lng, lat) point(19.1, 42.1)) * 1609.344 AS distance FROM cities WHERE (point(lng, lat) point(19.1, 42.1)) < (10000 / 1609.344) ORDER BY distance;

    id | name | lat | lng | region | distance ----------+-----------------------------+----------+----------+--------+-------------------- 27696013 | Bjelisi | 42.10083 | 19.10417 | ME | 356.2025188423806 27699128 | Topolica | 42.09833 | 19.09417 | ME | 515.6034584176577 27696061 | Bar | 42.0937 | 19.09841 | ME | 712.7044816072382 27708312 | King Nikola's Palace | 42.10062 | 19.09129 | ME | 721.903811067934 27708268 | Princess | 42.10158 | 19.09132 | ME | 737.3598549548324 27708234 | Bar Port | 42.09701 | 19.09132 | ME | 789.5619694327141 27708184 | Castello | 42.10701 | 19.09623 | ME | 839.2352057529451 27699126 | Popovici | 42.09194 | 19.10528 | ME | 996.5017600203865 27708313 | Antivari Pier (historical) | 42.09708 | 19.08834 | ME | 1015.3313902853366 27695933 | Rikavac | 42.09278 | 19.08972 | ME | 1167.8829329656053 … (232 rows) Time: 2844.305 ms (00:02.844)

    Як бачите, сам запит — простий, але час виконання не дуже тішить око, навіть без EXPLAIN зрозуміло, що працює звичайний SCAN.

    Здебільшого, щоб зоптимізувати такі запити й допомогти їм використовувати індекс, долучають оператор обчислення відстані між точками «за прямою» , додатково потім уточнюючи результат за допомогою , але проблеми з полюсами та меридіаном це все одно не розв’язує.

    Вам знайоме це почуття, коли автор книжки чи статті силоміць підводить вас до того рішення, яке він заздалегідь визначив для себе як правильне? Саме час його відчути. Ми переходимо до третього чи, точніше сказати, до другого з половиною (бо він входить у той самий застосунок earthdistance) методу.

    Функція earth_distance та її помічники

    Може, дехто буде зі мною не згоден, але я вважаю, що команда розробників PostgreSQL — одні з найкмітливіших людей на планеті (а те, що вони створили свій проєкт безплатним і відкритим, робить їх ще й найщирішими). До чого це я веду?

    Оператор можна вважати «2D-шляхом» до розв’язання завдання, і якщо він працює не дуже добре, треба переходити в 3D, що й зроблено в earth_distance. Цей модуль дозволяє перетворити будь-які координати на планеті на тривимірну точку в просторі й потім працювати з нею. Оскільки вбудованого типу даних для 3D-точки в Postgres немає, використовується тип cube, а точніше його «нащадок» earth, в якому додаються деякі перевірки на «здоровий глузд» на кшталт «точка не може бути далеко віддалена від поверхні». Звичайно, куб вважається «нульовим», тобто його протилежні вершини збігаються.

    Спочатку кілька корисних функцій:

    • ll_to_earth(latitude, longitude) — перетворює пару «широта — довжина» на той самий тип earth, обчислюючи тривимірну позицію точки в просторі.
    • earth_distance(point1, point2) — обчислює відстань між двома точками у форматі earth.
    • earth_box(point, radius) — створює куб такого розміру, щоб у нього потрапляли всі точки, розміщені на відстані не більше ніж radius від point. Цей куб є приблизним критерієм пошуку, але завдяки операторові (входження кубу в куб) дозволяє ефективно використовувати GIST-індекси, проводячи потім «доуточнення» запиту.

    SELECT *, ROUND(earth_distance(ll_to_earth(42.1, 19.1), ll_to_earth(lat, lng))::NUMERIC, 2) AS distance FROM cities WHERE earth_box(ll_to_earth (42.1, 19.1), 10000) @> ll_to_earth (lat, lng) AND earth_distance(ll_to_earth (42.1, 19.1), ll_to_earth (lat, lng)) < 10000 ORDER BY distance;

    id | name | lat | lng | region | distance ----------+-----------------------------+----------+----------+--------+---------- 27696013 | Bjelisi | 42.10083 | 19.10417 | ME | 356.60 27699128 | Topolica | 42.09833 | 19.09417 | ME | 516.18 27696061 | Bar | 42.0937 | 19.09841 | ME | 713.51 27708312 | King Nikola's Palace | 42.10062 | 19.09129 | ME | 722.72 27708268 | Princess | 42.10158 | 19.09132 | ME | 738.19 27708234 | Bar Port | 42.09701 | 19.09132 | ME | 790.45 27708184 | Castello | 42.10701 | 19.09623 | ME | 840.18 27699126 | Popovici | 42.09194 | 19.10528 | ME | 997.62 27708313 | Antivari Pier (historical) | 42.09708 | 19.08834 | ME | 1016.48 27695933 | Rikavac | 42.09278 | 19.08972 | ME | 1169.20 … (232 rows) Time: 102.084 ms

    Як бачите, результат куди ліпший за продуктивністю, навіть на звичайнісінькому MacBook Pro 2016, оброблення 12М+ записів майже вклалася в 100 мс. Поглянемо на EXPLAIN-запитові.

    Gather Merge (cost=45002.12..45441.98 rows=3770 width=69) Workers Planned: 2 -> Sort (cost=44002.10..44006.81 rows=1885 width=69) Sort Key: (round((sec_to_gc(cube_distance('(4471920.234086516, 1548541.2222539173, 4276093.607391206)'::cube, (ll_to_earth(lat, lng))::cube)))::numeric, 2)) -> Parallel Bitmap Heap Scan on cities (cost=651.34..43899.55 rows=1885 width=69) Recheck Cond: ('(4461920.235110745, 1538541.2232781458, 4266093.608415434),(4481920.233062288, 1558541.2212296887, 4286093.606366977)'::cube @> (ll_to_earth(lat, lng))::cube) Filter: (sec_to_gc(cube_distance('(4471920.234086516, 1548541.2222539173, 4276093.607391206)'::cube, (ll_to_earth(lat, lng))::cube)) < '10000'::double precision) ->Bitmap Index Scan on cities_location_idx (cost=0.00..650.21 rows=13572 width=0) Index Cond: ((ll_to_earth(lat, lng))::cube 
    Сканування індексу + додаткове уточнення дають нам дуже пристойну швидкість. Тож якщо ваша база велика, зменшити «охоплення» запиту — завжди гарна ідея, бо ж ситуація, коли треба знаходити щось по всьому світові, зустрічається нечасто; набагато частіше ми обмежуємо пошук якимось регіоном.
    Мабуть, вас цікавить питання, наскільки розбіжні результати обчислень різними методами (принаймні мені було дуже цікаво). Це легко дізнатися.
    SELECT name, ST_Distance(ST_MakePoint(lng, lat)::geography, ST_MakePoint(19.1, 42.1)::geography) AS postgis_distance, earth_distance(ll_to_earth(42.1, 19.1), ll_to_earth (lat, lng)) AS earth_distance, (point(lng, lat) point(19.1, 42.1)) * 1609.344 AS point_distance FROM cities WHERE earth_box(ll_to_earth (42.1, 19.1), 10000) @> ll_to_earth (lat, lng) AND earth_distance(ll_to_earth (42.1, 19.1), ll_to_earth (lat, lng)) < 10000 ORDER BY earth_distance;
    name | postgis_distance | earth_distance | point_distance -----------------------------+------------------+--------------------+-------------------- Bjelisi | 357.05152825 | 356.6040157475758 | 356.2025188423806 Topolica | 516.71294939 | 516.1846255398445 | 515.6034584176577 Bar | 712.02799946 | 713.5078129379874 | 712.7044816072382 King Nikola's Palace | 723.77941534 | 722.717511506365 | 721.903811067934 Princess | 739.14564214 | 738.1909768134576 | 737.3598549548324 Bar Port | 791.12180279 | 790.4519313791742 | 789.5619694327141 Castello | 838.76185601 | 840.1811573389859 | 839.2352057529451 Popovici | 996.13740888 | 997.6249760322966 | 996.5017600203865 Antivari Pier (historical) | 1017.61930422 | 1016.4758302850378 | 1015.3313902853366 Rikavac | 1168.91272962 | 1169.199322822384 | 1167.8829329656053 … Knjezdovo | 9751.02688274 | 9743.710964250973 | 9732.740617250734 Rt Sapavica | 9776.31845857 | 9772.941912657994 | 9761.938654824216 Livrsanik | 9790.74772202 | 9781.953343427898 | 9770.939939713666 Kabeta | 9803.27894257 | 9791.177885397401 | 9780.154095863507 Pecurice | 9825.29031086 | 9833.21849793169 | 9822.147375291843 Dedici | 9825.38102702 | 9836.570130079455 | 9825.495233870668 Kozjak | 9860.53074801 | 9882.053049767033 | 9870.926944792083 Livari | 9899.30877216 | 9888.084255774567 | 9876.95136032431 Ocas | 9877.66304883 | 9893.775540351273 | 9882.636237141522 Kamisora | 9932.59217935 | 9926.356311450303 | 9915.180325874655 Lunje | 9955.46356913 | 9951.533852256645 | 9940.329519539344 Pepici | 9950.93625773 | 9971.099451151647 | 9959.873089720966 Bajraktari | 9993.82232318 | 9992.844754025287 | 9981.593909774985 (228 rows) Time: 500.176 ms
    Тож, як бачите, розбіжність складає десь до 30 метрів на 10 км у найгірших випадках, що для більшості сценаріїв є доволі прийнятною похибкою. До речі, ми чекали значно більшої похибки й ця нас цілком влаштовувала.
    Підсумуємо інформацію про «метод кубів». Його переваги: швидкість, простота, можливість «переоцінити» розмір планети, змінивши таким чином одиниці виміру. З недоліків залишається сама точність, бо планета, як і раніше, вважається сферою.
    Цікавіші запити
    Тепер, коли ми знаємо основи, поговоримо про складніші запити. Наведу кілька прикладів, використовуючи для наочності «зменшений датасет» з піцеріями.
    Приміром, нам треба знайти найвіддаленіші від нас піцерії, а після цього визначити, до яких міст вони належать (вважатимемо, що піцерія належить до міста, центр якого розміщений найближче до неї). Звичайно, зробити це можна безліччю методів (бо ж це SQL); наведу той, що, на мій погляд, найточніше висловлює «алгоритм» пошуку.
    WITH pizzerias AS ( SELECT name, ll_to_earth(lat, lng) as point, earth_distance(ll_to_earth(lat, lng), ll_to_earth(42.1, 19.1)) AS distance FROM pizzerias ORDER BY distance DESC LIMIT 25 ) SELECT c.name AS city, p.name, p.distance FROM pizzerias p, LATERAL (SELECT name FROM cities_min c ORDER BY earth_distance(ll_to_earth(c.lat, c.lng), p.point) LIMIT 1) c;
    city | name | distance --------------+---------------------------+-------------------- Pljevlja | Brut | 141584.33308274313 Zabljak | Balkan | 117451.9785288297 Zabljak | Caffe pizzeria Balkan | 117435.32995569201 Zabljak | Lazar | 117308.9999099511 Bijelo Polje | cezar | 116663.29228130652 Bijelo Polje | Orao | 116642.62285195319 Bijelo Polje | Pierre | 116580.71776744149 Bijelo Polje | Padrino | 104133.00996894344 Kolasin | Padrino Pizzerua | 103643.11705954213 Kolasin | Pizzeria Kapri | 87709.3205690596 Niksic | Chaplin | 76339.67053537675 Niksic | Pizzeria Garfield | 76139.35825221038 Niksic | Stari Nikšić | 76118.70681853226 Niksic | Piazza Restaurant & Caffe | 76110.42052261815 Niksic | K2 | 75899.71658365549 Niksic | Šef | 75850.41193677587 Herceg Novi | Grifonee | 62681.009366742284 Herceg Novi | Nautilus | 62597.163060010935 Herceg Novi | Caffe Pizzeria Biblioteka | 62586.73859525146 Herceg Novi | Forte | 61781.28207372379 Herceg Novi | Atelier | 61018.18974275154 Herceg Novi | Popaj | 60869.123535469735 Herceg Novi | Cafe Pizzeria Trg | 60721.08839248005 Herceg Novi | Caffe Pizzeria 5 | 60702.71868706536 Herceg Novi | Pic Nic | 60417.41134618965 (25 rows) Time: 8.487 ms
    Спочатку ми вибираємо найвіддаленіші заклади, використовуючи сортування за відстанню за зменшенням. Після цього нам лишається «пройти» цими даними, вибираючи для кожного рядка найближче місто.
    Ще один цікавий запит. Знайдімо, в яких містах найбільше закладів з піцою; вважатимемо, що там більше люблять італійські смаколики. Логічніше, звичайно, було б рахувати відношення кількості піцерій на душу населення, але мені було ліньки шукати інформацію за населеністю, тому обчислимо «абсолютну» любов. Вважатимемо, що піцерія розміщена в місті, якщо від неї до центру не більше ніж 10 км.
    SELECT c.name, count(cp) FROM cities_min c, LATERAL (SELECT "name" FROM pizzerias p WHERE earth_distance(ll_to_earth(p.lat, p.lng), ll_to_earth(c.lat, c.lng)) < 10000 ) AS cp GROUP BY c.name ORDER BY count(cp) DESC;
    name | count --------------+------- Podgorica | 46 Tivat | 36 Kotor | 31 Budva | 23 Bar | 19 Herceg Novi | 16 Ulcinj | 16 Petrovac | 11 Niksic | 6 Cetinje | 6 Danilovgrad | 3 Bijelo Polje | 3 Zabljak | 3 Pljevlja | 1 Kolasin | 1 (15 rows) Time: 65.703 ms
    Мабуть, результати говорять самі за себе: якщо відкинути столицю, туристичні міста на узбережжі виказують значно більшу любов до піци, ніж ті, що розміщуються в горах (навіть наявність гірськолижних курортів не дуже впливає на традиціоналізм місцевих горян).
    Висновки
    
    PostgreSQL має два вбудованих механізми для роботи з локаціями: оператор та набір функцій earth_distance.
    Використовувати ліпше другий, але їх можливо комбінувати.
    PostGIS — найточніший метод оброблення таких даних, але він складніший з усіх боків, тому здебільшого можна обійтися простішим методом earth_distance.
    Звузити межі пошуку, задавши певний обмежений простір для запиту, — завжди слушна ідея.
    
    Как начинающему разработчику избежать безудержной отладки, красных глаз и испорченного настроения
    April 17, 2020, 3:00 am
    Привет! Я техлид и коуч Binary Studio, поэтому много работаю со студентами и начинающими разработчиками. Все они допускают похожие ошибки, которые замедляют профессиональное развитие. В этом материале я собрал несколько советов, как избежать шишек джуну. Эта статья будет полезна в первую очередь тем, кто уже пробовал писать коммерческие проекты, но еще не имеет достаточно опыта. Я старался концентрироваться исключительно на практических примерах, избегая лишних рассуждений. Весь материал базируется на моем личном опыте, поэтому, если вам есть что дополнить, пишите в комментариях.
    Используй готовые инструменты
    Если бы я мог вернуться в то время, когда только начинал свою карьеру, одним из самых главных советов самому себе был бы следующий: используй инструменты! Как сейчас помню, писал курсовую работу, задача которой была получить изображение с камеры, обработать его набором алгоритмов, записать некоторые данные в базу и отобразить готовую картинку на экран. И это все в режиме реального времени. Сложнее всего было отлаживать такую программу: нужно было одновременно следить за ошибками в работе с камерой, правильностью алгоритма, обращениями к базе данных и, конечно же, за работой с UI-фреймворком (кто имел дело с WPF-стилизацией, тот меня поймет). Со временем, набив несколько шишек и поучаствовав в создании ряда веб-проектов, я выработал для себя набор принципов, которые могут помочь справиться с этой сложностью.
    Как и любой уважающий себя джун, я брался за решение задачи целиком: для того чтобы сверстать страницу, мне приходилось создавать веб-приложение в Visual Studio из темплейта, среди списка существующих файлов находить нужную страницу и писать HTML/CSS наугад, так как результат можно увидеть в браузере только после нажатия F5. Если нужно было отправить запрос на сервер, я добавлял кнопку на страницу, вешал на нее обработчик, добавлял логику построения HTTP-запроса, нажимал F5 и только после клика кнопкой мог посмотреть, правильно ли я описал обработчик запроса на сервере. Visual Studio была моей точкой входа в приложение и точкой выхода. Часто я даже не понимал, что происходит при нажатии на F5, потому что целью было решить ту или иную задачу. Знакомо?
    
    Разделяй и властвуй
    Являясь коучем Binary Studio Academy, а также проверяя по несколько десятков домашек за сезон, я каждый раз сталкиваюсь с тем, что начинающие разработчики совершают одну и ту же ошибку: они пытаются охватить сложную задачу целиком вместо того, чтобы разбить ее на мелкие составляющие.
    Эта стратегия уменьшения сложности задачи путем ее разделения на более простые подзадачи известна как «разделяй и властвуй». В этом случае есть два предположения, которые обычно верны:
    
    задача может быть разделена на несколько частей так, что каждая часть может быть решена независимо;
    решение каждой из частей, составляющих задачу, менее сложное, чем решение всей задачи, и таким образом мы можем «победить» ее.
    
    Верстка и фронтенд
    Сейчас, если мне нужно написать UI, я не запускаю сервер. Вместо этого открываю онлайн-редактор (например, Codepen) и верстаю нужные мне компоненты. Если мне нужно редактировать уже существующую часть приложения, то Chrome позволяет редактировать HTML/CSS на лету, используя вкладку Elements в Chrome DevTools. После этого останется всего лишь скопировать финальную версию и вставить себе в приложение (это намного проще, чем перезапускать приложение после каждого малейшего изменения). Кроме этого, DevTools позволяет отлаживать JS (не алертами, а с помощью переходов), расставлять точки останова, отслеживать переменные и читать Call stack. Отдельные экстеншены дают возможность упростить работу с JS-фреймворками (Angular, React), отслеживать состояние приложения (Redux) и производительность.
    Коммуникация между клиентом и сервером
    Если мне нужно отправить запрос, я уже не создаю кнопку Test на форме. Вместо этого есть несколько инструментов, которые позволяют описать HTTP-запросы во всех деталях: cURL, Postman, Fiddler, RESTClient. Последний мне нравится больше всего, так как это экстеншен к VS Code и он позволяет описывать все запросы в виде интерактивного текстового файла, которым легко управлять. Если мне нужно более внимательно анализировать сетевой трафик, то можно обратиться к Fiddler или Wireshark. Таким образом я могу сфокусироваться на разработке конкретного API-метода в какой-то момент времени, не обращая внимания на остальную часть приложения.
    Разработка бизнес-логики
    Если говорить о бизнес-логике приложения, то в первую очередь в голову приходят юнит-тесты. Вместо того чтобы запускать все приложение целиком, юнит-тесты позволяют сфокусироваться на конкретной функции, которую можно вызвать с теми или иными аргументами. VS предоставляет удобный интерфейс, для того чтобы запускать и отлаживать тесты, а для их написания можно использовать один из следующих фреймворков: xUnit, NUnit, MSTest. Необязательно добиваться стопроцентного покрытия тестами, достаточно уже того, что вы сможете проверить правильную работу своего кода без запуска приложения целиком. Я специально ни слова не сказал о дебаге, потому что, мне кажется, это первое, с чем сталкиваются начинающие программисты. Но, кроме дебага, я советую также разобраться с дизассемблером и научиться читать чужой код (пакеты, библиотеки). Это даст вам более широкую картину того, что происходит за ширмой библиотечных вызовов.
    Взаимодействие с базой данных
    Не стоит забывать и о данных. ORM всячески стараются скрыть от разработчика работу с SQL. Вы пишете модель, затем пару вызовов библиотечных функций и получаете необходимую выборку. Но чем сложнее система, тем сложнее выглядит эта модель и тем большее у нее число функций. Поэтому заранее вооружитесь инструментами для работы с базой данных: IDE, профилировщиком, анализатором структуры запросов, анализатором логов. Если вы работаете с MS SQL, то большинство инструментов идет из коробки (MS SQL Management Studio, SQL Server Profiler, Execution Plan Analyzer), для других баз данных вам придется гуглить каждый инструмент по ключевым словам.
    
    Очень важно, чтобы вы не просто разбили приложение на отдельные составляющие, а и в тех местах, где определили «швы», описали заглушки: мок-данные, скрипты с HTTP-запросами, SQL-запросы. Это может быть полезно по двум причинам: во-первых, чтобы всегда можно было проверить изолированный компонент, а во-вторых, чтобы при объединении всех частей у вас перед глазами был контракт, которому необходимо следовать.
    Перед тем как подвести итог, хотел бы дать пример разработки конкретной фичи (логина пользователя), используя все то, что я перечислил выше:
    
    В первую очередь я фокусируюсь на UI. Как сказано выше, открываю CodePen и стараюсь нарисовать интерфейс компонента, который соответствует мокапам (два поля для ввода логина и пароля и кнопка Login).
    Когда UI готов, могу перенести весь код в компонент и создать все необходимые обработчики. На этом этапе заменяю все сервисы по работе с данными сервисами с объектами-заглушками, для того чтобы проверить функционирование кнопки без обращений к серверу.
    После того как все операции по работе с формой (клик на кнопку, валидация, сообщения об ошибке или переход на другую страницу приложения) правильно заработают с объектами-заглушками, могу переключиться на бэкенд. Сначала описываю эндпоинт, который принимает модель и возвращает код 200. Используя RESTClient, описываю HTTP-запрос в текстовом файле (адрес, заголовки и тело запроса) и проверяю, чтобы мой сервер отвечал правильно.
    Перед тем как приступить к бизнес-логике, посмотрю в базу данных и проверю, все ли запросы, которые связаны с авторизацией, можно выполнить на существующих данных. Так как обычно я использую ORM, этот шаг является всего лишь подстраховкой, потому что ORM сама построит все запросы, а мне нужно только правильно описать модель.
    Теперь я могу приступить к бизнес-логике. Не буду вдаваться в подробности реализации функционала авторизации, хочу лишь сказать, что на этом этапе правильность вашего алгоритма легче всего проверить с помощью юнит-тестов. Добившись того, чтобы моя функция авторизации работала правильно, я могу подключить ее к базе данных, вызвать посредством API-метода и проверить целую связку, используя все тот же текстовый файл с запросом.
    Когда связка «API + логика + база данных» работает, я могу заменить на клиенте сервисы с заглушками реальными запросами к серверу и, если все контракты были описаны правильно, автоматически получаю рабочий функционал. Стоит отметить, что до последнего шага я каждый раз фокусировался на маленьком участке программы и только в конце запустил все приложение целиком.
    
    Конечно, такой подход неидеален и имеет свои изъяны. Во-первых,здесь очень важна дисциплина. Всегда хочется взяться за все и сразу. Важно научиться делить большую задачу на несколько составляющих и фокусироваться на каждой из них по отдельности, отбрасывая все остальное на потом.
    Во-вторых,баги никуда не денутся, однако такой подход дает больше возможностей для контроля на каждом этапе. Если, например, вы видите, что ваш сервер возвращает не те данные (пользуясь вкладкой Network в браузере), можете переключиться на текстовый файл запросов и не использовать браузер до тех пор, пока сервер не будет работать правильно.
    В-третьих,вы могли заметить, что в процессе разработки у меня появилось несколько дополнительных артефактов: mock-сервисы с заглушками, текстовый файл с HTTP-запросами, юнит-тесты и запросы к базе данных (которые тоже желательно сохранять в отдельные файлы). В дальнейшем все эти артефакты вам придется поддерживать. Конечно, вы всегда можете избавиться от дополнительных файлов, как только закончите разработку конкретной фичи, но я крайне не рекомендую этого делать. Гораздо лучше постоянно строить себе подобного рода «леса», для того чтобы в любой момент времени было на что опереться.
    Наконец,скорее всего, вы будете работать над проектом не один, поэтому желательно, чтобы вся команда следовала подобному подходу. В противном случае кто-то перестанет поддерживать дополнительные артефакты или полностью удалит их за ненадобностью (см. пункт выше).
    И все же, запомните главное 🙂
    Когда я начинал свой путь разработчика, то не смог найти подобной статьи, которая подтолкнула бы меня в правильном направлении. Это стоило мне несчетного количества часов безудержной отладки, красных глаз и испорченного настроения. Наблюдая за нынешними студентами, я часто вижу, как они наступают на те же грабли: тратят много времени на уже решенные проблемы, вместо того чтобы сконцентрировать все усилия на предметной области, а второстепенные задачи делегировать инструментам. И даже если описанный выше подход к вашему случаю неприменим, а написание дополнительного кода в тягость, запомните главное: используйте инструменты!
    BA дайджест #8: мастерство работы со стейкхолдерами, прокачиваем модель Kano
    April 18, 2020, 12:00 am
    Всем привет! Несмотря на то, что в связи с ситуацией в мире, большинство материалов за последние месяцы так или иначе посвящены пандемии, удаленной работе и мемам про апокалипсис, все же получилось найти достойные материалы и по бизнес-анализу 🙂 Так что keep calm и приятного чтения!
    Цифры в скобках возле заголовков — примерное время на изучение материала.
    Статьи
    Stuck in the Middle: Mastering Stakeholder Management by Emily Tate(30 мин). Великолепное видео о работе со стейкхолдерами: с каким проблемами можно встретиться, как работать с ожиданиями, как построить «доверие».
    The Kano Methodology(7 мин). Автор статьи делится опытом переосмысления классической техники — он с коллегами сделал апгрейд. Должен признать, я нахожу его крайне удачным и уже взял на вооружение.
    8 Different Ways to Organize Your Backlog to Make it More Impactful(9 мин). Несколько действительно интересных способов организации бэклога, которые выходят за обыденный, скучный, отсортированный список. Рекомендую изучить, как минимум, для вдохновения.
    Designing questionnaires that actually work(4 мин). Очень необычная идея для создания опросников — собирать не связанные напрямую с продуктом ощущения пользователей. Вместе с тем что-то в этом есть. Если сможете объяснить клиентам, почему вы такое у них спрашиваете, и соберете результаты — поделитесь, будет интересно обсудить.
    Бизнес и системный аналитик. Что нужно знать(10 мин). Весьма дельные советы для новичков, которые работают в одной из указанных ролей. Не все пункты очевидны, так что рекомендую к прочтению.
    Проектирование в Confluence(10 мин). Обзор функций WYSIWYG-редактора Confluence. Будет полезен новичкам, которые только начинают знакомство с инструментом (либо если вы до этого не пользовались ничем, кроме стандартных инструментов форматирования).
    Complete Guide to Creating Mobile App Wireframes(9 мин). Неплохой гайд для новичков, который даст базовое понятие о процессе создания прототипов.
    CBAP online с минимальными рисками(5 мин). Автор статьи делится своим опытом прохождения онлайн-экзамена от IIBA. В основном речь об организационно-технических подводных камнях.
    8 mobile form design guidelines(6 мин). Если у вас большой опыт мобильной разработки, то эти советы покажутся вам «капитанскими». Вместе с тем, если вы только начинаете свой путь — must have изучить статью и впитать все, что там написано.
    32 отличия дизайна мобильного приложения под iOS и Android(30+ мин). Крайне достойная подборка с залипательными анимациями — так хорошо и по полочкам еще, пожалуй, никто не раскладывал.
    30 tips for signup flows (so that users stop cursing you)(14 мин). Несмотря на то, что это не первая подобная статья, которая появляется в дайджесте (и в целом), я не перестаю видеть актуальность подобных материалов, так как опыт подсказывает, что помимо актуальности для новичков, старичкам тоже очень полезно просматривать подобные статьи по диагонали. И хотя бы раз в полгода, чтобы не забывать базовые вещи. Но если вы недавно это делали — можно скипнуть, но только в этот раз 🙂
    How To Design Mobile Apps For One-Hand Usage(19 мин). Автор собрал в одном месте, пожалуй, все ключевые моменты и лучшие практики, которые стоит учитывать при разработке для мобильных устройств в современных реалиях, когда большинство девайсов используются одной рукой. Must have к прочтению.
    A suggested approach to the UX Writing process(7 мин). Как правило, подобные статьи содержат примеры и ряд базовых советов. Но сегодня автор делится техникой Voice chart, при помощи которой можно определить тон и формат общения системы с пользователем. Крайне рекомендую всем! Но, в первую очередь, продуктовым аналитикам.
    Let’s talk Neumorphism and Accessibility(6 мин). Очень трезвый обзор того, как эти два понятия уживаются друг с другом. Спойлер: очень плохо. Подробности внутри 🙂
    Understanding loading animations — types and applications(7 мин). Очень доступный материал, включающий категоризацию, примеры и даже требования к времени для анимаций.
    Buttons Alignment Policy(6 мин). Я — не я, если не включу подобный материал в каждый дайджест. Если они вам уже порядком надоели — сразу прошу прощения 🙂 Вместе с тем продолжаю регулярно встречать в дизайне проблемы с кнопками, потому буду и дальше шарить подобные советы для новеньких в IT.
    Guidelines for text fields design(5 мин). Несколько простых, но крайне практических советов по реализации текстовых (и не только) полей. Причем все советы еще и соответствуют принципам accessibility, так что применять их — must have.
    A checklist to improve your product UI (9 мин). Вообще это статья для дизайнеров. Вместе с тем материал очень пригодится аналитику, чтобы повысить качество коммуникации при обсуждении дизайна со стейкхолдерами.
    10 инструментов эффективной работы, или Забудьте о многозадачности(10 мин). В условиях удаленной работы эти, казалось бы, знакомые всем техники мне очень помогли. Спасибо, Павел 🙂
    Повышаем технический бэкграунд
    Android 11: What to Expect From the Latest Android Update?(5 мин). Десктоп-режим, игровой режим и др. Я очень жду первую фичу, заявленную еще для версии, так как это очень сильно упростит жизнь владельцам планшетов, которые привыкли работать за ПК (таким, как я).
    Проблемы релиза фич в больших проектах(6 мин). Знания для общего развития. Они дадут понимание, почему иногда внезапно простую фичу, которую делали давно, нельзя просто взять и вылить на прод.
    CAPTCHA: убивая конверсию(9 мин). Несмотря на то, что автор в большей степени ругает капчу и не раскрывает детали альтернативных вариантов защиты, кратко предложенных в конце статьи, материал имеет рациональное зерно. Не знаю, как вы, а я теперь еще раз подумаю перед тем, как применять капчу где-либо.
    API Style Guide, или Не заставляйте пользователей думать(8 мин). Если вы много работаете с API или даже составляете сопутствующие API спецификации, эта статья поможет узнать, чего требовать от себя или от разработчиков, когда следующий раз столкнетесь с недостаточно документированными запросами.
    Сравнение семи популярных платформ для вебинаров и конференций(15 мин). Обзор Skype, Zoom, Hangouts и других платформ (хороший, хоть и недостаточно глубокий; например, отсутствует что-либо про приватность и безопасность).
    8 плюсов Flutter по сравнению с React Native(6 мин). Материал поможет понять, почему с течением времени хайп вокруг Flutter становится все больше.
    События
    Product Marketing дайджест #3: стратегия роста во времена неопределенности, путь с $0 до $1,3M MRR
    April 18, 2020, 3:00 am
    Всем привет! Надеюсь, вы сидите дома и не болеете. Чтобы вы не скучали, я подготовил новый выпуск дайджеста. Сегодня в выпуске: маркетинг в LinkedIn, как проводить опросы, как работать с возвратом клиентов и много чего интересного.
    Почитать
    В настоящее время существует большая неопределенность в отношении того, что происходит на рынке. Поведение клиентов изменилось так быстро, что невозможно знать, что будет дальше. Reforge выпустила для B2Bи для B2Cнебольшие гайды: что делать в текущей ситуации. Если вы продаете бизнесам, то ищите новые возможности продаж, поскольку личные продажи и продажи на ивентах не работают по понятным причинам. Если работаете в B2C, то учитывайте, что стоимость конверсии сейчас будет расти и задумайтесь о бесплатных каналах привлечения. Также отталкивайтесь от своих ресурсов. Если конкуренты снижают рекламные бюджеты, то есть возможность нарастить долю на рынке.
    Стек маркетинговых технологий (martech) — это группа технологий/инструментов, которые маркетологи используют для анализа и улучшения своего маркетинга. Intercom попробовал разобраться в этом огромном океане (а это на минуту больше 7000 компаний) и опросил экспертов, чтобы выбрать лучшие инструменты.
    Редко бывают случаи, когда с первой попытки удается вырастить крупный бизнес. История Convertkit тоже не из таких. Фаундер прошел тернистый путь за 7 лет с 0 до $1.3M MRR.Как ему это удалось на рынке, где уже есть такие гиганты как MailChimp и ActiveCampaign? Фокус на сегменте авторов и правильное позиционирование. В статье также разобрано, как ConvertKit привлекал клиентов и почему.
    Понимание клиентов — это ключ к улучшению и расширению вашего бизнеса, но вы не сможете понять своих клиентов, если не узнаете о них больше. Один из способов сделать это — задать правильные вопросы для опроса в нужной точке их путешествия. С чего начать и какие вопросы задавать? Hotjar подготовили хороший гайд на эту тему.
    Рано или поздно идеи для блог-постов заканчиваются. И что делать дальше? Объясните фундаментальные понятия, которые будут полезны вашим клиентам, взвесьте плюсы и минусы в непростых решениях, запустите опрос и опубликуйте результаты. Мало? Почитайте гайд от Ahrefs с огромным количеством примеров. Обязательно найдете, что-то интересное для себя.
    Удержание клиентов — тихий убийца SaaS-бизнеса. Даже если вы приобретаете новых клиентов задешево, но они останутся на месяц или два, вы не сможете построить устойчивый долгосрочный бизнес. Есть готовые рецепты, как решить эту проблему? Конечно нет 🙂 Но все равно советую почитать best practices от Intercom, которые вам помогут начать системно работать с retention или подкинут новых идей.
    Послушать
    Во время одного из разговоров с коллегой мне пришла мысль, что обмениваться опытом можно не только 1 на 1, а еще и делиться этим с аудиторией. Как? Да просто записывать такие разговоры и делать подкаст. Так появился на свет мой подкаст Marketers. Сейчас уже опубликованы два выпуска: с Русланом Назаренко про работу в одном из самых быстрорастущих стартапови с Ильей Азовцевым о маркетинге в LinkedIn. Скоро будут новые эпизоды, поэтому подписывайтесь, чтобы не пропустить.
    Ребята из Product&Growth Show выпустили первый эпизод на английском языке с Head of Marketing в Mindvalley. В выпуске обсудили, куда идет рынок онлайн-образования и как продвигать вебинары.
    Посмотреть
    Рекомендую посмотреть вебинары от Reforge про рост во времена неопределенности. Доступны версии для B2C, B2Bи фаундеров.
    Поучиться
    Хотите получить структурированные знания по продуктовому маркетингу? Тогда приглашаю на курс от Lviv Product School, в котором я совместно с крутыми ребятами из MacPaw, HelpCrunch, Readdle, Crello, Wix поделимся своим опытом. Поспешите, регистрация скоро закроется. P. S. Если скажете, что от меня, то получите скидку в 15%.
    Ahrefs открыл свой курс за $799для всех желающих! Крутой курс, который я прошел полгода назад и советую всем, кто уже работает с контент-маркетингом или хочет развиваться в этом направлении.
    Спасибо, что дочитали до конца. Увидимся в следующем выпуске!
    P. S. Подписывайтесь на мой канал в Telegram, чтобы быть в курсе всего интересного из мира маркетинга продуктов и не пропустить следующий выпуск дайджеста.
    C++ дайджест #26: StayAtHome та вивчай Machine Learning
    April 19, 2020, 12:00 am
    Привіт, мої любі сішники! У цьому випуску пропоную ознайомитися з фреймворками для машинного навчання. Почнімо? 🙂
    Machine Learning
    
    Машинне навчання наразі є актуальним та набуває все більшого поширення. У списку найбільш використовуваних мов програмування на другому місці впевнено тримається С++ (link 1, link 2, link 3). Тож розлянемо, за допомогою яких бібліотекми можемо працювати у світі С++ 🙂
    DMTK (презентацiя) — фреймворк від Microsoft для клієнт-серверних систем. Підтримує масштабовність.
    cuDNN — бібліотека глибинного навчаннявід NVIDIA з обчисленнями на GPU.
    mlpack — бібліотека для глибинного навчання, написана на С++. Гарно масштабується, але має не досить обширну документацію, якщо порівнювати з Caffe2 або TensorFlow.
    TensorFlow — мабуть, найвідоміша бібліотека машинного навчання, розроблена та виплекана корпорацією зла Google. Посилання для ознайомлення та вивчення:
    
    Build and Train Neural Network with Tensorflow C++;
    Machine Learning on Desktop, iOS and Android with Tensorflow, Qt and Felgo;
    Как я Keras на C++ запускал;
    Как подружить Tensorflow и C++;
    Exporting trained TensorFlow models to C++ the RIGHT way!;
    Tensorflow Lite integration with Qt and Felgo for multi-platform machine learning apps on iOS and Android;
    Coral USB Accelerator, TensorFlow Lite C++ API & Raspberry Pi for Edge TPU object detection;
    Machine Learning: Add Image Classification for iOS and Android with Qt and TensorFlow;
    How to Create an Image Classifier Using Qt, OpenCV and TensorFlow.
    
    COVID-19
    Modern C++
    Корисні посилання
    Інструменти
    Оновлення
    Цього місяця маємо такі оновлення:
    
    LLVM 10.0.0 Release Notes;
    Qt 5.14.2, Qt Creator 4.12, Qt Automotive Suite 5.13.2;
    CLion 2020.1;
    Vulkan 1.2.137.
    
    Хвилиночка флуду
    
    
    
    
    Как извлечь пользу из проваленного проекта
    April 20, 2020, 12:00 am
    
    Сорванные сроки в два раза.
    Что делать с бюджетом?
    Как выйти с минимальными потерями?
    Где искать чудо?
    Ошибаться не страшно, страшно не нести ответственность.
    
    Проваливать проект — это не плохо, плохо выходить из проекта, не взяв на себя ответственность.
    Привет! Сегодня мы поговорим о фейлах.
    Однажды я решил заняться развитием собственной компании, и вот уже 8 лет, как двигаюсь в этом направлении. И чем чаще спотыкаюсь и больше шишек набиваю, тем сильнее мне хочется делиться этим опытом с теми, кто столь же отчаянно строит собственную компанию. Я не претендую на истину в последней инстанции, но буду очень рад, если другим менеджерам и руководителям статья поможет преодолеть сложные этапы развития.
    
    Иллюстрация Уляны Патоки
    Что такое «фейл»
    Google переводит английское fail как «провал», и это нам подходит, поэтому в дальнейшем будем использовать его именно в этом значении.
    Фейлят все — и большие компании с опытом, и маленькие «зеленые» фирмы. Не фейлить невозможно. Вы не можете спрогнозировать все риски и проработать их, но даже если можете, то на это не всегда хватает времени и ресурсов; в итоге вина за провал возлагается на компанию, подписавшуюся на проект.
    Можно, конечно, приводить много возражений и отмазок: клиент постоянно меняет скоуп, он не понимает, как осуществляется разработка, клиент неадекватен, таким заказчикам место на фрилансе, у клиента не тот часовой пояс или характер 🙂
    Но все равно виновата компания!
    Кто не проработал риски? Кто неправильно их оценил? Кто хотел завести проект быстрее, чтобы избавиться от бенча? Кто экономил на ролях в проекте? И так далее.
    Не берите проект, если вы не уверены, что доведете его до конца.
    Чтобы это понять, реально оцените свои силы: много ли в вашем окружении людей или компаний, которые смогут помочь вам, если у вас не хватит ресурсов или экспертизы. Здесь важно опереться на собственный успешный опыт, и, если вы уже преодолевали подобные челленджи, тогда все окей, ведь вы уже знаете, как это бывает.
    Возможно, за вашей спиной команда, на которую вы можете опереться железобетонно.
    В моем случае есть понимание своего внутреннего ресурса, и, конечно же, я могу опираться на свою команду: она уже неоднократно оправдывала доверие, ввязываясь в бой вместе со мной. Хочу сказать, что эти челленджи вынесли ребят на новый уровень и сделали только круче.
    Например, иногда бывают ситуации, когда нужно брать проект на новой технологии. Тогда вы должны быть на 300% уверены, что, даже если ваши менеджеры и разработчики покинут вас, вы зарелизите проект в срок. Впрочем, это уже тема для другой статьи 🙂
    Итак, самое правильное, что вы можете сделать, это избежать фейла.
    Как не зафейлиться
    Большая часть фейлов зарождается на первых фазах проекта, таких как исследование (Discovery) и/или инициализация, поэтому важно ничего не упустить. Эти фазы связаны с планированием, подготовкой и проработкой рисков, но очень часто (в спешке или из-за отсутствия оплаты) их просто опускают, полагаясь на адекватность клиента по ту сторону монитора.
    Часто бывает, что, для того чтобы перекрыть бенч, приходится завести проект. Или прилетает заявка, по которой срочно нужно принять решение, брать ее в работу или нет. В таких случаях даже опытный Project Manager не всегда может все предусмотреть.
    Отличный вариант, когда такое решение принимается командой как осознанная необходимость (подчеркну, именно командой, потому что в случае чего крайним потом будет один Sales Manager, искренне спасавший бюджет компании).
    И совсем не отличный вариант, когда такое решение принимается на авось по принципу «лучше так, чем никак» либо когда Sales Manager невзирая ни на что хочет получить свой процент, то есть когда компания даже не делает попыток проработать риски.
    Самое главное — избежать фейла. Ниже рассмотрим методы, которые помогут это сделать.
    Коммуникация — слышать клиента, быть на связи, интересоваться его бизнесом и делами. Составлять в начале проекта план действий, на случай, если что-то пойдет не так. Если вы не знаете, что обсудить, скажите, что вы всегда готовы к открытым переговорам и признанию своих ошибок.
    Например, обсуждая с клиентом этапы работы, сообщите ему, как будете действовать, если что-то пойдет не так, и как вы будете его об этом информировать. Скажите ему, что это нормально и профессионально, что вы считаете правильным быть в курсе того, как обстоят дела у клиента.
    На одном из наших проектов у клиента заболел родственник. Менеджер, увы, не предпринял никаких шагов, чтобы уточнить, что происходит, полагая, что заказчик знает, что делает. Клиент стал реже отвечать, но и это не смутило менеджера. В итоге заказчик пропал и отказался оплачивать остаток работ, сославшись на подавленное состояние. Все закончилось хорошо, но мы потеряли время.
    Управляйте ожиданиями — если что-то идет не так, говорите клиенту сразу и корректируйте его ожидания. Обсуждайте, что и как он получит. У молодых менеджеров часто бывают с этим проблемы, поскольку они боятся сообщать о неприятностях клиенту. Так вот знайте, что, если вы можете говорить подобное клиенту сразу, ничего не стесняясь, — это опыт!
    Планирование и риски. Однажды на ивенте я невольно подслушал, как звукорежиссер, настраивавший оборудование для большой сцены, ругает своего молодого помощника, не следовавшего правилу «5П»: Правильное Предварительное Планирование Предупреждает Происшествия.
    Если вы изучите каждое слово в контексте проектного менеджмента, с вероятностью 99% ваш проект будет спасен. Конечно, как ни прорабатывай правила, рано или поздно столкнешься с риском, который не был предусмотрен. Но вы достаточно легко с ним справитесь, если будете знать, что делать в смежных ситуациях. Собираетесь ли вы в лес на пикник или разворачиваете проект ВigData, это правило универсально. Если вы играли когда-нибудь в шахматы, это оно. Вы должны увидеть доску и просчитать все варианты ходов каждой фигуры противника.
    Однажды при организации ивента в Испании возникли непредвиденные ситуации, в которых один спикер потерял чемодан, а другой — задержался на 2 дня. Хорошо, что у нас не только был проработан трансфер, но и имелась пара личных авто в запасе; они должны были отвечать за кухню, на них и забрали спикера из аэропорта. Так что проверено на себе 🙂
    Виды фейлов
    Здесь ничего нового: приходим к старому доброму тройственному ограничению из проектного менеджмента.
    Сроки.Вы срываете клиенту сроки, и у него слетает заранее проплаченная рекламная компания, затягивается демо для инвесторов стартапа, или ему нужно приложение под ивент, который передвинуть невозможно
    Например, бывало так, что неопытный PM сам, без согласования с клиентом, принимал решение о том, когда провести демо, а клиент, в свою очередь, сам принимал решение о приглашении на демо инвестора.
    Случалось, что PM погружался в разработку на 3 дня, а на оказывалось, что клиент уже нашел сейлза и директора и пришел с претензией к PM. И тут выяснялось, что PM в это время работал не покладая рук, но не информировал об этом клиента, поэтому тот в ужасе начал менять свои планы и т. д.
    На мой взгляд, управление ожиданиями на 80% закрывает вопрос сроков.
    Бюджет.У клиента совсем нет денег, а проект не доделан. Так может случиться, когда у вас не просчитаны риски и не пройдена фаза Discovery проекта, а в ходе разработки вы узнаете, например, что платежная система функционирует совершенно по другому принципу. Часто случается, когда разработчик откладывает непонятные задачи на потом, а когда наступает это самое «потом» и задача становится понятной, выясняется, что API службы доставки, которую нужно интегрировать в интернет-магазин, вообще не заточена под такую интеграцию. Менеджер не отвечает за это непосредственно, потому что эта проблема технического характера, но он обязан на соответствующем митинге проработать этот риск с командой заранее.
    Скоуп.Экспертиза может закончиться, и тогда решение вопроса становится непредсказуемым — и по деньгам, и по срокам. Бывает, что в ходе разработки выясняется, что клиенту, например, нужно не просто добавлять данные в таблицу, но и осуществлять их разбор, и генерировать по ним отчеты. В ходе работы вы понимаете, что это OLAP, к которому вы не знаете, с какой стороны подступиться.
    Та же история: задачи, не проанализированные на ранней стадии, позже могут выйти боком. У нас был случай, когда зашел в работу большой проект и ребята оценили его как обычную CRM на Laravel. Уже после прохождения отбора в конкурсе, за день до подписания контракта, разработчики получили уточняющий комментарий клиента, что для нас означало работу с BigData + OLAP, о чём мы на тот момент знали не больше, чем о дальнем космосе и полетах спутников. Все закончилось хорошо: немного танцев с бубном — и HR + CEO + DevOps пересобрали команду, проект успешно взлетел, но понервничать нам пришлось серьезно.
    Основные факторы, повышающие вероятность фейла (стейкхолдеры)
    Сотрудники
    Болезни.Да, люди болеют, и болеют чаще всего внезапно. Поэтому в идеале всегда должен быть второй человек, обладающий такими же навыками. Это позволит поддерживать баланс в случае чьей-нибудь болезни.
    Отпуска.Менеджеры не всегда помнят об отпусках разработчиков. Некоторые люди вовсе не возвращаются из отпусков. Вот почему важно, чтобы менеджеры заглядывали в планы отпусков.
    Усталость.Разработчик, давно не бывший в отпуске, будет выдавать очень низкий КПД. Важно, чтобы HR выявлял это при первых же звоночках: апатии, непунктуальности, изменении обычного поведения, грустном настроении или прохладном отношении к работе. Усталость — подлая штука, часто она приходит совершенно неожиданно, в одно прекрасное утро.
    Увольнения.У сотрудников меняются жизни, на них влияют родственники, климат, законодательство — с этим ничего не поделаешь.
    Фрилансеры.Это категория людей, среди которых очень маленький процент хороших подрядчиков, но они есть. И если у вас нет классного контракта, работать с фрилансером — это все равно что иметь дело с котом в мешке. Да простят меня боги фриланса!
    Требования
    Нет требований.О каком обещании и сроках может идти речь?
    О неполных.Вы сами управляете рисками и разбираетесь в том, что для разработчиков и тестировщиков важно, а что нет. Для каждого проекта полнота требований своя, где-то достаточно хорошего мокапа, а где-то нужны функциональные требования и диаграммы use case. Главное, чтобы менеджеру и команде было на 100% понятно, что делать для достижения результата, обозначенного заказчиком.
    Здесь трудно дать конкретные рекомендации. Все зависит не от проекта, а от глубины понимания задач разработчиками и остальных членов команды, но это уже определяется их опытом.
    Менеджмент
    «И снова здрасьте» — это менеджмент, от которого на 98% зависит возникновение фейла.
    Нет backlog’a — нет оценки и приоритетности задач. Как следствие, нет плана движения и сроков по проекту. Всегда прикидывайте объем задач, сопоставляйте, насколько вы в него вписываетесь, и информируйте клиента о малейших возможных рисках.
    Нет трекинга — менеджер не следит за состоянием задач, не проводит ежедневные митинги. Если менеджер теряет понимание происходящего, компания начинает терять время и деньги.
    Нет управления ожиданиями — клиента не вводят в курс происходящего (как позитивного, так и негативного), в итоге заказчик вообще ничего не понимает. Даже если вы решите не посвящать клиента в трудности проекта из благих побуждений, позже он будет удивляться каждой заминке и считать вас непрофессионалами.
    Когда фейл настал
    Четыре пункта, описанных ниже, очень хорошо работают в моей практике. Из них можно сделать roadmap и смело использовать.
    
    Признать и взять ответственность.Поверьте, не нужно спорить, это не приведет ни к чему хорошему. Может, на 10%, на 50%, 80%, но ответственность перед клиентом нужно принять, стиснув не только зубы, но и все места, которые можно стиснуть.
    Написать отчет, почему это произошло.Написать недлинный отчет клиенту о том, что привело к этому фейлу. Желательно так, чтобы отчет содержал понятные клиенту процессы. Это убедит клиента в том, что вы понимаете ситуацию, его беспокойство и можете контролировать происходящее.
    Обозначить конкретные шаги и сроки.Обсудите шаги, которые нужно предпринять, и сроки их выполнения. Даже если вы еще не знаете, что делать, добавьте риски и заложите время на ресерч, но выдайте клиенту конкретику. Хорошо работает демонстрация позитивного и негативного сценариев, с ориентацией клиента на негативный. Он скажет, что понимает вас, но все равно будет думать о позитивном: так ему легче. В результате клиент убедится в том, что вы эксперт и знаете, что делать. Это успокоит его.
    Стать более внимательным.Теперь, пока вы не разберетесь с фейлом, следует быть максимально внимательным. Разумеется, не нужно звонить клиенту утром и спрашивать, как он себя чувствует и не остыл ли его кофе, но всю информацию по проекту важно доводить до ведома заказчика максимально быстро.
    Бояться также не стоит: терять вам уже нечего — можно только приобрести.
    
    Рассказывайте клиенту о каждом маленьком прогрессе. Чем чаще вы будете его информировать, тем скорее у него появится ощущение, что ситуация под контролем, и он успокоится.
    Глазами клиента
    Клиенту важно знать, что он получает. В тот момент, когда вы сорвали проект, реализовав который клиент хотел спасти мир, он утрачивает понимание того, что происходит, а заодно и доверие к вам, и начинает ощущать себя обманутым. Поэтому важно всегда сообщить ему, что он получит, без общих фраз. Клиента пугает отсутствие конкретики, потому что он бизнесмен, а значит, у него есть план развития. И когда вы фейлите проект, то вы тем самым подрываете его план спасения мира.
    Где искать чудо и бюджет
    Теперь нужно разобраться с ситуацией, когда вам страшно, неясно, что делать, а в голове все время вспыхивают вопросы: кто это будет фиксить? за какие деньги? в какие сроки?
    Ответ прост: чудо наступает после того, как вы возьмете на себя ответственность за происходящее и проявите вовлеченность в проект. Вы начинаете видеть, что клиент тоже человек, и даже если он и не идет вам навстречу, то подстраивается и помогает.
    Клиент компенсирует бюджет, если он увидит, что вы вложились в его проект по полной. Когда работа будет закончена, отправьте ему письмо, в котором в цифрах будут указаны ваши затраты на устранение этого фейла. Это вызовет уважение к вам, клиент увидит, сколько ресурсов вы вложили. Предложите ему покрыть часть этих расходов настолько, насколько он считает справедливым.
    В нашей практике клиенты покрывают от 50% этих работ.
    Давайте подытожим, как обернуть ситуацию себе на пользу
    
    Принять в ней максимум участия и ответственности. Это поддержит клиента.
    Продолжать демонстрировать результат. Это придаст клиенту уверенности.
    Закончить проект. Это создаст клиенту ценность, а вам вернет репутацию.
    Отправить смету. Это увеличит вероятность, что клиент оплатит часть расходов.
    Ретроспектива и выводы — вишенка на торте — покажут вашу системность. Отправьте результаты ретроспективы клиенту.
    
    Совсем немного нашей собственной статистики:
    
    70% клиентов возвращается после выруливания ситуации;
    более чем 50% бюджета, ушедшего на устранения фейлов, покрывается в благодарность за вашу ответственность.
    
    На личном примере
    Напоследок рассмотрим кейс, имевший место в работе нашей компании.
    О проекте
    Достаточно большой проект, агрегатор национального масштаба. Стек технологий: Laravel + SPA + SSR.
    Что произошло
    После смены нескольких команд разработчиков в течение полугода возник коллапс с багами. PM не вытянул, не смог найти общий язык с клиентом, начал хитрить и перегружать разработчиков команды бестолковыми заданиями.
    Как отреагировал клиент
    Клиент выдвинул ультиматум — окончить работу. Затем подключил сторонних разработчиков, да еще и фрилансеров, в итоге количество багов только возросло.
    Как разрулили
    Заново собрали команду, усилив ее техлидами и более опытными сотрудниками. Создали план выхода из кризиса и согласовали его с клиентом понедельно. Обсудили объем работ и назначили клиенту дату, когда будет устранено 80% ошибок.
    В общем, спасибо, что дочитали. Помогайте клиентам, не бросайте их у разбитого корыта или проекта. Ведь им страшнее и сложнее, чем вам. Любите свою работу и служите людям!
    «Нужно давать людям играть. Ставить сложные задачи. Платить за их ошибки». Александр Конотопский — о задачах Ajax Systems, найме инженеров и украинском продукте
    April 20, 2020, 4:00 am
    Я довольно давно знал о существовании Ajax Systems, но как-то не внушало доверия отечественное производство электроники. А потом мне довелось попробовать. И так вышло, что одновременно я попробовал пользоваться сигнализацией Ajax и домофоном одного из китайских флагманов компании Hikvision. Я был поражен. Поражен тем, насколько китайцы сделали глючное устройство и насколько наше просто работало. Отлично работало.
    Потом начали выходить разные интервью основателя Ajax Александра Конотопского, и он оказался очень харизматичным спикером. Но во всех этих интервью с ним разговаривали про бизнес, а мне было очень интересно порасспрашивать про айти. И вот мы записали двухчасовой разговор.
    Самые интересные тезисы из видео можно прочитать ниже. Если больше нравится слушать или смотреть, ссылку вы найдете в конце. А также подписывайтесь на мой телеграм-канал, там будет небольшой гиковский кусочек, не вошедший в видео, где мы обсуждали фронтенд.
    И еще одно, у нас тут конкурс для самых активных.
    Я совсем не профессиональный журналист, поэтому тем, кто посмотрит полную версию, было бы что добавить. Так вот, предлагайте в комментариях свои вопросы Александру, а он выберет лучший и подарит комплект сигнализации (Hub 2 и датчик движения с фотофиксацией). Вопросы принимаются в течение недели после публикации.
    
    «Сегодня и ближайшие два-три года мы будем делать то, чего просят люди»
    Hardware или software компания — на сегодняшний день это однозначно тесно связанные понятия. Все наши ноу-хау, точки продаж, технологии — это software defined. Hard у нас на хорошем уровне, он тесно переплетен с soft. Когда мы начинаем что-то разрабатывать, всегда делаем это с самого нуля, чтобы иметь полную свободу выбора. Какой процессор мы поставим, какие аналоговые схемы, какие алгоритмы мы построим на них? И, например, то же «время работы от батареи» — одна из сильных наших сторон за счет того, что переплетены hard и soft.
    Если мы возьмем наше программное обеспечение и наложим его на какую-то стандартную плату — ардуиновскую или китайскую — мы не получим таких показателей. В целом, мы фанаты Apple: бизнес-девелопмент, производственный менеджмент, саплай чейн менеджмент, разработчики. Нельзя оторвать Embedded Soft от Cloud Soft, потому что это все — очень интегрированная система. Например, у нас специально разработанные протоколы идут от наших радиодатчиков до хаба, от нашего хаба до серверов, от наших серверов — до приложений.
    Забавно, что промышленный дизайн — это тоже очень важный фактор, который влияет на культуру компании. Когда разработчик приходит на работу, он может делать абсолютно бездушные вещи, и у него будет «настроение один». И он может создать какую-то крутую штуку, когда видит крутой дизайн — ему хочется круто программировать. Конструкторы, когда видят крутой дизайн, хотят сделать крутой конструктив. Ребята на продуктовых линиях, которые собирают устройства целыми днями, понимают, что делают крутые вещи. От того, что он неправильно соберет устройство, у кого-то может сгореть дом или может погибнуть человек. И поэтому он себя ощущает немножко по-другому. Когда делаешь красивые штуки, ты на них концентрируешься и работаешь с абсолютно другим настроением.
    В Ajax много software и hardware инженеров — первых, конечно, ощутимо больше. «Железо» мы сделали один раз, а программное обеспечение в нем обновляется три года. Пример: сейчас мы выпускаем датчики с фотоверификацией MotionCam. Там у нас технология Wings, и это software defined radio. Радиопротокол создается в основном за счет софта. Но при этом я всегда обращаю внимание, что не стоит недооценивать ни производство, ни hardware. Принято считать, что «железо» — это коммодити. На самом деле все не так просто.
    Инженеры, которые делают продукт, интернет вещей, должны пересекаться. Хардвер-инженер должен немножко «рубить» в софте, а софтвер-инженер — в харде. Я видел, как софтвер-инженеры, которые не «рубят» в харде, тормозили проект. Они его не могут реализовать в принципе. Соответственно, если человек умеет только готовить программное обеспечение, он скажет: «Так, я сейчас поставлю сюда Embedded Linux и в User Space напишу Sensing технологию. И мне нужен будет аккумулятор 200 ампер-часов, чтобы этот датчик работал год». — «Нет-нет, чувак, подожди. Он должен быть небольших размеров. У него должен быть кост, в рынок должен попадать». И он такой: «В смысле?».
    Сейчас мой основной челлендж — логистика, цепочки поставок, закупки и финансы. Никогда не думал, что там могут возникать проблемы. Я понимаю ценность своего производства, потому что видел, как у моих друзей были заблокированы поставки на контрактном производстве. Я видел людей, которые не имеют производственной маржи. Финансово их бизнес ощутимо менее здоров, чем наш.
    Раньше я говорил, что мой фокус — R&D, бизнес-девелопмент. Это наше сердце, наша нефть. Если убрать R&D, бизнес-девелопмент и оставить чисто продакшн, будем более бедной компанией, чем сейчас. Если отдать на аутсорс производство, поставки, тоже будем беднее, чем сейчас. Еще забавно, что на нашем рынке клиенты ценят то, что производство — именно наше. Клиенты уверены, что мы не производим в Китае, уверены, что нет дыр в устройстве.
    Сегодня и ближайшие два-три года мы будем делать то, чего просят люди. А у нас запросов на дополнительные функции ощутимо больше, чем возможностей по реализации. Это однозначно мой фокус. Часто вижу ребят, которые запускают свои стартапы. Например, собираются фокусные инженеры. Я говорю: «Ребята, пойдите сначала спросите, кто хочет это купить». Не надо ходить на продуктовые конференции — пойдите к людям. Хотите что-то продать корпоративному клиенту? Найдите кого-то из компании, позвоните туда и спросите: «Вам такое надо?». В Америке, в Англии поспрашивайте. А если делаете hardware, то помните, что вам нужны деньги на запуск производства. На Амазончик денег закинули, нажали, вылились. В hardware-релизе — немножко иначе. Сперва надо подумать об этом реальном мире.
    «Если ты сильнее человека, который управляет непосредственно подразделением, значит, ты очень плохо нанимаешь»
    Я уволил себя со множества занимаемых должностей в Ajax Systems. И в один прекрасный момент может появиться человек, у которого будет лучшее продуктовое видение. И я тоже себя уволю. Может прийти человек, который будет лучше драйвить бизнес. Год назад, например, у меня была проблема: мы получили большую дырку в кэш флоу, потому что директор отдела продаж неправильно составил прогноз и не вытянул контракты.
    Сегодня, спустя год, мы выросли в два раза, и у нас проблема с размером продакшна, потому что контрактов больше. Проблему с продажами мы ликвидировали. И у меня очень крутая пачка биздевов, которые захватывают рынки.
    Мы увеличили команду раза в четыре. Если год назад мы сами ходили слушать, как строить биздев, то сегодня уже мои ребята могут пойти в бизнес-школу (украинскую и не только) и рассказать, как нужно строить B2B-биздев для крупных европейских контрактов. Соответственно, здесь есть стратегическое мышление, видение будущего, команда. Для меня задачи СЕО — о двух историях: куда мы идем и что мы делаем в перспективе. Интегрируем HomeKit или выпускаем еще один датчик для защиты периметра?
    Если ты сильнее человека, который управляет непосредственно подразделением, значит, ты очень плохо нанимаешь. На сегодняшний день, собственно, найм, привлечение (мне не очень нравится слово «найм», лучше «привлечение людей в команду») — это основная моя задача. Я раньше думал, что это — стройка. Вот возьму чувака, который работал в большом бизнесе, поставлю финансовым директором, и он все сделает. Возьму другого чувака, поставлю. Потом я понял, что это сельское хозяйство и имплантология в комплексе. Как органы: когда их имплантируют, они иногда приживаются, а иногда — нет. Если они прижились, то должны прирасти, вся эта история должна вырасти. Очень важно, как сама по себе команда растет. Нужно давать людям играть. Ставить сложные задачи. Платить за их ошибки — не только за свои, и я к этому нормально отношусь.
    Нормально, что иногда людей уводят. Ведь человек выбирает, где ему интереснее, где лучшие условия, где сильнее идея
    Кроме того, есть и другие инструменты корпоративного управления. Например, независимые директора на борде. Мы стараемся постоянно быть ровными — чтобы за счет разных мнений разных людей, этого пресловутого разнообразия мы не попали в ловушку одного человека. Все вокруг боятся об этом сказать.
    А в украинской (в СНГ-шной, в принципе) бизнес-культуре мы привыкли к пирамидам. Вот здесь есть папа, он самый умный, а дальше все — свита и его помощники. Но технологические компании так не растут. Например, у нас много талантливых людей. Я уверен, в моем офисе огромное количество ребят, у которых IQ выше моего. У них прекрасные идеи. Моя задача — их слышать, слушать как можно больше. И опираясь на эти идеи, принимать решения.
    Если раньше я мог быть в разных частях моего бизнеса реально лучшим, то на сегодняшний день я нигде не лучший. Например, Валик Гриценко сильно поднял торговую марку Ajax, Богдан Демчишин — раскачал производство. R&D лиды сильно вырастили и команды, и уровень продукта, который они делают, и уровень технологии — он вырос без моего участия. Уже многие продукты, которые презентованы — это не мои продукты. Да, я мог сориентировать: «Вот, сделайте примерно это. Рынок — примерно такой. Грубо говоря: это для Италии, Испании и Южной Африки. Цена — примерно такая-то. А конкуренты такие».
    Дальше ребята собирали бизнес-требования, изучали рынок, разработку, запускали массовое производство, делали продажи. И это все делалось другими руками. При таком моем поверхностном участии вышли, например, MotionProtect Outdoor, Button.
    Нормально, что иногда людей уводят. Ведь человек выбирает, где ему интереснее, где лучшие условия, где сильнее идея. Я нормально к этому отношусь, это работает и в обратную сторону. Мы берем людей с того же рынка — и они выходят на тот же рынок. Это все взаимосвязанная история, и это не всегда найм.
    Конечно, люди уходят и приходят. У нас, как у любой, наверное, продуктовой компании, текучка ощутимо меньше, чем в аутсорсе. Если не брать интернатуру, где у нас есть специальности, которых нет на рынке. Например, на рынке нет Embedded QA. В том виде, в котором нам нужно, никто не тестит хардверные девайсы, и этих специалистов неоткуда брать.
    Соответственно, мы воспитываем, растим этот домен. Потом кто-то увольняется, уходит, начинает работать в других компаниях. Мне кажется, в IT сегодня мы все друг другу комплиментарны. Не бывает, чтобы кто-нибудь пошел и все съел у других. Это экосистема, которую мы делим.
    Безусловно, у нас есть ребята, которые и выше рынка, и ниже рынка. Хороший вопрос: что такое рынок? Наверное, для меня рынок — это DOU: лучше метрики никто не придумал. И, в принципе, наверное, в Украине это — лучшая метрика.
    Скажу так: мы редко отказываем по причине, что для нас это дорого. Такие случаи есть, но они редки. И от нас редко уходят, потому что у нас хуже условия по деньгам. При том мы находимся на окраине Киева — у нас есть определенная философия, которая стоит за этим. Здесь мы, скажем так, несгибаемы. Потому что крайне не хотим стать «смузи стартапом», куда ходят за смузи, а не за продуктом.
    Что касается зарплаты, мы всегда делаем взвешенное предложение. Приходит человек, просит выше рынка. Например, на заводе есть линейная зависимость. А в программировании ее нет. Крутой чувак может перформить и в десять раз больше. Он крутой архитектор, его не заменить средними специалистами. Соответственно, можем сделать предложение выше рынка. Мы получаем хороший заработок за те разработки, которые мы делаем. Для нас это крайне важно. Инженерная сила — определяющая.
    
    «У нас есть работник, который зашел как джун QA, и сегодня он участвует в программе опционов»
    Когда мы приглашаем людей, мы не говорим: «Вы, в том числе, можете в будущем получить сток-опшны». Потому что это все делается спустя Х времени. Нужно поработать год, два, оценить длинную дистанцию. Мы понимаем, что это человек, без которого нашего бизнеса не может быть. Это причина, почему мы должны дать ему акции.
    Сначала люди даже не очень понимали: «Что ты мне принес? Зачем мне это? Оно что, сколько-то будет стоить?». Они искренне в это не верили. Потом, когда мы росли-росли-росли, появилась более твердая юридическая составляющая, прозрачные оценки компании. Эта история начала звучать абсолютно по-другому.
    Конечно, я считаю, что сток-опшн — это самый правильный KPI, который только может быть. Потому что любой KPI или OKR может быть искажен, он не учитывает всю картину в общем. А если наоборот, ты начнешь учитывать всю картину в общем? Что важнее — прибыль? Например, если бонус от прибыли давать, тогда у нас не будет денег инвестировать в R&D. Квартальный отчет не управляет компанией. Это неправильно. Это как обезьяна, которая жала на кнопку, получала оргазм за оргазмом и умерла от голода.
    Но с опционами есть очень много нюансов. Например, они должны быть ликвидными, чтобы люди в них верили. Должны быть примеры, когда сотрудники получили опционы, продали и приехали на работу на новом «Мерседесе», условно говоря. Должна быть какая-то справедливость, общие правила: кому мы раздаем, а кому нет? Поэтому я формирую эту программу самостоятельно.
    И, собственно, в ближайшее время ряд людей получат этот инструмент. Причем большинство из них о нем не заикались. Они очень крутые чуваки и нереально перформили, не думая об опционах. У нас есть работник, который зашел как джун QA, и сегодня он участвует в этой программе.
    Мы не можем привлекать людей, которые не деливерят. Мы можем платить выше рынка, на десять процентов, на двадцать, на тридцать, на пятьдесят — даже в два раза выше рынка. Но нам нужно, чтобы все было реализовано
    Мы говорим про биржу или про масштабный выход. В нашем случае, это или компания может быть продана большому стратегу, или это выход на биржу. Базовый вариант — идти на IPO. Исходя из нашего размера, мы можем выходить на IPO хоть завтра. Исходя из нашей готовности: структура, аудированная отчетность за Х лет, соответствие каким-то механизмам — мы это планируем сделать в течение следующих Х лет.
    Причины выходить на IPO: ликвидность для инвесторов, ликвидность для сотрудников, борьба за таланты. Но быть частной компанией — отличная вещь. Поэтому, если будет возможность решить те задачи, которые я озвучил, без выхода на IPO, то, возможно, мы их будем решать. Это наша стратегия.
    Еще важный момент: когда ты продаешь людей или часы, получаешь деньги за людей и за часы. Когда продаешь готовый продукт, получаешь деньги за готовый продукт. Ты ничего нам не заплатишь, пока мы тебе не доставим новый датчик. И, соответственно, мы чувствительны к тому, что могут люди реализовать.
    Я не знаю, какой процент проектов в аутсорсе, которые доходят до релиза. Или доходят, но ими никто не пользуется. Слышал разные цифры, но подозреваю, что довольно большой. А в нашем случае все немножко не так. Соответственно, мы не можем привлекать людей, которые не деливерят. У нас просто бизнес-модель не срастается. Мы можем платить выше рынка, на десять процентов, на двадцать, на тридцать, на пятьдесят — даже в два раза выше рынка. Но нам нужно, чтобы все было реализовано.
    Мы опасаемся, что если будем применять инструменты массового набора планктона, не получим деливери. Например, если будем хантить. Несколько раз мы применили этот инструмент, когда было очень надо. То есть сказали: «Эй, сколько ты хочешь? Напиши цифру в контракте, заходи, будешь у нас работать. Нам очень нужно, мы спешим». Все люди, которых мы захантили, вышли из компании в течение полутора лет. Они не реализовали ничего. И на это есть причины.
    Отношения с человеком начинают складываться на этапе первого контакта. Если он приходит, начинает сравнивать продукты, зарплаты у нас и в другой компании, говорит: «Так, вот ваш продукт, а вот продукт другой. Вот ваша зарплата, а вот другая зарплата. Да, здесь матч. А вот здесь у них есть печенье, а у вас, например, печенья нет. (Хотя у нас есть печенье, но не такого вида). Я пойду работать в другую компанию». Мы просто говорим: «Да, это правильное решение». Мы не будем это обсуждать, смеяться ни в коем случае. Это всего лишь выбор человека.
    Почему-то принято считать, что, когда говорят про хороший продукт, вы должны автоматически забыть про зарплату
    Когда мы начинали коммуницировать эту стратегию, сначала было страшновато: а вдруг никто не захочет с нами работать? А потом заметили: есть много людей, которые хотят что-то реализовывать, потому что у них внутри большая творческая энергия. И люди устают от того, что они эту творческую энергию не раскрывают. Этот параметр важен. Почему-то принято считать, что, когда говорят про хороший продукт, вы должны автоматически забыть про зарплату. Но нет. У нас бывали и смешные ситуации.
    Недавно человек отказался от работы, потому что мы предложили чересчур много. У него был текущий уровень притязаний ниже нашего стандарта. Мы подумали: человек технически тянет, он просит меньше — так давайте дадим больше, и он быстрее к нам выйдет. А он сказал: «Какие-то вы подозрительные. И что-то с вами не так. Я к вам не пойду работать». Инженеры иногда делают странные выводы, принимают странные решения.
    HR Brand Ajax — это забавная история. Недавно с ребятами из MacPaw обсуждали, как они строят HR Brand. Нам в чем-то проще, потому что здесь много пользователей нашего продукта. И к нам часто приходят ребята: кто-то на консалтинг, а потом, например, вливается в команду, а кто-то в штат. «Мне нравится. Я ваш пользователь. Хочу быть причастным».
    И это лучшая для нас мотивация. У нас есть завод, где объективно работать не очень прикольно. Но там постоянно растет зарплата, стабильно платят деньги. Но в интернете о нем много плохих отзывов. Например, на заводе у нас дисциплина: если ты опаздываешь, тебя штрафуют.
    
    «Мы не делаем фирменные магазины Ajax. Потому что понимаем, что еще многому должны научиться»
    Сейчас у нас 500 000 пользователей в приложении. Думаю, в течение двух лет будет миллион. Мы есть в миллионе домов, в самом богатом регионе мира — Европейском Союзе. И это сама по себе ценность. Почему мы выигрываем в Европейском Союзе, например, у тех же американских компаний? Американские компании довольно интересно расширяются. Они, грубо говоря, не видят европейский рынок и те деньги, которые для нас — мегабольшие.
    Мы — компания мечты для Украины, но для Америки это какой-то усредненный результат. Например, B2C увеличивается быстро. В2В не так быстро. Дальше, если идти в В2В, вес технологий становится выше, чем вес маркетинга. В2С — это клевая реклама. В В2В мире люди выбирают, они смотрят, сравнивают. Меньше — сейлз кост, больше — ценность технологии.
    И это то, что мы генетически, как украинцы, делаем круто. Мы говорим о том, что не достигнем того уровня маркетинга, который делают американцы. Они очень круто это делают. Но при этом технологически мы не будем слабее. Искренне верю, что в Украине на сегодняшний день можно разработать практически все что угодно — имея бюджет, имея терпение. Здесь огромное количество инженеров, и не только айтишных. Поэтому мы сознательно, например, не идем в В2С — не продаем потребителю, не выходим на американский рынок.
    Мы смотрим на API как на продукт для узкой аудитории. На него все больше запросов. Мы выкатили «корпоративный API». Он таргетирован на большие В2В-контракты. Для того чтобы сделать технологию для 10 людей и для 10 000 людей, требуется очень разная стоимость R&D.
    Когда делаешь технологию для десяти людей, с каждым лично познакомишься, подпишешь с ним юридические документы на большой контракт, можешь включить Х часов поддержки. Потом эту платформу еще обслуживаешь. Должен, грубо говоря, запрашивать за нее деньги и автоматически ее предоставлять. И там просто получается бэклог, на который ты смотришь. А в этом бэклоге, помимо, собственно, юзер-стори про апишку, еще миллиард всяких вещей, например, EN 54. И поэтому, выбирая, делать пожарку или делать API, мы выбираем делать пожарку.
    Мы не делаем фирменные магазины Ajax. Потому что понимаем, что еще многому должны научиться. При этом мы постоянно взвинчиваем уровень технологии, чтобы конкурировать на рынке. В Google у тебя лучшие кадры — они шпилят в их флагманские бизнесы. А интернет вещей — это какой-то десятый бизнес. Но ты не конкурируешь с Google.
    Я конкурирую не с Ларри Пейджем, а с лидером того подразделения, который делает охранные системы. Не с United Technologies или Hikvision, а с конкретным человеком, который сегодня занимает должность в корпорации, рубится с тобой. И это хорошая новость. Потому что у тебя, как у предпринимателя, намного больше свободы, творчества, чем у него.
    Недавно самая быстро растущая охранная компания в Ирландии United Technologies (миллиарды долларов маркет кап) перешла на Ajax. У нас было много разных побед, мы во многих сферах развиваемся. Но вот именно на этом кейсе я реально кайфанул. United Technologies прилетели в Киев, мы с ними много разговаривали. Они с большим уважением к нам относились, очень хвалили наш продукт. Завязался хороший диалог.
    И я считаю, что этот момент — это то, ради чего я хожу на работу. Чтобы клиентами были Samsung, Google, Huawei и так далее, но украинский продукт. Это лучшее продвижение бренда «Украина». Это лучшее, чем я могу замотивировать людей. Вы сделали что-то такое, благодаря чему всемирно известного лидера свапнули на украинскую компанию.
    Этот текст краткая (или не очень) выжимка моего почти двухчасового разговора с Александром, который мы записали и смонтировали благодаря Компьютерной школе Hillel. Слушайте и смотрите полную версию ниже:
    Благодарим Ярославу Тимощук за помощь в подготовке статьи.
    
    
    
    Похожие публикации:
    
    Где купить радиоуправляемый уаз 469
    Как в movavi добавить текст
    Как очистить историю в mozilla
    Что такое коллизия java