Какие факторы вы считаете при принятии решения о том, над чем работать дальше?

Ответ 1

Мы использовали граф значений для определения проектов на основе значения и усилий, как часть lean.

Ответ 2

Несколько вопросов, которые я задаю, влияют на то, над чем я работаю:

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

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

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

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

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

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

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

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

Ответ 3

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

Fun + challenge = быстрое обучение, для меня.

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

Ответ 4

Я склонен взвешивать 4 предмета, основываясь на вещах при принятии решения о том, над чем работать дальше:

• Этот элемент необходим для чего-то еще?
• Могу ли я работать над этим элементом (т.е. я чего-то жду от него)?
• Как быстро/легко получить этот товар?
• Насколько интересно найти работу, необходимую для этого элемента?

Ответ 5

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

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

Задачи, каждая из которых имеет свою оценочную стоимость, идут на то, что называется "отставанием" для команды, вместе с задачами "внутренней реструктуризации" (как правило, рефакторинг, который не будет предоставлять новый пользовательский плюс, но будет способствовать дальнейшему развитию и более продуктивное), а также оцененные затраты и краткое изложение ожидаемых выгод (что должно быть выражено способами, понятными для премьер-министров - к счастью, как я уже сказал, наши высокотехнические люди). Рефакторинг может также, по консенсусу инженерных коллективов, считаться необходимым условием для определенных бизнес-задач (например, "не имеет смысла продолжать работу над компонентом X до тех пор, пока класс Y, слишком большой, не будет правильно разделен, что займет N баллов" ).

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

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

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

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

Ответ 6

Легко. Я спрашиваю своего босса.

Ответ 7

Высокое значение + низкий риск.

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

Ответ 8

Простота: что является самым высоким и лучшим использованием моего времени.

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

Ответ 9

:) В задании я оставил это решение у своего руководителя проекта и руководителя группы, поскольку они знают лучше "Что такое приоритет проекта"

В домашних условиях я делаю, где вижу удовольствие, обучение и вызов

Ответ 10

Ответ 11

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

Ответ 12

Я бы посмотрел на то, что имеет наивысший приоритет с точки зрения управления для первоначального определения приоритетов предстоящих проектов. Если все они являются приоритетными 1 проектами, то есть несколько других факторов, которые могут помочь моему решению:

• Я вижу, насколько ценным будет проект для организации? Это тот тип вещей, который действительно помогает с конкурентным преимуществом, которое у нас есть?

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

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

• Какие команды и структуры существуют для других проектов? Я не думаю, что хочу присоединиться к проекту, который похож на массовое крушение поезда, которое должно произойти. Достаточно ли структуры, чтобы я не ушел и не сделал свою собственную вещь, которая может повредить проектам шансов на успех? Считаю ли я, что я мог бы работать с X, используя методологию Y и технологию Z?

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

Ответ 13

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

Если вы намереваетесь добиться успешной ИТ-карьеры, которая перемещается вокруг работодателей differnet, то, к сожалению, наиболее успешной стратегией является "сбор мозаичного слова". Определите текущую/следующую большую вещь и попытайтесь получить ее на своем резюме. например FInd тривиальный AJAX с проектом SOA back end, который никогда не может выйти на производство, это повысит вашу ценность для будущих работодателей, даже если проект имел мало значения для вашего текущего разработчика.

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

Ответ 14

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

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

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

В проницательных компаниях, однако, хорошо понятно, что решения имеют несколько интересных свойств:

• Каждому требуется время и силы, которые отвлекаются от выполнения фактической работы.

• Каждое решение является компромиссом

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

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

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

Сама структура может дать очень простые правила для принятия решений или, альтернативно, предоставить некоторые аналитические методы, такие как Pareto, SWOT, Cost Benefit, Expected Return analysis или Porter Five Forces и т.д. Однако, стоит держать правила простыми, недвусмысленно и как можно проще.

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

• Компенсация Fog Creek
• Наша стратегия .NET
• Задайте приоритеты
• Fruity рассматривает, настраивает и сверхзвуков: FogBugz 7 здесь

Если вы заинтересованы в выборе того, с чем нужно работать, с личной точки зрения одним из лучших советов, на мой взгляд, является тот, который дал Пол Грэм в своем эссе " Что вы хотите, чтобы вы знали".

Ответ 15

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

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

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

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

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

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

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

Ответ 19

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

Эта книга от Марка Форстера содержит несколько полезных советов.

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

Ответ 20

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

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

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

Ответ 21

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

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

Ответ 22

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

Кроме того, он может быть катарсическим, чтобы иметь возможность пересекать кучу материала из списка.

Ответ 23

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

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

Ответ 24

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

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

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