Почему сроки всегда так коротки? [Дубликат]

    

У этого вопроса уже есть ответ:

    

Я младший разработчик в небольшой компании (в команде из 2 разработчиков). Каждый раз, когда нас просят внедрить новую функцию:

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

  • нас просят начать разработку до того, как функции будут полностью указаны, поэтому новые вещи, которые нужно показать, но срок остается

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

Был один релиз, который я очень хорошо помню. Когда мы сделали демонстрацию боссу, он сказал нам: «Что?» Вы взяли две недели, чтобы произвести это ?! и все, что мы могли ответить, было «Нет, на самом деле это заняло у нас три недели». У меня была встреча с ним и еще одним младшим разработчиком (который покинул компанию из-за этой встречи!), И он в основном сказал нам, что он не был доволен, потому что то, что мы выпустили, было дерьмом.

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

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

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

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

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

Почему так? Это не кажется таким трудным для понимания, что если мне нужно x дней для выполнения задачи, я не могу сделать это за x /2 дня, даже если вы скажете «пожалуйста» и спросите с улыбкой. Это кажется настолько очевидным, что крайний срок будет упущен и /или что требования к качеству не будут выполнены.

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

31 голос | спросил Mathieu 7 AM000000100000002331 2014, 10:12:23

9 ответов


31

На самом деле два варианта: выйти или создать основу.

Я думаю, что мне не нужно много объяснять об уходе. Это очевидно. Если вы не можете ни принять это, ни осмелиться изменить его, это единственный способ продвинуться вперед.

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

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

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

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

Когда приближается крайний срок, в частности, если крайний срок был предоставлен вам из внешних источников без вашего согласия - это справедливая игра, чтобы просто сказать им, что вы не закончили. Если вы сказали с самого начала, что двух недель не хватит, то никто не может обвинить вас в том, что вы не закончили через 2 недели. Путь от младшего к старшему dev означает обучение тому, чтобы иметь возможность держать прямое лицо, сообщая своим менеджерам, что это не сделано из-за их решений. Имейте в виду, что если вы оценили 4 недели, но должны были отправить в течение 2 недель, то любая задержка будет not вашей неисправностью.

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

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

ответил Frank 7 AM000000110000002331 2014, 11:01:23
21

Существует множество причин, по которым сроки всегда будут жесткими.

Одна из основных теорий здесь - закон Паркинсона.

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

Итак, если у вас есть проект, который займет 3 месяца, и вы получите 6-месячный срок? Сколько времени это займет? 6 месяцев, конечно, потому что всегда есть что-то, что можно улучшить.

Установив более сжатые сроки, руководство пытается выявить лучшее в людях. Сила жестких сроков.

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

ответил Pieter B 7 AM000000110000004431 2014, 11:35:44
9
  

Почему сроки всегда так коротки?

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

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

ответил guillaume31 7 PM00000010000000631 2014, 13:09:06
9

Было упомянуто «Растущие шары», но это в основном проблема менеджера, у которого есть давление сверху и позволяет себе говорить в обещания, которые он не может сохранить. На моем рабочем месте все значительно улучшилось, когда менеджер моего менеджера, который никогда не получал обещанных ему результатов, был заменен. Новому менеджеру был предоставлен список из 10 вещей для достижения, и он просто сказал «нет» семи из них. И не сдвинулось ни с одного из семи «нет», как бы они ни пытались его напасть. И тогда команды под ним, без смешных сроков, достигли трех задач, которые он принял. Который предыдущий менеджер не смог бы сделать. Все (вверх и вниз) действительно счастливы с ним.

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

То, что вы можете достичь с крайними сроками: изменить приоритеты, чтобы задачи some были закончены. Например, если работа A выглядит так, что она будет завершена на 90%, а работа B выглядит так, как будто она будет завершена на 60%, вы перемещаете усилия от B до A, чтобы один из них был выполнен в течение крайнего срока. Или уменьшить объем работы. Если задание A со всеми запланированными функциями не может быть достигнуто в крайний срок, вы уменьшаете функции.

О оценках: если вы сделаете наилучшую оценку времени выполнения задачи, и вы действительно, действительно хорошо, тогда задача займет расчетное время плюс или минус некоторое случайное дополнительное время. Именно поэтому его называют «лучшей оценкой». Если вы сделаете оценку, никто не сможет ее изменить. Никогда не позволяйте никому заставлять вас изменять свои оценки (если только они не снижают оценку, которая оценивается). Тогда ваш менеджер может установить цели. Если эти цели не согласуются с оценками, это его вина. Если вы оцениваете «это занимает три месяца», и он говорит «сделайте это через две недели», это его вина, если вы не закончите через две недели. Это еще больше его вина, если он подчеркивает вас, и вы даже не закончите в течение примерно трех месяцев.

ответил gnasher729 7 PM00000020000004031 2014, 14:22:40
3

Ваша команда явно страдает от чрезмерно оптимистичные графики :

  

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

Если вы действительно много работаете, это проблема управления.

  

Это всегда так? Всегда ли короткие сроки?

Мой опыт: да, они обычно. Но если план слишком оптимистичен, то он обречен на провал.

  

есть ли что-то, что я могу с этим сделать?

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

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

ответил BЈовић 7 PM00000040000001231 2014, 16:08:12
1

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

С тех пор произошло две вещи; бюджеты были сокращены, а курсы управления были изобретены в качестве дешевого заменителя техники.

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

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

ответил RedSonja 7 PM00000040000001331 2014, 16:13:13
1

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

В настоящее время я спрашиваю их: «Итак, когда вы пишете предложение, вы получаете его и отправляете его клиенту, или вы проходите процесс подготовки?»

Рефакторинг - это наш процесс разработки.

ответил Wyatt Barnett 7 PM00000050000005931 2014, 17:27:59
0

Крайние сроки всегда слишком короткие, потому что оценки являются неточными.

Есть два важных момента, которые следует учитывать с крайними сроками:

  1. Оценки должны основываться на всех ожидаемых усилиях (включая понимание, внедрение, тестирование нового /предыдущего поведения и развертывания и т. д.)
  2. Иногда оценки ошибочны

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

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

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

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

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

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

Решите, сколько усилий положить на это; если он все еще не работает, решите перейти к другой команде /компании.

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

ответил Kevin Hogg 7 PM00000040000000331 2014, 16:57:03
0

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

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

  • : необходимая продолжительность, затрачиваемая на создание
  • прошло: продолжительность между началом и окончанием

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

Истекшее

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


Когда это случится с вами, и они будут оказывать давление на вас, вы можете быть интересны в движении Agile. Agile «обманут», введя третью переменную: область.

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

ответил Matthieu M. 7 PM00000050000005931 2014, 17:44:59

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132