Сколько работаю 1с-ником, везде вижу одну и ту же проблеми - оценка сроков. Чаще всего все терки с работодателем или заказчиком именно об обценке сроков.

Очень частая ситуация "В бухгалтерии не проводится документ, не знаю какой, сколько времени вам нужно чтобы решить проблему?"

Когда вопрос поставлен так, то тут еще не сложно выкрутиться и пояснить "Вы сдуререли?! Как я смогу это оценить из этих данных?"

Но все же часто исходных данных довольно много, но точно оценить всё равно нельзя.

Я вот привык считать что срыв сроков в программинге это нечто нормально (да почти все софт.компании срывают сроки). Другое дело, когда работодатель начинает видеть в этом проблему, и пытаться её устранить. Т.е. добиться точных оценок сроков. Т.е. невозможного.

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

Хотелось бы как выработать свой подход.

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

Работодателя понять то можно, ты ему говоришь "дней", а он слышит "рублей". "Не знаю сколько времени потребуется" = "Не скажу сколько это вам будет стоить".

После попыток начать устанавливать сроки, работодатель всегда очень быстро переходит к политике "уменьшение сроков" (аля повысить производительность единицы "1с-ник"). Без оплачиваемых сверхурочных это быстро превращается в бесплатного 1с-ника, который 8 часов работает платно, а потом еще 10 бесплатно.

На текущей работе я явно совершил какую-то тактическую ошибку со сроками. Сейчас работодатель решил карать рублем за просрок, и первая же задача от меня по срокам зависит лишь на 10%-20%. Уверен, что скоро уволюсь, не вижу решения.

Последний момент очень хороший пример. Вчера вечером уже после рабочего дня ставится задача "сделать до 12:00". На всякий случай начал делать вечером удаленно (о чем не сообщил) - кто-то выключил удаленный комп, я ничего не успел. Хотя была команда от меня комп не выключать. Утром опять не дали мне этот комп, а база только там, и по сети её не слить, инет узкий. В итоге доступ к компу получил только в 16:00. Т.е. уже после срока. Собрал все доказательства что моей вины как бы нет. Дак не помогло! Директор уперся что я слишком часто нарушаю сроки и на этот раз он типа на это глаза не закроет а вычтет из ЗП. ЗП кстати средняк в регионе, мне хватало.

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

Разумеется решил работать до зарплаты и после получения писать заявление. Серая, опыт показал что с серой ЗП, лучше сначала полследнюю получить, чем ничего не получить :)

Однако, очень хорошо прочувствовал что есть моя ошибка. До этого 3 месяца проблем не было, сроки просрачивались, а чаще всего их не было.

Большинство задач в конторе такие, что там срок только с потолка можно брать. "У нас не работает обмен с сайтом, сегодня успеете?", при том что я его в глаза не видел не разу еще :)

Но вот не первый раз я натыкаюсь об этот камень, когда требуют сроки на задачи неизвестного заранее объема работы.

Когда-то былу меня начальник, который добился идеального расклада. Для все людей, включая директора у него была одна коронная фраза:

"Сначала я бью клавиатурой по башке, 50 раз, со всей дури. После того как человек уже вырубился, я ему говорю срок, в надежде что он не запомнит. Вы уверены что хотите узнать срок?" :) Бывало кто-то говорил что хочет срок, и он демонстративно вырывал клавиатуру и шел с нею в сторону жертвы ))) Видимо комичность позволяла разрядить. Имхо не такое уж плохое у него решение, но у меня так не получалось :)

Как вы решаете оценку сроков?

Вы в концлагере работаете?
Сроки определяются очень просто - берешь максимальный период приходящий тебе в голову и умножаешь на 5. На возражения, почему так долго, говоришь подняв указательный палец: Кто из нас специалист?

Наверное, надо планировать на глубину большую чем один день.
Соберите все проблемы, отранжируйте их вместе с начальником, и заложите план.
План поделите на месяца, недели.
У начальника будет понятная картина, чем занимается сотрудник.
И часть "срочных" задач можно будет отсеять, перенеся их на следующий месяц.

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

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

Как правило, задач с дедлайном меньше половины, что сильно упрощает дело

Мне вот нравится такое сравнение:
Работа программиста такая же творческая, как и художника. Но у художника никто не спрашивает "Сколько времени у тебя займет эта картина?". Будет вдохновение - напишет за 1 вечер, не будет - может и год.
*Текст сопровождать отстраненным философским взглядом*

Где голосовалка с пунктом "ТС - неудачнег"?

(4) И у художников есть сроки.

Еще такой вариант - дали задачу, пообещал что завтра сделаешь.
А потом тебе неожиданно дают очень срочную задачу, со сроком "еще вчера".
И ты никаким образом не успеешь сделать первую задачку. Кто виноват?

(6) Уголовные? За подделку билетов банка россии?

(7) не брать вторую задачу, пока не сделана первая

(7) Не верная постановка вопроса. Если поток задач превышает количество необходимых ресурсов, то ресурсы нужно увеличивать или расставлять приоритеты.

(7) Надо систему для учета задач. И назначить ответственного, кто эти задачи расставляет по приоритетам. В этом случае к программисту вопросов не будет. Всегда понятно чем, как долго и почему он занимался

(5) С чего это? Нормальный вопрос по организации работы.

(11) есть такая система: канбан называется.
Вешаете доску, делите на три части:
1. надо сделать
2. в работе
3. сделано.

когда задача приходит в отдел - она (бумажка с ней) вешается в раздел 1.
Когда программист берет задачу в работу - она перевешивается в раздел 2. Количество задач в работе равно количеству программистов.
Когда задача сделана - она перевешивается в раздел 3.

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

После этого любой приходящий с задачей видит текущую ситуацию.

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

(12) Лично мой вывод после прочтения (0). И да, весь этот текст можно было заменить на "Помогите советом, как оценивать сроки выполнения задач". А так, он вроде как поплакался

(14) в большинстве случаев сроки выполнения никому не нужны, это чистая формальность. На что влияют озвученные сроки выполнения?

(0) Решение инцидентов происходит в заранее оговоренные сроки с бизнесом.
Сроки эти оцениваются исходя из критичности проблем, чем критичнее инцидент, тем меньше срок.
Со стороны ИТ сроки решения инцидента должны быть соблюдены

(17) тут вроде не про инциденты говориться, а про новую разработку в том числе

(16) Это чтобы программист булки не расслаблял. А то сидит на всяких мистах и вообще не понятно чем занят

(19) это нужно мотивацией решать. От того, что сам себе программист сроки ставит, он быстрее работать не будет

