закрыть окно

Порционная работа.

  • Артем

  • 4

  • 21 Feb 2017

Порционная работа.

Сегодня я расскажу о распространенных ошибках со стороны клиентов которые мешают моей работе. Это будет довольно-таки познавательно.

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

Первая и самая главная ошибка которую может совершить клиент это порционные данные. Типичный пример из этого:

1.Представим вам дают ТЗ на просчет проекта. Вы просчитываете проект по ТЗ, отправляете клиенту цену и сроки. Со следующего дня начинается проект. Вы его разрабатываете, через два дня решаете спросить про мультиязычность, так как в верстке выбор языков есть, а ТЗ про это нет. Вы спрашиваете клиента, как так? В ТЗ же ведь этого не было? Спустя 30 минут споров клиент признает что в ТЗ этого не было, и готов за это доплатить. В чем здесь ошибка, в том что архитектура проекта строится впервые дни, на основе вводных данных.И если по умолчанию не было описано в необходимости мультиязычности, то добавить её в уже существующий проект довольно-таки сложно. В первую очередь это касается любителей Mysql. Так, как под каждую хотелку клиента приходится перестраивать базу. Для меня это конечно не новинка. Так как от клиента я ожидаю всего чего угодно. И в это не входит корректное ТЗ. И поэтому архитектура должна быть гибкой и расширяемой, и увы это касается и Mysql. Совет который я могу дать один, делайте правильную архитектуру и будьте готовы к подобному.

2.Второй случай ярко применим в принципе ко многим проектам. Примером можно назвать сколько угодно например: Клиент мне говорит просчитать проект по ТЗ, а после просчета говорит срочно начать писать backend. На мой вопрос, где верстка. Клиент утверждает что верстка не нужна.Я не стал ему расписывать лекцию почему верстка нужна, но опишу небольшую лекцию здесь.

Если вы посмотрите первый пункт, то будет ясно что не всегда все идет по ТЗ. И вообще глупо на это рассчитывать. Но особенно глупо писать backend без верстки. Потому что любите распараллеливать процесс сталкиваются обычно со следующими трудностями:

Во время верстки по желанию клиента добавили новые элементы, и теперь интегрировать её сложно, так как для этого нужно дописывать функционал.И тут дилемма по ТЗ вы не должны дописывать функционал, но в верстке он присутствует. И тут вариант всего один если у клиента есть деньги он за это доплатит, если у него денег нет вы будете делать бесплатно.

Я не люблю что-то делать бесплатно, поэтому всегда отправляю клиента за версткой. Но я отступаю от этого правила, когда бюджет клиента это позволяет.

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

4.У вас бывало такое вам скидывают ТЗ полностью, но мелочные моменты например в виде требуемой базы, или нужной формулы для просчета, их нет. И их требуется ждать. На самом деле ждать это еще самое меньшее из бед. Самое худшее это когда вам дают эти мелочи порционно, то есть сегодня скидывают базу, через два дня одну формулу, через два дня другую. И так допустим вы установили срок в 5 дней. И все эти 5 дней будут в ожидании. Когда такие моменты происходят я всегда честно говорю клиенту, что проект тормозится на срок пока он не предоставит все данные по проекту в нужном объёме.

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

Теги:работа,фриланс

Псс..... чувак, а записью поделится не хочешь?

Комментарии

  • xaker01 Батиенко 21.02.2017 16:53

    Часто, очень часто все эти пункты встречаются, почти с 80% клиентами...
    Любое обновление, "правки" сначала сбивают логику и очередность задач в голове, а потом уже и на код это влияет.

  • Федор Troitsky 26.02.2017 00:56

    1. Я думаю это хороший опыт для вас что задание нужно не просто взять и запилить, а прочитать, осмыслить и задать вопросы.
    2. Я не знаю как на планете ПХП но в моем мире можно писать бэкенд без дизайна потому что API. И еще потому, что опытный разработчик хорошо знает узкие места и задаст нужные вопросы. Умение думать и задавать нужные вопросы, вообще отличает опытного разработчика от начинающего. Это вам про 5 лет опыта.

  • Федор Troitsky 26.02.2017 01:31

    Предыдущий коммент, резковат. Погорячился. Конечно, как минимум мокапы должны быть до начала любых работ, просто для гарантии единого видения продукта. Однако, на своем опыте могу отметить, нормальное ТЗ как правило включает в себя пару основных мокапов, а если нет, вы должны сесть и сделать их, так чтобы найти общий язык с заказчиком, ТЗ для вас а не для него вобщем-то. Для бэкенда, достаточно пары вайрфреймов на основные места. Наш бэкендщик Паша отрывается от фронтенда на пару недель вперед легко. Пишет нам АПИ и документирует все что надо. Иногда случаются мелкие казусы, но в целом такой подход отлично работает, пока мы на фронте разбираем UX, user flow, прототипируем, делаем макеты, итд у него уже все готово и в тестах.
    Берите на вооружение =)

  • Noi Studio 27.02.2017 13:36

    По первому пункту.
    Есть две реалии студия(когда работает над проектом целая команда а не один человек) и один человек .
    В ситуации когда работает целая команда,думаю не нужно обьяснять что если что-то отсутствует то до разработчика этот проект не доходит,а так и остается не стадии уточнения вопросов.
    У меня не скрою,существуют моменты когда да я упускаю какие то моменты,и об этом собственно я и пишу в блоге.
    По второму пункту опять студия vs один человек .
    Поэтому с моей точки зрения мне комфортнее работать над проектом когда я вижу картину всю целиком,да я могу работать без верстки но как я указал у этих проектов ценовой порог совершенно другой.

Чтобы оставить комментарий вам нужно авторизоваться!