Google-сервисы: уйти нельзя остаться
🤗По одной из версий, Google-сервисы останутся в нашей стране, но с некоторыми ограничениями.
😱 А судя по последним новостям может произойти все что угодно. И по некоторым прогнозам, корпоративные аккаунты могут стать недоступны с августа.

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

​​No-codе решения: для чего подходят, плюсы и минусы
Работа с no-code платформами основана на графическом интерфейсе, который позволяет создавать функциональные решения без знания языков программирования.

С помощью no-code с минимальными ресурсами можно тестировать и реализовывать даже смелые проекты:
🔹 сайты различной сложности (лэндинги, многостраничные сайты, интернет-магазины);
🔹 мобильные приложения с личными кабинетами и разными ролями (например: покупатель, поставщик, администратор);
🔹 внутренние корпоративные сервисы;
🔹 средства для работы с базами данных;
🔹 голосовые приложения и чат-боты;
🔹 модули для платежей и пр.

Бизнесу наших клиентов это дало следующие преимущества:
🔹 высокая скорость освоения работы с платформами;
🔹 снижение нагрузки на разработчиков — они могут заниматься более сложными и серьезными блоками, все еще требующих кода;
🔹 сокращение времени запуска MVP;
🔹 возможность протестировать больше гипотез.

Ничто не универсально – и no-code имеет свои ограничения:
🔹 не подходит для разработки сложных технических проектов и высоконагруженных систем (мессенджеры, блокчейн-проекты и пр.);
🔹 сложная масштабируемость: при росте числа пользователей или значительном расширении функционала продукта необходимо подключение классической разработки;
🔹 привязанность к изначальной платформе: сложность при переходе на другие решения (у каждой платформы свои принципы проектирования и блоки, поэтому придется собирать проект заново);
🔹 риски, связанные с прекращением работы поставщика no-code решения в регионе.

Как итог – учитывая специфику таких платформ, они подходят:
🔹 на начальных этапах разработки;
🔹 при запуске стартапа;
🔹 для автоматизации процессов в малом и среднем бизнесе.

​​Сегодня все следят за облаками ✈️, а мы продолжаем нашу серию статей о переходе на отечественные сервисы. В нашем новом материале:
– рассмотрели несколько российских сервисов – Yandex Cloud, VK Cloud Solutions, SberCloud;
– сравнили возможности и ограничения каждого хранилища;
– разобрали первые шаги по переносу данных.
Подготовьтесь к «переезду», чтобы он не стал пожаром, и читайте нашу статью на Хабре: https://habr.com/ru/company/simbirsoft/blog/679814/

Как выстроить онлайн-коммуникацию на работе: чаты
Чтобы общие чаты несли максимальную пользу и не было желания их замьютить, наши коллеги из QA поделились способами/правилами, которые заведены у нас:
🔹 Одно сообщение всегда лучше, чем очередь импульсивных сообщений подряд. Можно создать такое правило и зафиксировать в описании чата. А при добавлении нового специалиста акцентировать на этом его внимание – так и он сразу всё поймёт, и команде напоминание будет. Если же оно нарушается, можно на дэйлике подсветить плюсы «чистого и аккуратного» чата и четко сформулированных сообщений.
🔹 Если в мессенджере есть функция тредов/комментариев сообщения, активно используем эту чудесную фичу. Опять же, чтобы чат не тонул в непрочитанных сообщениях и важная информация не терялась.
🔹 Вопросы по проекту задаём в общий чат, а не личным сообщением. С одной и той же проблемой к руководителю могут прийти разные люди в личке. Если же обсудить её в общем чате, ответ видит вся команда и лиду не нужно тратить время на объяснения каждому. Также есть вероятность, что вопрос задаст один коллега, а ему ответит другой. Опять же – экономия времени.

В команде важно поощрять вопросы, чтобы ни у кого не было страха показаться «глупыми». Например, мы используем тезис «Глупый вопрос – это незаданный вопрос». Но бывает и такое, что коллеги могут десять раз спросить об одном и том же. Понятно, что это может раздражать, потому что «я же вам уже объяснил, вы что, не читаете чат?!». В таких ситуациях мы предлагаем проанализировать – возможно, это очень важная информация, которая достойна большего, чем затеряться в чате. Её лучше вынести в базу знаний, или закрепить сообщение, или сделать рассылку на корпоративную почту.

