🔥 Обсуждаем безопасность ИТ-продукта с точки зрения кода и инфраструктуры в прямом эфире. Подключайтесь!
Реальные примеры с проектов, конкретные рекомендации, которые «написаны кровью», активные участники 😏

Смотрите трансляцию:
— на канале SimbirSoft на YouTube: https://youtu.be/j5agHZq9iEI

Подключайтесь к обсуждению по ссылке: https://bbb-ext.simbirsoft.com/b/mze-hlo-off-heb

Инсайты обсуждения ☝️

Что меняется на проекте со Scrum-мастером?
☝️Недавно мы спрашивали вас о необходимости Scrum-мастера, когда работа на проекте ведётся по этому самому Scrum. Не все согласились с тем, что отдельный специалист нужен. Мы попросили нашу коллегу из направления QA Наталью раскрыть этот вопрос и поделиться личным опытом.

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

Невозможно ощутить полноценную пользу от Scrum, если только частично выполнять его основные принципы. Да, фреймворк допускает надстройки и внесение изменений в него для конкретных ситуаций, но остаётся сводом чётких правил. Не зря обязанности Scrum-мастера выделены в отдельную должность: его полноценная работа предполагает реализацию организационных моментов и сбора метрик, определённых методологией. И чтобы качество продукта не страдало, необходим человек, который будет настраивать работу команды.

«Дело было осенью. Шел четвёртый месяц работы над MVP.

Все команды, забыв о квартальном планировании, трудились над срочным запуском продукта. Я подключился к проекту на этапе вывода MVP. К слову, тот запуск был образцово-показательным. Но не обошлось без потерь: по разным причинам ушли QA-специалист и скрам-мастер. Однако на проекте остались крутые и вовлеченные люди, которые приобрели и сохранили весь пережитый опыт.

Что мы имели на входе?..»

Отрывок нового IT-романа, дневник разработчика? Неееет, это статья нашего QA о том, как метрики помогают выстроить работу команды и решить проблемы на проекте – от ограниченного ресурса до ошибок на проде.

В Телеграфе вы найдёте:
🔹 пошаговый путь к метрикам на примере одного проекта;
🔹 мемы;
🔹 реальные графики-результаты проделанной работы;
🔹 (ещё мемы).
Полгода труда точно стоили того – прочитайте и убедитесь сами 😏

Смена подрядчика: как не наступить на старые грабли
К подрядчику, который перенимает продукт, требования намного выше, чем к команде-«первопроходцу». Создать и развивать продукт самому легче, чем переделывать за кем-то. Нужно проанализировать:
🔹чужой код;
🔹что можно переиспользовать (беря во внимание риски);
🔹как довести продукт до ума.
Это трудоёмкий процесс, поэтому сначала предлагаем присмотреться к своей старой команде. Если же присматриваться больше не к кому, следующий пункт в посте можно пропустить.

А может и не стоит менять подрядчика?
Перед принятием решения внимательно изучите:
🔹документы по планированию, оценке затрат, учету рисков;
🔹процессы разработки, коммуникацию в команде;
🔹этапы разработки и наличие специалистов на проекте.
Пример.
Проблема: постоянно нарушаются дедлайны.
Возможные причины:
1. Проект оценивала другая команда, а в новой некоторые специалисты работают над двумя вашими продуктами.
2. В процессе появились новые стейкхолдеры, и они детализировали фичи.
3. На проекте нет аналитика, соответственно, корректной постановки задач. Разработчикам приходится несколько раз переделывать фичи, прежде чем конечный пользователь скажет: «Да, это я и имел в виду».
Возможные решения: переоценка с учетом актуальной специфики проекта, корректировка процессов разработки и управления.

Всё-таки стоит: на что обратить внимание
Вы выбрали несколько компаний по рекомендациям/отзывам, соответствию технического стека и опыту в вашей сфере. Далее присмотритесь к процессам, которые он предлагает вам при перенятии проекта. Схема должна выглядеть следующим образом:
1️⃣ Изучение системы
2️⃣ Аудит
3️⃣ План выполнения задач
4️⃣ Разработка + Аналитика + Тестирование
5️⃣ Релиз
Если подрядчик сразу говорит, что в условный день он готов приступить к работе, вероятность плохого результата возрастает многократно.
Это похоже на смену лечащей компании: вы приходите с болями в области печени в новую клинику. Странно, если вам тут же предложат лечить этот орган. Сначала специалист начнёт сбор анамнеза, изучит ваши жалобы.

Что должен спросить хороший подрядчик до начала работ: изучение системы
Что было
🔹 Причины смены подрядчика
🔹 Боли: что конкретно не устраивает
🔹 Бизнес-потребности: для чего/ кого продукт делается
Что есть
🔹 Отношения со старой командой: можно ли с ними взаимодействовать
🔹 Исходники: где находятся, версионность и т.п.
🔹 Документация и ТЗ
🔹 Отчеты предыдущих исследований
Что будет
🔹 Ожидания клиента от продукта: цели сейчас и на несколько лет вперёд
🔹 Время, которое клиент будет уделять проекту
Эти вопросы определяют надёжную компанию, которая отвечает за результат. Они помогают соотнести реализацию продукта с вашими ожиданиями и требованиями.

