#резюменедели
Wadline назвал нас среди лучших разработчиков ПО 2023, а ещё – среди тех компаний, которым можно доверять. Ну а кто мы такие, чтобы не соглашаться? 😅 Вот и соответствуем :)

Клиент отзыв нам прислал. Пишет, что с нами легко и надёжно 😇

Наш директор по качеству Екатерина Ремизова – на Доске почёта «Лучшие люди Ульяновской области»! Наши коллеги вообще часто удостаиваются высоких наград. Например, в прошлом году одним из лучших людей региона стал соучредитель компании, Backend-разработчик Алексей Колесников😎

А на десерт – публикации в СМИ)
▪️ Дали комментарии о рынке IT-аутстаффинга для ComNews: В России востребован аутстаффинг
▪️ Поделились опытом с TProger: Как стать тестировщиком в 2024 году: что происходит на рынке и что учить

#вопросыбизнеса
Как происходят утечки и что делать, если это произошло
– рассказывает Максим, web-разработчик

В сети опубликовали крупнейшую базу данных из 26 миллиардов учётных записей 😱 Среди данных можно найти учётки Tencent, X, Telegram, Dropbox, Vk, LinkedIn, Adobe и другие.

Такие инциденты могут сильно ударить по репутации компании. Например, привести к потере клиентов, инвесторов, а также возможным судебным искам и штрафам от надзорных органов.

Клиентам важно, чтобы данные были надёжно защищены и не оказались в руках злоумышленников.

🤖 Какие киберугрозы актуальны на начало 2024?
Существует проект по безопасности веб-приложений OWASP, в котором сформирован список с самыми актуальными уязвимостями. Перечень периодически обновляется.
Предлагаю познакомиться с OWASP Top Ten и проверить свою инфраструктуру.

Три самые ходовые угрозы👇
▪️ 3 место. Инъекции
Могут быть связаны с ошибками в архитектуре. Чаще всего используются уязвимости из группы SQL-инъекций и запуск команд на уровне операционной системы.
▪️ 2 место. Сбои шифрования
Это некорректные настройки защиты соединений и данных: неправильные условия для хранения ключей, устаревшие алгоритмы шифрования и ошибки при реализации в коде.
▪️ 1 место. Нарушения контроля доступа
Тут всё банально – о доступе к функциональности, к которой у злоумышленника не должно быть доступов.


💁Что можно сделать, если произошла утечка данных
▪️ Не скрывать факт инцидента
Скрывать информацию смысла нет, так как клиенты и инвесторы рано или поздно смогут обнаружить источник утечки. Открытость же напротив снижает градус.
▪️ Объяснить, что дальше
Расскажите, что произошло, какие данные были украдены и какие действия (будут) предприняты со стороны компании. Напомните рекомендации безопасности клиентам, и даже о банальной смене паролей.
▪️ Возможно, предоставить бонус клиентам
Бонус или скидка поможет сгладить негатив и удержать клиентов.

🕵️ Как проверить самому утечку данных
Специальные сервисы уже придуманы за нас) Например, на сайте Cybernews возможно посмотреть, в каких слитых базах находится ваш email или номер телефона (вводите по такому принципу: +7(999)000-00-00)

Подготовили для вас чек-лист по IT-безопасности 🔐
В него вошли списки неочевидных угроз и инструментов для их устранения, решения по обновлению библиотек, ответы на реакцию команды.

Всем привет! Подписчик задал классный вопрос в комментариях к посту об опорных словах на презентации продукта. А как, собственно, определить тип восприятия клиента: визуал он, аудиал, дигитал или кинестетик?

Составили подробный ответ – решили продублировать и в основной ленте 🤗

Как определять тип восприятия клиента
Так как «чистых» типов крайне мало, для определения в большинстве случае потребуется время и уже проведённые совместные встречи.
В целом, могут помочь и фразы, которые мы описали в основном посте для презентации) 👆

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

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

