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

Гид по сегодняшним публикациям:
🔹 Классический подход: преимущества и риски
🔹 Ответ на задачу ☝️
🔹 Гибкие методологии 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

☝️Рассказали RB.RU о 7 способах реализации мобильных приложений для бизнеса. Для каждого из них описали возможности и ограничения, а также в какой ситуации он подходит ✨

​​Simbirsoft. Редизайн корпоративного сайта
Недавно мы обновили корпоративный сайт.
🧐Зачем мы это сделали?
😎Чтобы быть ближе к нашим пользователям: рынок динамично развивается, меняются тренды и паттерны и даже лучший дизайн морально устаревает.
Оптимально раз в 3 года проводить редизайн и полноценный UX-аудит.

Как выстроили дизайн-процесс?
1️⃣Использовали проверенные приемы UX-дизайна: количественные и качественные исследования, конкурентный анализ, данные Яндекс.Метрики, запросы целевой аудитории.

2️⃣На основании полученных данных описали:
→ новую структуру сайта;
→ блоки, которые следует добавить;
→ функциональные обновления;
→ концепцию форм обратной связи.

3️⃣Провели качественные исследования:
→ интервью с заинтересованными лицами;
→ тестирование кликабельных прототипов на пользователях.

4️⃣По итогам исследований и анализа метрик:
→ обновили блок «Портфолио» на основе обратной связи от аккаунт-менеджеров и отдела продаж;
→ изменили структуру и формат раздела «Блог»;
→ переработали блок «Вакансии».

Основная визуальная задача – сохранение фирменного стиля с использованием новых трендов и лучших практик дизайна на рынке.
Для облегчения поддержки и развития функциональности сайта спроектировали дизайн-систему и создали более 40 иконок и 20 иллюстраций.

​​Круглый стол «IT-щит для бизнеса: как сделать продукт безопасным?»
Изменения на ИТ-рынке рождают новые вызовы для бизнеса. В центре внимания – безопасность, способность обеспечить защиту пользовательских данных и надежную работу ИТ-системы.

Из чего складывается ИТ-безопасность и как ее выстроить? Какие расходы критически важны, а какие второстепенны? Способны ли аудиты безопасности принести реальную пользу?

Эксперты SimbirSoft приглашают обсудить современные способы защиты программного обеспечения на круглом столе 25 августа в 14:00 (по московскому времени) в онлайн-формате.

Будет интересно представителям бизнеса, которые курирует вопросы разработки ИТ-продуктов, техническим директорам, директорам по информационной безопасности и цифровой трансформации, менеджерам ИТ-продуктов и тимлидам.

В прямом эфире вы сможете задать вопросы или обсудить свои кейсы с нашими спикерами.

Узнать больше о программе круглого стола и зарегистрироваться можно по ссылке: https://s.simbirsoft.com/7JmP

Google-сервисы: уйти нельзя остаться
🤗По одной из версий, Google-сервисы останутся в нашей стране, но с некоторыми ограничениями.
😱 А судя по последним новостям может произойти все что угодно. И по некоторым прогнозам, корпоративные аккаунты могут стать недоступны с августа.

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

​​No-codе решения: для чего подходят, плюсы и минусы
Работа с no-code платформами основана на графическом интерфейсе, который позволяет создавать функциональные решения без знания языков программирования.

С помощью no-code с минимальными ресурсами можно тестировать и реализовывать даже смелые проекты:
🔹 сайты различной сложности (лэндинги, многостраничные сайты, интернет-магазины);
🔹 мобильные приложения с личными кабинетами и разными ролями (например: покупатель, поставщик, администратор);
🔹 внутренние корпоративные сервисы;
🔹 средства для работы с базами данных;
🔹 голосовые приложения и чат-боты;
🔹 модули для платежей и пр.

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

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

Как итог – учитывая специфику таких платформ, они подходят:
🔹 на начальных этапах разработки;
🔹 при запуске стартапа;
🔹 для автоматизации процессов в малом и среднем бизнесе.