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

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

#резюменедели Совпадение недели – попали в 5 рейтингов. Эмоция недели – гордииимся 😏💙 По версии TAdviser мы… 🥉 в тридцатке крупнейших поставщиков IT-услуг 🥈 в двадцатке крупнейших IT-поставщиков в российских банках 🥇 в десятке крупнейших игроков на рынке IT-аутсорсинга hh.ru в одиннадцатый раз провёл исследование и составил рейтинг работодателей. И мы заняли в нём 21 место среди крупных компаний в сегменте «IT и интернет». И в Хабровском рейтинге у нас такие же результаты – 20 место ✌️ Наш директор по качеству Екатерина Ремизова выступила на конференции CNews и поделилась опытом контроля бизнес-процессов: зачем нужна система менеджмента качества, как команда из 4 человек проаудировала за полгода 480 проектов и что им помогает 🦸 Делимся кусочками выступления и ответа на один из вопросов. Ну и как же без фоточек)

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

Чтобы не сходить с ума от штиля – погружаемся в шторм мобильной разработки! Ух, и оседлаем эту волну 🌊 P.S. Без регистрации всё ещё никак) Но благо это быстро.

Что учесть при взаимодействии с клиентом: управляем зарядом батарейки – рассказывает Андрей, PM Мы уже писали про то, почему каждому менеджеру важно быть хоть немного психологом. В том посте мы сделали акцент на команду, сегодня – на клиента. Есть два вида реакции: эмоциональная и рациональная – наши батарейки. Вместе эти реакции ежедневно влияют на коммуникацию, принятие решений и, в конечном итоге, на успех всего проекта. На старте проекта они заряжены на условные 50%: клиент и вы находитесь в нейтральном состоянии, пока не произошло ничего хорошего или не очень. 🔋 Как заряжать эмоциональную батарейку клиента Проявлять заботу в общении с клиентом, понятно и честно доносить информацию об актуальной ситуации на проекте, открыто говорить об ошибках. 🔋 Как заряжать рациональную батарейку клиента Делать так, чтобы задачи решались качественно и в срок, а проблемы – профессионально и быстро. 🪫 Как разражается эмоциональная батарейка клиента Клиент получает информацию о ходе проекта нерегулярно, сама коммуникация нечёткая или менеджеру страшно указать клиенту на нереалистичность требований Даже если с задачами всё по итогу будет хорошо, клиент вряд ли будет готов к новым проектам с таким подрядчиком – при условии выбора из нескольких исполнителей одинакового уровня. 🪫 Как разражается рациональная батарейка клиента Тут всё просто – делать долго, дорого и/или некачественно. В процессе такого «поведения» не избежать нескольких резких рациональных и эмоциональных «разрядок». Восстанавливать отношения с клиентом после такого необходимо сначала с эмоциональной стороны (признание ошибки — управление ожиданиями), а уже после с рациональной стороны (разбор причин — рассказ о выводах — выполнение обещанного).

#вопросыбизнеса В каких случаях проводят аудит качества кода – рассказывает Ринат, руководитель Mobile-направления Напомню, что технический аудит качества кода – это анализ кодовой базы и разработка предложений, как можно её улучшить. Расскажу, когда и для каких целей проводят аудит. ▪️ Для анализа качества продукта, если реализует его сторонний подрядчик. Аудит позволит убедиться в качестве реализованных решений. ▪️ При смене подрядчика. Новый подрядчик проводит разные виды аудита, в том числе качества кода, чтобы оценить продукт, в каком состоянии он находится. ▪️ Есть вопросы к работе текущей команды проекта: много багов, «вечный» рефакторинг и т.д. Аудит поможет понять, какие проблемы есть в приложении и расставить приоритеты для их исправления. Исследование причин ошибок – это отдельный аудит. ▪️ Для оценки готовности приложения к масштабированию и другим амбициозным планам по его развитию. ▪️ Для определения ключевых точек роста проекта и конкретных шагов для их реализации. Предположим, на вашем внутреннем проекте работает небольшая команда или всего один разработчик – другие специалисты заняты своими проектами. Аудит поможет посмотреть на код незамыленным глазом и подсказать, оптимальны ли выбранные технические решения, какие риски есть и как их можно избежать. ❗️ В ходе технического аудита кода не происходит поиск багов и определение их критичности, а только подсвечиваются проблемные зоны и риски в коде проекта.