Первый этап договорных отношений: аудит
Что входит:
🔹 аудит кода (обязательно);
🔹 аудит функционала (обязательно);
🔹 аудит архитектуры, БД, инфраструктуры;
🔹 UX-аудит
🔹 аудит процессов.
Результаты:
🔹 документ о состоянии продукта;
🔹 рекомендации к исправлению.
❗️Важно! В рекомендации должен входить перечень шагов с их приоритизацией. Правильный подрядчик предлагает несколько вариантов решения проблем. Вы сможете выбрать наиболее подходящий вам, опираясь на бюджет, требования и сроки.
Кроме того, результаты могут быть неожиданными: иногда проще сделать всё с нуля, чем переделать то, что есть. Возможно, после аудита вы поймете, что можно скорректировать что-то в старой команде и не менять её.

Наши дизайнеры приготовили видео о том, как с помощью интерфейса помочь пользователю распознать и устранить ошибки при работе с продуктом. Пустой набор результатов поиска, ненайденная страница – это всё об этом.

3 минуты = рекомендации + объяснения + примеры. Ну и ещё 6 секунд на заставку)

Заботливый мини-спойлер для тех, кому не нужны объяснения и примеры: сообщите, на каком этапе возникла проблема и в чём она состояла, а также предложите вариант решения.

Как на самом деле должна работать Политика качества
Политика качества зачастую рождается как «работа над ошибками». Расскажем о внутреннем проекте, над которым работали много лет назад и на котором совершили те самые ошибки.

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

Что удалось выяснить
Вводные данные:
Релиз предполагал двухнедельный спринт. Команда состояла из ПМа, который подключался лишь изредка, трех разработчиков и одного QA. Планируемая оценка – 150 часов с учетом отвлечения специалистов на другие проекты.
Исследование показало:
К середине первой недели спринта — при передаче проекта от одного ПМа к другому — забыли объяснить часть логики реализации фичи. Road map давно не актуализировался, описание задач было недостаточным. Когда вспомнили про фичу к середине второй недели спринта, это добавило еще 60 часов разработки и ретеста.
В конце первой недели спринта от проекта отвлекли самого осведомленного разработчика и подключили нового. Погружение для него не провели. В конце второй недели главный разработчик вернулся на проект и переписал код новичка. Результат – еще 40 часов разработки.
При смене QA-специалиста также выяснилось, что документацию на том внутреннем проекте не вели. В итоге новый QA затратил еще 25 часов, чтобы разобраться в логике.
Проект потребовал 275 часов реализации: вышел из запланированных двух недель, бюджет превышен в два раза.

Выводы
Чтобы избежать подобных ситуаций на проекте, необходимо:
🔹 разработать и согласовать регламент передачи проекта;
🔹 закрепить ответственных специалистов за внутренними проектами, чтобы не «терять» осведомленность при передаче от одного к другому;
🔹 внедрить шаблон постановки задач, который никогда не помешает, а только упростит работу;
🔹 закрепить обязательный минимум по документированию, в том числе документ по погружению новых специалистов.

Очень часто мы можем сказать, что «проект простой, зачем там что-то усложнять, быстрее сделать, чем соблюдать правила и стандарты». В большинстве случаев такой проект вряд ли закончится успешно. Минимальные принципы и стандарты, от которых не стоит отступать, должны быть всегда, даже на внутренних проектах компании.

Нефункциональные требования
При проектировании системы чаще всего говорят о её функциональности: ключевая формулировка – «ИТ-продукт должен делать то-то и то-то».
🚢 Вспомним о Титанике. Можно ли сказать, что лайнер не выполнял свои функции? Нет. Он комфортно перевозил на своём борту более двух тысяч человек, обеспечивая их сервисом и развлечениями, но это не спасло его от трагедии.
Если не учитывать нефункциональные требования (НФТ), то ИТ-система может вдребезги разбиться о реалии своего существования. Нужно ли говорить о том, какие за этим стоят риски для бизнеса?

В сегодняшнем материале хотим разобрать три группы НФТ:
🔹 мощности и производительности;
🔹 безопасности, соответствию стандартам и законодательству;
🔹 переносимости и совместимости.
Приятным бонусом станут чек-листы, которые помогут сформулировать эти требования ☝️

Корпоративная культура в сложные времена
Мы чаще пишем о технологиях, но не забываем, что главное в командах – это люди, и сегодня наш пост об отношениях и поддержке. Начиная с пандемии нас окружают напряжённые новости, противоречивые мнения и разные способы переживаний эмоций.

Мы не оставляем сотрудников «вариться» в информационном поле без поддержки. Не рассыпаться помогают несколько лайфхаков:
🔹 Открыто говорим о сложном
Руководители подразделений пишут в нашу внутреннюю социальную сеть или отвечают на вопросы в прямой трансляции, групповых чатах или личных сообщениях.
🔹 Ведём здоровые коммуникации
– Не разжигаем споры и конфликты на острые социально-политические и национальные темы.
– Не распространяем информацию, которую не можем проверить.
Например, интерпретировать законы и постановления следует профессионалам: юристам, сотрудникам кадрового отдела, медикам и т.д. (в зависимости от ситуации). Личное толкование будет неверным решением.
💙 Поддерживаем друг друга
Для неформального общения строим целую «инфраструктуру»: встречи направлений офлайн и онлайн, более 30 секций и клубов по интересам. Это позволяет всем получать поддержку и быть на одной волне с командой.
И конечно, это не всё. Справиться с эмоциями или тревогами, если это нужно, помогают как руководители, так и квалифицированные психологи и HR-бизнес-партнёры (HR BP).

А какие способы поддержки команд помогают вам?

Быстрое создание мобильных решений: три лайфхака
Горизонт планирования сокращается, и похоже, с каждым днём всё больше. Мнением о том, как в этих условиях вести разработку (на примере мобильных приложений), поделился Ринат Шамшутдинов, руководитель направления мобильной разработки SimbirSoft.

Советы уже в Телеграфе, you are welcome✌️