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

Смотрите трансляцию:
— на канале 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✌️

Как найти подход к специалистам в команде? – отвечает Дмитрий Петерсон, операционный директор SimbirSoft.

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

Если вам интересно узнать больше о личном опыте тимлидов нашей компании – в комментариях оставим ссылки на интервью с ними и короткие описания :)