Задать вопрос
zenden2k
@zenden2k
PHP & C++ programmer

Можно ли работать программистом, но не оценивать сроки?

Я наверно неплохой программист, но меня раздражает, когда меня спрашивают про сроки.
Во-первых, мне очень тяжело оценить. Вопрос про сроки заставляет мой мозг зависнуть или уйти в бесконечную рекурсию. Мой мозг тратит на него больше ресурсов, чем собственно на саму разработку.
Во-вторых, это психологически тяжело для меня, боюсь назвать слишком маленький срок, не уложиться в сроки и меня уволят. Ну или по головке не погладят. Боюсь назвать слишком большой срок, потому что получится слишком дорого и заказчик откажется. А другие подумают что я такой вот тормоз.
Вообще у меня слабая нервная система.
В итоге я пишу код и все время боюсь, что не успею.
Хочу программировать и ни о чем не думать.
Вот пишу свой опенсурс проект, там благодать - ничё оценивать не надо, сам придумываешь, сам реализуешь, никто над душой не стоит. Но этим не заработаешь.
Как быть?
  • Вопрос задан
  • 5467 просмотров
Подписаться 25 Оценить 2 комментария
Пригласить эксперта
Ответы на вопрос 17
trevoga_su
@trevoga_su
1. НЕ ВЕЗДЕ сроки имеют место быть. Ищите работу где сроки не требуются. Таких мест полно. Это как правило долгоиграющие проекты принадлежащие бизнесу, а не говеные веб-студии, штампующие на заказ.

2. Сроки можно озвучивать, если вы пишите что-то, что вам понятно, задача прозрачна или типична. Есть задачи, когда о сроках не может быть и речи - например, поддержка/разбор чужого кода кода. На таких задачах сроках быть в принципе не может.

3. Приехал я как-то с поломкой машины к мастеру-частнику. Говорю - вот то то не работает. Сроки? А он мне отвечает - а я не могу сказать. Откуда я знаю что там сломалось?
Это я к тому, что даже такая в такой теме, как ремонт авто, где казалось бы все четко и все делается по наработанной схеме, сроки крайне не определены.

4. Если с вас требуют сроки, значит вы что-то делаете не так или работаете где-то не там. Про сроки можно говорит в строительстве, где укладка одной плитки СТАНДАРТНО занимает Н минут и вы должны полы покрыть 30х40 метров. Тогда сроки справедливы. В IT сроков не может быть. Т.е. не должен исполнитель думать о сроках. Это не его дело. Менеджмент должен дать время с запасом и не терзать исполнителя.
Ответ написан
@djay
Самое главное в этой индустрии - это не качество кода, а сроки. Вся индустрия держится на сроках. И нет, такого работодателя, который будет давать много времени на реализацию фичи. Любой работодатель заинтересован в извлечении максимальной прибыли при минимальном вложении (т.е экономии бюджета на разработке).

Тебе придётся научится с этим работать и жить. Иначе никак. Это главный навык.

С другой стороны, оценивать время которое ты затратишь на реализацию не так уж сложно:

1. Когда спросят "сколько понадобится времени" - всегда отвечай - дайте минут 10-20 на оценку, я не могу взвесить не подсчитав.

2. Разбей задачу которую тебе дали на под-задачи. Обычно получается - обрабока/создание какой-либой формы, добавить небольшой подсчёт и аналогичное. То есть по сути, одна задача в своём подавляющем большинстве состоих из мелких под-задач.

3. Приувеличь сроки на ~50% (+/- 20%). Например на создание CRUD формы уйдет не больше 30 минут, а ты называй час. И остальные подзадачи в этом духе. В итоге, даже если просчитался где-то у тебя есть страховка.
Ответ написан
pletinsky
@pletinsky
Ваша проблема довольно типична на самом деле :) Это не какие то индивидуальные особенности, просто многие боятся самому себе в этом признаться.

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