#резюменедели Китайский Новый год, друзья! Окунаемся в сказочную атмосферу ✨ Что делать, когда Кощей похитил Новый год, потому что не успел сдать проект? 🦹🏻‍♂️ Вместе с детьми наших IT-специалистов нашли рецепт, но у нас есть только его начало: 1. Пойти по SCRUM-дороге, у которой нет ни начала ни конца 2. Составить точный план сказочного мира на митинге с Гудвином, Львом и Страшилой 3. Очистить репу от багов… А окончание похоже найдётся в их приключениях 🪄 Вжуууух, переносим вас в мир, нарисованный дизайнерами Изумрудного города. Магия начинается…

Неполное описание задачи в таск‑трекере? – Не надо так 😶 – рассказывает Екатерина, руководитель QA-направления Часто на проектах задача сначала обсуждается между руководителем разработки и системным аналитиком верхнеуровнево: что именно делать и в каком виде. Автор при переносе такой задачи в таск-трекер может решить, что подробно заполнять поля уже не нужно. Ведь фича уже описана в базе знаний 🙄 Что делать, если такое иногда происходит в команде 1. Напомните команде, чем это может грозить ▪️ Разработчикам и QA-специалистам потребуется больше времени, когда они будут брать фичу в работу. Сначала специалист пойдёт изучать требования в базе знаний, потом уточнять их у коллег, процесс затянется, при доработках снова придётся вспоминать, о чём вообще это всё было. ▪️ Больше вероятности, что задача, вернётся на доработку. Если у задачи отсутствует подробное описание с требованиями, то разработчик может не понять, чего именно от него ждут. Поэтому задача, скорее всего, вернётся на доработку, а того, кто её ставил, попросят уточнить техническое задание. 2. Обсудите единый вариант оформления При создании задач основные пункты описания: ▪️ Понятное название задачи ▪️ Требования к функциональности и производительности продукта или системы, которые необходимо реализовать ▪️ Ссылки на дизайн-макеты, описание архитектуры, включая структуру, компоненты и взаимодействие между ними ▪️ Требования к тестированию и контролю качества, включая критерии приёмки Точный перечень будет зависеть от специфики проекта – обсудите его внутри своей команды и придите к единому удобному шаблону оформления.

