Это казалось отличной возможностью в то время. Деловой знакомый связался с вами с предложением какой-то контрактной работы. Это звучало идеально: вы приступили к работе над проектом, о котором всегда мечтали, без каких-либо проблем управления клиентом, с которыми обычно сталкиваются фрилансеры. Вы будете иметь дело только с руководителем проекта, делать отличную работу, получать деньги, и все это будет мило.
Но теперь вы работаете круглосуточно, чтобы вовремя доставить работу клиенту, несмотря на то, что эта работа практически не похожа на проект, который вы первоначально обсуждали. Сфера действия продолжает нарастать, оповещения об ошибках приходят все быстрее и быстрее, вы на три месяца старше первоначального срока, клиенты нервничают, хотя им еще предстоит предоставить вам различные фрагменты необходимой информации… и когда (если !) Вы когда-нибудь закончите, вам заплатят только то, что вы изначально оценили до начала работы (и все вышло из-под контроля).
Если вы когда-либо заключали контракты с кем-то еще, вы знаете, как трудно удержать контроль над проектом. Когда вы находите своих собственных внештатных клиентов, хотя вы должны нести бремя управления клиентом, вы также получаете преимущества контроля отношений. Но часто, когда фрилансеры заключают контракт с кем-то еще, становится трудно поддерживать этот уровень контроля. Они оказываются в положении «ресурса», а не «уважаемого профессионала», и оттуда все выходит из-под контроля.
В то же время в непредсказуемом мире веб-дизайна или разработки все может пойти и не получится. И слишком часто, руководитель проекта не по назначению указывает пальцем на его или ее штат сотрудников, кричащих: «Подрядчик сделал это!» Слишком часто подрядчик становится козлом отпущения.
Хорошая новость: это не должно быть так сложно! Независимые дизайнеры и разработчики могут защитить себя от опасностей заключения контрактов … как только они поймут, почему возникают эти проблемы, и поймут тактику, необходимую для борьбы с ними.
Цель этой статьи — объяснить некоторые из распространенных ошибок и определить тактику, которую вы можете использовать, чтобы защитить себя, когда в следующий раз окажетесь в сомнительной позиции «ресурса проекта».
Во-первых, мы рассмотрим виды ситуаций, в которых доверяющий подрядчик может непреднамеренно настроить себя для эксплуатации. Затем мы поговорим о решениях, показывающих, как именно каждая тактика может помочь вам ответить на сложные вопросы вашего менеджера проекта или самих клиентов.
Проблема
Часто подрядчики чувствуют, что у них мало или нет контроля над проектом — как мы уже говорили выше, они чувствуют, что они «просто ресурс». Это чувство может усилиться в ряде обстоятельств — обстоятельств, которых следует избегать подрядчикам! Давайте посмотрим на них сейчас.
- Неточные или несуществующие спецификации или брифинги
Часто клиент и менеджер проекта хотят начать работу как можно скорее. Итак, у вас есть встреча, вычеркните проект в очень грубом смысле, а затем кто-то спросит вас, сколько времени пройдет, прежде чем вы сможете «что-то нам передать».
В других случаях менеджер проекта уйдет, напишет спецификацию — спецификацию, которая может быть, а может и не быть настолько специфичной, какой вы хотели бы в идеале, — и она будет подписана клиентом еще до того, как у вас появится возможность спросить вопросов. Или, может быть, вам просто не нравится процесс определения объема работ, и, если вам захочется начать, начните до того, как проект будет подробно описан.
Очевидно, это рецепт катастрофы. Проекты нуждаются в четкой оценке, и, хотя сейчас это может показаться скучным, подробности о том, как именно должна работать система администрирования товарного запаса / функциональность Календаря последних новостей / средство поиска, окупятся — большие — когда наступят тяжелые времена.
- Сфера Creep
Эта проблема настолько распространена, что едва ли нуждается в обсуждении, однако ее распространенность в веб-индустрии указывает на то, что многие люди — от людей в крупных организациях до независимых фрилансеров — все еще борются с ползучестью.
Естественно, четкая, формально согласованная спецификация проекта проделывает очень долгий путь для решения этой проблемы, но очень важно поддерживать клиента в жестких условиях на протяжении всего процесса разработки. Однако могут возникнуть проблемы, когда вы «только подрядчик» и не имеете готового доступа к клиенту или его влияния.
- Отсутствие соглашения о сроках или необоснованных сроках
Клиент сказал: «Я хочу запуск в мае», менеджер проекта передал это вам, а вы сказали: «Нет проблем». Теперь вам интересно, о чем вы думали!
Возможно, ползучесть области добавила месяцы к сроку поставки. Возможно, вы исследовали разработку по ходу дела и, в отсутствие четкого плана разработки, теперь вы обнаруживаете, что разбираетесь с тысячами строк схематичного кода, который действительно только когда-то предназначался для использования в прототипе проекта, но теперь включает в себя тело вашей работы. Или, может быть, клиент позвонил руководителю проекта и сказал, что «через неделю состоится выставка, и нам бы очень хотелось, чтобы у нас было что-то удивительное — новый сайт был бы идеальным. ?» … и, как дурак, ты согласился!
Корень проблемы во всех сценариях — ожидания. Очень важно заранее определить ожидания относительно результатов и сроков, прежде чем работа начнется. Если вы не уверены в том, что можете предоставить временные рамки без проведения какого-либо исследования, важно сказать об этом — и прийти к соглашению относительно того, когда вы сможете предоставить временные рамки или оценку. И да, это применимо, даже если менеджер проекта первоначально обратился к вам со словами: «Мне нужно, чтобы кто-то создал этот веб-сайт с поддержкой электронной торговли за три месяца — вы можете это сделать?»
После того, как проект ограничен, у вас должно быть пространство для маневра с точки зрения того, что, в частности, когда доставляется.
- Неоплата
Плохо спланированные проекты часто приводят к неудовлетворенности клиентов. Это редкий тип менеджера проекта, который готов отказаться от более базовых аспектов управления проектом (определение проекта, заключение соглашений, получение письменного одобрения клиента и т. Д.), Но затем он может удовлетворить клиента, пока проект полностью завершается. рельсы. Скорее всего, они повернутся и обвинят «подрядчика», когда клиент начнет требовать то, что, по его мнению, обещал руководитель проекта.
Так что может случиться так, что даже после того, как вы сожгли всю полуночную нефть, которая у вас есть, сломали кишку и передали проект клиенту — поздно, но завершено (почти!) — клиент остается настолько разгневанным на то, как он Лечили, что они удерживают оплату.
Теперь, если у вас есть соответствующее соглашение с вашим руководителем проекта, вы можете убедить его заплатить вам независимо от того, получил он платеж или нет. Но если у вас есть всего несколько писем, в которых обсуждается ориентировочная цена, вам повезет, если вы вообще получите какой-либо платеж.
Это на самом деле произошло с моей подругой, которая заключала контракт на ее подругу. И хотя она очень доверяла и верила в эту дружбу и, когда клиент отказалась платить, поверила, что она получит вознаграждение, к сожалению, просто так не получилось. Если бы только у нее был подходящий контракт на месте …
- Отсутствие договорных обязательств
Контракты могут помочь гарантировать, что вам платят (или у вас есть законные средства правовой защиты, если вам не платят!), Но они служат ряду других целей.
Представьте, что вы разработали часть проекта, как обсуждалось (но не четко определено!), И после обзора клиент объявляет, что это «совсем не то, что мы имели в виду». Или, возможно, они просто решили, что функциональность не нужна. Кому принадлежит код? Если вы исследовали и разработали функциональность с нуля, им принадлежит идея? Или вы можете применить его к другому проекту, для которого вы можете получить отдачу от вложенных в него времени и энергии?
Ответ должен лежать в вашем соглашении о работе.
- Вопрос об ответственности
Возможно, когда вы согласились сделать работу, вы подумали, что сможете в течение нескольких недель бездельничать в своей студии в творческом тумане, кодировании или проектировании без перерыва. Это будет ваша ответственность — все остальное будет лежать у ног менеджера проекта, который вас нанял.
Подумай еще раз. Именно этот подход ведет многих ничего не подозревающих подрядчиков по пути к бессонным ночам, невыполненным обещаниям, невыгодным проектам и рабочим отношениям, которые страдают до такой степени, что становятся неприемлемыми.
Именно в этом вопросе — вопросе ответственности — и заключается решение проблемы подрядчика.
Решение
Для фрилансера, выступающего в качестве подрядчика, вопрос об ответственности может быть трудным для понимания. Кто пишет спецификацию: вы или руководитель проекта? Кто устанавливает сроки? Клиент или менеджер проекта? Вы получили право голоса? По каким вопросам? До или после того, как эти вопросы обсуждались менеджером проекта и клиентом?
Мы все знаем, что для любой технической работы важно заранее определить обязанности проекта и передать их соответствующим сторонам. Это правда, но туманная.
Как подрядчик может гарантировать, что они никогда не сгорят? Убедитесь, что вы берете на себя ответственность за каждую работу, которую вы выполняете.
Как показало это обсуждение, подрядчику слишком легко справиться с вину, если что-то пойдет не так. В ваших же интересах взять на себя полную ответственность за все, что вы делаете.
Это не означает, что вам нужно взять на себя обязанности менеджера проекта. Это не означает, что вы должны обойти менеджера проекта и иметь дело напрямую с клиентом, если это не является согласованной практикой работы. В конце концов, у менеджера проекта тоже есть работа.
Роль руководителя проекта
Менеджер проекта не существует исключительно для того, чтобы обеспечить хороший, дружественный буфер между вами и клиентом. Он также не может взять на себя ответственность за вашу работу.
Роль менеджера проекта заключается в управлении проектом:
- выяснить потребности клиента
- соответствовать этим потребностям с навыками проектирования и разработки в собранной команде проекта
- убедитесь, что команда проекта (даже если это команда из 1!) имеет все необходимое для выполнения работы в соответствии с высокими стандартами, в срок и в рамках бюджета
Для выполнения этих обязанностей руководителю проекта нужна ваша помощь — вот почему вы были наняты! Он или она нуждается в вас, чтобы принимать обоснованные решения о том, что достижимо. Если вы не чувствуете себя информированным, вам необходимо убедиться, что вы получили эту информацию: спросите менеджера проекта. Он или она хочет убедиться, что у вас есть то, что вам нужно для работы. Если вам не хватает чего-то, что вам нужно, сообщите менеджеру проекта!
В конечном счете, менеджер проекта хочет сделать клиента счастливым. Установление ожиданий, соблюдение сроков и результатов является критически важным для счастья клиента. Помогите руководителю проекта установить соответствующие ожидания и выполнить свои обещания, поддерживая открытый диалог.
Теперь, если у вас сложилось впечатление, что секрет работы с менеджером проекта — это общение, вы правы. Тем не менее, это правда, что обязанности менеджера проекта зашли так далеко.
Хотя руководитель проекта отвечает за то, чтобы команда выполняла проект в срок и в рамках бюджета, в конечном итоге именно команда должна выполнять поставленные задачи.
И, если вы собираетесь нести ответственность, вы должны убедиться, что вы можете придерживаться этих сроков и результатов.
Поэтому, прежде чем согласиться выполнить какое-либо задание — в любой момент процесса — вы должны убедиться, что руководитель проекта предоставил вам все необходимое для выполнения этого шага. Это практическое правило в равной степени относится и к оценке временных рамок, и к разработке самого проекта. Спросите, что вам нужно — подробную спецификацию, подписанные соглашения, согласованный срок — и убедитесь, что вы получите это. Только тогда вы сможете дать надежные обещания выполнить часть работы, уложиться в сроки и так далее.
Основы защиты подрядчика
Нетрудно предпринять шаги, которые гарантируют, что вы никогда не станете козлом отпущенного проекта. Фактически, эти практики должны стать частью вашей стандартной процедуры заключения контрактов. Следуйте простым принципам, изложенным ниже, и вы будете лучше защищены!
- Всегда заранее получайте краткую и / или четкую спецификацию, прежде чем что-то обещать, спроектировать или построить. Согласовать и подписать все стороны, включая клиента.
Этот документ позволит легко определить ползучесть области и оценить, следует ли добавить предлагаемые дополнения в область (и оценить стоимость!) Или отложить до следующего этапа работы.
- Проводить исследования и разработки одновременно? Найдите среду разработки, в которой вы уверены, что будете работать, а затем договоритесь с вашим руководителем проекта о плане, который соответствует развитию проекта в эту среду.
Если вы пробуете новый подход или структуру, сообщите об этом менеджеру проекта и постарайтесь встроить «жирный» в график разработки. Убедитесь, что вы разработали план, который, по вашему мнению, является управляемым и с которым вы можете работать.
- После того, как вы получите спецификацию, поработайте с менеджером проекта и клиентом, чтобы уточнить сроки, результаты, обязанности и моменты, в которые вы выставите счет за работу.
- Положите сроки, результаты, обязанности и детали выставления счетов в соглашение, и сделайте это подписанным всеми сторонами.
- В любой момент, когда вы чувствуете, что пытаетесь угадать кого-то или что-то, работаете без полной информации (или самой полной информации, которую можно получить) или у вас просто возникают вопросы, поговорите с вашим руководителем проекта. Если у вас есть проблема, они хотят знать об этом (на самом деле — они делают!).
Имейте в виду эти практические правила при выполнении контрактной работы, и вы сможете лучше выполнять свои обязательства.
Подрядчик Осторожно!
Приняв философию, согласно которой вы должны нести полную ответственность за свою роль в качестве подрядчика в любом проекте, вы почувствуете себя более уверенно, предпринимая шаги, чтобы гарантировать, что вы можете оправдать любое принятое вами решение или действие, которое вы совершили. принято, когда фишки не работают.
Чтобы привести вас в правильное состояние, вот несколько стандартных комментариев, которые вы можете услышать в своей контрактной роли (если вы еще не слышали их тысячу раз). Это комментарии, которые должны запустить ваш пульс … и увидеть, что вы делаете все возможное, чтобы обеспечить свою защиту.
- «Мне это нравится! Можем ли мы добавить эту функциональность в этот раздел… и это, и это? И если мы просто слегка его изменим…»
Ответ: «Хорошие предложения! Эти дополнения выходят за рамки текущей спецификации проекта, но не хотите ли вы, чтобы мы пересмотрели проект, чтобы включить их? Конечно, нам придется пересмотреть временные рамки и оценить, чтобы мы могли учесть все дополнения. «
- «Я видел это на сайте конкурента и действительно думаю, что мы могли бы использовать его на нашем…»
Ответ здесь должен быть таким же, как и выше, но, если ваша спецификация уже содержит функциональность, которая отвечает потребностям, которые будут удовлетворены предложенным клиентом дополнением, обязательно объясните это и спросите, какое решение они бы предпочли.
- «Где этот результат? Вы сказали, что он будет готов пять дней назад!»
Диапазон возможных ответов здесь велик, но суть в том, что каждый раз, когда вы изменяете область действия, пересматриваете свою временную шкалу, чтобы гарантировать, что работа может быть завершена в согласованные сроки, и при необходимости согласовывайте новые сроки.
Если вы сделали это, вы никогда не должны слышать этот вопрос. Даже если вы просто отстали из-за других обязательств, вы должны предупредить вашего руководителя проекта до даты поставки и сразу же после того, как вы отстаете , чтобы он или она могли скорректировать ожидания клиентов в отношении результата.
- «Извините. У нас сейчас финансовые трудности. Можем ли мы отложить этот платеж на месяц или два?»
Ответ: «Я боюсь, что наше соглашение о работе предусматривает, что я не могу продолжать работу до тех пор, пока этот счет не будет оплачен. Возможно, оплата в рассрочку будет проще для вас?»
Видеть? Время, которое вы потратили на написание этого соглашения в начале проекта, уже окупилось!
- «Клиент не доволен работой. Он очень расстроен из-за беготни, недопонимания, бесконечных технических трудностей и горячих проблем. Они хотят получить полное, пошаговое описание того, что происходит, черт возьми! «
Мой коллега когда-то был в положении, в котором ему было сделано это заявление. Он спокойно открыл свой ноутбук и начал составлять подробный список всех проблем, связанных с коммуникацией, задержкой информации, невозвращенным телефонным звонком и игнорируемой электронной почтой, которая передавалась между ним, менеджером проекта и клиентом … и при этом ясно продемонстрировал, что он вышел за рамки служебного долга, чтобы сделать проект успешным.
Сразу стало очевидно, что проблемы, с которыми столкнулся клиент, не имеют к нему никакого отношения. Но если бы у него не было этого бумажного следа (и его стремление сделать большую работу), чтобы защитить себя, он был бы в горячей воде.
Защити себя!
В мире внештатных или контрактных веб-разработок часто кажется, что вы несете ответственность за все. Ну, когда дело доходит до обещаний, которые вы дали, вы несете ответственность. Крайне важно, чтобы вы делали все, что в ваших силах, чтобы гарантировать, что вы можете предоставить именно то, на что заключили контракт, и что у вас есть соответствующая документация — и вы точно знаете, где вы находитесь — если что-то пойдет не так.