Это делается потому, что в разработке время большинства задач очень трудно оценить адекватно. Большая часть оценок - это просто цифры с неба. Плюс ко всему реальное время обычно "стремится" к запланированному. То есть если вы делаете работу быстрее, вы будете растягивать ее, чтобы не сделать раньше срока, чтобы люди не думал, что вы даете намеренно завышенные оценки. Если же не успеваете - то будете работать как папакарло по выходным, гробя свое здоровье и качество продукта, который вы разрабатываете.

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

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

Что посоветовать - вопрос непростой. Ну, работать в серьезных проектах конечно, с профессиональными людьми. Там таких проблем поменьше.
Ну и конечно учиться оценивать. Ведь ваши беспокойства вызваны неопределенностью. Вы просто не знаете как сказать правильную цифру. Конечно на самом деле никто не знает, некоторые лишь пытаются убедить себя, что знают. Однако вы можете приблизиться к реальности.

  • Ведите статистику по тому, сколько времени занимают сделанные вами задачи, или используйте существующую.
  • Разбивайте задачи на подзадачи и оценивайте их отдельно, а потом складывайте результат.
  • Сравнивайте задачи с теми, что вы уже делали.


Системный подход решает многое.
Ну и конечно классический финт ушами: закладывание рисков. Просто учтите риски, добавив время, проявив храбрость, чтобы сказать большую цифру. И если на самом деле сделаете быстрее, считайте, что учтенные вами риски попросту не случились. Это вашему руководителю будет очень понятно.
Ответ написан
Комментировать
Jump
@Jump
Системный администратор со стажем.
Программировать - можно.
Работать программистом - нет.
Ответ написан
Берите задачи где сроки не критичны, я например всё заказываю заранее или какие ни будь второстепенные вещи и мне вообще пофигу сколько будет делать человек.

Назовите заранее срок в 2 раза больше, да часть клиентов потеряете, зато с теми кто останется будете абсолютно спокойно работать в комфортном для себя режиме.
Ответ написан
@serega_kaktus
Программист-самоучка, фрилансер
Оценка времени на задачу - вполне распространенная процедура, и не только в IT. Так что лучше научиться это делать, так как чаще всего оценка требуется.
Если у вас есть несколько лет программирования, то вы способны спланировать работу над задачей от и до, разбив на более мелкие. Оцените каждую мелкую задачу и сложите. Опять же, чаще всего бывает, что задача в том или ином виде вам встречалась, может какие-то ее части встречались, основывайтесь на них. И всегда берите запас +-10-20%. Если технология не знакома, то оцените эту же задачу в рамках знакомой технологии и умножьте на 2 - чтобы учесть время на изучение технологии. Если какие-то этапы непонятны, неизвестны, то их оговорите отдельно.
Ответ написан
zoonman
@zoonman
⋆⋆⋆⋆⋆
Есть проект, называется Fogbugz
www.fogcreek.com/fogbugz
В нем можно ставить задачи и указывать время их исполнения. Он собирает информацию и потом может выдавать предсказание о времени выполнения задачи.
По опыту могу вам посоветовать, если вам кажется, что задача займет пару часов, а заказчику скажите 4 или 6. В систему вводите свое собственное время. Через пару месяцев у вас появится некоторая картина вашей скорости.
На мой взгляд лучше срок немного увеличить, чем сделать не вовремя. Вообще это приходит с опытом, но все равно очень сложно оценивать время выполнения. Лично я стараюсь узнать о задаче максимум до начала ее выполнения или представления оценки заказчику.
Что еще можно сказать - не переживайте сильно по поводу оценки времени. Все ошибаются, даже специалисты с 10-20 летним стажем.
Есть еще немного другой подход - непрерывная разработка, в которой нужно ставить оценки времени, но необязательно их соблюдать. Т.е. оценку разработчик делает сам для себя. Что-то вроде личного мотиватора, не более того.
Ответ написан
Зависит от компании и от того, как там все устроено. По опыту могу сказать, такие есть. Иногда будут спрашивать как дела на текущем этапе и сколько примерно осталось, и все. Только тут главное не наглеть, чтоб не создалось впечатление, что можно было сделать быстрее. Ищите небольшие компании с неформальной обстановкой в коллективе

