Здравствуйте, turbocode, Вы писали:

T>>>Не смеши меня, ну что ты там за три месяца мог такого большого написать?
S>>4 Мб исходников. DI, много слоев. Скажу что многие вообще не используют DI.

T>Напугал. Много слоёв? А они точно были нужны? Может поэтому сроки и были просраны?

Точно нужны. Выделение слоев в как в дизайне графическом так и в дизайне ПО -- это основа всего. Они не увеличивают сроки а наоборот упрощают работу с проектом. Но нужно понимать как все устроено.

T>>>P.S. Как то заезжали проекты которые писались сотней человек десяток лет — там одних сырцов на гигабайты. И ничего никто в обморок не падал.

S>>Такие проекты без документации не пишутся. Если нет документации -- то значит есть незаменимый специалист и только он знает как все устроено.

T>Документация в общих чертах по архитектуре конечно есть, но в коде документации нету.
T>Человека который бы понимал что там везде происходит в гигабайтах кода — конечно же нету, да и это невозможно: объять необъятное.
T>Но тем не менее — не смотря на всё — проекты развиваются и поддерживаются.

Это плохой пример. Хотя бы документация по архитектуре должна быть полной. А мелочи уже можно восстановить из контекста.

Здравствуйте, Shmj, Вы писали:

S>Не знаю, раньше я очень стыдился этого. А теперь начинаю мыслить иначе. Понятно что можно применить тактику и умножить ожидаемые сроки на число пи. Но нахрен кому нужны такие сроки?

На число пи — перебор. Я множу на число Эйлера.

Не совсем понимаю. Обычно при разговоре с заказчиком возникает триада: сумма, срок, функциональность. Или ты работешь консультантом с почасовой оплатой, не привязанным к сроку и конечной сумме, только периодически выдаешь отчеты, подтверждающие твою полезную кипучую деятельность?

Если проект не очень большой, и ты планируешь работать в основном один, то зависимость деньги-срок довольно линейна, и ты сам заинтересован в том, чтобы вычислить срок поточнее, минимум его верхнюю границу. Если ты не юниор, то опыт позволит вычислить срок довольно точно и оценить запас. Особенно если ты используешь хорошо известные тебе технологии. Если проект короткий (условно, до 3 месяцев), запас на непредвиденные затыки должен быть побольше. Если есть незнакомые технологии — тоже. Если в проекте что-то зависит от третьих лиц, поведение которых вносит элемент непрежсказуемости, — тоже. И т.д. Я, когда это имеет значение, прикидываю 3 варианта: оптимистический, реалистичный, пессимистический.

Обычно первый этап работы — составление ТЗ. В нем задача разбивается на этапы, утрясаются требования, сроки, расписываются взаимные обязанности, и все становится намного яснее.

S>Кстати, возможно в этом искажении есть и огромный плюс.
S>Есть подозрение что этот эффект заложен природой и имеет созидательную функцию. Если бы мы не занимались шапкозакидательством а видели реальные сложности, то отказывались бы от многих сложных проектов.
Зависит от: фикси или сторонний разработчик
Для стороннего — может получиться, что привлечешь кого-то. Но он придет к тебе в следующий раз, имея подобный опыт? Ну и "карму" (репутацию) портит. Хотя если заказчик в результате доволен, то может и все будет неплохо.
Если ты постоянно будешь занижать сроки для своего внутреннего заказчика — будут большие проблемы. Поэтому лучше давать сроки более реальные либо договариваться о прототипировании — когда реализуется часть функциональности и заказчик может и посмотреть что получится и сроки можно будет более точно оценить. Хотя были ситуации, когда реализовывали упрощенный прототип и заказчик говорил — меня это устраивает, я не готов тратить еще 1-2 месяца, чтобы получить все остальные хотелки...

Здравствуйте, Shmj, Вы писали:

