Вот вот, когда весь день заняли встречи например с 11-18:00 и ты просто не понимаешь а как бы поесть, на помощь приходит семья. Принесут тарелку еды к компу, и благодаря выключенной камере,пока всё собираются на встречу 3-5 минут можно успеть пообедать.
Сильная разница в возрасте внутри одной команды может приводить к конфликтам, но всё опят же зависит от людей. Поэтому да, можно в 35+ команду взять 18+, но это не всегда хорошо.
Потенциал - это не курсы, тут больше если человек пошёл на курс, то как минимум он учиться хочет.
У моих знакомых были примеры, когда меняли сферу на ИТ именно 35+, в силу обстоятельств, искали интересную работу, а раньше никто не подсказал, график работы и тд, то есть менять профессию можно вне зависимости от возраста.
Команды разработки справляются с оценками по такой схеме, закладывают ресурсы на аналитику, разработку, тестирование.
Железо и сопровождение также возможно верхнеуровнево заложить бюджет по планируемой нагрузке объём хранимых данных и тд.
То есть к такой диаграмме ещё как правило идёт описание с ключевыми моментами решения - нагрузка, количество пользователей и тд, то что как раз помогает оценить.
Подскажите, а в вашей практике какие схемы использовались, что получить оценку от команд?
Да, показано верхнеуровневое взаимодействие Actor -> Система, чтобы упростить схему, так как Оператор КЦ может взаимодействовать и с другими модулями системы, но можно показать и с конкретном модулем. Аналогично и Администратор
Да, по процессу заказчик приходит к архитектору для проработки верхнеуровневой архитектуре (vision), далее этот документ по процессу согласуется с заинтересованными командами и уже поступает в детальную проработку системному аналитику. В этой статье есть подробнее про "Непрерывный цикл производства" https://habr.com/ru/companies/alfa/articles/768160/
Администратор взаимодействует с модулем "Модуль метрики бизнес-события" в самой системе "Единое окно КЦ", который показывает метрики по работе пользователей в системе. На данной схеме он не отражен с целью упрощения схемы.
Также Администратор взаимодействует с системой метрики, эту стрелочку дополню на схемы в статьей. Спасибо за комментарий!
Конечно, у команды разработки возникают вопросы к большей детализации задачи, но тут я стараюсь все-таки разделись этап оценки и планирования и системный анализ по решению.
Например, некоторым командам не достаточно 1 уровня C4 модели, поэтому делаю 2 уровень, так как для их системы это влияет на на оценку. Также практически все команды для оценки просят протоколы для взаимодействия систем, потому что это влияет на сложность разработки.
Получается я стараюсь искать баланс в схеме и достаточное отображение, чтобы команды оценили доработку и запланировали. Без такой схемы планирование, бюджет, оценка не получается у команда (пробовали по документу бизнес требований делать оценки, не вышло)
Иногда, заказчик может прийти с требованием хочу показать людям сколько идти до ближайшено отделения почты, нужно эти данные забрать из Яндекс api. Начиная выяснять а зачем ему такая интеграция, можно прийти к тому, что дешевле с точки зрения разработки показать на карте ближайшие метро и это покроет потребность бизнеса, чем показывать время до метро
Интересный макросы: свойства страницы и отчёт по свойствам страницы. Если таблицу обернуть в свойства страницы, то потом можно автоматизировать сбор различных список и поиск внутри по множеству страниц
Я считаю, что middle - это 3+ лет, а senior 5+, значит всё что до, это как правило junior. Почему так? За это время как правило у аналитика появляются различные задачи и он уже может и сверху посмотреть на задачу и провести сравнительный анализ технологий на минимальном уровне.
Про требования. Вы пишите, что хотели бы слышать на собеседовании, а это косвенно требования, потому что ответы показывают уровень знаний кандидата.
Рада, что вам попались кандидаты, как вы искали. Я считаю, что у молодёжи сейчас есть другие плюсы, кроме как знать определения. Я встречала не молодежь, которая не знает определений и работает уже на уровне главных специалистов, но они прекрасно выполняют задачи и являются хорошими боевыми единицами.
Я вам завидую, что находите время читать именно книги, это здорово!
👍 спасибо за статью, здорово, что тема актуально и затронула много читателей.
Читая вашу статью, я вижу требования к senior и начальный уровень архитектора, я в профессии более 8 лет и успела увидеть несколько компаний и проектов, начинала как раз с junior позиции.
Определения - это хорошо, но аналитик это не википедия, которая сыпет в разработчика определениями. Главное для junior (моё мнение) - это умение думать здраво, слышать и горящие глаза с желанием научиться. А если человек ещё и позитивные, это прям повезло.
Конечно, он должен иметь знания по hards скилам, но без того, что написала выше, работать вряд ли сможет.
Ещё момент про книжки, где вы берете время, чтобы их читать? На работе ставят задачи и у них нет времент, чтобы вы читали книги, им нужны решения, поэтому я благодарна habr, интенсив курсам, митапам и конференциям, где люди делятся знаниями в сжатом виде, потому что мозг аналитика в режиме многозадачности книг и определений просто не поместит.
Тут не компания судя по статье, а внутреняя договорённость у команды
К "идеальному удаленщику" не хватает:
Наличие замка на двери в импровизированном кабинете, чтобы дети, кошки, собаки и другие члены семьи не отвлекали
Чувство времени, то есть человек не опаздывал бы на встречи
Вот вот, когда весь день заняли встречи например с 11-18:00 и ты просто не понимаешь а как бы поесть, на помощь приходит семья. Принесут тарелку еды к компу, и благодаря выключенной камере,пока всё собираются на встречу 3-5 минут можно успеть пообедать.
😁 конечно можно, но с повышением своих скиллов же веселее.
Сильная разница в возрасте внутри одной команды может приводить к конфликтам, но всё опят же зависит от людей. Поэтому да, можно в 35+ команду взять 18+, но это не всегда хорошо.
Потенциал - это не курсы, тут больше если человек пошёл на курс, то как минимум он учиться хочет.
У моих знакомых были примеры, когда меняли сферу на ИТ именно 35+, в силу обстоятельств, искали интересную работу, а раньше никто не подсказал, график работы и тд, то есть менять профессию можно вне зависимости от возраста.
Бывают разные ситуации, но их не большинство. Например, команда 35+, зачем им 18+ .
Также если есть потенциал, то можно очень хорошо прокачать под компанию специалиста, главное понимать на входе под какие задачи
Чтобы попасть в ит, нужно
Лёгкие Курсы + мотивация = пройти собес и начать работать. 🙂
Испыталка + мотивация = самообучение по списку тем для работы. Помощь Меньера и впитывание знаний как Губка
После испыталки + мотивация = составить себе план развития на год, чтобы добиться повышение = другие курсы🙃
Через год + главное не выгореть = понять нравится ли профессия и найти курсы для роста или переквалификации
Команды разработки справляются с оценками по такой схеме, закладывают ресурсы на аналитику, разработку, тестирование.
Железо и сопровождение также возможно верхнеуровнево заложить бюджет по планируемой нагрузке объём хранимых данных и тд.
То есть к такой диаграмме ещё как правило идёт описание с ключевыми моментами решения - нагрузка, количество пользователей и тд, то что как раз помогает оценить.
Подскажите, а в вашей практике какие схемы использовались, что получить оценку от команд?
Да, показано верхнеуровневое взаимодействие Actor -> Система, чтобы упростить схему, так как Оператор КЦ может взаимодействовать и с другими модулями системы, но можно показать и с конкретном модулем. Аналогично и Администратор
Да, по процессу заказчик приходит к архитектору для проработки верхнеуровневой архитектуре (vision), далее этот документ по процессу согласуется с заинтересованными командами и уже поступает в детальную проработку системному аналитику. В этой статье есть подробнее про "Непрерывный цикл производства" https://habr.com/ru/companies/alfa/articles/768160/
Администратор взаимодействует с модулем "Модуль метрики бизнес-события" в самой системе "Единое окно КЦ", который показывает метрики по работе пользователей в системе. На данной схеме он не отражен с целью упрощения схемы.
Также Администратор взаимодействует с системой метрики, эту стрелочку дополню на схемы в статьей. Спасибо за комментарий!
Конечно, у команды разработки возникают вопросы к большей детализации задачи, но тут я стараюсь все-таки разделись этап оценки и планирования и системный анализ по решению.
Например, некоторым командам не достаточно 1 уровня C4 модели, поэтому делаю 2 уровень, так как для их системы это влияет на на оценку.
Также практически все команды для оценки просят протоколы для взаимодействия систем, потому что это влияет на сложность разработки.
Получается я стараюсь искать баланс в схеме и достаточное отображение, чтобы команды оценили доработку и запланировали. Без такой схемы планирование, бюджет, оценка не получается у команда (пробовали по документу бизнес требований делать оценки, не вышло)
Иногда, заказчик может прийти с требованием хочу показать людям сколько идти до ближайшено отделения почты, нужно эти данные забрать из Яндекс api. Начиная выяснять а зачем ему такая интеграция, можно прийти к тому, что дешевле с точки зрения разработки показать на карте ближайшие метро и это покроет потребность бизнеса, чем показывать время до метро
Когда пишите статью:
1) определите пользу. Поставьте себя на место читателя. Зачем ему тратить время на чтение.
2) упростите подачу материала. Помните, вы не диссертацию пишите.
3) проверьте орфографии и пунктуацию. Статья - это ваше лицо. Не приятно видить в ней ошибки
4) изучите похожие статьи, комментарии к ним, чтобы избежать ошибок.
5) пишите в удовольствие. Найдите то, что вас вдохновляет и интересно, тогда статья получится живой
0,33 балла уступила победителю в номинации Карьера и образование в ИТ.
А за второе место ничего не дадут? 😁
Откуда такое название? Почему?
Спасибо за структурированную статью об не системной теме как soft skills
Интересный макросы: свойства страницы и отчёт по свойствам страницы. Если таблицу обернуть в свойства страницы, то потом можно автоматизировать сбор различных список и поиск внутри по множеству страниц
Я считаю, что middle - это 3+ лет, а senior 5+, значит всё что до, это как правило junior. Почему так? За это время как правило у аналитика появляются различные задачи и он уже может и сверху посмотреть на задачу и провести сравнительный анализ технологий на минимальном уровне.
Про требования. Вы пишите, что хотели бы слышать на собеседовании, а это косвенно требования, потому что ответы показывают уровень знаний кандидата.
Рада, что вам попались кандидаты, как вы искали. Я считаю, что у молодёжи сейчас есть другие плюсы, кроме как знать определения. Я встречала не молодежь, которая не знает определений и работает уже на уровне главных специалистов, но они прекрасно выполняют задачи и являются хорошими боевыми единицами.
Я вам завидую, что находите время читать именно книги, это здорово!
👍 спасибо за статью, здорово, что тема актуально и затронула много читателей.
Спасибо, дополню статью, согласна. Изначально ориентировала статью на читателей, кто уже где то прочитал о профессии.
Сколько junior вы нашли с такими критериями?
Читая вашу статью, я вижу требования к senior и начальный уровень архитектора, я в профессии более 8 лет и успела увидеть несколько компаний и проектов, начинала как раз с junior позиции.
Определения - это хорошо, но аналитик это не википедия, которая сыпет в разработчика определениями. Главное для junior (моё мнение) - это умение думать здраво, слышать и горящие глаза с желанием научиться. А если человек ещё и позитивные, это прям повезло.
Конечно, он должен иметь знания по hards скилам, но без того, что написала выше, работать вряд ли сможет.
Ещё момент про книжки, где вы берете время, чтобы их читать? На работе ставят задачи и у них нет времент, чтобы вы читали книги, им нужны решения, поэтому я благодарна habr, интенсив курсам, митапам и конференциям, где люди делятся знаниями в сжатом виде, потому что мозг аналитика в режиме многозадачности книг и определений просто не поместит.