Комментарии 48
НЛО прилетело и опубликовало эту надпись здесь
Как-то не совсем понятно, почему изображается офис на картинке, а не общение с фрилансером или оффшор-конторой. Тогда бы было логичнее.
Почему то, мне знакома данная ситуация и думаю не только мне.
НЛО прилетело и опубликовало эту надпись здесь
Иногда, когда хочу заняться фрилансом, дабы отвлечься от основной работы. Все соглашения с клиентами я заключаю устно, так как проекты небольшие и сложности не представляют, но так как все мы люди, у клиента в последний момент или во время разработки возникает мысль внедрить что-то ещё, ну и если это не сложно, то почему бы и нет, но некоторые клиенты полагая, что можно сесть на шею начинают постоянно что-то просить добавить. Вот тут уже нужно уметь сказать просто, НЕТ!
НЛО прилетело и опубликовало эту надпись здесь
а за форум им доплатят?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
скверно то как. Хотя с таким дуболомством со стороны начальства бывает сталкивался, притом и с одной и с другой стороны.
Зато теперь начальник этих аутсорсеров будет всегда требовать ТЗ или хотябы договор
НЛО прилетело и опубликовало эту надпись здесь
эм… а что такое SLA?
НЛО прилетело и опубликовало эту надпись здесь
ITIL
Почитайте тоже, может быть очень полезно. SLA — одна из важнейших составляющих ITIL
Почитайте тоже, может быть очень полезно. SLA — одна из важнейших составляющих ITIL
SLA рулит фтопку. У меня ситуация с точностью до наоборот:
Есть SLA, договор и т.д. каждая деталь прописана, заявки документируются.
Призодит звонок (не заявка!) от клиента:
— «Срочно все бросай, надо то-то и то-то»
— Приеду послезавтра, я на другом объекте, по SLA время реакции на такой инцидент — неделя.
— Какая, нафиг, Саша, неделя! Говорю же что сейчас нужно!
— Мы же это обсуждали, в договоре прописано, приложение 1, сервис 15, уровень сервиса низкий, а значит неделя.
— Что ты меня паришь своими бумажками, что думаешь, я буду в них сидеть разбираться? Я тебе деньги плачу чтобы все работало. Мне пофиг что там понаписано. Приезжай сейчас и делай, если хочешь чтобы дальше мы вообще работали.
И что в таких ситуациях делать? Зато когда составляется SLA, и ты говоришь цены на высокие уровни сервиса — то всем пофиг, делаем самый низкий, за что тут платить, подождем если что.
Есть SLA, договор и т.д. каждая деталь прописана, заявки документируются.
Призодит звонок (не заявка!) от клиента:
— «Срочно все бросай, надо то-то и то-то»
— Приеду послезавтра, я на другом объекте, по SLA время реакции на такой инцидент — неделя.
— Какая, нафиг, Саша, неделя! Говорю же что сейчас нужно!
— Мы же это обсуждали, в договоре прописано, приложение 1, сервис 15, уровень сервиса низкий, а значит неделя.
— Что ты меня паришь своими бумажками, что думаешь, я буду в них сидеть разбираться? Я тебе деньги плачу чтобы все работало. Мне пофиг что там понаписано. Приезжай сейчас и делай, если хочешь чтобы дальше мы вообще работали.
И что в таких ситуациях делать? Зато когда составляется SLA, и ты говоришь цены на высокие уровни сервиса — то всем пофиг, делаем самый низкий, за что тут платить, подождем если что.
НЛО прилетело и опубликовало эту надпись здесь
за что тут платить, подождем если что
сие означает что заказчик не до конца понимает что он покупает. Повторить 10 раз при заключении договора не лишне. И перевести на язык покупателя.
Бумажки и в правду не стоит трясти, потому что они лишь фиксируют договоренность. Бывают конечно хитрецы, которые на «отношении» пытаются сэкономить, но большинство соблюдают устные договоренности. Если доходит до перечитывании SLA, то значить ее просто не читали и не объяснили по-началу.
К стати у меня было неоднократно что со временем SLA поднимали и цена при этом естественно росла. Заказчика надо обучать.
Да, бумаги вычитывают, без дополнительного пинка, только дважды прожжённые.
сие означает что заказчик не до конца понимает что он покупает. Повторить 10 раз при заключении договора не лишне. И перевести на язык покупателя.
Бумажки и в правду не стоит трясти, потому что они лишь фиксируют договоренность. Бывают конечно хитрецы, которые на «отношении» пытаются сэкономить, но большинство соблюдают устные договоренности. Если доходит до перечитывании SLA, то значить ее просто не читали и не объяснили по-началу.
К стати у меня было неоднократно что со временем SLA поднимали и цена при этом естественно росла. Заказчика надо обучать.
Да, бумаги вычитывают, без дополнительного пинка, только дважды прожжённые.
Да, это из разряда на «отношении» пытаются сэкономить
С такими надо быть вдвойне профи.
Вариантов собственно два:
либо сделать как хочет заказчик и вытащить стоимость издержек из него, либо сделать по контракту. В обоих случаях нехилые риски потерять либо денег, либо заказчика.
В крупной фирме, скорее всего затребуют гарантийное письмо на сверхконтрактные работы. Либо сделать, а потом перезаключить контракт с более строгой SLA = дороже.
Мелкой фирме или фрилансеру остается либо признать что деньги значительные, риски потерять их того не стоят и сделать как требует заказчик, либо «учить» — например вытянуть переписку, правильно отквотить, дабы было очевидно противоречие и отослать или сделать это устно.
Главное — обязательно выполнить все контрактные обязательства, как бы не складывались отношения в процессе, либо в соответствии контрактом его разорвать.
В целом такие заказчики рисковые — если они пытаются выиграть копейки на мелочи, то в случае серьезных проблем будет все намного хуже. Это важно, поскольку контракт обычно описывает рабочие процессы и очень редко когда закрывает все возможные прецеденты.
Вариантов собственно два:
либо сделать как хочет заказчик и вытащить стоимость издержек из него, либо сделать по контракту. В обоих случаях нехилые риски потерять либо денег, либо заказчика.
В крупной фирме, скорее всего затребуют гарантийное письмо на сверхконтрактные работы. Либо сделать, а потом перезаключить контракт с более строгой SLA = дороже.
Мелкой фирме или фрилансеру остается либо признать что деньги значительные, риски потерять их того не стоят и сделать как требует заказчик, либо «учить» — например вытянуть переписку, правильно отквотить, дабы было очевидно противоречие и отослать или сделать это устно.
Главное — обязательно выполнить все контрактные обязательства, как бы не складывались отношения в процессе, либо в соответствии контрактом его разорвать.
В целом такие заказчики рисковые — если они пытаются выиграть копейки на мелочи, то в случае серьезных проблем будет все намного хуже. Это важно, поскольку контракт обычно описывает рабочие процессы и очень редко когда закрывает все возможные прецеденты.
Я думаю, вполне логично, как и с любым товаром, любые бонусы были бы привлекательными. Поэтому не стоит говорить НЕТ — это самое неприятное, что можно сказать Вашему заказчику. Вот 2 тактических приема, которые я использую уже 7 лет для того, чтобы избежать подобных факторов, мешающих работе в удовольствие:
1. Даже если я ОЧЕНЬ уверен в том, что концепция проекта логична, все детали обговорены и я сам согласен и не имею противоречий, нужно убедить себя в том, что придется доделывать и переделывать — поэтому сроки и цену необходимо говорить с необходимым запасом. И в буквальном смысле понимать свои цифры как «цена за проект + несколько средних доработок». Когда речь пойдет о серьезных доработках, неглупый заказчик сам будет знатЬ, что это стоит денег. При этом он с удовольствием, и позитивно, и, главное, как само собой разумеющееся, примет вашу открытость к несложным доработкам и изменениям.
2. Не стоит прописывать цену за каждую мелочь и писать сверхдетальные спецификации с оценкой времени и стоимости. Поставьте себя на место заказчика! Это для него истинный тихий ужас. Я работаю с тремя заказчиками, занимающимися online-бизнесом в разных категориях, вот уже 7 лет, и практика подтверждает (думаю, каждый опытный фрилансер это подтвердит), что идея ВСЕГДА развивается по ходу ее реализации, по ходу тестирования самим заказчиком, после запуска и в течении жизни. Это нормально, и это даже интересно… если грамотно спланировать и выставить цену. Не нужно пугать заказчика словами «ок, это дополнение будет стоить еще 200 баксов» каждый раз, когда ему понадобиться что-то исправить. В конце концов, вы теряете свой следующий проект с ним, т.к. с Вами не очень то приятно работать. Куда проще заложить запас в стоимость, ведь практически всегда он будет востребован.
Надеюсь, моя точка зрения будет кому-то полезна, а кого-то натолкнет на размышления, но и критика приветствуется.
1. Даже если я ОЧЕНЬ уверен в том, что концепция проекта логична, все детали обговорены и я сам согласен и не имею противоречий, нужно убедить себя в том, что придется доделывать и переделывать — поэтому сроки и цену необходимо говорить с необходимым запасом. И в буквальном смысле понимать свои цифры как «цена за проект + несколько средних доработок». Когда речь пойдет о серьезных доработках, неглупый заказчик сам будет знатЬ, что это стоит денег. При этом он с удовольствием, и позитивно, и, главное, как само собой разумеющееся, примет вашу открытость к несложным доработкам и изменениям.
2. Не стоит прописывать цену за каждую мелочь и писать сверхдетальные спецификации с оценкой времени и стоимости. Поставьте себя на место заказчика! Это для него истинный тихий ужас. Я работаю с тремя заказчиками, занимающимися online-бизнесом в разных категориях, вот уже 7 лет, и практика подтверждает (думаю, каждый опытный фрилансер это подтвердит), что идея ВСЕГДА развивается по ходу ее реализации, по ходу тестирования самим заказчиком, после запуска и в течении жизни. Это нормально, и это даже интересно… если грамотно спланировать и выставить цену. Не нужно пугать заказчика словами «ок, это дополнение будет стоить еще 200 баксов» каждый раз, когда ему понадобиться что-то исправить. В конце концов, вы теряете свой следующий проект с ним, т.к. с Вами не очень то приятно работать. Куда проще заложить запас в стоимость, ведь практически всегда он будет востребован.
Надеюсь, моя точка зрения будет кому-то полезна, а кого-то натолкнет на размышления, но и критика приветствуется.
Категорически не согласен. Мы продаем свое время. Почему мы должны отдавать его бесплатно? Накручивать «подушки» — путь вникуда. Есть клиенты, которые доверяют Вам и сразу принимают работу, а есть пардон, у которых по каждой мелочи есть свое мнение. И на лбу у них при заклбючении контракта ненаписано кто есть кто. Получается с адекватного клиента мы сдерем неадекватно много. А с «вредного» будем иметь минусы. Разьве это честно?
Из моего опыта выхода два.
1. Если заказчик имеет желание развивать проект по мере разработки и не имеет ясной картины того, что мы делаем, мы всегда можем предложить ему работу в стиле экстримального программирования. Сколько работаем — столько оплачиваете.
2. Если же работа в стиле экстримального программирования заказчику кажется черным ящиком, то мы можем назвать точную сумму, но при этом прописать в ТЗ все, буквально до мелочей. Каждая фича, стоит времени разработчика. А время = деньги.
Это честно по отношению к обоим участникам сделки.
Из моего опыта выхода два.
1. Если заказчик имеет желание развивать проект по мере разработки и не имеет ясной картины того, что мы делаем, мы всегда можем предложить ему работу в стиле экстримального программирования. Сколько работаем — столько оплачиваете.
2. Если же работа в стиле экстримального программирования заказчику кажется черным ящиком, то мы можем назвать точную сумму, но при этом прописать в ТЗ все, буквально до мелочей. Каждая фича, стоит времени разработчика. А время = деньги.
Это честно по отношению к обоим участникам сделки.
В случае 1 из Вашего опыта — это нечестно по отношению к заказчику.
Случай 2 также не имеет практического смысла, как по мне, ведь большинство проектов даже в теории не могут быть предопределены с самого начала, т.к. должны корректироваться в соответствие с требованиями, изменяющимся пониманием проекта, запросами тех же пользователями, приходящими новыми идеями и т.п.
Я предлагаю в лице заказчика видеть не робота, который должен все знать, понимать, но при этом верить вам наслово — сколько и когда и как вы сделали. Куда выгоднее обрести в его лице человека, которому с Вами приятно работать — тогда творческий потенциал обоих открывается, и работать приятно.
Возможно, каждый подход заслуживает уважения. По крайней мере, за все годы опыта в очень серьезных проектах, моя точка зрения себя оправдывает на все 100: доволен и я деньгами, и зказчик работой, и при этом ему не впадло платить — ему это даже нравится, т.к. он получает человеческие условия; успешен проект и в ногу со временем; радуются пользователи. Что еще нужно?
Я думаю, можно описать все это одной простой фразой: «Превратим найм в сотрудничество». Не забывайте, что Вы кроме денег получаете опыт. Пусть даже в том, как наперед попытаться предугадать возможные развития событий; пусть в решении небольших разнообразных подзадач; в конце концов, опыт переделывать и доделывать. Ведь известно, что самая тяжелая и высокооплачиваемая работа — это доделать/изменить/переделать продукт, который делал другой developer. Поэтому опыт бесценный. его не купишь, и на него в любом случае уходит ВАШЕ время.
Случай 2 также не имеет практического смысла, как по мне, ведь большинство проектов даже в теории не могут быть предопределены с самого начала, т.к. должны корректироваться в соответствие с требованиями, изменяющимся пониманием проекта, запросами тех же пользователями, приходящими новыми идеями и т.п.
Я предлагаю в лице заказчика видеть не робота, который должен все знать, понимать, но при этом верить вам наслово — сколько и когда и как вы сделали. Куда выгоднее обрести в его лице человека, которому с Вами приятно работать — тогда творческий потенциал обоих открывается, и работать приятно.
Возможно, каждый подход заслуживает уважения. По крайней мере, за все годы опыта в очень серьезных проектах, моя точка зрения себя оправдывает на все 100: доволен и я деньгами, и зказчик работой, и при этом ему не впадло платить — ему это даже нравится, т.к. он получает человеческие условия; успешен проект и в ногу со временем; радуются пользователи. Что еще нужно?
Я думаю, можно описать все это одной простой фразой: «Превратим найм в сотрудничество». Не забывайте, что Вы кроме денег получаете опыт. Пусть даже в том, как наперед попытаться предугадать возможные развития событий; пусть в решении небольших разнообразных подзадач; в конце концов, опыт переделывать и доделывать. Ведь известно, что самая тяжелая и высокооплачиваемая работа — это доделать/изменить/переделать продукт, который делал другой developer. Поэтому опыт бесценный. его не купишь, и на него в любом случае уходит ВАШЕ время.
Насчет опыта согласен.
Однакож, объясните, почему 1 вариант нечестен?
Заказчик не знает чего хочет. Как мы можем сказать сколько это стоит? Мы предлагаем ему работать вместе. Знаком его лично с каждым программистом. Он лично видим и может пощупать итога работы каждого конкретного человека. Очень советую почитать на эту тему: ru.wikipedia.org/wiki/Экстремальное_программирование
Будущее оценки такого сложного процесса как разработка интеллектуальной собственности именно за такой методикой.
Вариант второй имеет смысл для мелких-средних проектов. Когда все определено. Если есть неопределенности — единственная правильная методика — п.п. 1
Ваш способ ведет к потереи либо клиента «слишком дорого», либо, что наивероятно, своего времени. Для начинающих это не страшно и даже полезно — опыт. Для крутых — это не страшно. Их имя — оправдывает любую сумму. А вот для средних студий, коих, думаю, большинство — он тупиковый.
Однакож, объясните, почему 1 вариант нечестен?
Заказчик не знает чего хочет. Как мы можем сказать сколько это стоит? Мы предлагаем ему работать вместе. Знаком его лично с каждым программистом. Он лично видим и может пощупать итога работы каждого конкретного человека. Очень советую почитать на эту тему: ru.wikipedia.org/wiki/Экстремальное_программирование
Будущее оценки такого сложного процесса как разработка интеллектуальной собственности именно за такой методикой.
Вариант второй имеет смысл для мелких-средних проектов. Когда все определено. Если есть неопределенности — единственная правильная методика — п.п. 1
Ваш способ ведет к потереи либо клиента «слишком дорого», либо, что наивероятно, своего времени. Для начинающих это не страшно и даже полезно — опыт. Для крутых — это не страшно. Их имя — оправдывает любую сумму. А вот для средних студий, коих, думаю, большинство — он тупиковый.
С экстремальным программированием знаком.
Спорить можно бесконечно. Мнений много. И, к сожалению, у каждого своя практика, и каждый по-своему прав. Не забудем, что у каждого проекта, в каждом направлении индустрии много особенностей — в итоге все перерождается в бесценный опыт, основанный на реальной работе — как случилось у нас с Вами.
У Вас получается делать так, как Вы предлагаете здесь. У меня по-своему тоже превосходно получается. Всего лишь хотел высказать свое видение. Но опровергать Ваше мнение даже не «не хочу», а не получится )
Спорить можно бесконечно. Мнений много. И, к сожалению, у каждого своя практика, и каждый по-своему прав. Не забудем, что у каждого проекта, в каждом направлении индустрии много особенностей — в итоге все перерождается в бесценный опыт, основанный на реальной работе — как случилось у нас с Вами.
У Вас получается делать так, как Вы предлагаете здесь. У меня по-своему тоже превосходно получается. Всего лишь хотел высказать свое видение. Но опровергать Ваше мнение даже не «не хочу», а не получится )
Так же добавлю, что зачастую бывают ситуации, когда сказать «нет» — это единственный правильный выход. Если Ваш подход был честным и адекватным, помыкавшись по другим и набравшись ума, заказчик снова вернется к Вам.
Касательно того, что мелкие переделки и неприятности все равно будут — тут я с Вами согласен. Я закладываю на них 10-15%. Если неприятности выходят на бОльшую сумму, то, как писал следует пересмотрать способ финансовых отношений. «Видимо, что-то случилось» :)))
НЛО прилетело и опубликовало эту надпись здесь
Гм, он как раз говорит правильные вещи.
А вы, как я понимаю, ровесник дедушки Ленина?
А вы, как я понимаю, ровесник дедушки Ленина?
Посмотрите статистику того же RantACoder-а: самой меньшей ценой берут только на очень простых, мелких и чисто техниеских проектах. Во всех остальных случаях цена — не первое, на что смотрят в Вашем биде. Оно и не удивительно. Зачем мне проект задешево, но сделанный через задницу, от кодера, который и вопросов то грамотно не задаст, а разобраться в бизнес-процессе — и подавно не сможет. Мне с этим проектом жить, его развивать и улучшать. Я даже больше скажу, сколько раз объяснял цену — почти всегда заказчики готовы поднять допустимый максимальный бид после логичных объяснений.
НЕТ — говорить стоит и нужно уметь это делать.
ставить себя на место заказчика — это вопрос спорный. ибо цель любого предпринимателя получить большее, заплатив за это как можно меньше. моя цель, как исполнителя — получить достойное вознаграждение за свою работу. поставив себя на место заказчика, я перечеркну свою цель.
есть техзадание, и по этому заданию определяется стоимость продукта/услуги.
любые, самые незначительные изменения должны оплачиваться. иначе вы рискуете попасть в вечное рабство мелких и бесплатных дополнений. ибо «идея ВСЕГДА развивается по ходу ее реализации», а процесс совершенствования бесконечен ;o). после нескольких таких дополнений, вам придется объяснять заказчику, что шара кончилась, а он будет требовать продолжения халявы. 90% на то, что вы расстанетесь врагами.
суть любого дополнения — это его необходимость. если с точки зрения заказчика, стоимость этой необходимости равна нулю, то ваш труд не только бесплатный, но и бессмысленный.
зы. если вы занимаетесь ремонтом квартир, то я с удовольствием обращусь к вам :o) у меня возникнет много идей по ходу работы :o)
ставить себя на место заказчика — это вопрос спорный. ибо цель любого предпринимателя получить большее, заплатив за это как можно меньше. моя цель, как исполнителя — получить достойное вознаграждение за свою работу. поставив себя на место заказчика, я перечеркну свою цель.
есть техзадание, и по этому заданию определяется стоимость продукта/услуги.
любые, самые незначительные изменения должны оплачиваться. иначе вы рискуете попасть в вечное рабство мелких и бесплатных дополнений. ибо «идея ВСЕГДА развивается по ходу ее реализации», а процесс совершенствования бесконечен ;o). после нескольких таких дополнений, вам придется объяснять заказчику, что шара кончилась, а он будет требовать продолжения халявы. 90% на то, что вы расстанетесь врагами.
суть любого дополнения — это его необходимость. если с точки зрения заказчика, стоимость этой необходимости равна нулю, то ваш труд не только бесплатный, но и бессмысленный.
зы. если вы занимаетесь ремонтом квартир, то я с удовольствием обращусь к вам :o) у меня возникнет много идей по ходу работы :o)
> Не стоит прописывать цену за каждую мелочь и писать сверхдетальные спецификации с оценкой времени и стоимости. Поставьте себя на место заказчика! Это для него истинный тихий ужас.
А отсутствие таких спецификаций и оценок — тихий ужас для исполнителя. Имхо, надо по-дефолту прописывать, а если заказчик уже зарекомендовал себя с хорошей стороны и с ним сложились нормальные отношения, то там уже можно и менее формально подходить к вопросу работ :).
А отсутствие таких спецификаций и оценок — тихий ужас для исполнителя. Имхо, надо по-дефолту прописывать, а если заказчик уже зарекомендовал себя с хорошей стороны и с ним сложились нормальные отношения, то там уже можно и менее формально подходить к вопросу работ :).
Как то взгрустнулось даже…
Жизненная ситуация.
Причем, как правило, чем меньше бюджет, тем больше бесплатных фич требует заказчик. Иными словами, порядочность в бизнесе прямо пропорциональна бюджету.
Причем, как правило, чем меньше бюджет, тем больше бесплатных фич требует заказчик. Иными словами, порядочность в бизнесе прямо пропорциональна бюджету.
Стандартная ошибка обещать неизвестно что. Которая, если подумать, означает безответственность. По опыту работы в больших проектах — это всегда стоит больших денег или неудовлетворения сторон. Во фрилансе приходиться говорить себе «это урок тебе на будущее» :)
Я очень терпимо отношусь к дополнениям, тем более они повод запросить дополнительные деньги или бонус, но всегда отвечаю что это зависит от изменений и заранее ничего обещать не могу. Буквально на прошлой неделе пришлось послать своего последнего индуса-заказчика, когда мы не сошлись во мнении на словах «небольшие изменения» и «недорого» ;)
Я очень терпимо отношусь к дополнениям, тем более они повод запросить дополнительные деньги или бонус, но всегда отвечаю что это зависит от изменений и заранее ничего обещать не могу. Буквально на прошлой неделе пришлось послать своего последнего индуса-заказчика, когда мы не сошлись во мнении на словах «небольшие изменения» и «недорого» ;)
— Если нужны будут какие-то небольшие изменения, ты же их сделаешь?
— Хорошо. Если мне нужны будут деньги, ты же мне их дашь?
— Ну я же не говорю, что нужно будет всё менять, так, может, одну-две странички…
— Я тоже не говорю, что мне нужно будет много денег, так, 100-200 долларов.
извинитие, точно анекдот не помню, сто лет назад слышал :)
— Хорошо. Если мне нужны будут деньги, ты же мне их дашь?
— Ну я же не говорю, что нужно будет всё менять, так, может, одну-две странички…
— Я тоже не говорю, что мне нужно будет много денег, так, 100-200 долларов.
извинитие, точно анекдот не помню, сто лет назад слышал :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Dilbert: изменения бесплатны