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

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

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

Улучшение процессов – залог успеха
– рассказывает Даниил, 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 выделили несколько пунктов, которые влияют на их рабочий настрой:
◾️ коллеги-профессионалы, которые любят своё дело и «горят» им;
◾️ атмосфера взаимопомощи внутри команды;
◾️ возможность поиска лучшего решения;
◾️ ощущение важности и полезности итогового продукта и личного вклада.