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

«Основная проблема интерфейса в том что это интерфейс. Интерфейсы — это препятствия на пути. Я не хочу сосредоточивать свои силы на интерфейсе. Я хочу сосредоточиться на работе… Я не хочу осознавать себя использующим компьютер, я хочу осознавать себя делающим дело».

Дональд Норман

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

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

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

Уровень подготовки веб-мастера: средний или высокий

Указав авторство материалов, вы предоставите пользователям дополнительную информацию об интересующем их содержании и авторе. Обозначив свое авторство, вы поможете пользователям находить ваш контент. Нажав на ваше имя, они смогут найти другие ваши материалы или стать вашим подписчиком в Google+. Все очень просто! А некоторые нюансы мы разъясним ниже.


Авторство, указанное в результатах поиска (Джон Мюллер, один из моих любимых авторов)

То есть как — психология?

Некоторые наши специализированные компании, предоставляющие услуги на рынке юзабилити, уже много лет укомплектованы дипломированными психологами (чаще всего, выпускниками кафедр инженерной или общей психологии). Действительно, уже более полувека русскоязычная психология исследует процесс взаимодействия человека и техники (первая наша книга по теме) и, в частности, интерфейсы между оператором и техническим устройством. Конечно, терминология эта носит сугубо эргономический характер, однако это не затрудняет перенос знаний в IT-среду (например, Дмитрий Сатин, основатель UsabilityLab, является выпускником самой эргономической кафедры факультета психологии МГУ).
Психологическое знание в России популяризируется слабо, хотя само по себе может быть очень полезным для разработки программных продуктов. Я попытаюсь коротко изложить некоторые базовые принципы проектирования — как их видно изнутри классических психологических (преимущественно, когнитивных) работ. Я уверен, что буфер, которым является юзабилити, IT-индустрии не нужен: психологические знания можно научиться применять напрямую.

Сначала предметная область

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

Ключи/запросы

Это фразы, которые набираются в поиске, для достижения результата (ответа на вопрос, покупки, получения информации…)
По частотностям
НЧ – низкочастотные (величина вычисляется логарифмически относительно самого большого числа запросов по ВЧ запросу из категории), для простоты пусть будет все что ниже 300 запросов (хотя в каждой группе по разному).
СЧ – среднечастотные (величина вычисляется логарифмически относительно самого большого числа запросов по ВЧ запросу из категории), для простоты пусть это будет все что выше 300 и ниже 2000 запросов (хотя в каждой группе по разному).
ВЧ – максимальное значение количества поисков простого запроса, к примеру «Светильник».
По конкуренции
НК – низкоконкурентные запросы, по которым есть шанс двинуться в топ (мало точных вхождений поисковой фразы, мало главных страниц, низкое количество результатов в поисковой выдаче)
СК – средне конкурентные запросы, по которым есть шанс продвинуться в топ, но есть и конкуренция (весь топ занят или главными или точными вхождениями, но показатели ссылочной массы конкурентов низкие)
ВК – высококонкурентные запросы, по которым необходимо из кожи вон вылезти чтоб продвинуться (и топ весь занят, и ссылочная масса ужасающая) при средних бюджетах ВК топ недостижим, но можно долго работать, чтоб кардинально поменять выдачу (закупка сателлитов, ссылочной массы, грамотное внутренне СЕО).

Семантическое ядро

Предполагает, что будет оптимизироваться каждая страница сайта. Это значит, что страница конечно будет давать ответ на запрос пользователя, но при этом на ней должен быть материал, который включает в себя эти ответы. То есть признаки, по которым ПС сможет выдать именно эту страницу на это запрос…
Пока что это сами запросы пользователей – они же «КЛЮЧИ»
Ключевые фразы подбираются для каждой страницы персонально.
Для главной страницы берутся общие запросы (описывающие общую категорию и выделяющие общую тематику сайта).
Для страницы категории выбираются запросы более узкой тематики, выделяющие отдельную категорию в общей всего сайта.
Для страницы товара/услуги – берутся максимально конкретные запросы, отражающие ее суть и позволяющие максимально точно ее/его идентифицировать.

0 Стратегия: Тариф Беззаботный

Минимум затрат, так как трафик тупо покупается у ПС. Других вариантов нет.

1 Стратегия: На халяву

Низкоконкурентный трафик – занимается ниша, где есть спрос, но нет конкурентов – классический «кто первый встал – того и тапки».
Схема до боли проста – ищем свободные ниши, подбираем НК запросы, пишем материал (даем полезное на запрос пользователя) – попадаем в ТОП, для усиления эффекта можно закупить по парочке ссылок.

Юзабилити-специалист нужен всем: большим IT-компаниям и маленьким стартапам. О том, как обычно выстроен процесс работы юзабилиста в больших компаниях, на хабре писалось уже не раз. А тему «как взять и прямо сейчас организовать работу внутри вашей команды» (пусть и небольшой) почему-то все время обходили стороной.

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

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

