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

#вопросыбизнеса Миграция БД: переезд с Oracle на PostgreSQL Контекст К нам обратилась госкомпания, которая использовала Oracle. В марте 2022 года вендор покинул российский рынок, и с тех пор пользователи СУБД столкнулись с рядом рисков: ▪️ сохранения безопасности данных; ▪️ отсутствия обновлений и техподдержки от вендора. Это подтолкнуло клиента искать аналог, который заменит продукт по функциональности. Наша задача на этом проекте – подготовка миграции большей части логики БД со всеми данными, адаптация кода приложения и реализация возможности тестировать результат переноса. Ищем аналог Oracle PostgreSQL оказался оптимальной альтернативой. У системы есть ряд неоспоримых преимуществ: ▪️ Открытый исходный код. Большое комьюнити разработчиков выступает в качестве вендора и поддерживает ПО в актуальном состоянии. Это делает решения на его основе достойным вариантом для импортозамещения. ▪️ Общие расходы, как правило, меньше, чем на Oracle (но зависят от кейса). ▪️ Достаточная функциональность, гибкость, масштабируемость. Именно эти плюсы привлекли внимание клиента к системе. Для заказчика PostgreSQL стала достойной заменой импортному ПО. Огромным плюсом было то, что клиент мог периодически останавливать работу системы в продакшне для переезда БД. Это помогло сократить действия при подготовке и непосредственной миграции данных и тем самым уменьшить риск ошибок в процессе. Переезжаем Нельзя сказать, что процесс переноса оказался простым: мы столкнулись с разными сложностями при подготовке переноса и проверке целостности данных. Специалисты проделали глобальную работу по исследованию и исправлению устаревшего легаси-кода: исправляли запросы (в основном, мелкие отличия, экранирование, замену специфичных для исходной системы функций и синтаксических конструкций), проверяли, сравнивая результаты и скорость работы с Oracle, иногда оптимизировали запросы, рефакторили устаревший код. В общем, приводили приложение в соответствие с новыми требованиями. Наш вывод На подобном проекте важен опыт разработчиков: специалисты должны глубоко разбираться в обеих системах и подбирать подход с необходимыми инструментами для успешной миграции СУБД. Если хотите почитать о реализации этого проекта подробнее, то вам сюда 🫵🌝

#резюменедели Получили награды 🏆 Вошли в рейтинг крупнейших разработчиков мобильных приложений для бизнеса и госсектора 😏 Дали комментарии СМИ и выпустили статьи 📰 Статьи: ▪️ Хабр: Делаем ML-проект с нуля: на что обратить внимание управленцу ▪️ в нашем блоге: Как мы автоматизировали процесс согласования документов с помощью 1С Комментарии: ▪️ Обзор TAdviser: Мобильные приложения для бизнеса и госсектора Выступили на мероприятии и провели своё 🗣 ▪️ Выступили на конференции по системному и бизнес-анализу Flow 2023: подготовили доклад «Повышение точности оценки этапа аналитики» 💬 ▪️ Провели Backend MeetUP | AI & Computer Vision в Казани: рассмотрели кейсы продвинутого применения ИИ в разработке а также обсудили секреты хорошего питчинга 🤗 P.S. А ещё смотрите, какой красивый стенд у нас был на международной IT-конференции «Стачка» 😍

Почему глубина планирования проекта важна – рассказывает Сергей Гордеев, руководитель проектного офиса Что можно сделать, чтобы снизить неопределённость, излишнее напряжение в команде? – Тщательно распланировать проект и разделить его на уровни: ▪️ крупные вехи, ▪️ итерации, ▪️ логические блоки, ▪️ версии или спринты. Такое деление важно соблюдать, даже если проект лёгкий или короткий. В идеальном мире планирование должно быть до уровня отдельных задач. Так все участники разработки будут понимать сроки и критерии готовности. Что даёт глубина планирования 🔹 Для заказчика – чёткое представление: что команда реализует в каждый отрезок времени и какую ценность вносит в развитие продукта. 🔹 Для обеих сторон – прозрачность работ и определённую цель для каждого этапа. Важно закладывать запас времени, особенно если продукт изменчив – у вас всегда будет люфт для реализации важной фичи или устранения блокирующего фактора.

