Еще один негативный момент частого взаимодействия «клиент-исполнитель» – это постоянные прерывания в работе. Это тоже нехороший момент с точки зрения выполнения задач на итерации. Да, клиент будет доволен, что ему дают напрямую общаться со всеми на проекте, но важнее, чтобы проект двигался к логическому завершению, а не просто удовлетворялись сиюминутные пожелания клиента.
Если клиент более-менее технически подкован, то он может получить точную техническую информацию от исполнителя на проекте. Такое взаимодействие имеет место, но только по согласованию с менеджером. В идеале менеджер должен быть в курсе о любых движениях на проекте. Ему не обязательно везде участвовать, но проинформирован он быть должен.
Очень сложный момент с отчетами от исполнителя для клиента. Дело в том, что исполнитель обычно пишет на своем техническом языке и на своем уровне абстракции. Весьма вероятно, что клиент просто не поймет исполнителя. Вы должны учитывать эту особенность и давать писать отчеты исполнителю, если он в состоянии написать отчет на языке клиента – простыми словами, поменьше букв, меньше технических деталей, общее положение по задачам и проекту в целом.
Последний момент, который мы обсудим в этой главе – это совмещение в менеджере функций менеджера, аналитика и тестера.
Функции менеджера:
Планировать
Контролировать сроки и исполнение задач
Решать вопросы и управлять ресурсами
Взаимодействовать с клиентом
Функции тестера:
Проверять качество результата
Функции аналитика:
Изучать предметную область клиента
Переводить задачи с языка клиента на язык разработки
Проектировать решения, отвечающие потребностям клиента.
Для небольших проектов эти роли можно совмещать. Особенно в случаях когда бизнес-логика на проекте не является очень сложной. Почему лучше обойтись одной ролью? Просто тогда усложняется взаимодействие между ними. Кто-то должен координировать это взаимодействие и система получается еще более сложной.
Например, у клиента возникла потребность что-то доделать. Он обращается к менеджеру и начинает объяснять, но менеджер не понимает его, т.к. бизнес-логика – не его компетенция. Либо клиент может обращаться к аналитику, но тогда менеджеру сложнее контролировать влияние клиента на проект.
На мой взгляд, в большинстве случаев можно обойтись одним человеком для совмещения этих ролей.
Пожалуй, это была самая важная глава. В ней мы рассмотрели, как вести ежедневно проект, как планировать итерации и какие взаимодействия бывают на проекте. Уделяя достаточно времени проекту по указанной выше схеме и при адекватной оценке ресурсов, вы уже вероятно доведете проект до логического результата. Однако вам необходимо изучить 2 специальных этапа, без которых не обходится ни один проект. В следующей главе мы как раз поговорим об одном из них.
Глава 7. Внедряем в эксплуатацию
Очень часто в проектах бывает так, что ввод в эксплуатацию происходит неявно. Т.е. делали, делали, а потом раз – и сайт уже работает в боевом режиме с реальными посетителями. У этого подхода есть ряд минусов:
Посетители будут видеть ошибки и недоработки
Есть риск вместе с тестовыми данными почистить реальные данные
Могут быть ошибки, которые будут критичными для SEO и рекламы.
Учитывая эти моменты, мы распишем свое видение как надо внедрять проекты в эксплуатацию.
Первое, чем надо заняться, – это общее тестирование. Вы должны проверить совместную работу всех модулей, попробовать основные workflow ваших пользователей, т.е. сценарии, по которым будут действовать ваши посетители.
Также вы должны проверить корректность работы сайта в разных браузерах и на разных платформах. Конечно, проверять следует те браузеры и платформы, которыми пользуется ваша целевая аудитория.
Тестирование старайтесь вести на реальных данных и очень желательно провести тест на больших объемах данных. Со временем база данных может разрастись, и приложение, которое очень шустро работало в начале, может начать дико тормозить на больших объемах данных. Поэтому забейте программно в базу данных множество информации и посмотрите, как реагирует на это система.