(18) в 0 я инцидент увидел.
По разработкам сроки устанавливает ИТ исходя из оценки своих ресурсов, тут свобода

(20) Так если начальству покажутся сроки слишком растянутыми, то оно замотивирует невыплатой премии

(21) с инцидентами сроки важны, да
но с инцидентами первая задача - понять откуда они возникают и управлять этим. Если что-то регулярно ломается - это нужно либо чинить либо планировать на это ресурс.

(22) ключевое тут слово "покажутся".

(22) замотивирует, как мы видем из топика, искать новую работу.

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

(26) все эти задачи решает аджайл.
ранжирование - да, но для ранжирования не обязательно точные сроки знать

(23) Снова мимо. Задача должна быть выполнена. Анализ инцидентов другой вопрос и решается отдельно.

(28) тредстатер жалуется, что много срочных задач по которым горят сроки.
вывод, кажется, простой - нужно понять откуда так много срочных задач по которым горят сроки.

(27) Не имея сроков выполнения работы нельзя проконтролировать время ее выполнения и нельзя планоровать работу.

(29) Да, и что? Функция сопровождения - прежде всего сопровождоть, предложения по оптимизации работы не должны мешать исполнению основной функции.

(30) в функции сопровождения нет вообще задачи оценки сроков, там есть задача оказания нужного уровня поддержки.

когда у вас сервер падает - вы же не оцениваете сроки его восстановления? берете и начинаете цинить

(31) см (14)

(0) Чего тут думать? Берешь максимально возможный срок, приходящий в голову, умножаешь на два и добавляешь неделю. Если спросят, почему так долго - читай (1)

(1) На 5 - эт чересчур, гг. Я максимально возможный срок, приходящий в голову, считаю с рисками, так что он уже немаленький.

(30) Ну и конечно надо для планирования потребности в ресурсах.

(34) Планирование ресурсов в операционной, не проектной, деятельности - дохлый номер. Тут только аджайл, причем с ресурсами "кто свободен, тот и папа".

Можно еще взять время нв постановку задачи, тестирования, опытной эксплуатации, внедрения и все это смело умножить на 3.

(35) Можно спрогнозировать поток задач и время выполнения. Статистика рулит.

(36) на 3.14)) http://www.ashmanov.com/pap/ashrul.phtml

(0) Я в ответ задаю вопрос: "Сколько времени займет сделать ремонт?". Это их успокаивает.

(0) по разработке. Есть куча методик, но все они дорогостоящие и их погрешность около 10-20%. Нужно ли тебе это? По поддержке. Ведешь учет обращений и срок их решений. Через год классифицируешь обращения и систематезируешь время их исполнения. Создаешь нормативы. Точность заложешь при статистическом анализе. Новые работы - безсрочно решаются.

+(37)  Можно контролировать поток задач. Если очередь растет, то нужно больше людей либо повышать уровень исполнителей либо искать узкое место.

(38) Бред. "Не бывает технических проблем. Бывают только человеческие, то есть организационные." Жизнь разнообразнее.

- Пожалуйста, грубо оцените срок выполнения задачи
- Два ёпаных дня

(41) планировать и контролировать можно все что угодно. вопрос только зачем.

Нужно не контролировать, а управлять.
Управлять нужно следующиим главными параметрами:
1. Какую задачу в данный момент нужно решать скорее всего.
2. Как организовать наиболее оптимальное решение этой задачи.

Когда начинаются вечные разговоры о сроках и угрозы санкций - об \тих двух пунктах как правило забывают

(43) два условных программистско-дня

(41) А каким боком контроль потока задач связан со сроками их выполнения?

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

Хотя, операционка - оно и есть косяки исправлять и свистоперделки мелкие лепить, то да.

(45) Это занудная оценка, а не грубая. :)

(0) Аналогичная проблема коллега,
Планирование сроков по проектам
но у меня скорее просто не хотят платить, а сваливают на сроки и прочее, поэтому мне компромис не найти, уже написал заявление.

(0) Чтобы оценить объем работы - нужно для сначала "поставить диагноз". По аналогии: представь, что к врачу приходит человек и говорит: "Доктор! У меня что-то болит. Сколько вам нужно времени, чтобы меня вылечить?".

Т.е. если это ошибка в программе - найти причину. Далее, оценить трудозатраты. Здесь (важно!!!) учесть все затраты: разработка ТЗ (пусть даже минимального), кодинг, тестирование (не менее 30% от кодинга!!!), согласование и т.д. Вот это время озвучиваешь руководству. При чем оценка должна быть интервальной. Т.е., к примеру, "Для реализации этого отчета нужно от 4х до 6ти часов". Если руководство наседает на конкретном сроке - выбираешь максимальный.

Еще один момент: руководство обычно думает, что если поставит "жесткие" сроки, то сотрудники будут "бегать быстрее и веселее". Если срок нереален - так и говоришь. Если сложно - запомни волшебную фразу: "Указанный срок нереален. Реальный срок - такой-то. Прошу пересмотреть указанные Вами сроки". В этом нет ничего плохого. Руководство не разбирается во всех вопросах. Поэтому  срок в любом случае за тобой.

+49 Увольняться из-за проблем со сроками - глупо. Потому как руководство любой (!!!) компании будет просить сроки.

(50) у нас не просят

(0) Волшебное правило внедренца - умножай срок, сказанный программистом на 3-5. Если срок неизвестен - говори полгода.

(46) Даже мелкая с виду свистоперделка может вылиться в переделку структуры хранения данных. По факту более-менее точно можно планировать задачи с длительностью до 1-2 часов. Да и то только после начала исполнения.

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

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

простая формула для всех:
1.дорого
2.быстро
3.качественно
Заказчик может выбрать только 2 любых пункта

(13) надо не три части, а 5. по советской системе ещё 2 гвоздя добавить)

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

Проблема со сроками решается на 50% если у человека хорошо развиты коммуникативные качества и он может внятно объяснить и успокоить клиента. Остальные 50% это дисциплина.

(50) "Войну и мир" написать за неделю? Я не на столько гениальна!

(55) Львиная доля времени убивается на выяснение, чего именно заказчик хочет.
"Написать таблицу квадратов до 100" - это четкое задание. (Хотя не факт, что именно этого заказчик хочет на самом деле. И это выяснится только при попытке сдать заказ)
"Написать таблицу, в которой будут все нужные нам(заказчику) ответы по умножению" - это очень нечеткое задание. Тут, как ни крути, должно и будет применено творчество.

(55) Есть такая проблема с некоторыми заказчиками. Ключевое слово "планировать". Планировать можно что угодно и как угодно и только при наличии техзадания, но при выходе за рамки сроков их нужно просто отодвигать, а не начинать требовать поминутного описания действий. Программирование это работа инженера а не слесаря механосборочных работ, расписать действия заранее по техкарте невозможно. В большинстве случаев, в процессе, пробуешь несколько методов в поисках оптимального решения. Ситуация "Ага, ты не успеваешь, на-ка тебе, теперь, задачку: будешь описывать подробно все действия, чтобы еще больше не успевал!". Некомпетентный в вопросе разработки сотрудник начинает просить описание работы в терминах понятных ему + время на каждый этап, получается описание типа "доработал алгоритм N  часов" и "модифицировал запрос  M часов", "подготовил описание этапов работы L часов", о чем это ему скажет и какие решения на основании этого можно принять?

+(61) Вариантов немного: или клиент в результате сам понимает, что бессмысленно требовать сроков по задачам "Хочу кнопку "сделать все хорошо"", выданных по телефону во время обеда, или начинает писать нормальные техзадания с подробным и четким описанием, по которым можно что-то запланировать.

Или надо увольняться :)

(56)имхо 1) дешево, а не дорого

(38) Хорошая статья, забрал себе в копилку знаний!

(0) Валить из такой конторы, где штрафуют за назначенные сроки.

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

(0) Не увольняйся, предлагаю такой выход: прикидываешь сколько аналогичную задачу решал в прошлом и умножай на 3!

(66) Ну да, ну да. Продолжаем взращивать в себе гения

(56) http://www.artlebedev.ru ))))

(0) А вообще уговори начальство тебе пройти обучение (чтобы выделило тебе время и деньги), и работай не 40 часов в неделю, а 60 часов и упорно работай,  не бездельничай, используй время в дороге для самообучения (книги, видеокурсы), работай в субботу,  и так в течении года,  результат будет!

(66) В бизнес-приложениях творчеству места нет. Есть необходимость в рутинных операциях автоматизации процессов. Особая креативность только навредит, т.к. максимально приближенное к типовому решение позволяет реализовать поддержку с минимальными затратами. А вот "креативная" самописка чуть ли не с ассемблерными вставками может обслуживаться, как правило, только самим "художнегом".

(68) Творческой деятельностью занимаются не только гении. Какой-нибудь копирайтер из рекламного отдела газеты "Вечерний Зaжonинск", сочиняя комментарий к рекламному объявлению, тоже творит. Где тут можно усмотреть манию величия, я не понимаю.

(72) В широком смысле даже в работе токаря или дворника есть элемент творчества. Так что не стоит тешить себя иллюзиями

Тупое программирование по ТЗ - это одно. А придумываение структур БД, преобразование сумбурных бизнес-процессов в алгоритмы, рисование интерфейсов - чистое творчество.

Раньше были проблемы, сейчас как-то с опытом полегче стало. Конечно до часа не угадаешь, но общие рамки всегда представляешь. Взял за привычку называть два срока. Максимальный и ожидаемый. Вообще после прочтения Голдратта Критическая Цепь также стало правилом максимально снижать сроки. Это мотивирует, заставляет собираться и делать. А не долго размазываться в творческом поиске. Есть уже отработанные подходы по поиску ошибки, есть отработанные методы написания нового функционала. Изобретательство тоже имеет место, но чтобы оно не затягивалось просто жеско ограничиваешь его во времени. Т.е сегодня я прикидываю различные варианты архитектуры нового функционала, завтра я реализовываю тот вариант который в итоге буду считать лучшим и пофиг если он не будет идеальным.

(71) Если бы это было так, разработка бизнес-приложений была бы полностью роботизирована. А этого мы пока не наблюдаем. (73) Нет. Работу токаря выполнит робот, а с деятельностью разработчика-внедренца робот не справится. Конечно, речь идет о текущем уровне развития технологий, в будущем ситуация может измениться.
А что за иллюзии?

(4) Работа программиста такая же творческая ...

где ты эту глупость прочитал ?

(73) А в узком смысле художник тоже ремесленник, если рисует по заказу!

(77) Это напрямую следует из определения творческой деятельности. Я не понимаю, дядьки, вы чего, при слове творчество сразу представляете себе богемного композитора в дорогом махровом халате, который бухает вискарь в 11 утра? :)

(78) В том же узком смысле, ремесленники выдадут на одно и тоже задание выдадут разные результаты и за разными сроками.

(76) Разработка приложения, способного по заложенной в него схеме бизнес-процесса писать код, вполне возможна. Более того - подобные приложения уже есть, Visual Studio умеет преобразовывать UML-диаграммы в C# код, IBM RSD/RSA умеет те же UML преобразовывать в C++ код.

Бизнес-приложения пока еще не доросли до такого, но принципиальных проблем из-за "нехватки творчества" в этом нет. Так чта...

(79) Дело не в халатах. Деятельность программиста нужно планировать по срокам. И ничего тут пальцы гнуть

(81) А вот проектирование UML-диаграммы хрен автоматизируешь. О чем и речь.

(44) Это цикл PDCA. Никакого анализа не может быть без планирования, исполнения, проверки и только в конце анализ.

(44) Поток сознания.

(82) Безусловно, нужно. И маститый композитор тоже должен сдать музыку в срок. Это не отменяет творческого характера деятельности по разработке программных продуктов.

если не можешь оценить сроки твоей реализации задачи значит ты не спец.Оценил.Устроило.Делай. Сделал раньше молодец, плохо оценил делаешь за свое личное время и должен успеть к сроку.
  Это касается любой профессии.
Ко мне приходили спецы на дачу делать ремонт, например обшить сайдингом.
Спрашиваю, сколько времени и денег нужно? 2/3 начинают ломаться ну примерно так, а дальше как пойдет- таких сразу в сад посылаю.

ага, расскажите про PDCA буху, которому завтра отчетность сдавать, а у него что-то не проводится
http://www.pankovarules.ru/#!pdca-по-русски/zoom/c11lv/image7gl

(88) Это не задача буха, а линейного руководителя.

(70) И зарплату не смей просить вообще!

(83) Проектирование UML-диаграммы уже визуализировано достаточно настолько, что программистом для этого быть не обязательно. Любой, кто понимает моделирование процессов, сможет создать описательную UML-диаграмму. При этом ему совершенно не надо знать ни одного языка программирования.

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

(78) А не ремесленники нищенствуют, зато получают после смерти мировую славу.