Недовольство пользователей внедряемой IT-системой: что с этим делать
«Мы внедрили CRM, но ей все недовольны. Нам надо с этим разобраться, как будете решать?». Этот вопрос заказчик задал на собеседовании одному из наших аналитиков. Своим взглядом на ситуацию поделился наш ведущий аналитик Даниил.
Читайте в Телеграфе, а если хотите рассказать о своём опыте, наши комментарии отлично подходят для этого 🥰

Технологии машинного обучения «повзрослели» до того, что теперь их можно применять в разных бизнес-приложениях ©️

👇В ролике рассказали об одном из таких примеров – автоматизации рутинной деятельности при помощи приложения. Оно позволяет измерять параметры объекта по фотографии.

ML-разработчики и проджект-менеджер SimbirSoft рассказали:
🔹 о проведённых исследованиях
🔹 ключевых особенностях
🔹 трудностях
🔹 внедренных решениях
– в процессе разработки MVP мобильного приложения на основе нейросетей для учёта и маркировки леса.

К слову, эту уникальную систему можно использовать в любой промышленной отрасли, где требуется произвести учёт объектов в сжатые сроки 😏

Связь бизнес-процесса и HR-процесса в IT-компании: личный опыт
В нашей компании за каждый отдельный блок (этап пути сотрудника на проекте) отвечает закрепленная HR-команда. Такая структура позволяет точно разделять зоны ответственности, оперативно реагировать на возникающие сложности у IT-специалистов и развивать глубокую экспертизу внутри, за счет фокуса и постоянного анализа решаемых задач.
Группы и задачи HR-специалистов:
🔹 группа подбора – оценивает навыки специалиста для ускорения подбора команды на проекты;
🔹 группа адаптации – проводит встречи с каждым специалистом, помогает быстрее адаптироваться в команде проекта, выявляет сложности на начальном этапе работы;
🔹 группа мотивации и развития – регулярно наблюдает за эффективностью специалистов, поддерживает и мотивирует их для долгосрочной проектной работы;
🔹 группа кадрового администрирования – сопровождает специалистов по кадровым вопросам, планированию отпусков, оперативно предоставляет кадровые документы клиентам компании;
🔹 группа Office Support – обеспечивает удобные условия для работы в офисах компании;
🔹 группа Event – проводит мероприятия для вовлеченности специалистов.
Как правило, самые ресурсозатратные процессы – это подбор, адаптация и развитие сотрудников. Рассматриваем их подробнее в Telegraph 😎

Проблемы команд при работе по Scrum: как их избежать?
Далеко не у всех разработка по Scrum идёт гладко. Мы подготовили карточки, чтобы напомнить, как можно избежать распространённых проблем при использовании гибких методологий в рабочем процессе 👇

🔥3 дня до круглого стола по безопасности IT-продукта.

Эксперты SimbirSoft вместе с заместителем директора центра разработок АО «ИнфоТеКС» рассмотрят:
– Из чего складывается IТ-безопасность и как её выстроить?
– Какие расходы критически важны, а какие второстепенны?
– Способны ли аудиты безопасности принести реальную пользу?
Время
🔹25 августа в 14:00 (по МСК)
Место встречи
🔹Онлайн. Узнать больше о программе круглого стола и зарегистрироваться можно по ссылке: https://s.simbirsoft.com/7JmP
Стоимость
🔹Бесплатно

На видео наш операционный директор Дмитрий Петерсон рассказывает подробнее, что вас ждёт на мероприятии 🔥 Приятного просмотра 🤗


Информационные партнеры
IB-BANK.RU — сетевое издание по информационной безопасности в банковской сфере.
Cyber Media (securitymedia.org) — портал, освещает новости и тенденции из сферы информационной безопасности и технологий.
RB.RU — независимое издание о технологиях и бизнесе

Один день из жизни релиз-менеджера

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

