Комментарии 82
Спасибо кэп. Раньше бы, аналогично в ответ поплакался бы в жилетку. Сейчас понимаю, что подобных заказчиков нужно вежливо игнорировать.
Игнор действительно помогает.
Да, игнор помогает… Но как быть в том случае, если заказчик==начальник, а результат работы ждут другие сотрудники?
Можно упереться рогом, уткнуться в другие (и кстати, более важные задачи!) и ждать, когда задача опять «всплывет» и срок в две недели не будет казаться таким невероятным. Но конструктивно ли это?
Можно упереться рогом, уткнуться в другие (и кстати, более важные задачи!) и ждать, когда задача опять «всплывет» и срок в две недели не будет казаться таким невероятным. Но конструктивно ли это?
Как только начальник\заказчик поймёт, что нашёл фею, которая исполняет желания за дёшево, он тут же сядет и поскачет. Поэтому либо придерживаться реальных оценок, либо увольняться\игнорировать. Иначе вы в любом случае окажитесь виноватым.
Ну вот примерно такой расклад начальнику и показать. написать примерно — этот пункт столько, этот столько, если не верит. При такой детализации окажется еще что вы слишком оптимистично оцениваете.
Принцип 3-х гвоздей никто не отменял.
Игнорировать не надо, надо искать другой подход. Если, конечно, заказчик важен.
>> Он может ошибаться в сторону занижения сроков, но в сторону завышения — почти никогда.
Это пока он неопытный, и еще не научился называть сроки с запасом на форс-мажорные обстоятельства.
Это пока он неопытный, и еще не научился называть сроки с запасом на форс-мажорные обстоятельства.
Может, я чего-то не понял, но по-моему, статья именно эту ситуацию и иллюстрирует.
И сколько же надо опыту? На самом деле больше зависит от характера — мне сложно ставить высокую оценку. При этом иногда понимаю, что сроки явно занижены. Сильно. Но не всегда… опыта не хватает оценивать узкие места — подзабытую технологию (не использованную больше года) и прочее подобное. Ну и побочный рефакторинг тоже неплохо может откушать.
На самом деле больше зависит от характера — мне сложно ставить высокую оценку. При этом иногда понимаю, что сроки явно занижены
Это как раз от недостатка опыта. Со временем придёт уверенность в себе ;)
«больше зависит от характера — мне сложно ставить высокую оценку. При этом иногда понимаю, что сроки явно занижены» — ну и кому вы хорошо этим делаете? Себе — нет, вам придется больше работать, сверхурочно, за те же деньги. Удовольствия от работы это тоже вряд ли добавит.
Заказчику/начальнику — тоже нет, большая вероятность срыва сроков и риски (о которых он не знает), более высокая вероятность что вы (возможно) снизите качество чтобы успеть в сроки — все это редко когда компенсируется приятной слуху цифрой по времени и деньгам.
Другим разработчикам — ну точно нет, теперь их более точные оценки будут восприниматся как завышенные, со всеми вытекающими (конфликты, срывы сроков, снижение качества).
Давать нужно реальную оценку, насколько она реальна это действительно вопрос опыта а не характера. В реальную оценку заложены и риски, процент которых кстати тоже определяется на основе опыта, а не константа, как некоторые любят. И уж если чувствуете что оценка занижена, то стоит ее пересмотреть, разве что проект нужен вам или компании ну позарез.
А сколько надо опыта? У меня получилось около 3 лет программирования и оценки чтобы выйти на более менее нормальную погрешность и почти не допускать ошибок оценки. Потом точность повышается, как и скорость оценки, ну и область расширяется, учишся более точно оценивать риски, можешь оценивать время и риски на освоение технологии (точность конечно снижается в этом случае). Лет 5 наверное надо на задачах разной сложности, чтобы оценивать точно риски, в том числе и форсмажорные. Но 2 лет или пары серьезных пролетов с серьезными последствиями достаточно чтобы понять что эти риски должны быть заложены.
Заказчику/начальнику — тоже нет, большая вероятность срыва сроков и риски (о которых он не знает), более высокая вероятность что вы (возможно) снизите качество чтобы успеть в сроки — все это редко когда компенсируется приятной слуху цифрой по времени и деньгам.
Другим разработчикам — ну точно нет, теперь их более точные оценки будут восприниматся как завышенные, со всеми вытекающими (конфликты, срывы сроков, снижение качества).
Давать нужно реальную оценку, насколько она реальна это действительно вопрос опыта а не характера. В реальную оценку заложены и риски, процент которых кстати тоже определяется на основе опыта, а не константа, как некоторые любят. И уж если чувствуете что оценка занижена, то стоит ее пересмотреть, разве что проект нужен вам или компании ну позарез.
А сколько надо опыта? У меня получилось около 3 лет программирования и оценки чтобы выйти на более менее нормальную погрешность и почти не допускать ошибок оценки. Потом точность повышается, как и скорость оценки, ну и область расширяется, учишся более точно оценивать риски, можешь оценивать время и риски на освоение технологии (точность конечно снижается в этом случае). Лет 5 наверное надо на задачах разной сложности, чтобы оценивать точно риски, в том числе и форсмажорные. Но 2 лет или пары серьезных пролетов с серьезными последствиями достаточно чтобы понять что эти риски должны быть заложены.
Бывает, что занижаешь календарные сроки ради того, чтобы заказ вышел дешевле чем у конкурентов, но при этом не было у заказчика ощущения, что работаешь «за еду». То есть оцениваешь работу в 40 часов (впритык, без запаса) и 10к, но вместо 5 рабочих дней заявляешь два (пятницу и понедельник), соответственно 4к, рассчитывая работать 4 дня по 10 часов, а если неучтенные подводные камни, то по 12 и больше. Просто альтернатива — остаться вообще без заказов и хоть каких-то но денег на эти дни. Сиюминутная выгода перевешивает долгосрочное влияние на рынок и риски завалить сроки из-за форс-мажоров.
Ну я же уточнил " разве что проект нужен вам или компании ну позарез", в том числе и по этой ситуации.
Да бывает когда переступаешь через себя чтобы взять проект. У меня 1 раз такое было, деньги были нужны, ничем хорошим правда это не закончилось, вскоре после того как взял «дешевый» появился нормальный проект, и пришлось впахивать чтобы успеть везде, но на тот момент я этого не знал. Для себя взял за правило что такое возможно только в крайнем случае, лучше просидеть без работы, потратить это время на самообразование или более активный поиск проектов, чем работать за еду, если конечно позволяют деньги. «Дешевый» проект, это внутренее недовольство, что не получаешь заслуженного, и оно все равно влияет, как это не подавляй. Так же это занятое время, и вполне может получится ситуация что не получится взять нормальный проект из-за того что время занято дешевым. На сроках в несколько дней это не критично, а вот если там месяц, то уже может стать проблемой.
Да бывает когда переступаешь через себя чтобы взять проект. У меня 1 раз такое было, деньги были нужны, ничем хорошим правда это не закончилось, вскоре после того как взял «дешевый» появился нормальный проект, и пришлось впахивать чтобы успеть везде, но на тот момент я этого не знал. Для себя взял за правило что такое возможно только в крайнем случае, лучше просидеть без работы, потратить это время на самообразование или более активный поиск проектов, чем работать за еду, если конечно позволяют деньги. «Дешевый» проект, это внутренее недовольство, что не получаешь заслуженного, и оно все равно влияет, как это не подавляй. Так же это занятое время, и вполне может получится ситуация что не получится взять нормальный проект из-за того что время занято дешевым. На сроках в несколько дней это не критично, а вот если там месяц, то уже может стать проблемой.
У меня на первых работах было примерно так. Сколько вам нужно на реализацию? Спашивали меня начальники, ответом было 2 недели. Они улыбались, и когда через две недели запаздывали, улыбка разъяснялась. Мол мы давно вас знаем, надо умножить на два и накинуть 10%, тогда все ок.
Угу, был и такой опыт. Только вот потом, когда посмотрели на общие суммы, по факту, спросили а почему так дофига получается. У всех спросили, и у разработчиков, которые дали оценку и набросили риски (технические и риски оценки) и у менеджеров которые умножили на коэффициент вдруг.
Мне всегда безумно «нравились» эти магические формулы, которые чудесным образом должны работать в любой ситуации. Почему на 2 и почему 10%, почему не в 3 раза как коллега на форуме писал, или не на пи как менеджер из другой компании рассказывал. Чем цифра в 17% не красива, почему 10%? Откуда это? Кто высчитывал коэффициенты погрешностей программистов? Если главная цель не завалить делайн — ну умножайте на 100 сразу, чтобы с запасом, стелить соломку так стелить. А если все же нужно выдать максимальную эффективность с разумными сроками, то стоит все же сообщить программистам всю информацию, насколько критичен дедлайн, насколько высока вероятность изменений в ТЗ в процессе работы, какие риски можем себе позволить и вместе с ними сделать оценку всех рисков. Не стоит боятся что обманут обладая всей информацией, и точно не стоит завышать сроки самостоятельно втихаря, это может создать много проблем. Да и как разработчики научатся оценивать, если всегда столько перестраховки, сколько времени не назови, все равно его в 2 раза больше. Ну и о какой ответсвенности может идти речь когда каждый раз фактически срывая срок разработчик видит что «улыбка мудрого начальника разьясняется», что все предусмотрено, и сильно то старатся успеть в срок не нужно, и сообщать о возможных проблемах заранее тоже не нужно, все равно ведь успеем, мудрый начальник заложил кучу времени. А потом «мудрый» начальник понимает что уже не может пользоватся магической формулой, слишком выходит, никто не купит такое. Вот тут и начнется самое интересное.
Нет, если уж начальники знали что ваша оценка не верна, они должны были попросить вас пересмотреть оценку, сказать что могут позволить себе оценку этой задачи в 4 недели и спросить точно ли уверен или все же стоит увеличить.
Мне всегда безумно «нравились» эти магические формулы, которые чудесным образом должны работать в любой ситуации. Почему на 2 и почему 10%, почему не в 3 раза как коллега на форуме писал, или не на пи как менеджер из другой компании рассказывал. Чем цифра в 17% не красива, почему 10%? Откуда это? Кто высчитывал коэффициенты погрешностей программистов? Если главная цель не завалить делайн — ну умножайте на 100 сразу, чтобы с запасом, стелить соломку так стелить. А если все же нужно выдать максимальную эффективность с разумными сроками, то стоит все же сообщить программистам всю информацию, насколько критичен дедлайн, насколько высока вероятность изменений в ТЗ в процессе работы, какие риски можем себе позволить и вместе с ними сделать оценку всех рисков. Не стоит боятся что обманут обладая всей информацией, и точно не стоит завышать сроки самостоятельно втихаря, это может создать много проблем. Да и как разработчики научатся оценивать, если всегда столько перестраховки, сколько времени не назови, все равно его в 2 раза больше. Ну и о какой ответсвенности может идти речь когда каждый раз фактически срывая срок разработчик видит что «улыбка мудрого начальника разьясняется», что все предусмотрено, и сильно то старатся успеть в срок не нужно, и сообщать о возможных проблемах заранее тоже не нужно, все равно ведь успеем, мудрый начальник заложил кучу времени. А потом «мудрый» начальник понимает что уже не может пользоватся магической формулой, слишком выходит, никто не купит такое. Вот тут и начнется самое интересное.
Нет, если уж начальники знали что ваша оценка не верна, они должны были попросить вас пересмотреть оценку, сказать что могут позволить себе оценку этой задачи в 4 недели и спросить точно ли уверен или все же стоит увеличить.
НЛО прилетело и опубликовало эту надпись здесь
Форс-мажором чаще всего оказывается желание заказчика урезать сроки в два раза. Зная это, программист завышает сроки в два раза.
Одно дело — заказчики. Тут можно ситуацию обыграть, доказать что и как долго будет делаться.
Вдвойне проблема, если со стороны заказчика выступает «компетентное» лицо — программист, который говорит заказчику: «да, вы что Семен Семеныч, вас парят. Я это сделаю за 3 часа». И ведь с таким заведомо-заинтересованным «компетентным» лицом куда сложнее договориться, потому что он не понимает (или делает вид, что не понимает), что длительность переговоров УЖЕ с лихвой перекрыли ЕГО сроки.
Вдвойне проблема, если со стороны заказчика выступает «компетентное» лицо — программист, который говорит заказчику: «да, вы что Семен Семеныч, вас парят. Я это сделаю за 3 часа». И ведь с таким заведомо-заинтересованным «компетентным» лицом куда сложнее договориться, потому что он не понимает (или делает вид, что не понимает), что длительность переговоров УЖЕ с лихвой перекрыли ЕГО сроки.
Ну тогда можно сказать «Действительно, Семен Семеныч, с Вашей стороны будет ошибкой поручить это мне вместо Васи, если он действительно может сделать это за 3 часа. Даже если Вася — директор газпрома(условно) и хочет 50$/час, Вы сэкономите»
Ну а вообще лично я с таким не сталкивался, наверное еще предстоит
Однако лично я себя убедил в том, что начальник — сотрудник такого же уровня, что и я. Отчасти проблема с оценкой связана со страхом перед начальством. Так вот, я для себя уяснил, что неадекватных начальников не нежно бояться (а лучше даже вести себя с ними немного вызывающе), так как потерять работу такую имхо только в радость. А хорошее начальство никогда тебя в такое положение не поставит, так что их и бояться нечего
А вообще я устал от того, что есть кто-то сверху и занимаюсь фрилансом:)
Ну а вообще лично я с таким не сталкивался, наверное еще предстоит
Однако лично я себя убедил в том, что начальник — сотрудник такого же уровня, что и я. Отчасти проблема с оценкой связана со страхом перед начальством. Так вот, я для себя уяснил, что неадекватных начальников не нежно бояться (а лучше даже вести себя с ними немного вызывающе), так как потерять работу такую имхо только в радость. А хорошее начальство никогда тебя в такое положение не поставит, так что их и бояться нечего
А вообще я устал от того, что есть кто-то сверху и занимаюсь фрилансом:)
А вообще я устал от того, что есть кто-то сверху и занимаюсь фрилансом:)
Звучит как: «Я устала заниматься сексом за деньги, потому ушла из борделя и стала индивидуалкой»
А вообще я устал от того, что есть кто-то сверху и занимаюсь фрилансом:)
Ах, ну да, ну да, ведь работа на фрилансе подразумевает полное отсутствие начальства, не так ли? :)
Совсем нет,
Фриланс дает некоторую степень свободы, территориальную независимость и бОльшие деньги.
А еще имхо неплохой старт перед переходом в полностью свое дело, так как учит искать клиентов, продавать, планировать, иногда делегировать и руководить, нести полную ответственность за результат и многое другое
Фриланс дает некоторую степень свободы, территориальную независимость и бОльшие деньги.
А еще имхо неплохой старт перед переходом в полностью свое дело, так как учит искать клиентов, продавать, планировать, иногда делегировать и руководить, нести полную ответственность за результат и многое другое
> А еще имхо неплохой старт перед переходом в полностью свое дело, так как учит искать клиентов, продавать, планировать
Это самое хардкорное, по-моему. Это ведь не начальник, который один и с уже известными своими закидонами. Клиенты каждый раз разные и неадекватов среди них полно, этому надо то, этому это, тому «чтобы готово вчера». Из некоторых приходится клещами вытаскивать информацию, которую по моей логике они должны были вывалить в структурированном виде первым делом.
Сейчас вот как раз, заказ с первоначальным сроком в неделю растянулся и уже пошла третья, как раз из-за мутного заказчика, который не может толком сказать, где и что, у которого API пришлось неделю ждать, API насквозь дырявое, там баг, тут баг, то отсутствует, это отсутствует. Для POST запросов приходится эмпирическим путём названия полей подбирать, потому что отвечает он с неплохим таймаутом и очень мутно — сиди и расшифровывай. При этом спрашивал «Yesterday was release date, have you finished?». И это при не работающем API и выключенных серверах. Nuff said. Самое интересное, что он даже не manager-boy, а Java Developer. Приходится много думать, как его лучше спросить и как лучше реагировать на не несущие никакой полезной информации ответы.
Так что я тоже думаю, что это неплохо прокачает скилл коммуникации.
Это самое хардкорное, по-моему. Это ведь не начальник, который один и с уже известными своими закидонами. Клиенты каждый раз разные и неадекватов среди них полно, этому надо то, этому это, тому «чтобы готово вчера». Из некоторых приходится клещами вытаскивать информацию, которую по моей логике они должны были вывалить в структурированном виде первым делом.
Сейчас вот как раз, заказ с первоначальным сроком в неделю растянулся и уже пошла третья, как раз из-за мутного заказчика, который не может толком сказать, где и что, у которого API пришлось неделю ждать, API насквозь дырявое, там баг, тут баг, то отсутствует, это отсутствует. Для POST запросов приходится эмпирическим путём названия полей подбирать, потому что отвечает он с неплохим таймаутом и очень мутно — сиди и расшифровывай. При этом спрашивал «Yesterday was release date, have you finished?». И это при не работающем API и выключенных серверах. Nuff said. Самое интересное, что он даже не manager-boy, а Java Developer. Приходится много думать, как его лучше спросить и как лучше реагировать на не несущие никакой полезной информации ответы.
Так что я тоже думаю, что это неплохо прокачает скилл коммуникации.
Одно дело — заказчикиИ совсем другое — быдлокодеры на фрилансе, которые, чтобы добавить кнопочку или поправить стиль в css-ке, просят пятизначную сумму.
Заказчик, который сам программист — это идеальный вариант.
Конечно, если у исполнителя не стоит цели подхалтурить (а у большинства, как показывает практика, именно эта цель и стоит).
Всякая задача стремится занять всё отведенное ей время © что-то там из законов Мерфи
Видел у кого-то в портфолио: «Подстановка прилагательного `простенькая` на оценку стоимости не влияет. Примеры: `Нужна простенькая нейронная сеть`»
Сильно хуже, когда разработчик говорит время с потолка, надеясь еще успеть 2-3 проекта попутно вести. Показалось работы на 2 дня — назвал 2 недели, и доволен, что есть запас. Оговорили деньги, сроки, взялся делать — ОПА! — а работы там и правда на 2 недели full time (о чем заказчик примерно и думал, поэтому его срок в 2 недели даже порадовал, вроде как разработчик показался адекватным), и деньги не особо изменишь — а те, другие 2-3 проекта стоят.
И начинается «вешание лапши» и «завтраки».
Это я к тому, что не только разрабы от неверных сроков страдают.
И начинается «вешание лапши» и «завтраки».
Это я к тому, что не только разрабы от неверных сроков страдают.
Ну да, разработчики такие плохие, врут заказчикам, а то, что заходишь на фриланс и видишь предложения вроде 5к за сайт, так это, значит, нормально? А тот факт, что чтобы семью кормить, нужно минимум 2-3 проекта таких вот одновременно вести никто, конечно, не учитывает. А из двухдневного проекта получается двухнедельный, конечно, не потому, что заказчик сам не знает, чего хочет, или ему друг посоветовал использовать C++ для бэкэнда «чтоб быстрее».
Я это к тому, что завышение сроков в 3 раза — это, среднестатистически, норма. Даже без учета информации из статьи, которая тут некоторое время назад была про то, что «программисты — оптимисты».
Я это к тому, что завышение сроков в 3 раза — это, среднестатистически, норма. Даже без учета информации из статьи, которая тут некоторое время назад была про то, что «программисты — оптимисты».
Сам сталкивался. Поэтому прошу расписывать, как разработчик видит время и объемы. И деньги, это уж особенно важно, чтобы потом не было «а что Вы хотите, я с Вас так мало попросил, а Вы мне еще сроки требуете».
«Мы не настолько богаты, чтобы заказывать сайты за 5К» :)
«Мы не настолько богаты, чтобы заказывать сайты за 5К» :)
Хорошо, когда заказчики компетентные и не жадные. Мир был бы однозначно лучше, если бы они представляли большинство :)
«Мы не настолько богаты, чтобы заказывать сайты за 5К» — отличная фраза. Жаль что многие все же искренне надеются что вот именно им повезло и попался разработчик и профессиональный и дешевый одновеменно, и что они не повторят судьбу многих других тоже выбравших по принципу меньшей цены, но которым не повезло и пришлось терять деньги и время и начинать все сначала. А ведь есть и те кто продолжает ходить по граблям, сначала за 5К, потом «раскошеливаются» на 30К, а сайт на самом деле 300К в первой версии (в рублях российских конечно), а потом вообще его нужно с фриланса снимать и команду набирать из 10 человек, или компанию подрядчика с аналогичными ресурсами. Так и ходят по граблям пока не дойдут до нормальной цены, либо бросят потратив деньги и кучу времени.
«Сколько платишь — столько и получаешь» — правило работает в большинстве случаев. Не стоит надеятся что удастся выиграть в эту «лотерею» получив хорошо задешево.
«Сколько платишь — столько и получаешь» — правило работает в большинстве случаев. Не стоит надеятся что удастся выиграть в эту «лотерею» получив хорошо задешево.
Так ведь фриланс-сайты почитать, так все как один работают дешево, но профессионально, имеют 20-летний опыт, никогда не срывают сроки, и у каждого по 100 готовых проектов масштабов хотя бы mail.ru. И цены — от рубля и выше.
Неопытный заказчик либо поведется, либо нет, и побежит к дорогим серьезным фирмам. А там та же петрушка, даром что за 5К сайт они для начала выкатят 2М рублей: как-то встречал контору, которая за запуск сайта в рамках стандартного 1с-Битрикса (т.е. тупо натянуть дизайн и разложить инфоблоки) называла 3М, и уточняла, что ни контентом, ни дописыванием модулей за эти деньги они заниматься не будут, ибо и так дешево. Сколько в тех лямах было заложено на работу — не скажу, но, похоже, по показателю «бабок на единицу лоха» они переплевывали даже цену чернил в оригинальных картриджах, которая, как известно, более прибыльна и менее рискова, чем даже наркота. «Учи, сынок, Битрикс, если из страны ехать не собираешься» :)
Неопытный заказчик либо поведется, либо нет, и побежит к дорогим серьезным фирмам. А там та же петрушка, даром что за 5К сайт они для начала выкатят 2М рублей: как-то встречал контору, которая за запуск сайта в рамках стандартного 1с-Битрикса (т.е. тупо натянуть дизайн и разложить инфоблоки) называла 3М, и уточняла, что ни контентом, ни дописыванием модулей за эти деньги они заниматься не будут, ибо и так дешево. Сколько в тех лямах было заложено на работу — не скажу, но, похоже, по показателю «бабок на единицу лоха» они переплевывали даже цену чернил в оригинальных картриджах, которая, как известно, более прибыльна и менее рискова, чем даже наркота. «Учи, сынок, Битрикс, если из страны ехать не собираешься» :)
Ну я скорее говорил про тех которые понимают что то что они выбрали — дешево, но при этом надеются что им повезет и это будет еще и качественно. Ну если как пример, 5 человек оценили проект в $4-6К а один в $1К, вот и думают, возьму этого за 1К, а вдруг повезет, и получу что нужно, в крайнем случае много не потеряю. И таких много, как ни странно, приходят, рассказывают что предыдущие подрядчики «не смогли», получают оценку, иногда офигевают от разбежки с прошлой оценкой и уходят искать свою удачу дальше шагая по граблям (хотя может у них бюджет просто такой маленький, недооценили вовремя, посмотрев на порталы за 3 копейки «быстро, дешево, качественно», не знаю, кто-ж скажет наверняка). Или это может мне так везет :(
А то что вы описали, ну риск нарватся на тех кто живет за счет разового обдирания лохов а не долгосрочного сотрудничества всегда есть, но как я понимаю с репутацией у таких контор плохо, она либо плохая, либо ее нет. И если речь уже идет о 3М то можно раскошелится и заказать независимую оценку, не такая уж дорогая штука, просто все привыкли что аналитика-оценка бесплатно (на фрилансе по крайней мере).
С суперрпрофессионалами за 5$ в час на фриланс сайтах — то же самое, не может стоить хорошая работа слишком дешево, ну а чтобы понять что есть «слишком», нужно общатся с исполнителями вооружившись вилкой для снятия лапши, нужно спрашивать бывших клиентов ((письменные отзывы на фриналс сайтах — бред) и поверьте я ничуть не обижаюсь когда меня просят связать с клиентами чтобы они подтвердили что я занимался этим проектом, если конечно я вижу что это стоит того, и думаю не один я), нужно минимизировать риски за счет договора, разбивки на этапы, привлечения внешних консультантов, ну и конечно общатся, общатся и общатся, если человек профессионал, он сможет любому обьяснить чем он занимается, почему это столько стоит, какие есть варианты. Вопрос только во времени. Если исполнитель говорит «все будет ок, ты успокойся, у 100 раз так делал» — нужно бежать как можно дальше. Как мне хочется бежать и от заказчика который не готов погрузиться в проект, уделить ему кучу времени, а просто считает что можно показать несколько сайтов, функционал на которых ему нравится а исполнитель волшебным угадает что ему на самом деле нужно и все будет замечательно. Ну я конечно не говорю про задачи обьемом в день-два, я больше про крупные вещи, на месяцы, где можно потратить время и деньги на то чтобы выбрать хорошего исполнителя.
А битрикс, нет спасибо, не мое, ни в прямом смысле, ни в указанном вами :)
А то что вы описали, ну риск нарватся на тех кто живет за счет разового обдирания лохов а не долгосрочного сотрудничества всегда есть, но как я понимаю с репутацией у таких контор плохо, она либо плохая, либо ее нет. И если речь уже идет о 3М то можно раскошелится и заказать независимую оценку, не такая уж дорогая штука, просто все привыкли что аналитика-оценка бесплатно (на фрилансе по крайней мере).
С суперрпрофессионалами за 5$ в час на фриланс сайтах — то же самое, не может стоить хорошая работа слишком дешево, ну а чтобы понять что есть «слишком», нужно общатся с исполнителями вооружившись вилкой для снятия лапши, нужно спрашивать бывших клиентов ((письменные отзывы на фриналс сайтах — бред) и поверьте я ничуть не обижаюсь когда меня просят связать с клиентами чтобы они подтвердили что я занимался этим проектом, если конечно я вижу что это стоит того, и думаю не один я), нужно минимизировать риски за счет договора, разбивки на этапы, привлечения внешних консультантов, ну и конечно общатся, общатся и общатся, если человек профессионал, он сможет любому обьяснить чем он занимается, почему это столько стоит, какие есть варианты. Вопрос только во времени. Если исполнитель говорит «все будет ок, ты успокойся, у 100 раз так делал» — нужно бежать как можно дальше. Как мне хочется бежать и от заказчика который не готов погрузиться в проект, уделить ему кучу времени, а просто считает что можно показать несколько сайтов, функционал на которых ему нравится а исполнитель волшебным угадает что ему на самом деле нужно и все будет замечательно. Ну я конечно не говорю про задачи обьемом в день-два, я больше про крупные вещи, на месяцы, где можно потратить время и деньги на то чтобы выбрать хорошего исполнителя.
А битрикс, нет спасибо, не мое, ни в прямом смысле, ни в указанном вами :)
Да… «Показать несколько сайтов, которые нравятся, попросить бюджет поменьше, и сроки покороче» — это универсальный рецепт граблей, притом и заказчику, и исполнителю.
Насчет разовых обдираловок лохов — к моему ужасу, это я слышал от (не ошибаюсь если) коммерческого директора одной из всероссийских контор, которая еще и уверенно в топ-10 входит во всех конкурсах. Пусть даже я ошибаюсь, но поводов понтоваться у них масса. Только вот задумаешься иной раз — все ли их «победы» взяты именно трудом, или таким же понтом (когда заказчик лоханулся, отвалил много лямов, понял свою глупость, и просто не станет ругать такого подрядчика, чтобы глупо не выглядеть).
Аналитика — это тоже вилка, с одной стороны, аналитик вроде как разбирается, но он бы решал задачу так и так (и видит трудозатраты такие-то), а подрядчик, имя опыт (или протупив), взялся делать с другого конца. Даже если оба добросовестные, сроки аналитика и подрядчика разойдутся как в море корабли, а если проект крупный, то и непонятно будет, это сроки из-за подхода, или из-за вылизывания.
Все упирается в а) приличного подрядчика, б) необходимость во все вникать самому (хоть подрядчику, хоть заказчику), в) понимании, что кроме как «делать быстрее», в работе есть фаза «думай лучше и проектируй под задачу». И вот с пунктом «а» — самое сложное ))
Насчет разовых обдираловок лохов — к моему ужасу, это я слышал от (не ошибаюсь если) коммерческого директора одной из всероссийских контор, которая еще и уверенно в топ-10 входит во всех конкурсах. Пусть даже я ошибаюсь, но поводов понтоваться у них масса. Только вот задумаешься иной раз — все ли их «победы» взяты именно трудом, или таким же понтом (когда заказчик лоханулся, отвалил много лямов, понял свою глупость, и просто не станет ругать такого подрядчика, чтобы глупо не выглядеть).
Аналитика — это тоже вилка, с одной стороны, аналитик вроде как разбирается, но он бы решал задачу так и так (и видит трудозатраты такие-то), а подрядчик, имя опыт (или протупив), взялся делать с другого конца. Даже если оба добросовестные, сроки аналитика и подрядчика разойдутся как в море корабли, а если проект крупный, то и непонятно будет, это сроки из-за подхода, или из-за вылизывания.
Все упирается в а) приличного подрядчика, б) необходимость во все вникать самому (хоть подрядчику, хоть заказчику), в) понимании, что кроме как «делать быстрее», в работе есть фаза «думай лучше и проектируй под задачу». И вот с пунктом «а» — самое сложное ))
Из той же серии: «ну-у-у, раз две недели, то уж ладно, я согласен… но может понадобится пару мелких фич добавить, там на час-другой времени. просто включим в эти две недели, это ведь не проблема?»
Через месяц, отбиваясь от очередной «мелкой фичи» уже люто ненавидишь заказчика, проект, собственную глупость и отсутствие посредника-менеджера, который каждую «мелкую фичу» округляет в большую сторону до дней, прописывает в договор и честно потом берет свой процент с дохода.
Через месяц, отбиваясь от очередной «мелкой фичи» уже люто ненавидишь заказчика, проект, собственную глупость и отсутствие посредника-менеджера, который каждую «мелкую фичу» округляет в большую сторону до дней, прописывает в договор и честно потом берет свой процент с дохода.
Спасибо за этот пост. Ни о чем по сути, но очень поднял настроение )
Бессмысленно убеждать программиста, что оцененную им задачу можно сделать быстрее. Он может ошибаться в сторону занижения сроков, но в сторону завышения — почти никогда.
Еще как может, особенно если оплата идет по часам. Для объективности надо оценивать хотя бы 2-3 разработчиками. Если все трое сказали примерно одинаковые цифры — тогда да, тогда с вами согласен.
Еще как может, особенно если оплата идет по часам. Для объективности надо оценивать хотя бы 2-3 разработчиками. Если все трое сказали примерно одинаковые цифры — тогда да, тогда с вами согласен.
А что делать заказчику, если все трое сказали разные сроки и суммы, отличающиеся в разы, причем часто взятые с потолка (на фрилансе в каждом первом проекте можно встретить)?
Не всегда с потолка, просто на фрилансе есть 2 моды вредные для заказчика
а) Оценивать стоимость своего времени, а не стоимость задачи
б) Не делать того, чего не требуется строго или наоборот, включать в цену кучу нетребуемых плюшек.
Из пункта А проистекают ситуации вида следующей.
Верстальщик берется за программирование, оценивает задачу в 2 недели и тыщу баксов. Программист берется за программирование, оценивает задачу в 3 дня и 300 баксов. В комьюнити начинается чморение программиста как демпера работающего за еду.
Для заказчика это выглядит как «3 дня за 300» против «14 дней за 1000», и не более того. т.к. заказчик обычно не в теме. Заказчик думает — ну второй-то явно не понимает во что ввязывается. И получается эпический 100%-ный фэил у всех участвующих в безобразии.
Из пункта Б проистекает ситуация вида следующей.
Задача сделать просто добавление текстового поля в базу.
Первый делает вида insert into table (txt) values ($_POST[txt])). Работает? Работает. Заказчик не заглядывающий в код заметит что это УГ? Нет. Цена вопроса? 100 баксов и 1 день.
Второй делает примерно то же самое, только с фильтрацией переменных, т.е. делая все строго необходимое по «понятиям», но в то же время не додумывая ненужной фигни. Цена вопроса? 500 баксов и 3 дня.
Третий делает… админку, данные из базы, авторизацию, экспорт, хмл, интерфейс на extjs и так далее, заряжает 2000 баксов и 2 недели.
При чем для заказчика при заказе это звучит как «100 за день», «500 за 3», «2000 за 14». и не более того. т.к. заказчик обычно не в теме.
Самое жуткое в том, что второму (с нашей точки зрения наиболее адекватному) бороться с 1 и 3 бесполезно, т.к. первый задавит аргументом «фигли так дорого», а третий задавит аргументом «я забочусь о заказчике, все равно все это делать надо». Любопытно, что третьих на западном фрилансе минимум, т.к. с занятостью проблем там нет, а на ру фрилансе очень много, т.к. заказы очень редки и из них пытаются выжимать по максимуму:)
а) Оценивать стоимость своего времени, а не стоимость задачи
б) Не делать того, чего не требуется строго или наоборот, включать в цену кучу нетребуемых плюшек.
Из пункта А проистекают ситуации вида следующей.
Верстальщик берется за программирование, оценивает задачу в 2 недели и тыщу баксов. Программист берется за программирование, оценивает задачу в 3 дня и 300 баксов. В комьюнити начинается чморение программиста как демпера работающего за еду.
Для заказчика это выглядит как «3 дня за 300» против «14 дней за 1000», и не более того. т.к. заказчик обычно не в теме. Заказчик думает — ну второй-то явно не понимает во что ввязывается. И получается эпический 100%-ный фэил у всех участвующих в безобразии.
Из пункта Б проистекает ситуация вида следующей.
Задача сделать просто добавление текстового поля в базу.
Первый делает вида insert into table (txt) values ($_POST[txt])). Работает? Работает. Заказчик не заглядывающий в код заметит что это УГ? Нет. Цена вопроса? 100 баксов и 1 день.
Второй делает примерно то же самое, только с фильтрацией переменных, т.е. делая все строго необходимое по «понятиям», но в то же время не додумывая ненужной фигни. Цена вопроса? 500 баксов и 3 дня.
Третий делает… админку, данные из базы, авторизацию, экспорт, хмл, интерфейс на extjs и так далее, заряжает 2000 баксов и 2 недели.
При чем для заказчика при заказе это звучит как «100 за день», «500 за 3», «2000 за 14». и не более того. т.к. заказчик обычно не в теме.
Самое жуткое в том, что второму (с нашей точки зрения наиболее адекватному) бороться с 1 и 3 бесполезно, т.к. первый задавит аргументом «фигли так дорого», а третий задавит аргументом «я забочусь о заказчике, все равно все это делать надо». Любопытно, что третьих на западном фрилансе минимум, т.к. с занятостью проблем там нет, а на ру фрилансе очень много, т.к. заказы очень редки и из них пытаются выжимать по максимуму:)
Проблема в том что " т.к. заказчик обычно не в теме.". Если заказчику важна эта задача, ему стоит поговорить со всеми тремя, тогда он сразу поймет нужен ли ему 3 вариант (а может ему на самом деле нужна была админка, но он не знал об этом). Между 1 и 2 вариантом ему сложнее будет выбрать, но это уже риски и стоит смотреть что важнее цена или риски качества (при этом понимая что в некоторых случаях более высокая цена не гарантирует более высокого качества), репутацию, потфолио, и прочие бессмысленные вещи. Ну и если речь о реальных задачах, то там уже не заглядывая в код можно увидеть (на багах анпример) профессионализм. А значит можно защитится договором в случае большой задачи, можно разбить на этапы и прочие техники.
Но вот если заказчик и не собирается погружатся в тему, пусть и не глубоко, а видит только цену и сроки — ну тогда он сам себе злобный буратино, мало того что скорее всего ошибется с исполнителем, так еще и получит не то что нужно его бизнесу, потому что не знает и не хочет узнать, понять и разобратся что ему нужно. И под «разобратся» я конечно не имею в виду «выучить язык и технологии».
Но вот если заказчик и не собирается погружатся в тему, пусть и не глубоко, а видит только цену и сроки — ну тогда он сам себе злобный буратино, мало того что скорее всего ошибется с исполнителем, так еще и получит не то что нужно его бизнесу, потому что не знает и не хочет узнать, понять и разобратся что ему нужно. И под «разобратся» я конечно не имею в виду «выучить язык и технологии».
Для эксперимента очень хочется попробовать такую штуку, как planning pocker и оценить, насколько точнее будут оказываться сроки.
коллеги рассказывали, точнее так, подходят и спрашивают:
— Сколько тебе надо времени развернуть веб сервер для питоновских скриптов, при условии что серв с ОСью есть, питон код (готовый к употреблению будет от разработчиков)
— Ну полчаса — час, как раз подобное на прошлой недели делал, а что?
— а тут данную задачу поставили коллеги N, он оценил это в 600 часов.
— Сколько тебе надо времени развернуть веб сервер для питоновских скриптов, при условии что серв с ОСью есть, питон код (готовый к употреблению будет от разработчиков)
— Ну полчаса — час, как раз подобное на прошлой недели делал, а что?
— а тут данную задачу поставили коллеги N, он оценил это в 600 часов.
если это не офисная работа, то эти 600 часов могут включать работу по дому, потому что больше не когда ее делать.
Ситуация, когда что-то, необходимое для решения задачи, «будет...», тоже по факту увеличивает сроки как минимум в 2 раза :)
Так он может подумал что надо написать свой web сервер на котором питон крутиться будет )
НЛО прилетело и опубликовало эту надпись здесь
>время неадекватно занизил
>Но, конечно, не 600 часов
так 600 часов, по вашему, это завышено или занижено?
>Но, конечно, не 600 часов
так 600 часов, по вашему, это завышено или занижено?
НЛО прилетело и опубликовало эту надпись здесь
тогда давайте прикинем, что при решении данной задачи возникли все возможные проблемы.
начиная от нашествия бурундуков убийц в датацент, заканчивая саботажем со стороны разработчиков, в какое время вы бы оценили решение?
начиная от нашествия бурундуков убийц в датацент, заканчивая саботажем со стороны разработчиков, в какое время вы бы оценили решение?
Сколько раз твердили миру: составляйте ТЗ. Нет в ТЗ — значит это не заложено в сроки, не оплачивается. Оплатят сверху? Нам так же потребуется дополнительное время на реализацию новых задач. Всё просто и понятно. ТЗ это не всегда 20 страниц А4 мелким почерком (а жаль), достаточно составить список по пунктам (обычно получается 10-20 + подпункты) что надо сделать. Описать сложные моменты по одному обзацу текста (можно с картинками), потом всё это дело согласовать с разработчиками (не только программистами) и дописать/переписать. Итого: потратив чуть-чуть времени перед началом разработки проекта — сэкономить много больше времени во время реализации проекта.
ТЗ не панацея к сожалению. Ни для заказчика, ни для разработчика. Было у меня как то такое ТЗ по пунктам, даже к договору приложили. А когда начали реализацию, вдруг поняли что пункты некоторые можно трактовать очень по разному (хотя ну очевидными они казались при оценке, даже уточнять не стоит), т.е. в оценке я конкретно ошибся и конечно в меньшую сторону. Пришлось работать «за еду». А всего-то нужно было не надеятся на очевидность, а попросить заказчика рассказать пункт ТЗ своими словами.
Это я к тому что ТЗ можно использовать как опорную точку для обсуждения проекта, понимания его одинаково заказчиком и исполнителем, документацией для поверхностного ознакомления с проектом, но не более. А уж силу ТЗ, как способа защиты исполнителя он неучтенных задач, а казачика от невыполненных или выполненных некачественно, сильно переоценивают. Исключение — многостраничные детальнейшие ТЗ написанные профессиональными аналитиками, прошедшие через этап тестирования документации и внимательно прочитанные, полностью понятые и подписанные всеми заинтересованными сторонами. Такие встречаются очень редко, да и смысла в них в большинстве случаев мало, так как аппетит действительно приходит во время еды, и некоторые изменения в задачах нужно добавить в процессе работы над задачей (оплатив конечно и сдвинув сроки если нужно), иначе может получится так что после первого этапа сразу второй надо делать в котором учтены ошибки первого, а так можно исправить уже на первом этапе ошибки которые видны.
Это я к тому что ТЗ можно использовать как опорную точку для обсуждения проекта, понимания его одинаково заказчиком и исполнителем, документацией для поверхностного ознакомления с проектом, но не более. А уж силу ТЗ, как способа защиты исполнителя он неучтенных задач, а казачика от невыполненных или выполненных некачественно, сильно переоценивают. Исключение — многостраничные детальнейшие ТЗ написанные профессиональными аналитиками, прошедшие через этап тестирования документации и внимательно прочитанные, полностью понятые и подписанные всеми заинтересованными сторонами. Такие встречаются очень редко, да и смысла в них в большинстве случаев мало, так как аппетит действительно приходит во время еды, и некоторые изменения в задачах нужно добавить в процессе работы над задачей (оплатив конечно и сдвинув сроки если нужно), иначе может получится так что после первого этапа сразу второй надо делать в котором учтены ошибки первого, а так можно исправить уже на первом этапе ошибки которые видны.
>А всего-то нужно было не надеятся на очевидность, а попросить заказчика рассказать пункт ТЗ своими словами.
>Это я к тому что ТЗ можно использовать как опорную точку для обсуждения проекта
Я как бы об этом и написал:
>потом всё это дело согласовать с разработчиками (не только программистами) и дописать/переписать.
Только вот не согласен что
>документацией для поверхностного ознакомления с проектом, но не более
Если мы говорим о фрилансе (без договора, без вообще каких-либо оформлений) то проще заказчику сказать чтото типа «напишите в ТЗ всё что вы отите сделать, сразу предупреждаю — нет в ТЗ, значит делать не надо». Потом опять же уточняете спорные моменты, оцениваете и работаете по этому списку задач.
Если же мы говорим о работе с юр.лицами, договорами, оформлением, налогами итд то там без варианта —
> 20 страниц А4 мелким почерком
Рассказывать мне что
>А уж силу ТЗ, как способа защиты исполнителя он неучтенных задач, а казачика от невыполненных или выполненных некачественно, сильно переоценивают
вообще изначально бессмысленно. Я сам работаю по описанной мной схеме и знаю много других фрилансеров кто работает так, и почему-то это работает. К тому моменту как текущее ТЗ закончится заказчик может увидеть что не доделано и составить дополнительное задание которое потом будет ещё и дополнено исполнителем потому что он уже знает что и как надо делать.
>Это я к тому что ТЗ можно использовать как опорную точку для обсуждения проекта
Я как бы об этом и написал:
>потом всё это дело согласовать с разработчиками (не только программистами) и дописать/переписать.
Только вот не согласен что
>документацией для поверхностного ознакомления с проектом, но не более
Если мы говорим о фрилансе (без договора, без вообще каких-либо оформлений) то проще заказчику сказать чтото типа «напишите в ТЗ всё что вы отите сделать, сразу предупреждаю — нет в ТЗ, значит делать не надо». Потом опять же уточняете спорные моменты, оцениваете и работаете по этому списку задач.
Если же мы говорим о работе с юр.лицами, договорами, оформлением, налогами итд то там без варианта —
> 20 страниц А4 мелким почерком
Рассказывать мне что
>А уж силу ТЗ, как способа защиты исполнителя он неучтенных задач, а казачика от невыполненных или выполненных некачественно, сильно переоценивают
вообще изначально бессмысленно. Я сам работаю по описанной мной схеме и знаю много других фрилансеров кто работает так, и почему-то это работает. К тому моменту как текущее ТЗ закончится заказчик может увидеть что не доделано и составить дополнительное задание которое потом будет ещё и дополнено исполнителем потому что он уже знает что и как надо делать.
Оценка полноты ТЗ — это отдельный навык, который надо развивать.
Я бы изменил текст:
сначала на разработку нужно было потратить одну неделю, после обсуждения две.
сначала на разработку нужно было потратить одну неделю, после обсуждения две.
Программисту респект за то, что он сразу все обсуждает с заказчиков. И выставляет его ожидания. Индусы не парятся — струячат все картинками, если что — в договоре не было написано, что это берется с сервера, даже то, что это должен быть label. И все равно к ним идут, потому что для самого первого прототипа и так сгодится.
А потом, конечно, доделывают честные русские девелоперы… и заказчик офигевает, сколько стоит действительно хорошее приложение.
А потом, конечно, доделывают честные русские девелоперы… и заказчик офигевает, сколько стоит действительно хорошее приложение.
Говорят же, что «со времён египетских пирамид, сроки по строительству не исполняются».
Связано ли это с тем, что раньше разработчиков хоронили вместе с фараоном?
Связано ли это с тем, что раньше разработчиков хоронили вместе с фараоном?
НЛО прилетело и опубликовало эту надпись здесь
Хотелось бы эту статью перевести на все языки мира, чтобы торжественно вручать клиентам, партнёрам и коллегам для ознакомления :))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как две недели?!