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

Выступили на мероприятиях 🗣
▪️ Современные производственные предприятия – это сложные системы, в которых ежедневно протекают различные технологические процессы. Как взять их под контроль – рассказали на GP Days.
▪️ Поучаствовали в IT-форуме РУССОФТ, рассказали о важном – экспертизе сотрудников и о том, как её растить внутри компании.

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

Подборка книг – команде разработки
– рассказывает Алексей, backend-разработчик, архитектор
В IT я больше 10 лет и прошёл путь от джуниора до сертифицированного архитектора. Я не открою вам Америку своим набором, но каждая книга в нём подтверждена проектным опытом – я расскажу, когда эти книги пригождаются и почему.

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

Позже мы выпустим ещё две части этой серии :)

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

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

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

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

Получили награды 🏆
Вошли в рейтинг крупнейших разработчиков мобильных приложений для бизнеса и госсектора 😏

Дали комментарии СМИ и выпустили статьи 📰
Статьи:
▪️ Хабр: Делаем ML-проект с нуля: на что обратить внимание управленцу
▪️ в нашем блоге: Как мы автоматизировали процесс согласования документов с помощью 1С
Комментарии:
▪️ Обзор TAdviser: Мобильные приложения для бизнеса и госсектора

Выступили на мероприятии и провели своё 🗣
▪️ Выступили на конференции по системному и бизнес-анализу Flow 2023: подготовили доклад «Повышение точности оценки этапа аналитики» 💬
▪️ Провели Backend MeetUP | AI & Computer Vision в Казани: рассмотрели кейсы продвинутого применения ИИ в разработке а также обсудили секреты хорошего питчинга 🤗

P.S. А ещё смотрите, какой красивый стенд у нас был на международной IT-конференции «Стачка» 😍

#вопросыбизнеса
Миграция БД: переезд с Oracle на PostgreSQL
Контекст
К нам обратилась госкомпания, которая использовала Oracle. В марте 2022 года вендор покинул российский рынок, и с тех пор пользователи СУБД столкнулись с рядом рисков:
▪️ сохранения безопасности данных;
▪️ отсутствия обновлений и техподдержки от вендора.
Это подтолкнуло клиента искать аналог, который заменит продукт по функциональности.

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

Ищем аналог Oracle
PostgreSQL оказался оптимальной альтернативой. У системы есть ряд неоспоримых преимуществ:
▪️ Открытый исходный код. Большое комьюнити разработчиков выступает в качестве вендора и поддерживает ПО в актуальном состоянии. Это делает решения на его основе достойным вариантом для импортозамещения.
▪️ Общие расходы, как правило, меньше, чем на Oracle (но зависят от кейса).
▪️ Достаточная функциональность, гибкость, масштабируемость.
Именно эти плюсы привлекли внимание клиента к системе. Для заказчика PostgreSQL стала достойной заменой импортному ПО.
Огромным плюсом было то, что клиент мог периодически останавливать работу системы в продакшне для переезда БД. Это помогло сократить действия при подготовке и непосредственной миграции данных и тем самым уменьшить риск ошибок в процессе.

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

Наш вывод
На подобном проекте важен опыт разработчиков: специалисты должны глубоко разбираться в обеих системах и подбирать подход с необходимыми инструментами для успешной миграции СУБД.

Если хотите почитать о реализации этого проекта подробнее, то вам сюда 🫵🌝

6 токсичных рабочих ситуаций
Надеемся, что в них никто не узнает себя 🌚

1. На часах 21:00, а Марату все ещё приходят рабочие сообщения. Ситуация не разовая. Часто такие письма присылают с пометкой – «прости, что поздно», «посмотри завтра», «пишу, пока помню».
Однако даже в этом случае, это токсичная коммуникация.
Все люди разные – кто-то просто выключит уведомления, а кто-то наш Марат – не может не прочитать и не ответить, потому что переживает, что пропустит что-то важное.

2. Марат работает над задачей, но после каждой итерации руководитель вносит свои правки и не позволяет самостоятельно принять даже самое мизерное решение. Это микроменеджмент, он тоже считается токсичным. После такого тотального контроля сотрудники часто становятся безынициативными и зависимыми от чужого мнения.

3. Наш Марат согрешил и стал менеджером-передачей 🤽‍♀️
Он больше не вчитывается в сообщения, а просто пересылает их от дизайнера к клиенту и наоборот. Свое мнение никак не обозначает.
Это в корне неправильно и токсично по отношению к его коллегам — Марат должен вникать, фильтровать информацию, вычленять главное и упорядочивать работу.

4.
▪️ «ASAP»
◾️ «Сделаем за неделю?»
◼️ «А может очень постараемся и завтра получится сдать — ну пожалуйста».
Марат бросает все дела, геройски выполняет горящую задачу, получает спасибо и …. *вот здесь звуки тишины* только через неделю получает обратную связь 🙈
В этой ситуации можно бесконечно говорить про демотивацию, а также, что Марат больше никогда не будет быстро реагировать даже на ASAP. Если коротко — не делайте так, правильно оцените срочность перед постановкой задачи. Вы получите более качественный результат, если дадите сотруднику возможность детально все проработать.

