​​#полезное #импортозамещение

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

Поскольку тема импортозамещения сейчас актуальна, и у бизнеса есть такой запрос, будем делиться нашей экспертизой и практическим опытом. Сегодня затронем тему миграции из Oracle в PostgreSQL.

Для кого актуально?
Oracle – качественный инструмент, но дорогостоящий в лицензировании и поддержке. Не каждая компания может себе его позволить.
На фоне новостей об уходе из России тема миграции из Oracle на системы управления базами данных с открытым исходным кодом, прежде всего PostgreSQL, становится все более актуальной. Только за последний месяц количество поисковых запросов в wordstat.yandex по теме Postgres превысило 66 тысяч. Хотя переход на эту СУБД в России начался уже давно. В рамках концепции импортозамещения за последние несколько лет многие отечественные компании стали использовать PostgreSQL.

Почему Postgres подойдет для миграции из Oracle?
Postgres отличается высокой надежностью и хорошей производительностью. Сейчас это одна из самых продвинутых баз данных с открытым исходным кодом в мире. Среди известных мировых компаний, которые ей пользуются: Apple, Etsy, Red Hat, Skype, Spotify, Yahoo. В целом PostgreSQL подходит от небольших сайтов до крупных корпоративных баз данных.
Благодаря своим достоинствам PostgreSQL – отличная замена нишам, которые ранее занимал Oracle. Поскольку обе базы используют транзакционный лог для защиты информации, построены на версионных движках, поддерживают бекапы и репликацию.
👉 Postgres подходит для сложных операций с большими объемами постоянно обновляющихся данных. Система не подведет в чрезвычайных ситуациях.

Что потребуется для миграции на Postgres?
Сроки, объем задач, состав команды и общая стоимость проекта будут зависеть от множества факторов. Для каждого проекта мы подбираем аналитика, который готовит варианты индивидуального решения.

#статьи

Почему руководитель проекта должен обладать достаточной свободой?
В работе руководителя проекта (project manager, PM) многое зависит от объема фактически предоставленных прав. Ему необходимо давать указания и принимать локальные решения, чтобы действовать «здесь и сейчас» и достигать результатов.
Для выполнения своей роли project manager должен обладать определенным минимумом полномочий:
🔹 участвовать в формулировании проекта и ограничений;
🔹 иметь право голоса при назначении специалистов, ответственных за выполнение отдельных заданий;
🔹 поручать членам команды выполнение отдельных заданий;
🔹 получать информацию об указаниях и решениях, касающихся проекта;
🔹 проводить все совещания по проекту;
🔹 иметь право одобрения и приема результатов проекта или возвращения на доработку неудовлетворительно выполненных отдельных заданий.

Пример из нашей практики.
Клиент обратился к нам с целью создать дополнительный канал продаж для привлечения новых клиентов и увеличения продаж. При этом он не был уверен, что продукт решит эту задачу, и сказал об этом своему project manager’у.
PM принял решение выстроить работу по концепции Lean Startup: с минимальными затратами протестировать гипотезу о том, что приложение найдет свой отклик среди пользователей. Клиент принял это предложение. Но руководитель проекта понимал, что даже в таком варианте продукт может оказаться нежизнеспособным, если не будет интересен целевой аудитории. Он обсудил с командой вводные данные. Они подготовили новую идею и презентовали ее заказчику. Обновленная концепция продукта обеспечивала более широкий функционал и вариативность, а главное – позволяла клиенту самостоятельно тестировать подобные гипотезы, меняя тематику, целевую аудиторию и каналы распространения. Так произошел перезапуск идеи, или pivot – изменение направления стартапа с целью его дальнейшего развития и сохранения жизнеспособности. В результате уже через 1 месяц команда разработала MVP-версию продукта.
Клиент был доволен таким подходом: PM проявлял инициативность и принимал решения в интересах проекта. В дальнейшем мы реализовали с этим заказчиком еще не один проект.

Подобные результаты невозможны без достаточной свободы и самостоятельности в принятии решений у руководителя проекта. Подробнее о задачах и компетенциях project manager’а читайте в статье на нашем сайте. А если хотите почувствовать себя PM-супергероем – сохраняйте наш Telegram-стикерпак 🦸

#полезное

Чек-лист: что обсудить с подрядчиком перед предварительной оценкой ИТ-проекта
Рассказываем, какие особенности будущей ИТ-системы владельцу продукта важно обсудить с подрядчиком перед началом оценки проекта по фичам. Для наибольшей объективности мы рекомендуем клиентам оценить ответы вместе со своей командой.

