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

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

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

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

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

Последний момент, который мы обсудим в этой главе – это совмещение в менеджере функций менеджера, аналитика и тестера.

Функции менеджера:

Планировать

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

Решать вопросы и управлять ресурсами

Взаимодействовать с клиентом

Функции тестера:

Проверять качество результата

Функции аналитика:

Изучать предметную область клиента

Переводить задачи с языка клиента на язык разработки

Проектировать решения, отвечающие потребностям клиента.

Для небольших проектов эти роли можно совмещать. Особенно в случаях когда бизнес-логика на проекте не является очень сложной. Почему лучше обойтись одной ролью? Просто тогда усложняется взаимодействие между ними. Кто-то должен координировать это взаимодействие и система получается еще более сложной.

Например, у клиента возникла потребность что-то доделать. Он обращается к менеджеру и начинает объяснять, но менеджер не понимает его, т.к. бизнес-логика – не его компетенция. Либо клиент может обращаться к аналитику, но тогда менеджеру сложнее контролировать влияние клиента на проект.

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

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

Глава 7. Внедряем в эксплуатацию

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

Посетители будут видеть ошибки и недоработки

Есть риск вместе с тестовыми данными почистить реальные данные

Могут быть ошибки, которые будут критичными для SEO и рекламы.

Учитывая эти моменты, мы распишем свое видение как надо внедрять проекты в эксплуатацию.

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

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

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

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