Традиционно скидываем сюда кусочек нашей живой дискуссии 🔥

Как мотивировать команду на развитие и достижение целей
– рассказывает Алексей Флоринский, генеральный директор
Горжусь тем, что мы смогли выстроить культуру семейственности и взаимопомощи, которая помогает коллегам воспринимать компанию как пространство для творчества и развития. Кратко поделюсь основными принципами, которые помогают мотивировать команду покорять новые горизонты.

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

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

Поддержка и развитие
Мы всегда поддерживаем развитие hard и soft skills сотрудников: ведём менторскую систему, помогаем повышать квалификацию и проходить сертификацию за счёт компании, обмениваться опытом на внутренних мероприятиях.
Я глубоко убежден, что только обладая развитыми soft skills, можно работать продуктивно. Для развития гибких навыков сотрудники могут пройти внутреннюю и внешнюю оценку компетенций и узнать зоны роста. Далее при поддержке ментора или руководителя сотрудник составляет план обучения (книги, курсы, конференции) по выбранной теме. По завершении обучения советуем систематизировать полученную информацию, рассказав коллегам о приобретенных знаниях. Мы считаем корпоративную культуру успешной тогда, когда 100% сотрудников независимо от своих ролей и задач являются носителями конкурентных преимуществ компании. Их вклад в проекты помогает достигать бизнес-целей наших партнёров и расти всей компании. И это повод сказать команде: «Спасибо».

P.S. Этот комментарий Алексей дал РУССОФТ для ежегодного исследования «Индустрия программного обеспечения в России» 🧮

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

Как оставаться с заказчиком на одной волне
– рассказывает Сергей Гордеев, руководитель проектного офиса
Стремясь к совершенству в разработке, мы вникаем в специфику бизнеса заказчика и ищем первопричину обращения к нам. За годы практики мы выработали несколько принципов работы с клиентом, которые помогают нам понимать, чего он хочет, и действовать в соответствии с его требованиями. Вот основные из них:

🔹 Быть в контакте. Мы часто взаимодействуем с клиентом, обсуждаем видение и детали, чтобы в конечном итоге достигнуть нужного результата, и всегда остаемся на связи.
🔹 Фиксировать ответственность. На старте проекта составляем матрицу ответственности:
▪️ фиксируем задачи и ожидания заказчика,
▪️ распределяем роли и обязанности.
Если в процессе что-то идёт не так, проводим ретроспективу – даём всем участникам высказаться и вносим корректировки по результатам обратной связи.
🔹 Фиксировать точки контроля. Заранее согласовываем с заказчиком план созвонов, на которых демонстрируем промежуточные результаты по проекту.
🔹 Быть предсказуемыми. Все процессы на проекте прозрачны для клиента: он знает, что сейчас происходит и сколько времени будет длиться каждый этап. Это координирует руководитель проекта.

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

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

В статье рассказали, для чего внедрять 1С:ERP, как подготовиться и с чего начать. А в кейсе — как провели аудит безопасности для немецкой компании.

А ещё мы дали комментарии СМИ:
▪️ ComNews: Что мешает внедрять DevSecOps в России
▪️ Коммерсантъ: Разработчики софта не успевают за уязвимостями
▪️ Коммерсантъ: Власти могут создать ресурс для разработчиков программ на основе нейросетей

P.S. А наши коллеги из кулинарного клуба вдохновляют и показывают: осень – пикнику совсем не помеха ✨ Так что собираемся и дарим друг другу улыбки 💙

#вопросыбизнеса
Что такое PWA и почему оно становится популярнее
Строго говоря, PWA – это веб-приложение. Но некоторые особенности, заложенные на начальном этапе разработки frontend’а, трансформируют его во что-то очень близкое к нативному приложению, которое пользователь мог бы установить на свой смартфон через Google Market или AppStore.
Иными словами, это сайт, который ваши клиенты скачивают из браузера как обычное приложение.

Как и нативное приложение, PWA имеет возможность отправлять push-уведомления, работать в автономном режиме без подключения к интернету, хранить данные локально. Используя для передачи данных протокол HTTPS, PWA имеет безопасное соединение, которое обеспечивает конфиденциальность данных пользователя.

🔺 Большая часть клиентов хочет пользоваться услугами именно через смартфон. А в последнее время блокируют приложения в сторах всё чаще,
Например, на одном из проектов недавно заблокировали iOS-приложение. Мы в срочном порядке разрабатывали PWA, чтобы пользователи могли и дальше пользоваться сервисом в привычном мобильном формате.

Запись в салон красоты, вызов на дом представителей клининговой компании, бронь времени в автосервисе, всё одно – клиент будет делать это с телефоном в руках, зачастую ещё и впопыхах. Здесь и заключается основная задача PWA:
▪️ с одной стороны, сделать более приятным и запоминающимся опыт пользователя при взаимодействии с вашим сервисом, используя мобильное устройство;
▪️ с другой стороны, сделать разработку более доступной для бизнеса.

PWA быстрее и дешевле для реализации, чем мобильное приложение – вы создаёте один продукт и для Android, и для iOS. Тестировать гипотезы проще, так как обновления доступны для ваших пользователей сразу после их релиза без дополнительной загрузки из сторов. При этом PWA индексируется в поисковиках, и на вас работает SEO-продвижение. Да и установка из браузера уменьшает количество необходимых действий для клиентов (конечно, к этому способу надо свою аудиторию ещё приучить).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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