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

📌 Задача: Разработать 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 и прочее. Но что делать, если времени практически нет? Остаётся быстро усилить команду. На примере кейса фронтенд-разработчик Антон рассказывает, как максимально снизить издержки при этом.

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

SimbirSoft — в списке лучших веб-разработчиков и интеграторов России 2022 по версии Tagline 🤟

На итоговую позицию в списке влияют бизнес-показатели, оценка портфолио, клиентского листа и других качественных параметров.

Уже более 5 лет являемся участником рейтинга и не собираемся останавливаться😎

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

Что по этому поводу думают наши коллеги?
💬«На моем прошлом проекте была внедрена интересная практика. Раз в две недели мы проводили созвон, на котором наш QA рассказывал о том, что его волнует на проекте с технической точки зрения и не только. Благодаря этим митингам мы смогли добавить много ценных фич». 
Александр, frontend-разработчик
💬«На мой взгляд, лучшее решение – проводить мероприятия наподобие ретроспективы с максимально дружелюбной обстановкой, где поощряются разговоры о проблемах и способах их решения. При этом важно опросить каждого участника. После этого озвученные проблемы нужно решить: чем больше, тем лучше. Все должны видеть, что этот инструмент работает».
Джан, frontend-разработчик

В помощь руководителю проекта, тимлиду, владельцу продукта
Как обнаружить такую ситуацию на своем проекте (тревожные сигналы):
🔹Ни у кого постоянно нет вопросов на ежедневных/общих митингах.
🔹Хорошо развиты коммуникации между отдельными ролями, но в общем чате всегда тишина.
🔹Перед релизом часто возникают вопросы, которые можно было решить раньше.
Что делать в этой ситуации? Наиболее популярные методы:
🔹Формировать культуру свободного, но контролируемого общения.
🔹Поощрять желание команды говорить о проблемах в начале работы над задачей и предлагать к ним решения.
🔹Ретро – один из важнейших инструментов. Необходимо сделать его рабочим за счет грамотного ведения, умения разговорить каждого члена команды и соблюдение договоренностей.
🔹Просить исполнителей своими словами описать, как они поняли ту или иную задачу, чтобы можно было вовремя скорректировать реализацию.