#подкасты

Мы тут немало рассказывали про разные аспекты frontend-разработки, но ещё не познакомили вас со специалистами, которые создают все эти удивительные вещи. Исправляемся!

🧑‍💻Сегодня Frontend-направление SimbirSoft объединяет 200+ скиловых разработчиков. За 6 лет они реализовали свыше 280 разнообразных проектов для банков, ритейла, фудтеха, здравоохранения, образования и других сфер. Ежедневно наши frontend-специалисты развивают 70+ IT-решений 🔥
В видео наши коллеги рассказывают, с чего начался их путь в IT, какие задачи они решают, чем их привлекает frontend-разработка и как им удается найти баланс между кодингом и управлением.

Приятного просмотра!

Никаких вступлений, переходим к делу! 💃
Какой метод управления проектом больше подходит в этой ситуации?
P.S. Ответ раскроем завтра 😇

Как и обещали, возвращаемся с пояснениями! 🤗

Гид по сегодняшним публикациям:
🔹 Классический подход: преимущества и риски
🔹 Ответ на задачу ☝️
🔹 Гибкие методологии Agile: преимущества и риски
🔹 Задачка со звёздочкой (пояснение в понедельник)

Классический подход: преимущества и риски
Преимущества
🔹 Фиксация требований на старте и стабильность содержания проекта.
🔹 Предсказуемость процесса разработки. Качественная проработка требований и видения продукта на ранних стадиях проекта позволяет сэкономить время и силы на исправлении недочётов и решении проблем в дальнейшем.
Подводные камни/риски
🔹 Негибкое взаимодействие при возникновении новых условий и потребностей. К примеру, если нужно изменить цель, проект необходимо перезапустить и сформировать новый устав, определить требования и ограничения.
Классическое управление по PMI можно использовать, когда:
🔹 заинтересованные лица имеют чёткое видение результата – конечный продукт;
🔹 составлено подробное техническое задание на разработку;
🔹 есть жёсткие ограничения по сроку и бюджету проекта;
🔹 реализация проекта предполагается по формату договора fixed price.

Ответ на задачу
Если нужно создать ИТ-продукт, где фундаментальное содержание и цели проекта зафиксированы и неизменяемы, а также есть чёткие ограничения по сроку и бюджету, лучше выбирать классический подход. В этом случае Agile будет избыточным.

Гибкие методологии Agile
Преимущества
🔹 Быстрый жизненный цикл разработки.
🔹 Гибкость в принятии решений для улучшения итогового продукта.
🔹 Регулярное получение обратной связи от заинтересованных сторон открывает возможность вносить корректировки в реализацию проекта или в функциональность разрабатываемого продукта.
Подводные камни/риски
🔹 Отсутствие чёткого плана затрудняет управление ресурсами и планирование.
🔹 Все заинтересованные стороны должны работать в тесном сотрудничестве, чтобы каждый знал об изменениях, задачах и их актуальности.
🔹 Предъявляются более высокие требования к команде.
Гибкие методологии работают, когда:
🔹 детали проекта, требования и реализация фич всех запланированных модулей/подсистем ещё не до конца определены на старте. Нет чёткого понимания конечного результата, но есть общее представление о продукте;
🔹 проект нужно быстро корректировать и подстраивать под изменяющиеся требования.

Задачка со звёздочкой
Условия: Высокая неопределённость требований и высокая техническая неопределённость
Пример проекта: создание приложения для мобильного устройства с блоком считывателя радиосигналов. Главная фича – распознавание размеров и других параметров объекта по фотографии, сделанной устройством.
Вопрос: Как бы вы поступили в этой ситуации?

Пояснение к задаче
Вы правильно поняли, что отказываться от проекта с высокой неопределённостью сразу не стоит, так как по итогу упущенная выгода может быть весомой. К тому же в этом случае клиент, скорее всего, не придёт к вам и со следующими своими продуктами – сложная разработка не для вас.
Однако, в условиях «хаоса» Agile-методологии не подходят – они не позволят даже приблизительно оценить фронт работ и провести планирование. Значительное изменение сроков или количества специалистов на проекте может привести к недовольству клиента, также продукт может быть неосуществим.
Чтобы быть уверенным в возможности его реализации, команде необходимо уменьшить неопределённость. Например, использовать практику предпроектного исследования и реализовать прототип системы. Это помогает понять, достаточно ли команде технической экспертизы и инструментов для решения подобных задач.
Если возвращаться к описанному в задаче приложению со считывателем радиосигналов – это реальный пример из нашей практики. В ходе предпроектного исследования мы проверили гипотезу о возможности внедрения алгоритма machine learning в приложение и протестировали функционал считывания радиосигналов в полевых условиях. Команда убедилась, что задача имеет понятное техническое решение, тем самым снизила уровень технической неопределённости. Далее следовала стандартная схема работ.
Другой вариант – стартовать по концепции Lean Startup. Она позволяет с минимальными вложениями протестировать гипотезу: создать прототип, собрать обратную связь от пользователей, определить, интересен ли продукт целевой аудитории, и наметить план его развития.

