В попередній статті поділився чому саме в липні 2022 ми вирішили запускати SELECT — сервіс з продажу квартир, що заробляє лише коли угода заключена. Ключові фішки сервісу — 3D-тури, якісна інформація про апартаменти та чудовий сервіс, що супроводжує покупця всім шляхом.

В це складно повірити, однак для запуску бізнесу з продажу квартир, в першу чергу були потрібні квартири, які будемо продавати. Причому для старту потрібно було знайти та залучити не менше 20 таких.

Ассортимент можна було взяти в кінцевих продавців, однак ми зосередилися на роботі з партнерами — брокерами, які допомагають продавцям. Так було безпечніше одразу з кількох бізнесових причин.

Головний виклик на цьому шляху — знайти перших партнерів, які готові сміливо вписатися в іноваційну історію. Це саме по собі непросто, оскільки рієлтори, в масі своїй, вельми консервативні та покладаються тільки на перевірені інструменти.

Ба більше — на той момент ми ще не мали продукту на проді, що робило задачу складнішою за підрахунок факапів Ілона Маска.

В цьому нам допомогла CRM, яку впровадили на базі Notion, однак спершу поділюся деталями процесу аутріча, щоб стало зрозуміло, як ми дійшли саме до такої системи.

Шерше ля рієлтор

Говорячі про бізнес-девелопмент, наш аутріч виглядав як воронка з кількох етапів залучення нових брокерів. Потрібно було збудувати машину з перетворення незнайомців в партнерів з чудовими стосунками.

Запорука успішної конверсії — якість вхідних лідів. Не можна розраховувати на пісні Queen, якщо на вході у вас мелодії з концерту Поплавського.

Для себе ми виділили два джерела потенційних партнерів з квартирами — вхідні заявки з лендінгу сервісу та проактивний аутріч хороших брокерів. Перший не зіграв вагомої ролі, а от другий розберемо детально.

Занурившись в Rieltor.ua, що входить в холдінг ЛУН, ми знайшли сотні файних брокерів з цікавими для нас квартирами. Цей сервіс ретельно перевіряє всі дані про рієлторів та зберігає їх історію та відгуки, що стало в нагоді.

Спершу ми просто пройшлися сайтом, як звичайні користувачі, однак швидко зрозуміли, що це не дозволяє рухатися швидко. Домовившись з командою Rieltor, ми почали вивантажувати потрібну нам інформацію з їх бази даних напряму, формуючи цікаві нам вибірки.

Знайшовши всіх рієлторів з перевіреними даними, які мають квартири, що потенційно нам підходять, усвідомили, що таких набралося кілька тисяч.

Ми не змогли б зконтактувати з усіма ними при всьому бажанні.

Ой.

Довелося хардкорно пріоритезувати

Якщо не вдаватися в деталі, спершу ми лишили в переліку лише брокерів, які публічно вказали, що готові ділитися комісією. Однак таких все одно лишилося близько тисячі.

Потрібно було пріоритезувати глибше, тому застосували скорінгову модель, за допомогою якої оцінювали кількість якісних квартир в портфоліо брокерів.

Для побудови моделі спершу довелося на власні очі ретельно продивитися кожну з більше тисячі квартир, щоб лишити тільки з якісним ремонтом, файною локацією та в новобудовах. Навалившись всією командою упродовж двох днів спромоглися все проаналізувати та відсіяли зайве — це, авжеж, не перегляд фільмів Томмі Вайсо, але мозок поплив.

Кількасот квартир, що залишилися в переліку, розподілили на квартілі по вартості за квадрат, та в першу чергу зконцентрувалися на другому та третьому, оскільки очікували, що більш дешевші якісні квартири продаватимуться швидше за дорожчі. Однак зовсім дешеві брати не могли, бо з такими не сходилася економіка через інвестиції в підготовку контенту.

В майбутньому ми проводили такий аналіз раз на тиждень-два, тому великою мірою автоматизували весь цей процес за допомогою скриптів та формул Notion.

В кінцевому рахунку ми відібрали першу сотню брокерів, кожен з яких вів якнайбільше цікавих нам квартир. Тепер лишилося найпростіше (сарказм) — перетворити їх на десятки партнерів, познайомивши з сервісом та вибудувавши з ними файні стосунки.

Силами однієї менеджерки по роботі з партнерами.

Ой №2.

Поціновувачі вузьких воронок

Щоб витиснути максимум з можливого, в першу чергу систематизували наші підхід до перших контактів. Спроектували скрипт для дзвінку, що містив набір тез, які хотіли донести в розмові з потенційним партнером.

1. Телефонували, щоб зацікавити. Всі рієлтори добре знають ЛУН, тому здебільшого тут проблем не виникало.
2. Презентували сервіс. Спершу спробували зробити це онлайн, однак швидко зрозуміли, що тут потрібен особистий контакт, тому почали зустрічатися з брокерами наживо.
3. Отримували першу квартиру. Після того наші юристи перевіряли квартиру та власника в реестрах, отримували підтвердження ексклюзивності в брокера, робили 3D-зйомку та збирали всю інформацію.
4. Отримували другу, третю й так далі квартиру.

А потім зіткнули пілотний процес з безсердечною реальністю.

Швидко зрозуміли, що така ідеалістична картинка не відповідає реальному процесу аутріча, тому розширили воронку:

1. Перша розмова не завжди відбувалася одразу. Доволі часто не могли дотелефонуватися, що доволі дивно, враховуючи особливості професії рієлтора.
2. Навіть коли на тому боці слухавку брали, часто з’ясовувалося, що прямо в цей момент потенційному партнеру незручно виділити кілька хвилин для розмови.
3. Багатьом сервіс подобався, але не було можливості одразу надати нам квартиру на продаж.
4. Презентації спершу тре було запланувати, а потім провести. В проміжку між цима подіями могло відбутися багато чого.
5. Між домовленістю про квартиру та виїздом знімальної групи був помітний лаг часу.
6. Часом квартири не проходили перевірку. Наприклад, пару разів нам пропонували арештовані судом апартаменти.
7. Інколи запропоновані партнером квартири нам не підходили, з різних причин.

Окрім покращення процесу, зіткнулися з неоптимальністю нашого пілотного скрипту, тому в новій версії скоротили тривалість розмови-знайомства в три рази — з 20 хвилин до 7.

Як результат — менеджер по роботі з партнерами проводить вп’ятеро більше потенційних партнерів якомога далі по етапах воронки за той же ж час. Оскільки ми говоримо про спілкування з людьми, робота настільки ж творча, як збір напарників в Mass Effect.

CRM у Notion за кілька кліків

Для системного розвитку стосунків з партнерами недостатньо було папірців та гугл-таблиць. Потрібно було впровадити та постійно покращувати інструменти, що реально допомагають працювати ефективніше, а підходи, що не допомагають — безжалісно відкидати.

Для початку створили картотеку партнерів — спершу база даних виглядала як банальна таблиця з купою потенційних лідів, холодних наче шашлик 1 січня.

Заповнили інформацією картку кожного. Тут нам допоміг імпорт даних в Notion прямо з CSV-файла, що ми експортували з бази даних Rieltor.ua.

Як справжні адепти канбану, створили дошку, де кожен етап воронки мав окремий стовпчик. Вивели на неї всю необхідну інформацію, щоб одним поглядом можна було оцінити прогрес.

Оскільки нас цікавить результат, а не процес, кожен стовпчик це саме агрегатний стан ліда, а робота відбувається між стовпчиками. Якщо лід в стовпчику «Презентували», це означає, що презентацію ми вже провели, однак квартиру поки не отримали. З одного боку, це давало розуміння де ми знаходимося, а з іншого — що потрібно робити далі.

Для вибудови якісних стосунків важливо вести таймлайн всіх контактів та їх результатів — всю історію по кожному з партнерів втримати в голові неможливо.

Після кожної розмови пробували вносити резюме в тіло-опис об’єкту, але це було незручно, бо доводилося костилити дати та запарюватися з редагуванням. Замість того почали вносити резюме розмов в коментарях до кожної картки партнера:

1. В них є чітка дата та час.
2. Свіжі записи були згори, що дозволяло швидко відновлювати в пам’яті на чому зупинилися в спілкуванні з конкретним рієлтором.
3. Важливо було не забувати записувати інформацію одразу після розмови, інакше ідея з таймлайном працювала так собі.
4. Можна було прямо там в коментарях заодно й обговорити результати якоїсь з розмов. Зручно.

Потенційних партнерів багато, а менеджерка по роботі з ними лише одна (Дар’юшко, обіймаю), тому виникла потреба ефективно організувати всі ці дзвінки та презентації, втримавши кукуху. Потрібен був календар.

Щоб його створити, ми доповнили картки партнерів властивостями, що містили дату та час наступного дзвінку, і тим самим для презентацій.

Після того створили в’юху-календар, куди вивели всі минулі та заплановані дзвінки та презентації. Завдяки цьому можна було легко регулювати навантаження менеджера та чітко знати з якими партнерами, в якій послідовності, з приводу чого потрібно поговорити, щоб провести їх по воронці.

Ба більше — кожному запису в календарі також налаштували нагадування, які приходили сповіщеннями з додатку Notion на телефоні.

Згодом допрацювали ще кілька нюансів:

1. Розділили календарі дзвінків та презентацій. На практиці це виявилося зручніше, оскільки ці два процеси помітно відрізняються.
2. Змінили сортування в переліку та на борді, щоб згори були партнери з найбільшою кількістю цікавих нам квартир.
3. Доповнили кожну картку теплотою контакту — важливо знати, на якій ноті завершилося попереднє спілкування, щоб зосередитися на тих, хто прийняв нас з відкритими обіймами та не заважати, якщо навпаки.
4. Фільтранули з переліку та на борді всіх брокерів з якими не змогли домовитися з різних причин. Тобто прибрали записи одночасно по статусах та теплоті контакту.
5. Вивели в картку партнера цікаві нам квартири, щоб не довелося розшукувати інформацію про них на дошках оголошень.
6. Замінили складні скорінг-формули простою властивістю пріоритетності від кількості цікавих нам квартир.
7. За допомогою rollup-властивостей вивели всі квартири партнера, що продавалися, або продаються прямо в картку. Разом з поточним статусом, щоб можна було швидко дізнатися «як справи» в кожного з них.

Чудо вдалося здійснити — ми залучили 15 перших сміливих партнерів з файними квартирами, в той момент, коли наш сервіс існував лише як презентація на 10 слайдів. Це додавало імпульсу всій команді, що й дозволило запустити перших потенційних покупців вже за місяць з моменту початку роботи над SELECT.

