Интранет яндекс

Внедрение интранета. Опыт, ошибки, рекомендации

Время на прочтение

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

Однако никто не пишет о «нематериальной» цене вопроса, о рисках, о том, как и зачем создавать интранет, и каких трудов это стоит. Хотят на раз два, и корабль поплывет. Желательно, чтобы плыл сам.

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

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

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

Сценарий «Все и сразу»

История начала у таких проектов банальна.

Клиент приходит к агентству и говорит: «Вот бюджет, который мы готовы потратить на портал. Давайте реализуем масштабный проект. Нам нужна ЭЦП, автоматизация подачи пяти видов заявок, обязательно система оценки 360, интеграция с 1С и нашей корпоративной системой! Если будет надо, мы готовы расширить бюджет».

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

Бермудский треугольник формируют:

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

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

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

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

Этапы и меры нейтрализации каждого пика

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

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

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

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

Этап № 2. Девятый вал

Это пик первой волны внедрения. Налажены доработки начальных релизов, завершено проектирование и оценка всех «хотелок». Многие из них в стадии активной разработки. Финансирование работ приближается к максимуму.

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

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

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

Клиент разочарован и запал пропадает — деньги инвестируются, а работа компании не оптимизирована, от пользователей идет негатив. Ожидания не оправдываются реальностью. Интегратор слышит: «У меня ничего не работает. На что мы тратим деньги? Где результат?». Желание продолжать проект постепенно снижается.

Этап № 3. Отлив

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

Корабль интранета окажется под риском опустеть и остаться без пассажиров.

Проект входит в фазу оттока.

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

Но отведенный срок прошел, руководство не устраивает отдача и постоянное финансирование сокращается. А иногда и прекращается вовсе.

Этап № 4. Мокрый песок

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

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

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

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

Этап № 5 На мели

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

Мы помним, что финансирование сократили. И однажды перестанет работать маленькая функция, потом сломается еще одна — уже ключевая, и пользователь выполнит задачу по старинке. У него не будет иного выбора. «Не работает календарь, буду в своем писать». А денег на поддержку системы уже нет. Это момент переключения — люди уходят с ресурса окончательно.

Спустя время данные на портале полностью теряют актуальность, ломается еще один процесс, а постоянного финансирования все нет. Руководитель просит точечную починку. «Исправьте эту ошибку, эту ошибку». Фиксация мелких ошибок не влияет на общую картину. Улучшение работы интранета идет импульсами, хаотично, а состояние в целом идет вниз и портал не развивается. Он теряет свою значимость. Группа евангелистов распадается. Стратегий развития никто уже не строит.

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

В чем ошибки?

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

Мы собрали эти ошибки в один список, чтобы вы ничего не упустили при внедрении корпортала.

Запуск пользователей в формате «скоростной заплыв»

«Запускайте всех, пусть портал работает!» — частое заблуждение, что массовый наплыв неподготовленных пользователей запустит корпортал, и корабль поплывет. Не поплывет. В 80% случаев на старте он встретит стену непонимания у пользователей и получит снежный ком негативных отзывов.

Внедрение корпортала на неподготовленную «почву»

Пользователей не готовят к запуску корпоративного портала и ставят просто перед фактом: «Работаем!». А «зачем, почему и как пользоваться» не объясняют.

Непродуманная схема обратной связи

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

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

Запрос на «промежуточные» результаты на раннем сроке проекта

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

Пользователям позволено игнорировать корпортал

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

Финансирование корпортала прекращается

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

Рекомендуем, как сделать «Все и сразу»

Если вы подумали, что тактика «Все и сразу» — утопия, то мы вас порадуем. Так тоже можно внедрить интранет (проверено на практике), если подрядчик и клиент помнят и выполняют свои задачи.

Составить план релизов

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

Спланировать этапы постепенного подключения пользователей

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

Провести работу с негативом и наполнять бэклог

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

Продумать формат работы с обращениями

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

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

Рассказать о команде «адвокатов» проекта

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

Подводить комплексные итоги по проекту

Всё требует систематизации. Очень часто проекты по корпорталу из года в год копят реализованный реестр задач, какие-то обороты по клиенту. Но ни агентство, ни менеджер на стороне заказчика не сводят это в единый отчет, не подводят итоги с очной встречей. И как следствие не строят планов. Когда руководство выходит к команде с запросом на промежуточные результаты, сказать нечего, отчет не готов, руководство слышит невнятные объяснения о «потерпеть», «мы что-то там делаем».

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

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

Сценарий «Всё стабильно»

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

Три симптома проекта под названием «Всё стабильно»:

Как плывет этот корабль?

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

На начальном этапе пользователей так же заставят работать на портале, но без явного принуждения. Фокус-группе дают возможность освоиться в интранете, изучить его. Всё происходит без нахрапа. Однако в течение полугода число пользователей увеличивают, пусть и поэтапно.

Финансирование развития интранета также идет планомерно.

Этап № 2. Штиль

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

Целевая точка будет в том же диапазоне — год-полтора, но ожидания несколько другие. Если в первом варианте ждут вау-эффекта, то здесь работающего инструмента в базовой комплектации с заделом на дальнейшее развитие. В целом система будет устраивать клиента. Совпадает и цикл созревания сотрудников до этого инструмента — год/полтора.

Этап № 3. Сбой в навигации

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

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

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

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

Ожидание максимальных результатов в первый год жизни проекта

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

Сокращение финансирования на развитие портала

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

Работа без огонька

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

Рекомендации для стабильных проектов

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

Агентству не терять стратегического подхода к ведению

Регулярно подводить с клиентом итоги работы: за квартал, полугодие. Составлять цели и планы развития на так называемые спринты, короткие отрезки. Длина этого спринта может быть разной. Кто-то говорит о 9 неделях, кто-то о 3 месяцах или чуть более. Обе стороны в проекте должны держать вектор развития корпортала под контролем, понимать, куда и зачем вы идете.

Заказчику набраться терпения

Взвешенные, стабильные проекты развиваются медленнее, а результатов всем хочется побыстрее. Да и чтобы на слайдах годовой презентации перед руководством эти результаты были «ого-го» какие. Такого здесь не будет. Но благодаря пунктам 1 и 2, системному видению, образ корпортала не будет выглядеть «черной дырой», высасывающей деньги.

Постоянная работа с обратной связью

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

Скалы

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

Контактное лицо уволилось, никто не подхватил проект, ведущий разработчик решил сменить специальность и покинул команду. Что делать, если ко всем проблемам добавились и эти? Как начинать, если вы в критической точке?

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

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

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

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

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

Причал

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

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

Нейросеть YandexGPT (YaGPT) стала доступна на главной странице «Яндекс» — ya.ru в «Алисе» через команду «Давай придумаем» в браузере.

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

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

17 мая 2023 года «Яндекс» добавил нейросеть нового поколения под названием YandexGPT (YaGPT) в виртуальный помощник «Алиса».

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

Новая опция уже доступна в приложении «Яндекс», в «Яндекс Браузере», в «Яндекс Станциях» и в умных телевизорах с «Алисой».

Для активации опции генерации текста с помощью нейросети YandexGPT достаточно сказать: «Алиса, давай придумаем!», потом ассистенту можно ставить разные задачи.

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

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

Встроенную в «Алису» нейросеть YandexGPT обучали на суперкомпьютерах «Яндекса». Обучение проходило в два этапа. Чтобы нейросеть впитала в себя знания о мире, сначала ей показали общедоступные тексты: материалы книг, сайтов, статей. Они были отобраны с помощью поисковых технологий «Яндекса», которые позволяют находить среди миллиардов документов наиболее полезные.