Специфика зарубежных проектов На иностранных продуктах мы замечаем закономерности в подходах к работе. Решили поделиться ими в посте) 1. Отлаженный процесс онбординга Каждый сотрудник получает план на первые месяцы работы: какие доступы настроить, в какие задачи погрузиться. Помимо этого, к новичку приставлен buddy – сотрудник из той же команды, который знакомит с коллегами, помогает погрузиться в продукт и предстоящие задачи. 2. Метод кнута и пряника недопустим, во всём приветствуется гибкость Во время code review специалисты стараются не «тыкать»: «ты сделал неправильно»,, «ты не учел». Вместо этого используется подход с позиции «мы»: «у нас возникла проблема», «не хотим ли мы это поменять». Вместе с высокими требованиями к hard-скиллам здесь есть принятие того, что человек может ошибиться. Сложно представить ситуацию, при которой члена команды отчитали бы за промах публично. 3. На первом месте качество Как и на любом IT-проекте, клиенту важно укладываться в дедлайны. Однако если команда по объективным причинам не успевает в срок, руководство не будет форсировать события, ведь в приоритете – качество продукта. Задачу вынесут в следующий релиз, чтобы пользователь не получил сырой продукт. Когда менеджер хочет как можно быстрее выложить фикс бага, он говорит об этом заранее, и команда укладывается в срок без необходимости работать сверхурочно. 4. К слову о переработках: их, как и само явление трудоголизма, компания не приветствует Сотрудника, пришедшего на рабочий созвон в свой выходной, ненавязчиво отправят отдыхать. Здесь ценят не только работу, но и отдых, и чётко следуют идее work-life balance – лучшей защите от эмоционального выгорания. 5. Гибкие требования к продукту и результату Как правило, в российских компаниях принято ставить чёткое ТЗ с частично прописанными условиями реализации. На иностранных проектах чаще видим фокус на бизнес-идее. Специалистам предоставляется свобода выбора пути решения, поощряется инициативность. Такое смягчение требований объясняется просто: разработчик может сделать не так, как требует менеджмент, а намного лучше. 6. Высокий уровень лояльности руководства опирается на не менее высокие требования, и в первую очередь – к soft-скиллам сотрудников На проектах российских заказчиков мы привыкли к жёстким оценкам, в том числе сроков выполнения задачи. На иностранных более лояльны к срокам, но цена этого – автономность работы. Конечно, если специалист обратится за помощью, никто не откажет, но здесь ждут, что специалист разберётся в задаче сам, не отрывая от работы коллег.. Какие трудности приходится преодолевать чаще всего ▪️ Самое очевидное – языковой барьер. Работа в интернациональной команде предполагает свободное общение на иностранном языке: все общие созвоны и митапы проходят на английском, а специфика продукта обязывает также владеть и технической лексикой. ▪️ Гарантировать взаимозаменяемость в командах. На проекте нет чёткого разделения ролей. Если специалисту по силам справиться с задачей другого направления, к нему могут обратиться за помощью. Фронтенд-разработчика могут подключить к задачам бэкэнда. Да и автотесты часто также выполняют разработчики. ▪️ Выстраивание графика работы в разных часовых поясах. Стандартный кейс из жизни интернациональной команды: все сотрудники находятся в разных временных зонах, приходится соотносить время митингов и корректировать свой рабочий день.

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

#резюменедели Суббота у нас сегодня читательская) В статье для it world рассказали, как технологии ИИ используются в процессах разработки. Вы знали, что разработка с применением ИИ-инструментов на разных стадиях жизненного цикла ПО к 2028 году может достигнуть 75%? 🤯 С ComNews поделились мыслями об импортозамещении: ▪️ Первая российская АБС мигрировала на импортонезависимые СУБД ▪️ Что мешает провести импортозамещение вовремя. Считаем, что заменить иностранное ПО полностью до 1 января 2025 года – это амбициозно. Чтобы сделать это, надо: 1. обеспечить достаточное количество качественного российского ПО 2. подготовить кадры для работы с ним 3. обучить конечных пользователей В кейсе – как усилили команду Zetra на проекте микросервиса веб-приложения для экстренных служб 👩‍🚒 Среди вызовов – сложная архитектура, состоящая из 50 микросервисов, отсутствие детализации ТЗ и сжатые сроки)

SMART и делегирование в работе руководителя – рассказывает Ирина, руководитель отдела QA Когда растишь отдел, очень хочется работать с профессионалами, которым можешь доверять: поставить задачу – и быть уверенным, что она будет сделана. Чтобы было именно так – важно вкладываться в своих сотрудников с самого начала: 1. делегировать, 2. ставить задачи по SMART, 3. расставлять приоритеты между ними (и объяснять, почему именно так и не иначе). Понятно, что сразу новичкам делегировать не будешь – с ними надо обязательно тщательно проговаривать второй и третий пункты. Именно чёткость и понятность в постановке задач позволяют со временем перейти к делегированию. → Ставишь задачу, назначаешь ответственного, ограничиваешь во времени, обозначаешь точки контроля И можно не называть это SMART’ом, но это будет он, пусть и в супер-лайтовом виде) Почему это важно Для личных дел и вопросов детали можно не расписывать: ты понимаешь, что имеешь в виду. Но когда ставишь задачи кому-то другому, должно быть полное совпадение твоих ожиданий и ожиданий специалиста. SMART – это не про микроменеджмент, это про прозрачность и однозначность. Получается, если каждый привыкнет работать в парадигме SMART, то информация будет восприниматься всегда в верном ключе. Конкретика будет привычкой, и сломанного телефона не случится) Так что, если вы прививаете этот навык сотрудникам с первого дня, потом спокойно сможете поручать им задачи различного уровня сложности. Если какой-то информации им не хватит – они сами первые сообщат вам об этом 🙌

