Надо было вчера: как сделать сайт в короткие сроки
Редкий заказчик не говорит на старте проекта, что сайт нужен был еще вчера. Редкий заказчик получает этот сайт реально в короткие сроки – чаще проект затягивается на безумное количество времени. Ну или получает быстро, но откровенное г…
О горящей *опе (читай: дедлайнах) в digital-среде слагают легенды, а заваленные сроки по проектам уже стали нормой. Для кого-то нормой, но только не для 365 Media Group.
В статье расскажу на примере реальных кейсов, что нам помогает удерживать проекты в рамках оговоренных сроков.
Что поможет сделать сайт быстро и качественно
Деньги!!!
Шучу, конечно, куча бабла не решает абсолютно все проблемы, хотя явно скрашивает жизнь. Но сделать сайт быстро и качественно = дорого, вот тут об этом говорили, поэтому примем “деньги” за постоянную и идем дальше.
Помимо денег ингредиенты для успешного успеха следующие:
- Проверенные временем, кровью, потом и слезами проджектов методологии ведения проектов;
- Светлые умы, способные на старте проекта вытащить на свет божий реальный запрос заказчика и предложить самое эффективное решение при имеющихся вводных;
- Прямые руки из плеч, способные это дело реализовать в срок и по красоте (не уйдя в запой, желательно).
Дальше о каждом по порядку (и реальные кейсы обещал, помню).
Гибкие методологии – потому что звучит красиво
На деле ни одна методология, расписанная в учебнике, не сравнится с тем шедевром российских реалий, который можно увидеть на проектах.
Гибкие методологии они на то и гибкие, чтобы подстраиваться под реальность. Я бы вот, например, в принципы Agile добавил что-то вроде “обязательная доставка бутылки горячительного для разраба, если приходится вызвать парня в выходной на пару часиков, ибо аврал авральный”. Такое реально бывает.
Гибкость – наше все, и вы даже не представляете, в какие позы лотоса мы иногда выкручиваемся, если “все упало, надо срочно поднять”. Рабочие формулы для своих проектов мы уже давно выявили путем натертых мозолей.
Вот пример, что можно сделать со Scrum, если время улетает на какую-то непонятную возню:
- Спринты: По всем канонам спринт занимает 2 недели. Но кто сказал, что этот срок нельзя изменить, если того требует специфика проекта.
- Ежедневные стендапы: Если команда распределенная и встречаться ежедневно сложно, потому что один в Геленджике, другой на Камчатке, можно сократить количество стендапов до пары раз в неделю. Реалии удаленки, что поделаешь, зато поддержку проектов можно почти круглосуточно оказывать. Это прям наша ситуация, реагируем на запросы с 4 утра и до 10 вечера по Москве.
- Бэклог: Шерстить бэклог проектов стоит регулярно. Не надо ждать, когда протухнут задачи, которые вообще-то надо бы вот прям сейчас сделать, потому что от них зависит будущее всего проекта.
Некоторыми ритуалами вообще можно пожертвовать, если они жрут много рабочего времени, но по факту ценности дают мало.
Короче, мы ко всему привыкли подходить с долей здорового критического мышления и это дает свои результаты. В частности, помогает сократить сроки проектов.
Простой пример.Идет разработка магазина. Стандартный путь. Сделали дизайн – согласовали. Сделали верстку – согласовали. Сделали натяжку – ну, вы поняли.
Ускорение проекта 1. Если клиент адекватный и идет на контакт, мы переходим к верстке и натяжке уже после согласования страницы, а не всего дизайна. Есть риск получить нежданчик, но мы его на себя принимаем и понимаем + если идти где-то с опережением, то можно потом свободнее управлять ресурсами.
И тут как раз вытекает Ускорение 2. Прилетает клиент с криком: “Все пропало”. А спринт уже забит. Что делать? Верно, у нас есть на каком-то из проектов лаг по времени, который мы сами себе и создали. Значит, мы можем спокойно выдернуть 1 или 2 людей на небольшой срок на тушение пожара. Для этого у нас в команде есть определенные люди (максимально стрессоустойчивые, истинные джедаи), которые могут тушить такие пожары.
Ну и Ускорение 3. Правильное использование ресурсов. У нас есть большое портфолио разного функционала. Пришел человек с запросом интегрировать CDEK – значит, программистом на проекте будет сотрудник, который делал такую интеграцию уже как минимум 1 раз.
Алиса в стране чудес или галлюцинации на старте проекта: как найти истину
Мы никогда не верим заказчику сразу. Для его же блага, разумеется. Часто бывает такое, что первичный запрос трансформируется вообще во что-то другое. Благодаря этому вы получаете инструмент, который правда поможет достичь поставленных бизнес-целей, а не просто красивый сайт.
Да, мы будем задавать много вопросов, дотошничать, может быть где-то даже спорить. Если бы мы соглашались с каждым “хочу”, клиентов бы у нас уже не было.
"Потому что ценность в честном экспертном подходе, а не желании что-то кому-то вылизать, лишь бы денег дали."
Сорри за жесткость, но в этом наша сила, а свидетельство тому крутые проекты и счастливые заказчики.
Понятно, что спор ради того, чтобы просто отстоять свое мнение, потому что “мы ж крутые эксперты, а вы ниче не понимаете” – это тоже проигрышная стратегия. Во всех переговорах наша цель – докопаться до истины. Потому что:
На этом пути самурая главный инструмент – качественный брифинг заказчика. Вот пара советов, как совместными усилиями выудить ту самую задачу, которая затем пойдет в реализацию:
Тщательная подготовка к брифингу = половина успеха. Да, надо собрать инфу по бизнесу заказчика, изучить рынок, посмотреть текущий сайт (если есть) и т.д. Потом уже накидать список вопросов и отправить его заранее до встречи, чтобы заказчик мог подготовиться;
Всегда начинаем общение с целей. Зачем бизнесу сайт? “Чтоб продавал” – плохой ответ, копаем глубже;
Дальше стараемся понять мотивы того ЛПР, с которым общаемся. Его личные KPI в добавок к тем целям, которые есть у бизнеса.
А потом уже обсуждаем все детали: какая функциональность нужна, какие странички-кнопочки можем предложить.
Итог качественного общения – понятные сроки и бюджет проекта, а еще снижение стоимости владения сайтом, потому что сразу нужную задачу закрываем. Не надо будет потом все переделывать или как-то внепланово дорабатывать.
Очень живой пример одного из текущих проектов. Запрос на входе был следующий: “Нам нужен аналог HH.ru только для определенной категории работодателей и соискателей”. Ну, казалось бы, проще не бывает. Человек знает, что хочет, да еще и пример конкретный перед глазами, сами пользуемся.
Но опыт говорит о другом. “Хочу, чтобы было как HH” может значить, что хедер сайта нравится или картинки на слайдере супер. Буквально так, а остальное может вообще отличаться, потому что цель у проекта другая, отличная от целей HH…
Смотрите, что в итоге будет реализовано:
Тендерная площадка, где продюсеры массовых мероприятий могут разместить задание для большого количества исполнителей, которые вместе могут провести шикарный фестиваль или симпозиум для бизнесменов. И у каждого осветителя, звукача, кейтеринга должна быть история успешных проектов, внутренний и внешний рейтинг, нужны несколько ЛК и возможность внутренней коммуникации не только между заказчиком и подрядчиком, но и внутри команды.
Разве это HH.ru ? Вот-вот. Представляете, что было бы, если бы мы реально начали пилить второй HH (подсказываем: проект бы пошел по п****, потому что пришлось бы в итоге все переделывать под всеобщий мат). Хорошо, что мы докопались до истины, продумали за заказчика упущенные бизнес-процессы и в итоге шикарный проект очень скоро будет на проде.
Про команду с прямыми руками
Есть у нас одна фишка, которая помогает отвечать за качество и сроки проектов. Заключается она в том, что мы никогда не передаем свои проекты на подряд. Никакого аутстафа, только внутренняя команда, только хардкор.
Когда специалисты сработались друг с другом и уже знают, что от кого можно ожидать, это снижает риски провала в разы. Да, мы всегда тратим кучу ресурсов на поиск самородков, которые останутся у нас на корабле надолго, но зато нам так спокойнее. И заказчикам тоже, потому что они знают, что их проект не спихнут на непроверенных людей.
Резюмируя все вышесказанное. За время работы мы стали настоящими стресс-спасателями проектов на Битрикс, так что просто знайте: если со сроками пи**ц, 365 Media Group – молодец. Приносите свои проекты к нам на реанимацию.
_________________________________________________
Ой кстати, если кто-то хочет работать в классной компании и этот кто-то ответственный человек, ориентированный делать свою работу очень хорошо и с энтузиазмом, то вот у нас тут вакансии есть.
С сайтами вечно такая ерунда. Каждый заказчик пытается дать правки дизайнеру (блин сеньор, с огромным опытом). Вот ты же не стоишь над душой у хирурга конда он тебя оперирует или у автомеханика, когда твое ведро чинит. А тут правочки. На входе нужно продавать экспертизу иногда безапелляционную.
Работа хирурга и работа дизайнера это все-таки разное и не сравнимое, но все же в этом что-то есть. Мне кажется это ваша ошибка, вы должны выстраивать клиенту правила поведения, а не он вам!
"Потому что ценность в честном экспертном подходе, а не желании что-то кому-то вылизать, лишь бы денег дали." - повешу в рамку, пожалуй)))
Классная статья, спасибо за полезный материал! :)
Изрядный вопрос заказчиков - хочу много, денег мало, надо быстро. Как им грамотно отвечаете? Как обрабатываете возражения?
Другая ситуация. Делаете проект, все классно, но за некоторое время понимаете, что не успеете в срок, оказалось сложнее, дольше и т.п - что в этом случае , как работаете с заказчиком?
Ну если факапим, то правильное решение как можно раньше (когда заметил, что не справляемся) сказать честно, прямо и не юлить. Обычно все всё понимают и относятся не так плохо как ожидается. Но тебя будут считать честным и ответственным.
Мы никогда не верим заказчику сразу. Для его же блага, разумеется. Часто бывает такое, что первичный запрос трансформируется вообще во что-то другое.-заказчик не всегда в курсе всех тонкостей и его нужно направить
Все верно. Но есть заказчики, которые думают, что точно знают, что хотят, а на самом деле это не всегда так. Тут больше про них идет речь