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