Дигитал. В инфографиках не обратит внимание на стиль, а скажет «как логично расположены блоки» или «нужно бы добавить связи между объектами». Он просит чёткий протокол встречи с результатами. Сам легко подбивает документы или предлагает, как сделать формулировку конкретной, без лишних толкований. Важен не только итог, но и его подробное обоснование – это не зависит от доверия к сотруднику.
Из неформального – если он играет, то ему нравятся стратегии. Говоря о покупке, он опишет её функциональность: количество карманов, «подходящесть» для разных сезонов и погоды.

Кинестетик. Записывает для себя по ходу встречи. В процессе мозгоштурма может вставать с места и ходить. На презентации важно самому иметь устройство с продуктом – чтобы «руками» следовать за спикером. Он часто вертит что-то в руках, может лопать пупырку и рисовать во время встреч.
Из неформального – может предпочитать личные дела вести письменно: планы, бюджет. О свитере или рубашке расскажет, какие они наощупь. Больше всего нравятся выставки, где разрешили трогать и крутить. Из поездки вспоминает много тактильных впечатлений: фрукт был пушистым, а в здании были гладкие камни, в кафе – ласковый кот)

Мы это всё к чему? 👆 – В наших пользовательских руках всё больше смартфона. И по количеству, и по времени, между прочим.

И ещё недавно разработка приложений для этих самых смартфонов была стабильной и понятной. Но оказалось, не только жизнь общажная полна сюрпризов :)

Так давайте 29 февраля обсудим этот вопрос! А именно:
▪️ актуальную ситуацию на рынке разработки мобильных приложений
▪️ современные решения в создании мобильных сервисов и тренды в поведении пользователей
▪️ опыт и кейсы бизнеса по преодолению блокировок и ограничений
▪️ состав идеальной команды разработки мобильного приложения
▪️ инхаус, аутсорс или аутстафф в мобильных проектах: что выгоднее бизнесу и при каких условиях

– Чем же всё это окончится? – Будет апрель март.
– Будет март, вы уверены? – Да, я уверен.

А ещё: запись нашей с вами встречи и памятка с актуальными способами создания мобильных решений для бизнеса (по каждому будут указаны особенности, плюсы и минусы).

Ну какова красота! Регистрация тут: https://s.simbirsoft.com/NKc6)

P.S. Админ собрал отсылки для всех возрастов, 😎 – если понял все три. А остальным солнышко придётся ставить, а то как же солнечные очки без солнца)

SMART и делегирование в работе руководителя
– рассказывает Ирина, руководитель отдела QA

Когда растишь отдел, очень хочется работать с профессионалами, которым можешь доверять: поставить задачу – и быть уверенным, что она будет сделана. Чтобы было именно так – важно вкладываться в своих сотрудников с самого начала:
1. делегировать,
2. ставить задачи по SMART,
3. расставлять приоритеты между ними (и объяснять, почему именно так и не иначе).

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

→ Ставишь задачу, назначаешь ответственного, ограничиваешь во времени, обозначаешь точки контроля

И можно не называть это SMART’ом, но это будет он, пусть и в супер-лайтовом виде)

Почему это важно
Для личных дел и вопросов детали можно не расписывать: ты понимаешь, что имеешь в виду. Но когда ставишь задачи кому-то другому, должно быть полное совпадение твоих ожиданий и ожиданий специалиста. SMART – это не про микроменеджмент, это про прозрачность и однозначность.

Получается, если каждый привыкнет работать в парадигме SMART, то информация будет восприниматься всегда в верном ключе. Конкретика будет привычкой, и сломанного телефона не случится)

Так что, если вы прививаете этот навык сотрудникам с первого дня, потом спокойно сможете поручать им задачи различного уровня сложности. Если какой-то информации им не хватит – они сами первые сообщат вам об этом 🙌

#резюменедели
Суббота у нас сегодня читательская)

В статье для it world рассказали, как технологии ИИ используются в процессах разработки. Вы знали, что разработка с применением ИИ-инструментов на разных стадиях жизненного цикла ПО к 2028 году может достигнуть 75%? 🤯

