Выполнение сроков
Уважаемые профессионалы-разработчики, поделитесь, пожалуйста, жизненным опытом по данному вопросу:
Не раз встречал в вакансиях требование, в общих чертах сводящееся к «умению заранее гарантировать четкие результаты и сроки выполнения предстоящей работы». Меня интересует именно навык заранее гарантировать сроки выдачи конкретных результатов. Благодаря чему он приобретается? Если в первую очередь благодаря опыту, то (простите за каламбур) сколько нужно времени, чтобы начать чувствовать себя «на ты» со временем?
24 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівЭто гонево!
Беги от них чем дальше и чем быстрее тем лучше.
Сроки можно указать ориентировочно, но не гарантировать!
Этого навыка не существует В ПРИНЦИПЕ. Дословно это означает ОТКАЗ МЕНЕДЖМЕНТА выполнять свою работу, а просто расписать на всех дедлайн, урезав разумеется (чтобы вы быстрее работали), и брать за это львиную долю денег (ваших — за то что в сроки не укладываетесь).
Единственная причина, по которой ты ПОСТОЯННО видишь это требование в вакансии — люди не могут продуктивно работать в таких условиях и уходят. А менеджеры как раз могут: делать-то ничего не надо.
Это хуже чем рабы на галерах — здесь давай работай как раб, но ещё и как менеджер, и качество как от реального «не покращеного» эджайла предоставь.
Для того чтобы не нарушать обещаний, их не нужно давать :)
А если серьезно: одна из самых существенных проблем связанных с естимейтами (за исключением оптимизма, есс-но) — это то что умолчательно предполагается что естимейт — это ответ на вопрос «сколько времени ты будешь писать код», в то время как используется это значение для оценки того «когда проблема будет решена». То есть, если ты говоришь что фигня вопрос — работы на два часа, то при сорокачасовой рабочей недели мы собираем 20 тасков, и ... удачи :) Ну или берем 6 «effective hours/day», и получаем 15 тасков. Забывая о стэндапах, митингах, помощи коллеге или собственным просьбах помочь, внешних и внутренних зависимостях, и еще о вагоне и маленькой тележке вещей на которые тратится время. А еще это нужно протестировать, куда-то задеплоить, возможно посмотреть на ошибки. А еще возможно надо подумать, возможно надо время въехать в задачу. В итоге писать код ты возможно таки будешь те же два часа, а вот потратишь — пол дня — день.
это странное и противоречивое(это как принцип неопределенности — либо четкий результат, либо четкий эстимейт) заявление может означать много чего.
один из вариантов(самый безопасный) — просто они обожглись на перфекционистах “я-всё-еще-делаю-свой-код-идеальным-какой-такой-релиз?!”, либо на пофигистах-лентяях(та завтра будет готово! да, опять — завтра! а шо такое?). обе проблемы формулировка не решит(это как написать “не быть мудаком” — от мудаков не защищает, еще и выставляет дураком). но, возможно, люди искренне заблуждаются. в таком случае предлагаю ответ “вы можете протестить мои технические знания, а в процессе работы посмотреть, насколько хорошо я справляюсь с приоритетами — когда нужен перфекционизм, а когда важнее достичь результата любой ценой”.
то есть, к разработчику относятся не как к генератору решений, который еще от окружающих зависит, а тупо как к молотку — если не получается гвозди забивать ровно, то виноват молоток и надо искать другойесли их не устраивает ответ, тогда это другой вариант:
Ігноруй такі вакансії. Якщо таке написано, то слід читати як «шукаємо лоха і вижмемо всі соки».
Гарантировать четкие результаты и сроки возможно только в случае четко поставленного ТЗ. Поэтому основные усилия надо направить на то чтобы получить такое ТЗ (или же подготовить кастомера к тому что «возможны варианты»), а дальше — дело техники.
дубликат
Гарантировать четкие результаты в конкретные сроки возможно исключительно в случае четко поставленного ТЗ. Чего не наблюдается чуть реже чем всегда :)
Гарантию как известно дает только Госстрах.
Когда от Вас просят эстимейты по времени, никогда не забывайте, что Вы — как правило — работаете не в вакууме. То, что Вы накодили, нужно как минимум смержить с кодом других гениальных пацанов, потом потестать, возможно написать какую-то документацию, потом зарелизить клиенту. Не забывайте про юнит-тесты. А главное — не забывайте, что после тестов вылазят баги :) и нужно время, чтобы их воспроизвести, локализовать и пофиксать. Из своего опыта: в лучшем случае процесс коденья и послекоденья соотносяцца как 60 к 40. Если просто умножите время, которое как Вам кажецца необходимо, на два — намана.
Еще тонкий момент — давать оценку в часах или днях :) это нужно выяснить путем проб и ошибок на своем ПМ-е или тимлиде. «Пару дней» — такое однозначно не катит, но «20 часов» большинство лидов поймет как два дня ровно :)
Навык эстимейта приобритается исключительно с опытом, причем в конкретных условиях. С проекта на проект и с комании на компанию оно не переносится. Хотя предыдущий опыт будет способстовать более быстрой адаптации.
Эстимейт это не клятвенное пионерское обещание. Это оценка, которая может расходиться с конечным результатом. Точность в 25% я бы считал хорошей. Про «гарантирует морг» и «влажные мечты» там ниже совершенно верно написали.
Точность эстимейтов, выходящих где-то за 3 дня, резко падает. В этом случае нужна декомпозиция.
Практика показывает, что подключение команды, еще пары человек, дает ощутимо бОльшую точность эстимейта, особенно на длинных дистанциях.
Тайм-менеджмент и эстимейты — вещи параллельные и независимые.
Нужно просто внимательно слушать вопрос, одни менеджеры подходят и спрашивают, сколько займёт это времени, а другие через сколько будет готово, а это две большие разницы — одно число это сколько надо обезьяно-часов, а второе число — конкретная дата в будущем. На второй варинт вопроса никогда не отвечай, потому что ты не знаешь чем еще тебя параллельно могу загрузить. В первом случае просто потраченные часы на проект будут меньше и пусть менеджеры двух проектов выясняют у кого авторитет длинее, а во втором случае надо будет рвать свою жопу, чтобы не профукать свой эстимейт.
это влажные мечты бизнес ящеров, забей х**
Ну во-первых четкие результаты может гарантировать только морг.
Во-вторых это все равно проблема проджект менеджера.
Ну и в-третьих все зависит от того, как быстро ты освоишь техники тайм-менеджмента.
Спасибо.
Пм умножает на 3, как мидл)))
E = (o + 4m + p) / 6
where E is Estimate; o = optimistic estimate; p = pessimistic estimate; m = most likely estimate
Где 5???
Не естественные у вас какие-то коефициенты. Я бы предложил Пи, число ейлера, метод золотого сечения.
Настоящий программер просто сдвинет влево на2-3 разряда ...
Если кроме шуток, то видел варианты и с другими коэффициентами. Один фиг это аппроксимация бета-распределения.
хз, я со своими N годами опыта, всеравно попрежнему множу эстимейты на 5, на всякий случай
А я на Пи :)