В отличие от предыдущих языковых моделей, нейросеть YandexGPT дообучили на сотнях тысяч примеров содержательных и хорошо написанных ответов. Именно поэтому она отвечает так же просто и понятно, как знающий человек. Для сбора и подготовки таких примеров «Яндекс» задействовал свои технологии краудсорсинга и команду AI-тренеров.

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

В начале февраля «Яндекс» сообщил, что разрабатывает свою версию генеративной сети ChatGPT в рамках развития языковой модели из семейства YaLM (Yet another Language Model, нейросеть на базе решений GPT-3 от компании Open AI). Проект получил предварительное название YaLM 2.0, которое в итоге поменяли на YandexGPT.

В марте и апреле «Яндекс» начал активно нанимать на должность AI-тренеров специалистов гуманитарных профессий (журналистов, педагогов, филологов, профессиональных редакторов, социологов, психологов, филологов) для обучения своей нейросети YaLM 2.0.

4 апреля 2023 года «Яндекс» выпустил бета-версию мобильного приложения «Шедеврум» для генерации изображений с помощью нейросети. Инструмент доступен всем пользователям в Google Play и App Store. Количество попыток не ограничено, можно генерировать столько картинок, сколько захотите.

Мы создаем и поддерживаем экосистему внутренних сервисов, необходимых для ежедневной работы всей компании и её подразделений, а также сервисы для сопровождения найма и организации соревнований по программированию.

Мы создаем и поддерживаем экосистему внутренних  сервисов, необходимых для ежедневной работы всей компании и её подразделений, а также сервисы для сопровождения найма и организации соревнований по программированию.

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

пользуются внутренними сервисами

и 2 млн внешних пользователей

средняя нагрузка на наши API интранета

в разработке на JavaScript, Python и Java

Сервисы для сопровождения процесса найма в Яндекс

От заявки на вакансию, подбора кандидатов и собеседований до приема на работу. Сайт, на котором вы сейчас читаете этот текст, тоже сделали мы 😉

Экосистема сервисов для организации работы сотрудников

— Рабочий календарь;

— сервис для проведения видеовстреч;

— сервис со структурой компании и списком сотрудников;

— сервис для оформления командировок, отпусков и отсутствий;

— сервис для performance review (регулярная оценка сотрудников);

— навигация по офисам (карта бизнес-центров, оборудования и столов сотрудников);

— единый API с данными о сотрудниках;

— сервис для онлайн-обучения.

Онлайн-платформа для организации соревнований по программированию.

— Сайт Академии Яндекса;

— Хэндбуки по машинному обучению, основам Python и C++.

В нашей команде более 150 специалистов: фронтенд- и бэкенд-разработчики, менеджеры, дизайнеры и тестировщики. Мы работаем по принципу v-team — когда под каждый проект собирается отдельная мини-команда, руководителем которой может стать и разработчик. Смена проекта может происходить раз в полгода.

Наша распределенная команда работает в Москве, Санкт-Петербурге, Екатеринбурге, Минске, Симферополе и других точках мира.

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

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

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

Задач много — от «перекладывания JSON» до создания новых микросервисов и больших современных интерфейсов.

Технологии и подход к разработке

Мы стараемся использовать актуальный стек. Все наши сервисы живут в облаках и работают на базе Docker.

У нас много интерфейсов различной сложности: от классических SPA с помощью create-react-app до сервисов со сложной клиентской архитектурой и поддержкой мобильной платформы в виде WebView внутри приложения под iOS или Android. Мы активно переходим на TypeScript, компоненты пишем с помощью React/Effector, поддерживаем существующие проекты на Redux/Redux-observable. Развиваем дизайн-систему в проектах и пишем для её реализации библиотеку компонентов.

Пишем e2e-автотесты на JavaScript с помощью WebdriverIO и покрываем компоненты модульными unit-тестами с помощью библиотеки react-testing-library и фреймворка Jest.  Следим за визуальным качеством сервисов при помощи скриншотных тестов на основе библиотеки Hermione.

