Rocket Firm

Проекты и задачи с неясным статусом

rocketfirm — Thu, 11 Jul 2019 03:57:46 GMT

Успех проектов напрямую зависит от степени взаимопонимания. Продвинутые менеджеры знают, что пока клиента информируют о происходящем — уровень напряженности в работе минимален. Когда человек знает, что происходит и чего ждать в ближайшем будущем — он спокоен.
Это правило применимо и к команде проекта. Старайтесь придерживаться принципа горизонтального взаимодействия: дизайнер помнит о программисте, программист о тестировщике, менеджер — о всех. Учитывайте, что коллега планирует нагрузку с учетом открытых задач, и неизвестность усложняет его работу.

Запомнить легко — всегда держи коллег в курсе

Команда сдала работу, а клиент уехал в отпуск? Напишите об этом в карточке проекта/задачи. Получил задачу, но не готов приступить? Пометь в задаче, когда сможешь ею заняться. Всегда отмечайте, почему задача «повисла в воздухе».

хороший пример

Дизайнер заглянул на два шага вперед: позаботился о менеджере, который будет контактировать с технарями клиента, и о самих технарях, которые будут работать с его исходниками.

плохой пример

Прошел месяц после отправки выполненной работы, а задача висит без комментария по поводу фидбэка от клиента.

худший пример

Закрытая задача без объяснений.

Весь процесс «делания» по проекту контролирует менеджер. Именно он в ответе за открытые задачи — карточки. Но ответственность за срок выполнения и уровень реагирования всегда несет исполнитель!

Работа с замечаниями клиента

rocketfirm — Thu, 11 Jul 2019 03:54:12 GMT

Это отдельный процесс, требующий особого внимания и подхода. Почти всегда дизайнер относится к замечаниям о макетах негативно — это защитная реакция. Потому что он делал макет неделю и ему он нравится, а тут кто-то проситпеределать.

Но ясно же, что не прислушиваться к замечаниям клиента — глупо. Это если бы вы заказали капучино с карамелью, а вам бы её не положили, просто потому что бариста считает, что карамель — для слабаков. В результате ничего кроме испорченных отношений не будет.

Вообще клиент всегда хочет улучшить проект, ведь это в его интересах, но ему нужно помочь, потому что не всем всегда удаётся правильно донести свои переживания и озабоченность.

Из нашего опыта, существует 2 типа замечаний: замечания-проблемы и замечания-решения.

Замечание-решение

«Сделайте слайдер на главной поменьше в 2 раза».

Клиент в своей голове уже придумал за дизайнера решение и приказывает исполнить его. Это происходит автоматически и большинство заказчиков делают именно так. Здесь важно выяснить: что беспокоит клиента, чего он боится, где видит проблему. В нашем примере скорее всего клиент боится, что какую-то важную информацию ниже слайдера не увидят — недоскроллят до нее. Если так, то решений куча: поменять блоки местами; убрать слайдер, если он мешает; поменять концепцию главной страницы и т.д.

Но проблема может быть и в другом, это нужно выяснить. Возможно клиент просто увидел сайт успешного конкурента, где слайдер был поменьше. И не факт, что решение клиента «уменьшить блок» спасет положение, может быть станет еще хуже. Для дизайнера обычно легко вносить замечания-решения, но делать это, не понимая какую цель преследует клиент, как минимум неправильно.

Замечание-проблема

«На главной для нас важен блок проектов, а сейчас он очень скромен и незаметен, что можно сделать?».

Вот это супер-замечание, сразу понятен приоритет и сразу куча решений в голове: переместить вверх, увеличить заголовки, подобрать красочную иллюстрацию, а если проекты главные на сайте по смыслу, то вообще в шапке на главной их пустить. То есть клиент рассказал о своем беспокойстве и спрашивает, как будет лучше.

Нам нужно превращать замечания-решения в замечания-проблемы. Не слепо делать то, что придумал клиент, а узнать чего он хочет добиться/какую проблему решить, разобраться и предложить решение. Тогда всем будет легче работать и шансы успеха проекта возрастут.

Как превратить замечание-решение в замечание-проблему
Чтобы из замечания-решения получилась замечание-проблема, нужно задавать вопросы.