С ComNews поделились мыслями об импортозамещении:
▪️ Первая российская АБС мигрировала на импортонезависимые СУБД
▪️ Что мешает провести импортозамещение вовремя. Считаем, что заменить иностранное ПО полностью до 1 января 2025 года – это амбициозно. Чтобы сделать это, надо:
1. обеспечить достаточное количество качественного российского ПО
2. подготовить кадры для работы с ним
3. обучить конечных пользователей

В кейсе – как усилили команду Zetra на проекте микросервиса веб-приложения для экстренных служб 👩‍🚒 Среди вызовов – сложная архитектура, состоящая из 50 микросервисов, отсутствие детализации ТЗ и сжатые сроки)

​​#вопросыбизнеса
Как сокращаем риски при оценке проектов
– рассказывает Антон, руководитель архитектурного комитета

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

Мы аккумулируем в общей базе опыт решения типовых задач, оценённый в часах (планируемых и фактических).
⬇️
Периодически корректируем оценки типовых задач на основе обновлённой информации.
⬇️
Используем наборы готовых решений, которые связывают различные этапы реализации системы. Так, типовая функция системы имеет оценку на различных этапах: от аналитики и проектирования до реализации и тестирования.
⬇️
Оценку проекта проводим в два этапа. На первом детально оцениваем аналитику, архитектуру и проектирование системы. Этап реализации, тестирования и внедрения оцениваем рамочно – для общего понимания сроков и бюджетов, которые могут корректироваться.
Второй этап оценки запускается после завершения этапа аналитики и проектирования, когда команда более детальное погрузилась в проект и у неё есть понимание сроков.

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

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

Специфика зарубежных проектов
На иностранных продуктах мы замечаем закономерности в подходах к работе. Решили поделиться ими в посте)

1. Отлаженный процесс онбординга
Каждый сотрудник получает план на первые месяцы работы: какие доступы настроить, в какие задачи погрузиться. Помимо этого, к новичку приставлен buddy – сотрудник из той же команды, который знакомит с коллегами, помогает погрузиться в продукт и предстоящие задачи.

2. Метод кнута и пряника недопустим, во всём приветствуется гибкость
Во время code review специалисты стараются не «тыкать»: «ты сделал неправильно»,, «ты не учел». Вместо этого используется подход с позиции «мы»: «у нас возникла проблема», «не хотим ли мы это поменять». Вместе с высокими требованиями к hard-скиллам здесь есть принятие того, что человек может ошибиться. Сложно представить ситуацию, при которой члена команды отчитали бы за промах публично.

3. На первом месте качество
Как и на любом IT-проекте, клиенту важно укладываться в дедлайны. Однако если команда по объективным причинам не успевает в срок, руководство не будет форсировать события, ведь в приоритете – качество продукта. Задачу вынесут в следующий релиз, чтобы пользователь не получил сырой продукт. Когда менеджер хочет как можно быстрее выложить фикс бага, он говорит об этом заранее, и команда укладывается в срок без необходимости работать сверхурочно.

4. К слову о переработках: их, как и само явление трудоголизма, компания не приветствует
Сотрудника, пришедшего на рабочий созвон в свой выходной, ненавязчиво отправят отдыхать. Здесь ценят не только работу, но и отдых, и чётко следуют идее work-life balance – лучшей защите от эмоционального выгорания.

5. Гибкие требования к продукту и результату
Как правило, в российских компаниях принято ставить чёткое ТЗ с частично прописанными условиями реализации. На иностранных проектах чаще видим фокус на бизнес-идее. Специалистам предоставляется свобода выбора пути решения, поощряется инициативность. Такое смягчение требований объясняется просто: разработчик может сделать не так, как требует менеджмент, а намного лучше.

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


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

▪️ Гарантировать взаимозаменяемость в командах. На проекте нет чёткого разделения ролей. Если специалисту по силам справиться с задачей другого направления, к нему могут обратиться за помощью. Фронтенд-разработчика могут подключить к задачам бэкэнда. Да и автотесты часто также выполняют разработчики.

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

Неполное описание задачи в таск‑трекере? – Не надо так 😶
– рассказывает Екатерина, руководитель QA-направления