Мы это всё к чему? 👆 – В наших пользовательских руках всё больше смартфона. И по количеству, и по времени, между прочим. И ещё недавно разработка приложений для этих самых смартфонов была стабильной и понятной. Но оказалось, не только жизнь общажная полна сюрпризов :) Так давайте 29 февраля обсудим этот вопрос! А именно: ▪️ актуальную ситуацию на рынке разработки мобильных приложений ▪️ современные решения в создании мобильных сервисов и тренды в поведении пользователей ▪️ опыт и кейсы бизнеса по преодолению блокировок и ограничений ▪️ состав идеальной команды разработки мобильного приложения ▪️ инхаус, аутсорс или аутстафф в мобильных проектах: что выгоднее бизнесу и при каких условиях – Чем же всё это окончится? – Будет апрель март. – Будет март, вы уверены? – Да, я уверен. А ещё: запись нашей с вами встречи и памятка с актуальными способами создания мобильных решений для бизнеса (по каждому будут указаны особенности, плюсы и минусы). Ну какова красота! Регистрация тут: https://s.simbirsoft.com/NKc6 P.S. Админ собрал отсылки для всех возрастов, 😎 – если понял все три. А остальным солнышко придётся ставить, а то как же солнечные очки без солнца)

Как определять тип восприятия клиента Так как «чистых» типов крайне мало, для определения в большинстве случае потребуется время и уже проведённые совместные встречи. В целом, могут помочь и фразы, которые мы описали в основном посте для презентации) 👆 Визуал. Когда клиент объясняет команде свою идею, он сразу показывает свой экран и рисует её в миро блоками. Когда слушает описание задачи, просит пошарить ваш экран и дополнительно сам читает. Ему легче воспринимать информацию с видео, когда он слушает, он явно смотрит на экран. В презентациях обязательно просит инфографики, диаграммы. Если вы обсуждаете что-то неформальное – также можно «выцепить» информацию. Например, о новой куртке он скажет, что она красивая (цвет, дизайн и т.п.), в новом фильме обращает внимание на монтаж, цветокоррекцию, фоновые предметы. Аудиал. Все инфографики, схемы просит озвучивать. Он часто просит прочитать текст вслух: описание задачи, слоган, инструкцию. Вы видите, что человек не смотрит на экран, но при этом отлично воспринимает информацию. Ему легче созвониться и обсудить вопрос, чем вести переписку. Возможно, рассуждает вслух, когда думает над задачей. Неформальный контекст – делится, что ему отлично заходят аудиокниги и подкасты. Хорошо запоминает тексты песен. Дигитал. В инфографиках не обратит внимание на стиль, а скажет «как логично расположены блоки» или «нужно бы добавить связи между объектами». Он просит чёткий протокол встречи с результатами. Сам легко подбивает документы или предлагает, как сделать формулировку конкретной, без лишних толкований. Важен не только итог, но и его подробное обоснование – это не зависит от доверия к сотруднику. Из неформального – если он играет, то ему нравятся стратегии. Говоря о покупке, он опишет её функциональность: количество карманов, «подходящесть» для разных сезонов и погоды. Кинестетик. Записывает для себя по ходу встречи. В процессе мозгоштурма может вставать с места и ходить. На презентации важно самому иметь устройство с продуктом – чтобы «руками» следовать за спикером. Он часто вертит что-то в руках, может лопать пупырку и рисовать во время встреч. Из неформального – может предпочитать личные дела вести письменно: планы, бюджет. О свитере или рубашке расскажет, какие они наощупь. Больше всего нравятся выставки, где разрешили трогать и крутить. Из поездки вспоминает много тактильных впечатлений: фрукт был пушистым, а в здании были гладкие камни, в кафе – ласковый кот)

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

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