Однак, щоб це стало реальністю, спершу потрібно було виїхати на всі квартири від цих брокерів, зібрати по них всю інформацію та відзняти 3D-тури. Наступного разу поговоримо про управління контентом сайту, та як ми збудували CMS на базі Notion.

Бережіть себе та близьких ❤️

До зустрічі.

В липні 2022 року, прямо в розпал війни, ми в ЛУН запустили стартап в Україні. Причому першу цінну версію доставили на прод за 20 робочіх днів.

Ви можете вирішити, що ми поїхали кукухою (не без цього), однак хотіли швидко перевірити іноваційну для цифрових продуктів бізнес-модель, про яку всі мріють, однак бояться наче Олега Вінника.

Outcome-based, Transaction model, Ended value monetization — в неї купа назв, але суть в тому, щоб брати гроші лише коли користувач отримує кінцеву цінність. Якщо це рекрутмент — то після найму та проходження випробувального періоду (привіт Djinni). А якщо мова про нерухомість — за факт продажу або оренди (привіт Bird).

Даруйте, а до чого тут війна?

Щоб перевірити життєздатність моделі, потрібно поставити її в заздалегідь складні обставини. Перевіривши в тепличних умовах, завжди буде спокуса сказати «просто ринок бурхливо зростав сам по собі — бізнес-модель тут ні до чого».

Ба більше — коли все гаразд, і попередня модель працює передбачувано, всі стараються нічого не чіпати, а до можливих експериментів ставляться наче собаки-підозрюваки. Страшно зламати старе й не збудувати краще нове.

Ринок під час кризи — ідеальний полігон перевірки радикальних ідей, оскільки умови недружні, а попередні бізнес-моделі страждають. Нічого втрачати, chaos is a ladder, оце все.

Для перевірки нової бізнес-моделі ми в ЛУН запустили SELECT — сервіс з продажу квартир в Києві. Його основна фішка — повністю інтерактивні 3D-тури, які дозволяли погуляти по цікавій квартирі з компа чи мобільника, а також кльовий сервіс з персональним менеджером, який проведе потенційного покупця за ручку упродовж всього процесу.

Якщо допоможемо продати кілька квартир в Києві — запевнимося в життєздатності моделі сплати за результат і підготуємося до повномасштабного запуску після завершення війни.

Запустили першу цінну версію SELECT менше ніж за місяць

Швидко визначилися де брати квартири (запартнерилися зі сміливими брокерами) та потенційних покупців (трафік з Flatfy), а інженери показали чудеса бутстрепінгу з мінімальною кількістю костилів та скотча.

Однак згодом на нас очікувала прірва операційки, причому офлайнової:

1. Комусь потрібно виїздити на квартири, щоб відзнімати їх на спеціальну 3D-камеру від Matterport, заповнювати весь вміст та особливості апартаментів (Танюш, Марин, низький уклін);
2. Хтось мав приймати й обробляти вхідні заявки на огляди квартир наживо та цінові пропозиції;
3. А ще тре було виїздити на огляди цих квартир наживо з потенційними покупцями;
4. Не кажучи вже про залучення нових партнерів та налагодження стосунків з існуючими заради нових квартир (Дашунь, ти просто монстр).

На аутсорс таке не віддати, оскільки якісний збір інформації та високий рівень сервісу — основні фічі SELECT.

Щоб ефективно виконувати одноманітну офлайнову роботу та втримати кукуху, важливо було створити чудовий бекофіс, що нівеллював би більшу частину рутини.

А дупа не злипнеться?

Оскільки ми говоримо про стартап, розробляти десяток адмінок власноруч — не варіант. На борту лише 3 фул-стек інженери (Нікіто, Катюшо, Ярічек, люблю вас), які мають розробити ВЗАГАЛІ ВСЕ з абсолютного нуля, а створення бекофісу займає стільки ж часу, скільки потрібно для підрахунку всіх скандалів шоу Холостяк — майже безкінечність. Особливо враховуючи те, що цей шлях зазвичай веде до незручних в користуванні монстрів — ви точно бачили такі на власні очі.

Важливо було створити бекофіс для керування новим цифровим бізнесом майже безкоштовно й максимально швидко. Причому потрібен був інструмент, який ми могли би використати для зберігання всіх даних й керувати ними в реальному часі.

Причому робота з даними має відбуватися прямо з телефону — знімальна група буде, не повірите, на зйомках 3D-турів квартир, персональні менеджери на показах квартир наживо потенційним покупцям, а менеджер по роботі з партнерами взагалі не злізає з мобільника — домовляється з партнерами, оце так сюрприз.

Дешево, швидко, надійно та ще й з файним мобільним інтерфейсом.

Це був удар.

Неочевидні рішення

Кілька днів крутив в голові традиційні варіанти — всі з блокуючими недоліками. Певного моменту спала думка — гей, а чому не використати готовий сервіс по роботі з документами та даними — наприклад Airtable, Coda чи Notion:

1. В них непогане API;
2. Там можна зберігати великі масиви інформації;
3. Є управління доступами;
4. Мають залізобетонний аптайм.

Дослідивши всі ці сервіси, усвідомив, що Notion імпонує найбільше — команда вже має досвід роботи з сервісом, він гнучкий, може в групову роботу над одним документом в реальному часі, приємний повнофункціональний мобільний інтерфейс та дружнє API для майбутньої інтеграції.

Команда ідею підтримала, а після ретельного аналізу та серії уроків з помилок, ми вирішили використовувати Notion як CRM, CMS, для обробки вхідних заявок, а також як таск-трекер та базу знань для команди. One tool to rule them all!

Ба більше, наш сайт був нескладним — каталог квартир з можливістю записатися на огляд апартаментів наживо та запропонувати свою ціну, якщо все сподобалося. Все ж, основний двіж відбувався в офлайні та на бекофісі, а ззовні користувачі бачили лише вітрину.

Тому дійшли висновку, що Notion можна використати не тільки в якості бекофісу всіх внутрішніх процесів, але також і в якості бази даних на проді:

1. Контент подекуди змінювали, однак нечасто.
2. Унікальних користувацьких даних (типу «обраного» чи особистої статистики) не було.
3. Мільйонів відвідувачів на день з 1 000 RPS не очікували.

Використання Notion в якості сховища зекономило нам прірву часу не тільки за рахунок нерозробки бекофісу, а ще й тому, що не довелося проектувати та розгортати власну БД, якою б нескладною вона не була. Справедливості заради, це вимагало інвестицій часу в більш глибоку інтеграцію з API Notion, однак ми вважали, воно того вартувало.

Notion як сховище даних для проду?

Справа в тому, що Notion має на борту не тільки інструменти для текстових матеріалів, різноманітних таблиць чи чеклістів — він вміє в повноцінні бази даних.

Ці сховища архітектурно сильно нагадують реляційні, підозрюю, саме умовний PostgreSQL лежить під їх капотом в Notion. Ось кілька речей, які вони вміють:

1. Створювати різні таблиці для різних об’єктів. В нашому випадку була таблиця з партнерами, квартирами, заявками, покупцями і так далі.
2. Всі ці об’єкти містять в собі довільний набір властивостей з різними типами значень — текст, зображення, лінк, число, масив, або навіть зв’язок-посилання на іншу сутність. Так, наприклад, об’єкт партнери містив в собі властивість «квартири», куди складаються ID квартир, які він виставив на продаж. В об’єкті «квартира», відповідно, була зворотня властивість «партнер» з ID-посиланням на картку рієлтора.
3. в кожній сутності може міститися майже безкінечна кількість властивостей, про що детальніше розповім в майбутній статті про управління контентом сайту.
4. В кілька кліків можна налаштувати будь-яку потрібну в’юшку, застосувавши комбінацію фільтрів зі складною логікою, сортувань, групувань і так далі.
5. Можна об‘єднувати дані з різних таблиць в одну. Джойнити не переджойнити.
6. Базу можна візуалізувати як у вигляді банальної таблиці, так і у вигляді борда чи навіть календаря.

Корисно, гнучко та зручно. І це все без жодного рядка коду та SQL-запитів.

Бази даних в Notion надають значно більше різноманітних плюшок, однак якщо розповідати про кожну, то статтю не можна буде назвати навіть лонгрідом.

Поділюся всім цим господарством корисностей в наступних статтях циклу.

Кілька квартир ми продати допомогли, життєздатність бізнес-моделі сплати за кінцеву цінність успішно перевірили.

А от з якими плюсами, мінусами та підводним камінням Notion в ролі ядра бізнесу ми зіткнулися на цьому шляху, як саме все було організовано та працювало — поділюся в наступних частинах.

Продовження — «Перші клієнти до релізу» про CRM та вибудову стосунків із партнерами.

Бережіть себе та близьких ❤️

До зустрічі.

Поскольку суперменом я не вышел, пришлось научиться нескольким финтам, помогающим вести дела. Надеюсь, они помогут и вам.

Начнём с управления задачами. Знаю, вы только что вздохнули — «о боже, очередная система таск менеджмента!». Спешу обрадовать (а кого-то огорчить) — не претендую на лавры GTD, Скрама, Канбана или других прекрасных методологий. Речь о нескольких простых правилах, которые для меня отлично работают и дополняют любую систему, которой придерживаюсь.

Следует понимать, что вещи ниже работают для меня в сложившихся обстоятельствах.

Не изобретал серебрянную пулю, которая поможет каждому в любом деле. Но для начала погружу вас в контекст.

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

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

Наш горизонт планирования — пол года. Именно на шесть месяцев вперёд поддерживаю стратегию развития нашей платформы. Обозначаю её широкими мазками, детали могут меняться, однако в целом стратегия помогает всем понимать, куда продвигаемся следующее полугодие. Каждый месяц план пересматриваю, порой обстоятельства требуют свернуть в другую сторону, хотя чаще этого не требуется.

Стратегия отвечает на простой вопрос.

Где мы должны оказаться спустя пол года?

Потребуется немного воображения, однако ответить на этот вопрос может каждый. Главное, чтобы ответ был конкретным, а не «за всё хорошее, против всего плохого».

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

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

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

Из этих проектов сформировал простую дорожную карту. Этот roadmap и олицетворяет полугодичную стратегию развития Платформы, которая в свою очередь вписывается в долгосрочную двух-трёхлетнюю стратегию компании.

Что приблизит нас к цели за следующий месяц

