Работая над большим, постоянно развивающимся проектом, я почти каждый день сталкиваюсь с различными формами согласования задач: от «Очень срочно, исправьте здесь.
Сможешь сделать это за часЭ» на «Оцените, сколько недель займет решение этой проблемы».
Я как исполнитель сам оцениваю время и сложность выполнения каждой задачи и считаю это единственно правильным подходом к оценке объёма предстоящих работ в области разработки ПО.
Но, наблюдая за многими проектами — сторонними, о которых пишут в статьях и блогах, а также проектами соседних отделов компании, я вижу, что разные менеджеры проектов используют разные подходы к оценке сроков выполнения задач.
И они не всегда совпадают с моим отношением к этому вопросу.
Принципы
Обобщив накопленную информацию по теме оценки сроков, я получил следующие принципы оценки сроков работ:- Окончательную оценку заданию может дать только непосредственный исполнитель;
- Оценки времени всегда слишком оптимистичны;
- Невозможно оценить все время задачи, требующей разделения на подзадачи.
Непосредственный исполнитель (или исполнители в случае групповой разработки) сам разбивает общую задачу на подзадачи для более точной оценки и сам указывает риски по каждой из подзадач.
Таким образом, суммируя время на каждую из подзадач, можно получить весьма оптимистичные сроки выполнения всего объема работ. Эти сроки умножаются на риски и получается примерное время, необходимое для всей работы.
Главное, чтобы эти принципы были понятны не только исполнителю, но и заказчику, иначе ему захочется сыграть с исполнителем в угадайку.
Игра в загадки
В процессе выполнения задания могут возникнуть обстоятельства, на разрешение которых потребуется дополнительное время.Например, оказывается, что архитектура системы не позволяет решить задачу «быстро и красиво», и команде разработчиков приходится выбирать: делать хаки и массу другой ненужной работы, усугубляющей состояние системы в целом, или предложить руководителю проекта провести рефакторинг необходимых модулей.
Оба решения очевидны, как и тот факт, что второе более приемлемо в долгосрочной перспективе.
Сложность ситуации в том, что некоторые лица, принимающие решения, думают, что все в компании играют в угадайку: раз программист назвал дедлайн, то он должен его уложить.
И его не волнуют изменившиеся обстоятельства; ему важнее «перевалить» ответственность за сроки на исполнителя, чем пытаться найти оптимальное решение общей проблемы.
Индивидуальный подход
Практически каждый проект имеет свою архитектуру и свое наследие (обычно «тяжелое»), поэтому при оценке задачи разумно делать скидку на специфику проекта.Одно дело, когда проект молодой, хорошо продуманный, а код написан с тщательным соблюдением всех норм и правил дизайна и кодирования, и совсем другое, когда проект находится в непрерывной разработке уже 5 лет, в течение которых сменились десятки разработчиков, написавших сотни тысяч строк кода с использованием фразы «пока это работает».
Чем сложнее архитектура и чем запутаннее существующий код, тем больше риск не уложиться в сроки выполнения задачи.
В таких случаях я вижу выход во вводе специальных коэффициентов, на которые умножается предварительная оценка времени выполнения задачи.
Игры разума
Каким бы опытом ни обладал человек, поставляющий задачу разработчику, он может лишь «прикинуть» сроки ее реализации; слишком много нюансов необходимо учитывать в каждом конкретном случае: это новый функционал или доработка существующего, гибкость архитектуры системы и качество существующего кода, специфика подхода к решению проблемы внутри конкретный проект. А если постановщик задачи не имеет технического образования, то о сроках выполнения задачи он может только догадываться.И сделать это он может только из любопытства – угадает он или нет, ведь практической ценности такая оценка не имеет. Все дело в том, что некоторые руководители проектов пытаются лично установить сроки выполнения программистом конкретной задачи, что в принципе абсурдно.
Корни этого невежества кроются в непонимании специфики работы в ИТ-сфере: оценить время, необходимое для настройки сервера, может только системный администратор, а время, которое будет потрачено, может сказать только программист. по задаче.
Задача менеджера — управлять задачами, но процессы внутри задачи уже не в его компетенции.
Универсальность
Есть ряд задач, которые должны предусматривать возможность переноса функционала в другие проекты.Если у компании несколько проектов и оцениваемую задачу необходимо выполнить в рамках каждого из них, пора пересмотреть оценку сроков и сложности этой задачи.
Во-первых, требование «универсальности» должно быть заявлено сразу, а не после того, как задача уже вошла в стадию реализации.
Если на одном из поздних этапов разработки заказчик захочет сделать функционал универсальным, это приведет к переписыванию значительной части кода, а значит, и к пересмотру сроков.
В моей практике был случай, когда после доработки сложного механизма для одного из проектов заказчик захотел применить его в другом проекте и, получив ответ о специфике реализации задачи, пожаловался, что функционал не работает. не был сделан универсальным.
Но это уже тяжелый случай.
Трудный случай
Отдельно хотелось бы упомянуть случаи, когда постановщик задач (заказчик) считает себя профессионалом, хотя на самом деле даже не претендует на это.Такой заказчик не верит ни во что изложенное в этой статье и считает, что способен оценить сроки выполнения задачи с точностью до минуты, даже не обладая достаточным объемом технических знаний.
Лучше отказаться иметь дело с такой тиранией.
Это лучшее решение для всех: подрядчик избавится от нереальных сроков, заказчик после бесчисленных попыток умерит свой «профессионализм».
История
Помню, был случай, когда руководство захотело «заморозить» один вялый и абсолютно убыточный проект, после некоторой доработки функционала.Программистам предложили оценить задачу, они оценили ее без рисков — дали очень оптимистичный, минимальный срок.
Когда мы начали копать, то поняли, что нас ждет серьезный рефакторинг.
После бессонных ночей в офисе и работы по субботам и воскресеньям сроки в итоге были соблюдены, но с небольшими недочетами.
За эти недостатки последовал вердикт властей: программисты пропустили установленные ими сроки.
Это была игра в угадайку; никто не хотел слышать о каких-либо рисках.
Программисты подставили себя, в итоге их дополнительно обвинили в нерентабельности и нерадивости проекта, но само руководство на встрече с инвестором выглядело благосклонно, обвиняя в нерентабельности проекта невнимательность команды разработчиков.
Теги: #менеджмент #Управление проектами #разработка #оценка задач #Чулан
-
Партизаны
19 Oct, 24 -
Бесплатный Кластер (Proxmox + Nexenta)
19 Oct, 24 -
Googlebot Понимает Javascript
19 Oct, 24 -
Обновлены Acrobat, Reader И Flash Player.
19 Oct, 24
