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

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

前往频道在 Telegram

Авторский канал IT-компании SimbirSoft про разработку и управление ей: делимся экспертизой, лайфхаками, разбираем реальные кейсы. 🔹Наш сайт: https://s.simbirsoft.com/FT1c 🔹Вопросы: info@simbirsoft.com

显示更多
1 360
订阅者
无数据24 小时
+27
-230
帖子存档
☝️Рассказали RB.RU о 7 способах реализации мобильных приложений для бизнеса. Для каждого из них описали возможности и ограничения, а также в какой ситуации он подходит ✨

Repost from Russian Business
Создание мобильных приложений — что важно учесть в нынешних условиях? Как бизнесу оптимизировать затраты на создание приложен
Создание мобильных приложений — что важно учесть в нынешних условиях? Как бизнесу оптимизировать затраты на создание приложений в текущих условиях? О возможных вариантах их реализации читайте в материале. @rb_ru

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

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

​​Как бизнес использует Data Science Data Science помогает анализировать большие объемы информации, извлекать из них полезные знания и на их основе предпринимать действия для улучшения бизнеса. Ниже – примеры успешного использования :) Google Таргетированная реклама Google основывается на запросах в поисковой строке, а также на общении и активности пользователя в социальных сетях, его перемещениях. Например, если человек часто заходит в Starbucks, система начнет показывать ему рекламу кофе и т.д. Netflix Сервис на основе анализа поведения подписчиков создает для них индивидуальную подборку потенциально интересных фильмов и сериалов, причем «обложка» для рекомендуемого контента формируется лично для каждого зрителя. Target Сеть американских супермаркетов присылает покупателям персонализированные скидочные купоны, основываясь на истории их покупок и анализе поведения. Кейс SimbirSoft На основе Big Data для страховой компании мы разработали систему, рассчитывающую вероятность и частоту обращения клиента за медицинской помощью. Мы принимали в расчет следующие факторы: 🔹 возраст и пол пациента; 🔹 поставленные ему ранее диагнозы; 🔹 назначенные процедуры; 🔹 перечень обращений для каждого отдельного клиента, с указанием времени, типа услуги, вида лечения и т.д. ❗️Важно было учесть, что некоторые эпизоды происходили до того, как пациент стал клиентом страховой: часть данных не попала в базу, поскольку человек обращался к доктору в частном порядке или в государственную поликлинику. Мы применили один из методов Data Science «анализ выживаемости», созданный специально для обработки цензурированных данных – это сведения, в которых часть событий не наблюдалась или не могла наблюдаться в период сбора информации. С его помощью смогли точнее спрогнозировать следующее обращение клиента в компанию, а также определить наиболее вероятный период и тип посещения.

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

Как вы думаете, сколько давно не обновляемых или мало загружаемых приложений удалил AppStore за последние 6 лет?
Anonymous voting

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

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

Как бы вы поступили в этой ситуации?
Anonymous voting

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

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

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

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

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

Какой метод управления проектом больше подходит в этой ситуации?
Anonymous voting

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

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