+(91) Я к чему все это - в бизнес-приложениях рано или поздно все придет к тому, что описание бизнес-логики станет доступно любому непрограммисту. Никому не станет нужен "идеальный" код, который не укладывается в стандарты и типовые модели, соответственно, не поддерживаем в принципе. Да такой код, в общем-то, и сейчас не особо приветствуется.

(92) Гы, особенно у Blizzard, Valve  и Bioware: As it done.

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

(95) Да, и что, если есть объективные причины сдвигать сроки, то их нужно сдвигать.

(0) Вали оттудова нафиг!

(97) ты не понял: они вообще не оглашают сроков. Их позиция: "Когда будет готово, тогда и выпустим".

(81) Дык это... составление схемы и есть творчество, ибо заказчик, как правило, сам не знает чего хочет.

(96) Если в будущее смотреть - машине достаточно будет сообщить "хочу сделать сеть шаурмячных в городе N". Она на основании этих данных рассчитает места наибольшей проходимости, поставку мяса из местных живодерен, потребительский индекс относительно шаурмы и т.д.

Повторюсь - _принципиальных_ проблем для создания такой машины нет. И ничего творческого машина не использует - только статистику и расчет цепочки поставок.

(99) И правильно делают. Причем тут люди с улицы? Это бизнес.

(0) Я когда ремонт делал, расписал максимально этапы работы и этапы оплаты для мастеров, дал им возможность самим поставить сроки. В итоге сроки превысили в 2 раза. И в общем я считаю что еще хорошо отделался

А ведь ремонт можно спланировать вплоть до каждой операции, ну плюс погрешность в 20%

И вообще, нефиг путать программиста с кодером.

(79) т.е. плитку класть это тоже творчество, да ? :)

(77) Инженеры! - "Творчески одаренные и рационально мыслящие  ученые,  которые способны выстроить планету в любое время в любом месте". (с) Роберт Шекли. Планета по смете

Рассказ практически про прогрраммистов ;)

Если интересно, то полностью рассказ здесь http://lib.misto.kiev.ua/SHEKLY/30-22.txt

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

(91) Вот типичное путание программиста и кодера. Программист может не написать ни одной строки кода, и, тем не менее, быть программистом.

(105) Класть плитку - это искусство...

(103) у меня сроки и смета от плана - 10% получилось.

(105) Еще как! Ты не представляешь как трудно найти хорошего плиточника, и хорошего сварщика

(101) А где говорилось о принципиальной невозможности творческой деятельности для машины? Она невозможна только на данный момент - что, собственно, позволяет нам сейчас легко определить, относится конкретная деятельность к творческой или нет, просто проверив, справится ли с ней машина.

(111) плиточников и сварщиков в ПТУ учат ;)
и программистам ПТУ достаточно

(101) Ты сроки создания такой машины назови. Конкретные.

(113) теоретик блин. Ты задолбаешся искать ХОРОШЕГО сварщика. Попробуй

(107) Тебе нужно вернуться к определению понятия "творчество", а то ты сейчас договоришься до того, что его не существует в принципе. :)

(114) Ты готов заплатить мне за предварительный анализ? Без проблем, дай мне ресурсы - я тебе и сроки назову, и план проекта набросаю.

Только количеству нулей в сметах не удивляйся.

(115) Дык опыт нужен, как сварщику, так и программисту.

(117) Давай сроки и стоимость - а я тебе скажу - заплачу или нет.

(115) я не задолбаюсь :)
у меня друг сварщиком работал.
а его тесть - варил хрень всякую при стоительстве АЭС.
в союзные времена у тестя з\п сварщика была 1000-1300 р.
инженеры столько не получали :)

(116) Творчество - это создание чего-либо "с нуля". Новой концепции, новой модели. Если ты разработаешь новую модель бизнеса, принципиально новую концепцию программирования и т.д. - вот это творчество.

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

(120) Почему ты упорно кодера называешь программистом?

Начался околонаучный флуд одинэсников.
Вернемся к ситуации в (0). Автор имеет проблемы также с организацией своего времени, как и с самоутверждением в коллективе. То есть типа з...а такого

(118) Т.е. ты, будучи заказчиком, хочешь, чтобы я потратил свои ресурсы на поиск ответа на заданный тобой вопрос?

Забавные вы. Полветки уже обсуждается, что оплачивается ЛЮБАЯ работа, связанная с потребностями заказчика - и тут на тебе, выкати мне халявную оценку и анализ, а я решу, платить или нет.

(121) Что в твоем понимании "программист"?

(101) и как скоро наступит такое будущее, если не секрет?

на самом деле, когда закзачик просит сроки - ему не обязательно нужны именно сроки. Ему, возможно, нужно что-то другое (например, уверенность что прог балду не пинает).
Поэтому - нужно понять что нужно заказчику и сделать так, чтобы у него это было.

Вот тут про это хорошо написано: http://habrahabr.ru/company/stratoplan/blog/202028/

(124) См. (117)

(120) При этом создавая то, чего не существовало раньше. ЧТД. Потому что если бы оно существовало, то зачем заказчику вообще заказывать разработку? Бери и пользуйся.

(124) Кстати, системы BI, способные "подсказывать" ответы на нечетко сформулированные вопросы, уже есть.

(0) Знакомая проблема. Я организовываю учет задач/выполнения, что-то типа доски в (13) , только в электронном виде.

забавно, когда строят "северный поток" в сроки укладываются, а когда надо немножечко типовую поправить так сразу проблемы :)

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

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

Инженер - по сути своей ремесленник в первую очередь, а уж во вторую - изобретатель.

(123) 1. Да, потому что иначе ты получишь деньги, а потом ничего не сделав выставишь астрономические сроки и суммы. Не, так дело не пойдет. Тыж специалист - должен сходу сказать когда и сколько.
2. Прочитай хоты бы его должностные инструкции. В них не только и не столько тупое кодирование.

(130) Ты не понимаешь. Там не творческие люди работают.

(134) конечно,там только суровые дядьки с лопатами. :))

(130) Укладываются, как же. Тупо вносят изменения в проектную документацию. Это практикуется со времен строительства египетских пирамид.

(132) хороший инженер - изобретатель с навыками ремесленника.

(136) да-да-да, все так и было.

(136) Очень небольшие изменения.

(132) Какие комплексы? Просто присутствует творческий момент в нашей деятельности, вот и все, зачем это отрицать?

+(139) Тем более не в проектную документацию.

(136) так переносили, что даже раньше срока сдали первую очередь.

(139) Дай мне финансирование хотя бы 1/1000 от стоимости Нордстрима и я гарантировано поправлю типовую в заданный срок. :)