Блок 1. Общее описание будущей ИТ-системы:
🔹 Какие задачи она должна решать?
🔹 Кто ей будет пользоваться, на каких устройствах и что можно будет делать с помощью этой ИТ-системы?
🔹 Требования к производительности и нагрузке системы. Интеграция с какими внешними и внутренними сервисами предполагается и т.п.
🔹 Есть ли у нее аналоги? Что в них нравится, а что нет?

Блок 2. Варианты сотрудничества:
🔹 Предполагаемые зоны ответственности и формат работы над системой
🔹 Будет ли команда заказчика принимать участие в разработке?
🔹 Были ли уже какие-то наработки?
🔹 Какие требования к code style, стандартам и сертификации предъявляются?

Блок 3. Реализация будущей ИТ-системы:
🔹 Ожидания по срокам и бюджету.
🔹 Предпочтения по архитектуре, стеку, фреймворкам, системе управления базами данных и т.п.
🔹 Есть ли брендбук для разработки дизайна?
🔹 Какую статистику/аналитику предполагается собирать? Планируется ли подключение внешних систем аналитики?
🔹 Требуется ли нагрузочное и автоматизированное тестирование?

Это базовый набор вопросов, и в зависимости от особенностей проекта он может изменяться и дополняться.

#статьи

VPN – это безопасно?
Делимся комментариями нашего руководителя направления IT Support Максима Закамскова для онлайн-журнала CHIP.

Правда ли, что VPN-сервисы продают трафик третьим лицам?
В соглашении с пользователем (EULA) сервис, как правило, указывает, какие данные он собирает и с какой целью использует. Например, ExpressVPN пишет, что не собирает и не регистрирует историю просмотров, направление трафика, содержание данных или DNS-запросы подписчиков, подключенных к VPN. Но во время регистрации могут собирать некоторую личную информацию, например, адрес электронной почты и платежную информацию, т.е. то, что необходимо для предоставления услуги.

Есть ли разница между бесплатными и платным VPN с точки зрения безопасности?
Разница между бесплатным и платным VPN может быть незначительной. Как правило, платный VPN предоставляет больший объем трафика и скорость подключения. Что касается безопасности, то ее может и не быть. При этом важно помнить, что приложения для VPN могут запрашивать самые разные разрешения в мобильном устройстве, например, доступ к звонкам/контактам/местоположению и прочие данные, и отказываться работать без их предоставления. Это может создать опасность утечки.

Насколько безопасно пользоваться банковскими приложениями, вводить пароли на других сайтах и в приложениях во время использования VPN?
С одной стороны, может показаться, что это безопасно, поскольку трафик между банковским приложением и информационной системой банка зашифрован отдельно. Но при использовании VPN нужно понимать, что в данном случае появляется дополнительный посредник в передаче трафика. Он может воспользоваться фактом прохождения «интересных данных» и попытаться провести атаку на них.


Чтобы ознакомиться с полной статьей, а также ответами специалистов из VK, REG.ru и других компаний, жмите на кнопку 👇

🧐А вы пользуетесь VPN?

#статьи #кейсы

Мы подготовили серию статей о зарубежном проекте, который ведем уже более 9 лет. Здесь будем публиковать резюме и прикреплять ссылку на полный материал, если вы захотите узнать подробности 💙

Почему добавление процессов и инструкций на проекте может быть эффективнее новых фич или технологий

Часть 1. Предыстория
Уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет ПО для госпиталей. Система обеспечивает ряд шагов бизнес-процесса. Общий программный комплекс состоит из 8 подпроектов. Алексей – наш программист – отвечает за 2 подпроекта и различные интеграции с другими.
На старте на разработку и саппорт накладывало свой отпечаток то, что мы «унаследовали» систему после нескольких предыдущих команд с разными подходами к организации работы. При этом саппорт состоял из трех линий:
1️⃣ Команда поддержки на телефоне и в чатах на стороне Великобритании: клиент создает задачу в Jira на доработку.
2️⃣ Технические специалисты на стороне клиента. Задача второй линии – провести исследование на боевом сервере, понять, что не так, суть ошибки и что надо сделать, чтобы улучшить ситуацию.
3️⃣ Наша команда. Задача третьей линии – реализовать кодовое изменение и сделать деплой улучшения на сервер.

