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

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

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

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

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

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 будем рядом, дальше стараться для вас.
Желаем вам самого душевного Нового года и шлём вам с этим постом миллион сердец! Спасибо, что вы с нами – мы это ценим 💙