— Вот ты, Иванов, сколько забьешь бразильцам? Ты же старший ответственный нападающий, мне нужна точная цифра!
Верстаешь экран, и как-то лого не так в правом нижнем углу, начинаешь двигать его вправо-влево-вниз, фигак — уже на обед зовут, два часа улетели куда-то. Или вот сложный таск, разбил его на части: библиотечный и клиентский код; пилишь скромную библиотечку, прям хорошо! Тестами обложил, но в душе знаешь, что будут изменения под клиентский код (а там и тесты нужно будет править :(
И тут приходит «плэнинг» покер, фразы типа фибоначчи «намберс» или стори «поинтс». Напланировали задач на тридцать с половиной часов, и команда разрабов из пяти человек всю неделю пилит и пилит и пилит.
И потом оправдываешься: но вы же знаете, есть три стадии написания кода: 1) сделай, чтоб работало; 2) сделай, чтоб работало правильно; 3) сделай, чтоб работало быстро. Ну ok, до третьей стадии редкий фронтэнд-разработчик допишет, но все же — код был переписан дважды. Или так подробно разъясняешь: любой html разработчик решает задачу: a) просто и неправильно; затем б) сложно и неправильно; затем в) сложно и правильно; затем г) просто и правильно. И это не так просто — многие начинают с пункта «б», да там и остаются.
И что же делать? Уволить скажете и будете правы. Ну вот чел хорош, кофе варит, задатки менеджера, на виме пишет код (или на емаксе, я не уверен). Как повысить его производительность?
Сесть рядом и посмотреть, что чел пишет — я за; тут есть но — не все любят, когда к ним пялятся в экран. Или чел говорит, что сделает таску за два месяца; предлагаешь через неделю посмотреть, как идут дела — а там таска почти и готова (я за чекпоинты каждые два дня, но все мы разные). Иногда проблема в незнании библиотеки (например, компонентов), тут нужно тренировать чуйку, мне кажется (понять стиль автора библиотеки). Иногда в мотивации — хочется вспомнить момент из финала года одной тв-игры: «Зинаида Ивановна, вот вы написали нам сотню вопросов, и только 101й сыграл, как у вас хватило сил? — Господин ведущий, я вот читаю книгу — увидела и отослала вопрос, и если нет этого желания, не нужно и играть». Ну то есть, нужно планомерно обучать повышению производительности, мало кто сам себе признается, что может сделать чуть-чуть быстрее (да и захочет делать).
Комментарии (26)
rmuhamedgaliev
04.01.2020 20:03xyli0o а в чем собственно суть поста? А то это не статья, а какой-то клибаейтный заголовок и все.
xyli0o Автор
04.01.2020 21:26Хочется «боевых» историй об оценках (например см. habr.com/ru/post/482854/#comment_21091204)
rmuhamedgaliev
04.01.2020 21:32Тогда хотя бы JS уберите из тегов вряд ли это как-то напрямую к JS относится. А то сбивает с толку.
apapacy
04.01.2020 20:41+2Большинство средних и мелких ИТ-предприятий занято разработкой довольно стандартного и не слоюжного набора задач. Соответственно они поддаются достаточно точному нормированию.
Хотя не всегда, но это может быть связано с чисто субъективными факторами.
Например, команда разработчиков не имеет достаточной квалификации и тогда любая задача это квест. Или вместо того чтобы использовать для решения обычной задачи обычных средств (например готового фреймворка, cms или то что можно купить как услугу — карты, видеочаты и т.п.) команда начинает велосипедить — но тут уже время будет тратиться на на задачу а на разработку новейшего непревзойденного своего.
Но у этого вопроса есть и его вторая часть Она касается разработчиков/внедренцев ERP. Они почему-то не хотят смириться с тем фактом что выполнение одной и той же операции по времени может иногда в разы отличаться у разных исполнителей и у разных партий деталей. В уж просто посчитать какая трудоемкость выполнения операций по вводу информации в ERP систему и сколько для этого потребуется дополнительного персонала — это вообще за гранью понимания. Т.к. ERP это априори лучше и быстрее.
firedragon
04.01.2020 20:59+3Какая то феерическая фигня. Хотя тоже самое описано у Брукса.
Автор пиши продолжение, реально читалось хорошо.
Размажь канбан и аджайлы, пошути про израильскую армию и «кабанов», можно добавить заметок и про российское МО.
Выйдет реальная увлекательная книга
fzn7
04.01.2020 22:10Не любят когда пялят в экран? Вы точно профессионал? Если уверен в своей работе, то с этим не должно быть проблем. Менеджер один раз посмотрит и больше к оценке сроков вопросов не будет.
xyli0o Автор
04.01.2020 23:35Был удивлен тоже, да. Hо люди бывают разные и стоит с уважением относиться к личному пространству
fzn7
05.01.2020 09:40Рабочее место это личное пространство? Oo
apapacy
05.01.2020 16:11По рабочему месту и личному в том числе личному пространству я привожу в пример обучающий ролик по скраму от ИБМ. Менеджер так удачно расположился сам и расположил своих подопечных что ему видны экраны разрабочиков-мужчин и ноги разрабочиков-женщин.
ganqqwerty
05.01.2020 23:31+1Ух, жесть, они там реально как гребцы на галере… Кто-нибудь, дайте бородачу длинный кнут!
fzn7
06.01.2020 09:50В чем в итоге драма вы можете сформулировать? Мне тоже комфортно работать дома в трусах и в майке, но это не имеет отношения к вопросу доверия к вам как к специалисту. Напрягите зеркальные нейроны и встаньте на место менеджмента, который получает оценку +- бесконечность. Вы считаете, что приближаться к вам ближе чем на 2 метра нельзя, ок. Предлагаете просто верить? А в случае срыва сроков простить и забыть?
ganqqwerty
06.01.2020 18:43Ну, к счастью, пока ситуация на рынке такая, что если менеджмент будет не «просто верить», а вам это не понравится — вы за неделю найдете себе другую компанию и другой менеджмент.
fzn7
07.01.2020 22:24Сложный продукт невозможно создать без планирования. Если разработчик этого не понимает, то пусть идет куда угодно
sshikov
04.01.2020 22:11+1>Или чел говорит, что сделает таску за два месяца;
Э-э-э, давайте так — вы можете думать про это что угодно, а я бы просто сразу сказал «Не верю» (с).
Таких оценок просто не бывает в природе. Нет в программировании рутинных задач такого размера, которые можно было бы точно оценить.
Во-первых, два месяца следует разбить на рабочие дни, и никак иначе. И во-вторых, задачи для оценки должны быть размером порядка одного дня. Ну то есть, оценка в три дня — еще туда-сюда, четыре часа — тоже, но два месяца — никуда не годится, потому что ее точность — те же два месяца, то есть реальные сроки будут например от двух до четырех.
>Напланировали задач на тридцать с половиной часов, и команда разрабов из пяти человек всю неделю пилит и пилит и пилит.
Ну и наконец — в неделе обычно 40 часов. Что в таком случае означает ваша фраза? Если у вас в команде пять человек, вы на неделю должны были напланировать на них на 200 часов задач. То есть, задачи у каждого отдельные, а не пять человек сидят над одной и той же.
И если вы будете хотя бы эти простые правила соблюдать — вы будете получать тем более точные оценки, чем более знакома для вас конкретная задача. Иными словами — сначала декомпозиция на мелкие и знакомые задачи, и только потом оценка. Если декомпозиция не получается, значит задачи слишком сложные, или незнакомые, а точность ваших оценок никуда не годится. Но вообще говоря, с этим тоже можно жить.
P.S. Вам бы не пост на эту тему писать, а просто почитать что-то типа Де Марко и Листера, например, для начала. Об управлении проектами и рисками.xyli0o Автор
05.01.2020 00:16Давайте посмотрим с другого угла — запланировали на 200 часов, а разработчики успели сделать на 30.5. Почему? Чисто теоретически, тимлид на встречи побежал, техлид ревьют все подряд, третий заболел, четвертый педалит изо всех, пятый по лотерее тестит за четвертым, а в пятницу инфопятница.
questor
05.01.2020 03:25запланировали на 200 часов, а разработчики успели сделать на 30.5. Почему?
Вообще-то ответ на этот "почему" должны дать в конце итерации и обсудить командой.
Возможных разных "потому что" может быть несколько, вы приводите только один сценарий.
Как показывает практика, точность оценок со временем повышается, думаю не погрешу против истины если скажу, что при наличии подобных обсуждений точность повысится быстрее.
sshikov
05.01.2020 09:05Это именно другой угол. И это как раз обычно называют управление рисками.
>тимлид на встречи побежал
А он не знал, что у него будут встречи? Да ладно вам, наверняка же догадывался — они регулярно бывают. Или знал, но не учел, что рабочих часов у него для кодирования меньше, чем 40 в неделю?
questor
05.01.2020 03:21Статья начата хорошо, но оборвана на половине мысли.
Эстимейты хорошо работают на типовых задачах, поэтому правильно указывать не только оценку, но и например: доверительный интервал, мин-макс, условия применения, показывать риски (и точки в которых проводить эскалацию на ЛПР, чтобы не специалист принимал решение, а менеджер разделял ответственность за срыв сроков)
xyli0o Автор
05.01.2020 12:061. Будет продолжение :)
2. Хочется что-то попроще (например, sean-parent.stlab.cc/presentations/2016-12-14-management-tips/2016-12-14-management-tips.pdf)
hd_keeper
Ну и?