Как работать с заказчиками, если ты дотошный, а они мыслят «в общем»?
Что-то вот сижу в субботу вечером, доделываю задачи за неделю. И на одном моменте в одном проекте я споткнулся о мысль, которая заставит меня переписать иначе всё, что я делал в нем до этого. Но это есть не проблема. А просто толчок к тому, чтобы посмотреть на ситуацию более глобально.
Работаю я в небольшой фирме PHP + JS кодером, больше у нас програмеров нет.
В вопросе написал "дотошный" - я в это слово вкладываю такую ситуацию, что ты когда делаешь работу, то продумываешь все возможные ситуации. Все, какие способен вообразить мозг (но наверняка не все, которые могут быть). Хочешь их должным образом обработать.
И вот как обычно это происходит у нас - приходит клиент, говорит "хочу такой вот сайт с такими то своими плюшками". Я прикидываю примерно по срокам - на их основании мы говорим цену заказчику. Он соглашается. Начинаем пилить. Обязательно возникает ряд моментов, когда заказчик желал "так-то", а по факту есть целый ряд обстоятельств, которые он просто не допускал в голове. У него всё было радужно, а тут оказывается, что, когда наступает необходимость детально и однозначно описать схему работы его гениальной идеи, возникает куча несовпадений, которые он не знает, как обыграть в его собственных "бизнес-процессах" (назовем их так).
Сейчас я заметил, что получается, что такие моменты сильно тормозят мою работу - я говорю одни сроки, потом возникают вот такие моменты, как я описал, но которые я не могу продумать изначально. Вот или не дорос я до того уровня, когда подводные камни для меня будут все как на ладони, или хз что еще. Тогда сроки раздуваются, соответственно стоимость проекта для фирмы понижается.
ТЗ составлять изначально это частично бы помогло, но только частично, потому что в плане архитектуры (насколько это слово применимо в рамках наших небольших проектов) тоже буду продумывать всё я, а значит также какие-то моменты будут упущены, а потом они вылезут боком.
Вообщем мне кажется, я что-то делаю не так. И наверняка же многие в такой ситуации были. Подскажите, что исправить?
UPD:
Всем спасибо за советы.
Все сошлись во мнении, что без ТЗ работа так и будет катиться в ад) В принципе это понятно, но если проект достаточно большой, то и ТЗ пишется не час и не полдня даже. То есть на его формирование уходит прилично времени, а это опять же деньги. Деньги, которые по идее нужно брать с заказчика - ему этот документ пригодится в любом случае - даже если ему не понравятся наши условия, которые мы назовем в конце написания задания, он может взять этот док и пойти к другому разработчику и стадия согласования задания будет уже пройдена. Но! Это понимаем мы сейчас здесь. А заказчик не особо хочет напрягаться с этим - для него "все легко и понятно, ведь ему нужна просто синхронизация с 1Ской" и неважно что стоковую для используемой CMS сюда не притянешь и за уши, ибо 1с конфа перепиленная вдоль и поперек, например.
Я искал как-то инфу по цене ТЗ. Выяснил, что 10% стоимости проекта это норм бюджет на ТЗ (разумеется, от проекта к проекту всё по-разному). Потом писал одному своему заказчику задание к его проекту, с ним плотно общались, выяснял как и что должно работать. Он остался вполне доволен, потому что потом проект ему делали другие разработчики, сделали на своё усмотрение некоторые вещи, но в ТЗ они были прописаны, заказчик в итоге получил в целом именно то что хотел, хоть и с нервами, ибо разрабы видимо прочли тз по диагонали)
Так вот я к чему - не каждый заказчик понимает необходимость ТЗ и готов отдать определенную сумму за его написание ДО старта работ и ДО того, как мы озвучим общую сумму. И на просторах СНГ я уверен у многих подобная ситуация, как вы в ней действуете?
> Вот или не дорос я до того уровня, когда подводные камни для меня будут все как на ладони
Ну, наверно, это так.
Вы уж определитесь, программист вы или кодер.
Программист - это конвертер из задачи в алгоритм, из одного мышления в другое. Кодер - конвертер из алгоритма в код, он должен с программистом работать, а не с заказчиком.
Если честно, ваш вопрос меня ставит в тупик, какие там подводные камни могут быть при обычной мирной веб-разработке на JS и PHP?! Я бы понял, если бы реверс-инжиниринг, или если бы заказы такие, что каждый день новая ОС, библиотека и т.д.
Есть выражение "инициатива ебет инициатора". Прекратите быть инициатором.
Делайте так, как хотел заказчик. Если его это не устроит, то пусть доплачивает за переделку.
Не знаю какой у вас там договор, и как вы оформляете на бумаге вашу разработку, но вы должны защищаться от подобных вещей.
Если вы не прорабатываете проект изначально, и даете сроки "примерно", то это целиком и полностью ваш косяк, и вы должны за него отвечать. Не умеете ставить сроки? Давайте срочки x2, x3, x5. До тех пор, пока не научитесь более-менее правильно определять.
вот вроде это и не инициатива, а дельные моменты, которые глупо было бы не рассматривать сразу - в коментах к первому ответу в теме я привел пример с сайтом аренды/продажи товаров.
Alex Me: я понимаю о чем вы. Такие вещи должны прорабатываться либо на этапе составления ТЗ сразу, либо должны закладываться в срок разработки.
Об этих моментах большинство заказчиков не думают, и это не их вина.
Именно для этого существуют специальные люди которые составляют ТЗ.
Если у вас нету таких людей, то просто закладывайте возможность таких "форс мажоров" в сроки разработки, и тогда не будет проблем.
Я работал с человеком, который находил мне заказчиков и вел с ними всю работу. Так вот, я прикидывал время проекта, допустим "неделя". Называл ему срок "2 недели". Он в свою очередь называл заказчику срок "месяц\полтора".
И это было совершенно нормально. А когда проект сдавался раньше срока, то заказчики были даже рады :)
Alex Me: но по большей части, когда во время разработки вы начинаете задавать подобные вопросы - вы выступаете инициатором, и вас будут ебать.
Тот же пример с арендой\продажей:
Вы могли сделать тупо "влоб", что товар бронируется с Х до Y, а затем становится доступным. Когда у заказчика возникнет вопрос: бляяя, у меня товара нет, а бронь уже снята, что делать? Вы могли бы попросить денюжку за доработку, так как этого не было в изначальном ТЗ.
D' Normalization: да, целенаправленно тз у нас никто не пишет. Ведем перед началом работы переписку почтовую с вопросами по проекту и потом эту переписку юзаем в качестве ТЗ. Именно вопросы логики действий выясняю я.
Вообщем видимо да, для меня возможность бороться с этим - пока что только длинными сроками
D' Normalization:
>>> Вы могли сделать тупо "влоб", что товар бронируется с Х до Y, а затем становится доступным. Когда у заказчика возникнет вопрос: бляяя, у меня товара нет, а бронь уже снята, что делать? Вы могли бы попросить денюжку за доработку, так как этого не было в изначальном ТЗ.
верно говорите)) я что-то потом сам перечитал и подумал "а какого я начал задавать эти вопросы, когда можно было сделать ровно как хотели"
Alex Me: проблема в основнои из-за отсутствия ТЗ, которое утверждаждается заказчиком.
Из-за вот таких вот "инициатив", зачастую у заказчика разгорается аппетит, и он начинает придумывать что-то вроде:
Да, теперь я вижу что нам нужно сделать ИИ для определения времени брони. Только сделайте его масштабируемым, и чтобы он мог предсказать конец света и скорость достаки почты России.
Нужно еще чтобы он мысли читал, и не давал сделать заказ если у клиента есть в мыслях "невернуть".
всего 2 недели разработки могут сэкономить целых 2 часа проектирования
Составляйте ТЗ либо самостоятельно, либо на пару с заказчиком. Пока у вас не закончатся вопросы - работа не начинается в принципе. Базовое проектирование "что-где" у вас будет происходить уже в этот момент.
Видно, что вы имеете опыт работы с заказчиками, но маленький опыт.
Все. что надо от заказчика в принципе - это только тематика. Остальное идут "заготовки", т.е. конкретно заточенные модули: надо звонок с сайта - да на (заказчик), влепим + 100 баксов; надо отзывы - пфф - извольте кушать 100 баксов; надо онлайн консультант с неограниченным количеством операторов, да еще свой, с хранением на своем сервере - да ладно, еще 250 баксов…
И с сроками будет все в порядке и уже готовый макет есть, осталось отдать дизайнеру, чтобы порезал по лекалам.
Предварительная сдача: тут может заказчик сказать, что вместо красного хочет пурпурный и место свежих товаров не справа - вверху а слева по центру - извольте 3 доработки за счет фирмы.
Остальные пупыр-шурупыр "чтобы тут было как там. но так чтобы было похоже вон на то, как здесь " - дополнительная оплата и естественно сроки.
Я не хочу ваше хобби принижать, вы возможно энтузиаст. Но сначала вы должны делать бизнес, чтобы нанимать верстальщиков чтобы из готовых модулей собирали проекты.
А для себя пробовать разные варианты, сочетания, разработку новых модулей. стилей, каркасов и пр..
если честно, я мало представляю, как я могу это применить у себя. Лебедев то может и знает сразу на 70% что будет в его дизайне. Но код мне сдается - это иная субстанция, она готовится не так.
dimonchik2013:
то есть в принципе те люди, которые сидят в компаниях и пишут свои ТЗ по 800 страниц тоже должны сразу проект видеть на 70%?
Я конечно не сравниваю свои задачи с такими, где нужно ТЗ на почти тысячу страниц, но и всё же не всегда просто формошлепством занимаюсь.
Вот была задача с сайтом где должна быть возможность аренды и продажи некоторых изделий. Вот вроде всё понятно - если есть заказ с 10 по 15 числа, то клиентам показывает что товар доступен до 9 включительно и с 16 включительно. Это были мысли заказчика. А потом пошли наши вопросы - что если клиент не отдал 15 вечером, а что будет, когда вы станете работать по всей стране и будете юзать не самовывоз, а службу доставки. Ок служба доставки дает свои сроки доставки, мы их можем учиывать, когда формируется заказ, но что если перевозчик задержит груз? А что если товар битый придет? И еще оочень много моментов. Но я не могу их все охватить, многие до меня доходят только когда я уже делаю реализацию задач.
У меня в одной из заметок есть следующая форлума "функционал = количество часов = количество денег". . Она означает, что конкретный функционал, например, интеграция сайта с facebook я делаю условно за 1,5 часа для стандартной CMS. Час моего времени стоит 600 рублей, значит, я эту задачу я должен взять с клиента 900 рублей = 600 руб/час * 1,5 часа.
Расписывай максимально детально свой функционал, т.е. что ты делаешь. В любом случае есть какие-то общие детали, которые ты делаешь из проекта в проект. Выведи за них время на основе своего опыта, добавь в свой личный список. Потом, когда клиент тебе говорит мне нужно один, два, три - достаешь свой перечень и говоришь на его основе сумму. Можешь добавить к итоговому ценнику коэфиценты. У меня, например, их два: копание в самописном движке + 40% и оплата сразу 100% суммы контракта -10%. Можешь для себя также сделать за сумму договора, за лояльность к клиенту, за то, что он привел друга к тебе... Это ограничивается только твоей фантазией.
Про договор ТЗ и растягивание сроков.
Все чего нет в ТЗ делается за дополнительную сумму. Если ты неправильно понял ТЗ - это твоя проблема, надо было уточнить, дописать формулировку в договор/приложение. Хочет человек что-то сверху оговоренного ранее - нет проблем, за доп.плату сделаем. Подписал человек акт - работа закончена, возобновление только по новому контракту.
Бесплатные правки и мелкие моменты...
В свою ставку я кладу 10% на вот такие мелкие доработи по ходу или в конце. Получается, что если общий договор у меня на сумму в 10 часов, то где-то час я могу потратить на все эти "Мне синий не нравится, давайте сделаем зеленый" или "Поменяйте эти два блока местами, а то смотриться как-то плохо" и т.п. Если все это дело выходит за 1 час, причем выходит уже сильно, тогда очень прозрачно намекаешь человеку что либо пускай останавливается, либо платит сверху.
Ну не хочет заказчик возиться с мелочами - и не надо.
Проблемы с дотошностью нет никакой.
Ты просто делаешь и предусматриваешь все ситуации.
Сам.
Проблемы подкрадываются с другой стороны - если заказчик все это не хочет оплачивать.
))))))))))))
Дотошность ведь это и очень большие затраты времени.
Сейчас работаю с двумя заказчиками - все уже по пять раз переделывал с нуля.
Самое главное - они за все это платят.
> И на просторах СНГ я уверен у многих подобная ситуация, как вы в ней действуете?
Без разницы.
И у нас и в Европе и в Америке - они все разные. Кто не хочет "переплачивать" за ТЗ, кто-то согласен без ТЗ работать и платить за каждую переделку, кто-то мозги по полгода выносит при составлении ТЗ/обсуждении проекта, на том получает ТЗ (бесплатно) и не заказывает работу (а судя по объявлениям этого заказчика и отсутствию изменений на домене заказчика - ищет еще исполнителей, кому будет выносить мозги, еще 2 года).
С азиатскими заказчиками не работал.
спасибо за ответ) лишний раз натолкнули на мысль - а стоит ли продолжать возиться с бытовым вебдевом, когда не получается всё решать "без лишнего гемора", или попробовать пойти в большую опенсорсную компанию и там пилить один большой проект на пару лет)
Alex Me: Ну это как посмотреть. У меня бытовой вебдев небольшой (интернет-магазин) пилится уже лет 10 под одного конкретного заказчика. Сейчас планируется очередной переход на очередную новую версию....
Alex Me:
Ну на совсем мелком бытовом веб-деве дотошность не окупается. Тут все уже стремятся наоборот, предлагать заказчику самому делать - я имею ввиду "конструкторы сайтов".
Я про "пару лет" не имел ввиду, что это страшно долго, да и в рамках большого опенсорса пару лет это не такой большой период. Я говорил о том, что там как раз может больше пригодится подход "со вниманием к деталям".
Но я могу тут ошибаться, я не работал в крупных компаниях еще =/
Alex Me: Я работал. Всех интересует результат. И большие и мелкие.
Но у крупных деталям уделяется чуток побольше времени. Ведь из-за косячка мелкого простой сайта с миллионом посетителей - это страшно.
