Команда несерьёзно относится к ретроспективе – что делать?
– рассказывает Екатерина, руководитель направления QA
Ретро в команде посещают «для галочки». Коллеги не слушают друг друга, каждый параллельно делает второстепенные задачи. Постоянно стандартные фразы: в целом всё понравилось, были небольшие проблемы, будем в следующем спринте работать усерднее… Непродуктивно, неприятно 😖

Что можно сделать
▪️ Обсудить с командой проблемы. Выяснить, что им не нравится в формате проведения: что лишнее, а чего не хватает. Возможно, стоит отдельно поговорить с «лидерами мнений», наиболее опытными специалистами, к которым идут за советами и прислушиваются. И ещё раз объяснить цели.
▪️ Вариант для гибридного посещения – офлайн-ретро. Если у команды принято в какой-то день работать из офиса, можно провести ретроспективу именно в этот день. А остальных участников подключить онлайн. Вовлечённость в таком случае выше.
▪️ Попробовать изменить время. Конец рабочего дня или время перед обедом – это «ленивые» слоты. Все на низком старте, чтобы доделать рабочие дела и пойти по своим)
Заранее узнайте мнения коллег на one-to-one.

Пожелания к любым командным встречам, чтобы они были полезными
▪️ Помогайте коллегам высказаться – пусть встреча для них будет прогнозируемой. Составьте план встречи по обсуждаемым вопросам и придерживайтесь его. Дополнительно можно определить порядок: например, начинают аналитики, следом за ними тестировщики и т.д. Так не будет неожиданностей + объединим коллег из одного направления – а обсуждать вопросы, которые непосредственно относятся к тебе, согласитесь, интереснее. Постепенно привычка говорить закрепится.
▪️ Исключайте лишнее. Контролируйте себя и других – встреча должна соответствовать заявленной повестке. Так легче получить конкретные предложения и, соответственно, проследить изменения по ним. Прививаем мысль, что ретроспектива – это про пользу 🙌
▪️ Включайте коллег в обсуждение. Если разработчик реализовал задачу по её описанию и в итоге пропустил требование – выясните причины и предложения не только у него. Спросите у аналитика, по какой структуре ему удобнее работать – может, требования всегда должны быть в отдельной ссылке? У кого были подобные проблемы?
▪️ Обсуждайте реальные кейсы. Общие слова картину не покажут, а все будут относиться к ретро как к своей курсовой – лишь бы не захлебнуться. Так что мотивируйте коллег говорить реальными примерами.
Не «возможно, нам стоит реже обновлять компоненты», а «постоянные обновления компонентов снижают мою результативность, с понедельника по среду я тратил на это по 4 часа и не смог закончить задачу».

Всем полезных встреч ✌️

– Шеф, всё пропало! Фича забагована, релиз откладывается, клиент недоволен…

Если в вашей проектной жизни хоть раз случались инциденты, приглашаем вас 7 декабря в 14:00 мск на вебинар «QA-экстрим: что может пойти не так при тестировании IT-продукта и какие выводы сделать бизнесу».

Руководитель QA-направления SimbirSoft Екатерина и руководитель QA-отдела Алексей разберут разные виды инцидентов и расскажут, как исправить инцидент быстрее и как не допустить «пожара» на проекте в будущем, а также ответят на ваши вопросы.

Вебинар бесплатный, но нужно зарегистрироваться: https://s.simbirsoft.com/bcdp

После мероприятия все участники получат памятку с лучшими практиками по предотвращению инцидентов на проекте. Письмо придет на указанную при регистрации почту.

Ждем вас в онлайне 7 декабря в 14:00 мск!

#SimbirSoft #IT #тестирование #трансляция

Как облегчить команде осмысление ТЗ
– рассказывает Евгения, ведущий аналитик
Хотите, чтобы специалисты вашей команды погружались в проект быстрее? И разработчики тоже этого хотят :) Мы пришли в своей работе к двум лайфхакам – можете предложить их своим аналитикам. Если приживётся – ТЗ станет более увлекательным чтивом)

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

Lite-ТЗ, или визуальное ТЗ, состоит из описательной части и изображений мобильного приложения. В документе есть:
- карта экранов и связи между ними,
- прототипы (дизайн) всех экранов,
- user story – описание того, что пользователю дают конкретные функции приложения.
Исполнителям станет понятнее, когда требования описаны «экранами» с небольшими текстовыми комментариями – это снизит вероятность ошибок. Да и согласовывать с заказчиком визуальное ТЗ удобно: он сразу видит, на какой результат может рассчитывать.

#резюменедели

Forbes опубликовал рейтинг лучших работодателей России, в который вошли 125 компаний 🏆
Мы впервые приняли в нём участие и расположились на 17 строчке в категории «Серебро» – отличный повод для гордости ✌️

Оценивалось возросшее в мире влияние ESG-повестки, на основе которой были сформированы 3 группы: «Сотрудники и общество» (S), «Экология» (E) и «Корпоративное управление» (G). И здесь нам есть, чем гордиться:
💙 «Серебро» в номинации «Экология»
💙 «Золото» в номинации «Сотрудники и общество»
💙 «Бронза» в номинации «Корпоративное управление»

Каждая новая победа – это результат совместной работы наших клиентов, сотрудников и партнёров! Обещаем не останавливаться на достигнутом, ведь мы совершенствуемся каждый день 😊

