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

Меня зовут Настя, я менеджер проектов команды разработки в iSpring. Несколько лет я работала в техподдержке, и это стало хорошим стартом — но со временем хочется не просто работать с готовым продуктом, но и иметь отношение к его созданию. И здесь опыт в техподдержке помогает, ведь проджект-менеджер — среди прочего и саппорт для команды. В поддержке ты привыкаешь контролировать задачи, решения которых ждет клиент — что-то похожее происходит и в работе менеджера проектов, просто немного под другим углом. Расскажу, как навыки, полученные за годы работы в техподдержке, могут оказаться полезными на позиции PM-а.

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

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

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

Уверена, что мой опыт пригодится наставникам и тимлидам, которые также вводят новых QA. Делитесь в комментариях и своим опытом.

В техподдержку iSpring ежемесячно поступает 7300 запросов со всего мира. Техподдержка состоит из трёх уровней:

1. Первая линия. Принимает звонки клиентов, решает простые кейсы: например, дать пользователю инструкцию или восстановить доступ к аккаунту.

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

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

Как работают первые две линии и почему мы пришли к такому разделению техподдержки, — в статье «Как двухуровневая система техподдержки освободила отдел разработки от рутинных саппорт-задач».

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

Компания iSpring 20 лет разрабатывает решения для дистанционного корпоративного обучения. Клиенты находятся в 172 странах, поддержка работает в режиме 24/7 на семи языках. В месяц обрабатываем примерно 7300 обращений по всем каналам связи: по телефону, электронной почте, в чате. 

97% кейсов закрываются со статусом «Довольный клиент». Но так было не всегда: чем больше становилось клиентов, тем сильнее мы начали проседать. Особенно страдали кейсы, которые отдавались в разработку. 

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

Меня зовут Арина, я руководитель отдела технической поддержки iSpring. Расскажу, как переход к двухуровневой системе поддержки помог сократить время решения задач с трёх дней до трёх часов, снизить нагрузку на отдел и перестать дёргать разработчиков из-за лёгких задач. 

Всем привет! В статье расскажу:

— Как и почему у нас возникла необычная проблема, вызвавшая поток 400-ых ошибок. 

— Как реализовали полноценную поддержку отмены операций в микросервисе.

— Как реализовали свой пул подключений к базе для переиспользования подключений к базе в рамках запроса к сервису.

— Как применили контексты в микросервисе и что от этого получили.

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

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

Чтобы локализация происходила проще, мы сделали фичу, которая собирает исходный текст в формат XLIFF, отправляет его в Crowdin и потом передаёт клиенту готовый локализованный текст. Это быстро, почти автоматически и тестируется! Про особенности тестирования сборки текстов в XLIFF-документ и расскажем в статье.

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

Собрали 5 советов, которые помогут тестировщику найти взаимопонимание с разработчиками.

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

Например, пандемия Covid-19 заставила нас всех анализировать данные о заболеваемости, разбираться в показателях эффективности вакцин и разъяснять свои выводы окружающим: родителям, друзьям, коллегам. 

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

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

Первый правильный ответ появился через 8 часов после публикации: шифр отгадал Wigaro из Москвы. Следующие ответы появлялись по одному в день: на второй день отгадал AlexKarpan из Киева и на третий — GruBBy_kz из Караганды.

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

Мы созвонились с победителями и обсудили, как они решали задачу и какие у них впечатления. Даём разгадку.

На разные праздники мы дарим технической команде iSpring Tech подарки. Чаще всего это были книги. Потом переключились на командные футболки. Первый дизайн был с разными космическими кораблями из Звездных войн. И вот перед очередным праздником — это был Новый год — мы вновь задумались о подарках. Решили снова сделать футболки — но не простые, а особенные, чтобы прям для технарей…

Многие наши разработчики любят сложные задачи, ребусы, логические задания и квесты. Так родилась идея сделать футболку-загадку: придумали шифр из пяти уровней и загадали в нём забавные фразы, которые часто употребляют программисты. Основная задача при шифровке была преобразовать текст в картинку, чтобы картинка получилась визуально интересная. 

