Как определить приоритет задач при создании программ?

Категория: Технические советы

– Автор: Игорь (Администратор)

Когда вы создаете программные продукты, так или иначе возникает вопрос определения приоритета между стоящими задачами. За что браться первым, что можно отложить на потом и тому подобное. На эту тему написано немало статей и придумано технологий. Но, тут важно понимать, что универсальных подходов попросту не существует. А все потому, что приоритет складывается из большого числа условий. Другими словами, то что подходит в одном случае, в другом может только навредить. Поэтому в рамках данной статьи я расскажу несколько мыслей на тему как определить приоритет задач при создании программ.

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

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

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

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

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

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

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

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

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

Рассмотрим пример. Автоматическая подстановка текущей даты в поле. С одной стороны, поставить текущую дату дело 5-10 секунд, поэтому автору продукта назвать такую задачу приоритетной сложно. С другой стороны, если пользователям приходится это проделывать по сто раз, что сильно повышает вероятность ошибки, то такая задача может иметь повышенный приоритет. Может быть и обратная ситуация, когда приоритет задачи наоборот раздувают. Поэтому всегда помните, что приоритет носит субъективный характер и что всегда имеет смысл уточнять детали.

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