#вопросыбизнеса Как происходят утечки и что делать, если это произошло – рассказывает Максим, 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)

#резюменедели Wadline назвал нас среди лучших разработчиков ПО 2023, а ещё – среди тех компаний, которым можно доверять. Ну а кто мы такие, чтобы не соглашаться? 😅 Вот и соответствуем :) Клиент отзыв нам прислал. Пишет, что с нами легко и надёжно 😇 Наш директор по качеству Екатерина Ремизова – на Доске почёта «Лучшие люди Ульяновской области»! Наши коллеги вообще часто удостаиваются высоких наград. Например, в прошлом году одним из лучших людей региона стал соучредитель компании, Backend-разработчик Алексей Колесников😎 А на десерт – публикации в СМИ) ▪️ Дали комментарии о рынке IT-аутстаффинга для ComNews: В России востребован аутстаффинг ▪️ Поделились опытом с TProger: Как стать тестировщиком в 2024 году: что происходит на рынке и что учить

🌚 5 вредных советов для общения с клиентом Предлагаем вам немного отвлечься от рабочих задачек и прочитать наши «советы» (нет) для общения с клиентом. Мы собрали их на основе разных книг про успешный успех, мнений с форумов в интернете и рассказов тёти Вали из соседнего подъезда. Мы тут представляем IT-мир наоборот – в нём всё другое, включая законы физики, поэтому имейте в виду, применять эти «советы» на практике опасно для вашей карьеры! 1. Сразу покажите, кто тут самый главный эксперт 😎 Вместо стандартного приветствия, начните разговор на английском – клиент должен видеть, какой умный менеджер ему достался. А затем в разговоре вверните все профессиональные термины, которые знаете – тогда не останется никаких сомнений, что перед ним REAL эксперт. 2. Никогда не сдавайтесь 💪 Клиент не соглашается с предложенным вами решением? Настаивайте, уговаривайте, бесконечно аргументируйте, напоминайте о себе через каждые 30 минут. Звонить ночью (и на выходных ) тоже можно – так вы покажете свою вовлечённость! Помните, настойчивость ломает все барьеры. Только вперёд, вы справитесь! 3. Присоединяйтесь к проблеме 🫂 Когда клиент обсуждает сложности на вашем проекте, важно разделить с ним печаль. Ответьте, что вы понимаете, как это расстраивает – у вас была похожая ситуация, но вы справились, значит, и он тоже сможет. Реально решать проблему разумеется не нужно, перечитайте пункт 2 – вы что, уже забыли??? 4. Всегда широко улыбайтесь 😁 Вне зависимости от того, что обсуждает с вами клиент: приятные новости, серьёзный вопрос или сложности на проекте – улыбайтесь. Не беда, если улыбка натянутая и с непривычки дёргается глаз. Главное, что вы покажете свою лояльность и расположенность. 5. Копируйте движения 👯 Как пишут умные статьи, людям нравятся те, кто на них похож. Используйте это знание по максимуму. Клиент сменил позу – сделайте также. Потянулся за стаканом воды – повторите. Почесал нос? Вы знаете, что делать – срочно копируйте. Так вы точно понравитесь и проект будет ваш. Это, конечно, шутки, чтобы поднять вам настроение) Надеемся, никто не встречал коллег из этого поста)🤞🏻