Comments 22
Вы меня, конечно, простите, но
клиент ожидал одного, а разработчики предполагали другое (все в договоре не пропишешь)— это абсурд. Все надо не в договоре прописывать, а ТЗ составлять грамотное. Прорисовывать прототипы, продумывать все нюансы, а не гнаться за сроками.
Хотите жизненный пример работы с одной из студий:
Договор, срок, цена, все обговорено — далее задержка на 2 недели по срокам, делают часть на собственном движке, требуют предоплату — оплачиваю, тут же как только деньги поступили говорят что они ошиблись со сроками и ценой за свою работу требуют в 3 раза больше оговоренного, при получении отказа говорят досвидание.
ИТОГО: Потрачено 4 недели в пустую, на руках 1/10 сайта на движке который никто не знает и минусом сумма денег.
Это к сведению о том, сколько стоят такие НЕуспешные проекты для заказчиков таких студий.
Договор, срок, цена, все обговорено — далее задержка на 2 недели по срокам, делают часть на собственном движке, требуют предоплату — оплачиваю, тут же как только деньги поступили говорят что они ошиблись со сроками и ценой за свою работу требуют в 3 раза больше оговоренного, при получении отказа говорят досвидание.
ИТОГО: Потрачено 4 недели в пустую, на руках 1/10 сайта на движке который никто не знает и минусом сумма денег.
Это к сведению о том, сколько стоят такие НЕуспешные проекты для заказчиков таких студий.
А как же договор где они обязаны сделать такой-то объем за такие-то деньги?
Спасибо за комментарий. Очень справедливо. Если есть еще примеры от заказчиков — присылайте. Попробую описать проблему и убытки заказчиков в случае затягивания сроков. Заказчик часто теряет не меньше, а даже больше.
а прототип делали — технические риски выясняли или сэкономили? Ни просто же так они потребовали в 3 раза больше денге, ни чем при этом не объяснив. Или просто так?
>>1/10 сайта на движке который никто не знает
А другие и не должны знать. Наличие известного движка — способ удовлетворить бедных заказчиков, которым тоже нужен очень-очень типичный сайт. Причем типичный с точки зрения разработчика.
И как так получилось, что вы получили именно 1\10: у вас 10 иттераций планировалось?
>>1/10 сайта на движке который никто не знает
А другие и не должны знать. Наличие известного движка — способ удовлетворить бедных заказчиков, которым тоже нужен очень-очень типичный сайт. Причем типичный с точки зрения разработчика.
И как так получилось, что вы получили именно 1\10: у вас 10 иттераций планировалось?
Думаю, имелось ввиду, что человек за предоплату получил 1/10 готового функционала. К примеру, только главную страницу (а не сделаны еще: и ЛК, и витрина, и выставление счетов, и т.д. до 10).
Наличие известного движка даст гарантию, что если что-то пошло не так во взаимоотношениях между заказчиком и исполнителем, то на любой фриланс бирже можно найти специалиста, который завершит начатую работу. Иначе нужно искать специалиста, готового разбираться с чужим самописным движком без документации и завершить начатую работу, а это дольше по времени поиска, исполнения и значительно дороже за единицу времени работы. Заказчику выше, в таком случае, проще выкинуть 1/10 и списать предоплату в убытки.
Наличие известного движка даст гарантию, что если что-то пошло не так во взаимоотношениях между заказчиком и исполнителем, то на любой фриланс бирже можно найти специалиста, который завершит начатую работу. Иначе нужно искать специалиста, готового разбираться с чужим самописным движком без документации и завершить начатую работу, а это дольше по времени поиска, исполнения и значительно дороже за единицу времени работы. Заказчику выше, в таком случае, проще выкинуть 1/10 и списать предоплату в убытки.
И еще про движок. Даже если проект выполнен успешно (сдан заказчику и получены деньги), но не мертв, рано или поздно заказчик вернется со словами: хочу это или вон то, или вот у движка *популярный_движок* есть функция выравнить текст, а в админке вашей такой функции нет, мы бы хотели добавить эту функцию (или выравнить конкретный текст). И вы расцениваете, что хотелка стоит 10 000 денег, в то время как для *популярный_движок* либо уже есть бесплатный/платный плагин с таким функционалом, либо его можно заказать у тех же фрилансеров или конкурирующих контор (если функционал требуется существенный), к примеру, за 4 000 или 8 000 денег, соответственно. Или вы говорите, что да, конечно, вы можете выравнять текст по ширине на конкретно этой странице — всего за 500-1000 денег. Или вставить видео — за 500-1000 денег. В то время как в *популярный движок* это уже встроенный функционал, с которым справится тот, в чьи обязанности входит работа с сайтом. А для вас это легкие бабки и пара строчек php-кода.
В общем, vendor lock-in, это потенциально опасная ситуация, а в случае с веб-студией — крайне высокорисковая ситуация.
В общем, vendor lock-in, это потенциально опасная ситуация, а в случае с веб-студией — крайне высокорисковая ситуация.
А в суд?
Вопрос на засыпку — у вас почасовая/попроектная заработная плата у всех, включая руководство?
И при этом по неудачному проекту оплата у всех идет не зависимо от того, идет ли вообще работа или зависло что-то?
Как-то странно это. У студии (у которой сотрудники в офисе) — большинство затрат постоянные и мало зависят от количества проектов. Если все сотрудники на удалёнке и с почасовой оплатой (хотя для руководства это нереально) — тогда оплата не должна идти когда нет работы у конкретного сотрудника. А если работы слишком много — тоже смысла нет её продолжать и увеличивать расходы, пока уже сделанное не оплатят.
Как правило, производительность ограничивается не общим количеством заказов — а объемом поступающих новых. Так что убыточный заказ не должен уменьшать число успешных в других месяцах, он будет идти параллельно.
Недополученная прибыль — да, некоторые переработки — возможны (для этого в стоимость проекта закладывается страховая сумма), отсутствие оплаты — возможно (для этого обычно берут 50% предоплаты). Выводы в целом правильные, но калькуляция явно требует пересчета — с учетом возможности управлять рисками.
И при этом по неудачному проекту оплата у всех идет не зависимо от того, идет ли вообще работа или зависло что-то?
Как-то странно это. У студии (у которой сотрудники в офисе) — большинство затрат постоянные и мало зависят от количества проектов. Если все сотрудники на удалёнке и с почасовой оплатой (хотя для руководства это нереально) — тогда оплата не должна идти когда нет работы у конкретного сотрудника. А если работы слишком много — тоже смысла нет её продолжать и увеличивать расходы, пока уже сделанное не оплатят.
Как правило, производительность ограничивается не общим количеством заказов — а объемом поступающих новых. Так что убыточный заказ не должен уменьшать число успешных в других месяцах, он будет идти параллельно.
Недополученная прибыль — да, некоторые переработки — возможны (для этого в стоимость проекта закладывается страховая сумма), отсутствие оплаты — возможно (для этого обычно берут 50% предоплаты). Выводы в целом правильные, но калькуляция явно требует пересчета — с учетом возможности управлять рисками.
Вообще-то расчеты и выводы по крайней мере странные.
Во-первых, если закладывать прибыль на 100% от себестоимости, то можно и два провальных проектов иметь и выходить в ноль, что в принципе уже является принципом безубыточности и во многих отраслях это является хорошим признаком.
Во-вторых, четыре месяца делать проект не фиксируя поэтапную оплату, даже хуже, не беря предоплату — это в какой такой волшебной стране?
В-третьих, «проваливать» проект 4 месяца — это всё-таки ни в какие ворота. Или над этим проектом работают люди далекие от разработки, и надо делать чистки в рядах. Или этот проект не по силам пока студии, но является по каким-то причинам приоритетными и эти убытки можно списывать на ивестиции в более светлое будущее.
Какие-то взятые с потолка цифры не описывают всей ситуации и выводы тут:
Работая у вас менеджером и руководствуясь такими принципами я бы отбирал проекты для студии максимально типичные и максимально простые, которые по сути уже готовы. Высылал бы ТЗ максимально шаблонизированное, т.е. по сути поменять названия и всё. При попытке клиента заказать что-то определенно другое, действовал бы поэтапно. Вначале, попытки склонить к существующему варианту. При неудаче, обозвать этот проект уникальным и, взвинтив ценник, предложить почасовую оплату. Клиент или отвалится, или закабалится.
Во-первых, если закладывать прибыль на 100% от себестоимости, то можно и два провальных проектов иметь и выходить в ноль, что в принципе уже является принципом безубыточности и во многих отраслях это является хорошим признаком.
Во-вторых, четыре месяца делать проект не фиксируя поэтапную оплату, даже хуже, не беря предоплату — это в какой такой волшебной стране?
В-третьих, «проваливать» проект 4 месяца — это всё-таки ни в какие ворота. Или над этим проектом работают люди далекие от разработки, и надо делать чистки в рядах. Или этот проект не по силам пока студии, но является по каким-то причинам приоритетными и эти убытки можно списывать на ивестиции в более светлое будущее.
Какие-то взятые с потолка цифры не описывают всей ситуации и выводы тут:
- Делай, что уже умеешь. Что не умеешь делать, за то не берись.
- Скорость важнее всего.
- Лучше много мелких проектов, чем несколько больших.
- Переложите вашу эффективность на плечи заказчика используя почасовую оплату.
Работая у вас менеджером и руководствуясь такими принципами я бы отбирал проекты для студии максимально типичные и максимально простые, которые по сути уже готовы. Высылал бы ТЗ максимально шаблонизированное, т.е. по сути поменять названия и всё. При попытке клиента заказать что-то определенно другое, действовал бы поэтапно. Вначале, попытки склонить к существующему варианту. При неудаче, обозвать этот проект уникальным и, взвинтив ценник, предложить почасовую оплату. Клиент или отвалится, или закабалится.
Не совсем так )
— Можно закладывать и 200% процентов, но попробуйте найти заказчика с такими ценами.
— 4 месяца проект не делается. По расчету он делается один месяц и растягивается на 4 в случае наличия проблем в проекте.
— Проект проваливается очень быстро, а вот тянется он долго (если усреднить, то в 4 раза дольше чем делается)
— Можно закладывать и 200% процентов, но попробуйте найти заказчика с такими ценами.
— 4 месяца проект не делается. По расчету он делается один месяц и растягивается на 4 в случае наличия проблем в проекте.
— Проект проваливается очень быстро, а вот тянется он долго (если усреднить, то в 4 раза дольше чем делается)
— Можно закладывать и 200% процентов, но попробуйте найти заказчика с такими ценами.
А уменьшить себестоимость на 25% или 50% соответственно?
— 4 месяца проект не делается. По расчету он делается один месяц и растягивается на 4 в случае наличия проблем в проекте.
— Проект проваливается очень быстро, а вот тянется он долго (если усреднить, то в 4 раза дольше чем делается)
Тут вопрос занятости. Например, вы начали разрабатывать проект и через 3 недели показали заказчику. В этот момент заказчик или говорит: «Ой не! Всё фигня!» и тут два пути, или он дает предоплату (что покрывает уже часть расходов) и вы продолжаете работать. Или не платит и вы в мусорное ведро выкидываете проект.
Мои принципы — это:
- очень внимательно следить за своими словами
- пресекать неясности с дополнительными хотелками клиента
- не бояться выкинуть проект
Например, если фактический расход уже превышает стоимость проекта (съедает всю прибыль), то проанализировать куда потрачено столько ресурсов. После этого, при дальнейшей разработке регистрировать каждый чих сделанный в сторону этого проекта. Можно заморозить проект на месяц, сделать быстро прибыльный за это время.
Рассматривать всегда каждый проект, как единственный, который у вас есть. Например, если я работаю только над одним проектом, то работая в убыток я не протяну 4 месяца. Мои ресурсы слишком ограничены чтобы тянуть эту лямку дальше. Мое поведение будет в крайней степени зависеть от этого, будет вполне логичным и для клиента.
Почасовая или не почасоватя, это среднего значения не меняет. Когда есть проблемные клиенты, они требуют участия команды. На первом этапе «проблемности» — менеджер пытается вытащить проект, выполняя силами разработчиков доработи, которые, как ему кажется, спасут проект. Это требует время и невозможность нормально делать другие проекты. На втором этапе проблемности — задействован менеджер, руководство что бы разобраться кто в действительности не прав. Эти часы стоят еще дороже для компании + тоже задействуют ресурсы разработчиков.
Производить более точный расчет — очень сложно. Были взять проекты из собственного опыта — длительные с большими бюджетами и типовые решения. Для всех проблемных — сроки затягивались примерно в 4 раза и наблюдался значительный провал побщей производительности.
Производить более точный расчет — очень сложно. Были взять проекты из собственного опыта — длительные с большими бюджетами и типовые решения. Для всех проблемных — сроки затягивались примерно в 4 раза и наблюдался значительный провал побщей производительности.
менеджер пытается вытащить проект, выполняя силами разработчиков доработки, которые, как ему кажется, спасут проект— т.е. уже наплевать на ТЗ, так? «Давайте мы вам еще календарик сделаем», так? Это очень недальновидный подход.
Я как-то участвовал в одном проекте, где ТЗ дописывалось по мере разработки. И вот где-то через полгода начали появляться требования диаметрально противоположные изначальным. Когда же был задан резонный вопрос «Чего собственно ради?» ответ заставил задуматься — «За время работы мы передумали и хотим чтобы сайт был такой, а не как был задумано изначально». Результат — прекращение сотрудничества.
Вы полностью правы ) Нужно контролировать ТЗ. И это важно не только для студии, но и для заказчика. Заказчик сам часто не догадывается, какие последствия тянут те или иные доработки по сайту в оргструктуре компании. Например подключить электронные платежи — задача не сложная, но что бы реально эта схема заработала на уровне всего бизнеса необходимо решить кучу смежных вопросов… а это тоже задерживает сдачу проекта и убытки соответственно.
ТЗ писать нужно, контролировать тоже. А начинающих менеджеров нужно учить. Для этого в статье есть наглядная демонстрация.
ТЗ писать нужно, контролировать тоже. А начинающих менеджеров нужно учить. Для этого в статье есть наглядная демонстрация.
Самое страшное просчитаться в сроках на огромном и сложном проекте. Мы как-то так попали: оценили очень большой проект, выставили стоимость, заключили договор, стали делать и в какой-то момент поняли, что сильно ошиблись в сроках реализации. А проект настолько большой, что над ним работала выделенная команда. В результате колоссальные убытки, ведь обязательства взяли, нужно сделать любой ценой и качество должно быть на уровне, любая работа — наше лицо. Проект дотянули, убыток получили большой, клиент остался недоволен из-за сильного срыва сроков (ему ж не объяснишь, что на самом деле он сильно сэкономил из-за нашей ошибки).
Как кто-то писал на Хабре: берем оценку программиста и умножаем на число пи :)
Как кто-то писал на Хабре: берем оценку программиста и умножаем на число пи :)
UFO just landed and posted this here
Тут еще важно НЕ принимать участие в конкурсах/тендерах. Проблема вот в чем: при оценке объемов проекта мы можем ошибиться в большую или меньшую сторону. При обычной деятельности эти ошибки компенсируют друг друга, а в (честных) конкурсах вероятнее всего побеждает тот, кто в данный момент ошибся сильнее прочих.
Убыточность таких проектов очевидна, однако не всегда можно понять, какой именно проект окажется НЕуспешным. Возможно, какую-то сумму на риски надо прописывать изначально в бюджет каждого проекта? А вообще, лучше всего достигать максимального понимания с заказчиком — что именно будет включено в проект, и что — нет. Рассказывать о дополнительных опциях и сразу оглашать стоимость таких дополнительных опций. Если не все такие моменты могут уместиться в договоре и ТЗ, то хотя бы устно. Если клиент вас понял, он вряд ли уже будет выдвигать требования, не умещающиеся в рамки оговоренных условий. Я вообще часто рисую на встречах с заказчиками. Когда они видят то, что получается в блокноте, как-то само собой выходит, что решаются множество неожиданных вопросов.
Sign up to leave a comment.
Сколько стоят НЕуспешные интернет-проекты для студии?