1. Собираем список задач, которые должны попасть в релиз. Здесь может быть несколько подходов:
🔹 Заводим задачу релиза в таск-трекере, смотрим в нем задачи, у которых есть атрибут «номер релиза: {версия}» и добавляем их списком в общую релизную задачу.
🔹 Заводим задачу в таск-трекере, а оунеры продуктовых команд оставляют комментарии с задачами, которые должны попасть в релиз. Также в комментариях оставляют всю необходимую дополнительную информацию, например: нужно выполнить определенные действия в админке, добавить конфигурации, обновить шаблоны и т.д.
2. Создаем релизную ветку и вливаем все задачи релиза в нее.
3. Собираем релиз-кандидат для проведения регресса.
4. Меняем статус у всех задач, которые попали в релиз-кандидат.
5. Во время регресса следим за блокерами релиза (баги с высокой критичностью, краши). У каждого бага должен быть ответственный, а если его нет, то назначаем, поскольку пока баг не исправлен, релиза не будет.
6. По мере необходимости при исправлении багов регресса собираем новые релиз-кандидаты, обновляем общую задачу, дополнив списком багов, которые заехали в очередном релиз-кандидате, меняем статус у задач.
7. При сборке релиз-кандидатов следим, чтобы заливали только исправления багов, обнаруженные во время регресса. Никакие новые фичи на этом этапе не вливаются, даже если очень хочется. Так как часть функциональности уже проверена, новая фича может повлиять на многое и придется проводить регресс снова, есть риск не уложиться в дедлайн. Тут могут быть исключения — при согласовании и под ответственность команды.
8. Когда последний релиз-кандидат устраивает команду QA и нет багов, которые блокируют релиз, то собирается релизная сборка (такая же, как последний релиз-кандидат).
9. Прописываем релизноты, загружаем сборку в магазин приложений (для мобилок). Для мобилок могут быть тонкости, например, плавная раскатка версии на пользователей.
10. Сообщаем QA, которые имеют доступ «к бою», чтобы они скачали сборку из магазина приложений (мобилки), либо зашли на «боевой» стенд и провели необходимые проверки.
11. Закрываем все задачи, которые заехали в новой версии.
12. Ветку релиза вливаем в мастер, мастер вливает в develop. В мастере добавляем тег с номером версии.
13. В течение нескольких дней после релиза следим за крашами. Дальше по согласованию с тимлидом решаем, нужен ли хот-фикс.

Подробнее о технической части и документации процесса управления релизами читайте здесь 😎

🔥 Обсуждаем безопасность ИТ-продукта с точки зрения кода и инфраструктуры в прямом эфире. Подключайтесь!
Реальные примеры с проектов, конкретные рекомендации, которые «написаны кровью», активные участники 😏

Смотрите трансляцию:
— на канале SimbirSoft на YouTube: https://youtu.be/j5agHZq9iEI

Подключайтесь к обсуждению по ссылке: https://bbb-ext.simbirsoft.com/b/mze-hlo-off-heb

Инсайты обсуждения ☝️

Что меняется на проекте со Scrum-мастером?
☝️Недавно мы спрашивали вас о необходимости Scrum-мастера, когда работа на проекте ведётся по этому самому Scrum. Не все согласились с тем, что отдельный специалист нужен. Мы попросили нашу коллегу из направления QA Наталью раскрыть этот вопрос и поделиться личным опытом.

Что изменилось, когда к команде подключился Scrum-мастер?
🔹 Повысили точность оценки задач. Когда появилось достаточно сделанных задач, Scrum-мастер провёл пару встреч-упражнений по калибровке их оценки.
🔹 Встречи стали эффективнее. Scrum-мастер продумывает сценарии для встреч с бизнесом, ретро, спринтов и кварталов. Команда придерживается этого плана – это позволяет сосредоточиться на целях собрания и продуктивно участвовать в нём.
🔹 Оптимизировали время работы специалистов. Часть организационных работ взял на себя Scrum-мастер: заведение задач и заявок на доступы к ресурсам компании, планирование и создание встреч-созвонов. Также специалисты больше не устраняют «препятствия», например, в виде задач-блокеров – коммуникацию с ответственными лицами ведёт Scrum-мастер, а команда занимается проектом.

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

«Дело было осенью. Шел четвёртый месяц работы над MVP.

Все команды, забыв о квартальном планировании, трудились над срочным запуском продукта. Я подключился к проекту на этапе вывода MVP. К слову, тот запуск был образцово-показательным. Но не обошлось без потерь: по разным причинам ушли QA-специалист и скрам-мастер. Однако на проекте остались крутые и вовлеченные люди, которые приобрели и сохранили весь пережитый опыт.

Что мы имели на входе?..»

Отрывок нового IT-романа, дневник разработчика? Неееет, это статья нашего QA о том, как метрики помогают выстроить работу команды и решить проблемы на проекте – от ограниченного ресурса до ошибок на проде.

В Телеграфе вы найдёте:
🔹 пошаговый путь к метрикам на примере одного проекта;
🔹 мемы;
🔹 реальные графики-результаты проделанной работы;
🔹 (ещё мемы).
Полгода труда точно стоили того – прочитайте и убедитесь сами 😏