SimbirSoft: управление разработкой

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

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

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

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

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

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

#вопросыбизнеса

Как заказчику завершить проект: база знаний
– рассказывает Анастасия Леонтьева, руководитель направления QA
Владеть информацией в IT = владеть продуктом. Поэтому бизнесу ещё перед стартом необходимо зафиксировать данные, которые команда разработки должна передать по окончании проекта. Какие это данные? – ответили в карточках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«И так сойдёт! Сроки горят! Едем в продакшн! Потом протестируете всё»...
... так и начинаются настоящие пожары
– рассказывает Светлана, QA-специалист SimbirSoft

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

Читайте эту историю в нашем лонгриде.

🎥 Сегодня вместо #резюменедели делимся с вами кусочком внутрикорпоративного проекта SimbirNews Night, в котором обсуждаем новости компании и приглашаем коллег сыграть в популярные игры.

На этот раз мы так вдохновились проектом «Громкий вопрос» Импроком – что тоже решили испытать свои интеллектуальные способности в чтении по губам. Это было очень громко, азартно и крайне непросто🤯😂

Спасибо авторам за игру и настроение, нам понравилось💙

Если у вас есть свои любимые корпоративные проекты — делитесь)

Руководитель в отпуске – правда или вымысел?
Проверили руководящую должность и отпуск на совместимость – у нас вышло 100% 🏄 Как? – Алексей в видео расскажет)

Как мы строим разработку
– рассказывает Даниил, Project Manager
У всех свой ключ к тому, как достигать целевого результата на постоянной основе. За 20+ лет рецепт сложился и у нас – делимся им 🥢

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

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

🔹 Техническая декомпозиция задач
Необходимость декомпозиции проверяется просто – в диаграмме Ганта на задачу отведено больше, чем 6 часов (2 часа оставляем на созвоны, риски и пресловутый человеческий фактор). Здесь появляется неопределённость. Что понятнее:
▪️ разработчик сделает 3 небольших задачи в среднем по 6 часов,
или
▪️ разработчик сделает «жирную» задачу за 15 часов?
Что будет человек делать 3 рабочих дня?.. Другое дело, когда появляется детальность как для специалиста, так и для управленца. Это упрощает планирование.

🔹 Сбалансирование команды
Это и о грейдах, и о направлениях. Подбираем достаточно бэкендеров по отношению к фронту – чтобы бэк не опаздывал, а фронт не простаивал. Если у нас 3 бэка и 2 фронта, то естественно 1 QA не хватит – он просто не успеет качественно всё проверить. И так далее. Писали об этом месяц назад.

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

🔹 Служба качества
В нашей компании есть отдел, который так и называется – в их задачу входит проведение внутренних аудитов наших проектов. Они погружаются в суть проекта и по чек-листам проверяют:
– достаточность информации, детальность описания процессов (Gitflow, Workflow), настроена ли CI/CD, где ведётся тестовая документация и в каком объёме и детализации…
То есть проверяется всё по регламентам: всего ли достаточно, чтобы успешно завершить проект и сделать его в лучшем качестве.

Если про какой-то пункт хочется почитать больше – пишите, мы запостим)

#резюменедели
Сокращённая неделя не повод расслабляться – решили мы 🏄 Иииии вошли в топ рейтинга, прокомментировали важные темы и встретились с комьюнити на форуме 💫

CNews обозревали мобильность в бизнесе 2023, и мы в стороне не остались и в их топ крупнейших разработчиков корпоративных мобильных приложений попали 🤘

Наш руководитель отдела QA Ирина помогла читателям Skillbox разобраться со SMART: почему такая постановка целей работает, а почему нет. Ещё рассказала, как «добиться высокого качества программного обеспечения (ПО)» по SMART’у.
А руководитель направления аналитики Константин рассказал «Ведомостям», зачем компании визуализируют ассистентов и кому это может прийтись по вкусу.