Бэкенды пишем на Python 3 и Java. При разработке бэкендов на Python используем последние версии фреймворков Django и асинхронный FastAPI, а также библиотеку Celery и ARQ.

При написании Java-проектов используем языки Java Core и Kotlin, фреймворки Spring и Apache Kafka.

Храним данные в PostgreSQL, MongoDB, Redis и ClickHouse.

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

Мы спросили нашу команду, что даёт работа в HR Tech

Нам всегда нужны

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

Только быстрый офер

Ищем лида команды, которая развивает сервис Стафф — ядро интранета Яндекса. Ждём, что вы проектировали критичные к отказу сервисы, отлично знаете Python, Java или Kotlin, управляли небольшими командами, готовы к сложным технологическим вызовам и непродуктовым задачам.

Карьерный портал Yandex Team — ключевой инструмент для привлечения сотрудников в Яндекс. Вам предстоит полностью отвечать за развитие продукта и помогать редакции в части дизайна. Ждём, что вы управляли дизайном и развивали B2C-продукт, умеете видеть потребности компании и пользователей.Мы развиваем главную страницу интранета, сервис общения со случайным коллегой Random Coffee и другие сервисы для сотрудников Яндекса. Ищем человека, который сформирует стратегию технического развития нашей экосистемы и построит дружную и сильную команду бэкенд-разработки.Yandex TeamTicket позволяет оформлять командировки в несколько кликов и агрегирует множество поставщиков услуг. Мы ищем сильного менеджера проектов с релевантным опытом работы, который готов развивать сервис и улучшать мир бизнес-поездок.Для автоматизации HR-процессов мы используем ERP-систему Oracle E-Business Suite (OEBS) и веб-приложения внутренних сервисов. Вам предстоит тестировать с помощью SQL, PL/SQL, Java + JUnit + Selenium, Jenkins, создавать тестовые данные, запускать проверки и автотесты. Приходите!Мы развиваем Академию и Лицей Яндекса — портал образовательных программ и LMS для обучения программированию со всей сопутствующей инфраструктурой. Присоединяйтесь, если знаете TypeScript и React, работали со стейт-менеджерами Effector или Redux.Сервис Yandex TeamTicket позволяет оформлять командировки онлайн в несколько кликов. Ищем сильного менеджера по продажам. Приходите к нам, если больше двух лет занимались холодными продажами, умеете формировать стратегию развития клиентов и работать в CRM, хотите улучшать организацию поездок.Мы отвечаем за десятки систем: интранет-портал, корпоративный календарь, инструменты для безопасной переписки в Telegram, сервис видеоконференций и блог-платформу. Ищем опытного фронтенд- разработчика для работы над нашими сервисами.Мы создаём мобильное приложение для сервисов повседневной работы сотрудников: календаря, интерактивных карт офисов, личных профилей, согласований и других. Оно поможет взаимодействовать с IoT-инфраструктурой нового офиса Яндекса в Москве. Ищем руководителя команды мобильной разработки этого приложения.Команда HR Tech строит и поддерживает экосистему внутренних сервисов, необходимых для работы всех сотрудников Яндекса. Мы ищем опытного разработчика, который будет решать задачи application security. Наш стек: Python, Django, Celery, FastAPI, asyncio, PostgreSQL, MongoDB.Экосистема интерактивных дашбордов показывает динамику важных HR-метрик и помогает руководителям и отделу персонала Яндекса принимать верные решения. Мы ищем аналитика, который любит визуализировать данные и уже работал с Tableau, Power BI, DataLens или другими BI-инструментами.HR Tech работает над внутренними сервисами для сотрудников Яндекса. Мы ищем коллегу в команду оптимизации компенсаций и бюджетирования для работы в OEBS. Вы станете оптимизировать процессы, участвовать в проектировании нового сервиса и руководить реализацией фич.Наша команда создаёт интранет Яндекса — высокотехнологичные и современные сервисы для найма сотрудников, организации работы и жизни внутри компании.В Яндексе есть подразделение HR Tech. Это разработчики, дизайнеры и менеджеры, которые делают сервисы для найма сотрудников и для организации работы. Если вы хотите вместе с нами создавать удобный интерфейс, продумывать архитектуру сервиса и оптимизировать код — ждём в команде.Ищем дата-инженера, который будет заниматься созданием и развитием Data Warehouse в HR.HR Tech — это сервисы для найма сотрудников и инструменты для работы в компании. Приходите, если готовы работать с СУБД Oracle, PL/SQL и другими средствами разработки Oracle. У нас интересные задачи и постоянный карьерный рост.Наша команда разрабатывает сервисы для сопровождения найма в Яндекс (сайт, где вы читаете этот текст, тоже сделали мы). Стек: Python, Django, PostgreSQL, MongoDB, Celery. Приходите улучшать наши сервисы, если применяли Django и работали с реляционными и нереляционными БД.