(140) если только чуть-чуть :)

На старой работе, во франче когда там работал(Жадный франч был). Мои задачи оценивала одна женщина, около 45 лет. При устройстве на работу, она проводила со мной собеседование. В итоге обо мне у нее сложилось не правильное представление, ей показалось, что специалист я отличный, с опытом, а тогда опыт у меня был пол года. Бух. учет она знала, а 1с 8 -нет

Мое мнение, она всегда занижала часы, как бы говорила "РЕШИМ ЗАДАЧУ ЧУТЬ ДЕШЕВЛЕ, ОСТАВИМ О СЕБЕ ХОРОШЕЕ ВПЕЧАТЛЕНИЕ, ЧТО БЫ ОНА В ДАЛЬНЕЙШЕМ К НАМ ОБРАТИЛАСЬ С ДРУГОЙ ЗАДАЧЕЙ"

(143) Ты должен сам осметиться, дать сроки и стоимости работ.

(143) ха-ха-ха, даже если я тебе дам 100500 от стоимости нордстрима ты не родишь за 3 мес.

(140) Никто не отрицает наличия творческого элемента в деятельности программиста. Только не стоит думать, что творчество не присуще деятельности токаря или инженера. Кстати, и менеджера

Интересная ситуация. Ведутся проектные работы на лямы ч/ч и все прекрасно планируется.

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

Твой вопрос звучит ровно как требование "Нарисуйте большую кнопку "Сделать за.бись!"

(144) Стопроценто творческая деятельность только у бородатого дядьки, сидящего на облаке.

(148) это как-бы элемент любой работы, если она тебе нравится и ты к ней относишься ответственно.

(152) Совершенно согласен. Поэтому я против взращивания мифа о богоизбранности прогов.

(148) Менеджера - безусловно, а с работой токаря вроде бы должен справляться достаточно простой робот-станок, разве нет?

(153) лет 30-35 проги действительно были "богоизбранными" :)

сейчас обычные работники,

(153) А кто такие мифы культивирует? Обычная профессия, в деятельности которой присутствуют элементы творчества. Одна среди многих. Где избранность-то?

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

(155) Не уверен. Создастся новый язык программирования, который будет упрощен и рассчитан на среднего программиста.

(0) Как я тебя понимаю. Вот моя тебя примерно год назад
v8: Опять сорвал свои же сроки выполнения или как правильно рассчитать время....
Как решить проблему? Очень просто Архангельский + экспириенс в проф. области. Начинай читать, потом еще раз читать и уже понимать, на третий раз применяешь. Проверено на практике, работает.

(154) Ты с военными не работал - вот где творчество прет. Один завод получил заказ от военных, на чертежах допуски десятые доли миллиметра, изготовили строго по чертежам и уложились в тысячные доли миллиметра. В итоге вся партия в брак. Почему? А потому что военные сказали "Нам чертежи пофиг, у нас есть шаблон для проверки деталей - если деталь подходит к нему - ОК, не подходит - брак". А шаблоны с теми же самыми допусками в десятые миллиметры сделаны.

В регионах это обычное дело, пытаться прогнуть по баблу. Всякие немыслимые схемы разрабатывают, лишь бы платить поменьше. Как правило и клиенты и работодатели мудачье как в (0)

(161) :)))

(161) зачем схемы ?

отнимаешь 30% от предложенной сметы и торгуешься дальше.

в мск ровно так же.

(161) какие сметы у работодателя? в (0) фикси

(164) А какие претензии к его работодателю? Работодатель должен терпеть бесконечную неорганизованность и необязательность? все время "входить в положение"?

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

Прогибать по баблу штатника это ахтунг какой-то.

на самом деле, обычно работадателю плевать на сроки.
Ему на что-то другое не плевать, например, нужно чтобы бухгалтерия вовремя отчетность сдала.

Если на это (то, что важно работодателю) обращать внимание, то достаточно быстро никто не будет требовать сроков по любому поводу.

да ясен пень, я и говорю, что тупо пытается экономить, ему похеру эти сроки

(167) Я не вижу ничего плохого в депремировании сотрудника, если он реально допустил прокол

(170) У тебя тоже зарплата 10% официальный оклад и 90% черная премия? И ты гордо называешь это депремированием, если зажмешь  т.н. "премию"?

(171) А почто про меня. Автор не мой сотр.
А что депремирование возможно только при черной или серой ЗП? Глупость какая. От цвета ЗП ничего не зависит, если делать все грамотно.
Даже в колхозе на 100% белой ЗП- депремирование обыденное явление.

Вопрос то не в том, нужны сроки или не нужны. Все понимают что нужныю И вопрос не в том, плохо это или нет, не укладываться в сроки, все понимают, что это бывает и это нормально.
Вопрос в том, стоит ли за назначенных хз кем срок "ставится задача "сделать до 12:00", и невыполнение этого срока наказывать программиста рублем?

(172) Нормальный спец не пойдет на оклад 10% и 90% премию, пусть даже 100% белую, если она не существенно выше рынка. Потому что он спец и уже знает, чем это грозит.

(173) вопрос вот в чем - почему от программиста требуют сроки и наказывают рублем?
Это может очень сильно зависит от поведения конкретного программиста

в регионах такая шняга сплошь и рядом у буржуев типа (172)

поэтому в регионах все сплошь фришники или франчи, а на фикси только неопытные лохи типа (0)

(157) Т.е. на основании того, что я за ответ на вопрос прошу денег, ты делаешь вывод, что я ни хрена не знаю?

Типичный быдлозаказчик именно так и поступает, вообще-то.

(176) Вау!! Меня назвали буржуем. Какой комплимент!

(178) Именно. Ты не знал конкретных сроков и стоимости, а так уверенно говорил... а когда про них спросили - начался развод на деньги. Не знаешь - не говори.

девочки не ссорьтесь

(180) Я разве уверенно говорил про сроки и стоимость?! ГДЕ?

Не надо мне приписывать свои глупые домыслы. Я как раз таки и сказал - дай мне ресурсы и я тебе назову сроки и окончательную стоимость проекта. Это ТЕБЕ интересен данный вопрос, это ТЫ мне его задаешь, а я могу ответить на него, потратив свое время и твои деньги.

+(182) Звонит заказчик, говорит "сделай мне збс". Что именно входит в "збс" - я должен узнать сам. Забесплатно. Охренеть теперь.

все хорошо , когда тебе поставили задачу (как смогли) - после приемки, - все хорошо, да, НО ... и тут что все не так и имелось ввиду и подразумевалось + а в ескеле добавляем колонку и вот - а вы нифига три дня тут делаете свой отчет (с)

