Пропускаются ли сроки выполнения заданий по программированию? [закрыто]

18

Это была моя работа фрилансера в oDesk. Я выполнил несколько заданий ранее в данное время, но это был первый раз, когда я пропустил срок. Это была очень долгая работа, и я старался изо всех сил, но я все еще не уложился в срок. Теперь я очень напуган. Потому что это моя вина, что я пропустил срок.

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


источник
1
Полностью зависит от окружающей среды. Например, моя последняя работа была в цифровом агентстве, которое заряжало клиентов на основе оценок. Если вы пропустили крайний срок, бизнес потерял деньги. Моя текущая работа настолько динамична, что нет никаких реальных сроков вообще ... если мое внимание требуется в другом месте, мне дают соответствующее время, чтобы посвятить этому. Возможно, включение этого в ваш вопрос поможет с ответами.
Саймон Уайтхед
3
пропущенные сроки являются общими для всех рабочих мест
Стивен А. Лоу
2
Я действительно надеюсь, что вы общались с клиентом по поводу пропущенного срока. Пропускаются крайние сроки, но это не должно быть неожиданным, когда это происходит - вы должны быть в состоянии увидеть его и сообщить об этом. Обычно это проще, чем просто сказать «Нет, еще не готов».
Бобсон
6
Делай это быстро, делай это дешево, делай это хорошо: выбирай два.
Reactgular

Ответы:

45

Да. Пропущенные сроки являются общими в разработке программного обеспечения.

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

Перефразируя Фридриха Брукса « Мифический человеко-месяц» :

Фредерик Брукс, автор книги «Мистический месяц человека»

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

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

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

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

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

  • Большинство программных продуктов - не что иное, как программные проекты, которые были сокращены из-за подобных проблем.

В заключение:

Плохие оценки и недооценка сложности из-за ремесленного характера процесса разработки программного обеспечения означают, что он остается незрелой дисциплиной.

Тулаинс Кордова
источник
11
+ Хороший ответ, но будучи знакомым с механическим и гражданским строительством, забавно, как программисты легко сравнивают строительство мостов и другие вещи, когда они не имеют ни малейшего представления, как они строятся.
Майк Данлавей
3
Я бы согласился с идеей, что программное обеспечение является планом (с точки зрения плана в разработке - описание каждой детали проекта). В случае проектирования время физического строительства преобладает, поэтому большая разница в планировании не играет роли. Однако поскольку программное обеспечение состоит только из плана ... «Уровень техники в разработке программного обеспечения еще не достиг того уровня, когда программные проекты повторяются и практически не подвержены риску», - в таких случаях зачем вообще проект? Если что-то повторяется и может быть автоматизировано, то это не нужно делать много раз, но можно сделать один раз и скопировать.
Мацей Пехотка
2
@ user61852: Вы меня не так поняли. «План» для разработки является «источником» для информатики, то есть для подробного описания каждого компонента, но как только мы его получим, мы можем его построить (ввести makeили что-то еще). Что такое «план» в информатике, будет «планом» плана »в технике. Разница в том, что makeв информатике это занимает не более нескольких часов, в то время как на написание исходного кода (включая тесты и интеграцию) уходят месяцы, тогда как в инженерном планировании может потребоваться месяцы (включая структурные вычисления), а на сборку - годы. Так что отклонения от планирования оказывают меньшее влияние на последнем.
Мацей Пехотка
1
@ user61852: Относительно повторяемости - одна вещь, в которой компьютеры хороши - это автоматизация. Скажем, вам нужно создать простой блог - в тот момент, когда у вас будут точные «оценки», вы получите WordPress (или любую другую систему блогов), поэтому вам не нужно ничего делать (в случае бриджа) у вас все еще другая среда, поэтому вам нужно более тщательно адаптироваться, так как камень может отличаться или может быть среда обитания птицы или это может разрушить вид) - программисты могут быть более ответственными за создание инструментов (стандартная модель моста).
Мацей Пехотка
2
Бонус за цитирование Мифического Месяца Человека; Фредерик Брукс выдерживает все эти годы, потому что он сосредоточен на людях, а не на технологиях.
Михаил Шопсин
3

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

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

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

TJ Trapp
источник
2
Я всегда даю 20% места при оценке. 5-10% это слишком мало. Я думаю, это зависит от того, насколько вы отвлечены. Индивидуальный разработчик может вообще не отвлекаться
BЈовић
Я сольный разработчик, и я обычно беру 10% маржи за свои проекты.
Консоль
Хммм ... см. Закон Хофштадтера
Филипп
1
По сравнению с 5-20%, я думаю, что 100% маржа лучше. Шутки в сторону. Это позволяет вам изучить ваши варианты гораздо лучше. И ответьте на дополнительные вопросы по Stack Exchange.
Acumenus
О да, это ошибка разработчика, когда 15-летний менеджер проекта давит на 1,5-летнего новичка-разработчика программного обеспечения, чтобы он дал ему оценку, затем настраивает ее на еще более агрессивный характер и ведет себя так, как будто разработчик ослабевает, когда проект закрывается. , Я никогда не работал на менеджера или руководителя, который вообще мог бы писать программное обеспечение, и вы говорите, что пропущенные сроки не должны стать обычной практикой, если вы хотите продолжать получать работу? Пропущенные сроки являются эндемичными, потому что большинство руководителей в буквальном смысле некомпетентны в своей работе. Мой лучший менеджер все еще не был инженером-программистом, просто знал свои пределы.
пессимистический
3

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

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

Philipp
источник
2

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

Удивительная вещь в скорости заключается в том, что она включает в себя все нематериальные вещи, такие как прерывания и неожиданные сложности, которые разработчики с трудом учитывают в своих оценках. Все вероятности усредняются с течением времени. В среднем за 10 недель наши оценки скорости были точными в пределах 5%. Тем не менее, когда мы оцениваем одни и те же задачи в часах, одна и та же команда постоянно недооценивает на 30-50%.

Карл Билефельдт
источник
1

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

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

Если кто-то переделал кухню, они обычно думают: «Ну, я сделаю это через две недели». Они заканчивают это около шести недель спустя.

Мередит Бедный
источник
1
Какое отношение НАСА имеет к моему вопросу?
1
Если говорить более конкретно, какое отношение имеет человеческая эволюция к вашему вопросу? НАСА является четко задокументированным примером в публичных отчетах обученных и опытных людей, недооценивающих большие проекты. Короче говоря, ваш опыт «естественен».
Мередит Бедный
Хотя я согласен, что оценки большинства людей по крайней мере вдвое, но в следующую единицу времени ... ммм. В любом случае, НАСА очень хорошо оценивает задачи, которые они уже умеют делать. Проблема в том, что люди не очень хорошо оценивают задачи, когда не знают, чего не знают. Поскольку НАСА выполняет много действительно новаторских работ, неудивительно, что они мало знают о том, что они делают, пока не начнут это делать. Таким образом, причина первоначальной недооценки. Кроме того, некоторые люди предрасположены быть оптимистичными, а другие - пессимистичными. Не уверен, что эволюция вовлечена.
Данк