Pull to refresh

Comments 26

Тогда хотя бы JS уберите из тегов вряд ли это как-то напрямую к JS относится. А то сбивает с толку.

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


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

Спасибо, ради таких комментов и был написан пост
Какая то феерическая фигня. Хотя тоже самое описано у Брукса.
Автор пиши продолжение, реально читалось хорошо.
Размажь канбан и аджайлы, пошути про израильскую армию и «кабанов», можно добавить заметок и про российское МО.

Выйдет реальная увлекательная книга

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

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

Рабочее место это личное пространство? Oo

По рабочему месту и личному в том числе личному пространству я привожу в пример обучающий ролик по скраму от ИБМ. Менеджер так удачно расположился сам и расположил своих подопечных что ему видны экраны разрабочиков-мужчин и ноги разрабочиков-женщин.


Ух, жесть, они там реально как гребцы на галере… Кто-нибудь, дайте бородачу длинный кнут!
В чем в итоге драма вы можете сформулировать? Мне тоже комфортно работать дома в трусах и в майке, но это не имеет отношения к вопросу доверия к вам как к специалисту. Напрягите зеркальные нейроны и встаньте на место менеджмента, который получает оценку +- бесконечность. Вы считаете, что приближаться к вам ближе чем на 2 метра нельзя, ок. Предлагаете просто верить? А в случае срыва сроков простить и забыть?

Все верно но дело в нюансах.

Ну, к счастью, пока ситуация на рынке такая, что если менеджмент будет не «просто верить», а вам это не понравится — вы за неделю найдете себе другую компанию и другой менеджмент.
Сложный продукт невозможно создать без планирования. Если разработчик этого не понимает, то пусть идет куда угодно
А котики хабр? посмотрит менеджер, а там котики хабр. конфуз.))

Если менеджеру не нравятся котики это реально конфуз. Бегите

>Или чел говорит, что сделает таску за два месяца;
Э-э-э, давайте так — вы можете думать про это что угодно, а я бы просто сразу сказал «Не верю» (с).

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

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

>Напланировали задач на тридцать с половиной часов, и команда разрабов из пяти человек всю неделю пилит и пилит и пилит.

Ну и наконец — в неделе обычно 40 часов. Что в таком случае означает ваша фраза? Если у вас в команде пять человек, вы на неделю должны были напланировать на них на 200 часов задач. То есть, задачи у каждого отдельные, а не пять человек сидят над одной и той же.

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

P.S. Вам бы не пост на эту тему писать, а просто почитать что-то типа Де Марко и Листера, например, для начала. Об управлении проектами и рисками.
Давайте посмотрим с другого угла — запланировали на 200 часов, а разработчики успели сделать на 30.5. Почему? Чисто теоретически, тимлид на встречи побежал, техлид ревьют все подряд, третий заболел, четвертый педалит изо всех, пятый по лотерее тестит за четвертым, а в пятницу инфопятница.
запланировали на 200 часов, а разработчики успели сделать на 30.5. Почему?

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


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

Это именно другой угол. И это как раз обычно называют управление рисками.

>тимлид на встречи побежал
А он не знал, что у него будут встречи? Да ладно вам, наверняка же догадывался — они регулярно бывают. Или знал, но не учел, что рабочих часов у него для кодирования меньше, чем 40 в неделю?
на фразе html разработчик, закрыл статью…
  1. Статья начата хорошо, но оборвана на половине мысли.


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


Only those users with full accounts are able to leave comments. Log in, please.