(182) В (101) ты говорил что это возможно. Так можно сказать только зная сроки и смету, иначе это просто фантазии. Поэтому если это не фантазии - то сроки и смету ты уже делал, так что можешь сказать.

(185) Возможно построить небоскреб. Это означает, что я знаю сроки постройки и смету?

(183) Если ты говоришь "Да без проблем!", то сроки и цену должен назвать тут же.

(187) На (186) ответь.

(174) По-разному бывает.
У меня в трудовом договоре оклад 5000 руб.

(187) Отличный подход к проектам, что я могу сказать. Тебя спросят: "Можно ли автоматизировать наш учет?" - ты что ответишь, не зная ни условий учета, ни кухни заказчика, ни его специфики - вообще ничего, кроме того, что любой учет можно автоматизировать, были бы ресурсы.

(125) Про прозрачность и доверие очень понравилось.

(186) Во-первых, небоскребы уже строились, так что возможность их создания доказана на практике. Во-вторых, узнать цену и сроки по уже построенным небоскребам больших проблем нет. В-третьих, откуда ты знаешь что за небоскреб хочет заказчик? Может на 2000 этажей, чтобы выстаивал при землетрясении в 12 баллов и на верхний этаж за 20 секунд подниматься. А ты тут ему смело "Да не вопрос! Платите деньги - все посчитаю!"

(189) И зарплата на уровне рынка?

(183) конечно.

ты ему называешь срок, стоимость.
Василий называет ему срок, стоимость.
Маша называет ему срок, стоимость

я он уже решает кто ему будет делать.

(190) В (101) ты именно это и сделал.

(195) Так что ты ответишь на вопрос: "Можно ли автоматизировать наш учет?" - в такой ситуации?

(186) те, кто строил-проектировал назовут тебе сроки,стоимость, параметры с точность, достаточной для принятия решения.

(194) обратите внимание, что слово "качество" не прозвучало ни разу

(196) Я не буду отвечать как ты в (101), рассуждая о сферических конях в вакууме. А буду обсуждать конкретный учет.

(198) это как-бы подразумевается.

(194)  Это когда есть грамотное ТЗ с четкими требованиями. В 90% случаев у заказчика каша в голове, бардак в базах, а на их ТЗ без слёз не взглянешь.

вопрос качества - головная боль заказчика.

(192) Да гамновопрос, гг. В такой проект будет заложено 50 лет и несколько сот миллиардов долларов только на разработку новых материалов, подходящий под данные условия.

Вот про проект, в котором законы физики нарушаются, я отвечу по-другому. А если задача стоит сугубо инженерная - она реализуема. Точка. Какой ценой - это уже ВТОРОЙ вопрос.

Я давно уже понял что бесполезно конкурировать по цене, нужно делать свой бренд.

(201) предварительная оценка - бесплатно.

рабочее ТЗ - за деньги.

(130) При таких проектах предпроектный анализ и оценка занимают месяцы и годы, и бюджет на них выделяется в миллионах (миллиардах) долларов. Или ты тумаешь Главный Прораб почесал затылок 5 минут и сказал: 7 месяцев и 5 дней за 1700 млн. долларов?

(197) Не назовут. Где-то проскакивала инфа, что превышение сметы на постройку "Бурдж-Халифа" (который самый высокий щаз) составило еще больше двух стоимостей сметы. По срокам, впрочем, уложились.

(203) Вот это и есть развод. Грамотный же специалист скажет, что на текущем уровне технического развития данный проект нереализуем в разумные сроки и цену и требуются фундаментальные исследования.

(206) Вот, блин, о чем я и говорю.

(206) я про общий срок проекта.

(205) Не бесплатно - она неявно включается в стоимость выполненных работ.

(205)ты ж только что говорил что вписываются на основании предварительных оценок, то бишь с цифр с потолка

(0) начал разбор текста со 2-ой действительно стандартной строки:
"В бухгалтерии не проводится документ, не знаю какой, сколько времени вам нужно чтобы решить проблему?" - отвечаю, если конфигурация на поддержке максимально - 30 минут.

(208) А как, ты думаешь, реализуются мега-проекты? Кто-то принимает решение что-то сделать. Идет к специалисту. Говорит кратко: "Я хочу построить самый высокий небоскреб в мире. Это возможно?". Специалист отвечает: "Да". Затем специалисту дают кучу бабла, и он начинает считать и проектировать.

(211) Щаз, ага. В твоих условиях прозвучало: "Ты сначала посчитай, а я решу, платить тебе или нет". Вот это и есть развод.

(211) в общем то да, если клиент слепошарый :)
(212) эээ ? я о сборе общих ожиданиях заказчика.

+(214) Хочу заметить - кучу бабла дают только на подсчет и проектирование, но никак не на саму постройку. Смету специалист озвучивает потом, когда посчитает и рассчитает.

(216) подсчет и проектрование - имеет стоимость и срок.

это ровно такая же часть проекта как и составление ТЗ для одинеснеков.

(217) Именно. Это я и затребовал в ответ на вопрос в (114). dmpl же мне ответил - ты сначала посчитай, а я подумаю потом, заплатить мне или нет.

(214) И опять возвращаемся к (101). На рассказано про то, что еще нигде и никогда не реализовывалось. Так что аналогия не катит. И, опять же, для подъема за 20 секунд на 2000-й этаж потребуется ускорение выше 6G, что 99% людей просто не выдержат. Т.о., для подъема требуется телепортация. Ты, как специалист, должен это понимать, поэтому ответ "Давайте бабло, а там или ишак умрет, или падишах" - чистый развод.

(217) а как определить стоимость и сроки подсчёта стоимости и сроков?

(215) Оно всегда сидит, как минимум в цене часа у тех же франчей.

(210) "Общий срок" проекта назовут только после проведенного предроектного исследования. Хотя бы первичного, чтобы понять, возможно ли реализовать в принципе, и примерный ПОРЯДОК сумм и сроков.

(219) Ты вот прямо так уверенно обещал сделать то, что не факт что реализуемо - так что я попросил сроки и цену, ведь если ты решил, что это реализуемо - ТЫ УЖЕ ВСЕ РАБОТЫ ПРОВЕЛ за чей-то счет.

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

Что непонятного-то?

(219) если не ларек, то желающих сделать - вагон и маленькая тележечка.

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

потом с победителем идет более плотная работа.

платить первому попавшемуся сколько попросил кмк не стоит.