Подборка книг – команде разработки – рассказывает Алексей, backend-разработчик, архитектор В IT я больше 10 лет и прошёл путь от джуниора до сертифицированного архитектора. Я не открою вам Америку своим набором, но каждая книга в нём подтверждена проектным опытом – я расскажу, когда эти книги пригождаются и почему. 1. Продать=помочь, Андрей Майборода Почему я начал с продающей книги? – Рассказываю историю. На проекте в соседней команде должны были реализовать фичу: она закрывала довольно редкий, но при этом очень неприятный баг. Я знал, что разработчики сделали это, и был спокоен. Потом произошёл инцидент на боевом сервере как раз из-за этого бага, я быстро его поправил и пошёл к команде: – Где фикс, его вроде бы уже делали? – Мы уже три недели пытаемся включить в релиз, но пока не получается – у заказчика различные возражения. Я сделал презентацию для заказчика, зачем нужен этот фикс – и за 15 минут получил решение задеплоить его на прод вне очереди. Я просто знал, как «продать» фичу, и понимал систему ценностей заказчика. Так что любой, кто работает с клиентом, должен обладать базовыми навыками продаж. 2. Кайдзен: ключ к успеху японских компаний, Масааки Имаи Первая идея, чтобы стать сертифицированным архитектором, у меня появилась где-то 18 лет назад. К этой цели я дошёл не за один вечер. Кайдзен как подход к жизни и учит постоянно развиваться и не стесняться мелких шагов. Кроме того, эта методология заставляет акцентировать внимание на вспомогательных бизнес-процессах. Например, я изучал: как работать на саппорте, как работать с БД, как делать аналитику, как продавать себя и т.д. Со временем это срослось в один большой и мощный клубок и подтолкнуло меня к сертификации. Повторюсь, это был длительный путь, а Кайдзен – это как раз система улучшений шаг за шагом. Я считаю, что её всем нужно применять и не мучиться :) 3. Мифический человеко-месяц, или Как создаются программные системы, Фредерик Брукс Команда – это не только набор скиллов каждого участника, это ещё и набор коммуникаций и других побочных вещей, о которых часто не задумываются. Часто к тимлиду могут прийти с подобной фразой: – Слушай, давай мы тебе дадим два дополнительных человека, но зато мы реализуем фичу не за шесть недель, а выкатим на прод за три. Если у вас добавилось два человека, у вас будет притирка команды, выстраивание коммуникационных взаимодействий, будет погружение в проект. К этому надо быть готовым всем членам команды. Чтобы понимать подобные аспекты в разработке и быть профессиональным командным игроком, и нужна эта книга. Кстати в ней прозвучала знаменитая фраза: «Многое изменилось в мире, но девять женщин всё так же не могут выносить ребенка за один месяц». Позже мы выпустим ещё две части этой серии :)

#резюменедели Выступили на мероприятиях 🗣 ▪️ Современные производственные предприятия – это сложные системы, в которых ежедневно протекают различные технологические процессы. Как взять их под контроль – рассказали на GP Days. ▪️ Поучаствовали в IT-форуме РУССОФТ, рассказали о важном – экспертизе сотрудников и о том, как её растить внутри компании. Дали комментарии СМИ 📰 ▪️ Деловой Петербург: Летом в Петербурге чаще всего запускали бизнес в стройке, торговле и общепите ▪️ IT Manager: Рынок разработки мобильного ПО: на пути к суверенитету ▪️ Федеральный Бизнес-журнал: Российские ИТ-компании сделали мощный рывок в развитии и рекордно увеличили прибыль ▪️ ComNews: Строгость EULA компенсируется сложностью доказать нарушения ▪️ Известия: Очищение имени: в Госдуме готовят закон об удалении персональных данных ▪️ Комменсантъ: Банкирам софт не дописан