Это уже тактика, смысл которой в ответе на вопрос — как именно мы будем идти к нашей полугодичной цели.

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

Я визуал, мне легче всего оперировать образами. Потому для организации задач использую колонки, между которыми перетаскиваю карточки. Прямо как в Канбане.

Для этого использую Trello с несколькими усилителями. Бесплатной версии мне полностью хватает.

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

Самое главное — не забывать записывать. Потому установил приложения Trello на все устройства — от рабочего ноутбука до личного телефона, чтобы задачи были под рукой. Через некоторое время выработал привычку и довёл её до автоматизма.

Порой с удивлением обнаруживаю карточки, которые не помню когда записал. Лучший показатель, что цель привычки достигнута.

На чём сфокусирована неделя

Это своеобразный план на неделю. Оперативная очередь или беклог спринта, если выражаться в терминах Скрама. Заполняю его карточками в пятницу вечером или утром понедельника.

Обычно беру в оборот несколько больших задач и ворох маленьких. Однако важно не переусердствовать и не забивать всё под завязку. Должен оставаться запас на непредвиденное. В работе менеджера продуктов чёрные лебеди летают клиньями.

Стараюсь в рамках одной недели заниматься лишь одной точкой приложения усилий из месячного плана. Фокус — король.

Чем заниматься сегодня

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

Главное — расставить всё таким образом, чтобы одновременно заниматься только одной задачей. К сожалению, люди не многозадачны и переключение между несколькими — один из самых раздражающих пожирателей времени. И, пожалуй, самый коварный.

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

Но что происходит, если задача требует усилий нескольких людей и свою часть вы сделали, а остальные ещё нет?

Что под контролем

Эта колонка — своеобразное чистилище для задач. В ней обитают все, которые требуют фонового внимания и периодического пинга.

Например, поручил кому-то какую-то задачу, и чтобы о ней не забыть, оставил в колонке «Контроль». Она позволяет разгрузить память и не беспокоится о том, что можешь забыть о каком-то поручении.

То же самое с делегироваными задачами, или теми, которые ожидают действий других людей, несмотря на то, что свою часть вроде как завершил. Главный принцип — задача не готова и не может двинуться дальше, если результат не достигнут.

Завершённые задачи

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

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

Архивированные задачи из Trello никуда не исчезают, к ним всегда можно вернуться. Делаю это крайне редко, но иметь такую возможность приятно.

Few more things…

Если задача требует от меня меньше двух минут — выполняю её незамедлительно. Только так мелочи не накапливаются. Иначе через неделю найду себя погребённым неотвеченными сообщениями, письмами и неподписаными документами. Порой важными.

Название задачи сформулировано в виде результата действия. «Оплатить налоги и сдать декларацию» вместо «Начать заполнять декларацию». То есть всегда ставлю цель через результат, а не процесс. Это дисциплинирует.

Если мне нужно потратить на что-то более 15 минут, заношу в общий список дел. Там задача не потеряется и о ней не забуду в гуще сражения.

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

У меня есть несколько задач, которые требуется выполнить регулярно. Например, раз в месяц мы встречаемся с техническим директором и обсуждаем прошедший месяц. Каждый понедельник я рассказываю другим руководителям подразделений компании о том, «чем там занимаются эти разработчики». Чтобы не заниматься дурной работой, использую усилитель для Trello, который любую задачу может превратить в повторяющуюся. Они будут автоматически появляться с нужной периодичностью, настройками и в нужных колонках.

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

Задачи стараюсь декомпозировать так, чтобы каждая из них требовала не более 8 часов. Хорошо — до 4. Идеально — 25 минут, чтобы вписаться в одну помидорку. Главное не переусердствовать и не заносить совсем уж мелочи.

Мухлевать можно, но зачем? В своей практике встречал людей, вносящих в список задач пару откровенно нерелевантных пунктов, выполнение которых не требует усилий. Например «✅ Приехать в офис». Здесь можно вспомнить про знаменитую притчу про 2 из 12 чашек кофе, но мне кажется, здесь это малоприменимо.

Бонус-трек. Есть несколько задач, которые появляются и остаются в Slack. Например, Саша написал мне вопрос, но прямо сейчас занимаюсь другим. Если это рутинно и недолго, то использую встроенные в Слек напоминалки. Откладываю задачу на то время, когда мне будет удобно к ней вернуться. Бац, и вновь оперативная память мозга не забита.

Вместо резюме

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

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

Система «Пяти колонок» помогает мне освободить мозг от рутины и сосредоточиться на важном. Она дополняла любую методологию, в которой мне приходилось работать — GTD, скрам, канбан, скрамбан, канрам и так далее (последнюю я придумал, не гуглите).

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

Уверен, у вас есть интересные особенности в управлении задачами. Поделитесь ими, пожалуйста. Всегда рад узнать новые крутые штуки :)

Несколько хитростей по управлению задачами was originally published in Архів on Medium, where people are continuing the conversation by highlighting and responding to this story.

Для цього потрібно мати файний дизайн, знайомих, які здатні за пляшку віски, або гроші, перетворити статичні макети на інтерактивний сайт.

Але створенням, власне, сторінок, сайт не обмежується — бо він створюється задля якоїсь мети. Частіше за все, щоб заробляти гроші.

Щоб мати прибуток, потрібна купа відвідувачей сайту, яким він цікавий, а також грамотний контент, що мотивуватиме відвідувачів звертатися за послугами або товарами, що продаються.

І це я не кажу ще про домени, хостінг, та інші базові речі для запуску сайту.

Для непідготовленої людини це все виглядає Rocket Science — чимось екстраординарним та складним.

Ми кидаємо виклик цим складнощам. Хочемо допомогти, щоб створення сайту в людей проходило просто та кайфово.

Для цього ми будуємо місце, де власник бізнесу або веб-розробник знайде все необхідне — від шаблону дизайну до людини, яка допоможе йому зі створенням логотипу. Від SEO-шника до набору ілюстрацій. Від веб-шрифту до розробника на Go.

Гіпермаркет, де є все необхідне для легкого та швидкого створення сайту, та його запуску як частини бізнесу.

З моменту своєї появи в 2002 році, й донедавна, TM виглядав як магазин при заводі. Завод виробляв продукцію, а магазин її продавав. Магазин продавав виключно товари власного виробництва, чим всі дуже пишалися.

Ці два напрямки існували нерозривно, й абсолютно залежали один від одного. Тактично це рішення, напевно, було позитивне в минулому, але стратегічно воно призвело до поганих наслідків.

Більше року тому, керівники компанії вирішили повністю відокремити ці два напрямки, щоб вони не залежали один від одного.

Так в рамках компанії TemplateMonster з’явився окремо Завод під назвою JetImpex, який постачає товари на продаж в усі магазині, в які можливо (навіть на ThemeForest), й Магазин, який перебудовується в Гіпермаркет, й приймає товари від всіх цікавих постачальників (навіть конкурентів нашого Заводу).

Як бізнес, на разі ми знаходимося в болючому процесі розділення, й переходу на нову бізнес-модель. Це великий тектонічний зсув, який зачепляє, та викликає дискомфорт в усіх, хто звик до старої парадигми.

Наше ж з вами завдання — створити найкращу в світі систему для роботи Гіпермаркету — Платформу.
Ми не займаємося товарами, ми займаємося майданчиком, де зустрічаються люди, які хочуть створити сайт, з тими, хто може їм допомогти — порадою, послугою, сервісом або товаром.

Що таке Платформа?

Це набір інструментів, за допомогою яких функціонує наш Онлайн-Магазин, й працюватиме Гіпермаркет. Відвідувачі мають знаходити те, що шукають, покупці планують отримати свої покупки та допомогу, а наші співробітники хочуть виконувати свої повсякденні обов’язки. Постачальники, в свою чергу, мають змогу віддавати нам товари на продаж, та отримувати свою винагороду.

Новий TM можна порівняти з величезним гіпермаркетом накшталт Ocean Plaza або Епіцентру. Гіпермаркет нічого не виробляє. Його завдання — організовувати та обслуговувати інфраструктуру для продажів магазинів та постачальників, які там знаходяться.

Головна мета існування Платформи — вирішення потреб бізнесу та користувачів, як внутрішніх так і зовнішніх.

Всі її інструменти не мають залежати один від одного, але мають поєднуватися в єдиний механізм. 1+1=3.

Якщо шукати метафору, напрошується паралель з автомобілем — складним механізмом, який складається з тисяч деталів та систем. Хоча мета існування в нього прозаїчна — доставити пасажирів з точки А в точку Б.

Так і Платформа, з якою наче все просто — є постачальники, які викладають товари чи послуги, є відвідувачі, які їх шукають та купляють. Ще є співробітники TM з мільйоном своїх щоденних завдань. І є ми — майданчик для зустрічі всіх цих людей.

А під капотом в нас велика купа цікавих штук.

Хто користується Платформою

1. Відвідувачі.
   Це люди, які поки нічого не придбали, через це ми мало про них знаємо. Наша головна мета — щоб відвідувачі якомога швидше знайшли те, що шукають. Відвідувачі бувають авторизованими, або ні. Коли вони авторизовані (або були в минулому), ми знаємо про них хоча б мінімум інформації.
2. Покупці.
   Це як відвідувачі, але ми їх вже впізнаємо, бо вони в нас вже щось колись купляли. Мета Платформи — зробити так, щоб покупець зробив ще одне придбання, та залишився ним задоволений. Покупці бувають постійними (коли кількість замовлень платних товарів два та більше), або одноразовими. Перетікання з других в перших дуже важливе для бізнесу ТМ — такі покупці нам як рідні.
3. Постачальники.
   Золоті люди. Вони довіряють нам продаж своїх товарів, розраховуючи отримати солідний прибуток. Ми намагаємося надати їм таку можливість — запрошуємо відвідувачів, викладаємо товари, організовуємо продажі та виведення коштів. За це постачальники діляться з нами частиною свого прибутку.
   Вони розподіляються на внутрішніх та зовнішніх постачальників, які діють по однакових правилах:
   а) Внутрішні — це наш колишній Завод, який немає ніяких переваг перед іншими постачальниками.
   б) Зовнішні до ТМ стосунку не мають. Наша мета — щоб вони продали якомога більше, та залишилися з нами якомога довше. В ідеалі, якщо нададуть нам ексклюзивні права на продаж своїх товарів (читай — підуть з інших гіпермаркетів).
4. Співробітники ТМ.
   Тут все просто — це ми з вами (для тих, хто в танку). Ми хочемо виконувати свою роботу якісно та швидко, без нервів. Мета Платформи — надати нам всі необхідні інструменти для цього, й щоб все працювало як слід.