— Сделайте слайдер на главной поменьше в 2 раза.
— Почему?
— Тогда освободится место под ним.
— Зачем нужно место под ним?
— Чтобы новости было лучше видно, чтобы человек видел, что ниже еще что-то есть.
— Хорошо. Значит, задача в том, чтобы дать понять посетителю, что сайт не заканчивается на слайдере.

В этот момент обнаруживается проблема. И именно её и будем решать. А не уменьшать слайдер в два раза.

К слову сказать, проблема может быть вовсе прозаичной — человеку просто не нравится наше решение, но из вежливости он пытается найти этому объективное обоснование. Это тоже нормально, клиент заказывает проект для себя и является принимающей стороной. В таком случае не надо терроризировать человека вопросами, а убедиться в том, что вы понимаете задачу. А потом предложить новое
решение.

Автор статьи: Дмитрий Цай

Методы нечеткого поиска в SQL: Расстояние Левенштейна

rocketfirm — Mon, 25 Feb 2019 07:50:46 GMT

В одном из проектов, работающих внутри TheFroot, запилили любопытную штуку – нечеткий поиск в SQL посредством расстояния Левенштейна. В статье, за совместным авторством Виталия Прохоненкова и Виталия Тарасенко, рассказываем о том, что это и как с этим жить.

Магазин Froot

Это маркетплейс, где один товар могут продавать десяток продавцов, выставляя разную стоимость. Подробнее о проектах Froot в портфолио rocketfirm.com.

Товар в базу данных магазина продавец передает через XML или через API. Продавец указывает, как называется товар, сколько его штук и сколько он стоит — все из его базы данных товаров. С количеством и стоимостью товара никаких проблем нет — бери себе, складывай в соответствующие ячейки SQL и выводи после на сайте. Проблема появилась с названиями.

Чаще всего продавец уже продает товары через свой сервис — то есть, у него есть своя система названий товаров, которую он под нас менять не будет (это время, деньги и лень). Имеем проблему: товар под названием “iPhone X серый 256 гигабайт” и “iPhone X 256 Gray”, попав в нашу базу, не найдут друг друга и станут двумя разными товарами. Если таких продавцов 10, и у каждого свое название (не говоря об ошибках в названиях), это не сделает хорошо ни нам, ни покупателям.

В многих маркетах эту проблему решают просто: сидит специально обученный человек и совмещает это все руками. Пришел к нему “iPhone X Grey 256 retina”, он его заботливо добавляет к “iPhone X 256Gb Gray”. У клиента таких ресурсов не оказалось, но подвернулся интересный инструмент — расстояние Левенштейна.

Расстояние Левенштейна

Расстояние Левенштейна — алгоритм нечеткого поиска. С помощью “расстояния” есть возможность находить соответствие между записями, которые в базе данных выглядят по-разному. Использование этого алгоритма позволяет находить слова и фразы в которых сделали опечатку или написал английское слово русскими буквами. После нахождения сравниваем названия с теми, что у нас есть в базе данных, и руками добавлять товар к товару не нужно.

Точность и вариативность алгоритма повышает использование метафонов (сравнивать можно и обычные строковые данные). Метафон – альтернативное название любой строки/слова/фразы. Метафоны бывают только латинскими, потому перед сравнением происходит транслитерация.

Например, в базе есть товар "Мобильный телефон Nokia 105 DS 2017 Blue". Его метафон будет примерно равен MBLNTELEFONNOK105DS. Если метафон фразы, на основании которой мы ищем поиск совпадет или похож (при соблюдении заданных ограничений), система примет два товара за один.

Минус “Левенштейна”, что если у случайного товара окажется похожий метафон, он добавится не к своей записи. То есть, применять расстояние Левенштейна бессмысленно, когда товар называется S3 (подразумевая Samsung S3), ибо точно найдется что-то другое, что на сто процентов будет совпадать по названию, но не будет являтся Самсунгом S3. Риск легко реализуется, увидь вы, как изгаляются с названиями продавцы.

Скрипт можно настроить, указав, насколько жестким должно быть сравнение – настраиваем количество символов, которые могут не соответствовать друг другу.

На практике, это работает так:

Ищем "Мобильный телефон Nokia 105 DS 2017 Blue"