История про Capacity команды: как нам помог этот показатель – рассказывает Светлана, PM Контекст 5+ лет мы развиваем приложение для работы с товарами, проект растёт – на прод поставляются новые фичи. Мы ежемесячно не успевали выполнять 100% из запланированного пула. «Как так получилось, что мы опять одну фичу не допилили?» Так мы и пришли к капасити. Капасити (capacity) – показатель максимальной ёмкости чего-либо. Например, в IT капасити можно применить в контексте ресурсов: штат, техника и т.д. Внедряем 🔹 Подсчёты Для подсчета капасити мы ориентируемся не на 8, а на 6 часов: 2 часа закладываем на допустимые риски. По нашему опыту, у сотрудника уровня Middle+/Senior с опытом работы 3–5 лет отдача по проекту будет на уровне 100% (1). Все остальные специалисты уступают по процентовке, но в нашей команде были специалисты только с высоким грейдом. Также важно не забыть ограничения в работе, в которые входят отпускные и больничные дни. Например, у нас в команде 2 аналитика: Lead и Middle+. Их капасити для спринта (10 дней): (Lead+Middle+)*количество рабочих дней=(0.7+1)*10=17 Оценивая загрузку с помощью капасити в человеко-днях, можно оценить любую команду на любой срок. Мы можем понять, в каком направлении и насколько у нас недостаточная загрузка по команде, и рассмотреть варианты перекинуть специалиста в другую команду или добавить в бэклог спринта ещё одну фичу. Фичи приходят на оценку тоже в человеко-днях. 🔹 Результаты ▪️ Производительность команды стабильна и составляет свыше 90% от плана работ на спринт. ▪️ С учётом ограничений мы формируем полноценную загрузку команды по всем направлениям, к минимуму сводим простой сотрудников в спринте. ▪️ Внедрение капасити добавило дополнительную ценность для заказчика в виде прозрачности загрузки. В нашем случае весь процесс внедрения занял 4 месяца. На это повлияло в большей степени то, что спринт на проекте длится в течение одного месяца, в команде около 20 человек: по 3–4 человека от каждого направления. Для небольших команд – например, по 10 специалистов – для внедрения этого подхода будет достаточно и 1–2 спринтов, продолжительностью 2 недели. Это позволит понять, насколько он удовлетворяет потребности и что стоит в нём изменить. Ограничения 1. Мы измеряем всё человеко-днями и в оценке фич, и в подсчете капасити. Если мы измеряем объёмы работы разными переменными, то свести их воедино будет проблематично – каждая будет жить своей жизнью. 2. Капасити – величина динамическая. Мы должны работать с верными и точными данными на проекте. Если все-таки кто-то уходит на больничный или в отпуск, то капасити пересчитывается. Благодаря этому мы формируем правильные ожидания у заказчика. 3. В подсчёте капасити учтены созвоны по фичам, активности лидов, но не учтены багофикс, техдолги и прочее. Исходя из особенностей проекта, его срока жизни, количество необходимых фиксов и задач техдолга может варьироваться от нескольких десятков до нескольких сотен.

Разрабатывать новое, используя накопленный опыт После реализации каждого проекта мы проводим ретроспективу: ▪️ обсуждаем полученный опыт, удачные идеи, которые можно использовать для разработки других подобных IT-систем; ▪️ вносим изменения в процессы, чтобы в будущем избежать совершённых ошибок. Таким образом у нас формируется актуальная база знаний, куда могут зайти сотрудники и посмотреть, какой проект реализовывали и что получили в итоге (с соблюдением NDA). Также у нас есть база знаний по технологиям. У SimbirSoft, естественно, есть свои наработки – удачные технические решения, которые мы стараемся переиспользовать, если такая возможность есть. Это позволяет снизить трудозатраты на реализацию проекта, а значит, и сэкономить деньги клиента. Условно: специалист мог бы потратить неделю на продумывание архитектуры, а вместо этого использует наработки и делает всё за день.

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