Що входить й не входить в Платформу

Як і автомобіль з прикладу вище, наша система доволі об’ємна. Якщо зобразити її схематично, вийде приблизно таке.

Ядром є наш сайт, який в свою чергу теж не є єдиним цілим, й ділиться на декілька окремих частин.

1. Вітрина:
   Каталоги товарів. Всі переліки по типу, категорії, фічі, та інші. Сторінки товарів з детальною інформацією, яка допомагає обрати те, що шукають наші клієнти. Основне місце знаходження всіх потенційних або існуючих покупців.
2. Кошик:
   Сюди потенційні покупці складають товари або послуги, що їм подобаються, й які вони планують придбати.
3. Чекаут:
   Місце, де проходить бізнес-магія. Тут ми приймаємо кошти від покупців найзручнішим для них шляхом.
4. Авторизація:
   Ядро системи. За допомогою неї ми впізнаємо покупців, постачальників, й співробітників та надаємо їм необхідну інформацію та доступи. Навіть модулі системи впізнають один одного тільки завдяки авторизації.
5. Кабінет Користувача:
   Тут є все необхідне для покупця — його замовлення, різноманітна корисна інформація, налаштування та додаткові можливості, які з’являються в зареестрованих користувачів. Наприклад, додавати щось в особисту колекцію та комусь її показати.
6. Кабінет Постачальника:
   Центральний елемент Гіпермаркету. Інструмент, де ми приймаємо всі товари від постачальників, перевіряємо, щоб вони були якісними та передаємо на Вітрину. Окрім цього саме тут постачальник бачить, скільки він заробив, та перетворює ці віртуальні числа в реальні гроші.
   Формально, кабінет постачальника лише є розширенням кабінету користувача.
7. Сторінка доставки:
   Тут покупці перевіряють свої замовлення після сплати, та забирають придбані товари чи послуги, разом з необхідною додатковою інформацією.

Окрім частин сайту в Платформу входить багатенько внутрішніх інструментів, головні з них:

1. Зіппер:
   Штука, яка бере купу матеріалів, та формує індивідуальний архів для покупців. Скоро ми відмовимося від Зіперу, й створимо сервіс доставки, завдання якого — знати посилання на всі необхідні матеріали по кожному товару та послузі, й зручно передати їх покупцю.
2. Мейлер:
   Внутрішній механізм надсилання листів. Листи бувають двох видів — періодичні та трігерні розсилки й транзакційні. Останні — це різноманітні (дійсно) корисні сповіщення на пошту.
   Наприклад, про успішну реєстрацію, або придбання товару.
3. Чат:
   Місце, де користувачі отримують допомогу та підтримку від наших кваліфікованих співробітників служби підтримки, або постачальників товарів.
4. Тікет-система:
   Ще одне місце для допомоги людям. Якщо чат — це інструмент оперативного спілкування, то спілкування в тікети переходить тоді, коли потрібен деякий час на вирішення проблеми, або пошук інформації. В тікеті час відповіді має менше значення, ніж в чаті.
5. Блог:
   Тут все зрозуміло. Місце для публікації різноманітної інформації для покупців та тих, хто просто проходить повз. Ми хочемо побудувати на його руїнах повноцінну спільноту веб-розробників, з крутими матеріалами, накшталт AIN або VC.ru.
6. Хелп:
   Величезний каталог статтів на різноманітну тематику, завдання яких — допомогти людям знайти рішення своєї проблеми без участі наших співробітників.
7. Афілятська система:
   В світі існують сотні тисяч людей, які хочуть мати пасивний дохід. Ми даємо їм таку можливість — якщо такі люди приводять нам покупців, ми ділимося з ними нашими прибутками.
   Відповідно, потрібна система, яка враховує всі продажі, проводить розрахунки та надає всі необхідні інструменти для цих цікавих людей. За деякий час система інтегрується в кабінет користувача, як окреме розширення по аналогії з кабінетом постачальника.
8. Промокоди:
   Внутрішня система, за допомогою якої ми надаємо та відслідковуємо всі знижки на Вітрині та Кошику. За її допомогою можна автоматично роздавати знижки за дії, проводити акції, та робити купу крутих речей для маркетингу.
9. Транзіфекс:
   Інструмент для локалізації нашого інтерфейсу. Ми постачаємо в нього рядки тексту англійською, а спеціально обучені та працівливі люди перекладають їх на всі 17 мов, які ми на разі підтримуємо — від української до китайської.
10. Банерна система:
    Ще один важливий інструмент маркетингу, за допомогою якого вони (майже) не чипляють розробників, й проводять акції, які тішать наших покупців великими знижками, обмеженими по часу.

А також всі внутрішні адмінки (яких на разі більше сотні).
З головних — ті, що керують:

1. Товарами.
2. Замовленнями.
3. Користувачами.
4. Властивостями.

У вас, напевно, вже голова обертом йде. На щастя, я не перелічував тут всього, це тільки основні речі :)

Ну добре, а що ж в Платформу не входить?

Перевірочне правило просте — якщо якась штука не потрібна саме для файної роботи Онлайн Гіпермаркету, то на 99,9% це не рахується частиною Платформи.

Наприклад, загальнобізнесові інструменти, накшталт Бітріксу24, 1С-Бухгалтерії, Jira, Confluence, Service Desk і т.д. — самому Гіпермаркету не потрібні, відповідно не є частиною Платформи.

В Платформу також не входять всі інструменти та механізми внутрішніх та зовнішніх постачальників, а також підпроектів ТМ.

Де ми зараз

По горло в технічних боргах, які накопичилися за останні 14 років.

В нас відверто фігова документація, яка до того ж, ще й організована хаоточно. Новій людині розібратися в ній доволі складно. Велика частина інформації, на жаль, застаріла.

Сам сайт, як головний елемент системи, працює значно повільніше за конкурентів (але ми вже досягли непоганих успіхів в прискоренні).

Система майже не покрита тестами — модульними, функціональними, інтеграційними і так далі. Це призводить до того, що будь яка необережна зміна може викликати каскадний ефект з багів та недоробок.

Історично склалося (ненавиджу цей вираз), що система організована як купа модулів, які тісно переплелися тентаклями між собою. Всі ці хаотичні зв’язки перетворюють систему на Моноліт, в якому важко розібратися без віски та досвідчених людей.

Але ми доволі оперативно рухаємося у світле майбутнє. Складність заключається в тому, що ми робимо це на працюючому проекті. Це як операція на сердці — складно, довго, але варте того.

Тільки від нас залежить, яким саме буде світле майбутнє TemplateMonster.

Куди ми рухаємося

Відповісти на це питання складно в рамках однієї статті, але спробую.

Ось вам невеличкий спойлер.

Будь яку систему (наша не виключення), можна розділити на фронт-офіс та бек-офіс. Перше — це те, чим користуються наші відвідувачі та покупці. Друге — інструменти для наших співробітників (читай — адмінки).

Якщо продовжити метафору з Гіпермаркетом, тоді Front Office то є вітрини та самі магазини, а Back Office — бухгалтерія, менеджмент, прийом вантажів, тощо.

Кожна з цих частин, в свою чергу, поділяється на фронтенд та бекенд. Перше — як система показується та працює в браузері користувача. А друге — як зберігаємо та обробляємо дані на сервері.

Це розділення найкращим чином демонструє влаштування автомобіля. Ззовні вона має файно виглядати та ефективно розподіляти повітря, всередені вона має тішити погляди водія та пасажирів, а для водія все керування має бути зручним. Це фронтенд.

З іншого боку, сам автомобіль, як ми знаємо, складається з купи внутрішніх систем і механізмів (від двигуна до бортового комп’ютеру), які й дозволяють насолоджуватися водію та пасажирам. Це бекенд.

Як бачите, в нас вийшло чотири квадранти, на кожному з яких я зупинюся детальніше.

Фронтенд фронт-офісу

Те що бачать наші відвідувачі та покупці в себе в браузері.

KPI (як будемо виміряти, наскільки якісна реалізація):

1. Клієнтська швидкість. Наскільки швидко сторінки відкриваються та повністю завантажуються.
2. Розширюємість інтерфейсу. Щоб раптом що, нам було легко припинити продавати шаблони, й почати торгувати автошинами, наприклад. В ідеалі, якщо інтерфейс це дозволить безболісно зробити.
3. Конверсія в придбання та реєстрації. Тут все просто — чим простіший та зручніший наш інтернет-гіпермаркет, тим краще він продає.
4. Google Page Speed Insights. Це синтетичний показник швидкості сторінок від Google. Цей пошуковик орієнтується на PSI, коли вирішує які сайти показувати вище у результатах пошуку.
5. Релевантність. Наскільки швидко відвідувачі знаходять те, за чим вони прийшли до нас на сайт. При умові, що до нас потрапляють нормальні відвідувачі, а не випадкові люди.

Особливості (як воно має працювати):

1. Миттєва реакція. Клікнув кудись — інтерфейс зреагував. Перейшов на іншу сторінку — вона миттєво відкрилася. Дивіться Elements від Envato. Це автоматично означає, що наш інтерфейс має бути «оптимістичним» — тобто таким, що показує результат дії користувача не чекаючи відповіді від сервера (яка у 99.99% випадків корректна, й займає декілька десятих долів секунди).
2. Атомарність інтерфейсу. Антиподом атомарного підходу є безконтрольне розмноження схожих елементів з невеличкими відмінностями. Наприклад, коли восени 2015 року я прийшов в TM, на сайті панували 36 червоних кнопок, кожна з яких відрізнялася висотою, кольором, градієнтом, розміром шрифта, стилем піктограм та іншми штуками. Атомарність дає можливість майже миттєво змінювати зовнішній вигляд інтерфейсу. Наприклад, перефарбувати всі блакитні кнопки в зелені, якщо виникла така потреба.
3. Адаптивність під всі пристрої. Від смартфону, до 5k-монітору. Причому адаптивність розумна — якщо людина переглядає нас зі смартфону, не потрібно їй завантажувати код, скрипти та зображення з 5k-версії для 30" retina-екранів. Приклад можна подивитися на новому сайті Smashing Magazine (на разі в беті).
4. Поведінкова адаптивність. Інтерфейс підлаштовується під користувача, в залежності від того, що ми про нього знаємо, його поведінки. Людина, яка в нас вперше, має бачити наш гіпермаркет по іншому, аніж постійний покупець, або постачальник. А покупець, який накупив в нас 10 шаблонів Joomla має всюди бачити Joomla першою — в меню, у переліках товарів, тощо.
5. SEO-Friendly. Не секрет, що наш сайт отримує трафік в основному з Google. Відповідно, ми маємо постійно шукати шляхи, як зробити Платформу ще більш дружньою для пошукових ботів, щоб Google ставив нас вище в результатах пошуку. Це накладає на нас певні обмеження, але відкриває нові можливості.
6. Області прямого редагування. В мене є мрія. Хочу, що маркетологи мали можливість легко змінювати контент на існуючих сторінках (у заздалегідь відведених місцях), або будувати нові сторінки у простому візуальному редакторі з готових елементів та блоків. Зовсім. Без. Участі. Розробників.
7. Розширюємий інтерфейс. Важливо, щоб в нас була можливість оперативно розширити асортимент товарів до мільйонів, або звузити його до одиниць. Можливо, нам доведеться радикально замінити товари, й перекваліфікуватися на продаж інших речей або послуг. Інтерфейс не має змінитися радикально. Тобто, він повинен бути достатньо ємким та нейтральним до тематики.
8. Відмовостійкість. Продукт з точки зору користувача вміє «падати» грамотно — коли не працює одна з частин системи, це стосується лише неї, вся інша частина працює корректно. Користувач, в свою чергу, отримує вичерпну інформацію про проблему та її причини.

