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