#вопросыбизнеса Как разобраться в ассортименте отечественного ПО и не ошибиться с выбором – рассказывает Дмитрий Петерсон, операционный директор На прошлой неделе мы писали, что переход с иностранного софта на отечественные готовые решения не всегда быстрый и бесшовный. Когда компания годами работала в одной системе и наладила бизнес-процессы, трудно в одночасье сменить рельсы. Разбираемся – как понять, что выбранное ПО имеет место и перспективы в вашей компании. На что обратить внимание 🔹 Продукт вендора соответствует целям и задачам компании Наилучший вариант, когда софт не имеет избыточной функциональности, но и дорабатывать его слишком долго не приходится. При выборе полезно описать бизнес-процесс, для которого приобретаете продукт. Это может быть техническое задание или отдельные user stories по взаимодействию пользователей с IT-системой. Это поможет подобрать оптимальное решение. Наличие демоверсии – определённо преимущество. Можно познакомиться с возможностями продукта и сравнить с вашими целевыми требованиями. 🔹 Процесс внедрения и поддержки продукта прозрачный и удобный Особенно стоит обратить внимание на срок внедрения и наличие техподдержки. Первое обычно можно узнать в интернете, а вот о качестве внедрения и поддержки резоннее узнать у клиентов. Что скажет о том, что вы попали в надёжные руки: ▪️ наличие прозрачной поддержки: быстрый приём обращений и обработка инцидентов в случае их наличия; ▪️ наличие открытой площадки, на которой клиенту видна вся работа по заявке, прежде всего статус и сроки её исполнения. С помощью чего анализировать 🔹 Техническое интервью с вендором Уровень экспертизы разработчиков продукта можно определить, пообщавшись с техническими специалистами поставщика софта. Берите на такую встречу своих опытных разработчиков, чтобы вместе с ними узнать, как решаются инциденты, как проходит кастомизация уже во время эксплуатации продукта, какие текущие возможности софта и т.д. 🔹 Участие в рейтингах Это стандартная история для поиска исполнителей в IT. Перед попаданием в рейтинги поставщики софта, например, проходят проверку экспертизы компании, часто клиенты принимают участие в распределении мест. Так что анализ рейтингов поможет составить представление об игроках рынка. 🔹 Репутация и открытость компании Описание продуктов, кейсы, список клиентов – информации о надёжном вендоре много и её легко найти. Как бонус – если вы увидите среди клиентов ваших конкурентов, значит, вендор уже знаком со спецификой вашей отрасли и бизнес-процессов. Ему легче будет понять и выполнить ваши требования.

#резюменедели Получили награды 🏆 Мы среди 50 крупнейших ИТ-поставщиков в ритейле 🛍 Полный список компаний тут, а здесь можно посмотреть некоторые из наших ритейл-проектов :) Дали комментарии СМИ и выпустили статьи 📰 Комментарии: ▪️ Известия: Спортивный ИИнтерес: как нейросети помогают атлетам ▪️ IT Channel News: Отечественное ПО для коммерческих заказчиков: на что и как переходить? Статьи: ▪️ AppTractor: Фишки React Native для реализации личного кабинета ▪️ Skillbox Media: 6 ошибок при постановке задач в IT-проектах ▪️ в нашем блоге: Разработка информационной системы и зрелость бизнес-процессов: выбираем решение ▪️ в нашем блоге: Аутсорсинг VS Аутстаффинг в заказной разработке Провели мероприятие 🗣 Обсудили с комьюнити Java-разработку и IT-архитектуру на Backend MeetUP в Самаре – два доклада и открытый микрофон после них 🔥

