Как две недели?!

    Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

    Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

    Мы всё обсудили? Нет? Что ещё?

    Надо ли тут картинку на фон? Конечно, надо. Без картинки серо и уныло. Да, дизайнер наш сделает. В отпуске? Ну вы пока заглушку какую-то сделайте сами, а в понедельник он выйдет и сделает. Нет, не в этот что будет понедельник, в следующий.

    Теперь всё уже? Снова нет? Что там еще? Ага, есть два варианта поведения — такой и такой. Блин, оба кажутся логичными! Значит, надо сделать настройку, чтобы пользователь мог выбрать так или так. Нет, ну не на этой форме же! Тут вот такую шестеренку нарисуйте — и по ней чтобы новый экран открывался, а на нём уже и выбор этих вариантов. И, коль уж у нас появилась форма настроек, давайте сразу добавим в неё еще вот это и вот это. Ну и реализуем, чтобы работало согласно этим настройкам. Я давно хотел, просто как-то не до этого было, а тут уж если всё-равно будете делать, так чего тянуть. Там всё однотипно, вы быстро справитесь.

    Ну конечно с юнит-тестами. И с интеграционными, да. И локализицию тоже, несомненно. Да, должно работать и при вертикальной и при горизонтальной ориентации. И с предыдущей версией тоже должно быть совместимо. Да, асинхронно. И с логами. И документацию тоже надо поправить будет. Ну что за вопросы вообще? Не первый ведь день работаете.

    Так, всё выяснили? Ну наконец-то! А теперь, когда уже вот всё вообще ясно, давайте еще раз трезво оценим ситуацию и снова прикинем, сколько нужно времени на реализацию?

    Как две недели ?!

    Мораль

    Бессмысленно убеждать программиста, что оцененную им задачу можно сделать быстрее. Он может ошибаться в сторону занижения сроков, но в сторону завышения — почти никогда. Если можете помочь лишними рабочими руками, снижением требований, достойной оплатой овертаймов — сделайте это. Просто уговаривать его, что тут ничего сложного и это можно сделать быстро — значит обманывать его, себя и заказчика.
    Инфопульс Украина
    Creating Value, Delivering Excellence
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 82

      +59
      Спасибо кэп. Раньше бы, аналогично в ответ поплакался бы в жилетку. Сейчас понимаю, что подобных заказчиков нужно вежливо игнорировать.
        +5
        Игнор действительно помогает.
          +3
          Да, игнор помогает… Но как быть в том случае, если заказчик==начальник, а результат работы ждут другие сотрудники?
          Можно упереться рогом, уткнуться в другие (и кстати, более важные задачи!) и ждать, когда задача опять «всплывет» и срок в две недели не будет казаться таким невероятным. Но конструктивно ли это?
            +31
            Как только начальник\заказчик поймёт, что нашёл фею, которая исполняет желания за дёшево, он тут же сядет и поскачет. Поэтому либо придерживаться реальных оценок, либо увольняться\игнорировать. Иначе вы в любом случае окажитесь виноватым.
              +2
              Согласен. Какое отношение к тебе такое отношение и к ним. Они давят, я игнорю. А в рамках договора так еще и совесть чиста.
                0
                а у меня немного другой подход к такой теме :-)
                просто популярно объясняю, почему так делать не стоит. Мне повезло, что я профессионал в убеждении (помимо аутсорса).
                +1
                Ну вот примерно такой расклад начальнику и показать. написать примерно — этот пункт столько, этот столько, если не верит. При такой детализации окажется еще что вы слишком оптимистично оцениваете.
                  +1
                  Принцип 3-х гвоздей никто не отменял.
                0
                Игнорировать не надо, надо искать другой подход. Если, конечно, заказчик важен.
                +15
                >> Он может ошибаться в сторону занижения сроков, но в сторону завышения — почти никогда.
                Это пока он неопытный, и еще не научился называть сроки с запасом на форс-мажорные обстоятельства.
                  +4
                  Может, я чего-то не понял, но по-моему, статья именно эту ситуацию и иллюстрирует.
                    +5
                    Статья иллюстрирует непонимание заказчиком сложности задачи. А запасы на форс-мажор — это на случай если простудишься/кирпич на голову упадет и т.д. Чтобы в этих случаях не объяснять почему не готово и не платить неустойку по договору.
                      +2
                      И до, и после «сложностей» программист заявил о сроке в 2 недели — я про это.
                        +4
                        Значит программист не первый раз работает с этим заказчиком и знает чего от него ожидать :)
                    +2
                    И сколько же надо опыту? На самом деле больше зависит от характера — мне сложно ставить высокую оценку. При этом иногда понимаю, что сроки явно занижены. Сильно. Но не всегда… опыта не хватает оценивать узкие места — подзабытую технологию (не использованную больше года) и прочее подобное. Ну и побочный рефакторинг тоже неплохо может откушать.
                      0
                      На самом деле больше зависит от характера — мне сложно ставить высокую оценку. При этом иногда понимаю, что сроки явно занижены

                      Это как раз от недостатка опыта. Со временем придёт уверенность в себе ;)
                        +2
                        «больше зависит от характера — мне сложно ставить высокую оценку. При этом иногда понимаю, что сроки явно занижены» — ну и кому вы хорошо этим делаете? Себе — нет, вам придется больше работать, сверхурочно, за те же деньги. Удовольствия от работы это тоже вряд ли добавит.
                        Заказчику/начальнику — тоже нет, большая вероятность срыва сроков и риски (о которых он не знает), более высокая вероятность что вы (возможно) снизите качество чтобы успеть в сроки — все это редко когда компенсируется приятной слуху цифрой по времени и деньгам.
                        Другим разработчикам — ну точно нет, теперь их более точные оценки будут восприниматся как завышенные, со всеми вытекающими (конфликты, срывы сроков, снижение качества).

                        Давать нужно реальную оценку, насколько она реальна это действительно вопрос опыта а не характера. В реальную оценку заложены и риски, процент которых кстати тоже определяется на основе опыта, а не константа, как некоторые любят. И уж если чувствуете что оценка занижена, то стоит ее пересмотреть, разве что проект нужен вам или компании ну позарез.

                        А сколько надо опыта? У меня получилось около 3 лет программирования и оценки чтобы выйти на более менее нормальную погрешность и почти не допускать ошибок оценки. Потом точность повышается, как и скорость оценки, ну и область расширяется, учишся более точно оценивать риски, можешь оценивать время и риски на освоение технологии (точность конечно снижается в этом случае). Лет 5 наверное надо на задачах разной сложности, чтобы оценивать точно риски, в том числе и форсмажорные. Но 2 лет или пары серьезных пролетов с серьезными последствиями достаточно чтобы понять что эти риски должны быть заложены.
                          0
                          Бывает, что занижаешь календарные сроки ради того, чтобы заказ вышел дешевле чем у конкурентов, но при этом не было у заказчика ощущения, что работаешь «за еду». То есть оцениваешь работу в 40 часов (впритык, без запаса) и 10к, но вместо 5 рабочих дней заявляешь два (пятницу и понедельник), соответственно 4к, рассчитывая работать 4 дня по 10 часов, а если неучтенные подводные камни, то по 12 и больше. Просто альтернатива — остаться вообще без заказов и хоть каких-то но денег на эти дни. Сиюминутная выгода перевешивает долгосрочное влияние на рынок и риски завалить сроки из-за форс-мажоров.
                            +1
                            Ну я же уточнил " разве что проект нужен вам или компании ну позарез", в том числе и по этой ситуации.
                            Да бывает когда переступаешь через себя чтобы взять проект. У меня 1 раз такое было, деньги были нужны, ничем хорошим правда это не закончилось, вскоре после того как взял «дешевый» появился нормальный проект, и пришлось впахивать чтобы успеть везде, но на тот момент я этого не знал. Для себя взял за правило что такое возможно только в крайнем случае, лучше просидеть без работы, потратить это время на самообразование или более активный поиск проектов, чем работать за еду, если конечно позволяют деньги. «Дешевый» проект, это внутренее недовольство, что не получаешь заслуженного, и оно все равно влияет, как это не подавляй. Так же это занятое время, и вполне может получится ситуация что не получится взять нормальный проект из-за того что время занято дешевым. На сроках в несколько дней это не критично, а вот если там месяц, то уже может стать проблемой.
                      0
                      У меня на первых работах было примерно так. Сколько вам нужно на реализацию? Спашивали меня начальники, ответом было 2 недели. Они улыбались, и когда через две недели запаздывали, улыбка разъяснялась. Мол мы давно вас знаем, надо умножить на два и накинуть 10%, тогда все ок.
                        +1
                        Угу, был и такой опыт. Только вот потом, когда посмотрели на общие суммы, по факту, спросили а почему так дофига получается. У всех спросили, и у разработчиков, которые дали оценку и набросили риски (технические и риски оценки) и у менеджеров которые умножили на коэффициент вдруг.

                        Мне всегда безумно «нравились» эти магические формулы, которые чудесным образом должны работать в любой ситуации. Почему на 2 и почему 10%, почему не в 3 раза как коллега на форуме писал, или не на пи как менеджер из другой компании рассказывал. Чем цифра в 17% не красива, почему 10%? Откуда это? Кто высчитывал коэффициенты погрешностей программистов? Если главная цель не завалить делайн — ну умножайте на 100 сразу, чтобы с запасом, стелить соломку так стелить. А если все же нужно выдать максимальную эффективность с разумными сроками, то стоит все же сообщить программистам всю информацию, насколько критичен дедлайн, насколько высока вероятность изменений в ТЗ в процессе работы, какие риски можем себе позволить и вместе с ними сделать оценку всех рисков. Не стоит боятся что обманут обладая всей информацией, и точно не стоит завышать сроки самостоятельно втихаря, это может создать много проблем. Да и как разработчики научатся оценивать, если всегда столько перестраховки, сколько времени не назови, все равно его в 2 раза больше. Ну и о какой ответсвенности может идти речь когда каждый раз фактически срывая срок разработчик видит что «улыбка мудрого начальника разьясняется», что все предусмотрено, и сильно то старатся успеть в срок не нужно, и сообщать о возможных проблемах заранее тоже не нужно, все равно ведь успеем, мудрый начальник заложил кучу времени. А потом «мудрый» начальник понимает что уже не может пользоватся магической формулой, слишком выходит, никто не купит такое. Вот тут и начнется самое интересное.

                        Нет, если уж начальники знали что ваша оценка не верна, они должны были попросить вас пересмотреть оценку, сказать что могут позволить себе оценку этой задачи в 4 недели и спросить точно ли уверен или все же стоит увеличить.

                          0
                          Ну это было конкретно к нам применимо, и действовало только после определенного времени, ну когда к нам присмотрелись. А да я на одной работе не задерживаюсь на так долго, что приходится переделывать формулу :) А то что со временем расслабляешься известный факт, смена работы или начальника лечение.
                      • UFO just landed and posted this here
                          +2
                          Форс-мажором чаще всего оказывается желание заказчика урезать сроки в два раза. Зная это, программист завышает сроки в два раза.
                          +3
                          Одно дело — заказчики. Тут можно ситуацию обыграть, доказать что и как долго будет делаться.
                          Вдвойне проблема, если со стороны заказчика выступает «компетентное» лицо — программист, который говорит заказчику: «да, вы что Семен Семеныч, вас парят. Я это сделаю за 3 часа». И ведь с таким заведомо-заинтересованным «компетентным» лицом куда сложнее договориться, потому что он не понимает (или делает вид, что не понимает), что длительность переговоров УЖЕ с лихвой перекрыли ЕГО сроки.
                            +2
                            Ну тогда можно сказать «Действительно, Семен Семеныч, с Вашей стороны будет ошибкой поручить это мне вместо Васи, если он действительно может сделать это за 3 часа. Даже если Вася — директор газпрома(условно) и хочет 50$/час, Вы сэкономите»
                            Ну а вообще лично я с таким не сталкивался, наверное еще предстоит
                            Однако лично я себя убедил в том, что начальник — сотрудник такого же уровня, что и я. Отчасти проблема с оценкой связана со страхом перед начальством. Так вот, я для себя уяснил, что неадекватных начальников не нежно бояться (а лучше даже вести себя с ними немного вызывающе), так как потерять работу такую имхо только в радость. А хорошее начальство никогда тебя в такое положение не поставит, так что их и бояться нечего
                            А вообще я устал от того, что есть кто-то сверху и занимаюсь фрилансом:)
                              +30
                              А вообще я устал от того, что есть кто-то сверху и занимаюсь фрилансом:)

                              Звучит как: «Я устала заниматься сексом за деньги, потому ушла из борделя и стала индивидуалкой»
                                +3
                                А вообще я устал от того, что есть кто-то сверху и занимаюсь фрилансом:)

                                Ах, ну да, ну да, ведь работа на фрилансе подразумевает полное отсутствие начальства, не так ли? :)
                                  +2
                                  Совсем нет,
                                  Фриланс дает некоторую степень свободы, территориальную независимость и бОльшие деньги.
                                  А еще имхо неплохой старт перед переходом в полностью свое дело, так как учит искать клиентов, продавать, планировать, иногда делегировать и руководить, нести полную ответственность за результат и многое другое
                                    +2
                                    > А еще имхо неплохой старт перед переходом в полностью свое дело, так как учит искать клиентов, продавать, планировать

                                    Это самое хардкорное, по-моему. Это ведь не начальник, который один и с уже известными своими закидонами. Клиенты каждый раз разные и неадекватов среди них полно, этому надо то, этому это, тому «чтобы готово вчера». Из некоторых приходится клещами вытаскивать информацию, которую по моей логике они должны были вывалить в структурированном виде первым делом.

                                    Сейчас вот как раз, заказ с первоначальным сроком в неделю растянулся и уже пошла третья, как раз из-за мутного заказчика, который не может толком сказать, где и что, у которого API пришлось неделю ждать, API насквозь дырявое, там баг, тут баг, то отсутствует, это отсутствует. Для POST запросов приходится эмпирическим путём названия полей подбирать, потому что отвечает он с неплохим таймаутом и очень мутно — сиди и расшифровывай. При этом спрашивал «Yesterday was release date, have you finished?». И это при не работающем API и выключенных серверах. Nuff said. Самое интересное, что он даже не manager-boy, а Java Developer. Приходится много думать, как его лучше спросить и как лучше реагировать на не несущие никакой полезной информации ответы.

                                    Так что я тоже думаю, что это неплохо прокачает скилл коммуникации.
                                      +1
                                      >>Yesterday was release date, have you finished?
                                      С такими условиями я таких неадекватов не терплю. Они как правило денег не приносят, но выносят мозг и прожигают мои нервы.
                                      Зачем терпеть отморозка, если есть хорошие?
                                0
                                Одно дело — заказчики
                                И совсем другое — быдлокодеры на фрилансе, которые, чтобы добавить кнопочку или поправить стиль в css-ке, просят пятизначную сумму.
                                Заказчик, который сам программист — это идеальный вариант.
                                Конечно, если у исполнителя не стоит цели подхалтурить (а у большинства, как показывает практика, именно эта цель и стоит).
                                +4
                                Всякая задача стремится занять всё отведенное ей время © что-то там из законов Мерфи
                                  +4
                                    0
                                    И это не закон а хохма была изначально. Подхваченная всеми неудачливыми руководителями, вечно срывающими сроки, как объяснение собственных неудач. Подробнее можно почитать у Де Марко.
                                  +66
                                  Видел у кого-то в портфолио: «Подстановка прилагательного `простенькая` на оценку стоимости не влияет. Примеры: `Нужна простенькая нейронная сеть`»
                                    +25
                                    Я бы даже сказал: «Подстановка прилагательного `простенькая` увеличивает стоимость в полтора раза в силу непредсказуемости»
                                      0
                                      Я эту же мысль во внутренних документах нашей маленькой, но очень гордой студии сформулировал как «Фраза „да там немного“ автоматически утраивает смету и сроки».
                                      +5
                                      Сильно хуже, когда разработчик говорит время с потолка, надеясь еще успеть 2-3 проекта попутно вести. Показалось работы на 2 дня — назвал 2 недели, и доволен, что есть запас. Оговорили деньги, сроки, взялся делать — ОПА! — а работы там и правда на 2 недели full time (о чем заказчик примерно и думал, поэтому его срок в 2 недели даже порадовал, вроде как разработчик показался адекватным), и деньги не особо изменишь — а те, другие 2-3 проекта стоят.

                                      И начинается «вешание лапши» и «завтраки».

                                      Это я к тому, что не только разрабы от неверных сроков страдают.
                                        +2
                                        Ну да, разработчики такие плохие, врут заказчикам, а то, что заходишь на фриланс и видишь предложения вроде 5к за сайт, так это, значит, нормально? А тот факт, что чтобы семью кормить, нужно минимум 2-3 проекта таких вот одновременно вести никто, конечно, не учитывает. А из двухдневного проекта получается двухнедельный, конечно, не потому, что заказчик сам не знает, чего хочет, или ему друг посоветовал использовать C++ для бэкэнда «чтоб быстрее».
                                        Я это к тому, что завышение сроков в 3 раза — это, среднестатистически, норма. Даже без учета информации из статьи, которая тут некоторое время назад была про то, что «программисты — оптимисты».
                                          +1
                                          Сам сталкивался. Поэтому прошу расписывать, как разработчик видит время и объемы. И деньги, это уж особенно важно, чтобы потом не было «а что Вы хотите, я с Вас так мало попросил, а Вы мне еще сроки требуете».

                                          «Мы не настолько богаты, чтобы заказывать сайты за 5К» :)
                                            +1
                                            Хорошо, когда заказчики компетентные и не жадные. Мир был бы однозначно лучше, если бы они представляли большинство :)
                                              +1
                                              «Ваши бы слова...»

                                              Хуже, заметно хуже, когда разработчик — компания, с понтами, «опытом» и страшным гонором. Это, так сказать, полярно противоположный вариант. Они знают объем работ, знают расклад по деньгам, но при этом даже проектировать на бумаге не умеют…
                                              0
                                              «Мы не настолько богаты, чтобы заказывать сайты за 5К» — отличная фраза. Жаль что многие все же искренне надеются что вот именно им повезло и попался разработчик и профессиональный и дешевый одновеменно, и что они не повторят судьбу многих других тоже выбравших по принципу меньшей цены, но которым не повезло и пришлось терять деньги и время и начинать все сначала. А ведь есть и те кто продолжает ходить по граблям, сначала за 5К, потом «раскошеливаются» на 30К, а сайт на самом деле 300К в первой версии (в рублях российских конечно), а потом вообще его нужно с фриланса снимать и команду набирать из 10 человек, или компанию подрядчика с аналогичными ресурсами. Так и ходят по граблям пока не дойдут до нормальной цены, либо бросят потратив деньги и кучу времени.
                                              «Сколько платишь — столько и получаешь» — правило работает в большинстве случаев. Не стоит надеятся что удастся выиграть в эту «лотерею» получив хорошо задешево.
                                                0
                                                Так ведь фриланс-сайты почитать, так все как один работают дешево, но профессионально, имеют 20-летний опыт, никогда не срывают сроки, и у каждого по 100 готовых проектов масштабов хотя бы mail.ru. И цены — от рубля и выше.

                                                Неопытный заказчик либо поведется, либо нет, и побежит к дорогим серьезным фирмам. А там та же петрушка, даром что за 5К сайт они для начала выкатят 2М рублей: как-то встречал контору, которая за запуск сайта в рамках стандартного 1с-Битрикса (т.е. тупо натянуть дизайн и разложить инфоблоки) называла 3М, и уточняла, что ни контентом, ни дописыванием модулей за эти деньги они заниматься не будут, ибо и так дешево. Сколько в тех лямах было заложено на работу — не скажу, но, похоже, по показателю «бабок на единицу лоха» они переплевывали даже цену чернил в оригинальных картриджах, которая, как известно, более прибыльна и менее рискова, чем даже наркота. «Учи, сынок, Битрикс, если из страны ехать не собираешься» :)
                                                  0
                                                  Ну я скорее говорил про тех которые понимают что то что они выбрали — дешево, но при этом надеются что им повезет и это будет еще и качественно. Ну если как пример, 5 человек оценили проект в $4-6К а один в $1К, вот и думают, возьму этого за 1К, а вдруг повезет, и получу что нужно, в крайнем случае много не потеряю. И таких много, как ни странно, приходят, рассказывают что предыдущие подрядчики «не смогли», получают оценку, иногда офигевают от разбежки с прошлой оценкой и уходят искать свою удачу дальше шагая по граблям (хотя может у них бюджет просто такой маленький, недооценили вовремя, посмотрев на порталы за 3 копейки «быстро, дешево, качественно», не знаю, кто-ж скажет наверняка). Или это может мне так везет :(

                                                  А то что вы описали, ну риск нарватся на тех кто живет за счет разового обдирания лохов а не долгосрочного сотрудничества всегда есть, но как я понимаю с репутацией у таких контор плохо, она либо плохая, либо ее нет. И если речь уже идет о 3М то можно раскошелится и заказать независимую оценку, не такая уж дорогая штука, просто все привыкли что аналитика-оценка бесплатно (на фрилансе по крайней мере).

                                                  С суперрпрофессионалами за 5$ в час на фриланс сайтах — то же самое, не может стоить хорошая работа слишком дешево, ну а чтобы понять что есть «слишком», нужно общатся с исполнителями вооружившись вилкой для снятия лапши, нужно спрашивать бывших клиентов ((письменные отзывы на фриналс сайтах — бред) и поверьте я ничуть не обижаюсь когда меня просят связать с клиентами чтобы они подтвердили что я занимался этим проектом, если конечно я вижу что это стоит того, и думаю не один я), нужно минимизировать риски за счет договора, разбивки на этапы, привлечения внешних консультантов, ну и конечно общатся, общатся и общатся, если человек профессионал, он сможет любому обьяснить чем он занимается, почему это столько стоит, какие есть варианты. Вопрос только во времени. Если исполнитель говорит «все будет ок, ты успокойся, у 100 раз так делал» — нужно бежать как можно дальше. Как мне хочется бежать и от заказчика который не готов погрузиться в проект, уделить ему кучу времени, а просто считает что можно показать несколько сайтов, функционал на которых ему нравится а исполнитель волшебным угадает что ему на самом деле нужно и все будет замечательно. Ну я конечно не говорю про задачи обьемом в день-два, я больше про крупные вещи, на месяцы, где можно потратить время и деньги на то чтобы выбрать хорошего исполнителя.

                                                  А битрикс, нет спасибо, не мое, ни в прямом смысле, ни в указанном вами :)
                                                    0
                                                    Да… «Показать несколько сайтов, которые нравятся, попросить бюджет поменьше, и сроки покороче» — это универсальный рецепт граблей, притом и заказчику, и исполнителю.

                                                    Насчет разовых обдираловок лохов — к моему ужасу, это я слышал от (не ошибаюсь если) коммерческого директора одной из всероссийских контор, которая еще и уверенно в топ-10 входит во всех конкурсах. Пусть даже я ошибаюсь, но поводов понтоваться у них масса. Только вот задумаешься иной раз — все ли их «победы» взяты именно трудом, или таким же понтом (когда заказчик лоханулся, отвалил много лямов, понял свою глупость, и просто не станет ругать такого подрядчика, чтобы глупо не выглядеть).

                                                    Аналитика — это тоже вилка, с одной стороны, аналитик вроде как разбирается, но он бы решал задачу так и так (и видит трудозатраты такие-то), а подрядчик, имя опыт (или протупив), взялся делать с другого конца. Даже если оба добросовестные, сроки аналитика и подрядчика разойдутся как в море корабли, а если проект крупный, то и непонятно будет, это сроки из-за подхода, или из-за вылизывания.

                                                    Все упирается в а) приличного подрядчика, б) необходимость во все вникать самому (хоть подрядчику, хоть заказчику), в) понимании, что кроме как «делать быстрее», в работе есть фаза «думай лучше и проектируй под задачу». И вот с пунктом «а» — самое сложное ))
                                          +3
                                          Из той же серии: «ну-у-у, раз две недели, то уж ладно, я согласен… но может понадобится пару мелких фич добавить, там на час-другой времени. просто включим в эти две недели, это ведь не проблема?»
                                          Через месяц, отбиваясь от очередной «мелкой фичи» уже люто ненавидишь заказчика, проект, собственную глупость и отсутствие посредника-менеджера, который каждую «мелкую фичу» округляет в большую сторону до дней, прописывает в договор и честно потом берет свой процент с дохода.
                                            +3
                                            Для этого есть документ тех-задания, где подробно раписано что именно делается. И есть контракт, где написано сколько это будет стоить.
                                            Еще пару мелких фич? Нет проблем, добавим, но тогда начинаем писать новое тех-задания для них и обсуждать цену за них. За ваши деньги любой каприз.
                                            +14
                                            Спасибо за этот пост. Ни о чем по сути, но очень поднял настроение )
                                              +2
                                              Бессмысленно убеждать программиста, что оцененную им задачу можно сделать быстрее. Он может ошибаться в сторону занижения сроков, но в сторону завышения — почти никогда.
                                              Еще как может, особенно если оплата идет по часам. Для объективности надо оценивать хотя бы 2-3 разработчиками. Если все трое сказали примерно одинаковые цифры — тогда да, тогда с вами согласен.
                                                +1
                                                А что делать заказчику, если все трое сказали разные сроки и суммы, отличающиеся в разы, причем часто взятые с потолка (на фрилансе в каждом первом проекте можно встретить)?
                                                  +4
                                                  Не всегда с потолка, просто на фрилансе есть 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 бесполезно, т.к. первый задавит аргументом «фигли так дорого», а третий задавит аргументом «я забочусь о заказчике, все равно все это делать надо». Любопытно, что третьих на западном фрилансе минимум, т.к. с занятостью проблем там нет, а на ру фрилансе очень много, т.к. заказы очень редки и из них пытаются выжимать по максимуму:)
                                                    0
                                                    Проблема в том что " т.к. заказчик обычно не в теме.". Если заказчику важна эта задача, ему стоит поговорить со всеми тремя, тогда он сразу поймет нужен ли ему 3 вариант (а может ему на самом деле нужна была админка, но он не знал об этом). Между 1 и 2 вариантом ему сложнее будет выбрать, но это уже риски и стоит смотреть что важнее цена или риски качества (при этом понимая что в некоторых случаях более высокая цена не гарантирует более высокого качества), репутацию, потфолио, и прочие бессмысленные вещи. Ну и если речь о реальных задачах, то там уже не заглядывая в код можно увидеть (на багах анпример) профессионализм. А значит можно защитится договором в случае большой задачи, можно разбить на этапы и прочие техники.

                                                    Но вот если заказчик и не собирается погружатся в тему, пусть и не глубоко, а видит только цену и сроки — ну тогда он сам себе злобный буратино, мало того что скорее всего ошибется с исполнителем, так еще и получит не то что нужно его бизнесу, потому что не знает и не хочет узнать, понять и разобратся что ему нужно. И под «разобратся» я конечно не имею в виду «выучить язык и технологии».
                                                  +1
                                                  Для эксперимента очень хочется попробовать такую штуку, как planning pocker и оценить, насколько точнее будут оказываться сроки.
                                                    0
                                                    Пробуйте. Если даже сроки точнее не станут, то проговорите командой функционал и лучше уложите это в голове. Задача так гораздо яснее становится. Одна голова хорошо, а две — лучше.
                                                  –1
                                                  коллеги рассказывали, точнее так, подходят и спрашивают:
                                                  — Сколько тебе надо времени развернуть веб сервер для питоновских скриптов, при условии что серв с ОСью есть, питон код (готовый к употреблению будет от разработчиков)
                                                  — Ну полчаса — час, как раз подобное на прошлой недели делал, а что?
                                                  — а тут данную задачу поставили коллеги N, он оценил это в 600 часов.
                                                    0
                                                    если это не офисная работа, то эти 600 часов могут включать работу по дому, потому что больше не когда ее делать.
                                                      0
                                                      офисная. т.е. 75 рабочих дней, т.е. почти 4 месяца.
                                                      имхо за это время можно выучить питон и написать все самому.
                                                      +2
                                                      Ситуация, когда что-то, необходимое для решения задачи, «будет...», тоже по факту увеличивает сроки как минимум в 2 раза :)
                                                        0
                                                        не совсем корректно выразился.
                                                        в оценку работы не входит работа разработчиков, вопрос к админу, сколько времени понадобиться разместить и запустить готовый код на сервере.
                                                          0
                                                          А если разработчик воспользуется какой-либо сторонней библиотекой, которой на сервере еще нету? А к ней потянутся еще зависимости?
                                                          Хотя 4 месяца конечно перебор.
                                                            0
                                                            >Хотя 4 месяца конечно перебор.
                                                            вот я о чем.
                                                            для манагера я тоже поставлю срок с вариантами осложнений, но не таких же размеров
                                                        –2
                                                        Так он может подумал что надо написать свой web сервер на котором питон крутиться будет )
                                                          0
                                                          Ваш коллега время неадекватно занизил. Я вижу сразу же 7 потенциальных проблем, которые могут занять некоторое время.
                                                          Но, конечно, не 600 часов.
                                                            0
                                                            >время неадекватно занизил
                                                            >Но, конечно, не 600 часов
                                                            так 600 часов, по вашему, это завышено или занижено?
                                                              0
                                                              Правильное время можно сказать только после того, как задача будет выполнена.
                                                              Подозреваю, что будет около 2-3 часов, если всплывут 1-2 проблемы.
                                                              Но я бы не стал говорить такое время заказчику и завысил бы его в 2-3 раза.
                                                                0
                                                                тогда давайте прикинем, что при решении данной задачи возникли все возможные проблемы.
                                                                начиная от нашествия бурундуков убийц в датацент, заканчивая саботажем со стороны разработчиков, в какое время вы бы оценили решение?
                                                                  –1
                                                                  Я говорю про реальные возможные проблемы(ОС, питон, модули, настройка проекта, недостаток файлов проекта, доп. ПО, время на общение), а вы какой-то фарс обсуждаете.
                                                                    0
                                                                    я не вижу причин на выставление столько часов на не самую сложную задачу, и пытаюсь понять, почему вы считаете, что это время занижено.
                                                                      0
                                                                      Мы просто друг друга не поняли. Я говорил, что занижено не 600ч, а полчаса-час.
                                                                        0
                                                                        ок. теперь понятно.
                                                                        про занижения полчаса час согласен, что заказчику, клиенту и манагерам необходимо предоставлять сроки завышенные на непредвиденные обстоятельства, но общение происходило в кругу «своей проф. ниши» а ворон, ворона как известно с полуслова понимает ;)
                                                          +2
                                                          Сколько раз твердили миру: составляйте ТЗ. Нет в ТЗ — значит это не заложено в сроки, не оплачивается. Оплатят сверху? Нам так же потребуется дополнительное время на реализацию новых задач. Всё просто и понятно. ТЗ это не всегда 20 страниц А4 мелким почерком (а жаль), достаточно составить список по пунктам (обычно получается 10-20 + подпункты) что надо сделать. Описать сложные моменты по одному обзацу текста (можно с картинками), потом всё это дело согласовать с разработчиками (не только программистами) и дописать/переписать. Итого: потратив чуть-чуть времени перед началом разработки проекта — сэкономить много больше времени во время реализации проекта.
                                                            0
                                                            ТЗ не панацея к сожалению. Ни для заказчика, ни для разработчика. Было у меня как то такое ТЗ по пунктам, даже к договору приложили. А когда начали реализацию, вдруг поняли что пункты некоторые можно трактовать очень по разному (хотя ну очевидными они казались при оценке, даже уточнять не стоит), т.е. в оценке я конкретно ошибся и конечно в меньшую сторону. Пришлось работать «за еду». А всего-то нужно было не надеятся на очевидность, а попросить заказчика рассказать пункт ТЗ своими словами.

                                                            Это я к тому что ТЗ можно использовать как опорную точку для обсуждения проекта, понимания его одинаково заказчиком и исполнителем, документацией для поверхностного ознакомления с проектом, но не более. А уж силу ТЗ, как способа защиты исполнителя он неучтенных задач, а казачика от невыполненных или выполненных некачественно, сильно переоценивают. Исключение — многостраничные детальнейшие ТЗ написанные профессиональными аналитиками, прошедшие через этап тестирования документации и внимательно прочитанные, полностью понятые и подписанные всеми заинтересованными сторонами. Такие встречаются очень редко, да и смысла в них в большинстве случаев мало, так как аппетит действительно приходит во время еды, и некоторые изменения в задачах нужно добавить в процессе работы над задачей (оплатив конечно и сдвинув сроки если нужно), иначе может получится так что после первого этапа сразу второй надо делать в котором учтены ошибки первого, а так можно исправить уже на первом этапе ошибки которые видны.
                                                              0
                                                              >А всего-то нужно было не надеятся на очевидность, а попросить заказчика рассказать пункт ТЗ своими словами.

                                                              >Это я к тому что ТЗ можно использовать как опорную точку для обсуждения проекта

                                                              Я как бы об этом и написал:
                                                              >потом всё это дело согласовать с разработчиками (не только программистами) и дописать/переписать.

                                                              Только вот не согласен что
                                                              >документацией для поверхностного ознакомления с проектом, но не более
                                                              Если мы говорим о фрилансе (без договора, без вообще каких-либо оформлений) то проще заказчику сказать чтото типа «напишите в ТЗ всё что вы отите сделать, сразу предупреждаю — нет в ТЗ, значит делать не надо». Потом опять же уточняете спорные моменты, оцениваете и работаете по этому списку задач.
                                                              Если же мы говорим о работе с юр.лицами, договорами, оформлением, налогами итд то там без варианта —
                                                              > 20 страниц А4 мелким почерком

                                                              Рассказывать мне что
                                                              >А уж силу ТЗ, как способа защиты исполнителя он неучтенных задач, а казачика от невыполненных или выполненных некачественно, сильно переоценивают
                                                              вообще изначально бессмысленно. Я сам работаю по описанной мной схеме и знаю много других фрилансеров кто работает так, и почему-то это работает. К тому моменту как текущее ТЗ закончится заказчик может увидеть что не доделано и составить дополнительное задание которое потом будет ещё и дополнено исполнителем потому что он уже знает что и как надо делать.
                                                                0
                                                                Оценка полноты ТЗ — это отдельный навык, который надо развивать.
                                                              +16
                                                              Я бы изменил текст:
                                                              сначала на разработку нужно было потратить одну неделю, после обсуждения две.
                                                                +5
                                                                Тоже ждал такой концовки.
                                                                0
                                                                Программисту респект за то, что он сразу все обсуждает с заказчиков. И выставляет его ожидания. Индусы не парятся — струячат все картинками, если что — в договоре не было написано, что это берется с сервера, даже то, что это должен быть label. И все равно к ним идут, потому что для самого первого прототипа и так сгодится.

                                                                А потом, конечно, доделывают честные русские девелоперы… и заказчик офигевает, сколько стоит действительно хорошее приложение.
                                                                  +1
                                                                  Говорят же, что «со времён египетских пирамид, сроки по строительству не исполняются».
                                                                  Связано ли это с тем, что раньше разработчиков хоронили вместе с фараоном?
                                                                  • UFO just landed and posted this here
                                                                      +1
                                                                      Хотелось бы эту статью перевести на все языки мира, чтобы торжественно вручать клиентам, партнёрам и коллегам для ознакомления :))

                                                                      Only users with full accounts can post comments. Log in, please.