Однажды глава третьей линии саппорта сообщил, что через пару месяцев покидает свою должность. После обсуждения было принято решение передать руководство нашему коллеге – Алексею.
На тот момент он работал с системой уже 7 лет и хорошо знал её особенности:
🔹 участвовал в разработке многих компонентов,
🔹 познакомился с профилированием производительности, использованием памяти диска, работой с базами данных,
🔹 изучил технологии LINQ (проект очень длительный, и в то время это была самая современная технология), Entity Framework, Dapper и многие другие вещи.
Нужно было срочно – за 6 недель – разобраться в подводных камнях, принимая проект от бывшего ведущего «саппортовца».

Завтра мы опубликуем вторую часть этой истории и расскажем, что предприняла наша команда, чтобы сократить время фикса проблем с 2–4 часов до 1 минуты. Уже сейчас вы можете прочитать полную статью в прикрепленной ссылке.

#статьи #кейсы

Значение процессов и инструкций на проекте

Начало истории в предыдущем посте.

Часть 2. Что мы сделали
Перед нами стояла задача быстро разобраться в подводных камнях поддержки масштабного проекта – более 100.000 строк C#. Это был сложный челлендж!
Итак, что мы делали:
1️⃣ Поняли, что мы постоянно имеем дело с внушительным объемом запросов от пользователей на саппорт и нужно что-то менять. Теперь при их выполнении собирали статистику по типам и частоте запросов.
2️⃣ Закрыли устаревшие задачи, которые были созданы более 2 месяцев назад. Вместе с тем нашли 30-40 задач без метки саппорта: выбрали их из треда «без метки», добавили метку – иначе они не отображались в задачах саппорта.
3️⃣ Нашли первое место для улучшения: сделали отдельный проект в Jira. До этого задачи саппорта создавались в том же проекте, что и задачи для разработки, но с пометкой Support.
4️⃣ Обновили админки во всех госпиталях до единой версии, так как она стала средством доставки фиксов. Сама админка не участвовала в бизнес-процессах, только настраивала их, поэтому можно было обновить все админки до последних версий.
5️⃣ На основании собранной статистики поняли: нужно временно начать перерабатывать, чтобы впоследствии ускорить работу. Иногда для ускорения каких-либо действий саппорта в таких длительных проектах нужно 3-4 часа программировать, чтобы потом сэкономить 5–7 минут при изучении определенных типов запросов, в первую очередь повторяющихся.
6️⃣ Создали специальную страницу-саппорт с инструкциями и готовыми кнопками: «Как фиксить различные классы проблем в админке». В итоге время фикса некоторых классов проблем сократилось с 2–4 часов до 1 минуты. Причем за 3 месяца по этому алгоритму не удалось исправить только один-единственный (!) баг.

Результаты
Самый главный результат – снизилась нагрузка на саппорт c 9–10 запросов в день до одного.
Как выглядел процесс создания задачи в саппорте ранее: Завести баг в джире, слинковать с джирой заказчика, передать на обработку, подтвердить закрытие, спросить у пользователя, закрыть в джире заказчика.
Как выглядит процесс теперь: Когда пользователь позвонил, сразу ввести номер пациента, нажать готовую кнопку для исправления бага, спросить пользователя о результатах.
➡️Это позволило 99% запросов исправлять за 1 минуту, и это могла делать первая линия саппорта. А после обновлений до последних версий многие баги исчезли. Вместо 12–16 часов на саппорт мы стали тратить всего 2 часа.
Также ежедневно отправляем автоматический отчет по всем задачам саппорта, которые находятся в реализации, в том числе просрочены более чем на 2 дня. Это позволяет понимать, какая задача «подвисла», мотивирует на поиск и устранение причин.

Выводы
1️⃣ Вопросам саппорта незаслуженно уделяют мало внимания, хотя работа с ними может серьезно улучшить процессы.
2️⃣ Добавление процессов и инструкций часто может быть более эффективным, чем введение новой фичи или технологии.
3️⃣ Затратив немного времени на обучение пользователей перед началом использования какой-то программы или оборудования, можно избежать многих проблем.

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

Также приглашаем поделиться впечатлениями, какие посты в Телеграме вам интереснее – короткие или длинные? А может быть, вы предпочитаете читать лонгриды, переходя по ссылке на сайт или Telegraph? Нам интересно и важно узнать ваше мнение 💙

#полезное

