KODE 
Тендеры и лиды
Информация
Красивое портфолио и эффектная презентация почти не показывают, как подрядчик будет работать именно с вашей командой.
Это становится понятно только в реальной работе. Например, насколько быстро подрядчик замечает противоречия в требованиях, предупреждает ли о рисках заранее, умеет ли объяснить технические решения понятным языком и как ведёт себя, когда задача оказывается сложнее, чем казалось на первой встрече.
Поэтому перед большим контрактом я бы посмотрел на подрядчика на небольшой реальной задаче. Но пилот тоже нужно правильно организовать, иначе он легко создаст ложное ощущение надёжности.
Часто заказчики воспринимают пилот как маленькую копию будущей работы: взять несколько экранов, отдать их команде и посмотреть на результат.
Предположим, подрядчику передали готовый дизайн и подробное техническое задание на три экрана. Через две недели всё выглядит аккуратно, интерфейс работает, серьёзных ошибок нет. Из этого можно сделать вывод, что команда умеет реализовывать понятную задачу по готовому ТЗ. Но остаётся неизвестным, как она работает с неопределённостью, задаёт ли уточняющие вопросы, замечает ли риски, насколько реалистично оценивает сроки и как сообщает о проблемах.
Поэтому пилот лучше выбирать таким, чтобы он был похож на работу, которой подрядчик потом действительно будет заниматься.
Во время пилота я бы смотрел не только на готовый результат, но и на сам способ работы команды. Можно сдать задачу раньше срока и показать хорошее демо, но при этом неправильно понять часть требований, не зафиксировать принятые решения и провести тестирование силами того же разработчика, который писал функциональность.
Похожая ситуация была на одном из пилотов, где нашей команде передали разработку личного кабинета для B2B-сервиса. Демонстрация и приёмка прошли гладко. При более подробном разборе выяснилось, что часть решений по логике команда обсуждала между собой и нигде не фиксировала, функциональность тестировал тот же разработчик, который её реализовывал, а об ограничениях сторонних сервисов, из-за которых пришлось менять подход и увеличивать объём работ, заказчику не рассказали. Результат формально работал, но заказчик не знал о части решений и рисков, которые могли повлиять на дальнейшее развитие продукта.
Поэтому до старта полезно заранее понять, что именно вы хотите увидеть в процессе работы.
Хороший признак, если подрядчик задаёт вопросы. Причём не только технические. Ему важно понять, зачем нужна функция, кто ей будет пользоваться, какие ограничения есть у соседних процессов и почему задача сформулирована именно так.
Иногда заказчика это удивляет: он пришёл за разработкой, а подрядчик начинает обсуждать саму постановку. На мой взгляд, это скорее полезный сигнал.
Гораздо настороженнее я бы относился к ситуации, когда команда без вопросов принимает любое ТЗ и сразу называет точную стоимость и срок. На реальном проекте неопределённость всё равно появится. Если её не заметили в начале, она проявится позже, когда изменения будут стоить дороже.
Пилот даёт возможность сравнить первоначальную оценку с фактическим ходом работы. Подрядчик может назвать срок в две недели, а затем столкнуться с неожиданным ограничением интеграции или особенностью исходной системы. Само по себе это нормально.
Гораздо важнее, что команда делает после этого. Сообщает ли сразу, что срок нужно скорректировать, объясняет ли причину, предлагает ли варианты, если новая дата критична. Или заказчик узнаёт о проблеме только в день сдачи.
В одном из пилотов мы оценили интеграцию с внешней CRM в пять рабочих дней. По документации API задача выглядела довольно простой. На третий день выяснилось, что часть эндпоинтов работает не так, как описано, а нужные данные приходится получать другим способом. В тот же день заказчик получил информацию о проблеме, новой оценке в семь дней и вариантах на случай, если исходный срок критичен. В итоге интеграция действительно заняла семь дней, но всё это время заказчик понимал ситуацию и мог управлять ожиданиями внутри компании.
Такой эпизод обычно говорит о подрядчике больше, чем точное попадание в первоначальную оценку.
Почти любой проект в какой-то момент сталкивается с неожиданностями. Функция оказывается сложнее, чем предполагалось, сторонний сервис работает иначе, появляются ограничения, которых не было видно на старте.
Поэтому я бы внимательно смотрел на сроки и качество коммуникации. Если команда заранее сообщает о риске, объясняет последствия и предлагает варианты решения, заказчик может принять решение. Если о проблеме становится известно только перед дедлайном, управлять ситуацией уже значительно сложнее.
Даже когда итоговый результат одинаковый, качество работы подрядчика в этих двух случаях сильно отличается.
Демонстрация почти всегда показывает лучший момент проекта. Функция работает, интерфейс выглядит аккуратно, разработчик уверенно объясняет результат. Но после демо полезно понять, насколько решение готово к дальнейшей жизни.
Можно спросить, что произойдёт при изменении требований, сможет ли другой разработчик разобраться в коде, где описана архитектура, как запускается проект, как тестируется критичная функциональность, кому принадлежат доступы и насколько просто будет передать работу другой команде.
Часть этих вещей легко проверить уже за несколько недель. И для долгого проекта они могут оказаться гораздо важнее внешне удачной демонстрации.
Технически сильная команда не обязательно подходит конкретному бизнесу. Например, заказчику нужны небольшие релизы раз в две недели, постоянная обратная связь и активное участие собственной продуктовой команды, а подрядчик привык получать большое техническое задание и возвращаться с готовым результатом через месяц-полтора.
Ни одна из этих моделей сама по себе не плохая. Но вместе они могут работать тяжело.
На одном из проектов нас привлекли принять работу предыдущего подрядчика. Продуктовая команда заказчика жила двухнедельными спринтами и ожидала промежуточных демо, обсуждения приоритетов и возможности менять задачи по ходу работы. Подрядчик работал иначе: предпочитал получить ТЗ целиком и вернуться с результатом через месяц-полтора, сведя количество обсуждений к минимуму.
Пилот он выполнил неплохо, качество кода устраивало. Но уже за несколько недель стало понятно, что заказчик почти не может влиять на процесс. Для продукта с часто меняющимися приоритетами такой формат оказался неудобным.
И хорошо, что это выяснилось на небольшом этапе, а не через год, когда большая часть системы уже находилась бы у подрядчика и стоимость его замены значительно выросла.
Есть задача на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR? Создайте тендер и выберите подходящего исполнителя из откликов.
Заполнить заявку
13843 тендера
проведено за восемь лет работы нашего сайта.
Я бы не ставил перед пилотом задачу доказать, что подрядчик хороший. Его задача дать достаточно информации для решения.
Иногда после пилота стоит продолжить сотрудничество. Иногда поменять условия, состав команды или процесс. Иногда отказаться от подрядчика.
Такой результат тоже полезен.
Стоимость нескольких недель работы несопоставима со стоимостью ошибки на длинном проекте, куда уже вложены основной бюджет, инфраструктура и критичные части продукта.
В одном случае пилот занял у заказчика три недели и стоил примерно как один спринт. За это время стало понятно, что команда подрядчика привыкла самостоятельно принимать архитектурные решения, почти не фиксировала их в документации и часто ставила заказчика перед фактом, чтобы не тратить время на дополнительные согласования. Для конкретного проекта это было критично, потому что позже систему должна была забрать внутренняя команда разработки заказчика.
Сотрудничество завершили после пилота. Три недели и небольшой по сравнению с основным проектом бюджет позволили обнаружить несовпадение до того, как переход к другой команде стал бы дорогим и сложным.
Несколько недель не позволяют проверить всё. Трудно заранее понять, как команда будет работать через полгода, когда одновременно появятся десятки задач, несколько интеграций, срочные изменения и разные внутренние заказчики. Нельзя полноценно проверить и способность подрядчика сопровождать быстро растущую систему.
Поэтому пилот не даёт гарантии правильного выбора. Он помогает снизить неопределённость до того, как сотрудничество станет дорогим.
За это время можно довольно хорошо понять стиль коммуникации, подход к оценке, отношение к документации, работу с неопределённостью и то, насколько заказчику комфортно вместе с этой командой принимать решения.
До начала работ полезно договориться, что именно вы хотите проверить. Например, насколько хорошо команда понимает задачу, насколько её оценка совпадает с фактом, как она реагирует на изменения, когда сообщает о рисках, сама ли замечает проблемы, насколько понятно фиксирует решения и может ли заказчик контролировать происходящее.
Тогда после пилота разговор будет строиться на конкретных наблюдениях, а не на общем впечатлении в духе «вроде всё понравилось».
Скорость я бы точно не ставил на первое место. Быстро реализовать небольшую функцию сравнительно несложно. Гораздо важнее, сможет ли через полгода другой разработчик разобраться в решении, не придётся ли переписывать половину системы при каждом изменении требований и будет ли команда заранее сообщать о возникающих рисках.
После пилота я бы ответил на три вопроса. Получила ли компания нужный результат? Устроил ли её способ работы команды? Стало ли понятнее, как это сотрудничество будет выглядеть через полгода?
Если на последний вопрос ответа по-прежнему нет, с большим контрактом лучше не спешить, даже если демонстрация прошла отлично.
Подрядчик приносит в проект не только код, но и собственный способ принимать решения, планировать работу, обсуждать проблемы и взаимодействовать с командой заказчика. Пилот позволяет увидеть всё это до того, как цена ошибки станет слишком высокой.