Часто на проектах задача сначала обсуждается между руководителем разработки и системным аналитиком верхнеуровнево: что именно делать и в каком виде. Автор при переносе такой задачи в таск-трекер может решить, что подробно заполнять поля уже не нужно. Ведь фича уже описана в базе знаний 🙄

Что делать, если такое иногда происходит в команде
1. Напомните команде, чем это может грозить
▪️ Разработчикам и QA-специалистам потребуется больше времени, когда они будут брать фичу в работу. Сначала специалист пойдёт изучать требования в базе знаний, потом уточнять их у коллег, процесс затянется, при доработках снова придётся вспоминать, о чём вообще это всё было.
▪️ Больше вероятности, что задача, вернётся на доработку. Если у задачи отсутствует подробное описание с требованиями, то разработчик может не понять, чего именно от него ждут. Поэтому задача, скорее всего, вернётся на доработку, а того, кто её ставил, попросят уточнить техническое задание.

2. Обсудите единый вариант оформления
При создании задач основные пункты описания:
▪️ Понятное название задачи
▪️ Требования к функциональности и производительности продукта или системы, которые необходимо реализовать
▪️ Ссылки на дизайн-макеты, описание архитектуры, включая структуру, компоненты и взаимодействие между ними
▪️ Требования к тестированию и контролю качества, включая критерии приёмки
Точный перечень будет зависеть от специфики проекта – обсудите его внутри своей команды и придите к единому удобному шаблону оформления.

#резюменедели
Китайский Новый год, друзья! Окунаемся в сказочную атмосферу ✨

Что делать, когда Кощей похитил Новый год, потому что не успел сдать проект? 🦹🏻‍♂️

Вместе с детьми наших IT-специалистов нашли рецепт, но у нас есть только его начало:
1. Пойти по SCRUM-дороге, у которой нет ни начала ни конца
2. Составить точный план сказочного мира на митинге с Гудвином, Львом и Страшилой
3. Очистить репу от багов…

А окончание похоже найдётся в их приключениях 🪄 Вжуууух, переносим вас в мир, нарисованный дизайнерами Изумрудного города. Магия начинается…

#вопросыбизнеса
В каких случаях проводят аудит качества кода
– рассказывает Ринат, руководитель Mobile-направления

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

▪️ Для анализа качества продукта, если реализует его сторонний подрядчик. Аудит позволит убедиться в качестве реализованных решений.

▪️ При смене подрядчика. Новый подрядчик проводит разные виды аудита, в том числе качества кода, чтобы оценить продукт, в каком состоянии он находится.

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

▪️ Для оценки готовности приложения к масштабированию и другим амбициозным планам по его развитию.

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

❗️ В ходе технического аудита кода не происходит поиск багов и определение их критичности, а только подсвечиваются проблемные зоны и риски в коде проекта.

Что учесть при взаимодействии с клиентом: управляем зарядом батарейки
– рассказывает Андрей, PM

Мы уже писали про то, почему каждому менеджеру важно быть хоть немного психологом. В том посте мы сделали акцент на команду, сегодня – на клиента.

Есть два вида реакции: эмоциональная и рациональная – наши батарейки. Вместе эти реакции ежедневно влияют на коммуникацию, принятие решений и, в конечном итоге, на успех всего проекта. На старте проекта они заряжены на условные 50%: клиент и вы находитесь в нейтральном состоянии, пока не произошло ничего хорошего или не очень.

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

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

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

🪫 Как разряжается рациональная батарейка клиента
Тут всё просто – делать долго, дорого и/или некачественно. В процессе такого «поведения» не избежать нескольких резких рациональных и эмоциональных «разрядок».

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

Чтобы не сходить с ума от штиля – погружаемся в шторм мобильной разработки! Ух, и оседлаем эту волну 🌊

P.S. Без регистрации всё ещё никак) Но благо это быстро.

Давайте поговорим! Открываем чат в комментариях 💁

Возьмём стандартный проект, в состав команды которого входят — проджект-менеджер (PM), тимлид, аналитик, разработчики и QA.

Насколько глубоко должен быть погружен проджект-менеджер в каждую задачу? Должен ли он проверять итоговый результат по каждой задаче или достаточно контроля исполнения по срокам?