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