Мы MM.SUP – команда сопровождения аналитического CRM компании Glowbyte – хотим рассказать о том, как не усложнять все и прийти к простым и правильным решениям в сфере построения процессов сопровождения. Рассказ основан на собственном опыте нормализации процессов управления дефектами промышленной среды ведущего банка топ-5 России.
Сейчас трудно в это поверить, но полтора столетия назад самым быстрым транспортом были поезда – их скорость в 60-100 км/ч казалась умопомрачительной. Но на заре XX века автомобили и самолёты прогрессировали, как сейчас компьютеры, и железнодорожный транспорт почти без боя отдал им рекордные достижения. Последним очагом сопротивления был скоростной полигон Цоссен – Мариенфельде в Германии.
Привет! Меня зовут Роман Ленц, в Первой грузовой компании (ПГК) я занимаюсь анализом данных и машинным обучением в рамках проекта «Цифровой вагон», подробнее о котором рассказано здесь. Еще 3 года назад я работал инженером-конструктором в зарубежной строительной компании. Почему я решил кардинально поменять свою карьерную траекторию, почему выбрал именно Data Science, и как я к этому пришёл? Поделюсь опытом, который, возможно, окажется полезным для молодых специалистов, ищущих «работу мечты». Тем, кто задумался о смене профессии, думаю, информация тоже будет полезна.
Я получил высшее образование за границей. После окончания вуза устроился на работу в московское представительство иностранной строительной компании. Мы занимались проектированием объектов по всему миру, но на российском рынке количество заказов постепенно снижалось: стоимость услуг была слишком высокой для местных клиентов. Стало очевидно, что скоро придется искать другую работу. Именно тогда я задумался о том, чтобы сменить карьерную траекторию.
Не скажу, что выбрал Data Science совсем случайно. Как у инженера у меня был сильный математический бэкграунд, я был знаком с основами некоторых языков программирования, разбирался в работе с данными. Меня привлекали области, где можно применить эти навыки и знания, поэтому направление Data Science показалось мне интересным вариантом для более глубокого погружения.
Определившись, я стал постепенно вспоминать основы математики, линейной алгебры, статистики, теории вероятности. Параллельно начал проходить профильные курсы на крупных онлайн-платформах – DataCamp, Stepik, Яндекс.Практикум и других.
Состоялась конференция разработчиков Apple, вручены награды Apple Design Awards, выпущены технические новинки и стартовал бета-тест новых систем. А ещё слухи, инсайды и другие подробности о грядущих продуктах компании Apple. Всё это в свежем дайджесте от Apple Pro Weekly News.
Привет, Хабр! Я Ани, отвечаю в Ozon Tech за обучение.
Сегодня поводом для поста на столь многоуважаемую аудиторию стал разбор задач контеста, который прошёл в рамках отбора участников на курсы Route 256.
Контест нам заменяет скрининг — мы проверяем технические навыки и опыт работы будущих участников, так как курсы рассчитаны на мидлов.
Ранее мы публиковали разбор задач по направлениям Go и QA (раз, два), пришло время поделиться задачами для C#, iOS (Swift) и Android (Kotlin, Java).
В этот раз нам посчастливилось провести контест совместно с Codeforces, и, судя по фидбеку участников, задачи зашли на ура. Надеюсь, разбор будет полезен и вам. А если захотите попробовать свои силы и попасть на курс, ищите ссылку на регистрацию ниже.
Что спрашивают на собеседовании Golang разработчика? Асинхронщина? Контексты? Вторая часть статьи с вопросами и ответами, собранными на собеседованиях.
Термин «выгорание» вошёл в мою жизнь как-то неожиданно. Работал я. Работал много лет: сначала кодил, потом свои проекты делал, команды собирал, бизнес налаживал… И тут — Бац! Куча мемов на эту тему во всех связанных с IT-ресурсах. Не знаю, то ли я в какой-то тундре жил, то ли тундра жила во мне. Но да ладно: мемы почитал, поржал и забыл. А тут неожиданно этот термин вошёл в обиход моих ребят. Где-то как бы в шутку, где-то в серьёз. А мы все знаем: в каждой шутке есть доля шутки, а остальное — чистая правда.
Это начало влиять на рабочий процесс. Простые задачи стали требовать больше ресурсов, некоторые затягиваться на ровном месте. Люди начали чувствовать себя дискомфортно. При этом я заметил, что чем моложе команды (в плане рабочего стажа), тем больше тема выгорания поднималась и тем активнее в них стали развиваться проблемы.
Признаюсь, поначалу я закипел. Для меня было очевидно, что проблемы элементарны. Время и ресурс, которые уходят на разговоры про выгорание, можно было потратить на их решение, и проблем бы просто не было. Для меня это выглядело так: люди сами себе создали проблемы, а теперь говорят, что им дискомфортно. Накатил типичный сеньорский снобизм:
«Вот я в своё время по 10 часов работал без выходных и отпусков. Скучные проекты пилил, ночью на проде хотфиксил и т.д. и т.п. У ребят же условия другие: график нормированный (авралы, конечно, бывают, но всё в рамках), переработки оплачиваются х1,5-х2 (всё по ТК), проекты интересные. Премии! Отпуска! Работа, блин, командная! Не как дурак сидишь и всё в одного пилишь, а в коллективе ответственных товарищей. Какое, мол, выгорание? Я вам сейчас расскажу про выгорание!» Ну и прочая блаж в том же духе.
Последние два с половиной года показали, насколько важно уметь противостоять стрессу на длинной дистанции. Если в офисе есть коллеги и, в конце концов, пятничный бар, где можно слить накопившийся негатив, на удаленке приходится изыскивать собственные способы профилактики. И чем выше напряженность в обществе, тем более виртуозным должно быть умение не поддаваться унынию.
Эту подборку рекомендаций мы собрали по итогам внутреннего собрания, посвященного стрессу, где все желающие могли поделиться своими паттернами. Возможно, вы бы хотели что-то к ней добавить? В таком случае добро пожаловать в комментарии!
Поводом для написания этой статьи послужил случай, когда сотрудники нашего HR-отдела предложили мне взять в нашу проектную группу Департамента разработки программного обеспечения ЛАНИТ на производственную практику выпускника одного из московских техникумов. Кандидат обучался четвертый год по специальности «Прикладная информатика» и, судя по резюме, претендовал на должность «стажера-разработчика SQL, С#, HTML, CSS». Он уже прошел предварительные собеседования и, по словам наших кадровиков, показал себя наиболее адекватным из 15 других претендентов. Поскольку у меня это был не первый случай руководства практикой у студентов и предыдущие прецеденты имели положительный результат, я согласился.
Давно хотелось написать про корпоративных программистов, по своему опыту, какие они бывают, какой у них стиль работы. Речь идет о разработке в плане сопровождения или переработки больших систем.
Первый тип - быстрые программисты. С такими сталкиваешься редко. Это эрудированные и увлеченные люди, обычно занимающие высокое положение в иерархии разработчиков (тим лиды или что-то около). Основная особенность - высокая скорость написания кода и способность быстро осваивать новые технологии. Думаю, для корпоративной среды это ценные сотрудники, поскольку, чаще всего скорость в цене. Качество кода у таких программистов не всегда высокое, чаще наоборот. Иногда код сложный. Один раз я просматривал код за одним из таких специалистов и он меня поразил одной особенностью. Это был код высококлассного спеца, но выглядел он как набросок - широкими мазками была сформирована структура, но вот детали были иногда просто не реализованы. Обычно код таких программистов приходится допиливать, но главное преимущество, что код очень быстро появляется и сразу в больших объемах. Работая с таким кодом, чаще всего находишься в растерянности от широты мысли и идей автора.
Второй тип - педанты. Код этих программистов пишется со средней скоростью, обычно он качественный в плане надежности и отсутствия ошибок, но часто бывает перегружен количеством рассмотренных кейсов, проверок и т.д. Код сложный, со сложными для понимания структурами и алгоритмами, от него нет чувства полетности, код тяжелый и очень трудно воспринимается при чтении. Один раз я сталкивался с таким кодом, где практиковались очень длинные строки - по несколько сот символов, вызовы методов с большим количеством параметров, каждый из которых сам был вызовом других методов или конструкторов. Править такой код чрезвычайно сложно, очень тяжело понимать для чего сделаны те или иные вещи.
Новая неделя – новая статья. Сегодня про социалку, а в первую очередь про воспитание детей и пенсию в передовых айтишных странах как о двух основных критериях социальной защищённости. Сравнивать будем США, Канаду, Германию, Нидерланды, Швейцарию, Великобританию, Кипр, Польшу, Израиль и Австралию. А опираться предлагаю не на логику и умозаключения, а на индексы с проверенной статистикой и цифрами.
В прошлом материале мы считали, сколько лет жизни среднестатистического программиста уйдет на накопление на квартиру в 100м2. В некоторых популярных среди айтишников странах этим самым айтишников не хватит одной жизни, чтобы выплатить ипотеку. Но каким-то образом в этих странах пенсия у стариков оказалась в топе по счастью. Как это вышло? Давайте смотреть.
Социальное развитие
Для того, чтобы ответить на вопрос, насколько государства поддерживают граждан в тех или иных сферах жизни, я нашла отличный индекс Social Progress Index, который учитывает как базовые человеческие потребности (питание, медицинское обслуживание, доступность жилья, личную безопасность, доступ к образованию), так и возможности права и свободы. Изучить можно его отдельно по каждой категории на официальном сайте индекса.
Какие у вас ассоциации с Узбекистаном? Кто-то вспомнит узбекскую кухню с пловом, мантами и лепешкой. Любители путешествий представят себе древние города и здания с причудливыми узорами. И конечно, вспоминаются работящие парни из Средней Азии. Но времена меняются, миграционные потоки тоже. Sad but true. И уже парни с бледными лицами в обнимку с лэптопами уезжают в солнечный Узбекистан.
Я преподаю английский десять лет, но скажу честно: если вы разработчик, тестировщик, дизайнер – это значит, что вы сможете выучить английский сами. Конечно, нужны партнёры для общения, но ими могут быть ваши зарубежные клиенты или коллеги, интернет-знакомые, однокомандники в онлайн-играх. Но главное – получить необходимую базу – вы сможете самостоятельно, сидя дома за компьютером. И вот почему.
Возможно, вы уже ищете работу за рубежом, готовы релоцироваться или рассматриваете такую возможность в будущем. В этой статье я поделюсь своим мнением как подходить к выбору страны для релокации, к выбору компании, к выбору позиции или роли. Я также затрону вопросы о поиске работы за границей, что важно сделать до непосредственной релокации, а также на чем важно сфокусироваться сразу после релокации. Помимо России я жил в двух разных странах — в Финляндии и в США. Поэтому немного поделюсь своим опытом.
Хоть раз в жизни каждый из нас задумывался о том, как прошлый опыт, ошибки и достижения привели его в ту точку, в которой он находится в данный момент. Человеку свойственно рефлексировать, анализируя все плюсы и минусы собственных жизненных решений.
Для команды разработки такой процесс также не чужд. Мы называем его ретроспективой. Чтобы оптимизировать в будущем работу, необходимо регулярно проводить это безусловно важное мероприятие в agile методологии. Давайте детально разберём преимущества ретро и научимся правильно проводить такие встречи.
Здравствуйте, меня зовут Екатерина, уже 11 лет я работаю учителем в школе. Год назад я решила сменить профессию и пошла на курсы тестировщиков в одну разрекламированную онлайн школу, разочаровалась в ней, а теперь учусь в другой. Мне стало интересно сравнить методики преподавания, чтобы понять, что-то не так со мной или с курсом? Предыдущую часть можно посмотреть здесь.
Добрый день!
Мы создали бесплатный инструмент который позволяет анализировать Персоны (индивидов/целевую аудиторию) на основе паттернов человеческого мышления (когнитивных искажений). Вы можете использовать этот инструмент в своей компании для увеличения эффективности работы команд маркетинга, продаж, продакт и др. Инструмент может быть также использован для самоанализа и повышения эффективности принимаемых вами решений.
Привет!
Я уже 10 лет в индустрии, успел поработать в разных компаниях — продуктовых и аутсорсинговых, больших и маленьких. Последние три года я ещё и менеджер — управляю командой разработчиков, помогаю им развиваться и нанимаю новых людей.
Я обратил внимание на то, что разработчики часто считают своей работой «написание кода», «добавление фич» или даже «закрытие задач в джире». Раньше я думал так же. Сегодня я расскажу, почему считаю этот подход ограничивающим рост и, что более важно, счастье.