❓ Готовы ли вы к цифровой трансформации? Боитесь начать или столкнулись с какими-то проблемам в процессе?

Каждая компания подходит к цифровой трансформации с разных стартовых позиций. Поделимся опытом команды SimbirSoft и поговорим лишь о некоторых рисках, с которыми бизнес может столкнуться, а может и нет. Чуть подробнее рассказывали Rusbase.

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

Также на старте есть риск неверно обозначить показатели, по которым можно будет определить успешность проекта цифровизации. Избежать этого помогут регламенты и другие правила, рекомендации и инструкции, документация с четко прописанными KPI (дорожные карты, спринты и пр.), а также обучающие материалы для повышения квалификации сотрудников.

Управление этими рисками можно сделать легче, если использовать следующие инструменты (подходят для любого бизнеса):

📌CRM – для выстраивания системы взаимодействия с клиентами,
📌корпоративная база знаний – для хранения регламентов и другой информации, предназначенной сотрудникам компании,
📌таск-трекеры – для постановки задачи и контроля их исполнения подразделениями и ответственными лицами,
📌корпоративные мессенджеры – для обмена сообщениями и материалами между сотрудниками,
📌HR-системы – для автоматизации процесса отбора, найма, адаптации и управления персоналом, обеспечения контроля карьерного роста и развития сотрудников внутри компании,
📌инструменты шифрования и VPN – для безопасного подсоединения сотрудников к корпоративным системам и локальной сети, а также защиты информации.

✅При выборе ИТ-решения стоит отталкиваться от входных данных и имеющихся ресурсов компании, а также от планируемых целей и результатов. Прежде чем внедрять готовый инструмент, проведите предварительную оценку, во сколько вам обойдется его кастомизация с учетом специфики деятельности. Многие крупные компании пишут их под себя сами или заказывают ПО у опытных ИТ-партнеров, обладающих широкой экспертизой.

👉🏻 Главное – ИТ-решения должны окупиться и принести выгоды для бизнеса.

Аккаунт-менеджеры – люди, которые остаются на связи с клиентами в любое время и делают всё для комфортного и продуктивного взаимодействия на проекте. Этот пост посвящён именно им 💙
Что их вдохновляет? Как удаётся разбираться во всех тонкостях? Какие задачи выполняют? – В нашем видео из первых уст 😎

​​Продолжая разговор о CRM, хотим поделиться дизайном такой системы для одного из наших клиентов ✨

Наши специалисты разрабатывают интерфейсы и бережно упаковывают их в анимированные кейсы. Результаты работы вы можете увидеть на площадке Dribbble: https://s.simbirsoft.com/B7c6. В каждом видео вы найдете концепцию, основной функционал и детали.

Смотрите и делитесь своими впечатлениями 💥

#статьи

Ошибки бизнеса на IT-проектах. Часть 1
Операционный директор SimbirSoft Дмитрий Петерсон поделился с РБК.Pro, какие ошибки допускает бизнес на проектах разработки. О том, как избежать их, расскажем в следующем посте.

Ошибка №1. Отсутствие чёткого понимания целей проекта
Важно донести до подрядчика цели проекта, чтобы команда смогла выбрать оптимальное решение и план его реализации.
В целом оптимальна итеративная разработка, когда процесс поделен на небольшие этапы и по итогам их выполнения специалисты производят анализ промежуточных результатов. Это помогает снижать неопределённость и при необходимости корректировать требования к продукту.

Ошибка №2. Неполные требования к IT-продукту
Все предпочтения лучше обговорить до старта работ. Внимательно отнеситесь к вопросам команды и старайтесь отвечать на них детально.
Если уже по ходу проекта выяснится, что устройства имеют технические ограничения, то необходимо будет заново проводить аналитику задачи и изучать возможные риски. Скорее всего, это приведёт к увеличению стоимость и сроков проекта.

Ошибка №3. Несвоевременное предоставление необходимых ресурсов
Обратная связь по определённому комплексу работ или предоставление доступов к внутренним системам заказчика в некоторых случаях может занимать до месяца (!). В это время подрядчик будет вынужден выставить счёт за простой своих специалистов, а в крайнем случае – распустить команду.

Ошибка №4. Проблемы в коммуникациях
Не только руководитель команды разработки должен оперативно отвечать на вопросы и предоставлять необходимые разъяснения. Клиенту важно назначить со своей стороны человека, который будет связующим звеном с подрядчиком: например, сообщать об изменениях в базах данных или напоминать руководителю о необходимости выбора прототипов.
Двусторонняя заинтересованность во взаимодействии повышает продуктивность работы и атмосферу на проекте.