Вигодонабувачі (кому важливо, щоб фронтенд фронт-офісу працював як слід):

1. Відвідувачі. Хочуть швидко знайти те, за чим прийшли на TM.
2. Покупці. Планують отримати допомогу з придбаним товаром, або зробити нове замовлення.
3. Постачальники. Хочуть відвантажити товар, або вивести зароблені кошти.
4. Стейкхолдери. Мають запевнитися, що їх співробітники отримують необхідні можливості в зручному вигляді, та можуть ефективно виконувати свою роботу.
5. Дизайн-інженери. Відповідальні за те, щоб все працювало швидко, зручно та якісно, а інтерфейс не викликав диссонансу.
6. Фронтенд-інженери. Працюють над тим, щоб не довелося мільйон разів перероблювати наш фронт-офіс.

Технології:

1. Декілька Single-page додатків. Лише подивіться на новий LinkedIn, й згадайте старий — різниця разюча. Деякі з додатків, де важлива індексація пошуковими ботами, реалізовані ізоморфно. Тобто так, щоб у ботів була можливість знайти контент згенерований на сервері.
2. React. Технологія від Facebook для створення веб-додатків на базі компонентного підходу за допомогою JavaScript.
3. Redux. Штука, яка робить так, щоб користувач завжди бачив актуальну інформацію в своєму веб-додатку, без зайвих завантажень сторінок.
4. Redux Form. А ця штука керує тим, щоб у формах, які заповнюють користувачі все було добре.

Фронтенд бек-офісу

Те, що бачать наші співробітники в своєму браузері.

KPI:

1. Швидкість виконання повсякденних завдань співробітником. Найголовніше, щоб наші колеги могли працювати ефективно та якісно. Для цього ми й надаємо їм відповідні інструменти. В кінцевому рахунку все зводиться до швидкості.
2. Клієнтська швидкість адмінки. Тут все просто — по аналогії з фронтендом фронт-офісу, важливо, щоб адмінка працювала максимально швидко. Оптимально — миттєво.
3. Швидкість розширення функціональності. Адмінки постійно змінюються — щось вирізається, з’являється щось нове, додаються нові розділи та купа функціональності. Все має бути спроектовано таким чином, щоб зміни впроваджувалися протягом годин, а не тижнів.
4. Розширюємість інтерфейсу. Аналогічно фронтенду фронт-офісу.
5. Рівень щастя співробітників. В кінцевому рахунку, ми робимо цей інструмент для них. Важливо, щоб вони не просто швидко могли виконати свою роботу, а й щоб в процесі вони отримували задоволення від цього.

Технічні особливості:

1. Єдина адмінка. Всі ви знаєте, що на разі ми маємо сотні різноманітних адмінок. Вони часто дублюють одна одну, реалізовані на різних технологіях, по різному виглядають та працюють. Ми маємо стандартизувати їх та призвести до єдиного інтерфейсу з різними доступами до інформації та можливостей, в залежності від співробітника.
2. Кастомізуємість під себе. Ми щоденно виконуємо дуже різні завдання, для яких потрібна тільки специфічна інформація. Відповідно, у наших колег має бути можливість тимчасово приховати якусь інформацію або розділ, щоб зосередитися на сьогоднішніх напрямках роботи.
3. Розподілення прав доступу до розділів та функціональних можливостей. Тут все зрозуміло, маю надію. Фінансовий директор та співробітник служби підтримки матимуть різний рівень доступу до інформацію та внутрішніх можливостей системи.
4. Модульність. Кожен сервіс може додати новий розділ в адмінку, або нові можливості в існуючи розділи. Все має працювати як слід в комплексі, незалежно від наявності та кількості підключених сервісів в системі.

Вигодонабувачі:

1. Співробітники ТМ.
2. Дизайн-інженери.
3. Фронтент-інженери.
4. Бекенд-інженери. В основному, вони створюють бекофіс, навіть його фронтенд. Відповідно, хочуть реалізувати його якісно.

Технології:

1. Веб-додаток. Класичний, не на React.
2. Bootstrap 4. Готовий низькорівневий фреймворк, що дозволяє конструювати адаптивні додатки на HTML+CSS+JS.
3. AdminLTE 3. Високорівневий фреймворк / набір готових блоків для Bootstrap, що дозволяють бекендеру збирати адмінки як конструктор Лего.

Бекенд фронт-офісу

Те, як ми працюємо з даними на сервері.

KPI:

1. Серверна швидкість.
2. Стабільність.
3. Швидкість розробки. Впровадження змін та появи можливостей, від ідеї до реалізації на продакшні.

Особливості:

1. Децентралізація. Мікросервіси. Система складається з сотен невеличких частин, кожна з яких виконує лише маленький набір завдань. Сервіси не спілкуються між собою напряму, тільки через посередників. Це підвищує загальну безпеку (злам однієї частини не дає нічого), таку систему важко загубити. Але це створює нові виклики з інтеграційних причин — коли в системі багато частин, з’являються проблеми на їх стику.
2. Модульність. Кількість сервісів може радикально збільшитися або зменшитися, система від цього не зламається. Кожна окрема частини системи абсолютно незалежна, й не пов’язана з іншими. Всі необхідні нашалтування, супровідні технології та матеріали вбудовані в сам модуль.
3. S.O.L.I.D. Це набір принципів при створенні архітектури цифрових продуктів. Спробую спростити — все має бути автономним, максимально дрібним та незалежним від інших частин.
4. Автономність. Принцип, за яким кожна окрема частина системи є абсолютно незалежною від інших, й навіть не знає про їх існування. Кожен модуль виконує лише один обов’язок. Модулі мають бути замінені в майбутньому без втрат в інших частинах системи. Наприклад, якщо ми вирішимо змінити наш чат на якийсь готовий інструмент — ніхто навіть цього не помітить.
5. No Single Point of Failure. Архітектура системи будується таким чином, що її не можна завалити DDOS-атакою, або людським фактором. В найгіршому випадку відключиться лише одна з частин системи, решта ж продовжить працювати як завжди.
6. Open REST API. Більшість модулів мають відкритий та документований протокол передачі даних. Це дозволяє кому завгодно отримувати необхідну інформацію, якщо є доступ до них. Авжеж, всі частини системи, пов’язані з грошима та клієнтами є закритими, хоча API в них також є, тільки ми ним ні з ким не ділимося.
7. Open Source. В своїй повсякденній роботі ми використовуємо багато інструментів, які були створені спільнотою. Час повертати борги, й ділитися нашими напрацюваннями. Якщо це дозволить комусь створити кращий продукт, може хтось поділиться з нами шляхами по покращенню наших.
8. PSR. Весь код, який пишеться, робиться по міжнародних стандартах спільноти. Правила жорсткі, але несуть з собою купу дивідентів по якості та швидкості програмування.
9. Документація. Всі функціональні частини покриваються детальним описом в спеціальній Базі Знань. Все з розрахунку на те, що в мабутньому хтось намагатиметься розібратися в описі для вирішення своєї проблеми.
10. Покриття тестами. Мінімум 80% функцій має бути покрито декількома прошарками тестів — функціональними, модульними, інтеграційними. Це драматично пришвидшить процес розробки та впровадження нових фіч в продукт.

Вигодонабувачі:

1. CTO та Platform Architect. Тут все зрозуміло. Це перші люди, які зацікавлені в якісній реалізації бекендових частин — щоб все працювало швидко, а розробка нових крутих штук займала години, а не місяці. Вони хочуть досягти ідеального стану системи, щоб все працювало швидко, стабільно та тримало величезні навантаження.
2. Бекенд-розробники. Вони, власне, відповідальні за якісну реалізацію кожного окремого модуля, бо не хочуть їх кожен рік переробляти.

Технології:

1. Мікросервіси на PHP7+.
2. Сховища даних Elastic / MongoDB.
3. Фреймворк Yii2.
4. Система Event Manager.
5. OAuth 2.0.

Бекент бек-офісу

За декількома відмінностями, бекенд фронт-офісу та бек-офісу майже ідентичні:

1. Backoffice Application. Існує модульний додаток, який знає про існування всіх сервісів, які до нього підключені. Він знає куди за якими даними ходити, бо часто користувачеві Єдиною адмінки потрібно показувати комбіновану інформацію з різних сервісів.
2. LDAP. За допомогою цього протоколу додаток BackApp розуміє в якого користувача який доступ до інформації, щоб не показати зайвого.

Зрозуміло. Над чим працюємо?

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

Першою справою ми маємо зайнятися інструментами, які застаріли техічно, й які створюють ризик всій системі. На схемі я розфарбував кожен модуль відповідно до його сьогоднішнього статусу.

1. Зелений — все добре, ця частина системи не потребує нагляду та розвивається в правильному напрямку.
2. Салатовий — ця штука файно, але потребує змін. Можливо, в ній мало тестів або документації.
3. Сірі зони в більш менш нормально працюють, але потребують значного рефакторінгу.
4. Помаранчеві потребують радикальних технологічних змін, через застарілість або невідповідність новітнім стандартам.
5. В червоних все тримається на соплях, пластеліні та чесному слові. Такі частини системи ми маємо якомога швидше замінити.

