Есть свои варианты? – будет здорово, если поделитесь ими) А с комментариями вернёмся в понедельник 🤗

Комментарии к задачке
Вариант А с большой долей вероятности приведёт к срыву сроков. 5 часов – это, конечно, некритично. Но 2 дня для выполнения задачи — это не много, и бездействие в этой ситуации может сыграть с вами злую шутку. Что будет, если специалист экстренно попал в больницу? К тому моменту, когда вы узнаете все детали, времени на выполнение задачи может оказаться недостаточно.
Вариант B подойдёт, если в вашей команде нет никого, кому можно делегировать задачу. Необходимо учитывать, что на погружение нового специалиста может уйти достаточно много времени и риск не уложиться в сроки всё еще остается.
Вариант С наиболее оптимальный, если другой специалист с вашего проекта занят менее приоритетной задачей. Таким образом получится привлечь уже погруженного в проект специалиста.

BI-аналитика: что такое и когда нужна
Вы коммерческий директор крупной компании. Недавно вы заметили, что прибыль начала снижаться, как и количество закрытых сделок. После всех обсуждений с ключевыми сотрудниками, анализа ситуации и выяснения причин вы решаете нанять другого руководителя отдела продаж. Проходит ещё несколько месяцев, а ситуация не улучшается.
Вы проверили несколько гипотез и ввели дополнительные бонусы для менеджеров по продажам, сделали ещё несколько кадровых перестановок – результат всё тот же. Что делать?

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

Как управлять проектом в условиях неопределённости? – лайфхаки от нашего PM Екатерины ☝️

Low-code-платформа: подводные камни
Челлендж: как без тысячи строк кода создать систему управления предприятием?? В 2022 году работали над подобной задачей — создавали Low-code-UI-конструктор 🤓  

Это не первый такой проект, так что мы понимали:
1️⃣ Важно смотреть на платформу с точек зрения двух групп пользователей, которые будут:
▪️ с её помощью создавать конечный продукт.
▪️ непосредственно работать с этим продуктом.
Механизмы работы платформы должны быть максимально абстрактными, чтобы закрыть как можно больше кейсов использования системы.    
2️⃣ Нужно начинать работу с MVP. При этом в нашем случае даже MVP содержала объёмный набор функций, и обойтись без них было нельзя — иначе не решить задачи пользователей и не получить от них обратную связь для дальнейшего развития.
3️⃣ Нужно разбить продукт на несколько более мелких частей или релизов, чтобы чаще выпускать стабильные версии и обновления.

Тем не менее при разработке мы столкнулись с такими препятствиями:
▪️ Нужны интеграционные тесты в большом количестве. И они не всегда очевидны из аналитики.
▪️ Много тестовой документации, которую нужно обновлять. При этом компоненты сложной системы взаимосвязаны — одно изменение влечёт за собой другое.
▪️ О недостающих критичных фичах мы продолжали узнавать в процессе разработки. Это связано с масштабом системы, широким спектром компонентов и подсистем.
▪️ Большое количество микросервисов в продукте влияет и на проработку архитектуры.

❗️ То есть нужно заранее учитывать и предугадывать множество взаимосвязей и интеграций. Сложность тестирования оказалась в том, что конструктор имеет огромное количество комбинаций, которыми можно воспользоваться. Прописать в аналитике исчерпывающие сценарии использования невозможно. Уже к сдаче MVP мы поняли, что нужно менять подход к тестированию. Мало просто проанализировать целевую аудиторию, нужно покрыть все требования тестами, применить техники тест-дизайна.

В итоге мы пришли к таким решениям:
1️⃣ Проанализировали все баги и узкие места, которые возникали при использовании системы в промежуточном тестировании, и выявили часто повторяющиеся комбинации и проблемы. Все проверки включили в регресс.
2️⃣ Воспользовались техникой попарного тестирования и составили максимально возможное количество комбинаций между элементами интерфейса, доступными действиями и событиями.
3️⃣ После общения с заказчиком о задачах той или иной фичи и анализа бизнес-логики системы прописали основные интеграционные тесты.
4️⃣ Поскольку без автоматизации тестирования невозможно быстро выпускать релизы, мы разделили процесс на этапы, чтобы снизить затраты и повысить эффективность. Совместно с заказчиком определили основные критичные сценарии, которые нужно проверять каждый раз при внесении правок в систему. Это позволило нам уже на самом начальном этапе запускать автотесты и покрывать критичный функционал, быстрее «заливать» хотфиксы или срочные доработки.

«Бутылочное горлышко»: доступы, срочность и конфиденциальность
Эта ситуация произошла ещё в начале пути SimbirSoft. Мы её хорошо помним, потому что она помогла нам выработать варианты решений для случаев, когда «бутылочным горлышком» становятся доступы.

Что, собственно, случилось?
К нам обратилась страховая компания для развития их сервиса. Нужно было настроить обмен данными между подразделениями и упростить работу с сервисом для сотрудников: ускорить оформление заявок, загрузку документов и т.д. Самое важное — нужно было сделать всё быстро.
Мы прониклись духом срочности, подключили к проекту аналитика, QA-специалиста, frontend- и backend-разработчиков, приготовились сворачивать «горы». И ничего у нас не вышло 🙃

Как решали
Сложности начались почти сразу, когда нашего уровня доступа оказалось недостаточно для решения задач. Компания опасалась за конфиденциальность данных, вместе со службой безопасности мы искали обходные пути, чтобы выгрузить только ту часть информации, что критично важна. Потратили не один день, а ситуация всё не решалась. Далее было много «хождений по мукам» и наших, и клиента, но в итоге мы сделали специальный NDA под проект.

Как работаем теперь
Опасения клиентов в таких случаях можно понять, а нам как аутсорс-компании важно, чтобы с нами было безопасно работать. Что мы теперь предлагаем в такой ситуации:
▪️ Составление дополнительного NDA под проект, как в описанной выше ситуации;
▪️ обезличенное сотрудничество. При необходимости все коммуникации ведутся через почту и подключённый к проекту специалист не знает, с какой компанией работает.

Как реализовать первый маркетплейс в отрасли
Партнёры из Северстали пару лет назад провели CustDev поставщиков и покупателей металлопроката и вот что выяснили:
▪️ желание поставщиков – получить новые источники привлечения клиентов;
▪️ желание клиентов – иметь оперативность и омниканальность в процессе покупки, а также знать актуальные цены и остатки.

🥁 🥁 🥁 Было решено – маркетплейсу металлпроката «Платферрум» быть!

В подкасте поговорили об организации B2B-маркетплейса – как стартовали проект и разрабатывали продукт 🏗

Таймкоды лежат в комментариях :)

Задачка для менеджеров
Ваш проект – мобильное приложение для банка. Вы занимаетесь его разработкой уже 6 месяцев. Внезапно одна из библиотек, которую вы активно использовали, перестала поддерживаться. Вы понимаете, что это может повлиять на достижение цели проекта. Что будете делать?

С комментариями вернёмся в понедельник 🤗