Ошибка №5. Избыточный контроль
Безусловно важно обговорить стртегически важные аспекты разработки будущего продукта, а также метрики промежуточного контроля. Но неоправданно высокое внимание клиента к тактике достижения результатов: например, методам решения задач – снижает уровень инициативности и демотивирует команду.

#статьи

Ошибки бизнеса на IT-проектах. Часть 2
При разработке IT-системы важна заинтересованность в качестве и успехе проекта как подрядчика, так и заказчика. Сегодня расскажем, как бизнес может помочь команде, чтобы работа над продуктом была продуктивной и результативной.

Совет №1. Точно определить требования к системе, расставить приоритеты и впоследствии своевременно сообщать об их изменении
Аналитику важно детально объяснить цель каждого требования к разрабатываемому ПО, чтобы он мог точно выразить его в спецификации. Тогда у команды на каждом этапе работы будет та информация, которая соответствует ожиданиям клиента.

Совет №2. Ознакомить аналитиков и разработчиков с особенностями бизнеса
Оптимальный вариант реализации проекта зависит от специфики бизнеса. Например, иногда лучше начать с адаптации действующего решения, чтобы обеспечить непрерывность бизнес-процессов. В других случаях подойдёт разработка MVP, чтобы проверить гипотезы в короткие сроки. К тому же, обратная связь сотрудников компании поможет получить более эффективное IT-решение, так как они знакомы с «внутренней кухней» бизнеса.

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

Совет №4. Стремиться к единому пониманию оценки и её наполнения и давать своевременную обратную связь
Эксперты подрядчика готовят детализацию оценки, декомпозируют крупные пласты работы на более мелкие задачи и предоставляют полную информацию об ограничениях и особенностях проекта. Когда некоторые пункты вызывают вопросы, исполнители обязаны дать необходимые пояснения. Если по итогам оценки клиент понимает, что он планировал затратить меньше ресурсов, возможно упростить структуру продукта или отказаться от менее важных функций.
Во время реализации команде также важно понимать, что она движется в правильном направлении. По ходу проекта у специалистов могут возникать и дополнительные предложения по улучшению продукта, которые они не смогут внедрить, если представитель заказчика не даст своевременную обратную связь.

Совет №5. Доверять профессионализму команды
Опытный подрядчик заинтересован в прогнозировании и предотвращении рисков, в обеспечении качества IT-решения и соблюдении требований заказчика. Он составляет различные чек-листы, чтобы ускорить разработку и избежать ошибок, а во время работы мониторит ключевые показатели эффективности.
Важно контролировать ключевые моменты и промежуточные результаты, но предоставлять свободу в методах их достижения в рамках оговорённых условий.

Напоминаем, что с полной статьёй вы можете ознакомиться здесь👇

#подкасты

Процесс онбординга в hh.ru
В нашем подкасте «Чистый код» вместе с руководителем мобильной разработки hh.ru Александром Блиновым мы поговорили о том, как сделать качественный мобильный продукт и что для этого необходимо. Здесь хотим поделиться фрагментом выпуска про онбординг – процесс включения сотрудника в рабочие процессы компании. Этот опыт будет полезен для любого бизнеса, где перед началом работы необходимо системное погружение новичка.

– В hh.ru процесс онбординга постепенно эволюционировал – сейчас это комплексная система. В продуктовой разработке кроме погружения в технологический стек, необходимо понимание бизнес-процессов на проекте. Чтобы сотрудник успел постичь всю информацию за 3–6 месяцев, мы разделили этот срок на части.
Для изучения технологической стороны и знакомством с продуктом мы подготовили презентацию, которая на данный момент насчитывает около 4 часов. Мы предлагаем изучить её за несколько дней. В каждую логическую часть мы поместили ту порцию информации, с которой человек может качественно ознакомиться: например, как устроен проект, как устроена биосистема и т.д.
После теоретического погружения мы предлагаем фичу для рефакторинга – перепроектирования кода. Для этого сотруднику не надо будет участвовать в бизнес-процессах, взаимодействовать с продакт-менеджером или дизайнером, он будет разбираться с чужим кодом и постигать самые сложные части нашего проекта: как работает многомодульность, стековая машина и т.д.
Уже после такого технического задания мы поручаем новичку разработку продуктовой фичи, где он погружается в бизнес-специфику. Чтобы сотруднику было легче входить в процессы, сначала он утром и вечером созванивается с тимлидом на ежедневной основе. Постепенно период увеличивается до двух дней, ещё позже – до двух недель. На таких встречах ментор помогает разбираться в проблемных вопросах и возникших трудностях. Благодаря этому сотрудник развивается.
Также в Miro мы подготовили разветвлённое дерево компетенций, после прохождения испытательного срока человек оценивает себя по нему. После ментор перепроверяет и анализирует эту информацию и отмечает те места, которые необходимо прокачивать для дальнейшего роста. При этом мы учитываем баланс внутри команды: кто-то может быть больше развит в аналитике, кто-то хорошо разбирается в биосистеме и т.д. В итоге мы получаем групповую синергию, когда каждый дополняет друг друга. Кроме того, это снижает bus factor («фактор автобуса») – так называют количество членов команды, при постоянном отсутствии которых работа попадет в кризисное положение.