Зверніть увагу, що мова не про функціональні можливості, а саме про стан системи, те що під капотом. Цілком можливо, що навіть штуки з червоної зони працюють нормально, але як вони працюють всередені — вже ніхто не пам’ятає, й змінювати та підтримувати їх вкрай важко.

Круто! З чого починаємо?

В нас є план, в якому порядку та чим потрібно займатися найближчими місяцями. Виглядає він приблизно так, а завжди актуальну версію можна знайти на Confluence.

Порядок та терміни реалізації можуть і будуть змінені в залежності від реальних обставин, але наближену картинку він дає.

В мене є мрія

Хочу щоб бізнес по всьому світу проквітав, економіка зростала, й зростав достаток всіх людей. Щоб бідних людей не залишилося, й всі мали рівні можливості для самореалізації.

Вважаю, інтернет дає таку можливість, але зараз він влаштований доволі складно. Це створює зайві бар’єри для звичайних людей.
Я хочу, щоб сайти створювалися легко та з вогником, щоб люди знаходили один одного, й покращували рівень свого життя.

Саме для цього ми будуємо Платформу Онлайн Гіпермаркету TemplateMonster, де кожен може знайти те, що йому потрібно для запуску та роботи свого бізнесу в інтернеті.

На нас лежить велика відповідальність за успіх десятків мільйонів людей по всьому світу. Впевнений, ми їх не підведемо.

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

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

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

К черту авторитетов вроде Купера, Нильсена, Нормана, Круга, Сатина и Головача, которые давно ничего не понимают в современном дизайне интерфейсов. Пришло время ломать стереотипы.

Время покинуть светлую сторону, и присоединиться к клубу классных пацанов из темной, не правда ли?

1. Главное — интерфейс

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

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

Ну, вы поняли, нужно как можно больше ярких кнопок, попапов и анимаций.

2. Вывалите всё сразу

Постарайтесь донести до пользователя все ваши мысли на первом экране браузера. То, что люди скроллят — миф, который насаждает нам вражеская пропаганда. А если что-то не поместилось, всегда можно уменьшить шрифт и отступы между всеми элементами. Главное — занять все свободное пространство браузера.

3. Пусть одинаковые действия приводят к разным результатам

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

4. Забейте на информационную архитектуру

Выведите весь контент на одной странице. Смешайте его как можно тщательнее. Уберите все заголовки и форматирование. Организуйте текст в единый абзац. Спрячьте навигацию или удалите её вовсе, это покажет вас в выгодном свете.

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

5. Сделайте нестандартно

Разместите логотип справа внизу. Переместите меню интернет-магазина вниз страницы. Разместите сверху фотографию вашей кошки (или соседской, если у вас нет).
Привычным паттернам следуют только закостенелые лохи.
Настоящие пацаны ломают стереотипы о колено.

6. Пусть интерфейс не реагирует

Ни в коем случае интерфейс не должен подавать признаков жизни — это пугает людей.

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

Людям всегда интересно общаться со службой поддержки, выясняя, успешно ли совершена оплата, или следует попробовать ещё разок.

7. Усложните формы

Жизнь людей недостаточно насыщенна вопросами об их личной жизни. Постарайтесь вставить как можно больше полей, выпадающих списков (многоуровневых!), радио-кнопок и чекбоксов в любую форму. Особенно ту, которая отделяет деньги пользователей от ваших кошельков.
Маркетологи будут вам благодарны.

8. Спрячте главное

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

9. Обращайтесь грубо

Навсегда вычеркните из своего интерфейса любую вежливость и просьбы «пожалуйста».

С чего это вы должны просить кого-то о чём-то?
Прикажите этим немощным холопам выполнить ваш указ, да и поделом им. Не для того ваша розочка цвела, чтобы кланяться и лебезить перед пользователями или покупателями.

10. Побольше канцеляризма

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

11. Уменьшите элементы и текст

Помните, вы уже делали это на этапе, когда нужно было уместить всю доступную информацию на первом экране браузера?
Сделайте текст меньше ещё на пару кеглей меньше — времена проведённые с лупой у экрана ноутбука с теплотой будут вспоминать все посетители.

12. Пусть интерфейс отвлекает

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

13. Не прощайте ошибок

Случайно ткнул не в ту ссылку? Твои проблемы, назад тебе уже не вернуться! Пытаешься загрузить в письмо 20-гигабайтный фильм? Ничего страшного, потратишь больше денег на траффик. Письмо-то всё-равно не сможешь отправить. Му-ха-ха!

14. Пишите обьяснения длинными и неясными

Постарайтесь всё писать, как завещал Наполеон в отношении французской Конституции. Только длиннее. И ещё. Все любят читать меленький шрифт со сносками.

15. Вставьте больше хреновых стоковых фото

К черту, что у нас в поддержке работают только бородатые мужики. Давайте представим, что у нас работают исключительно вылизанные длинноволосые блондинки. С гарнитурами двадцатого столетия на головах.

Забейте на сетку

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

16. Подберите вырвиглазные сочетания цветов

Творческая душа требует самореализации, понимаю. Идеальный контраст — когда всё красным шрифтом на зелёном фоне. Да, детка!

17. Заставьте выбирать

Пользователи обожают многообразие выбора. Его никогда не бывает много: вывалите на человека как можно больше вариантов.
Если он не сможет запомнить все — сам виноват.

18. Ничего не обьясняйте

Люди слишком глупы, чтобы понять ваш гениальный интерфейс. Пусть всё так и остаётся.

Надеюсь, вполне понятно, что следуя этим советам, вы приведёте свой интерфейс в полную жопу. Действуйте на свой страх и риск.

Не рекомендую повторять это у себя дома.

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

PPS: Будьте котиками, поступайте c точностью до наоборот :)

Уебанский интерфейс за 18 простых шагов was originally published in Архів on Medium, where people are continuing the conversation by highlighting and responding to this story.

В 2005 году, я только начал как следует работать дизайнером интерфейсов. Один клиент доверил мне свой новый проект — фотохостинг, который должен был подавить Фликр (угадайте, с каким результатом).

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

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

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

1. Профессиональный опыт, интуиция, ощущения и «знания» могут оказаться полной херней в любой момент времени.
2. Важно проверять гипотезы и полагаться только на результаты грамотно проведённых экспериментов.
3. Выдавать свои непроверенные аргументы как истину — зло.

Тогда мне было плохо от этого понимания, однако, в конечном счете, благодарен за урок.

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

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

Для начала — несколько аксиом и максим, принятых мной и актуальных для любых обстоятельств и контекстов:

Любое убеждение — гипотеза

Пока идея не подтверждена экспериментальным путём в боевых условиях — это не факт, даже если об этом говорит кто-то авторитетный. Критичность решает.

Полагаться на гипотезы опасно

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

Нельзя посчитать = нельзя проверить

Если непонятно, как измерить эффект при проверке гипотезы, значит её нельзя проверить, а значит см. пункт выше. Не говоря уже о случаях, когда не понятно, какой эффект измерять — тогда и гипотезы-то нет.

Интуиция ненадёжна

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

Измеримые факты уделывают эмоции

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

Контекст — король

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

Начать проверку не сложно

Гипотеза — это любое ваше предположение, которые потенциально может принести положительный или отрицательный эффект.

Проверять пессимистичные идеи формата «Если не сделаем это, тогда будет плохо» можно, однако не слишком продуктивно, потому ниже расскажу о том, как мы проверяем оптимистивные.

1. Инициируем и формализируем

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

По возможности стараемся сразу записать новую гипотезу в учетную таблицу. Если останется на словах — значит идеи не существует, про неё забудут или потеряют результаты.

Может показаться, что это бюрократия, однако иначе каждый сможет понять гипотезу как ему вздумается.

1. В чем состоит идея?
   Вывел для себя простую формулу: Если [предложение], тогда [результат]. Например: если сократить количество полей ввода данных в чекауте, тогда увеличится конверсия в покупки.
2. Зачем нам её проверять?
   В чем потенциальные выгоды для бизнеса и пользователя. В случае с чекаутом всё просто — для бизнеса больше денег, а для пользователя меньше мороки.
3. Как узнать, подтверждена ли гипотеза?
   KPI. Если нет четких измеримых показателей, на которые реализация идеи повлияет в ту или иную сторону — нет гипотезы.
   Возвращаясь к примеру с чекаутом — ключевым показаталем эффективности была конверсия в покупки.
4. Какой способ быстро проверить её?
   Всегда можно определить минимально необходимое решение. А после — сократить и его. Главная задача — проверить гипотезу как можно скорее, не углублясь в дебри разработки.
5. Существуют готовые решения?
   Ресурс разработчиков дорог. Всегда следует поискать готовые решения, которые помогут быстро проверить гипотезу: сервисы, движки, скрипты и прочее.
6. Как будем внедрять?
   Следует относится к проверке гипотез как к проекту. У любого проекта есть план действий, обьем работы, этапы реализации и требуемые ресурсы. В общем «что делаем, в каком порядке и что для этого нужно».
7. Кто уже делал?
   Кейсы, конкуренты, аналоги, лучшие практики.

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

2. Определяем приоритеты

В идеальном мире с радугами и единорогами у каждого из нас бесконечное время и за плечами безграничные ресурсы.

В суровом реальном мире это не так. Тут как у Алисы в Стране Чудес: если просто бежать изо всех сил —останешься на месте. А чтобы двигаться вперед нужно бежать вдвое быстрее.

В общем, после определения списка гипотез, следует расставить приоритеты, исходя из того, какая из них потенциально принесет больше счастья и добра (перечеркнуто) денег вам и проекту.

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

Лучшая гипотеза — та, которая затрагивает как можно больше пользователей и потенциально принесет больше денег, при этом проверка не займет много времени.

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

1. По горизонтальной оси располагаю гипотезы по уровню их сложности (скорости) реализации разработчиками
2. По вертикальной — потенциальную выгоду для проекта.
3. Зеленый сектор следует немедленно брать в работу.
4. Гипотезы из желтого ставлю в долгосрочный план.
5. На серый следует тратить время только если нет гипотез из зеленого и желтого.
6. А идеи из красной области просто удаляю, чтобы не отвлекали.

Выглядит просто, работает магически, прочищает мозг, хотя и не rocket science, конечно.

3. Проектируем и внедряем

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

1. Ищем лучшее интерфейсное решение в заданных условиях.
   Брейнштормы, скетчи, быстрые прототипы, вот это всё. Ничего такого, о чём нельзя прочитать в «Психбольнице в руках пациентов» Алана Купера.