© 2004-2023 ООО «ЯНДЕКС»

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

В сумме мы прошли около 20 контрольных точек, каждую из которых нужно было угадать. Иногда по текстовой загадке, включив логику. Иногда поискав ответ в Сети. Иногда найдя спрятанный QR-код или надпись. В дороге между точками нам в группу скидывали какие-то интересные факты о Яндексе и его сотрудниках. А ещё всякие полезности типа правил библиотеки, расписания работы офисов, расположения нужных по работе объектов.

Это не дура, это лошадь! Её Волож притащил :))

Про сам офис, который занимает огромную территорию в трёх больших зданиях, названных в честь известных российских «бизнесменов» (Строганов, Морозов и Демидов), много писать не буду. Это лучше один раз увидеть. Много ярких пятен, много странных людей, много уютных местечек. Сами смотрите.

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

Внутренний дворик – очень уютное место.

Будка для интровертов. Ну или просто место поговорить.

Музыкальная комната. Инструменты натащили сами сотрудники.

Переговорка имени Стаса Михайлова :))

Наш лось нашёл себе друга 🙂

Очень понятные указатели и заумные названия переговорок.

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

Обалденный вид с терассы на крыше. В эту штуку видно людей, гуляющих в парке Горького.

Светофор в отделе Яндекс.Пробок, который показывает как хреново сейчас на дорогах Москвы.

Юзабилити лаборатория. Жизнь за односторонним стеклом.

Селфи у знаменитой буквы «Я» рядом с кабинетом Воложа.

А вот и сам кабинет. Говорят в нём может поработать любой сотрудник, когда хозяина нет. Я не рискнул 😉

Уставшие и довольные.

В итоге все получили стикеры «Я делаю Яндекс» и ачивки в интранете за прохождение квеста. Даже вроде какой-то рекорд установили 🙂

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

Рано или поздно у любой ИТ компании (аутсорс или продуктовой) возникает желание организовать собственное пространство, где можно хранить информацию по проектам, сотрудникам, продажам. Вести рабочую переписку и обсуждать задачи/стратегии/документы. Чаще всего, такие компании начинают кодить все сами или пилят что-то для Битрикс24 и тд. В данной серии статей я расскажу о нашем велосипеде — опыте автоматизации процессов. Как положено, почти все self-hosted, opensource и постараемся обойтись почти без кодинга.

Disclamer

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

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

• Конечно GIT сервер, пользователи которого, будут связанны с пунктом 1
• Обязательно Chat-Server (Messenger если хотите) и конечно с пользователями из пункта 1
• Корпоративная почта, по любому с пользователями из пункта 1

– это наш скромный список. У кого-то он в разы больше, у кого-то наоборот.

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

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