(221) в строительстве есть вполне работающие методики.

с одинеснеками только в рамках договоренностей.

(226) "потом с победителем", победитель обязательно должен был быть в костюме от гучи, с голливудской улыбкой и приезжал на Каене.

(225) Докажи что реализуема. В частности, как твоя система учтет откаты и взятки? Где ты возьмешь эту статистику?

(228) не обязательно, кстате ;)

(226) Эт тендер. Ессно, команда, которая имеет ресурсы для предпроектного исследования за свой счет, вкладывается с риском, когда берется за это исследование по условиям тендера. Я понимаю, что dmpl - не заказчик, и ни гроша мне не заплатит ни сейчас, ни потом. Поэтому тратить собственное время и, возможно, деньги ради праздного любопытства - смысла нет. Но ему, видишь ли, надо для доказательства предоставить подробную смету, описание механизма учета взяток и откатов и т.д.

(229) "учтет откаты и взятки" - это куш называется, майдан - это тоже куш по сути.
(230) без портфолио все равно никак.

(225) Я возьмусь что-то доказывать, считать и описывать только после подтверждения твоей платежеспособности. ОК?

(232) ту да, согласен, про исполнителя нужно иметь инфу.

"откаты и взятки, платежеспособности, Сначала я бью клавиатурой по башке, 50 раз,", а может сначала перед началом исследования уяснить себе что вы участвуете в работе с ФРС или нет? если с ФРС то тут все понятно, а если за идею то тут могут быть нюансы.

(234) Да и о заказчике бы неплохо, гг. Вы возьметесь за серьезную задачу, если ее попросил Уася из соседнего подъезда, внесший предоплатой бутылку пива? :)

(231) Ты высказал утверждение - тебе же его и доказывать. За свой счет. Не хочешь доказывать - надо высказывать мнение, а не утверждение.

(237) На нет и суда нет. "На слабо" не поведусь.

(237) Если ты утверждаешь, что экспертных систем не существует - ОК, я тебе что-то доказывать не намерен тем более.

(239) а как же на счет, растет заказчик растете и Вы, разве что-то с тех пор поменялось?

(239) По автоматизации шаурмячных? Нет, не существует.

(241) Существует ли игра, в которой нужно складывать здания не из кубиков, а из пирамидок? Нет, не существует. Можно ли ее создать? Да, можно. Еще вопросы?

(240) Это если заказчик один и альтернатив нет.

(242) Аналогия кривая. Как ты докажешь, что шаурмячная - это пирамидка, а не шарик?

(239) какая к лешему экспертная система по шаурмячным ?

Гиви тебе распедалит лучше любого эксперта.

(244) Ой, бня...

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

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

Дальше будем говорить про небоскреб в 2000 этажей?

(0) Какая печальная история..

(246) лажа это все

(245) Кстати, обычно все так и есть. Потому что чтобы система заработала - нужен порядок, а вот с ним-то как раз проблемы. И никакая система не заставит человека не косячить. Потому что это человек - он и не хочет, а косячит. Только полная автоматизация решит проблему - но это только когда наступит коммунизм.

(246) См. (245). Эта система работать не будет ввиду саботирования на местах.

(249) Т.е. ты утверждаешь теперь, что эта система работать не будет? Ты уже работал с такой системой?

Сам себе противоречишь через комментарий. Не надоело?

(249) все эти "экспертные системы" созданы дабы подогнать решение под ответ ;)

данный челом с опытом и решение он принимает 20% инфа, 80% интуиция.

(250) Покажи работающую систему - поговорим. А так - банально наш южный друг из шаурмячной насилует ребенка в районе - и бизнес вылетает в трубу. В буквальном смысле - сгорает.

(250) "система работать не будет"

что ты считаешь результатом работы этой системы ?

(252) ну или участковый новый пришел

(253) Успешно работающий бизнес. Иначе нахрена эта система нужна?

(251) Угу, "а давайте-ка интуитивно рассчитаем маршруты доставки и загрузку 50 "Газелей", которым надо проехать три сотни торговых точек за день". Здорово-то как. Зачем мы компьютеры изобретали?

(256) это обычная задача по графам.

(252) Т.е. ты заранее отбрасываешь саму возможность существования положительного результата?

Не, спасибо, я так не играю. И не дай б-г мне в подчиненные РП с таким же настроем - завалит все, что можно, одними своими унылыми "ну не получится это", "не, невозможно".

и кстате, владельцы овощных палаток с этой задачей отлично справляются.

максимум что у них есть - тетрадочка :)

(257) Т.е. человек способен без расчетов на 80% верно решить эту задачу одной лишь интуицией?

(256) Эти задачи нерешаемы точными методами ввиду геометрического возрастания сложности при увеличении количества рейсов. Возможно получение лишь приближенного решения.

(260) решают же, см. пример выше.

(258) Либо система дает гарантированный результат, либо она не работает.

(252) то тебе бизнес жалко чи ребёнка?

(260) и тут не требуется верного решения.

досточно устраивающего лично владельца ;)


т.е. меня устраивает, что 50 газелей ездят по 300 км. в день по 300 точкам и расходуют в мес. 100500 денег, чем я потрачу на "экспертную системе" 100500 денег и в итоге
те же самые газели будут ездить по 280 км. и будут расходовать на 10% меньше. может быть.

%% с депозита на бюджет внедрения покроют эффект от внедрения.

(263) ну  разработчик с баблом же, а это результат :))

(266) да и наличие негативного опыта это тоже результат для будущего результата

(266) Ну дык а с чего все началось? Что во де в будущем программистов заменят автоматизированные системы. Ну и кто будет с баблом-то при таком раскладе? Такое только при коммунизме будет, когда каждому по потребностям, от каждого по способностям.

(268) ответ: тот кто их печатает.

Как-то был на собеседовании в одной из сети СПб аптек. Разговаривал с начИТ. На профессиональные темы не было задано ни одного вопроса. Но в финале начИТ спросил:
- Вам поставленна задача сделать работу за 5 рабочих дней. Но вы не укладываетесь, вам надо 6 дней. Ваши действия?
- Ну если это произошло - честно говорю с работодателем о возникшей проблеме. Объясняю причины и стараюсь найти взаимоприемлемое решение.
- Ответ не верный!
- ???
- Вы дожны были с самого начала работать не по 8 часов в день, а по 10, тогда через 4 дня вы бы выполнили работу, и у вас был бы еще один день в запасе, таким образом вы в данной ситуации не сорвали бы сроки.
=Занавес=
ЗЫ. От приглашения на следующее собеседование я отказался.