Да вы, батенька, эмпат! , или Почему каждому менеджеру важно быть хоть немного психологом
– рассказывает Михаил, PM

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

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

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

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

Менеджер в результате пожинает такие плоды:
▪️ быстрее обнаруживает любые тревожные звоночки,
▪️ в команде меньше напряжённости → конфликтных ситуаций,
▪️ специалисты более открыто высказывают предложения по изменениям и новые идеи.

Змей Горыныч Дейли зарубежных проектов состоит из:
▪️ small talk
▪️ стандартного рассказа о проделанной работе и планах
▪️ иииии???

У кого какие идеи возникли?)
А пока ждём ваших комментариев, будем пересматривать Алексея – он в видео рассказывает, как оно на самом деле 🤓

#резюменедели
У нас такие приятные новости :)

Во-первых, мы в рейтинге крупнейших ИТ-разработчиков для финтеха CNews 🏆

Во-вторых, неделю назад зажигали на всероссийском форуме от Сеймартек ✌️ На конференции присутствовали докладчики и делегаты из 5 стран! А что, автоматизация и цифровизация процессов технического обслуживания и ремонтов вообще-то сама себя не обсудит 😏

В-третьих, анонсируем, напоминаем, приглашаем, радуемся – 7 декабря онлайн-вебинар «QA-экстрим: что может пойти не так при тестировании IT-продукта и какие выводы сделать бизнесу».

Обсудим (вдруг вы ещё по ссылке не перешли и анонс не прочитали):
▪️ Инциденты на проекте: дисциплинарные, технические, коммуникационные. Разберём примеры и последствия каждого типа инцидентов.
▪️ Как поступить руководителю, если инцидент случился? Обсудим грамотную реакцию, взаимодействие с виновником и тактику по исправлению ситуации.
▪️ Что делать руководителю, чтобы избежать повторения инцидента? Поговорим о конкретных мерах.

Регистрация = 0,5 мин 😁

#вопросыбизнеса
Что делегировать нейронкам

Во многих отраслях ИИ уже не сидит без работы!) Мы в SimbirSoft считаем, что это хо-ро-шо и рассматриваем ИИ как отличного помощника, но в разумных пределах. Например, в разработке строго соблюдаем NDA и не допускаем обработки любых артефактов проектов с помощью ИИ.

Какие задачи решает искусственный интеллект — рассмотрим на нескольких примерах.

🔹 В финтехе ИИ уже давно предсказывает возможное банкротство, оценивает платёжеспособность клиентов, обнаруживает и предупреждает мошеннические действия.
🔹 В медицине – подсказывает диагнозы на основе симптомов, определяет склонность человека к разным заболеваниям, помогает быстрее зарегистрироваться на приём.
🔹 Также ИИ рассказывает, насколько эффективна рекламная кампания или канал в маркетинге, оценивает спрос на продукт, прогнозирует возможный отток клиентов. И конечно, составляет персональные рекомендации на основе интересов пользователя, например, в онлайн-кинотеатре.
🔹 Оптимизировать маршрут, спрогнозировать заполняемость склада и эффективность перевозок ИИ помогает в логистике.
🔹 А в промышленности – позволяет снизить процент брака, оптимизировать производство, чтобы выпускать максимум продукции, и составлять расписание для обслуживания и отладки техники.

Если что, мы можем всё это 😉

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

На каких проектах нужен scrum-мастер
– рассказывает Дмитрий, PM

Scrum-мастер точно не нужен лёгкому, строго ограниченному по времени и функциональности проекту. Потому что там scrum не нужен 🤷‍♀️ Например, это разработка интернет-магазина на Битриксе с минимальной кастомизацией.

А вот нужен он, когда у нас есть некий продукт, который будет долгое время развиваться. Для этого набирается команда, и она в плюс-минус неизменном составе ведёт продукт до конца. Здесь может не быть чётко сформированного ТЗ. Ведь когда мы говорим про гибкие методики, мы можем стартовать только с идеи.

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

Классический кейс, что scrum-мастер работает вместе с командой с самого начала. Основной смысл его деятельности – это обучить команду основам scrum, фасилитации* мероприятий scrum и самостоятельной работе с коллективной ответственностью. Как тренер)
*Фасилитировать ≠ модерировать. Ну например, мы собрались на планирование, каждый участник должен иметь понимание: что нам нужно иметь на входе, что – на выходе, зачем вообще это мероприятие нужно. То есть важно не просто управлять ходом мероприятия, а доносить его сакральный смысл.

Если обобщать, то основная задача Scrum-мастера – научить команду принимать решения без всякого руководства, чтобы она могла быть независимым элементом. Именно поэтому должен быть несменяемый костяк, иначе просто не получится, ведь Scrum-мастер развивает команду:
▪️ на примерах и практике показывает, какой профит приносит Scrum,
▪️ путём коучинга приводит команду к тому, что она сама доходит до решений.

Какие проблемы может Scrum-мастер решить подсветить команде и сделать так, что она сама их решит:
▪️ происходит конфликт между двумя разработчиками,
▪️ команда не проводит код-ревью,
▪️ команда планирует, но не укладывается в оценки и т.п.
– в общем, процессные и коммуникационные моменты, которые тормозят команду.

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