Мы проведем обзор публичных инструментов, которые мы использовали, чтобы повысить конверсию Бурук на 25% и сделать пользователей немного счастливее. В конце — про новинку от Google Analytics, которая позволяет связать онлайн источники трафика с оффлайн конверсией.

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

Повысить конверсию просто.

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

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

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

Модель пропасти

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

Сейчас, куда не посмотри, все стали учёные: литературой запаслись, интернеты читают. Кого не спроси, и о кривой принятия технологии знают, и вообще всё им понятно: «… да-да, знаем! Есть Новаторы, Ранние последователи, есть рынок ранний, а есть поздний, отщепенцы и увальни — ну куда без них? Да-да, между рынками, ранним и основным, есть пропасть, которую нужно перепрыгнуть!» Знают. Прыгают. Только, бывает, пикируют. А всё почему? Потому что аннотацию прочли, а содержимое не осилили. Поэтому я написал эту заметку. Речь пойдёт о том, что важные вещи, которые нужно знать о модели Пропасти, не всегда лежат на поверхности.


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

К слову сказать, на это понадобилось лет шесть изысканий.

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

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

Свои изыскания в этой части мы начали году в 2006-м, полагая, что лучшее решение для производства — это MRP. В 2010-м году, после некоторых опытов по внедрению, мы поняли, что MRP не ведет к увеличению эффективности. Количество заказов, произведенных точно в срок, не увеличивается, запасы не уменьшаются, скорость производства не растет. А зачастую даже наоборот. Я написал статью об этом. Довольно эмоциональную. Видимо серьезно задев тех, кто зарабатывает на внедрении MRP. Но ведь целью внедрения любой системы менеджмента должно быть увеличение эффективности, не так ли? Многие об этом забывают, как, впрочем, и о том, что цель бизнеса – зарабатывать деньги. Поэтому внедрение MRP чаще всего превращается просто в проект по внедрению MRP, а в не в проект по улучшению эффективности производства.

В ходе подготовки к Летнему Аналитическому Фестивалю 2012 родилась эта статья, в которой поднимаются следующие вопросы:

• Кто такие ИТ-менеджеры?
• В каких вузах их могут готовить?
• Что в вузе им должны прочитать?
• Как подготовить в вузе сотрудника для своей компании?

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

Мы в Alconost предоставляем услуги создания и ведения контекстной рекламы и, по долгу службы, иногда занимаемся разработкой посадочных страниц (landing pages). Мы были очень рады найти и перевести статью, в которой автор изложил все требования, которым такая страница должна соответствовать. Но есть в этой статье и большой минус. Пунктов аж 50, каждый можно отметить в чеклисте, но после доступен лишь результат в баллах, которым можно разве что похвастаться перед друзьями.

Мы против таких способов анализа информации. Потому каждый желающий может скачать подготовленную нами гуглотаблицу, ответить на вопросы “Да” или ”Нет”, отфильтровать ответы и получить результат и план действий.

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

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

Это шаблон описания сути вашей компании или проекта в одном предложении. Я открыл его для себя во время стажировки в США. Составив его, мы реально становимся сильнее. В последствии мне это помогло выбрать правильный курс, сфокусироваться и расставить приоритеты.

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

На позицию CTO я пришёл не через стандартный путь “Developer -> Senior -> Team lead -> CTO”, а через гуманитарный вариант – “PM -> Senior PM -> CTO”. В этом были как свои плюсы, так и минусы, и трудно сказать, чего больше, но персональных вызовов хватало всегда и техническое прошлое часто спасало, однако, сейчас не об этом.

4. Вынужденные оценки

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

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

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

Идеальные вопрошающие бывают. Они формируют очень точные чёткие вопросы, на которые приятно отвечать.

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

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

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

Главная проблема для всех – формулировка вопроса

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

На хабре есть много тем по специфичным аспектам менеджмента проектов. Но именно основы менеджмента до сих пор не были освещены.

Попробуем закрыть этот пробел.

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

UPD. Пост про менеджмент, а не про менеджеров.

Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

• Готовность Начать
• Готовность Завершить
• Готовность Выпустить

Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.

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

Самые крутые инструменты — универсальны, с их помощью можно решать самые разнообразные задачи. Примеры таких инструментов — документы и таблицы Google, ментальные карты Mindmeister, доски Realtimeboard. Вы можете их приспособить для чего угодно, особенно таблицы. Придумать и сделать такой инструмент сложнее всего. Я расскажу о еще одном универсальном инструменте, который мы активно используем — Tom's Planner.

Прекрасно понимая общую нелюбовь Хабравчан ко всему, где есть слово «SEO», отмечу, что правильная поисковая оптимизация является необходимой частью процесса создания и поддержания сайта, что отражено в соответствующих рекомендациях по созданию сайтов от Яндекса и Гугла.

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

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…

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

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.