Правила эффективного создания прототипа продукта

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

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

Жаловаться – здоровью вредить

image

Когда собираетесь пожаловаться, следите за тем, что вы при этом говорите. Не всегда слова, выражающие недовольства, помогут почувствовать себя лучше. В этой статье Stephanie Vozza, расскажет, как жаловаться правильно, чтобы получить результат. (далее…)

Повесть о том, как студентики за ночь сайт запилили

Поздний час, половина первого…

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

Первым делом определились в необходимости составления регламента встречи. Начали с тайминга – окончание в 5 утра, обязательные перерывы. Ваня вспомнил про методику Pomodoro – идея всем понравилась, и мы ее тут же применили.
(далее…)

Альтернативная энергетика получила $2 трлн инвестиций за прошедшие 10 лет

В докладе, подготовленном Программой ООН по окружающей среде (UNEP), Фракфуртской школой финансов и управления и Bloomberg говорится, что только за прошлый год объем инвестиций в энергетику на основе возобновляемых источников (в первую очередь на базе солнечных установок и ветряных генераторов) составил порядка $270 млрд, показав рост 17% год от года. Всего же с 2004 года во всём мире в альтернативную энергетику было вложено около $2 триллионов, лидируют Китай, США и Япония.
(далее…)

Объединить противоположности для решения одной задачи

Для достижения той или иной цели всегда требуется решить те или иные задачи, которые неизменно будут присутствовать. Когда мы говорим о цели, определение задачи выглядит не в виде вопроса «Есть задача или нет», а «Сколько здесь задач». Это правило является основополагающим и не требующим доказательств, как аксиома в математике. Всегда понятие цели должно сопрягаться с понятием задачи: задачи → цель. Приведу несколько примеров для наглядного применения этого правила.
(далее…)

3 фактора, которые создают разрыв между веб-дизайнерами и разработчиками, и способы их устранения

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

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

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

4 причины, по которым дизайн покоряет Силиконовую Долину

4 причины, по которым дизайн покоряет Силиконовую Долину - 1

Растет ли значение дизайна в Долине? Джон Маэда, партнер венчурного фонда Kleiner Perkins Caufield & Byers, уверен, что да. Во время презентации на South by Southwest 2015 он заявил, что Долина не просто начинает относиться к этому серьезнее, а оказывается захвачена дизайном. Вот четыре причины, по которым самые успешные технологические компании будущего будут, по сути, дизайнерскими.

(далее…)

4 совета для тех, кто во время ротации оказался в службе поддержки

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

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

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

Гибкие процессы и распределенные команды — секреты мастерства

Гибкие процессы и распределенные команды — секреты мастерства - 1

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

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

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

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

Итак, в чем проблема распределенной команды? Коммуникации. Затруднены коммуникации на всех уровнях, что порождает веер проблем. Та самая «транспортировка», которая упомянута как один из компонентов waste (потери) в концепции Lean Software Development.

Я для себя выделила три составляющие проблемы коммуникаций:

  • Техническая: если человека рядом нет, к нему нельзя просто взять и подойти, чтобы обсудить какие-то текущие проблемы.
  • Мотивационная: если у команды нет своей комнаты, где перед глазами есть доска со стикерами, списком проблем и остальной полезный контекст, фокус и приоритеты начинают «плыть».
  • Психологическая: люди, которые не сидят рядом и не видятся каждое утро, обсуждая за кофе последние новости или успехи детей в школе, менее склонны прощать ошибки коллегам, особенно если про коллегу они знают только логин в системе контроля версий и e-mail. Может возникать концепция «мы и они» по отношению к коллегам из другого офиса и прочие неприятные штуки
  • Отдельным пунктом стоит адаптация Scrum-активностей под распределенную команду.

(далее…)

«Яндекс» запускает «Путешествия»

Компания «Яндекс» в собственном блоге сообщает о запуске нового сервиса под названием «Яндекс.Путешествия».

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