Вопрос был про обязательство устроиться на работу — такого обязательства нет.
Чтобы было точнее и понятнее, по сути, мы проводим мастер-классы, которые внутри называем «стажировки». Мы показываем собственный код, рассказываем про реальные задачи и проекты, стажёры знакомятся с жизнью компании. Чтобы закрепить знания, ребята делают домашние задания, но их код не уходит в прод, мы не используем его в нашей работе. Задания проверяют ведущие стажировок и дают обратную связь. После окончания стажировки не выдается бумаг образовательного характера.
Трудозатраты с нашей стороны, безусловно, всё равно есть, поэтому что касается нашей заинтересованности, то:
1) Какая-то часть стажёров становится сотрудниками сразу после стажировки — это такая win-win история. Ещё часть прошедших стажировку разработчиков могут прийти к нам в течение нескольких лет, наработав подходящий опыт.
2) К тому же, нам интересно готовить хорошие кадры для рынка — через один-два-три года мы можем пересечься с нашими бывшими стажёрами на проектах или они могут вернуться к нам в качестве сотрудников. В целом, это влияет на узнаваемость и силу бренда, позитивно сказывается на рынке.
3) Стажировка полезна для прокачки собственных сотрудников и технологизации знаний. Ребята преподают, вырабатывают объективные критерии для оценки других.
Поэтому, наш опыт говорит, что затраты на стажировки могут в целом окупаться. При этом, конечно, сложно высказаться за формат в целом, так как у других компаний могут быть другие цели и параметры для проекта «стажировка».
Наша стажировка не предполагает обязательства устроиться к нам на работу или гарантии оффера после успешного прохождения. Но если в момент окончания стажировки будет вакансия, то мы с радостью пригласим в команду хорошо проявивших себя ребят.
Постановление Пленума Верховного Суда РФ от 23.06.2015 № 25 (п.65) — о направлении юридически значимых сообщений в электронной форме.
Постановление Пленума Верховного Суда РФ от 23.04.2019 №10 (п.55) — скриншот страниц в интернете как допустимое доказательство в суде (желательно заверенное нотариусом, если другая сторона оспаривает факт наличия переписки).
Если нет возможности заверить — суд может исследовать переписку непосредственно на заседании (Дело № А19-2500/2017).
Знаменитое дело о приобщении к делу скриншотов страниц в Инстаграм — дело № А40-245007/16-30-403
Подтверждение выполнения работ в Whatsapp — Постановление Девятого ААС от 26.10.2018 по делу № А40-118425/18
Признание переписки в мессенджере допустимым доказательством — Решение Арбитражного суда г.Москвы от 3 февраля 2020 г. по делу N А40-320/2019
Признание переписки в Whatsapp — Постановление девятого арбитражного апелляционного суда от 31 октября 2016 г. № 09АП-49415/2016
Признание заключения договора путем переписки в ICQ — Арбитражный суд Волго-Вятского округа (постановление от 22.05.2015 по делу № А79-1814/2014)
Признание заключения договора путем переписки в WhatsApp — Апелляционное определение СК по гражданским делам Суда Ненецкого автономного округа от 18 декабря 2019 г. по делу N 33-155/2019;
Апелляционное определение СК по гражданским делам Свердловского областного суда от 07 августа 2019 г. по делу N 33-12919/2019
Не факт, что эксперт во время осмотра будет отмечать части двигателя, подлежащие ремонту, но ПО предоставляет возможность рассчитать в том числе стоимость ремонта двигателя и отдельных его составляющих.
Привет! Silverdat как раз предоставляет взрыв-схемы авто по VIN. Т.е. то, что мы показываем эксперту, является точной взрыв-схемой именно этого авто, учитывая комплектацию, кузов и пр. Также мы даем эксперту возможность внести некоторые детали самому, если клиент заменил, к примеру, штампованные диски из комплектации на литые или установил парктроники и пр.
И еще: страховая всегда рассчитывает сумму ущерба по каталогам производителя и ориентируется в первую очередь на них. Если по каталогу положена замена детали (без возможности ремонта), значит так и будет. Silverdat дает возможность это отследить.
То же самое с ценами. Все цены берутся из рекомендованных каталогов.
Про техподдержку мы указали в самом начале, чтобы не вводить в заблуждение — прямо в заголовке. В вводной пишем, что это конкретный опыт, которым мы решили поделиться, потому что посчитали полезным.
Про «понравится», имеется ввиду именно же правильный, верный и корректный ответ, в таком случае он может понравиться :)
Но, спасибо, что обратили внимание, будем внимательнее.
Спасибо за комментарий) Это здорово, что Android-разработчики могут сохранять соседние страницы. Как правило, это очень нужно для комфортного пользования приложением.
Если простыми словами, то дизайнер, чтобы сделать дизайн, выполняет такие действия:
1. Открывает Фигму
2. Создаёт экран телефона 360 на 640 физических пикселей (в Фигме — это называется «Frame»)
3. Внутри этого экрана с помощью простых фигур, текста и стилей создаёт компоненты дизайна: бары, поля ввода, кнопки, переключатели
4. Как правило, дизайнер рисует несколько экранов, которые следуют друг за другом в логической последовательности (сценарии)
5. И также отрисовывает экраны с ошибками
Физически мы получаем экран телефона, в котором расставлены компоненты на определенных расстояниях друг от друга. Дизайнер словами и текстом дополняет экраны разъяснениями, как должны работать некоторые из компонентов. Например, как должен вести себя длинный текст, если он не помещается в заданную область.
С чего разработчику начать изучение дизайна?
Начать нужно с понимания, зачем нужен дизайн.
Дизайн нужен для двух вещей:
1. Сделать приложение удобнее
2. Сделать приложение красивее (и брендированное)
Чтобы выполнить первый пункт, нужно смотреть на приложение глазами пользователя. Собирать с них отзывы и дорабатывать приложение.
Чтобы выполнить второй, лучше позвать в команду дизайнера. Для создания красоты нужны знания и опыт.
Но если хочется попробовать дизайн самому, стоит освоить Фигму и посмотреть пару туториалов по основам веб-дизайна.
Раскрыть подноготную проекта, к сожалению, не можем (он под NDA), но описания видов работ должно быть достаточно для того, чтобы вникнуть в суть этого инструмента.
Каждый проект в своем роде уникален. У него свои ограничения и возможности, которые позволяют сконфигурировать работу таким образом, чтобы это приносило качественные результаты. Мы лишь поделились нашим опытом и инструментом, который позволил гармонично и эффективно выстроить работу в условиях большой команды и различных видов работ.
Стоит воспринимать спринт-пульс как дополнительный инструмент в работе, который позволяет собрать все бенчмарки и зависимости между членами команды, чтобы увидеть картину целиком и двигаться дальше для минимизации рисков и потенциальных простоев.
Привет! Записи будут всегда доступны для практикантов на специальном лендинге, но на занятиях нужно присутствовать, верно.
Не хотели мучать, но рука дрогнула при загрузке. Поправили.
Чтобы было точнее и понятнее, по сути, мы проводим мастер-классы, которые внутри называем «стажировки». Мы показываем собственный код, рассказываем про реальные задачи и проекты, стажёры знакомятся с жизнью компании. Чтобы закрепить знания, ребята делают домашние задания, но их код не уходит в прод, мы не используем его в нашей работе. Задания проверяют ведущие стажировок и дают обратную связь. После окончания стажировки не выдается бумаг образовательного характера.
Трудозатраты с нашей стороны, безусловно, всё равно есть, поэтому что касается нашей заинтересованности, то:
1) Какая-то часть стажёров становится сотрудниками сразу после стажировки — это такая win-win история. Ещё часть прошедших стажировку разработчиков могут прийти к нам в течение нескольких лет, наработав подходящий опыт.
2) К тому же, нам интересно готовить хорошие кадры для рынка — через один-два-три года мы можем пересечься с нашими бывшими стажёрами на проектах или они могут вернуться к нам в качестве сотрудников. В целом, это влияет на узнаваемость и силу бренда, позитивно сказывается на рынке.
3) Стажировка полезна для прокачки собственных сотрудников и технологизации знаний. Ребята преподают, вырабатывают объективные критерии для оценки других.
Поэтому, наш опыт говорит, что затраты на стажировки могут в целом окупаться. При этом, конечно, сложно высказаться за формат в целом, так как у других компаний могут быть другие цели и параметры для проекта «стажировка».
Постановление Пленума Верховного Суда РФ от 23.06.2015 № 25 (п.65) — о направлении юридически значимых сообщений в электронной форме.
Постановление Пленума Верховного Суда РФ от 23.04.2019 №10 (п.55) — скриншот страниц в интернете как допустимое доказательство в суде (желательно заверенное нотариусом, если другая сторона оспаривает факт наличия переписки).
Если нет возможности заверить — суд может исследовать переписку непосредственно на заседании (Дело № А19-2500/2017).
Знаменитое дело о приобщении к делу скриншотов страниц в Инстаграм — дело № А40-245007/16-30-403
Подтверждение выполнения работ в Whatsapp — Постановление Девятого ААС от 26.10.2018 по делу № А40-118425/18
Признание переписки в мессенджере допустимым доказательством — Решение Арбитражного суда г.Москвы от 3 февраля 2020 г. по делу N А40-320/2019
Признание переписки в Whatsapp — Постановление девятого арбитражного апелляционного суда от 31 октября 2016 г. № 09АП-49415/2016
Признание заключения договора путем переписки в ICQ — Арбитражный суд Волго-Вятского округа (постановление от 22.05.2015 по делу № А79-1814/2014)
Признание заключения договора путем переписки в WhatsApp — Апелляционное определение СК по гражданским делам Суда Ненецкого автономного округа от 18 декабря 2019 г. по делу N 33-155/2019;
Апелляционное определение СК по гражданским делам Свердловского областного суда от 07 августа 2019 г. по делу N 33-12919/2019
И еще: страховая всегда рассчитывает сумму ущерба по каталогам производителя и ориентируется в первую очередь на них. Если по каталогу положена замена детали (без возможности ремонта), значит так и будет. Silverdat дает возможность это отследить.
То же самое с ценами. Все цены берутся из рекомендованных каталогов.
Про «понравится», имеется ввиду именно же правильный, верный и корректный ответ, в таком случае он может понравиться :)
Но, спасибо, что обратили внимание, будем внимательнее.
Если простыми словами, то дизайнер, чтобы сделать дизайн, выполняет такие действия:
1. Открывает Фигму
2. Создаёт экран телефона 360 на 640 физических пикселей (в Фигме — это называется «Frame»)
3. Внутри этого экрана с помощью простых фигур, текста и стилей создаёт компоненты дизайна: бары, поля ввода, кнопки, переключатели
4. Как правило, дизайнер рисует несколько экранов, которые следуют друг за другом в логической последовательности (сценарии)
5. И также отрисовывает экраны с ошибками
Физически мы получаем экран телефона, в котором расставлены компоненты на определенных расстояниях друг от друга. Дизайнер словами и текстом дополняет экраны разъяснениями, как должны работать некоторые из компонентов. Например, как должен вести себя длинный текст, если он не помещается в заданную область.
С чего разработчику начать изучение дизайна?
Начать нужно с понимания, зачем нужен дизайн.
Дизайн нужен для двух вещей:
1. Сделать приложение удобнее
2. Сделать приложение красивее (и брендированное)
Чтобы выполнить первый пункт, нужно смотреть на приложение глазами пользователя. Собирать с них отзывы и дорабатывать приложение.
Чтобы выполнить второй, лучше позвать в команду дизайнера. Для создания красоты нужны знания и опыт.
Но если хочется попробовать дизайн самому, стоит освоить Фигму и посмотреть пару туториалов по основам веб-дизайна.
Каждый проект в своем роде уникален. У него свои ограничения и возможности, которые позволяют сконфигурировать работу таким образом, чтобы это приносило качественные результаты. Мы лишь поделились нашим опытом и инструментом, который позволил гармонично и эффективно выстроить работу в условиях большой команды и различных видов работ.
Стоит воспринимать спринт-пульс как дополнительный инструмент в работе, который позволяет собрать все бенчмарки и зависимости между членами команды, чтобы увидеть картину целиком и двигаться дальше для минимизации рисков и потенциальных простоев.