Резюме:
1. Ознакомьте сотрудника с важными теоретическими аспектами работы и компанией в целом.
2. Определите для него набор задач, где он может не контактировать с клиентами или не включаться в основные бизнес-процессы для тренировки полученных знаний.
3. Поручите задачу, которая предполагает внедрение в общий процесс и взаимодействие с другими членами команды и/или вашими клиентами.
4. Составьте ИПР, который будет интересен для самого сотрудника и полезен в рамках вашего бизнеса.
На протяжении всего погружения приставленный ментор должен направлять нового сотрудника и помогать ему в возникающих сложностях.


Как вам кажется, такой процесс онбординга оптимален или некоторые этапы можно сократить?
😎 Чем быстрее включить сотрудника в полноценную работу, тем быстрее он вырастет как специалист.
😇 Надо давать новичку время, чтобы он в комфортном темпе ознакомился со спецификой бизнеса.

​​#статьи

Time&Material или Fixed Price?
Когда выгодно заказывать IT-продукт с повременной оплатой, а когда – по «фиксе»? В блоге наша команда PM разобрала по полочкам этот вопрос, все подробности вы можете прочитать по ссылке. В нашей выжимке – условия, при которых оптимален тот или иной вариант.

Fixed Price (фиксированная модель) подходит:
🔹для небольших проектов, продолжительность разработки которых не превышает трёх месяцев;
🔹если у клиента есть строго ограниченный бюджет, жесткие сроки (например, в государственных проектах) и чёткое видение результата, прописаны подробные требования к проекту и отсутствуют переменные факторы;
🔹если со стороны заказчика есть один человек, ответственный за принятие решений и приёмку конечного результата;
🔹если разрабатываемое решение прежде всего ориентировано на внутреннее пользование и нет большой необходимости учитывать мнение пользователей.

«Фикса» хорошо подходит для стандартизированных решений. К примеру, если у клиента есть необходимость переноса производственных процессов в коробочное решение без добавления дополнительного функционала.

Time&Material (повременная модель) подходит:
🔹для проектов любого масштаба длительностью от нескольких месяцев и выше;
🔹для проектов с гибкими требованиями, когда объём работ нельзя точно определить заранее и качество продукта – на первом месте;
🔹при создании уникальных IT-продуктов для внешней аудитории, когда при каждом принятии решения необходимо учитывать мнение пользователей;
🔹для проектов повышенной сложности – например, внедрение/изменение архитектуры существующего ПО в большой корпорации;
🔹когда есть проверенный подрядчик с большим опытом, широкой экспертизой и профессиональной командой.

T&M подходит проектам с высоким уровнем неопределенности, в том числе продуктовым.

Из практики
Одному нашему клиенту для собственного производства необходимо было разработать IT-решение для детектирования объектов, распознавания элементов продукции и их параметров. Реализация решения была основана на технологиях machine learning. Поскольку подобные задачи по своей природе можно назвать исследовательскими и невозможно точно оценить сроки и бюджет на реализацию таких уникальных IT-продуктов, совместно с клиентом выбрали формат работы – Т&М. Это позволило команде провести необходимые работы и определить наиболее эффективный подход в решении задачи. С клиентом согласовывалось время, которое можно затратить на исследования, и перечень задач, которые команда собирается исследовать в течение этого периода.
В результате заказчик понимал, сколько времени и средств занимает данная задача, мог планировать и контролировать затраты на реализацию проекта.