Павел Холявкин
10 апреля 2014

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

Спасибо!



Павел!

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

Кроме того, при классическом подходе задачи объединяются по формальным признакам: этап дизайна, этап разработки, этап тестирования. Это не даёт управляющему инструментов принятия решений, проблемные задачи зачастую просто сдвигаются в конец проекта: «Сделаем, если успеем».

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

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

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

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

Пример понедельного плана проекта Договоров: гуль-док. Каждая колонка — одна неделя.

P. S.
Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
P. P. S.

Я веду практический курс «Управление проектами, людьми и собой». Дата следующего курса пока неизвестна.

 
Мы напишем вам, когда будет открыта запись. Без спама.

Поделиться

Комментарии

Алексей Рытов
10 апреля 2014

Строю разработку так не первый год и не представляю себе иного. Точнее представляю, и не хочу назад :-) Хочу дополнить, что в части проектов лучше делать не однонедельные, а двухнедельные итерации. Просто на глазок определяешь, что больше подходит.

Ещё я использую https://trello.com — возможно он кому-то тоже пригодится. Также применяю (не всегда) методику Scrum.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.

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




Недавно всплыло

4 2 4 Как создавался новый сайт бюро. Часть третья 1