Приёмка продукта от другого подрядчика – рассказывает Даниил, PM Контекст В прошлом году мы принимали сайт, разработанный event-агентством. С помощью своего конструктора сайтов компания создавала простые сайты и лендинги. Однако клиенту понадобилось разработать обучающую платформу – ресурсов конструктора не хватало, и пользователи жаловались на баги. Так проект перешел к нам – нужно было его спасти и помочь в дальнейшем развитии. Что усвоили 🔹 Требуй артефакты по максимуму и ставь дедлайны Когда мы принимали работу, много времени ушло на то, чтобы предыдущий подрядчик предоставил нам доступы к стендам, написал инструкции, как пользоваться админкой. Здесь необходимо чётко договариваться о дедлайнах. 🔹 Сохраняй контакты Мы не прекратили общение с предыдущим подрядчиком и сохранили контакт с его техническими специалистами. Первые пару недель у нас возникали вопросы по части админки. 🔹 Демонстрируй свою работу Когда защищаешь свой «новый» проект перед клиентом, важно показать ценность выполняемой работы. Мы проводили демо на каждом этапе исправлений: согласовали на неделю определённый скоуп задач, по итогам созванивались и показывали, что у нас получилось. Важно было работать с ожиданиями клиента и доносить ценность результата – ведь - ведь он нам доверился и ожидал помощи. 🔹 «Продавай» идею и ценность приёмочного тестирования С внешней дизайнерской стороны могут быть видны не все функциональные особенности. Поэтому мы начали с дизайн-аудита, но по ходу убедили клиента, что при таких жалобах пользователей необходим не только косметический ремонт. Так к дизайн-аудиту добавили приёмочное тестирование. Тут стоит добавить цифры: ▪️ в процессе дизайн-аудита выявили около 1000 UX\UI-правок, ▪️ в процессе приёмочного тестирования завели около 200 багов. Это дало нам то, что клиент был доволен уже на этапе отчётов, чувствовалось, как он успокоился. Он удостоверился, что мы смотрим в одну сторону. Объединяющая мысль этих пунктов – когда-нибудь предыдущий исполнитель уйдёт совсем и вы останетесь один на один с клиентом и продуктом. Чтобы максимально снизить рисковость этого момента – нужно создавать себе подушку безопасности. А у вас были подобные ситуации? Как всё прошло?

Зачем команде разработки знать, что завтра презентация продукта инвестору? 🤷‍♂️

#вопросыбизнеса Почему российский бизнес продолжает работать с иностранным софтом Анна, руководитель направления бизнес-решений Бизнес продолжает работать с иностранным ПО, потому что оно так или иначе все ещё доступно. За год бизнес нашёл разные способы обойти ограничения: vpn, приобретение/продление лицензии через зарубежные юрлица и прочее. Ведь иностранный софт развивался много лет, он конкурентоспособен и ориентирован на клиента в плане своей функциональности и юзабилити.   Кажется, что сегодня на российском рынке достаточно аналогов. А в реальности мы видим такие варианты: 1. Клиенту приходится дорабатывать и/или комбинировать импортозамещающие системы под себя; 2. Клиенту нужно менять свои бизнес-процессы и подстраиваться под то, что есть. Для быстрого внедрения придётся использовать готовое решение. Если адаптировать под себя – потребуется дополнительные время и деньги. Есть третий вариант – разработка с нуля, российские IT-компании имеют достаточно опыта и компетенций, чтобы создать бизнесу то, что ему нужно. Но на это опять потребуются ресурсы – время и значительные финансовые вложения.

