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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начали с формата удобного магазина «у дома» и пришли к одной из крупнейших ритейл-экосистем… Думаем, вы уже поняли: нашим новым партнером стала розничная сеть «Магнит»! Ее ежедневно посещает 16 миллионов человек, а наши разработчики, QA и SDET уже несколько месяцев работают над тем, чтобы сделать их покупки проще и удобнее. Следите за обновлениями! 😎

Поверхностная оценка задачи
Даже с опытными разработчиками такое случается: вначале кажется, что задача не займет много времени, а когда приступают к непосредственной реализации, оказывается, что не всё так просто.
Что думают про оценку задач наши коллеги?
💬При оценке я использую три основных критерия. Первый – выделенные ресурсы на решение задачи: есть ли все доступы, полное ли ТЗ и т.п. Второй – организация труда: приоритет задачи, необходимость коммуникаций в процессе её выполнения, бизнес-процессы и прочее. Третий – объём работ. Потом добавляю еще 30% времени на издержки: срочные созвоны, дополнительные вопросы, «падающие метеориты», попадание в «вечное Цукуёми» и другое.
Карина, frontend-разработчик

В помощь руководителю проекта, тимлиду, владельцу продукта
Как выглядят тревожные сигналы:
▪️ Задача выходит из запланированной оценки, исполнитель передвигает сроки.
▪️ Увеличились коммуникации по задаче у разработчика и аналитика или автора задачи.
▪️ Отмечается более двух возвратов одной задачи с тестирования или приёмки автором задачи.
▪️ В более чем 30% задач из бэклога нет описания или оно очень скудное.
Что делать в этой ситуации? Наиболее популярные методы:
▪️ При планировании обсуждать подводные камни задачи и задавать вопросы, всё ли понятно при реализации.
▪️ Подготовить шаблон задачи с минимальными сведениями, которые нужно указать в задаче.
▪️ Просить вести обсуждения не устно и в личных переписках, а в задаче.

На прошлой неделе мы писали о том, что делать если специалисты молчат о своих проблемах. А в статье 👇 есть продолжение про другие «горячие кейсы»:
🔹 Поставленная задача не совсем понятна.
🔹 Критика кода на проекте.
🔹 Долгий поиск решения.

Обычно мы про кейсы рассказываем, а вот сегодня про усиление команды hh.ru решили показать 📹
В видео аккаунт-менеджер Катя, мобильный разработчик Сергей и QA-специалист Яна делятся тем, как помогали развивать приложение «hh бизнес: поиск сотрудников». А в конце отзыв клиента о нас ещё можно послушать 🤗

А мы тут с нашими партнёрами вас поздравляем! 🎅🏼 Пусть вызовы оборачиваются для вас интересными находками и покорением новых вершин. И новогодние праздники мощно зарядят и вдохновят надолго-надолго! А мы командой SimbirSoft будем рядом, дальше стараться для вас.
Желаем вам самого душевного Нового года и шлём вам с этим постом миллион сердец! Спасибо, что вы с нами – мы это ценим 💙

​​Аудит процессов
Часто к аудиту процессов компанию подталкивают тревожные звоночки:
▪️ Рост дефектов на продакшене. Это влияет на отношение потребителей к продуктам – требует временных и финансовых затрат со стороны службы поддержки, команды разработки и тестирования.
▪️ Срыв сроков релизов важных фич. Также увеличивает временные и финансовые затраты, а также расходы на саму работу команды из-за частых овертаймов.
▪️ Невозможность оптимизировать работу команды из-за отсутствия метрик для оценки разработки, тестирования и качества продукта.

Но аудит можно проводить и в «спокойные» времена. Для чего это нужно?
➡️ Чтобы составить объективное понимание ситуации на проекте, выработать стратегический подход для внедрения улучшений, а также предложить метрики для контроля и оценки результатов.

Среди бизнес-результатов:
▪️ сокращение количества и критичности дефектов;
▪️ выявление дефектов на самых ранних стадиях разработки;
▪️ рост лояльности клиентов к продукту за счёт повышения качества и стабильности его работы;
▪️ увеличение попадания в оценку (благодаря снижению рисков) и скорости разработки, как следствие – снижение времени вывода ПО на рынок.

Аудиторами могут стать как внешние компании, так и сотрудники, обладающие необходимой экспертизой. Решить, что вам подойдет лучше, поможет таблица 👇 А бонусом публикуем чек-лист для внутреннего экспресс-аудита 👁

Адаптивная вёрстка
Адаптив для сайта как явление на языке мемов уже смело можно назвать «баяном», впервые в России он появился в 2012 году (10 лет назад, Карл!). И, наверное, вы подумали: «Да что тут читать? Даже у сайта булочной есть адаптив под мобильные устройства». Справедливое замечание...
Представьте наше удивление, когда за последние полгода чуть ли не каждый второй клиент обязательным требованием выставляет наличие адаптивной вёрстки для сайта. Удивляет нас это потому, что адаптив – опция «из коробки» для каждого нашего проекта, на которой мы даже не акцентируем внимание. Всем же понятно, что он должен быть. Оказывается, нет…

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