S>Кстати, возможно в этом искажении есть и огромный плюс. Вот, на одном из проектов я планировал сделать примерно за месяц, а пыхтел 3 месяца. Если бы сказал что сделаю за 3 -- то заказчик бы не согласился, слишком долго. А так согласились и довели до конца. А уже в процессе просто никто не хотел останавливаться, бросать на пол пути.

В простонародье это называется "кинуть лоха"

НС>В простонародье это называется "кинуть лоха"
Если он сильно дешево работал то заказчик может и потерпеть.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В простонародье это называется "кинуть лоха"

Нет. Заказчик получил услугу быстро и качественно, за недорого.

Но при этом, по неопытности, он думал что эту же работу можно сделать быстрее. Опыта у него не было, хотел сделать проект. Деньги есть а опыта и связей нет. Такое бывает. Не все же потомственные управленцы, верно?

Кинуть -- это взять деньги и потом послать нах или исчезнуть.

Здравствуйте, turbocode, Вы писали:

НС>>В простонародье это называется "кинуть лоха"
T>Если он сильно дешево работал то заказчик может и потерпеть.

Не сильно дешево, просто по средней рыночной цене. Разве плохо работать по рыночной цене?

Здравствуйте, Shmj, Вы писали:

S>Есть подозрение что этот эффект заложен природой и имеет созидательную функцию. Если бы мы не занимались шапкозакидательством а видели реальные сложности, то отказывались бы от многих сложных проектов. Как представишь сколько там работы -- так и ну его нафиг, лучше что-нибудь более реальное сделаю, лучше киоск по продаже хлеба поставлю...

Это дефект того, что мозг плохо умеет работать с вероятностями. Эволюционно выработалась способность быстро, пусть и не качественно производить оценку событий. Текущий алгоритм имеет неверно умножает вероятности. Если вероятность события P равна умножению вероятностей событий P1, P2 и P3, то мозг даст оценку P меньше, чем P1 * P2 * P3. Чем больше количество ошибок, тем больше погрешность.

Пример, если успех проекта зависит от 10 событий, и каждое имеет вероятность успеха в 98%, то человек может оценить успешность всего события примерно в 95%, а то и вообще в 98%. Попробуй оцени сам, не используя калькулятор.

S>Как вам кажется, является ли шапкозакидательство положительным качеством?
1. Это не шапкозакидательство, это естественное чувство при работе с виртуальными мирами. Нет материальной составляющей.
Которая имеет вес, размер, длиину, расстояние и т.п. Которое измеряется конкретно.
2. Надо просто умножать свою первоначальную оценку на Пи...
3. Производительность программиста зависит от качеств программиста, и практически не завыисит от опыта.
Многократно подтверждалоось. Самое известное подтверждение — Листер, де Марко — Peopleware

LVV>3. Производительность программиста зависит от качеств программиста, и практически не завыисит от опыта.

По вашему зеленые джуны смогут написать что то серьезное без опыта?

S>Не сильно дешево, просто по средней рыночной цене. Разве плохо работать по рыночной цене?

Пока что неизвестно по какой причине заказчик решил переплатить тебе две средних зарплаты, а не заменить тебя через две недели после старта когда уже было понятно что проект провален.

Здравствуйте, turbocode, Вы писали:

S>>Не сильно дешево, просто по средней рыночной цене. Разве плохо работать по рыночной цене?

T>Пока что неизвестно по какой причине заказчик решил переплатить тебе две средних зарплаты, а не заменить тебя через две недели после старта когда уже было понятно что проект провален.

Потому что 20% выполненной работы в IT для внешнего наблюдателя выглядят как 80% готовности. Ведь если за месяц сделали 80%, значит, так уж и быть, можно потерпеть еще недельку и получить то что хотел, пусть и с незначительной переплатой.

На первом этапе выбор такой:

1. Выгнать и потерять оплату за 3 недели (оплата понедельная). После чего искать другого разработчика, который не факт что выполнит лучше/быстрее. Вообще разработчика очень сложно найти, месяцами можно искать.

2. Не выгонять и оплатить еще 2 недели, получив готовый проект.

Что вы выберете? Ясно что любой нормальный челоевек выберет п. 2, чтобы не терять деньги. Ведь лучше доплатить за 2 недели, чем потерять за 3.

Далее. Проходят 2 недели и история повторяется.

При этом я не говорю об обмане. Вам уже много раз говорили -- задача оценки сроков -- это не задача разработчика. Он делает исключительно оптимистические сроки.

Здравствуйте, Слава, Вы писали:

С>Да это не шапкозакидательство, а естественное следствие того, что вся айти-индустрия построена на тотальном вранье. И если заказчику не врать — как другие делают, то он уйдёт.

все таки айти сильно оторванно от реальности и других сфер человеческой деятельности

Здравствуйте, turbocode, Вы писали:

LVV>>3. Производительность программиста зависит от качеств программиста, и практически не завыисит от опыта.

T>По вашему зеленые джуны смогут написать что то серьезное без опыта?

Зелёный джун может быть гораздо более производительным, чем лентяй с 20-летним опытом. Другой вопрос, что эта производительность может быть вхолостую.

S>1. Выгнать и потерять оплату за 3 недели (оплата понедельная). После чего искать другого разработчика, который не факт что выполнит лучше/быстрее. Вообще разработчика очень сложно найти, месяцами можно искать.
За 2 недели, третью тебе не оплатят — услышав что ты снова ничего не сделал, но код заберут конечно же. И код можно же передать новому разработчику, конечно он будет кривится но за неделю разберется (это та самая неоплаченная тебе неделя).

S>2. Не выгонять и оплатить еще 2 недели, получив готовый проект.
Можно перевести проект на Fixed Price (то есть оплата по факту выполнения — если ты так уверен что за 2 недели справишься), но ты ж сам не согласился бы? Верно?
Параллельно в это время подыскивать нового разработчика.

Как ни крути заказчику при любом раскладе тебя нужно выкидывать за борт.

Здравствуйте, 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>Как ни крути заказчику при любом раскладе тебя нужно выкидывать за борт.

За что? За то что даю неверные прогнозы? Ведь работа выполняется качественно и не дорого (по рыночной цене).

Заказчик не готов работать с тем, кто будет давать верные прогнозы. Он будет по-любому искать того, кто наобещает сделать быстро и дешево. А это, в большинстве своем, ни к чему хорошему не приведет.

Здравствуйте, Shmj, Вы писали:

Ты просрал проект, к тебе больше нет доверия и теперь будь готов лететь за борт.

Здравствуйте, turbocode, Вы писали:

T>Ты просрал проект, к тебе больше нет доверия и теперь будь готов лететь за борт.

Тебе уже много раз выше опытные люди объяснили твою ошибку. Прочитайте хотя бы ответ нашего уважаемого Лаптева, который не первый десяток лет работает в академических кругах, учит людей писать ПО. Это азы.

А вас мне искренне жаль. Я сам раньше был таким.

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

LVV>>3. Производительность программиста зависит от качеств программиста, и практически не завыисит от опыта.
>По вашему зеленые джуны смогут написать что то серьезное без опыта?
Почитайте Литера и Де Марко.
1. Речь идет о производительности НЕЗАВИСИМО от задач. Серьезность и несерьезность задачи тут пофиг.
2. Листер и Де марко только подтвердили удивительные ре6зультаты, которые были получены еще в 60-х годах.
Мем 10х родился еще тогда.
Конкретно: производительность лучших программистов по сравнению с худшими (с точки зрения производительности!) примерно в 10 раз лучше.
3. Листер и де Марко отмечают, что зависимость от опыта работы была отмечена как раз у юниоров первого года. После 3 лет производительность от опыта не зависит.
Читайте классиков!

Здравствуйте, LaptevVV, Вы писали:

LVV>3. Листер и де Марко отмечают, что зависимость от опыта работы была отмечена как раз у юниоров первого года. После 3 лет производительность от опыта не зависит.

Это если под программированием понимать кодирование, без проектирования.