5. А вот я-то! Или обесценивание.
Марат месяц работал над важным проектом и пытался удержать клиента. Было сложно, но все получилось. Марат делится с коллегами успехом, а в ответ слышит: «Ты молодец. У меня тоже такое было, только я там еще сто тыщ миллионов заработал и медаль».
Каким бы классным специалистом вы ни были, остановитесь на первой части предложения, скажите — да, ты молодец!

6. Ну чего вы, ну ладно вам, вот ловите смайлик с сердечком ❤️
В отделе Марата появились разногласия и возник серьезный спор. Руководитель против конфликтов, поэтому вместо того, чтобы выявить проблему и разобраться — отправляет всем лучи дружелюбия и смайлики с сердечками.
Так он подрывает свой авторитет и доверие сотрудников. Если руководитель не может прямо выразить свое мнение и разрешить ситуацию, то как дальше с ним работать?

В этом тексте мы явно перечислили не все ситуации, пишите в комментариях свои «токсичные» истории — вместе подумаем над тем, как с ними справиться.

Улучшение процессов – залог успеха
– рассказывает Даниил, PM
Стандарты управления проектами помогают успешно стартовать, вести и завершить проект. «Не трожь, пока работает» – это точно не про сервисный подход в работе и качество. Важно не переставать внедрять улучшения в бизнес-процессы и «вышлифовывать» свои лучшие практики.
Как выглядит стандартный процесс в разработке
1. Собираем требования ➡️ уходим на детальную проработку
2. ➡️ согласовываем наработки в команде ➡️ редактируем
3. ➡️ уже после идём к клиенту с нашим результатом

Что изменили мы
1. Мы собрали требования ➡️ проработали наше «быстрое видение»
2. ➡️ проходит первый круг внутреннего согласования ➡️ дорабатываем логику видения по обратной связи
3. ➡️ идём на внешнее согласование ➡️ только после этого мы уходим на детальную проработку
4. ➡️ согласовываем наработки в команде ➡️ редактируем
5. ➡️ идём к клиенту с нашим результатом

Недавно мы разрабатывали систему управления для предприятия и сравнили показатели с подобными «архивными» проектами, вот чего мы добились благодаря этому изменению:
▪️ количество возвратов на доработку снизилось,
▪️ по аналитике достигнута экономия 20% бюджета и сроков.

А у вас есть истории, когда даже небольшое изменение приводило к заметным позитивным результатам? 🌈

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

Мероприятий было настолько много за эту неделю, что, пожалуй, сосредоточимся только на них 😁
На IT-конференции «Стачка» сразу 5 наших спикеров рассказали:
🎙 как превратить студента в профи,
🎙 за счёт чего повысить точность аналитики,
🎙 что такое системное лидерство со стороны управления бизнесом,
🎙 как мы внедряли систему менеджмента качества, внутренних аудитов и стандартов,
🎙 как использовать методологию ADD – на примере реальных проектов.
В общем, активно впитывали информацию и делились ею сами 🧠

20 сентября было сразу две конференции✌️
— Kazan Expo 2023, где наша команда слушала доклады и общалась с комьюнити
— Форум «Лидеры цифрового развития», где выступили с докладом «ML и Big Data: как искусственный интеллект ускоряет жизнь»

А ещё мы открыли регистрацию на круглый стол «Усиление IT-команды: аутстаффинг от А до Я глазами заказчика и подрядчика» 🔥 Зарегистрируйтесь, чтобы услышать напрямую от заказчиков, что они думают об аутстаффе.

Делимся тёплыми воспоминаниями со «Стачки»💙

#вопросыбизнеса
2 месяца до отключения Google и Apple ID: готовимся
– рассказывает Светлана Кузнецова, руководитель web-направления
1. Анализируем риски
Прежде всего нужен анализ наиболее вероятных для конкретной компании последствий – после этого оценка доступных вариантов будет корректнее. Например, если важно и дальше регистрировать клиентов из других стран без ограничений, то можно разделить сервис на российский и зарубежный. Такой подход уже использовали некоторые компании – он позволяет соответствовать закону и при этом сохранять лояльность клиентов.
2. Осуществляем переход постепенно
Перед полным отключением иностранных методов авторизации переводить клиентов на альтернативные варианты требуется последовательно. Лучше предупредить пользователей об изменениях, чтобы снизить негативную реакцию и возможный отток. А проанализировать саму необходимость изменений: их объём, сложность и сроки выполнения, – нужно было ещё «вчера». Ведь чтобы обеспечить для клиентов плавный переход, новые фичи надо выкатить с запасом времени до этого отключения.
3. Вводим бонусы для пользователей
Важен продуманный бонус за подключение дополнительного разрешённого способа авторизации. Он снизит негатив и простимулирует пользователей. Неочевидным плюсом этого является снижение нагрузки на продукт «за минуту до».
4. Подготавливаем систему
Как естественное продолжение предыдущего пункта – нужен план для подготовки системы к повышенной нагрузке для той самой минуты X.

