Как не впадать в крайности контроля при работе с командой
— рассказывает Екатерина, PM
На мой взгляд, для управления проектом не подходит как вариант с микроменеджментом и тотальным надзором, так и полное расслабление и вседозволенность. Первый снижает лояльность к компании и мотивацию сотрудников, а второй часто приводит к тому, что вы не управляете ситуацией и сроками.

В начале своей карьеры я набила несколько «шишек». Зато поняла, что гораздо комфортнее и команде, и мне, когда выстроен баланс между контролем и доверием.

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

Главное донести до сотрудников и не забыть самому — мы не на разных сторонах баррикад, мы одна команда. Руководитель проекта должен выстроить комфортные условия и быть «своим» — к нему к первому должны идти с любыми вопросами и проблемами.

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

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

Приёмка продукта от другого подрядчика
– рассказывает Даниил, PM
Контекст
В прошлом году мы принимали сайт, разработанный event-агентством. С помощью своего конструктора сайтов компания создавала простые сайты и лендинги. Однако клиенту понадобилось разработать обучающую платформу – ресурсов конструктора не хватало, и пользователи жаловались на баги. Так проект перешел к нам – нужно было его спасти и помочь в дальнейшем развитии.

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

Объединяющая мысль этих пунктов – когда-нибудь предыдущий исполнитель уйдёт совсем и вы останетесь один на один с клиентом и продуктом. Чтобы максимально снизить рисковость этого момента – нужно создавать себе подушку безопасности.

А у вас были подобные ситуации? Как всё прошло?

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

Получили награды 🏆
Мы среди 50 крупнейших ИТ-поставщиков в ритейле 🛍 Полный список компаний тут, а здесь можно посмотреть некоторые из наших ритейл-проектов :)

Дали комментарии СМИ и выпустили статьи 📰
Комментарии:
▪️ Известия: Спортивный ИИнтерес: как нейросети помогают атлетам
▪️ IT Channel News: Отечественное ПО для коммерческих заказчиков: на что и как переходить?
Статьи:
▪️ AppTractor: Фишки React Native для реализации личного кабинета
▪️ Skillbox Media: 6 ошибок при постановке задач в IT-проектах
▪️ в нашем блоге: Разработка информационной системы и зрелость бизнес-процессов: выбираем решение
▪️ в нашем блоге: Аутсорсинг VS Аутстаффинг в заказной разработке

Провели мероприятие 🗣
Обсудили с комьюнити Java-разработку и IT-архитектуру на Backend MeetUP в Самаре – два доклада и открытый микрофон после них 🔥

#вопросыбизнеса

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

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

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

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

SimbirVolga – это:
▪️️ два дня плодотворного нетворкинга и отдыха,
️▪️ обмен опытом в формате мини-докладов,
▪️ экскурсия в Музей истории гражданской авиации,
▪️ кулинарный мастер-класс,
️▪️ прогулка на теплоходе по Волге.

Уже ждём следующей такой встречи 😁

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

История про 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. В подсчёте капасити учтены созвоны по фичам, активности лидов, но не учтены багофикс, техдолги и прочее. Исходя из особенностей проекта, его срока жизни, количество необходимых фиксов и задач техдолга может варьироваться от нескольких десятков до нескольких сотен.

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

Выступили на мероприятиях 🗣
▪️ Современные производственные предприятия – это сложные системы, в которых ежедневно протекают различные технологические процессы. Как взять их под контроль – рассказали на 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. Ну чего вы, ну ладно вам, вот ловите смайлик с сердечком ❤️
В отделе Марата появились разногласия и возник серьезный спор. Руководитель против конфликтов, поэтому вместо того, чтобы выявить проблему и разобраться — отправляет всем лучи дружелюбия и смайлики с сердечками.
Так он подрывает свой авторитет и доверие сотрудников. Если руководитель не может прямо выразить свое мнение и разрешить ситуацию, то как дальше с ним работать?

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