KnigaRead.com/
KnigaRead.com » Книги о бизнесе » Маркетинг, PR, реклама » Руслан Раянов - Управление проектом разработки сайта или веб-приложения. От идеи до внедрения

Руслан Раянов - Управление проектом разработки сайта или веб-приложения. От идеи до внедрения

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн Руслан Раянов, "Управление проектом разработки сайта или веб-приложения. От идеи до внедрения" бесплатно, без регистрации.
Перейти на страницу:

Теперь переходим к плану проекта. Как надо планировать? Систем планирования очень много, я просто расскажу свое видение этого вопроса.


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


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


Сформулируйте, исходя из приоритетов, задачи для исполнителей. При этом следует понимать, что сам приоритет – это по факту не задача. Задача требует указания контекста и особенностей. Также в задаче вы можете дать рекомендации по решению и описать особенности, если это требуется. Для каждой задачи необходимо определить следующие параметры:

Исполнитель

Дедлайн

Оценочное время

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


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


Еще очень важный момент по планированию – планируйте так, чтобы в конце итерации всегда получать рабочий результат. Что это значит? Представьте, что вы рисуете картину, например, портрет. Сначала вы делаете общий набросок, на котором определяете контуры лица. Затем вы наносите на холст крупные детали (глаза, рот, нос). После этого вы переходите к более мелким деталям (уголочки глаз, губ, морщинки). И, наконец, вы переходите к теням и т.д. На каждом этапе вы получаете полный рисунок и постепенно его детализируете.


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


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


Теперь давайте разбираться с вопросом «Как разбивать на этапы и итерации?».


Условно веб-приложение мы можем разбить на подсистемы/модули. Каждая подсистема может быть разбита на компоненты/страницы.


Первое, что вам нужно сделать, это определить роли в системе и подсистемы, которые в ней будут. Роли – это менеджер, администратор, продавец, оператор и т.д. Подсистемы – это обработка заявки, подготовка КП, форум, система сообщений.


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


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


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





Глава 6. Текучка по проекту


Итерация (неделя) началась. Наша задача, как менеджера проекта, это качественное выполнение всех задач итерации в срок.


Если говорить в общем, то на входе итерации мы имеем следующее:

Задачи исполнителей

Приоритеты клиента


На выходе мы должны получить:

Сделанные задачи

Отчет для клиента

Обратная связь клиента по итерации


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


Через 1-2 дня вы должны проверить, как идут дела, желательно посмотреть промежуточный результат. Нужна ли помощь по задаче? Если задач несколько, то исполнитель должен понимать приоритеты по задачам.


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


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


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


Как проверять задачи?


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


При проверке задачи учитывайте следующие моменты:

Тестируйте на реальных данных, а не на неправдоподобных (вроде строки из 100 символов без пробелов).

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*