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