Для этой оценки очень важно, чтобы ТЗ было уже написано и оно было достаточно детальным. Если этого не будет, то разработчики завалят вас кучей вопросов по деталям проекта.
Оценку лучше вести в часах и определить нормированную стоимость этого часа. У каждого компонента (или страницы) будет 2 оценки – минимальная и максимальная. Чем точнее написано задание, тем ближе они будут друг к другу.
В итоге, суммируя эти оценки, вы получите довольно точное представление о бюджете и сроках проекта.
Очень важно при этой оценке учесть все дополнительные работы (о которых могут забыть разработчики), а именно:
● подготовка проекта
● совещания
● тестирование
● первичная поисковая оптимизация
● вынесение настроек в админку
● дизайн для админки
● уведомления
● типовой функционал, не учтенный в ТЗ (смена пароля, восстановление пароля, выход и т.д.)
● создание системы бекапов
● настройка мониторинга доступности
● регистрация в поисковых системах
● обработка новых запросов клиента
● ведение проекта
● составление отчетности по проекту.
Еще важный момент, учитывайте, что в любом случае будут неучтенные доработки. Их размер зависит, в основном, от клиента – именно он в конечном счете определяет какие функции надо изменить. Здесь важно помнить, что чем позже вы внедряете изменения, тем дороже они будут стоить. Поэтому желательно сразу правильно определять состав функциональности в проекте.
При оценке важно учитывать такой показатель как уровень абстракции. Выберите приемлемый для себя уровень абстракции и именно на нем проводите оценку. Если у вас нет ресурсов для уточненной оценки, оценивайте на уровне модулей. В любом случае начинайте двигаться о верхнего уровня к нижнему, т.е. сначала в целом поймите на уровне подсистем что это будет, а затем разбирайте каждую подсистему на модули, а модули на компоненты. На любом из уровней абстракции вы можете остановиться, посчитав его достаточным для целей оценки.
Еще момент, выберите уровень технических решений и качества. Здесь имеет смысл брать ориентир на другие сайты, т.е. этот блок сделать примерно как на site.ru. Конечно, это очень субъективно, но позволит команде разработке сделать свое представление о выбранном уровне качества.
После того как мы сделали оценку по срокам и бюджету, хорошо бы собрать всю информацию воедино в так называемую концепцию проекта.
Что в нее входит:
1. Основные параметры проекта:
a. Цель проекта и результат. Что в итоге вы должны получить? Зачем вам нужен этот проект? Входными данными для какого следующего проекта будет результат текущего проекта? Четко определите критерии завершения проекта.
b. Сроки. Сколько в целом месяцев/недель займет проект?
c. Бюджет. Сколько вы запланировали заложить средств на реализацию проекта?
d. Объем. Что нужно реализовать в рамках проекта? Что мы оставим за бортом? Определите границы проекта.
e. Команда. Кто будет реализовывать этот проект? Кто за что будет отвечать на проекте?
f. Ресурсы. Какие дополнительные ресурсы вам потребуются для реализации проекта? Это могут быть знания, технические средства, место для работы и т.д.
g. Приоритеты внутри проекта. Что в проекте важнее всего из параметров? Сроки, бюджет, качество, объем? Возьмем, например, самолет. В нем важны, в первую очередь, качество и объем. Объем нельзя урезать, да и качество должно быть максимальным. Теперь возьмем социальную сеть. В ней могут быть важны бюджет (т.к. это деньги инвестора) и качество. Объем здесь не так важен – его можно развивать по ходу запуска проекта. Понимание приоритетов даст вам в будущем возможность варьировать параметры проекта. Например, вы не успеваете сделать в срок, а сроки являются приоритетом. Что делать? Либо уменьшайте объем, либо увеличивайте бюджет, либо внедряйте более простые и быстрые решения. При этом, разумеется, вы исходите из прописанных приоритетов проекта.
h. Риски. Каковы риски проекта? Выпишите список рисков, связанных с проектом. Вы можете их категоризовать. Например, организационные, технические, внешние, по параметрам проекта. Далее для каждого риска вы проставляете степень критичности и степень вероятности (от одного до трех). Далее в порядке приоритетности прорабатываете каждый риск – пишите меры, которые уменьшают вероятность и критичность риска. Тем самым вы получите карту рисков проекта и план по их обработке.
i. Ориентировочный план. Вы примерно должны определить, как вы достигнете цели проекта. Здесь не нужна детализация – просто определите этапы достижения цели. Это позволит команде разработки в целом понимать в какую сторону надо двигаться. Для каждого этапа наметьте ориентировочные сроки. Здесь следует понимать, что это не обязательство или план к исполнению. Это просто желательный план развития проекта, который в процессе может изменяться.
2. Краткое описание. Очень желательно иметь лаконичное описание, которое позволит сразу схватить суть проекта и показать его особенность. Это нужно для взаимодействия с внешним миром (дизайнеры, программисты, партнеры и т.д.). Хорошее описание сэкономит вам кучу времени при взаимодействии с возможными исполнителями на проект – вам не будут писать те, кто заведомо не подходит.
3. Критерии отбора исполнителей. Лучше их заранее проработать, чтобы опять же сэкономить время. Что могут включать эти критерии:
a. Общие требования, например, технологии, географическое расположение, образование, студия/фрилансер, под ключ/специализация. Указывайте требования так, чтобы сразу по максимуму отсеять кандидатов. Подумайте с какими кандидатами вы точно не хотели бы работать. При этом не указывайте аморфные "мастер своего дела" и прочее – это совершенно ни о чем не говорит кандидатам.
b. Мини тест на адекватность. Если кандидат хочет с вами работать, то пусть сделает простую последовательность действий, которую вы для него подготовили. Например, отправить на почту письмо с темой "ХХХ" с вложением КП в формате PDF. Если исполнитель вам пишет не в вашем формате, то скорее всего он будет так же себя вести и на проекте. Исполнительность – это первое, что нужно проверять для кандидатов.
Итак, мы написали концепцию. Исходя из этой концепции, мы будем инициировать проект. В следующей главе мы изучим моменты, связанные непосредственно с началом проекта.
Глава 5. Начинаем проект
Для начала давайте определимся, из чего мы исходим в начале проекта:
У нас есть концепция со всем параметрами.
У нас есть техническое задание. Мы не рассматривали его написание в этой книге. По сути, это техническое описание, что надо сделать на проекте. Обычно оно состоит из макетов и системных требований.
Состав команды разработки определен. Опять же мы лишь частично затронули момент с поиском исполнителей на проект. Предполагаем, что команда разработки у нас уже есть.
Вы – менеджер этого проекта. Т.е. у вас есть все полномочия по принятию решений на этом проекте, а также выделены ресурсы на проект, которыми вы можете распоряжаться.
Инициацию проекта можно условно разделить на 2 пункта:
Подготовка и выделение ресурсов
Планирование проекта
В плане подготовки инструментов и выделения ресурсов вам необходимо рассмотреть следующие моменты:
Вы должны обеспечить подготовку тестового домена, сервера, где будет работать тестовое приложение, базы данных, инструментов разработки (SVN, среды разработки и др.). Одним словом, вы должны подготовить тестовую среду.
Дайте права и полномочия членам проекта. Это доступы к системе планирования, доступ к тестовому приложению (база, код, иногда сервер). Дайте контакты участников проекта.
Необходимо провести обучение участников проекта предметной области. Особенно это важно для таких проектов, где предметная область очень далека от простого разработчика, например, специфические процессы продаж, сложное производство и т.д. Также на этом этапе важно выработать общую терминологию и пояснить ее участникам проекта.
Определение границ проекта для участников. Разработчики должны понимать область проекта, иначе есть риски, что проект пойдет не в том направлении. Обсудите параметры проекта с разработчиками, чтобы они понимали требуемый уровень качества и приоритеты клиента.
Наконец, проведите общее совещание по проекту. Это обобщает все вышесказанное + дает возможность познакомиться членам проекта.
Теперь переходим к плану проекта. Как надо планировать? Систем планирования очень много, я просто расскажу свое видение этого вопроса.
Как мы говорили выше, изначально лучше планировать общими этапами с очень примерными сроками. Очередной крупный этап детализируется на итерации (1-2 недели).
Скрупулезно планировать вы должны только текущую итерацию. Определите совместно с заказчиком, что вы должны сделать на этой итерации. По сути это будут приоритеты заказчика на итерацию.
Сформулируйте, исходя из приоритетов, задачи для исполнителей. При этом следует понимать, что сам приоритет – это по факту не задача. Задача требует указания контекста и особенностей. Также в задаче вы можете дать рекомендации по решению и описать особенности, если это требуется. Для каждой задачи необходимо определить следующие параметры:
Исполнитель
Дедлайн
Оценочное время
Чек-лист. Задание проще всего формулировать в виде чек листа. Так будет проще закрывать задачу исполнителю, а вам – проверять. Чек-лист – это антипод монолитного куска текста в котором размышления автора перемешиваются с заданием и вопросами к исполнителю. Структурируйте свои задачи в форме простых и понятных действий, которые надо сделать исполнителю для закрытия задачи.
Таким образом, у вас на итерацию будет пакет задач для исполнителей, который они должны сделать к определенному сроку. Если итерация составляет 1 неделю, то лучше, чтобы задачи были сделаны к четвергу, чтобы было время внести корректировки в рамках этой итерации. По окончании итерации необходимо написать отчет, в котором мы отражаем насколько хорошо мы закрыли приоритеты клиента на эту итерацию.
Еще очень важный момент по планированию – планируйте так, чтобы в конце итерации всегда получать рабочий результат. Что это значит? Представьте, что вы рисуете картину, например, портрет. Сначала вы делаете общий набросок, на котором определяете контуры лица. Затем вы наносите на холст крупные детали (глаза, рот, нос). После этого вы переходите к более мелким деталям (уголочки глаз, губ, морщинки). И, наконец, вы переходите к теням и т.д. На каждом этапе вы получаете полный рисунок и постепенно его детализируете.
Альтернативой такому подходу может быть сначала полная прорисовка глаз, затем нос и т.д. Но это не будет гармоничным рисунком.
Также и в вашем случае. Вы делаете скелет приложения, создаете пустые страницы, затем делаете общие компоненты без стилизации и т.д. В итоге на каждом этапе у вас будет рабочее приложение.
Теперь давайте разбираться с вопросом "Как разбивать на этапы и итерации?".
Условно веб-приложение мы можем разбить на подсистемы/модули. Каждая подсистема может быть разбита на компоненты/страницы.
Первое, что вам нужно сделать, это определить роли в системе и подсистемы, которые в ней будут. Роли – это менеджер, администратор, продавец, оператор и т.д. Подсистемы – это обработка заявки, подготовка КП, форум, система сообщений.
Совместно с заказчиком вы определяете приоритеты по подсистемам и личным кабинетам ролей. В результате вы создаете примерный план этапов проекта с учетом приоритетов бизнес-целей заказчика. При этом этап – это не обязательно только реализация одной подсистемы. Он может включать реализацию разных подсистем или их частей.
Далее вы берете текущий этап и разбиваете его на страницы. В большинстве случаев каждая страница – это одна задача. Конечно, есть очень тяжелые страницы, которые разбиваются на множество задач, но вы можете сами определять порядок композиции задач. В итоге вы получаете список задач на итерацию исходя из этапа и приоритетов заказчика внутри этапа.
Незаметно мы подобрались к концу главы. Сейчас у вас есть примерный план по этапам проекта и детализированный план на текущую итерацию в форме конкретных задач для исполнителей с понятными и простыми чек-листами. Следующий момент – самый сложный в проекте. Именно он определяет успех проекта и скорость его движения к долгожданному результату. Об этом мы будем говорить в следующей главе.
Глава 6. Текучка по проекту
Итерация (неделя) началась. Наша задача, как менеджера проекта, это качественное выполнение всех задач итерации в срок.
Если говорить в общем, то на входе итерации мы имеем следующее:
Задачи исполнителей
Приоритеты клиента
На выходе мы должны получить:
Сделанные задачи
Отчет для клиента
Обратная связь клиента по итерации
С чего начинается любая задача – передача задачи исполнителю. В начале недели обсудите задачи с исполнителями голосом, получите от них обратную связь по задачам. Есть ли у них вопросы? Предложения? Проблемы с реализацией? Верно ли оценено время? В итоге вы должны разрешить все вопросы и сделать так, чтобы исполнитель поставил статус задач в "Принято в работу".
Через 1-2 дня вы должны проверить, как идут дела, желательно посмотреть промежуточный результат. Нужна ли помощь по задаче? Если задач несколько, то исполнитель должен понимать приоритеты по задачам.
Если исполнитель выполнил раньше времени все задачи (а такое очень редко бывает), то либо давайте что-то со следующей итерации, либо передавайте ему задачи от других исполнителей на проекте.
В идеале надо каждый день следить за ходом задач на проекте и давать обратную связь клиенту по ходу работы и исполнителям по сделанному функционалу. Это позволит вам держать руку на пульсе проекта.
Важный момент – сразу договоритесь с заказчиком по минимуму влезать в середине итерации. Только в критических ситуациях. Заказчик в пятницу получает отчет по итерации и начинает тестировать приложение. В этот же день можно начинать формулировать приоритеты и задачи на следующую итерацию. Также желательно иметь от заказчика обратную связь в виде оценки, которая характеризует степень его удовлетворенности. Если вы получили низкую оценку более 1 раза – это знак, что надо что-то менять на проекте.
Как проверять задачи?
Первое, что надо сделать – это чтобы при выполнении исполнители неявно сами тестировали свой код. Мы это делаем следующим образом: при выполнении задачи исполнитель должен указать скрин по выполненной задаче на сервере.
При проверке задачи учитывайте следующие моменты:
Тестируйте на реальных данных, а не на неправдоподобных (вроде строки из 100 символов без пробелов).
В идеале созванивайтесь с исполнителем и совместно посмотрите задачи. Это ускорит процесс понимания и доработок (некоторые из них можно будет сделать по ходу просмотра задач). Дополнительный эффект – разработчику будет стыдно при большом количестве ошибок (все-таки личное общение), и это будет его мотивировать тщательнее проверять свои решения.
При выявлении ошибки всегда указывайте конкретику: URL, скрин, в чем именно ошибка, как должно быть.
Ведите метрики по ошибкам и выходам за дедлайн. По сути, 2 главные метрики программиста – это количество ошибок и выход за дедлайн. Используйте такую систему ведения плана, которая позволит вам отслеживать эти параметры. Мотивируйте исполнителей делать минимум ошибок и в пределах дедлайна.
Организационно можно разбить проверку на 2 составляющие: качественную и организационную. Качество проверяет тестировщик. Организационная составляющая – это общий контроль задач проекта и сроков. Фактически эти задачи можно дать разным людям (тестировщик и менеджер проекта). Однако в большинстве случаев объединение этих ролей обоснованно по соображениям рамок бюджета.
В рамках итерации вы должны дать исполнителям и заказчику обратную связь. Для исполнителей – это тестирование и рекомендации по выполнению задач. Для заказчика – это недельный отчет. Отчет по итерации может готовить либо менеджер проекта, либо старший разработчик.
Что должен включать такой отчет?
В первую очередь, это насколько команде удалось закрыть приоритеты клиента.
Во-вторых, это примерный план на следующую итерацию, т.е. что мы планируем делать дальше.
И последнее, это проблемы, особенности, предложения, возникшие в ходе итерации. Ваша задача – это дать как можно более полную информацию по состоянию проекта для заказчика. Также стимулируйте заказчика тестировать разработанные модули, указывайте в отчете ссылки на разработанный функционал, просите обратной связи по нему.
Проблемы и риски
Не бывает ни одного проекта без нештатных ситуаций и проблем. Они обязательно будут и ваша задача – научиться решать их быстро и эффективно.
Важно выработать общий набор принципов, исходя из которых вы будете принимать решение. О них мы говорили ранее.
Имейте правильные договоренности с клиентом. Чем прозрачнее ваше взаимодействие с ним, тем больше доверия и тем больше возможностей для маневра.
При решении сложных вопросов всегда действуйте в формате Win-Win. Учитывайте интересы всех сторон. Если вы будете постоянно прожимать одну из сторон, в итоге это может очень негативно сказаться на проекте. Делайте диалог и взаимодействие максимально прозрачными и открытыми.
При возникновении проблемы задайте себе очень важный вопрос: "Это проблема систематическая?", т.е. имеет ли она повторяющуюся природу? Если да, то ищите глобальные причины проблемы и рубите корень, а не срывайте листья. Старайтесь подобные конфликты и проблемы вскрывать на ранней стадии, избегая проблем в текущий момент. Позже эти проблемы превращаются в драконов и монстров, которые потребуют сверхусилий для их разрешения.
Теперь поговорим о рисках. Как мы раньше говорили у риска есть критичность и вероятность. Постоянно пересматривайте риски проекта и реализуйте мероприятия по их уменьшению. Если вы не можете уменьшить риск, то вам придется его принять, т.е. согласиться с его возможными последствиями – это тоже своего рода обработка риска – осознанное принятие риска.
Давайте кратко рассмотрим основные типовые риски и меры для их нейтрализации.
Нехватка бюджета. Меры: договоренности с клиентом, более точная оценка, уменьшение объема, качества и других параметров проекта.
Уход ключевого исполнителя. Меры: обучение и документация, работа исполнителей в паре, мотивация исполнителей, договоренности с исполнителем (неустойка).