Работа с оценками в качестве младшего программиста

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

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

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

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

• Многие разработчики с небольшим опытом управления оценивают задачи, используя собственную скорость или скорость «лучшего» разработчика в команде.

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

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

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

Из моего опыта:

• Я думаю, что старший разработчик или менеджер должен уметь оценивать историю пользователя (бизнес-требования) с точки зрения размеров футболок (XL, L, M, S, XS).

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

• Очень важно записать, сколько времени вам действительно потребовалось для выполнения задачи.

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

Это не только сделает вашу жизнь менее напряженной, но и позволит департаменту эффективно управлять своими ресурсами.

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

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

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

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

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

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

Это распространено.

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

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

После этого добавьте время, которое, как вы думаете, потребуется для тестирования, общения, анализа и т. Д.

Сначала: если вы пытаетесь справиться с любой проблемой быстрее, вы, вероятно, неплохой программист. Так что давайте избавимся от этой мысли.

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

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

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

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

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

С течением времени разработчик будет совершенствоваться быстрее, чем младший, и вместе с этим улучшится «скорость» команды - расчетный месяц за месяцем.

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

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

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

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

Позвольте представить вам моих двух друзей, WAG и SWAG

То есть, «Угадай дикий осел» и «Угадай дикий осколок»

Хотите верьте, хотите нет, я не придумал это. Они на самом деле довольно распространены в бизнесе. Взгляните на эту статью чтобы понять, что я имею в виду.

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

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

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

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

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

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

Это трудное место. Похоже, вы застряли в стадии «просто нужно доставить» этого конвейера.

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

• Кто сделал дизайн?
• Кто сделал оценку?
• Кто делает реализацию?

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