Десерт – участие в форуме CNews: Информационные технологии завтра, там мы вместе с коллегами обсуждали информатизацию экономики. Стенды были красивые, доклады интересные – нам понравилось 😌

Экономить время, не терять задачи и следить, всё ли идёт по плану...
...хотелось бы не только на проектах. Но с ними проще)
– рассказывает Павел, Project Manager

Подобрал для Skillbox проверенные сервисы управления проектами:
▪️ популярные таск-трекеры,
▪️ сервисы для корпоративной коммуникации,
▪️ сервисы для планирования с помощью диаграммы Ганта,
▪️ сервисы для создания базы знаний.

Для каждого инструмента описал тарифы и важную функциональность. Если хочется самую выжимку – она в конце статьи, в 4 коротких абзацах ✌️

Интересно, а есть среди нас те, кто пользуется чем-то не из списка...

Расстаёмся со старым – как обновить продукт
– рассказывает Евгения, ведущий аналитик

Контекст
Одному из заказчиков надо было помочь «освежить» сайт – провести замену стека и дизайна.

➡️ Что у нас было:
▪️ готовый дизайн от стороннего подрядчика
▪️ условие от заказчика – быстрый time-to-market
Так что план действий был такой: сначала запускаем обновлённую версию в прод, а в дальнейшем развиваем продукт.

Мы были полны решимости, но настаивали на подключении аналитика – документация к системе отсутствовала 🥲 Заказчика убедить не удалось – казалось, что достаточно (нет):
▪️ работающей системы, функции и данные которой надо перенести,
▪️ готового дизайна, который требовалось «натянуть» поверх переписанной системы.

➡️ Что произошло дальше
Вскоре после старта работ начались проблемы 🙃 Для реализации системы в новом дизайне требовалось переписать API и заложить логику под новую функциональность. Очень быстро накопилось около 30 вопросов, решение которых предполагало составление спецификации на доработку системы, описание новой бизнес-логики и доработку эндпойнтов.

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

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

3. Аналитик готовит прототип пользовательского интерфейса системы и согласовывает его с заказчиком.

4. Аналитик передаёт прототипы и требования заказчика дизайнеру.

5. Дизайнер приступает к разработке макетов.

6. Если от заказчика поступили новые требования к функциональности, аналитик пишет спецификации для доработки системы и передаёт в разработку.

7. Дизайнер предоставляет готовый макет, который после проверки аналитиком соблюдения требований передаётся на согласование заказчику.

8. Заказчик согласовывает макет или передаёт новые требования на доработку. Если требования «косметические» – только дизайнеру, а если они касаются функциональности или информационной архитектуры – аналитику.

9. Согласованный дизайн-макет передаётся фронтенд-разработчикам.

10. Фронтенд- и бэкенд-разработчики дорабатывают систему.

11. Запуск в продакшн 🍾

#резюменедели
На этой неделе мы делились экспертизой на своём мероприятии и на внешнем, на нашем сайте и СМИ 💫 Любим, когда общение с комьюнити – по всем каналам 🫶

2 дня на форуме ВБА-2023 «Вся банковская автоматизация» обсуждали современные тренды, инфраструктурные решения и хорошо проводили время)
▪️ Директор по качеству Екатерина и руководитель направления аккаунтинга Марина рассказали о нашем подходе к качеству и точках роста
▪️ C докладом «Автоматизация оценки залогового автомобиля с применением ML-технологий» выступил руководитель отдела mobile Евгений

А ещё вчера провели в Саранске Big Meetup, выступали с докладами сразу в 3 направлениях: frontend, QA, backend. 3 потока, 6 экспертов, вкусный нетворкинг – формула успеха нашей субботы 🧩

Комментарии дали:
▪️ CNews: «Ростелеком» создает СЭД для органов госвласти. Ему предрекают проблемы
▪️ New Retail: Молодые романтики или нарастающая киберугроза?

В статье поделились рекомендациями по подготовке 3 вариантов техзадания на разработку 🔗

Что делать, если клиент хочет релизиться несколько раз в неделю?🙄