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

Мы не оставляем сотрудников «вариться» в информационном поле без поддержки. Не рассыпаться помогают несколько лайфхаков:
🔹 Открыто говорим о сложном
Руководители подразделений пишут в нашу внутреннюю социальную сеть или отвечают на вопросы в прямой трансляции, групповых чатах или личных сообщениях.
🔹 Ведём здоровые коммуникации
– Не разжигаем споры и конфликты на острые социально-политические и национальные темы.
– Не распространяем информацию, которую не можем проверить.
Например, интерпретировать законы и постановления следует профессионалам: юристам, сотрудникам кадрового отдела, медикам и т.д. (в зависимости от ситуации). Личное толкование будет неверным решением.
💙 Поддерживаем друг друга
Для неформального общения строим целую «инфраструктуру»: встречи направлений офлайн и онлайн, более 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. Это было тестирование системы.
…
Ну что, вскрываемся? – Все ответы здесь.

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

Тендеры в IT: чек-лист по подготовке
Что нужно для победы в тендере на долгосрочную разработку IT-продуктов?
🔹 Широкая техническая экспертиза,
🔹 несколько «касаний» с клиентом,
🔹 серьёзная подготовка к тендерной процедуре,
🔹 терпение (зачастую этот процесс занимает не один месяц).

В нашем блоге руководитель профильного комитета Вагиз Исхаков на примере участия в тендере «Татнефти» подготовил чек-лист по этому процессу. В нём:
➡️ выбор площадки,
➡️ выполнение условий участия,
➡️ обеспечение заявки,
➡️ прохождение аудита,
➡️ начало сотрудничества.

Здесь расскажем про выполнение условий участия – если вас заинтересует тема, переходите по ссылке и читайте полную версию.

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

Продолжение туть 👇😇

5 факторов риска на проектах: не очень приятно, но всё решаемо
Попросили наших проджект-менеджеров рассказать о рисковых аспектах на проектах. Почему они неприятны как для клиента, так и для управленца и как реагировать на них – в нашем сегодняшнем посте.

➡️ Фиксовый проект
Если стоимость проекта определена «раз и навсегда», а рынок потребует изменений уже по ходу проекта, внести их будет проблематично. При отсутствии гибкости и возможности воздействовать на продукт по факту можно получить то, что уже устарело.
Кажется, что «фикса» – это более предсказуемая модель работы, но на самом деле здесь большой риск несоответствия оценки и результата. Мы недавно рассказывали, как клиент недостаточно проинформировал команду на этапе аналитики и возникла необходимость непрерывной актуализации ТЗ. Это страшно и для клиента, и для PM, так как ограничения будут мешать развитию продукта.
Мы следуем правилу: обозначить риски сразу и «взвесить» другие подходящие модели работы, например, Time&Material с поэтапным планированием (по 2–4 недели).

➡️ Не согласованы критерии приёмки
Бывает так, что ожидания от «готового продукта» у клиента и команды разные. Например, в ТЗ допущены неточности, или имеются пункты, которые можно двояко истолковать. Соответственно, заказчик может планировать реализацию функционала, о котором команда даже не догадывается. Уже в финале проекта или итерации могут возникнуть серьезные противоречия и, как результат, не соответствующий ожиданиям продукт. Чтобы этого избежать, с клиентом до старта разработки должны быть согласованы тест-кейсы или чек-листы приёмки, при необходимости они могут быть дополнены пользовательскими инструкциями.

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

➡️ Клиент, не заинтересованный в проекте и не включённый в процесс разработки
«Обязанность» клиента – согласовывать проектные артефакты самому или делегировать эту задачу. Иначе есть риски: не тот результат, что нужен, и конфликты. На митинге по целям перед стартом проекта важно обсудить такие моменты: например, при долгом отсутствии апрува, проект придется приостановить. А это деньги – придётся собирать команду заново и тратить время на погружение специалистов. Обсуждая «на берегу» риски и связанные с ними расходы, как правило, команда быстрее находит взаимопонимание с клиентом.

➡️ Немотивированная команда
Если разработчик не хотел подключаться к проекту, он будет работать через внутреннее сопротивление и показывать не лучшие результаты. При подборе команды важно учитывать этот момент и поискать альтернативу. Чтобы поддерживать мотивацию уже в ходе проекта, некоторые наши ПМ организуют посиделки онлайн или офлайн, где команда может поболтать о чём-то своём, высказаться.
Также мы просим клиента в случае разногласий обсуждать их с ПМ, аккаунтом – не распространять на всю команду сразу. Во-первых, проблема может затрагивать одного человека, а остальных это просто демотивирует. Во-вторых, с разработчиками надо общаться нежно, они люди чувствительные 💙 А вот управленцы готовы к негативу, подойдут к ситуации с холодным умом и примут взвешенное решение.
А вообще подрядчика, конечно, лучше выбирать с устоявшейся корпоративной культурой, чтобы на клиенте этот фактор никак не сказывался, а всё решалось внутри компании (не на правах рекламы 🙂).

Как быстро усилить команду большого ИТ-проекта и уложиться в сроки
Дедлайн… Его пытаются отсрочить, отодвинуть и не видеть как можно дольше, если в команде есть сбои в процессах или другие неразрешенные проблемы. При этом пересмотреть сроки не так просто: релиз/демо/тестирование — всё расписано по дням, как и окончание стадии разработки.

Когда проблемы всплывают достаточно рано, ещё можно успеть скорректировать процессы, ускорить разработку user stories и прочее. Но что делать, если времени практически нет? Остаётся быстро усилить команду. На примере кейса фронтенд-разработчик Антон рассказывает, как максимально снизить издержки при этом.