В качестве основы всей системы, мы перепробовали множество OpenSource ERP/CRM систем (Odoo, Axellor и другие), пытались адаптировать OpenProject и подобные проекты. Все они по своему хороши, но одним из требований была легковесность и простота доработки. Решили выбрать что-то на PHP, благо их вагон.

И так, мы имеем EspoCRM. Штука молодая, сложно сказать что это «самый лучший» выбор, но она нам понравилась. Без кодинга можно создавать сущности, можно добавлять поля и связи, похожа на CMS, но чуть более расширенная.

Наконец к делу. Подготавливаем платформу

После долгого предисловия, Espo будет выполнять следующие задачи:

Устанавливаем платформу

Тут все как с любым PHP проектом. Весь процесс подробно и с картинками расписано вот тут

После установки мы попадаем вот в такой интерфейс:

И мы имеем готовую к работе CRM. Но нас сейчас интересует управление пользователями.
(Я решил использовать Русскую версию, перевод неплохой и понятный).

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

Видим что-то такое:

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

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

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

Почта

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

В нашем случае — почта это не self-hosted подсистема. Конечно, можно организовать свой сервис, куча готовых решений на рынке. Но мы решили использовать Яндекс.Коннект. У них очень добрые лимиты в 1000 пользователей, достойный web-интерфейс и достаточный RESTapi. Конечно не без рекламы, но в наше время — это нормально.

Организовать почту можно по инструкциям от производителя и затем вернуться к этой статье.

Будем считать, что у нас уже есть настроенный сервис, и теперь нам надо связать почту и портал на espo.

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

Node-RED

Ставим Node-RED по инструкции с оф. сайта, проверяем, что все работает и открываем доки на API Яндекс.Коннекта.

Нам нужно зарегистрировать новое приложение и сгенерировать ему API Token.

В платформах выбираем «Веб-сервисы» и нажимаем кнопку-ссылку «Подставить URL для разработки».

Далее, настраиваем права данному приложению.

Нас сейчас интересует только Яндекс.Коннект Directory API, и настроить права можно, к примеру, вот так:

(минимально необходимо только Управление пользователями и Чтение данных о сотрудниках)

Сохраняем и видим что-то вот такое:

Сохраняем токен в надежном месте.

Теперь, наконец, переходим к интеграции через Node-RED.

Так мы запишем токен в глобальные переменные и дальнейшем сможем получать его с помощью global.get() в любой функции.

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

Node-RED + Яндекс. Коннект

Это будет тестовый аккаунт нашего потенциального юзера.

Тут мы подготавливаем тело запроса по инструкции и устанавливаем заголовок с токеном авторизации.

Ура! Мы сделали первый кусок интеграции!

Интеграция EspoCRM с Node-RED

Тут мы объявляем Hook на сохранение и удаление объекта пользователя. (можно почитать в доке) Каждый раз, когда кто-то сохраняет/создает/удаляет пользователя в Espo, будет отправляться запрос на сервер Node-RED. Наверное не самый безопасный способ, но если сервер Node-RED и EspoCRM находятся на одной физической (или виртуальной) машине, можно использовать localhost и уже будет чуть секурнее.
NODE_RED_ENDPOINT — мы настроим чуть позже.

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

Осталось все это соединить:

Мы рассмотрели базовый принцип интеграции через Node-RED. Конечно, мы не учли удаление и редактирование пользователя. Ниже ссылки на готовый Flow, который все учитывает. Его можно просто скопировать и импортировать себе (обновив токены доступа конечно).

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

В следующих статьях я расскажу:

FAQ:
Q: Зачем вообще Node-RED, если запрос можно сделать прямо из PHP к Яндексу?
A: Имея интеграцию на стороне Node-RED, мы можем менять конфигурацию, добавлять новые сервисы и хуки, на изменения пользователя, без дополнительного кодинга (не считая мелких функций на Node-RED). Процесс деплоя обновлений сводится к одной кнопке.