Как не впадать в крайности контроля при работе с командой — рассказывает Екатерина, PM На мой взгляд, для управления проектом не подходит как вариант с микроменеджментом и тотальным надзором, так и полное расслабление и вседозволенность. Первый снижает лояльность к компании и мотивацию сотрудников, а второй часто приводит к тому, что вы не управляете ситуацией и сроками. В начале своей карьеры я набила несколько «шишек». Зато поняла, что гораздо комфортнее и команде, и мне, когда выстроен баланс между контролем и доверием. Как это работает у меня: 1️⃣ С командой мы проговариваем: ▪️ цели проекта, ▪️ условия реализации, ▪️ требования клиента, ▪️ сроки, ▪️ ценность продукта. А также обсуждаем, как каждый специалист влияет на достижение поставленных задач. Таким образом все знают, что от их действий напрямую зависит конечный результат. 2️⃣ Затем мы выстраиваем план задач и ставим контрольные точки. Специалисты сами оценивают свои задачи и говорят, сколько времени им нужно для работы. 3️⃣ Каждый сотрудник чётко знает границы ответственности как свои, так и коллег. 4️⃣ Ко всем нужен индивидуальный подход, и моя задача — знать не только компетенции специалистов, но и их личные качества. Например, я знаю, что Сергей всё выполняет вовремя, но не любит лишнее общение и может растеряться, если его торопить. Ему не нужен дополнительный контроль, достаточно просто спрашивать про статусы на дейли. 5️⃣ Важно показать, что ошибки — это не страшно. Все их совершают, главное — выявить причину произошедшего, вовремя исправить и поделиться опытом с командой. 6️⃣ Мы общаемся не только по рабочим вопросам. Например, у нас есть чат, где можно переключиться и спросить у коллег какой-то личный совет, поделиться переживаниями или вместе над чем-то посмеяться. Главное донести до сотрудников и не забыть самому — мы не на разных сторонах баррикад, мы одна команда. Руководитель проекта должен выстроить комфортные условия и быть «своим» — к нему к первому должны идти с любыми вопросами и проблемами.

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

#резюменедели 🏆 Вошли в рейтинг крупнейших ИТ-поставщиков для ритейла Поделились со СМИ 📰 своим мнением по разработке системы, позволяющей предиктивно анализировать потребности рынка труда. А еще обсудили перевод инфраструктуры с сервисов Microsoft. Выпустили первую и вторую часть дневника разработки по проекту РОСТ (Карьера.онлайн) 🔏 Ну и на сладкое — рассказали, как гостили у @severstal 🥰

Мы к вам с ответами ✌️ Вариант А – в рамках договора и перед законом вы правы. Однако вряд ли клиент продолжит сотрудничество с подрядчиком, который не слышит его проблему. Кто знает, возможно, ситуация изменилась настолько, что продукт без правок и к другой дате клиенту больше не нужен. Вариант B не про продуктивную команду, которая качественно выполняет свои задачи. У специалистов должен быть нормальный рабочий график и время на отдых. Выгорание никого не щадит — даже при дополнительной оплате. Вариант С мы считаем самым оптимальным. Клиенту важно внести новые фичи до релиза и выпустить продукт раньше, а команда должна качественно всё реализовать – чтобы этого добиться, нам нужно больше ресурсов.

Задачка для менеджеров Команда вашего проекта состоит из backend- и frontend-разработчиков, аналитика, QA, дизайнера, тимлида (вас) и продакт-менеджера. При подготовке к релизу внезапно изменились требования и сдвинулись сроки – дата релиза стала гораздо ближе. Клиент готов подписать приложение к договору, в котором будут отражены все изменения. С комментариями вернёмся завтра 🤗

#резюменедели Дали комментарии СМИ 📰 РБК: Microsoft перестанет продлевать подписки корпоративным клиентам из России Рассказали о проекте 🔏 MVP мобильного приложения для международного маркетплейса Провели мероприятие и анонсировали новые 🗣 ▪️ Провели A warm Backend Meetup в Краснодаре. Поговорили об особенностях искусственного интеллекта и разработки моделей, а также о DWH и Data Lake ▪️ 26 августа проведём Backend Meetup в Самаре, а 9 сентября в Казани ▪️ Стартуем 27 сентября SDET-практикум