Следим за дополнениями, разъяснениями и комментариями законодателей
Меры ответственности будут понятны только после анализа правоприменительной практики. Самое критичное для бизнеса – блокировка или штраф, если не получится отреагировать вовремя на дополнительные указания. Ещё одно белое пятно в этом вопросе – ответственность за определение местоположения пользователя, когда он находится под VPN, ведь сервисы искажают данные. Так что IT-сообщество и бизнес держит руку на пульсе, чтобы немедля отреагировать в случае уточнений от госорганов.

Подборка книг – команде разработки. Часть 2
– рассказывает Алексей, backend-разработчик, архитектор

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

1. Гибкие методологии разработки, Вольфсон Борис
Компактная и очень грамотная книга – лучшего описания на человеческом понятном языке с примерами я не встречал. Автор рассматривает основные концепции и делает их сравнение: когда в какой команде какую методологию рекомендуется применить. И главное, книга небольшая – меньше 200 страниц, очень культурно :) Вы будете понимать, зачем есть каждый этап в каждой методологии и почему методологии именно такие.
2. Канбан и «точно вовремя» на Toyota, специалисты Toyota
К сожалению, я часто вижу, что фичи застревают на разных этапах. Эта ситуация противоречит системе «точно вовремя»: делай именно то, что надо, затрачивая только необходимые ресурсы. В книге найдёте разные подходы к устранению задержек – это хорошо ложится на разработку и откликается в «бережливом программировании».
3. Бережливое производство + шесть сигм в сфере услуг, Майкл Л. Джордж
Я работаю не на одном подходе, а использую несколько концепций разработки одновременно – именно эта книга подтолкнула меня к этому. Она позволила понять: если вы знаете одну методологию, это не означает, что вы должны её сразу применять. Вы должны изучить ещё несколько, сложить из них гремучую смесь для вашего конкретного проекта, и это будет более эффективно.
Попутно даётся понимание шести сигм и как их использовать. Считаю, что для всех продуктовых проектов это находка. Когда я стал внедрять на своих подпроектах шесть сигм, мы начали находить неявные баги – клиент был удивлён. Мы исправляли процессы. Сейчас я уже могу напрямую ходить к директору-британцу и предлагать идеи по улучшению – он знает, что это всегда обосновано. Я вижу статистику, по статистике я вижу отклонения, по отклонениям я нахожу проблемные места, а по «бережливости» я понимаю, как их наиболее оптимально исправить.

Скоро расскажем о трёх последних «артефактах» для роста IT-специалистов ✊🏻

Формируем успешную проектную команду
– рассказывает Светлана Кузнецова, руководитель web-направления

Для решения задач клиентов мы создаём новые команды или усиливаем специалистами уже существующие. Работая с сотнями проектов, мы выявили несколько факторов, которые помогают нам делать это эффективно.
🔹 Сбалансированность команды
На своем опыте выяснили, что на большинстве проектов задачи соотносятся примерно так: 30% – простые, 50% – средние, 20% – сложные. Следовательно, нужны как опытные специалисты Middle и Senior, так и начинающие Junior, которые смогут выполнять простые задачи и перенимать опыт. В таком случае мы решаем несколько задач:
◾️ в команде будет общепризнанный лидер и «рефери» для решения спорных ситуаций в лице Senior-разработчика;
◾️ задачи будут распределены в соответствии с профессиональным уровнем специалистов;
◾️ при выборе разработчиков будет экономически целесообразно учитывать уровень сложности и другие особенности проекта.

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

🔹 Понимание цели проекта и достижения ключевых точек
Важно, чтобы все члены команды знали цель проекта. При этом каждый разработчик должен понимать, как конкретно его задача повлияет на достижение результата. Зная это, он может:
◾️ вовремя заметить некорректную постановку задачи;
◾️ понять, как его задача влияет на другие;
◾️ скорректировать свои действия и свой план при отклонении от общей цели.
Обязательно стоит уделять внимание промежуточным итогам. Важно фиксировать завершение каждого этапа на проекте, отмечать вклад каждого специалиста и показывать фидбэк от пользователей. Это даст возможность команде оценить результат своей работы и настроиться на следующий спринт.

🔹 Мотивирующие факторы
Разработчики SimbirSoft выделили несколько пунктов, которые влияют на их рабочий настрой:
◾️ коллеги-профессионалы, которые любят своё дело и «горят» им;
◾️ атмосфера взаимопомощи внутри команды;
◾️ возможность поиска лучшего решения;
◾️ ощущение важности и полезности итогового продукта и личного вклада.