(269) Дык украдут забесплатно.

(256) >>Угу, "а давайте-ка интуитивно рассчитаем маршруты доставки и загрузку 50 "Газелей"

Реальная история. На заводе поставили программу оптимизации маршрутов. Забили в эту программу все точки с привязкой к карте, весь автотранспорт и т.д. Далее провели испытание - загрузили в программу реальные заказы (несколько тысяч в день). Программа чуток пожужжала и раскидала заказы по маршрутам. Руководство поначалу было в восторге, однако вскоре выяснилось, что на каждый день составляются разные маршруты, что в общем-то логично - программа пытается оптимизировать. Но! Оказалось, что водителям жутко неудобно каждый раз ездить по новым маршрутам. В общем все свелось к фиксированным маршрутам, которые были и раньше.

(270) задача либо интересна либо глаза в пол
(271) нужно понять что это цикл до майдана или после

(270) не вопрос, а переработки они оплачивают?

(0) Сроки.... сроки... можно ведь  работодателю и договор заключить с франчайзи. Но.... тогда придется платить и на выходе ничего сделано не будет тоже . Это все понимают.

Золотая середина с сроками ... максимально упрощать решения и не программировать ради программирования.

Привыкли запросы на  на 10 страниц текста (выдавая это за достижение)... а потом людям  год в них ковырятся

(272) Интересно, водители говорят нам пох на сокращение издержек, бизнес ну ладно пусть 100-200км лишних в день наматывают

(278) Патамушта водитель  сегодня здесь - завтра там. Текучка среди  водителей не есть гуд. Как вариант.

(278) зачастую затраты на мероприятия по сокращение издержек многократно превышают эти самые издержки за большой промежуток времени :)

(279) + экспедитору проще самому решить куда ему удобнее сначала ехать.

на одной точке нет никого, на другую пробка, в третьей ждут но попозже.

(278) не надо мыслить так категорично. если водитель каждый день будет ездить по незнакомому маршруту, то потери могут быть еще больше. Лишних 200 км это, предположим, 40 литров топлива или 1200 рублей. новый маршрут грозит:
1)опозданиями, в следствие чего торговая точка может отказаться от заказа;
2)штрафы, вытекающие из пункта 1 (особенно сети любят прописывать жесткие условия по времени доставки)
3)пробки, т.е. непродуктивный расход топлива
4)водитель может наматывать круги по району в поисках торговой точки, т.к. попросту не знает, как к ней проехать, т.е. тоже потери топлива
5)возможно что-то еще...

(282) "лишних" 200 км по городу практически нереально за день намотать.

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

(274) Зачем? Если ты перерабатываешь, значит, ты плохой специалист, и платить тебе надо вообще меньше ;-)

(284) Нет смысла планировать без учета пробок, иначе это не планирование. В планировании закладываю среднестатистическую загруженность + вероятность аварии

(277) Праааально! Надо тупо запросы в цикле е*ашить и обращаться через точку в цикле к его результатам. У нас тут сроки! Не до вашего программирования.

(287) нефиг программировать ради программирования, если мы решили задачу в срок и закачика устроили то это нормальное решение. Пофиг что он выполнять работу будте в 3 раза дольше.

(288) Угу, и через полгода такого активного "программирования" база превращается в глючное, тормозное месиво. Документы проводятся по 10 минут, отчеты формируются по полчаса, обработки и обмену идут по часу. В итоге производительность отделов, связанных с работой в базе падает раз в 5. Зато все успели в срок :)

(289) зато потом сколько пространства за переделать!

(289) Всегда говорю начальнику есть быстрый способ и правильный. Причем как правило правильный в 2 раза дольше. Но он быстро окупается на поддрежке. Если надо продать 1 раз и забыть первый путь оптимальный.

(0) Я как правило смотрю задачу: либо на месте решаю, либо реально оцениваю сроки. Если проблема серьезная то сразу говорю, что за 1 день ее не решить. Готовы ждать?

(290) Когда переделывать? Мы тут вообще-то в сроки укладываться должны, на остальное времени нет :)

(285) В наших реалиях не работает - ты фактически совмещаешь несколько джолжностей. Так что высер - бред болезненный; или начитался дятлов забугорных всяческих, или, что хуже, взял шаблон ашэров просто на веру.

(294) Оу, нужна была таблица "Сарказм"?

(272) это Антор? Есть интерес к подобной проге

(0)Проблема со сроками только у качественных франчей - таких как известно почти нет, так что проблемы такой практически нет.

(286) Интересно откуда вероятность аварии на маршруте берется? А таки наличие пробки от наличия аварии сильно зависит.

(298) рисуем сферического коня и по нему планируем :)

(300)

(285) черт, не подумал :)

(296) Ага, Антор.

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

Вспомнилось у Ремарка в одной из книг ("Три товарища"?).
Пришёл к художнику один небольшой бизнесмен, у которого жена в аварии разбилась. И заказал ему портрет жены. Художник сказал, что сделает через 3 недели.
К нему пришёл знакомый, который был одним из героев романа. И спросил, неужели все три недели тот станет делать картину. Тот рассмеялся и ответил, что пишет такие картины за неделю, а срок 3 недели называет с тем, чтобы заказчики не пытались вычислить "часовую тарифную ставку". То есть чтобы не жмотились.

(0) Вам нужно устраиваться в компанию работающую преимущественно с бюджетными организациями. Там с невыполнением сроков в целом проще, но, естественно не без частностей.

(0) На прошлой работе тоже штрафами чуть весь штат не разогнали, вовремя спохватились

(0)я иногда применяю метод декомпозиции, разбивая задачи на более мелкие, как то создать справочник, разработать макет отчета, написать модуль проведения и т.д. Оценивая свой опыт в написании подобных подзадач, провожу оценку времени, накидывая хК (в часах), где К - зависит от типа задачи (к чему х2 для добавления реквизитов в документ и, отнюдь х3 для написания отчета) Сложив полученное время получаем итоговые сроки. Плюс обязательно оговариваю с заказчиком, что в процессе внедрения возможны подводные камни, когда , к примеру, заказчик сам захочет внести изменения в начальное ТЗ (так ведь бывает!), что повлечет изменение сроков. Вот тут момент, несомненно, в пользу разработчика, т.к. заранее предугадать, какие будут "хотелки" у заказчика невозможно, поэтому и срок получается размытым. P.S.а вообще сроки нужны. Пример:"Собрание состоится в 18.00. Большая часть придет к 18.30 - 19.00. И все будет в норме. А не напиши начало собрания - никто вообще не придет!"