Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.

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

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

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

Хранение запасов стоит денег. Предположим, что на хлебозаводе есть шесть 50-тонных силосов для хранения муки. Это значит, что в среднем каждый день в них находится около 150 тонн муки. По сегодняшним ценам это 73000$ мёртвого капитала.

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

Зачем тогда вообще хранить запасы? Затем что есть ещё и расходы связанные с их нехваткой. Если на заказ новой партии булочек с кунжутом уходит два дня, то, если они вдруг закончатся в вашей закусочной, ваш бизнес по продаже гамбургеров остановится на двое суток. Запасы — это буфер, который предотвращает непредвиденные остановки. Сейчас придумано множество алогоритмов для вычисления оптимального объёма этих буферов (для начала: бережливое производство, теория ограничений).

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

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

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

Именно так выглядит Data Mining в клиентской аналитике. И именно так это уже работает на практике в сотнях крупных компаний по всему миру и в нашей стране.

Это перевод оригинальной статьи Principles of User Interface Design

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

— Пол Рэнд (Paul Rand)

1. Обязанность интерфейса — обеспечение взаимодействия

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

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

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

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

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

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

…
— А ты чем занимаешься то?
— Да мы с ребятами стартап запускаем, такой классный!
— О, круто! А что за стартап?
— Ну слушай, сейчас объясню. Вобщем, это каталог с музыкой, в котором ее можно оценивать, ставить лайки и делиться ею с друзьями. А главное, все это бесплатно!
— А ну понятно. Ладно, я пошел, до встречи.

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

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

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

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

Любой проект по разработке — это время команды, которое мы продаем. Значит, менеджеру, который делает предложение клиенту, нужно получить часы с разбивкой по видам деятельности и этапам, потом перевести их в деньги. Для этого мы делаем табличку (готовый пример ниже), в которой:

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

В статье «12 тыс рублей за сайт. Есть ли бизнес за МКАДом?» я писал про наш подход к разработке сайтов на базе разработанной внутри компании технологии. На момент написания той статьи, мы выпускали «под ключ» 24 сайта в месяц. Это больше чем один сайт в день силами команды из 8 человек.

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

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

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

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

LaTeX годится не только для составления всевозможной документации, но и для верстки качественных презентаций. При помощи пакета beamer можно создавать презентации, ничуть не уступающие презентациям PowerPoint или Impress.

В конце апреля я делал доклад на РИФ 2012 про этапы проектирования пользовательского интерфейса. Так как видео нет, попробую представить доклад в виде слайдов с моими комментариями.



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

В данной статье мне бы хотелось поговорить не только о подготовке и проведении презентации, но и об организации мероприятий в целом. У многих из нас хоть раз в жизни возникает необходимость организовать мероприятие того или иного масштаба, будь то встреча, мастер-класс, семинар или презентация. В мою жизнь так называемый ивент-менеджмент прочно вошел с началом трудовой деятельности в ИТ-компании: организовывая мероприятия по 3-5 раз в год (от встреч проектировщиков интерфейсов до семинаров по электронным библиотекам), я составила чек-лист необходимых для этого дел. Хочу поделиться им с хабражителями и помочь нуждающимся не наступить на грабли, часто встречающиеся на этом непростом, но увлекательном поле деятельности.

В сжатом виде он выглядит так:

• Решить, кто наши докладчики и потенциальные участники, а также что, где и когда первые расскажут вторым
• Исчерпывающе и понятно написать о событии на своем сайте
• Анонсировать событие в СМИ и социальных сетях, пригласить клиентов и партнеров
• Заблаговременно открыть регистрацию участников
• Заранее получить презентации докладчиков и тезисы выступлений
• Обеспечить стабильно работающий интернет, звук, свет, ПО и другое оборудование
• Заснять доклады и дискуссии на видео
• Организовать досуг участников после мероприятия
• После события написать письмо с благодарностью участникам и докладчикам
• Ознакомить с материалами события тех, кто не смог принять в нем участие
• Составить детализированный отчет о событии
• Собрать фидбек и учесть все ошибки при организации следующего мероприятия

За подробностями, советами и примерами — под кат.

Заранее спасибо за дополнения! Самые актуальные добавлю в статью с указанием авторства — глядишь, так и составим универсальное пособие для организаторов событий.

Upd: дополнила статью советами из комментариев! Спасибо за помощь AndreiYemelianov, RGaifutdinov, mivanova, ollystar, Cancel, verbinka, mujaji.

Автор книги «Быть гиком» Майкл Лопп (Michael Lopp) о рабочих собеседованиях, подозрительной профессии менеджера и о том, как вовремя уволиться.

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

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

Примерно к такому выводу в итоге приходят системно мыслящие (system thinkers) — категория сотрудников, к которым Майкл Лопп относит и себя. Лопп является гиком. Он тот, кто любит порядок и предсказуемый результат. И он понимает, что системно мыслящие люди могут столкнуться с уникальным давлением в офисе.

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

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-сентябрь 2011. В связи с повышенной конференционной активностью этой осенью вышла пауза с публикациями, но дальше такого наплыва мероприятий не будет.

10 августа на youtube появился ролик под названием «Будущее началось», никакого масштабного пиара, судя по количеству просмотров (80+) на момент публикации топика, он не получил, а ролик-то весьма достойный по нескольким техническим параметрам:

— очень гиковая/scifi анимация
— отличный утопический текст, который заставляет все 15 минут смотреть ролик, не отвлекаясь.
— безупречная дикция

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


P.S. Я не имею никакого отношения к ролику. Просто считаю, что он интересен хабралюдям с технической и болтологической точек зрения.

P.S.2 В комментариях все, ожидаемо, пустились в дискус на тему утопий. Но давайте прагматики добавим, какова цель этого ролика? Что предположительно будет на том ресурсе?

Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат G7 на странице 59. Мы включаем RunKeeper, когда катаемся на велосипеде, чтобы узнать среднюю скорость и похвастаться в твиттере. Мы используем софт каждый день. Наверное, бОльшую часть жизни мы уже проводим в обнимку с любимыми гаджетами и программным обеспечением, а не с любимым человеком.

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.

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

Разберем, какой оседлать собственное подразделение разработки и добиться успеха.