2. Опредялем все кейсы.
   Часто дизайнеры останавливаются на концептах, которые красиво выглядят на макетах, но в реальных боевых условиях всё идет по пизде, простите за французский. Следует предусмотреть все 95% случаев, которые могут произойти во время использования интерфейса, и продумать соответствующие решения. В таких случаях наш лучший друг — тестировщик (QC или AQC), они всегда озабочены тем, что мы не все предусмотрели.
   Про дизайн с реальными данными не сказал в интернетах только ленивый или некомпетентный дизайнер.
3. Описываем спецификацию разработчикам и аналитикам.
   Да, это следует делать дизайнеру нового интерфейса, если он здорового человека, конечно. Нет, не бизнес-аналитику. Не техническому писателю. Не менеджеру проекта. Не копирайтеру. Не уборщице.
   Да, это менее интересно, чем графический редактор или среда прототипирования, однако глубоко убежден, только дизайнер сможет описать свою идею максимально подробно и по человечески.
4. Результат работы дизайнера — не макеты, а запущенное решение.
   Именно по нему будут судить о качестве работы.
   Если дизайнер пропустил сырое и непроработанное решние на продакшн — сам виноват, нефиг перекладывать ответственность.

4. Собираем и анализируем данные

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

В 95% случаев проверяем гипотезы с помощью A/B или мультивариантного тестирования, где исходный интерфейс соревнуется с гипотетически более хорошим.

В качестве KPI, в нашем случае, чаще всего, выступает валовая доходность + конверсия. Порой бывает что-то более специфическое, но редко.

О сегментации

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

Например, мы часто устраиваем эксперименты только для посетителей из определенных стран, или вовсе только на одной локализации сайта. Порой проверяем эксперимент только для специально созданного сегмента посетителей «Потенциальные покупатели», чтобы не засорять результаты мусорным трафиком.

О семплировании

Пользуясь Аналитикой Гугла следует всегда быть настороже — если у вас много статистики, сервис начинает семплировать данные, что может исказить вам результаты.
Если коротко, Google берёт, скажем, 1% от всех сессий, подбивает точную статистику и экстраполирует результаты на оставшиеся 99%.
В общем, не круто. Насколько понимаю, корпоративная версия за вагоны денег лишена этого недостатка.

Что дальше?

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

1. Гипотеза подтверждена.
   Поднимем бокалы! Однако не расслабляемся: следует подумать, как усилить положительный эффект в будущем. Так появляется волшебная Идея 2.0.
2. Гипотеза опровергнута.
   Сигнал задуматься о причинах. Исправляем их и запускаем новый эксперимент. Если всё совсем плохо — забываем как страшный сон и радуемся, что это был лишь эксперимент.
3. Нихрена не понятно.
   Такое бывает, если влияние новинки не так существенно, как ожидалось, однако и хуже не стало. В такие моменты остается надеятся, что мы не потратили кучу денег на проведение эксперимента. В любом случае, ничего не мешает оставить новое решение в качестве нового основного.

Выводы

1. Полагаться на интуицию — опасно.
2. Важно правильно инициировать гипотезы и формализировать их.
3. Сосредоточиться следует на тех идеях, которые легко проверить и потенциальный эффект от которых максимален.
4. Любая гипотеза актуальна только в конкретном контексте. В другом проекте, например, полученные ранее данные могут быть не актуальны.
5. Проведённый эксперимент — это не конец, а новое начало бесконечного Кайдзен-процесса улучшений.

Вышеописанное может показаться сложным и страшным, если вы ещё не ставили экспериментов. Надеюсь, вас это не отпугнёт: ставить эксперименты — круто и не слишком сложно, когда обкатаешь процесс как следует. Надеюсь, эта вводная статья поможет.

Мало что сравнится по уровню удовольствия с кайфом в тот момент, когда эксперимент завершается с разгромным счётом в пользу нового интерфейсного решения.

Если же текст выше показался вам само собой разумеющимся, продиктованым здравым смыслом — значит вы молодец.
Однако никогда не лишне повторить пройденное :)

Как проверить гипотезу и не облажаться was originally published in Архів on Medium, where people are continuing the conversation by highlighting and responding to this story.

Пару лет спустя уже вовсю писал собственные сайты. Черт его знает, зачем они были мне нужны, однако самозабвенно копался в хитросплетениях HTML и JS. «Проекты» были ужасны — помните бегающие за курсором буквы?

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

В тот миг я почувствовал себя дизайнером интерфейсов.
Тогда ещё не осознавал, во что влип.

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

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

Исходя из этого, становится понятно, что каждый вокруг нас отчасти дизайнер. Однако существуют люди, которые посвятили себя постоянному поиску всё более эффективных способов решения задач на стыке человека и чего-либо.

В моём случае — цифровых интерфейсов.

Хороший дизайнер интерфейсов — это спецназовец мира дизайнеров.

Он знает и умеет многое. Владеет множеством инструментов и способов достижения поставленной цели.

Продвинутый дизайнер умело прототипирует и оформляет графически. Знает, где и как достать необходимую информацию. Понимает, как правильно инициировать гипотезы и проверять их правильность. Осознаёт важность предварительных исследований и анализа данных.

Универсальный боец, способный решить задачу комплексно и с должным предсказуемым качеством.

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

На мой взгляд, качественная работа дизайнера интерфейсов = эффективность + рациональность + понятность + эстетика, именно в таком порядке. Такое интерфейсное решение будет элегантным.
В общем, как завещал Дитер «Наше Всё» Рамс.

Дизайнер интерфейсов здорового человека

• Нацелен на результат.
  Им может быть достижение какой-либо цели или решение проблемы. Чем более крутой дизайнер — тем более сложную цель он может достичь и проблему решить.
• Не воспринимает действие как цель.
  Создать макет для лендинга — не самоцель, поскольку посадочная страница создаётся для достижения чего-либо. Например, может стоять задача собрать e-mail-ы и превратить их в регистрации.
• Решает задачи на стыке бизнеса и людей.
  Если исключить из формулы бизнес — он превращается в концептуалиста (что не есть плохо, однако не практично). Если исключить из формулы людей — он становится хренового пошиба маркетологом.
• Выступает адвокатом пользователей.
  Защищает их от порой странных идей других заинтересованных лиц (читай — маркетологов :).
• Ответственен за конечный результат.
  Например, в случае с сайтом, успешность работы дизайнера будут оценивать по тому, насколько качественно и эффективно внедрено что-то онлайн. Мало кто будет оценивать интерфейс по статичному макету или бесцветному прототипу, пусть и чертовски интерактивному.
• Умеет собирать информацию.
  Не ждёт маркетологов с текстами для простейшего сервисного лендинга. Знает о существовании принципа AIDA, и вполне может сам подготовить информацию для его правильной реализации.
• Любит сырые данные.
  Если чего-то не хватает — пойдет в Аналитику Гугла и раскопает всё, что понадобится. Если данных нет в Аналитике — найдёт её в другом месте, обработает и осознает/поймёт.
• Проектирует, а не украшает.
  Решает проблему. Ищет оптимальный метод и инструменты для решения проблемы. В первую очередь уделяет внимание идее и оптимальному пути её реализации, и только потом визуальным красотам.
• Меряет эффективность.
  Дизайн-решение считает удачным, если улучшены KPI — ключевые показатели эффективности. В случае с лендингом, который собирает e-mail-ы одним из таких показаталей, скорее всего, будет конверсия из посетителей страницы в собранные адреса почт → из них подтверждённые адреса → из них превращённые в лиды.
• Упрощает последующую работу.
  Разработчик — хороший товарищ дизайнера интерфейсов здорового человека. Поскольку он ответственен за конечный результат, упрощать работу разработчику (тем самым ускоряя конечную реализацию) — одна из задач дизайнера.
• Оптимизирует себя и процессы.
  Выделяет 20% рабочего времени на то, чтобы в следующий раз решить задачу на 20% быстрее или на 20% качественнее.
  Это помогает ему ритмично расти над собой и брать в работу более сложные задачи.
• Знает, что идеального решения не существует.
  Однако стремиться его достичь, пусть итеративно. Главное, чтобы с каждым разом решение становилось лучше. Такой себе Кайдзен.

Внимание!
Наброс на вентилятор ниже может и будет вызывать острое жжение внутри. Беременным детям животных читать текст ниже не рекомендую.

Дизайнер интерфейсов курильщика:

1. Ленится провести исследования перед началом работы.
   Считает, что и так всё понятно, зачем тратить время. В результате, регулярно изобретает интерфейсные велосипеды разного уровня паршивости (сам таким болел году эдак в 2007).
2. Сразу садится за макет.
   Не осознаёт решаемую задачу и её KPI. Следует парадигме «Хуяк-хуяк и в продакшн».
3. Ждёт тексты от маркетологов.
   Вместо того, чтобы быстро прикинуть примерный контент (а то и вовсе уделить время, и сделать всё хорошо), засоряет всё чёртовыми Lorem Ipsum-ами, от которых уже даже недизайнеров тошнит.
4. Не умеет находить нужную информацию и собирать данные.
   Ждёт, что прилетит волшебник на белом вертолёте и отгрузит всё сразу. Пальцем не пошевелит, чтобы найти требуемую для решения задачи информацию самому, или обратиться за помощью. «Что вы от меня хотите? У меня данных не было!».
5. Плохо ориентируется в статистике и её анализе.
   Не умеет делать из неё правильные выводы. Если делает, то поверхностные и часто ошибочные. Не представляет себе, как выглядит и работает Аналитика Гугла или Яндекс.Метрика. Не говоря уже о чём-то более экзотическом, вроде Вупры.
6. Тратит большую часть времени на графическое оформление.
   В результате может быть красиво, однако непрактично, сложно (дорого) внедряемо и всё пойдёт в стол. Зато портфолио будет впечатлять неискушенных.
7. Не умеет инициировать и проверять гипотезы.
   Полагается исключительно на интуицию и железобетонное «Я так вижу». Поскольку не проверяет своих решений, со временем уверяется в собственной непогрешимости, что раздувает и без того объёмное чувство собственной важности.
8. Выдрачивает пиксели.
   Дизайн курильщика прекрасно выглядит на статичном макете, но часто хреново работает вживую. Игры со шрифтами и эффектами регулярно приводят в ярость верстальщиков его макетов.
9. Ориентируется на процесс, а не результат.
   Потому регулярно факапит сроки, со всеми запасами, включая те, которые ставит сам себе. Зацикливается на мелочах, не знаком со старым методом прогрессивного джипега.
