Я управлял консультированием компаний веб-разработки с середины 2001 до 2013 года. К 2006 компания, которую я начинала одна, стала достаточно развитой и мой муж присоединился к нам, чтобы работать на постоянной основе. Подавляющее большинство нашей работы представлял аутсорсинг — разработка проектов для дизайнерских агентств.
Мы выпустили наш первый продукт, Perch, как второстепенный проект нашего бизнеса. Сначала мы отдали на аутсорсинг только дизайн, но в дальнейшем все больше и больше стали полагаться на помощь извне для обеспечения развития.
Вот некоторые вещи, которые я поняла, будучи заказчиком.
Постоянно прогрессируйте!
Я всегда знала, что мы достаточно хорошо общались с нашими клиентами. Мы задавали вопросы и регулярно обновляли версию разрабатываемого проекта.
Как клиент, я теперь знаю, что, даже если я вижу, что код передан, и разработчик говорит, что все идет по плану, я не всегда могу правильно понять, на правильном ли они пути. Я видела, как некоторые этапы могли зависеть от окончания работы аутсорсингового проекта. Например, Вы могли бы купить рекламу, чтобы она вышла в то время, когда произойдет запланированное событие. Если рекламу нужно купить заранее, а сроки сдачи проекта затягиваются, то деньги на рекламу будут потрачены впустую. Из-за страха перед неизвестным и финансового риска проще прекратить работу с клиентом, который постоянно спрашивает, закончена ли работа.
Конечно, когда Вы предоставляете услугу, важно, чтобы Вы сделали то, что обещали сделать, к тому сроку, который был указан изначально.
Объясните, на что обратить внимание
Раньше мы часто негодовали на то, что клиенты никогда не просматривают или не проверяют работу, которую мы выполнили, несмотря на то, что мы развернули работу на подготовительных серверах и сделали ее доступной для максимально пристального обзора. Оглядываясь назад, я думаю, что мы сделали допущение, что у клиента должно быть время не только на то, чтобы проанализировать все, что мы разработали, но и вникать и оценивать для себя прогресс нашей работы.
Я могу оценить Trello с нескольких позиций и увидеть, что каждая конкретная задача в процессе разработки или уже выполнена.
Даже если у вашего клиента есть доступ к системе, и он может видеть все ваши апдейты, сделайте так, чтобы он мог видеть каждый отдельный кусочек выполненной работы в любой момент.
Сделайте затраты понятными
Как владелец бизнеса с реальным продуктом, я знаю миллион вещей, в работе над которыми мне требуется сторонняя помощь. Но нанимая консультанта на почасовую ставку (особенно, когда я не полностью понимаю объем задачи) немного страшновато. А что, если это стоит намного больше чем, я предположила, или то, в чем я действительно нуждаюсь, по сути — самая обыкновенная поддержка, не стоящая таких больших денег?
Если Вы можете сделать свои консалтинговые услуги более похожими на реальные продукты с точки зрения того, как Вы представляете их на рынке, Вы можете сделать жизнь намного более простой для владельцев бизнеса… которые в реальности не уверены, какой в действительно бюджет понадобиться и как оплачивать ваши труды.
Этот подход назвали “продуктизированным консалтингом”, он включает в себя пакетированные услуги, которые обычно завершались бы на почасовой ставке за определенную фиксированную цену за одну консультацию или месячную сделку.
Ставьте деловые цели выше совершенства
Возможно самая важная вещь, которую я узнала будучи клиентом, состоит в том, что часто «достаточно хорошо» это достаточно. Как разработчик, мне требовалось время на выполнение действительно отличной работы… все же часто я разочаровывалась, что нас просили срезать углы и не разрабатывать прекрасное решение, которое мы были уверены, будет лучше, чем описанное в изначальном брифе.
Я по-прежнему люблю, чтобы все было идеально. Иногда, однако, намного более важно получить что-то уже готовое и работающее, даже если это означает, что нужно принять немного грубую работу. Как пример, мы недавно восстановили внутреннюю систему, которая позволяет людям платить за наш продукт и получать лицензию. Для бизнеса и наших клиентов, важным элементов а нашем проекте были части, с которыми они взаимодействуют; грубые края были видимой проблемой только для нас, и мы можем подчистить их по мере разработки и внедрения улучшений.
Эффективный рабочий процесс с фрилансерами в этом направлении требует перемены мышления и подхода в определении и количестве квот на рабочие места. Одна из причин, по которой мы не хотели отправлять продукт «с кривыми краями» было то, что мы подписывали контракт на разработку конкретного продукта. Наша работа заканчивалась, когда проект запускался; мы знали, что то состояние, в котором проект запускался, часто после уже не изменялось. Теперь, когда мы нанимаем разработчиков, мы пытаемся найти людей, которые заинтересованы в длительном взаимодействии. Мы надеемся, что такое взаимодействие помогает им быть уверенными, что, когда мы просим их отправить что-то готовое, над чем они работали, это не конец их работы над проектом и мы не услышим от них «до свидания».
Если бы я писала кодекс для других людей, я думаю, я бы способствовала именно такому типу взаимодействия. Вместо того, чтобы протестовать против желания клиента, который хотел, чтобы я отправила что-то, что еще не было полностью готово, я попыталась бы донести до них, что «отправка», это еще не конец выполненной работы.
Счета — убийца отношений
Многие проблемы, обрисованные в общих чертах выше, усугубляются моделью разработка/отправка/выставление счета на проект. С момента, как окончательный счет не подлежит изменению до того, как работа будет выполнена, клиенты часто воспринимают счет, как способ держать нас на коротком поводке, пока какие-то вещи (которые возможно и не были включены первоначально) не бelen сделаны. Это — довольно неприятный способ работы, если Вы хотите создать прочные долгосрочные отношения.
Многие наши фрилансеры теперь выставляют счет еженедельно или каждые две недели в процессе работы над элементами нашего проекта. Мне действительно нравится такая модель.
Во многих отношениях клиента/разработчика существует дисбаланс. Клиент часто властен платить или не платить деньги разработчику до тех пор, пока собственные сотрудники не перепроверят всю работу. Разработчик же может быть единственным, кто посвящен в дело полностью и действительно понимает значительную часть бизнеса клиента. Поэтому часть тестирования со стороны исполнителя также должна оплачиваться.
Конечно, есть люди, которые будут плохо обращаться с разработчиками независимо от того, насколько трудную работу те выполнили, или насколько они хорошо общаются. Однако я думаю, что большинство отношений становятся напряженными из-за того, что агентство не формируют понятный формат выставления счета.
Лучше вместе
В конечном счете лучшие отношения клиента/разработчика должны быть взаимовыгодными; два бизнеса сотрудничают на пользу друг друга, понимая коммуникационные потребности друг друга и деловые цели.