Когда (пока) не нужно мобильное приложение?
Да-да, компания по разработке IT-продуктов пишет о том, когда стоит отложить эту самую разработку. Всё верно)
Мы за то, чтобы ваши продукты приносили вам пользу и прибыль, а не наоборот 💙
Прочитать новый пост можно, не выходя из Телеграма 😇

P.S. Как вам такой формат публикаций?
😉 Приветствую!
🤔 Обычные посты мне всё-таки милее

#статьи

Изменения на рынке подтолкнули компании к усилению цифровизации: увеличился спрос на адаптацию готовых и разработку собственных продуктов.
Но бизнес всё ещё не до конца доверяет технологиям: «Разработка – это слишком дорого, а ещё долго и сложно», «Невозможно оценить эффективность IT-системы».

В статье для Executive рассказали о 5 популярных предубеждениях о финансовой стороне разработки (и о том, как происходит на самом деле). Материал будет полезен всем, кто задумывается о создании IT-продукта.

​​Как бизнес использует Data Science
Data Science помогает анализировать большие объемы информации, извлекать из них полезные знания и на их основе предпринимать действия для улучшения бизнеса. Ниже – примеры успешного использования :)

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

Netflix
Сервис на основе анализа поведения подписчиков создает для них индивидуальную подборку потенциально интересных фильмов и сериалов, причем «обложка» для рекомендуемого контента формируется лично для каждого зрителя.

Target
Сеть американских супермаркетов присылает покупателям персонализированные скидочные купоны, основываясь на истории их покупок и анализе поведения.

Кейс SimbirSoft
На основе Big Data для страховой компании мы разработали систему, рассчитывающую вероятность и частоту обращения клиента за медицинской помощью.
Мы принимали в расчет следующие факторы:
🔹 возраст и пол пациента;
🔹 поставленные ему ранее диагнозы;
🔹 назначенные процедуры;
🔹 перечень обращений для каждого отдельного клиента, с указанием времени, типа услуги, вида лечения и т.д.

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

Мы применили один из методов Data Science «анализ выживаемости», созданный специально для обработки цензурированных данных – это сведения, в которых часть событий не наблюдалась или не могла наблюдаться в период сбора информации. С его помощью смогли точнее спрогнозировать следующее обращение клиента в компанию, а также определить наиболее вероятный период и тип посещения.

– Погружён в потребности бизнеса;
– хорошо понимает клиента;
– контролирует выполнение задач на проекте;
– подходит индивидуально к каждой ситуации...
👀 Как аккаунт-менеджерам это удаётся?

🔥Несколько уровней менторства
🔥Своя система обучения
🔥Большой опыт в подготовке и адаптации специалистов
Обо всем этом – в видео от наших менторов в аккаунт-направлении👇

Как понять, что пора что-то менять в команде
Почему часто численность персонала вырастает независимо от того, становится работы больше или меньше? – Общая эффективность команды со временем начинает падать. Как правило, первые симптомы не очень заметны:
🔹Начинают ухудшаться метрики проекта: например, снижается скорость релизов.
🔹Некоторые процессы перестают выполняться: код-ревью, ретроспективы и т.д.
🔹Растет время на проектирование и разработку фич. Специалисты переходят к избыточному перфекционизму: ищут изящные и красивые решения – кодят «в своё удовольствие».
🔹Снижается мотивация команды.

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

Причины
Сформировать и поддерживать эффективную команду в принципе непросто. А на проекте сложно вовремя признаться, что есть проблемы и команда не вытягивает – мы до последнего верим в позитив. Среди основных причин провала (которых множество) можно выделить:
🔹отсутствие требуемых компетенций у специалистов и руководителей;
🔹отсутствие требуемого процесса/этапа в проекте;
🔹неверно определённые ожидания;
🔹ошибки в оценке проекта;
🔹отсутствие системы работы с рисками;
🔹отсутствие контроля.

Рекомендации
1️⃣Измерять работу над проектом с самого начала. При этом необходимо выстроить непрерывный процесс сбора метрик: количества фич в бэклоге, оценок пользователей, быстродействия продукта и т.д. Анализируя данные, вы сможете предотвратить угрожающие «пожары» и далее скорректировать работу команды.
2️⃣Выстроить нужный процесс работы и обеспечивать его: например, заранее проработать вопросы доступа к стендам, чтобы не возникало простоя и перегорания специалистов на этом фоне.
3️⃣От «замыливания» помогает периодический взгляд со стороны – аудит. Например, один клиент пригласил нас для оценки работы своего постоянного подрядчика. В итоге мы предложили улучшения, о которых не задумывались до этого ни клиент, ни команда разработки – свежий взгляд помог развитию проекта.
4️⃣Работать с проверенным партнёром.
Последний пункт раскроем в следующих постах, так как коротким комментарием тут не обойдёшься) В видео разбираем примеры реальных кейсов и их источники проблем (ссылка с привязкой к нужному моменту).

Создание мобильных приложений — что важно учесть в нынешних условиях?

Как бизнесу оптимизировать затраты на создание приложений в текущих условиях? О возможных вариантах их реализации читайте в материале.

@rb_ru