10. Руководствуется эмоциями и суевериями.
    Игнорирует факты, если последние не нравятся, или даже подтасовывает их ради собственной выгоды. Забивает на логику и элементарную алгоритмизацию.
11. Следует принципу «После меня хоть потоп».
    Не пишет спецификации. Забивает на проблемы в реализации. Не хочет нести ответственность за внедрение.
    Как результат — люди пользуются продуктом, собранным из пластыря и костылей, держащихся вместе на соплях.
12. Жалуется на «криворуких разработчиков».
    Не видит необходимости в тесном симбиозе разных членов команды, сознательно или без отделяется от неё. Тем самым выставляя на люди своё непонимание того, как создаются классные продукты.

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

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

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

Так или иначе, порой, даже лучшие дизайнеры интерфейсов, порой, ведут себя как дизайнеры курильщика.

Никто не идеален.

Дизайнер интерфейсов здорового человека и дизайнер курильщика was originally published in Архів on Medium, where people are continuing the conversation by highlighting and responding to this story.

Оказалось, неподготовленный человек, прочитав статью мог воспринять её радикально по-другому, порой с противоположным смыслом.

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

Режим прикрытия жопы включён:

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

Режим прикрытия жопы выключен.

Дизайн ≠ внешний вид

В широтах постсоветствого пространства под этим словом чаще всего имеют в виду «графическое оформление», мне же ближе понятие «проектирование».

Моё мнение не ново, однако убеждён: дизайн — это способ решения какой-либо проблемы.

К этой мысли пришёл не сразу — несколько лет пиздостраданий «поиграйте со шрифтами», и вот я здесь.

Проблема? Дизайн?

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

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

Яркий пример распространённого подхода «Хуяк-хуяк и в продакшн».

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

Исследование

Ответ на вопрос «А нужен ли там выключатель?».
Вполне может оказаться, что освещение в том конкретном месте не имеет какого-либо значения.

Оформление

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

Впечатления пользователя (UX)

Какие эмоции, впечатления вызывает взаимодействие с выключателем. Комфортно ли усилие нажатия? Издаёт ли подтверждающие звуки? Не болтается ли? Не торчит ли проводка, бьющая током при каждом нажатии?

UX — оценочное понятие (насколько хорошо/комфортно), а не процесс (что и как делать).

Исследование, прототипирование, оформление и документация — это всё Проектирование (Дизайн в моей интерпретации), а UX — его результат.

Интерфейс

Сам по себе переключатель как способ взаимодействия человека с лампочкой.

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

Идеальный интерфейс —когда задачу можно решить без интерфейса вообще.

Например, с помощью датчика, который будет включать и выключать свет автоматически.

Прототип

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

Минимально ценный продукт (MVP)

От заморского “Minimum Viable Product”.
Мне кажется, суть лучше всего передаёт эта смешная картинка из интернетов.

На нашем примере — MVP задачи был бы «пусть освещение работает всегда». Каждый дизайнер неизбежно сталкивается с жестокими реалиями жизни и узнаёт значение этой грустной аббревиатуры из управления проектами.

Пользователь

Биологический носитель информации, наполненный ожиданиями, страхами и суевериями. Только попробуйте его не удовлетворить.
Не любит выбирать.

Информация выше может (и будет) вызывать у кого-то жгучее и активное желание убедить меня в неправоте. Если это про вас — прогуляйтесь на улице, досчитайте до 100 и плюньте на это.

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

Мой понятийный аппарат дизайнера was originally published in Архів on Medium, where people are continuing the conversation by highlighting and responding to this story.

Это значительно снизило уровень стресса, который я испытывал ранее. Приятное чувство.

Постараюсь раскрыть для вас плюсы и минусы собственной модификации этой техники.

Для начала — небольшой исторический экскурс для любопытных.

Pomodoro — методика управления временем, предложенная Франческо Чирилло в конце восьмидесятых годов двадцатого столетия.

Изначально предназначалась для нужд парного программирования, однако со временем стало понятно, что ею могут пользоваться и дизайнеры, плотники и прочие контент-менеджеры.

Цель методики — погрузить человека в состояние «Потока», исключив отвлекающие факторы и сконцентрировав внимание на выполнении одного задания одновременно.

Поскольку мужчины, в большинстве своём, однозадачны — мне это чертовски пригодилось.

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

Работаю в этой парадигме с октября 2015 года, когда решил сменить карьеру, перейдя в TM. В новой команде появилась возможность выстроить все процессы по новому, исправив ошибки прошлого.

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

Однако в последний раз всё прошло успешно — неделя страданий, а после получил несколько полезных эффектов. К сожалению не без минусов, о которых парой абзацев ниже.

Как это работает

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

Разбиваю рабочее время на отрезки в 25 минут, каждый из которых и называется помидоркой. Между помидорами устраиваю себе пятиминутные перерывы. Каждую четвёртую помидорку — делаю 25-минутный перерыв.

В свой обычный рабочий день у меня получается 15 полноценных помидор, 2 больших перерыва и обед.

На рабочем компьютере настроил систему напоминаний о начале помидорок и перерывов по заранее заданному расписанию. Сделал это через встроенную маковскую аппликацию «Напоминания».
Стараюсь этому расписанию строго придерживаться, хотя и не всегда удаётся.

За одну помидорку следует сделать что-то законченное.
То есть следует постараться получить такой результат, чтобы не приходилось доделывать работу на следующей помидоре. Это крайне желательно, однако не критично. У меня часто на протяжении дня встречаются двух-трёх-четырёх помидорные задачи.

Иногда встречаются задачи-айсберги, это нормально.
В следующий раз декомпозирую подобные задачи тщательнее.
Если же завис на чём-то из-за моральных или психологических моментов — никакая методология не поможет.

Как правильно отдыхать

• Встать с рабочего места.
  Да, в кресле уютно и комфортно. Хочется остаться в нём и «не смотреть в экран», однако это не работает. Желательно выйти из комнаты, в которой находится ваше рабочее место.
• Не думать и не говорить о работе.
  Чаще всего мы отдыхаем с коллегами, потому велик соблазн что-то дообсудить, решить какие-то рабочие вопросы, регулярно ловлю себя на этом. В таких случаях говорим о погоде, хобби, детях, в общем, о чём угодно, только не касаемся работы. Если ловлю себя на рабочей мысли — поступаю аналогично. У каждного в жизни есть другие темы для размышлений, пользуюсь этим временем, чтобы обдумать их.
• Не пялиться в экраны.
  Да, никаких телефонов, планшетов и иже с ними. Скорее всего, читатели это статьи работают за компьютером, потому крайне важно оставить девайсы в покое и дать передышку мозгу и глазам.
• Если получается выйти на свежий воздух — идеально.
  Даже трёхминутная прогулка зарядит вас энергией, не говоря уже про 25 минут. Перекуры на крыльце — не считаются прогулкой, только если вы топаете ногами куда-то в сторону от офиса.
• Сменить деятельность.
  Этот пункт суммирует предыдущие. Если вы работаете за компьютерами — не сидите за ним. Вычитываете книги — не втыкайте в них. Мастерите сантехнику — ну вы поняли.

Итак, минусы:

1. Первые две недели прошли у меня довольно сложно.
   Следить за всем не хочется, кажется, это только мешает работе. Ощущение проходит, однако высок риск сорваться в привычный рваный «ритм» работы.
2. Порой не хочется прерываться.
   Особенно когда тебя «прёт» и кажется, что поймал быка за рога. Эти ощущения приятны, потому позволяю себе пропустить перерыв-другой в день, компенсировав в моменты следующих дней, когда работа «не идёт».
3. Иногда нет желания отдыхать.
   Кажется, что поймал рабочий поток. Выход — встать и таки пойти. Настоящему потоку это не мешает, а «поток-самозванец» не грех и прервать. В таких случаях стараюсь разбить задачу на несколько помельче, и продолжить в следующей помидоре.
4. Встречи и совещания ломают график.
   Если есть возможность — отказываюсь от длинных, сокращаю их или разбиваю на части. Если такой возможности нет — приходится терпеть, что уж тут поделаешь.
5. Сложно концентрироваться на параллельных задачах.
   Не слишком частая проблема, однако порой это нужно и важно. Поскольку помидороведение рассчитано на сфокусированную работу над одной задачей, в такие моменты приходится переходить в режим ахтыжёбаныйтынахуй, поскольку Pomodoro только мешает.
6. Иногда прерывают люди.
   Когда сфокусирован и сосредоточен на работе над каким-либо заданием, вмешательство других раздражает. Даже если это безобидный вопрос — он вытаскивает меня из определённой мысли, и чтобы к ней вернуться, приходится прикладывать усилия и время. Рекомендую записать в блокнот мысли-якоря, для быстрого погружения обратно в контекст задачи.
   Стараюсь ограничивать общение в строго отведённых помидорах. Это касается как онлайна, так и офлайна.
   К сожалению, не всегда это получается.
7. Телефон и другие звонки.
   Если что-то важное — приходиться говорить во время помидор.
   В большинстве случаев — переношу на перерыв.
8. Плохое название.
   Методика классная и серьезная, однако название вызывает улыбку, его сложно воспринять всерьез, когда рассказываешь кому-либо. Практически все за него цепляются, и как результат — мало прислушиваются к сути, а зря.

Как-то всё это странно

Выше писал — для меня эта методика сработала далеко не с первого раза. Её описание выглядело диковато. Однако она вызывала у меня любопытство и желание попробовать ещё раз.

Надеюсь, мне удалось донести до вас как её преимущества так и недостатки.

Прошу не воспринимать всё описанное в интернетах как нерушимую истину. Иначе это может привести к тому, что на управление управлением временем будет уходить больше времени, чем на работу. Это справедливо и для текста выше :)

Главное — я перестал возвращаться домой выжатым лимоном и у меня вновь появилась энергия для хобби.

Например, чтобы писать статьи.

Постскриптум

Откуда название у статьи?

Ботаники, чиновники и другие замечательные люди не могут сойтись во мнении, что же такое — этот красный сочный плод. Помидор называют ягодой, овощем и даже фруктом.

Огурец, оказывается, тоже нифига не овощ, а ягода.

Жизнь непредсказуема.

Овощное, фруктовое и ягодное управление временем was originally published in Архів on Medium, where people are continuing the conversation by highlighting and responding to this story.

Как связаться was originally published in Архів on Medium, where people are continuing the conversation by highlighting and responding to this story.