Мы решили поделиться этой задачкой со всем Хабром. За правильный ответ — приз: отправим победителям футболку с принтом-шифром, как на картинке, и сувенирный набор Марий Эл (в нём — бальзам «Огни Марий Эл», тушенка с мясом из лося, чай, грибы, магнит, открытки, сумка). Победители получат призы как раз к Новому году :)

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

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

IT-компании проводят практику, чтобы найти новых сотрудников, программистов. Это одна из наиболее распространённых причин. В iSpring мы после практики трудоустраиваем 20–30% ребят. Летом 2021-го в iSpring Tech прошли практику 54 студента, 16 получили работу. 

Практику для студентов iSpring проводит не первый год, но раньше масштабы были скромнее: каждое лето — до 10 человек на 1–2 проектах и пара наставников. В этом году студентов стало больше в несколько раз: нам пришлось пересматривать подход к организации практики и более чётко выстраивать процессы. 

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

В этой статье я расскажу про то, как можно организовать отказоустойчивое взаимодействие с внешними сервисами. Тема актуальная, очень часто из-за недоступности какого-то одного компонента может пострадать вся система.

О чем статья:

•  Синхронное и асинхронное взаимодействие; 

•  Зависимость доступности от использования синхронного взаимодействия;

•  Способы избавления от синхронного взаимодействия;

•  Избавление от синхронного взаимодействия с внешними сервисами в PHP.

Всем привет! В этой статье хочу поделиться опытом построения системы доменных событий (domain events) в нашем модульном монолите и микросервисах, рассказать о том, как мы гарантируем их доставку, следим за консистентностью в рамках транзакций, используя transactional outbox, чем доменные события отличаются от интеграционных и всё это в рамках multi tenant приложения. Подробнее под катом.

Привет! 24 июля мы проведем митап менеджеров продукта в смешанном формате: можно подключиться онлайн или, если вы рядом, прийти к нам в офис в Йошкар-Оле.

Темы будут интересны не только менеджерам продукта, а еще представителям смежных профессий: UX/UI, маркетинг, управление проектами, аналитика.

На митапе своим опытом поделятся продакты из ispring, Skyeng и СберТех, а пока мы попросили спикеров рассказать немного о себе и своём докладе.

Эта статья — переработанная версия доклада Отказоустойчивая работа с Redis с прошедшего 17 октября 2020 митапа PHP-разработчиков Йошкар-Олы.

Мы поговорим о подводных камнях использования Redis в системе, где важна отказоустойчивость — на примере хранения сессий в условном веб-сервисе, написанном на PHP, но многие замечания будут справедливы и для других платформ — например для микросервисов на Go. Статья будет полезна, если вы проектируете микросервисы или монолитные приложения с достаточно большой нагрузкой и интенсивно работаете с Redis либо столкнулись с потребностью в перепроектировании механизмов аутентификации и сессий.

Product-менеджер (продакт-менеджер или просто “продакт”) — это человек, который отвечает за успех продукта или какой-то его части. Миссия продакта отчасти альтруистическая и состоит в создании чего-то ценного, что сделает жизнь людей лучше. 

С другой стороны, сегодня профессия product-менеджера очень популярна, поэтому появляется все больше искателей легкого пути: проходишь онлайн-курс, добавляешь строку “product-менеджер” в резюме и просишь зарплату от 150 000 рублей. 

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

Привет, Хабр, меня зовут Богданов Илья, я работаю ведущим инженером в команде веб-разработки. Сегодня я вам расскажу, как настроить стандартную библиотеку Golang так, чтобы избежать неожиданных ошибок в production.

Моя статья ориентирована в основном на начинающих разработчиков, но ветераны Go тоже, вероятно, смогут узнать что-то новое. Коротко о чем будет статья:

• о том, как не ловить ошибки соединения с базой данных на production;
• http.Client и что не так с клиентом по умолчанию;
• http.Server и его подводные камни;
• и, наконец, рассмотрим пару занятных проблем, не связанных напрямую с настройкой стандартной библиотеки.

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

На тот момент наша команда работала над приложением, начало которому было положено еще в 2009 году не искушенными в архитектуре студентами. К 2018 это уже был типичный big ball of mud (большой ком грязи), или, этакий «монолит-копролит», как выразился один наш коллега. Думаю, многим знакомо.