T>В любом случае факап на +2 месяца это жестко, допустимая норма +1 неделя, если уж совсем жопа то +2 недели. Но никак не +2 месяца.
Наивный чукотский вьюнош ! Кажется, году в 2005 мне на глаза попалась статья от PwC, где говорилось, что по их мировым данным ИТ-проект в среднем по срокам просирается в 5 раз, а по деньгам в 3 О каком кошмаре Вы говорите, а?
Re: Шапкозакидательство в разработке ПО: хорошо или плохо?
S>Как вам кажется, является ли шапкозакидательство положительным качеством?
1. Это не шапкозакидательство, это естественное чувство при работе с виртуальными мирами. Нет материальной составляющей.
Которая имеет вес, размер, длиину, расстояние и т.п. Которое измеряется конкретно.
2. Надо просто умножать свою первоначальную оценку на Пи...
3. Производительность программиста зависит от качеств программиста, и практически не завыисит от опыта.
Многократно подтверждалоось. Самое известное подтверждение — Листер, де Марко — Peopleware
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>Заказчик потерпел убытки, так как если бы все честно оценивали свои силы то он мог бы найти исполнителя который сделал бы тоже самое за 1.5 — 2 месяца.
Или не мог бы. Или нашёл бы того, кто возился бы полгода.
Об убытках в таких ситуациях можно говорить только постфактум (когда гарантировано известно что кто-то сделал то же самое быстрее/дешевле), а не фантазировать.
Re: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Shmj, Вы писали:
S>Как вам кажется, является ли шапкозакидательство положительным качеством?
Да это не шапкозакидательство, а естественное следствие того, что вся айти-индустрия построена на тотальном вранье. И если заказчику не врать — как другие делают, то он уйдёт.
Re: Шапкозакидательство в работе: хорошо или плохо?
S>Как вам кажется, является ли шапкозакидательство положительным качеством?
Это обычная индусская тактика: наобещать заказчику нереального и потом годами кормить его завтраками не забывая при этом биллить жопочасы.
Заказчик потерпел убытки, так как если бы все честно оценивали свои силы то он мог бы найти исполнителя который сделал бы тоже самое за 1.5 — 2 месяца.
Re[3]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>Не смеши меня, ну что ты там за три месяца мог такого большого написать?
4 Мб исходников. DI, много слоев. Скажу что многие вообще не используют DI.
T>P.S. Как то заезжали проекты которые писались сотней человек десяток лет — там одних сырцов на гигабайты. И ничего никто в обморок не падал.
Такие проекты без документации не пишутся. Если нет документации -- то значит есть незаменимый специалист и только он знает как все устроено.
Re: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Shmj, Вы писали:
S>Есть подозрение что этот эффект заложен природой и имеет созидательную функцию. Если бы мы не занимались шапкозакидательством а видели реальные сложности, то отказывались бы от многих сложных проектов. Как представишь сколько там работы -- так и ну его нафиг, лучше что-нибудь более реальное сделаю, лучше киоск по продаже хлеба поставлю...
Это дефект того, что мозг плохо умеет работать с вероятностями. Эволюционно выработалась способность быстро, пусть и не качественно производить оценку событий. Текущий алгоритм имеет неверно умножает вероятности. Если вероятность события P равна умножению вероятностей событий P1, P2 и P3, то мозг даст оценку P меньше, чем P1 * P2 * P3. Чем больше количество ошибок, тем больше погрешность.
Пример, если успех проекта зависит от 10 событий, и каждое имеет вероятность успеха в 98%, то человек может оценить успешность всего события примерно в 95%, а то и вообще в 98%. Попробуй оцени сам, не используя калькулятор.
Re[4]: Шапкозакидательство в работе: хорошо или плохо?
T>>>Это обычная индусская тактика: наобещать заказчику нереального и потом годами кормить его завтраками не забывая при этом биллить жопочасы. S>>Индусы нынче рулят даже Микрософтом... Тактика работает.
T>Просрали они много чего и дальше просирают.
Тем не менее, в ИТ-индустрии нет тенденции к уменьшению их присутствия. А значит, в этой тактике есть рациональное зерно.
T>>>Заказчик потерпел убытки, так как если бы все честно оценивали свои силы то он мог бы найти исполнителя который сделал бы тоже самое за 1.5 — 2 месяца.
S>>Хрена с два! В 99% случаев проект бы не завершили -- поверьте моему опыту. S>>Большинство проектов в таких условиях даже до релиза не доводят.
T>Всё доводят если проект изначально не для распила, попутно увольняя хитрожопых
Поверьте, настоящие хитрожопые скорее Вас уволят с Вашим руководством. А с СЕО они найдут общий язык, кк показывает практика.
Re[14]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>>>Не смеши меня, ну что ты там за три месяца мог такого большого написать? S>>4 Мб исходников. DI, много слоев. Скажу что многие вообще не используют DI.
T>Напугал. Много слоёв? А они точно были нужны? Может поэтому сроки и были просраны?
Точно нужны. Выделение слоев в как в дизайне графическом так и в дизайне ПО -- это основа всего. Они не увеличивают сроки а наоборот упрощают работу с проектом. Но нужно понимать как все устроено.
T>>>P.S. Как то заезжали проекты которые писались сотней человек десяток лет — там одних сырцов на гигабайты. И ничего никто в обморок не падал.
S>>Такие проекты без документации не пишутся. Если нет документации -- то значит есть незаменимый специалист и только он знает как все устроено.
T>Документация в общих чертах по архитектуре конечно есть, но в коде документации нету. T>Человека который бы понимал что там везде происходит в гигабайтах кода — конечно же нету, да и это невозможно: объять необъятное. T>Но тем не менее — не смотря на всё — проекты развиваются и поддерживаются.
Это плохой пример. Хотя бы документация по архитектуре должна быть полной. А мелочи уже можно восстановить из контекста.
Re: Шапкозакидательство в разработке ПО: хорошо или плохо?
S>Кстати, возможно в этом искажении есть и огромный плюс. S>Есть подозрение что этот эффект заложен природой и имеет созидательную функцию. Если бы мы не занимались шапкозакидательством а видели реальные сложности, то отказывались бы от многих сложных проектов.
Зависит от: фикси или сторонний разработчик
Для стороннего — может получиться, что привлечешь кого-то. Но он придет к тебе в следующий раз, имея подобный опыт? Ну и "карму" (репутацию) портит. Хотя если заказчик в результате доволен, то может и все будет неплохо.
Если ты постоянно будешь занижать сроки для своего внутреннего заказчика — будут большие проблемы. Поэтому лучше давать сроки более реальные либо договариваться о прототипировании — когда реализуется часть функциональности и заказчик может и посмотреть что получится и сроки можно будет более точно оценить. Хотя были ситуации, когда реализовывали упрощенный прототип и заказчик говорил — меня это устраивает, я не готов тратить еще 1-2 месяца, чтобы получить все остальные хотелки...
Re[2]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В простонародье это называется "кинуть лоха"
Нет. Заказчик получил услугу быстро и качественно, за недорого.
Но при этом, по неопытности, он думал что эту же работу можно сделать быстрее. Опыта у него не было, хотел сделать проект. Деньги есть а опыта и связей нет. Такое бывает. Не все же потомственные управленцы, верно?
Кинуть -- это взять деньги и потом послать нах или исчезнуть.
Re[8]: Шапкозакидательство в разработке ПО: хорошо или плохо
LVV>>3. Производительность программиста зависит от качеств программиста, и практически не завыисит от опыта. >По вашему зеленые джуны смогут написать что то серьезное без опыта?
Почитайте Литера и Де Марко.
1. Речь идет о производительности НЕЗАВИСИМО от задач. Серьезность и несерьезность задачи тут пофиг.
2. Листер и Де марко только подтвердили удивительные ре6зультаты, которые были получены еще в 60-х годах.
Мем 10х родился еще тогда.
Конкретно: производительность лучших программистов по сравнению с худшими (с точки зрения производительности!) примерно в 10 раз лучше.
3. Листер и де Марко отмечают, что зависимость от опыта работы была отмечена как раз у юниоров первого года. После 3 лет производительность от опыта не зависит.
Читайте классиков!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, LaptevVV, Вы писали:
LVV>3. Листер и де Марко отмечают, что зависимость от опыта работы была отмечена как раз у юниоров первого года. После 3 лет производительность от опыта не зависит.
Это если под программированием понимать кодирование, без проектирования.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[15]: Шапкозакидательство в разработке ПО: хорошо или плох
Здравствуйте, turbocode, Вы писали:
S>>Тогда стоимость планирования будет сопоставима со стоимостью разработки. И сроки планирования будут достаточно большими.
T>Выходит что у тебя тупо нету опыта.
Тебе уже объясняли -- если задачи не типовые (типа ты каждый день делаешь сайты-визитки с ограниченным набором функционала) -- опыт не поможет.
Как вы объясните это:
Ошибка происходит независимо от того, знает ли индивидуум, что решение аналогичных задач в прошлом потребовало больше времени, чем планировалось
https://ru.wikipedia.org/wiki/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%BF%D0%BB%D0%B0%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
T>>>P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта. S>>Если чел. может спрогнозировать все этапы работы при проектировании -- он не будет заниматься наемным трудом. Нафиг это ему нужно, если он с такой же легкостью сможет составит бизнес-план и замутить бизнес, который будет приносить чистую прибыль, не требуя постоянного участия.
T>Допустим я оценил бы проект по себе в месяц работы, потом заказчик пришел бы к тебе а ты реально потратил три месяца. Кто виноват? Я или Ты?
А если мозг включить?
Задачу можно выполнить по-разному. У меня за 10+ лет работы не было ни одного случая, когда бы условия не расширялись/уточнялись в процессе работы. Задаете вопросы, предлагаете варианты и заказчик отказывается от своих старых идей в пользу новых. А это увеличивает время. Все просто.
Шапкозакидательство в разработке ПО: хорошо или плохо?
Есть ли в психологии такое когнитивное искажение как "шапкозакидательство"?
Почти всегда кажется что проект требует меньше денег и сил, чем потом выясняется в процессе работы. Особенно это актуально, когда наблюдаешь за работой со стороны. Всегда хочется сказать -- "та шо там делать, на что можно столько времени тратить".
С опытом это когнитивное искажение удается контролировать, но избавиться полностью практически не реально.
Кстати, возможно в этом искажении есть и огромный плюс. Вот, на одном из проектов я планировал сделать примерно за месяц, а пыхтел 3 месяца. Если бы сказал что сделаю за 3 -- то заказчик бы не согласился, слишком долго. А так согласились и довели до конца. А уже в процессе просто никто не хотел останавливаться, бросать на пол пути. Хотя и не очень приятно что больше времени/денег ушло, но дело то сделано, а это далеко не всем удается.
Есть подозрение что этот эффект заложен природой и имеет созидательную функцию. Если бы мы не занимались шапкозакидательством а видели реальные сложности, то отказывались бы от многих сложных проектов. Как представишь сколько там работы -- так и ну его нафиг, лучше что-нибудь более реальное сделаю, лучше киоск по продаже хлеба поставлю...
Как вам кажется, является ли шапкозакидательство положительным качеством?
Здравствуйте, turbocode, Вы писали:
T>Это обычная индусская тактика: наобещать заказчику нереального и потом годами кормить его завтраками не забывая при этом биллить жопочасы.
Индусы нынче рулят даже Микрософтом... Тактика работает.
T>Заказчик потерпел убытки, так как если бы все честно оценивали свои силы то он мог бы найти исполнителя который сделал бы тоже самое за 1.5 — 2 месяца.
Хрена с два! В 99% случаев проект бы не завершили -- поверьте моему опыту.
Большинство проектов в таких условиях даже до релиза не доводят.
Заказчик сам понятия не имел сколько чего стоит и насколько сложно сделать.
Re[3]: Шапкозакидательство в работе: хорошо или плохо?
T>>Это обычная индусская тактика: наобещать заказчику нереального и потом годами кормить его завтраками не забывая при этом биллить жопочасы. S>Индусы нынче рулят даже Микрософтом... Тактика работает.
Просрали они много чего и дальше просирают.
T>>Заказчик потерпел убытки, так как если бы все честно оценивали свои силы то он мог бы найти исполнителя который сделал бы тоже самое за 1.5 — 2 месяца.
S>Хрена с два! В 99% случаев проект бы не завершили -- поверьте моему опыту. S>Большинство проектов в таких условиях даже до релиза не доводят.
Всё доводят если проект изначально не для распила, попутно увольняя хитрожопых которые только молоть языком способны и биллить жопочасы.
Поверь три месяца вместо одного не могут пройти не замеченными и в любом случае должен был быть разбор полётов почему так случилось и такой факап часто приводит к увольнению исполнителя.
Правда по скраму тебе конечно начали бы выедать мозг уже после малейшего отклонения от плана, но там коллективная ответственность поэтому увольнять нужно всю команду целиком в таком случае.
S>Заказчик сам понятия не имел сколько чего стоит и насколько сложно сделать.
Заказчику поступают предложения и он выбирает то что видит более правдоподобным или нанимает отдельно эксперта для консультаций который выберет за него.
Re[3]: Шапкозакидательство в работе: хорошо или плохо?
T>>Заказчик потерпел убытки, так как если бы все честно оценивали свои силы то он мог бы найти исполнителя который сделал бы тоже самое за 1.5 — 2 месяца. MC>Или не мог бы. Или нашёл бы того, кто возился бы полгода. MC>Об убытках в таких ситуациях можно говорить только постфактум (когда гарантировано известно что кто-то сделал то же самое быстрее/дешевле), а не фантазировать.
В любом случае факап на +2 месяца это жестко, допустимая норма +1 неделя, если уж совсем жопа то +2 недели. Но никак не +2 месяца.
Re[4]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>Просрали они много чего и дальше просирают.
Прибыль компании растет, акции не обрушились.
T>Всё доводят если проект изначально не для распила, попутно увольняя хитрожопых которые только молоть языком способны и биллить жопочасы.
Далеко не все. Часто деньги заканчиваются до релиза. Или релиз сделан лишь номинальный, а по факту имеем какашку, с которой никто не хочет работать.
T>Поверь три месяца вместо одного не могут пройти не замеченными и в любом случае должен был быть разбор полётов почему так случилось и такой факап часто приводит к увольнению исполнителя.
А опыт у вас какой? Сколько лет работаете, выполняли ли проекты самостоятельно или руководили ли проектами?
S>>Заказчик сам понятия не имел сколько чего стоит и насколько сложно сделать.
T>Заказчику поступают предложения и он выбирает то что видит более правдоподобным или нанимает отдельно эксперта для консультаций который выберет за него.
Дайте координаты такого эксперта. Серьезно.
Re[4]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>В любом случае факап на +2 месяца это жестко, допустимая норма +1 неделя, если уж совсем жопа то +2 недели. Но никак не +2 месяца.
А где вы нормы нашли? В какой книге?
Re[2]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Слава, Вы писали:
С>Да это не шапкозакидательство, а естественное следствие того, что вся айти-индустрия построена на тотальном вранье. И если заказчику не врать — как другие делают, то он уйдёт.
Подозрения есть что весь мир построен на вранье. Дела государственной важности -- точно.
Re[5]: Шапкозакидательство в работе: хорошо или плохо?
T>>В любом случае факап на +2 месяца это жестко, допустимая норма +1 неделя, если уж совсем жопа то +2 недели. Но никак не +2 месяца. S>А где вы нормы нашли? В какой книге?
По своему опыту в пределах +/- 20% это нормально ошибаться.
Re[6]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>>>В любом случае факап на +2 месяца это жестко, допустимая норма +1 неделя, если уж совсем жопа то +2 недели. Но никак не +2 месяца. S>>А где вы нормы нашли? В какой книге?
T>По своему опыту в пределах +/- 20% это нормально ошибаться.
А опыт какой у вас? Руководите проектами, фрилансер или работаете по найму?
Re[7]: Шапкозакидательство в работе: хорошо или плохо?
S>Далеко не все. Часто деньги заканчиваются до релиза. Или релиз сделан лишь номинальный, а по факту имеем какашку, с которой никто не хочет работать.
Если заказчик в ИТ полный ноль то да его могут одурманить Кумары и доить его до полного банкротства.
T>>Заказчику поступают предложения и он выбирает то что видит более правдоподобным или нанимает отдельно эксперта для консультаций который выберет за него. S>Дайте координаты такого эксперта. Серьезно.
Эксперты экспертов знают друг друга издалека по результатам работы и никому координатов давать не нужно.
Я так понимаю что вы пытаетесь влезть туда где у вас нету ни опыта ни связей поэтому у вас такие и проблемы возникают (из таких компаний выживает 1 из 1000, если она не имеет других источников дохода).
Здравствуйте, turbocode, Вы писали:
S>>А опыт какой у вас? Руководите проектами, фрилансер или работаете по найму? T>Достаточный, работал во всех ролях и в роли заказчика в том числе.
Ну а конкретнее. Какого уровня проекты делали? Сколько человек в подчинении было? Каков максимальный срок разработки одного проекта? Каков бюджет?
По вашим ответам у меня создалось впечатление, что работали в основном с мелкими заказами, типа фриланса или около того.
Re[6]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
S>>Далеко не все. Часто деньги заканчиваются до релиза. Или релиз сделан лишь номинальный, а по факту имеем какашку, с которой никто не хочет работать. T>Если заказчик в ИТ полный ноль то да его могут одурманить Кумары и доить его до полного банкротства.
А эксперта же он может нанять, если сам ничего не понимает?
T>>>Заказчику поступают предложения и он выбирает то что видит более правдоподобным или нанимает отдельно эксперта для консультаций который выберет за него. S>>Дайте координаты такого эксперта. Серьезно.
T>Эксперты экспертов знают друг друга издалека по результатам работы и никому координатов давать не нужно. T>Я так понимаю что вы пытаетесь влезть туда где у вас нету ни опыта ни связей поэтому у вас такие и проблемы возникают (из таких компаний выживает 1 из 1000, если она не имеет других источников дохода).
Ну вот заказчик в IT не понимает, но деньги есть. Где ему нанять эксперта, который скажет что почем или сможет оценить работу по факту?
Re[9]: Шапкозакидательство в работе: хорошо или плохо?
S>Ну а конкретнее. Какого уровня проекты делали? Сколько человек в подчинении было? Каков максимальный срок разработки одного проекта? Каков бюджет?
Ну вот зачем мне тебе это рассказывать?
S>По вашим ответам у меня создалось впечатление, что работали в основном с мелкими заказами, типа фриланса или около того.
Ты не прав.
Re[10]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
S>>Ну а конкретнее. Какого уровня проекты делали? Сколько человек в подчинении было? Каков максимальный срок разработки одного проекта? Каков бюджет?
T>Ну вот зачем мне тебе это рассказывать?
Почему бы не рассказать? Не требуется же называть конкретные фирмы и названия проектов.
S>>По вашим ответам у меня создалось впечатление, что работали в основном с мелкими заказами, типа фриланса или около того.
T>Ты не прав.
Да ну.
Re[7]: Шапкозакидательство в работе: хорошо или плохо?
S>А эксперта же он может нанять, если сам ничего не понимает?
Если ничего не можешь, то лучше покупай элитную недвигу в центре Лондона там хотя бы посмотреть, пощупать и ощутить можно то что покупаешь.
Re[8]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
S>>А эксперта же он может нанять, если сам ничего не понимает? T>Если ничего не можешь, то лучше покупай элитную недвигу в центре Лондона там хотя бы посмотреть, пощупать и ощутить можно то что покупаешь.
Каждый человек сам решает на что просрать деньги. Хочет создать свой проект -- никто не имеет права запретить.
Вы же писали:
Заказчику поступают предложения и он выбирает то что видит более правдоподобным или нанимает отдельно эксперта для консультаций который выберет за него.
Вот я и спрашиваю: где вы видели таких экспертов? И какие гарантии что эксперт дал верную оценку?
Re[9]: Шапкозакидательство в работе: хорошо или плохо?
S>Каждый человек сам решает на что просрать деньги.
Я думаю что твой заказчик всё же хочет заработать денег, а не просрать.
Для просрать в мире создана целая индустрия развлечений.
S>Вот я и спрашиваю: где вы видели таких экспертов? И какие гарантии что эксперт дал верную оценку?
Потому что у эксперта есть опыт, есть за плечами выполненные проекты, он может разложить задачи по полочкам, расставить порядок и приоритеты задач, объяснить почему его оценка задач такая а не другая.
Re: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Shmj, Вы писали:
S>Как вам кажется, является ли шапкозакидательство положительным качеством?
Некоторые качества в одних ситуациях полезны, а в других оказываются вредны.
Если работа творческая, то уверенность в своих силах необходима, а срок оценить невозможно.
Неспособность оценить сроки если необходимые действия вообщем ясны — это недостаток, и в большинстве случаев мешает.
А программисты обычно быстро учатся умножать все сроки на 3 при оценке.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, turbocode, Вы писали:
lpd>>А программисты обычно быстро учатся умножать все сроки на 3 при оценке. T>Он же говорит что не получил бы работы в таком случае.
Тогда нужно было правильно оценить срок, и соврать работодателю. А слепо доверяться своим ошибкам не стоит.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[2]: Шапкозакидательство в разработке ПО: хорошо или плохо
Здравствуйте, lpd, Вы писали:
lpd>А программисты обычно быстро учатся умножать все сроки на 3 при оценке.
Проблема в том что такая оценка никому не нужна. Тебе скажут: ну и что ты там собрался делать 3 месяца? А ты что скажешь? Покажешь таблицу с рассчетами на 1 месяц и скажешь что я умножил на число ПИ?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>А программисты обычно быстро учатся умножать все сроки на 3 при оценке.
S>Проблема в том что такая оценка никому не нужна. Тебе сказут: ну и что ты там собрался делать 3 месяца? А ты что скажешь? Покажешь таблицу с рассчетами на 1 месяц и скажешь что я умножил на число ПИ?
Если начальник программист, то так и надо говорить.
Если менеджер, то умножать сроки каждой работы на 3.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[2]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, SergeyIT, Вы писали:
S>>Как вам кажется, является ли шапкозакидательство положительным качеством? SIT>Если задаешь такие вопросы, значит ты не специалист, имхо
Не знаю, раньше я очень стыдился этого. А теперь начинаю мыслить иначе. Понятно что можно применить тактику и умножить ожидаемые сроки на число пи. Но нахрен кому нужны такие сроки?
Re[4]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, lpd, Вы писали:
lpd>Если менеджер, то умножать сроки каждой работы на 3.
Есть ли за вашей спиной очередь из заказчиков, ожидающих работы с вами?
Если да -- то можно так сказать.
Если нет, то проект передадут тому, кто "смягчил ситуацию". А уже в процессе работы есть множество способов обосновать почему заняло больше времени. Ведь если сделали 20% работы, то выглядит как почти готово (выглядит как будто сделано 80%). И всегда можно сказать -- ну вот, только немножко осталось. Далее проходит немножко, доводите до 50% -- сроки выбрали в 2 раза. Далее заказчик сам понимает что передавать проект другому исполнителю -- будет потеря всего что уже потратил плюс не факт что сделают лучше и быстрее -- ничего не остается как платить вам до победного конца.
Так или нет?
Re[5]: Шапкозакидательство в работе: хорошо или плохо?
G>Тем не менее, в ИТ-индустрии нет тенденции к уменьшению их присутствия. А значит, в этой тактике есть рациональное зерно.
Точно? Тогда почему у всех стоит бронепоезд на запасном пути? Не для того чтобы съехать с Windows в случае чего?
T>>Всё доводят если проект изначально не для распила, попутно увольняя хитрожопых G>Поверьте, настоящие хитрожопые скорее Вас уволят с Вашим руководством. А с СЕО они найдут общий язык, кк показывает практика.
Если цель распилить, а не достичь результата то так и будет. CEO должен решить для себя что ему важнее? А если его обманули — значит хреновый СЕО и если он обанкротится то никто его жалеть не будет.
Re[5]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>Если менеджер, то умножать сроки каждой работы на 3.
S>Есть ли за вашей спиной очередь из заказчиков, ожидающих работы с вами?
S>Если да -- то можно так сказать.
S>Если нет, то проект передадут тому, кто "смягчил ситуацию". А уже в процессе работы есть множество способов обосновать почему заняло больше времени. Ведь если сделали 20% работы, то выглядит как почти готово (выглядит как будто сделано 80%). И всегда можно сказать -- ну вот, только немножко осталось. Далее проходит немножко, доводите до 50% -- сроки выбрали в 2 раза. Далее заказчик сам понимает что передавать проект другому исполнителю -- будет потеря всего что уже потратил плюс не факт что сделают лучше и быстрее -- ничего не остается как платить вам до победного конца.
S>Так или нет?
Если работа через сайт для фриланса, то если заказчик все же откажется на середине, то можно потерять рейтинг.
Если ты заключаешь договор на исполнение работ, то обычно прописывается неустойка. Если неустойке не слишком большая, то, наверное, в таком подходе может быть смысл.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[4]: Шапкозакидательство в разработке ПО: хорошо или плохо?
lpd>Тогда нужно было правильно оценить срок, и соврать работодателю. А слепо доверяться своим ошибкам не стоит.
Репутация плохая будет --> погонят с отрасли.
Re[5]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
lpd>>Тогда нужно было правильно оценить срок, и соврать работодателю. А слепо доверяться своим ошибкам не стоит. T>Репутация плохая будет --> погонят с отрасли.
Значит, нужно провести оценику рисков .
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[5]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
S>>Как вам кажется, является ли шапкозакидательство положительным качеством? T>Это обычная индусская тактика: наобещать заказчику нереального и потом годами кормить его завтраками не забывая при этом биллить жопочасы. T>Заказчик потерпел убытки, так как если бы все честно оценивали свои силы то он мог бы найти исполнителя который сделал бы тоже самое за 1.5 — 2 месяца.
Но-но, поосторожнее! Ты сейчас соотечественника обвинил в ведении нечестного бизнеса/в нечестном ведении бизнеса. За это можно и присесть. Украину не любишь, похоже
M>Но-но, поосторожнее! Ты сейчас соотечественника обвинил в ведении нечестного бизнеса/в нечестном ведении бизнеса. За это можно и присесть. Украину не любишь, похоже
Он вроде как сам в этом сознался.
Боялся потерять работу поэтому наврал заказчику что сделает всё за месяц.
Re[4]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
M>>Но-но, поосторожнее! Ты сейчас соотечественника обвинил в ведении нечестного бизнеса/в нечестном ведении бизнеса. За это можно и присесть. Украину не любишь, похоже T>Он вроде как сам в этом сознался. T>Боялся потерять работу поэтому наврал заказчику что сделает всё за месяц.
Здравствуйте, turbocode, Вы писали:
T>Потому что у эксперта есть опыт, есть за плечами выполненные проекты, он может разложить задачи по полочкам, расставить порядок и приоритеты задач, объяснить почему его оценка задач такая а не другая.
Конкретно дайте ссылку на сервис, который предоставляет услуги по оценке стоимости и сроков.
Re[6]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, lpd, Вы писали:
lpd>Если работа через сайт для фриланса, то если заказчик все же откажется на середине, то можно потерять рейтинг.
Не откажется. Он же уже за 2 месяца минимум десятку килобаксов потратил. У меня никто еще не отказывался, деньги то потрачены.
Притом заказчик видит сколько работы сделано, что ты реально работаешь.
Какой смысл ему терять деньги в обмен на унижение тебя? Тем более один отзыв мало на что повлияет.
lpd>Если ты заключаешь договор на исполнение работ, то обычно прописывается неустойка. Если неустойке не слишком большая, то, наверное, в таком подходе может быть смысл.
А вот тут нужно разумно подгодить к заключению договора. Оставить пункт, что добавление нового функционала продляет сроки. А новый функционал вы всегда можете предложить.
Re[5]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
lpd>>Тогда нужно было правильно оценить срок, и соврать работодателю. А слепо доверяться своим ошибкам не стоит. T>Репутация плохая будет --> погонят с отрасли.
Если это заказ на 1000 баксов -- возможно. Когда речь о десятках -- никто не будет рисковать ради мести. Тем более видно что вы работаете и сделали очень много, просто оценка была не верна.
Re[6]: Шапкозакидательство в разработке ПО: хорошо или плохо?
T>>Потому что у эксперта есть опыт, есть за плечами выполненные проекты, он может разложить задачи по полочкам, расставить порядок и приоритеты задач, объяснить почему его оценка задач такая а не другая. S>Конкретно дайте ссылку на сервис, который предоставляет услуги по оценке стоимости и сроков.
Это не сервисы, это связи которые собираются всю жизнь.
Но ты конечно же можешь завалится в какой то там Luxoft и они тебе там наоценивают в мегабаксы долларов даже самый простецкий проект.
Re[7]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>Если работа через сайт для фриланса, то если заказчик все же откажется на середине, то можно потерять рейтинг.
S>Какой смысл ему терять деньги в обмен на унижение тебя? Тем более один отзыв мало на что повлияет.
Если один отзыв не повлияет, то это можно считать способом получать заказы жадных заказчиков.
lpd>>Если ты заключаешь договор на исполнение работ, то обычно прописывается неустойка. Если неустойке не слишком большая, то, наверное, в таком подходе может быть смысл.
S>А вот тут нужно разумно подгодить к заключению договора. Оставить пункт, что добавление нового функционала продляет сроки. А новый функционал вы всегда можете предложить.
Гениально.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[5]: Шапкозакидательство в работе: хорошо или плохо?
S>Я не наврал а просто не стал умножать сроки на 3, как тут советуют.
Не парься, в случае с жопочасами тебя тяжело в чем то обвинить — ты ж педали крутил? крутил!
А то что не выкрутил за месяц так это проблема заказчика что поставил не на ту лошадку которая крутит быстрее и дешевле.
Re[12]: Шапкозакидательство в работе: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>Но ты конечно же можешь завалится в какой то там Luxoft и они тебе там наоценивают в мегабаксы долларов даже самый простецкий проект.
Именно так. Я уже приводил пример сервиса, который контора оценила о $45 тыс до $60 тыс. А фрилансер подрядился делать за $150 и две недели Не сделал, конечно. Ему платили где-то год, добрал до $1000, потом просто жалко стало и завершили этот эксперимент.
Re[7]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>Не парься, в случае с жопочасами тебя тяжело в чем то обвинить — ты ж педали крутил? крутил! T>А то что не выкрутил за месяц так это проблема заказчика что поставил не на ту лошадку которая крутит быстрее и дешевле.
Вам уже приводили статистику -- "ИТ-проект в среднем по срокам просирается в 5 раз, а по деньгам в 3". Нет лошаков, которые сделают быстрее и дешевле. Пообещать -- пожалуйста. Сделать -- фиг.
Re[8]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
T>>>Так, но погонят тебя сразу же после закрытия тобой последнего таска. S>>А поддержкой проекта кто будет заниматься?
T>Ваш код так сильно ужасен?
Не ужасен, просто его много и нет документации. Ведь документация по коду не писалась, итак времени нету...
Re[9]: Шапкозакидательство в разработке ПО: хорошо или плохо?
T>>Не парься, в случае с жопочасами тебя тяжело в чем то обвинить — ты ж педали крутил? крутил! T>>А то что не выкрутил за месяц так это проблема заказчика что поставил не на ту лошадку которая крутит быстрее и дешевле. S>Вам уже приводили статистику -- "ИТ-проект в среднем по срокам просирается в 5 раз, а по деньгам в 3". Нет лошаков, которые сделают быстрее и дешевле. Пообещать -- пожалуйста. Сделать -- фиг.
Вранье. Сдавали проекты в срок, но в команде не было Кумаров конечно и контроль за сроками был довольно жесткий.
Re[10]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
S>>Вам уже приводили статистику -- "ИТ-проект в среднем по срокам просирается в 5 раз, а по деньгам в 3". Нет лошаков, которые сделают быстрее и дешевле. Пообещать -- пожалуйста. Сделать -- фиг.
T>Вранье. Сдавали проекты в срок, но в команде не было Кумаров конечно и контроль за сроками был довольно жесткий.
Но тогда заказчика ваши сроки не устроят. Я то назвал в 3 раза ниже, чем называете вы. Он стал работать со мной. С вами работать не будет.
Вы ничего лучше предложить не можете. Пусть я ошибаюсь в сроках, зато имею оптимистичные прогнозы
T>>Это нормально, специалист читает код как газету (документация ему будет даже мешать) S>Кода реально много. Разобраться уйдет где-то месяц минимум.
Не смеши меня, ну что ты там за три месяца мог такого большого написать?
P.S. Как то заезжали проекты которые писались сотней человек десяток лет — там одних сырцов на гигабайты. И ничего никто в обморок не падал.
Re[9]: Шапкозакидательство в работе: хорошо или плохо?
S>Но тогда заказчика ваши сроки не устроят. Я то назвал в 3 раза ниже, чем называете вы. Он стал работать со мной. С вами работать не будет. S>Вы ничего лучше предложить не можете. Пусть я ошибаюсь в сроках, зато имею оптимистичные прогнозы
Кому нужны твои месячные проекты? Успокойся. Никто на них не претендует.
Re[10]: Шапкозакидательство в работе: хорошо или плохо?
T>>Не смеши меня, ну что ты там за три месяца мог такого большого написать? S>4 Мб исходников. DI, много слоев. Скажу что многие вообще не используют DI.
Напугал. Много слоёв? А они точно были нужны? Может поэтому сроки и были просраны?
T>>P.S. Как то заезжали проекты которые писались сотней человек десяток лет — там одних сырцов на гигабайты. И ничего никто в обморок не падал.
S>Такие проекты без документации не пишутся. Если нет документации -- то значит есть незаменимый специалист и только он знает как все устроено.
Документация в общих чертах по архитектуре конечно есть, но в коде документации нету.
Человека который бы понимал что там везде происходит в гигабайтах кода — конечно же нету, да и это невозможно: объять необъятное.
Но тем не менее — не смотря на всё — проекты развиваются и поддерживаются.
Re[3]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Shmj, Вы писали:
S>Не знаю, раньше я очень стыдился этого. А теперь начинаю мыслить иначе. Понятно что можно применить тактику и умножить ожидаемые сроки на число пи. Но нахрен кому нужны такие сроки?
На число пи — перебор. Я множу на число Эйлера.
Не совсем понимаю. Обычно при разговоре с заказчиком возникает триада: сумма, срок, функциональность. Или ты работешь консультантом с почасовой оплатой, не привязанным к сроку и конечной сумме, только периодически выдаешь отчеты, подтверждающие твою полезную кипучую деятельность?
Если проект не очень большой, и ты планируешь работать в основном один, то зависимость деньги-срок довольно линейна, и ты сам заинтересован в том, чтобы вычислить срок поточнее, минимум его верхнюю границу. Если ты не юниор, то опыт позволит вычислить срок довольно точно и оценить запас. Особенно если ты используешь хорошо известные тебе технологии. Если проект короткий (условно, до 3 месяцев), запас на непредвиденные затыки должен быть побольше. Если есть незнакомые технологии — тоже. Если в проекте что-то зависит от третьих лиц, поведение которых вносит элемент непрежсказуемости, — тоже. И т.д. Я, когда это имеет значение, прикидываю 3 варианта: оптимистический, реалистичный, пессимистический.
Обычно первый этап работы — составление ТЗ. В нем задача разбивается на этапы, утрясаются требования, сроки, расписываются взаимные обязанности, и все становится намного яснее.
Re: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, Shmj, Вы писали:
S>Кстати, возможно в этом искажении есть и огромный плюс. Вот, на одном из проектов я планировал сделать примерно за месяц, а пыхтел 3 месяца. Если бы сказал что сделаю за 3 -- то заказчик бы не согласился, слишком долго. А так согласились и довели до конца. А уже в процессе просто никто не хотел останавливаться, бросать на пол пути.
В простонародье это называется "кинуть лоха"
Re[2]: Шапкозакидательство в разработке ПО: хорошо или плохо?
S>Не сильно дешево, просто по средней рыночной цене. Разве плохо работать по рыночной цене?
Пока что неизвестно по какой причине заказчик решил переплатить тебе две средних зарплаты, а не заменить тебя через две недели после старта когда уже было понятно что проект провален.
Re[5]: Шапкозакидательство в разработке ПО: хорошо или плохо
Здравствуйте, turbocode, Вы писали:
S>>Не сильно дешево, просто по средней рыночной цене. Разве плохо работать по рыночной цене?
T>Пока что неизвестно по какой причине заказчик решил переплатить тебе две средних зарплаты, а не заменить тебя через две недели после старта когда уже было понятно что проект провален.
Потому что 20% выполненной работы в IT для внешнего наблюдателя выглядят как 80% готовности. Ведь если за месяц сделали 80%, значит, так уж и быть, можно потерпеть еще недельку и получить то что хотел, пусть и с незначительной переплатой.
На первом этапе выбор такой:
1. Выгнать и потерять оплату за 3 недели (оплата понедельная). После чего искать другого разработчика, который не факт что выполнит лучше/быстрее. Вообще разработчика очень сложно найти, месяцами можно искать.
2. Не выгонять и оплатить еще 2 недели, получив готовый проект.
Что вы выберете? Ясно что любой нормальный челоевек выберет п. 2, чтобы не терять деньги. Ведь лучше доплатить за 2 недели, чем потерять за 3.
Далее. Проходят 2 недели и история повторяется.
При этом я не говорю об обмане. Вам уже много раз говорили -- задача оценки сроков -- это не задача разработчика. Он делает исключительно оптимистические сроки.
Здравствуйте, Слава, Вы писали:
С>Да это не шапкозакидательство, а естественное следствие того, что вся айти-индустрия построена на тотальном вранье. И если заказчику не врать — как другие делают, то он уйдёт.
все таки айти сильно оторванно от реальности и других сфер человеческой деятельности
Re[3]: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
LVV>>3. Производительность программиста зависит от качеств программиста, и практически не завыисит от опыта.
T>По вашему зеленые джуны смогут написать что то серьезное без опыта?
Зелёный джун может быть гораздо более производительным, чем лентяй с 20-летним опытом. Другой вопрос, что эта производительность может быть вхолостую.
Re[6]: Шапкозакидательство в разработке ПО: хорошо или плохо
S>1. Выгнать и потерять оплату за 3 недели (оплата понедельная). После чего искать другого разработчика, который не факт что выполнит лучше/быстрее. Вообще разработчика очень сложно найти, месяцами можно искать.
За 2 недели, третью тебе не оплатят — услышав что ты снова ничего не сделал, но код заберут конечно же. И код можно же передать новому разработчику, конечно он будет кривится но за неделю разберется (это та самая неоплаченная тебе неделя).
S>2. Не выгонять и оплатить еще 2 недели, получив готовый проект.
Можно перевести проект на Fixed Price (то есть оплата по факту выполнения — если ты так уверен что за 2 недели справишься), но ты ж сам не согласился бы? Верно?
Параллельно в это время подыскивать нового разработчика.
Как ни крути заказчику при любом раскладе тебя нужно выкидывать за борт.
Re[7]: Шапкозакидательство в разработке ПО: хорошо или плохо
Здравствуйте, turbocode, Вы писали:
S>>1. Выгнать и потерять оплату за 3 недели (оплата понедельная). После чего искать другого разработчика, который не факт что выполнит лучше/быстрее. Вообще разработчика очень сложно найти, месяцами можно искать. T>За 2 недели, третью тебе не оплатят — услышав что ты снова ничего не сделал,
Что значит "ничего не сделал"? Очень много сделал. А вот прогнозы да, были не верны. И что?
Как вы вообще все себе представляете? Вы представляете фриланс и PHP?
T>но код заберут конечно же.
Код не нужен без того, кто его писал.
T>И код можно же передать новому разработчику, конечно он будет кривится но за неделю разберется (это та самая неоплаченная тебе неделя).
Ну да, только разберется. А где гарантия что он будет работать быстрее?
Я же не говорю что работаю медленно. Работаю средне и оплата средняя. Не супермен, но и не туплю. А вот прогнозы -- да, прогнозы ошибочные.
Но ведь от прогнозов же ничего не поменяется -- все равно не получится потратить меньше. То что придет другой и даст вам верные прогнозы, которые будут в 3 раза выше -- ничего не улучшит для кошелька заказчика.
S>>2. Не выгонять и оплатить еще 2 недели, получив готовый проект. T>Можно перевести проект на Fixed Price (то есть оплата по факту выполнения — если ты так уверен что за 2 недели справишься), но ты ж сам не согласился бы? Верно?
Fixed Price возможен в 2 вариантах:
1. Проект совсем маленький, на 3 дня работы, причем ранее вы с подобным работали.
2. Если ты крупная контора, работа по договору, у тебя свои юристы и хорошая финансовая подушка. Но тогда ценник умножай на 10. Не на 2, не на 3 а именно на 10. И сроки бери с запасом.
Отдавая конторе заказчик снижает риск полной потери денег. При работе с конторой исключена ситуация, что потрачены деньги и не сделано ничего. Однако за эту безопасность придется переплатить в 10 раз и потратить больше времени. Такова реальность.
T>Параллельно в это время подыскивать нового разработчика.
Он быстрее работать не будет. А прогнозы заказчик для себя может умножать на 3.
T>Как ни крути заказчику при любом раскладе тебя нужно выкидывать за борт.
За что? За то что даю неверные прогнозы? Ведь работа выполняется качественно и не дорого (по рыночной цене).
Заказчик не готов работать с тем, кто будет давать верные прогнозы. Он будет по-любому искать того, кто наобещает сделать быстро и дешево. А это, в большинстве своем, ни к чему хорошему не приведет.
Re[9]: Шапкозакидательство в разработке ПО: хорошо или плохо
Здравствуйте, turbocode, Вы писали:
T>Ты просрал проект, к тебе больше нет доверия и теперь будь готов лететь за борт.
Тебе уже много раз выше опытные люди объяснили твою ошибку. Прочитайте хотя бы ответ нашего уважаемого Лаптева, который не первый десяток лет работает в академических кругах, учит людей писать ПО. Это азы.
А вас мне искренне жаль. Я сам раньше был таким.
Вот то что вы декларируете -- это и есть шапкозакидательство. Вы искренне верите что сможете дать точную оценку. На самом деле это никому не под силу, главное развернуть ситуацию так, чтобы ответственность за неверную оценку была на каждой из сторон.
LVV>>3. Листер и де Марко отмечают, что зависимость от опыта работы была отмечена как раз у юниоров первого года. После 3 лет производительность от опыта не зависит. lpd>Это если под программированием понимать кодирование, без проектирования.
Наши американские друзья так и понимают: программист — это тот, кто работает с кодом.
А кто с кодом не работает — это НЕ программисты.
Аналитики-проектировщики они...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Шапкозакидательство в разработке ПО: хорошо или плохо?
LVV>Конкретно: производительность лучших программистов по сравнению с худшими (с точки зрения производительности!) примерно в 10 раз лучше.
Кому нужна производительность без успешных результатов?
Я лучше найму опытного лентяя но который сделает мне задачу в срок (даже если он половину этого срока провалял дурака), чем джуна который будет изображать бурную деятельность но ничего не сделает.
Re[10]: Шапкозакидательство в разработке ПО: хорошо или плохо
S>Тебе уже много раз выше опытные люди объяснили твою ошибку. Прочитайте хотя бы ответ нашего уважаемого Лаптева, который не первый десяток лет работает в академических кругах, учит людей писать ПО. Это азы.
Лаптев не работает в коммерческих структурах, где нужно уметь считать время и деньги.
S>А вас мне искренне жаль. Я сам раньше был таким.
Если и дальше будешь таким то рано или поздно тебя погонят.
S>Вот то что вы декларируете -- это и есть шапкозакидательство. Вы искренне верите что сможете дать точную оценку. На самом деле это никому не под силу, главное развернуть ситуацию так, чтобы ответственность за неверную оценку была на каждой из сторон.
Если нельзя дать точную оценку — делай декомпозицию задачи до тех пор пока не сможешь дать точную оценку. Конечно погрешность всегда будет но если в интервале [-20%; +20%] то это нормально, до +50% скажем так терпимо если такое происходит не слишком часто.
Re[11]: Шапкозакидательство в разработке ПО: хорошо или плохо
Здравствуйте, turbocode, Вы писали:
S>>Тебе уже много раз выше опытные люди объяснили твою ошибку. Прочитайте хотя бы ответ нашего уважаемого Лаптева, который не первый десяток лет работает в академических кругах, учит людей писать ПО. Это азы. T>Лаптев не работает в коммерческих структурах, где нужно уметь считать время и деньги.
Ему и не нужно -- он на более высоком уровне абстракции -- знает теорию управления проектами. Его ученики уже вполне работают в коммерческих стр-рах.
S>>А вас мне искренне жаль. Я сам раньше был таким. T>Если и дальше будешь таким то рано или поздно тебя погонят.
За что? За то что делаю работу качественно по рыночной цене?
Выгнать за неумение предсказывать -- не разумно. Я могу умножать на 3, как тут советовали. Но тогда никому такие сроки не понравятся. А вот когда уже по факту -- тогда смиряются.
S>>Вот то что вы декларируете -- это и есть шапкозакидательство. Вы искренне верите что сможете дать точную оценку. На самом деле это никому не под силу, главное развернуть ситуацию так, чтобы ответственность за неверную оценку была на каждой из сторон.
T>Если нельзя дать точную оценку — делай декомпозицию задачи до тех пор пока не сможешь дать точную оценку. Конечно погрешность всегда будет но если в интервале [-20%; +20%] то это нормально, до +50% скажем так терпимо если такое происходит не слишком часто.
На этапе планирования задача видна лишь в общих чертах. В процессе появляются такие проблемы, о которых вы и помыслить не могли.
Если вы можете предвидеть все проблемы на этапе планирования -- накой черт вам наемный труд? Легко станете миллионером и вам никто не нужен.
Re[5]: Шапкозакидательство в разработке ПО: хорошо или плохо?
LVV>>Конкретно: производительность лучших программистов по сравнению с худшими (с точки зрения производительности!) примерно в 10 раз лучше. T>Кому нужна производительность без успешных результатов?
Это — по умолчанию. Неуспешные результаты в этих экспериментах отсутствуют.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[12]: Шапкозакидательство в разработке ПО: хорошо или плохо
S>На этапе планирования задача видна лишь в общих чертах. В процессе появляются такие проблемы, о которых вы и помыслить не могли.
Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна вам в той степени детализации который соответствует вашему опыту чтобы оценить.
P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта.
Re[13]: Шапкозакидательство в разработке ПО: хорошо или плохо
09.11.2017 15:01, turbocode пишет: > S>На этапе планирования задача видна лишь в общих чертах. В процессе > появляются такие проблемы, о которых вы и помыслить не могли. > > Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна > вам в той степени детализации который соответствует вашему опыту чтобы > оценить. > P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду > своего опыта.
Практически любой проект в ПО занимает всё, отведённое на него время,
всегда есть что по нему поделать (исключения довольно редки). Так что
вопрос "попадания в оценку" по проекту/этапу проекта, размером примерно
в человеко-год хотя бы — это вопрос только о том, а что мы выкинем или
сделаем чуть получше чем "good enough". Тру-синьоры это делают или
какие-либо другие — неважно. Если заказчик с оценкой "на этапе
планирования" согласен, ему будет предоставлено X ресурса, а не "в
точности Y" функционала.
--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re[13]: Шапкозакидательство в разработке ПО: хорошо или плох
Здравствуйте, turbocode, Вы писали:
S>>На этапе планирования задача видна лишь в общих чертах. В процессе появляются такие проблемы, о которых вы и помыслить не могли.
T>Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна вам в той степени детализации который соответствует вашему опыту чтобы оценить.
Тогда стоимость планирования будет сопоставима со стоимостью разработки. И сроки планирования будут достаточно большими.
Собственно, для некоторых проектов сотни тыс. у.е. на этап планирования -- это не много. Но для низкобюджетных это не подходит -- там сроки нужно назвать сразу и бесплатно, никто не будет платить серьезные деньги за проект/план. Не, ну может $400-500 и заплатят, но настоящий проект/план на эти средства не сделать.
T>P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта.
Если чел. может спрогнозировать все этапы работы при проектировании -- он не будет заниматься наемным трудом. Нафиг это ему нужно, если он с такой же легкостью сможет составит бизнес-план и замутить бизнес, который будет приносить чистую прибыль, не требуя постоянного участия.
Если чел. работает по найму -- значит мозгов на самостоятельный проект все-таки не хватило.
H>Практически любой проект в ПО занимает всё, отведённое на него время, H>всегда есть что по нему поделать (исключения довольно редки). Так что H>вопрос "попадания в оценку" по проекту/этапу проекта, размером примерно H>в человеко-год хотя бы — это вопрос только о том, а что мы выкинем или H>сделаем чуть получше чем "good enough". Тру-синьоры это делают или H>какие-либо другие — неважно. Если заказчик с оценкой "на этапе H>планирования" согласен, ему будет предоставлено X ресурса, а не "в H>точности Y" функционала.
Обычно оценивают самый минимальный функционал(но расширенный функционал тоже должен быть известен (но делать его не нужно) чтобы изначально правильно заложить архитектуру — чтобы не возникло потом ситуации "архитектура для этого не предназначена — нужно всё переделывать")
Re[14]: Шапкозакидательство в разработке ПО: хорошо или плох
T>>Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна вам в той степени детализации который соответствует вашему опыту чтобы оценить. S>Тогда стоимость планирования будет сопоставима со стоимостью разработки. И сроки планирования будут достаточно большими.
Выходит что у тебя тупо нету опыта.
T>>P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта. S>Если чел. может спрогнозировать все этапы работы при проектировании -- он не будет заниматься наемным трудом. Нафиг это ему нужно, если он с такой же легкостью сможет составит бизнес-план и замутить бизнес, который будет приносить чистую прибыль, не требуя постоянного участия.
Допустим я оценил бы проект по себе в месяц работы, потом заказчик пришел бы к тебе а ты реально потратил три месяца. Кто виноват? Я или Ты?
Наивный чукотский вьюнош ! Кажется, году в 2005 мне на глаза попалась статья от PwC, где говорилось, что по их мировым данным ИТ-проект в среднем по срокам просирается в 5 раз, а по деньгам в 3 
О каком кошмаре Вы говорите, а?
.
