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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как уменьшить риск ошибок при переносе данных и попасть в ожидания клиента?
В новой статье на Хабре наш коллега Адель рассказывает, как можно решить проблему миграции чувствительных необработанных данных, которые на протяжении долгого времени заполнялись и хранились в Excel.

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

Разработка в условиях неопределённости
Клиент заказал доработку внутренней системы: необходимо было внедрить фичи из платного сервиса. Уже в ходе реализации стали возникать новые входящие требования – стало понятно, что клиент ожидал не просто переноса, а доработки фич. Так, возникла высокая степень технической неопределённости.

📌 Задача: Разработать IT-систему в данных условиях.

📝 Решение
Действие 1: настройка стабильной коммуникации
На старте проекта мы определили и зафиксировали каналы и формат коммуникации, а также круг лиц на стороне заказчика – экспертов-носителей необходимой информации. Стабильная коммуникация с ними была нужна уже на начальном этапе – сборе требований.
❗️ Проблема ❗️ Представители клиента были крайне загружены и периодически переносили встречи. При этом требования различных отделов часто не коррелировали между собой.
➡️ Перешли на планирование встреч через google-календарь. Выбрали постоянное время для созвонов, заранее обговаривали повестку и прописывали тайминг.
➡️ Ввели практику кросс-созвонов, чтобы обсуждать требования со всеми заинтересованными сторонами сразу.
➡️ Фиксировали письменно все достигнутые договоренности и дублировали их на почту.

Действие 2: переход с фиксированной схемы сотрудничества на Time&Material
Проект стартовал с классической фиксированной модели, где были обозначены следующие ограничения:
▪️ перечень разрабатываемых сервисов,
▪️ объём работ,
▪️ сроки и время работы,
▪️ стоимость работ.
❗️ Проблема ❗️ Клиент недостаточно проинформировал команду на этапе аналитики, а также добавлял новые требования к решению уже в ходе проекта – возникла необходимость непрерывной актуализации ТЗ.
➡️ Имея большой опыт работы с повышенными требованиями безопасности и координации этапов разработки, мы предложили переход на схему Time&Material с ориентацией на выстроенные бизнес-процессы клиента:
▪️ описали потенциальные риски;
▪️ четко сформулировали критерии приемки каждого этапа работ совместно с юридическими службами SimbirSoft и клиента;
▪️ произвели оценку для планирования бюджета разработки;
▪️ оговорили пути решения в случае превышения планируемого бюджета.
➡️ Переработали дорожную карту проекта, пофично декомпозируя задачи.
➡️ Непрерывно фиксировали входящие требования и исходящие предложения, актуализировали ТЗ по мере конкретизации требований.

✅ Ответ:
1 довольный клиент и завершенный в планируемые сроки проект.

Профилактика выгорания
Никакой теории, собрали в посте только личные советы наших менеджеров.

В спокойные времена
📎 Больше общаться. Если есть какое-то неудобство на проекте или во взаимоотношениях с командой, нужно обратиться к руководителю или аккаунту за советом. Ну и всё-таки важно выстраивать дружественный климат вокруг: то есть не надо замыкаться, чтобы самому себя не закапывать. Будьте открытыми: например, в чём-то просите помощи, если не успеваете, или поделитесь, что какие-то конкретные задачи вам нравятся больше. Возможно, это кому-то сложно, но надо стараться хотя бы начинать заниматься этим. Когда присутствует взаимная поддержка, выгорание случается реже или как минимум не в такой интенсивной форме.
📎 Планировать и приоритизировать. Внимательно относитесь к распределению задач, чтобы не загонять себя и не уходить в перегрузы. Оценивание своего времени – то, чему надо постоянно учиться. От проекта к проекту понимать, почему в этой ситуации я недооценил, сколько сложных задач подряд я могу решать без снижения эффективности. Может быть такое, что проект не требует напряжённой работы, но вы овертаймите из-за того, что выделили на задачу 4 часа, а не сделали её и за 7.
Если вы менеджер и понимаете, что никак не укладываетесь (или ваш сотрудник) – то делегируйте задачи, распределите их. Поможет декомпозиция: разбейте задачи на более мелкие, раздайте их остальным участникам процесса и контролируйте выполнение.
📎 Любить своё дело. Если получаете удовольствие от работы: вам это нравится, это ваше хобби – вы можете заниматься этим иногда почти круглосуточно.

Как оставаться оптимистичным, когда на проекте всё горит
📎 Быть в тонусе. Главное в этот момент – не расслабляться, чтобы принимать правильные решения, которые позволят решить ситуацию.
📎 Относиться с интересом. «Да неужели я этого не смогу сделать?!». Нужно попробовать воспринимать происходящее как уровень в игре, который никак не поддаётся. То есть смотреть на всё не только с позиции «надо», но и с желанием покорить эту гонку. Включить соревновательный дух.
📎 Не ограничиваться работой. Наша работа – часть жизни, но это не всё. Надо всегда понимать, даже если на проекте что-то получилось не так:
– вы способны (!) изменить ситуацию;
– у вас есть ваши семья, друзья, жизнь.
Если обстоятельства складываются так, что всё горит, просто обратите внимание, что это не смертельно и всё. Зачастую это помогает решить психологические проблемы и высвобождает свежие мысли :)
📎 Понимать клиента и оставаться профессионалом. Это достигается тренировками, опытом. Очень важно быть эмпатичным и с уважением относиться к переживаниям клиента. Ведь проект для него как ребёнок. Осознавая это, спокойнее относишься к претензиям с его стороны и не пытаешься во что бы то ни стало противопоставить ему своё экспертное мнение. Эмпатия играет большую роль.
Также важно профессионально объяснить причины ситуации и погрузить в план действий: например, в изменения процесса контроля. Тем самым вы показываете, что обстоятельства не хаотичны и вы управляете ими, работаете над конечным результатом.

Здесь мы собрали не самые типичные или общие рекомендации. Надеемся, что они откликнутся вам 💙 А если у вас есть свои способы, то предлагаем делиться ими в комментариях. Будем вместе гореть, но не выгорать внутри 💫

QA+SDET=QAA
Эта формула – наш ответ на усложнение задач, которые ставит перед собой бизнес. Мы задумались, как оптимизировать расходы на тестирование, и увидели новые возможности в роли QA-Fullstack, или QA Automation Engineer (QAA). Обучили QA-специалистов навыкам автоматизации и – вуаля! В обязанности QA-Fullstack теперь входят такие задачи, как улучшение процессов, контроль качества, тестирование и автоматизация тестирования.
🔹 Когда они могут существенно улучшить тестирование ПО и принести пользу?
🔹 Для каких задач и почему лучше обратиться к специалистам из SDET-направления?

Ответы в нашей статье на Хабре :)

Данетка История SimbirSoft
2003 год. Круиз по Волге. Человек в плаще и шляпе с чемоданом сидит на палубе под дождём несколько часов. Почему он там оказался?
…
У нас есть 3 подсказки:
1. В чемодане находилось GPS-устройство.
2. За человеком следили из офиса Ульяновска.
3. Это было тестирование системы.
…
Ну что, вскрываемся? – Все ответы здесь.

В этот пятничный вечер мы бы хотели узнать вас немного больше ☺️
И мы просим ответить вас всего лишь на один вопрос 💬