iFellow

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

Но тем не менее, общие тренды прослеживаются. ChatGPT не сам собой появился, это результат длительной работы. Инструмент 100% классный

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

На моменте инициации крайне отметить DoD (Definition of Done) и договориться с заказчиком. При этом мы сразу рисуем критический путь и проводим декомпозицию задач. Если четко определены границы проекта, то такие кейсы возникают только в классическом управлении проекта - запрос на изменение.

Контроль за управлением границ проектов лежит на руководителе проекта.

вечная классика )

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

Это целая отдельная тема для обсуждения. Но договориться с заказчиками практически всегда можно! Для этого мы работаем с "болями" клиента и подробно объясняем все этапы работ.

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

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

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

Инструмент не про производительность команд. Инструмент отвечает на другие, более высокоуровневые типовые вопросы:

- есть ли у нас глобальный простой у сотрудника, в какой практике (загружен менее половины времени) и какие сейчас возможности его занять?
- через два месяца закончится контракт, команда станет свободна, куда перераспределяем именно по такому стеку технологий?
- есть ли у нас в ближайший месяц два доступных разработчика С# в грейде таком-то?
- в случае 50% вероятности проекта на N сот миллионов рублей нам надо нанимать новых людей, перераспределять текущие команды или обучить в течение оставшегося времени?
- если сейчас 30% ИТ-специалистов такого-то стека или практики в полном простое, то нам это стоит вот столько и какие рыночные объективные причины?

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

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

Да, Вячеслав верно ответил, что "Орион" построен на платформе Jira. Гибкость данной платформы позволила нам сформировать такие инструменты.

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

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

Полная версия тут https://www.cnews.ru/articles/2023-01-24_kak_pervaya_portovaya_kompaniya_vnedryala

Если очень захотеть, то можно, конечно.

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

А как вы предлагаете называть людей, имеющих знания, но без опыта работы или с минимальным опытом?

Классная история. И вы в итоге стали архитектором?

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

Есть устойчивое выражение про "хорошего парня", поэтому получился такой вот каламбур.
Конечно же в ИТ работает и много девушек. Хотя в целом доля мужчин несколько больше. Это связано с тем, что больше мужчин в ВУЗах получают STEM-специальность.

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

ИТ-отрасль всегда открыта для талантливых и интересующихся специалистов. Так что все не так печально!

Спасибо, это интересная мысль

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

Джун всегда должен быть под присмотром ментора и удобнее всего это делать в офисе. Насчёт возраста — сильно зависит от того, из какой сферы пришел человек, если до 50 лет вы были далеки ИТ-сферы, то шансы невелики.

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

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

Мы анонсируем наборы слушателей в нашей группе Вконтакте и на сайте. Ближайший поток ориентировочно запустим в апреле.

Есть два варианта: 1. Отбираем с рынка через стандартное собеседование для проверки проф. навыков. 2. Проводим курс обучения для молодых специалистов. В процессе обучения отбираем наиболее перспективных.

Это бот, который реализует интерфейс Service Desk Jira компании в телеграме, для большего удобства пользования сервис деском со стороны сотрудников и бизнес-подразделений.

Спасибо за вопросы! Каждому полю присваивается тип данных (опять же, метаданные Jira), они сохраняются в соответствующем запросе issue Jira. А типы данных заложены в основном коде по каждому сценарию. Таким образом, при ответах пользователей Jira распознает, что за данные и в какой тип полей раскладывать у себя. А каждый пользователь в самом начале отдает свой номер для аутентификации и так телеграм сам отдает матчинг отправляемых данных, соответствующих авторизованному номеру телефона. А в Jira матчит номер телефона по УЗ пользователя.