Не прошло и года… Хотя, как не прошло? Прошло почти полтора года с начала моей работы над проектом сайта франчайзи 1С. Это комплексный проект, включающий web-разработку.
Интересных моментов за 17 месяцев работы над проектом было много, всем сразу поделиться не получится. В данной статье я расскажу про аспекты project management. Какие, на мой взгляд, были сделаны ошибки и как их можно было избежать.
Начинаем приближение – делим работу на этапы
Всю работу над проектом поделим на следующие основные этапы:
- Погружение в тематику и изучение бизнеса. Разработка, вместе с руководством компании, позиционирования и отстройка от конкурентов.Примечание: Если рассматривать структуру компании, то отдел интернет-маркетинга фактически является in-house агентством. Мою роль в данном проекте можно обозначить как project manager.
- Разработка структуры сайта с учетом требований бизнеса, usability и SEO. Данный этап включал, в том числе, подбор семантического ядра и разбивку его по страницам.
- Написание текстов для страниц сайта.
- Разработка прототипов в Axure на основе полученных текстов.
- Дизайн. Сначала разработка и утверждение общего стиля сайта и главной страницы. Дальше подготовка дизайн-макетов для каждой уникальной страницы.
- Верстка и интеграция (сборка в одно целое) страниц сайта.
* Этапы 3-6 проходили параллельно.
** В плане пропущен этап тестирования, но он подразумевается в п.6.
Что же пошло не так?
Все выглядит достаточно просто. Для небольшого проекта данная схема работы уже показала себя рабочей. Но посмотрите на некоторые цифры по данному проекту:
Собранная семантика – 2492 ключа (напоминаю, что это не интернет-магазин, а b2b сайт).
- Написано контента для 114 страниц
- Подготовлено дизайн-макетов для 89 страниц
- Верстка и интеграция так же 89 страниц.
Не мало, правда?
Основная идея была подготовить сайт, на котором каждая страница сама по себе являлась бы landing page. Страницы в результате не являются 100% уникальными, часть блоков переходит от страницы к странице.
Чтобы проделать такой объем работы требуется большое количество времени и ресурсов. Отсюда появляется ошибка №1.
Ошибка 1. Неправильная оценка объема работы
Изначально все участники процесса понимали, что проект большой. На моменте сбора семантического ядра стало ясно, что проект очень большой. А когда была разработана и утверждена структура сайта, появилось видение настоящего масштаба.
Что сделали мы?
Так как не было точной даты deadline, мы начали один за другим готовить тексты и прототипы страниц, надеясь, что с ростом количества готовых страниц, будет сокращаться среднее время на подготовку одной страницы. Несмотря на медленную скорость продвижения, дополнительные трудовые ресурсы долгое время не привлекались.
В итоге предполагаемый срок сдачи проекта постоянно сдвигался, и ситуация моментами казалось безвыходной.
Как стоило поступить?
На этапе первых страниц рассчитать среднее время на подготовку одной страницы: текст, прототип, дизайн, верстка, интеграция. Умножить на количество страниц, которое было известно с момента утверждения структуры сайта, и посчитать человеко-часы.
Имея на руках данную информацию еще на начальном этапе работы над проектом, следовало привлечь к участию бОльшее количество участников. Вместо самостоятельной подготовки текстов, потратить время на поиски 2-3 копирайтеров. Изменить роль штатного дизайнера с исполнителя на team lead группы удаленных специалистов, оставив на нем функции контроля результатов. Передать непосредственно web-разработку студии соответствующего размера, способной выделить на наш проект нескольких верстальщиков и программистов.
Вывод:
Как можно на более ранней стадии работы над проектом производите оценку трудовых затрат. Чем больше проект, тем большая требуется команда для его реализации.
Отсюда вытекает следующая ошибка – страх делегирования.
Ошибка 2. Моя работа, никому не отдам
Разумеется, владелец компании знает свой бизнес лучше всех, а дизайнер, разработавший фирменный стиль, лучше кого бы то ни было знает, как сделать так, чтобы все макеты соответствовали данному стилю. Но ритм нашей жизни настолько ускорился, технологии настолько усложнились, что человеку просто невозможно сделать все в одиночку.
Что сделали мы?
Несмотря не медленные темпы продвижения, тексты долгое время готовились экспертами в свободное от основных задач время. Да, по содержанию данные тексты гораздо более качественные, но так как их написание является дополнительной нагрузкой, то на подготовку потребовалось много времени и сил.
Дизайнер до последнего момента не мог поверить в то, что кто-то сможет быстрее и, практически без потери в качестве, делать макеты в его фирменном стиле и мы даже не пробовали искать ему помощников.
В результате, когда приступили к верстке, подрядчик был готов брать в работу материалы, а мы не были готовы их предоставить. Сроки постоянно сдвигались, мы предлагали оплату за конечный результат, а не потраченное время, подрядчику стало невыгодно сотрудничество с нами, и мы его потеряли.
Как стоило поступить?
Делегировать. Если внутренних ресурсов компании не хватает, то необходимо привлекать дополнительные трудовые ресурсы.
Когда стало понятно, что придется много писать, в том числе и для блога после запуска сайта, следовало сразу начать поиски профессионального копирайтера. Да, отдать написание текстов стороннему специалисту может быть очень сложно, поэтому копирайтера лучше иметь в штате. У нас появился такой специалист, когда уже было написано 90% текстов.
Стоило оставить разработку основного стиля на штатном дизайнере, а технические задачи передать удаленным исполнителям. Мы же начали передавать работы по дизайну, когда было готово больше 70% страниц.
Вопрос с версткой можно было упростить, доверив всю разработку студии, сняв таким образом с себя задачи поиска конкретных исполнителей, оценку их технического уровня, формулировку и соблюдение стандартов разработки.
Вывод:
Надо иметь достаточно смелости, чтобы доверять свою работу другим людям. И, даже, если задача будет сделана не на 100%, а на 75%, то вы потратите меньше времени на исправление ошибок, чем на решение задачи с нуля. И еще, подумайте, заметит ли кто-то кроме вас, что задача решена на 75%, а не на 100%? Не всегда стоит стремиться к идеалу.
От проблемы делегирования мы плавно переходим к вопросу: «С кем работать?»
Ошибка 3. Отсутствие проверенной команды проекта
Это скорее не ошибка, а отсутствие аналогичного опыта. Наиболее ощутимо в данном проекте это коснулось web-разработки.
Что сделали мы?
Когда был готов дизайн для нескольких страниц я начала поиски подрядчика на web-разработку.
Так как знакомые подрядчики отказались от данного проекта из-за большого объема, пришлось искать нового. До этого мне приходилось работать с более мелкими проектами, либо в ситуациях, когда подрядчик был определен заранее, и я поступила так, как делала это раньше. Стала искать не компанию, а отдельного специалиста по 1С-Битрикс.
Исполнитель нашелся, но его не устроила скорость нашей работы, и мы прекратили сотрудничество. Затем мы обратились в небольшую студию, которая на протяжении пары месяцев не могла нам сдать результаты по задаче, которую планировали закончить за 10 дней. Потом у нас в штате все-таки появился свой Head of development, который смог взять на себя функцию подбора удаленных исполнителей и их проф. тестирование.
У нас появились технические требования к проекту и очень жесткий отбор кандидатов. Процесс подбора кандидатов напоминал поиск золота на приисках. В итоге мы смогли сформировать сильную команду верстальщиков и программистов. Но для этого была просмотрена не одна сотня резюме, проведены десятки собеседований, а какие-то исполнители отсеивались после провала первого реального задания. Отсутствие подходящих исполнителей стало одной из самых сложных задач по ходу проекта.
Как стоило поступить?
Следовало с самого начала отдать проект в студию крупного или среднего размера, у которой уже сформирована своя команда специалистов, включая тестировщиков. При работе с фрилансерами, функции тестирования полностью ложиться на менеджера проекта, из-за чего приходится проходить несколько итераций правок по каждой задаче, что отнимает большое количество времени.
Плюсы работы со студией: наличие уже разработанных стандартов качества работы, смена конкретного исполнителя, без привлечения ресурсов заказчика, наличие механизма внутреннего тестирования.
Вывод:
Аналогичный, если не хватает своих ресурсов, то правильное решение – делегировать. Что вышло бы более экономично — заказ сайта в студии или работа с фрилансерами, сказать сложно, т.к. на поиск команды ушло огромное количество рабочих часов, которые могли бы быть потрачены на решение других задач.
Ошибка 4. Agile против Waterfall
Запускать весь проект сразу или по частям? В самом начале работы над проектом мы об этом даже не разговаривали, хотя можно было. Чем дальше, тем я больше убеждаюсь в мысли: «Чем крупнее проект, тем важнее применение Agile».
Что сделали мы?
Мы запустили сайт, напомню, 89 уникальных страниц, за пять релизов. Первый был в конце декабря 2015, затем в апреле 2016, августе, сентябре и финальный в первых числах октября 2016 года. По ходу работы над проектом, некоторые страницы добавлялись, некоторые решили убрать, что для такого большого проекта является нормальным рабочим процессом. Минусы подхода оказались в другом.
Во-первых, бизнес при подходе Waterfall не видит ежедневной работы над проектом и не понимает, двигается ли процесс и в правильную сторону ли идет движение. В итоге есть большой риск сдать проект, который не соответствует реальным ожиданиям заказчика, даже в таких условиях как наши, когда заказчик внутренний и с ним есть постоянный контакт.
Во-вторых, из-за редких релизов, даже при условии использования системы контроля версий (Git), после переноса изменений с тестовой ветки на боевой сайт происходили нестыковки версий и сайт, идеально работающий на тестовом домене, на боевом давал сбои. Приходилось заново все проверять, тестировать и вносить правки.
И, наконец, мы не имели возможности запускать активную рекламу на сайт и привлекать трафик, пока полностью не закончили все работы по web-разработке.
Как стоило поступить?
После формирования структуры сайта следовало расставить приоритеты для разделов и страниц сайта. Таким образом, можно было бы запускать страницы в более подходящем для бизнеса порядке, подключая услугу за услугой.
В соответствии Agile подходу к проекту, нам следовало выпускать релизы каждые 2-4 недели. Пусть это были бы даже 1-2 страницы, но все заинтересованные лица могли бы видеть прогресс и оперативно влиять на процесс.
Тестирование 1-2 страниц занимает в разы меньше времени, чем 50. Регулярные релизы могли бы поддерживать максимально актуальную версию сайта, что снизило бы количество ошибок при слиянии разных версий сайта.
И, самое важное, Agile позволил бы начать привлекать трафик на сайт до финальной сдачи проекта. Таким образом нам бы удалось перевести сайт из источника расходов в инструмент для получения прибыли. Когда бизнес видит, что сайт приносит доход, ему приятнее выделять средства и свои временные ресурсы на дальнейшее его развитие.
Вывод:
Рекомендую сначала запускать минимально возможную версию сайта, чтобы максимально быстро перевести его к самоокупаемости. А уже дальше, короткими спринтами, доводить проект до идеального (желаемого) состояния.
Зачастую, разработка сайта – это процесс, а не проект. Улучшать и дорабатывать его можно бесконечно. Главное, не терять цель, для чего вы это делаете и не забывать делать релизы почаще.
А есть ли результат?
Да, конечно! Несмотря на то, что работа над проектом временами напоминала бег под водой, когда, чтобы сделать даже маленький шаг, приходится преодолевать огромное сопротивление, результат оказался очень классным.
У нас есть раздел программ с возможностью выбора варианта поставки. Если посетитель еще не знает, какая программа 1С ему нужна, то мы предлагаем удобный инструмент сравнения программ. По возможности мы используем интерактивные элементы для вовлечения пользователя. Конечно же, мы предлагаем познакомиться с нашим опытом, так как для данного бизнеса это критично важно. А в компетентности специалистов можно убедиться, почитав экспертные материалы в блоге компании.