P.S.
слабая нервная система

Рекомендую Новопассит.
Ответ написан
Комментировать
@denikeweb
Freelancer, creative developer
https://events.yandex.ru/lib/talks/2235/ - я советую Вам посмотреть это видео. Суть его в том, что нужно сроки до 2 недель умножать на 2 или на 3, а от месяца - на 1.7 и добавлять 2 недели.

Я прошу не принимать мой ответ в штыки, так как не имею представления о Вашем опыте. Ниже опишу свое мнение по поводу программирования и оценки сроков.

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

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

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

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

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

Но все таки ставить сроки для программиста - первостепенная задача, потому что профессия не ограничивается написанием кода. Таковы реалии бизнеса. Надеюсь, что немного помог в Вашей проблеме
Ответ написан
sim3x
@sim3x
Можно ли работать программистом, но не оценивать сроки?
нет
Хочу программировать и ни о чем не думать.
для такого нужно стать суперспецом в узкой области и делать за время еквивалентное времени, затраченному на переговоры по срокам.
Ответ написан
Комментировать
donkaban
@donkaban
Умею рисовать тени
Программистов, способных оценить сроки - миллионы. Чтобы иметь тонкую нервную организацию надо доказывать свою состоятельность. Покажете гитхаб?
Ответ написан
@proxaoc
веб-разработчик, специалист по 1С-Битрикс
Никогда не понимал разработчиков, которые, хотя бы примерно, не могут обозначить сроки и оценку.

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

Не можешь в часах оценить - оценивай в днях, не можешь в днях - оценивай в неделях.

Причем сроки и оценка - это разные вещи, чтоб все понимали. Могу оценить задачу в 8 часов, но покажу только через неделю. Это нормально.

Если сразу не понятно как оценить - договаривайся об оплачиваемой диагностике. В той же автомастерской или конторе по починке компов так и поступают и ничего страшного.
Ответ написан
Комментировать
thestump
@thestump
программист PHP
Работал в одной конторе и там платили столько денег за задачу сколько времени на нее потрачено совершенно не думая про сроки дедлайна. Конечно нельзя было неделю заниматься плевой задачей, но времени чтобы не костылить, а выйти на верное и правильное решение было предостаточно. Т.е. день-два над одной задачей можно было просидеть при прочих равных.

Но в любом случае дедлайны имеют место быть потому что человек заказывающий ПО как правило ничего не смыслит в программировании, но он хочет ожидать когда будет предоставлен продукт.
На бытовом примере можно объяснить так: вы покупаете холодильник в магазине с доставкой и не оставите же вы холдильник в магазине сказав - да, на доставку надо время так что привизите его как будете готовы, вместо простого вопроса: в течении какого времени будет осуществленна доставка?!
Ответ написан
Комментировать
@tugo
Тренируйтесь оценивать для себя в спокойном режиме. Выделили задачу, записали на бумажку оцененное время задачи, сделали задачу, сравнили.
Навык оценки времени нарабатывается.
Ответ написан
Комментировать
rasswet
@rasswet
фиксируйте сроки каких-то работ по факту. сделайте для себя какую-то таблицу, сколько занимает каждый вид работ. исходя из неё сможете примерно оценивать. +/- 25% для работ на 1-3 дня можно оценить. кроме того можно оценивить "вилкой", например такая-то работа 7-10 часов. где 7мь это оптимистичный сценарий.
Ответ написан
Комментировать
@balamyt92
; select * from users; --
Для оценки сроков требуется срок от одного дня до месяца (в зависимости от размеров запросов). При этом оценка сроков должна быть оплачена если превышает срок в 3 дня.
Ответ написан
@huhrmuhr
Читай:
Брукс. "Мифический человеко-месяц". Опыт создания операционной системы.
Это еще лет 50 назад вызывало проблему ))))
Основной вывод, который я вынес из этой книги - собственную оценку сроков нужно умножать на 2, а лучше на 3, прежде чем озвучивать заказчику.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы