Мы открыли набор в новый Tolstoy Startup Camp. Это мастерская Яндекса, где мы помогаем запускать стартап. Она будет уже четвертой по счёту. Предыдущие три дали много не только его участникам, но и нам — мы поняли, как и что можно изменить в кемпе. В первых трех наборах мы были готовы работать с самыми разными проектами в сфере IT при условии, что нам нравилась идея, мы верили в команду или видели потенциал для развития бизнеса.

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



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

Один из них — Анатолий anatolix Орлов, который работает в Яндексе уже почти 10 лет. Первые два года в Яндексе он писал Маркет, а потом долго занимался производительностью поиска. Второй — Костя Горский, арт-директор Яндекс.Браузера. Он в Яндексе чуть больше четырех лет. Недавно его команда представила новую концепцию Браузера.
Читайте под катом не только их разные мнения, но и подробности о кемпе.

После завершения создания игры-головоломки на Unity и выпуска ее на Google Play и AppStore, появилось желание поделиться опытом и впечатлениями. И получить конструктивные замечания и предложения, если таковые возникнут

Приветствую, Хабрахабр!

В этой статье я постараюсь приоткрыть завесу над интересной технологией из области управления бизнес-процессами ( BPM). Интеллектуальный анализ процессов ( Process Mining) фокусируется на обнаружении, анализе и оптимизации бизнес-процессов на основе данных из журналов событий (англ. event logs), представляя недостающее звено между классическим анализом бизнес-процессов с использованием их моделей и интеллектуальным анализом данных ( Data Mining).




Рисунок 1. Позиционирование Process Mining.

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

Привет, Хабрахабр!

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

Никому не нравятся лаги. Любой человек, сталкивавшийся с ними, подтвердит это. А что если вы сами станете «лагать»?

Оптоволоконный интернет-провайдер ume.net снял рекламу, в которой четыре добровольца в течение 2 дней носили Oculus Rift. С установленной камеры и микрофона в очки и наушники «испытуемых» передавалось изображение и звук окружающего пространства. Изюминка заключалась в задержке видео- и аудиопотоков. Сначала их передача человеку отставала на 1/3 секунды, а потом аж на 3 секунды. О том, каково это, «тормозить по жизни», и рассказывает нам этот любопытный ролик. Рекламный посыл вполне очевиден.

Опасность — это реальность, страх — это твой выбор. х/ф «После нашей эры»

Два месяца назад (в марте) на TED появилось выступление канадского астронавта Кристофера Хэдфилда.
(Того самого астронавта, что спел песню под гитару на борту МКС. «Эта песня — само воплощение романтики покорения космоса.» пишет Lenta.ru)

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

За месяц видео набрало 1 000 000+ просмотров. А вот русской транскрипции еще нет.
Так как на Хабре «Космонавтика» является достаточно востребованной темой, думаю что найдется несколько хабражителей, которые помогут с переводом.
Транскрипт лекции разбит примерно на минутные отрезки(всего 13 кусочков). Предлагаю взять по одному, перевести и выложить в комментах (только не повторяйтесь).
Призываю так же вносить свои рекомендации в уже готовые версии перевода.

(видео на английском с английскими субтитрами. 16:45 — Крис исполняет красивую песню «Space oddity»)

Итак, сейчас 16-58, за какое время Хабр справится с переводом?

UPD: Ролик с МКС теперь вне закона

Под катом — английский транскрипт, в комментах — перевод.

Как-то раз позвонил мне один мой друг фотограф и задал очень интересный вопрос: “Что если повесить какую-нибудь фото-мыльницу на радиоуправляемый вертолёт и попробовать как-то снимать этой мыльницой с воздуха?”
А я, помнится, с раннего детства мечтал о радиоуправляемых летательных аппаратах, но жил в так называемой “глубинке”, поэтому дальше детских чертежей в этом деле я не продвинулся тогда. В этот раз с ходу я ответить ничего не смог, но т.к. тема меня вдруг заинтересовала (а кого не заинтересует?), я пообещал разобраться с вопросом и созвониться позже.

После выхода статьи «Как мы в Alconost организовали работу без офиса» меня часто спрашивают, как сделать так, чтобы удаленные сотрудники работали как единый слаженный механизм. Напомню, в команде Alconost около 20 “непроизводственных” сотрудников (менеджеры проектов, маркетологи, программисты) и более 300 сотрудников-исполнителей (переводчики, редакторы, дикторы, видеодизайнеры). Все работают удаленно, по свободному графику, без контроля отработанного времени.

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

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

Известно, что контуры проектного управления как современной научно-инженерной дисциплины начали оформляться в 50-х годах XX века в США. В этот период было положено начало методике календарно-сетевого планирования.

Однако не стоит забывать, что еще в 20-х годах активными темпами развитие проектных технологий шло и у нас. Страна с крупнейшей в мире плановой экономикой, СССР с 30-х годов прошлого столетия начал реализовывать ряд масштабных проектов, а названия некоторых стали известными на весь мир.

Немногим известно, что в СССР существовала отдельная дисциплина под названием «Научная организация труда» (сокращенно – НОТ), включавшая в себя ключевые методы и инструменты проектирования, которые успешно применяются сегодня в PMBok.

Но обо всем по порядку.

Меня зовут Митя Куркин, я руковожу разработкой iOS мессенджеров Mail.Ru Group. Сегодня я расскажу о нашем опыте ускорения приложений на iOS. Высокая скорость работы очень важна для 99% приложений. Особенно это актуально на мобильных платформах, где вычислительные мощности и, соответственно, заряд аккумулятора весьма ограничены. Поэтому каждый уважающий себя разработчик стремится оптимизировать работу своего приложения с целью устранения различных задержек, из которых складывается общее время реакции.

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

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

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

4. Мастера на все руки

О программе Sketch я узнал еще год назад. Скачал демо тогда еще 2-й версии. Признаться, она меня совершенно не впечатлила. Какой-то слишком простой показалась. Я привык к навороченным интерфейсам софта от Adobe, а расположение панелей в стиле Apple iWork (Pages, Numbers, Keynote) мне по какой-то причине не нравится. К тому же мне оказалось комфортнее работать с темным интерфейсом, каковой нынче есть в Photoshop CC. Плюс Sketch 2 был достаточно кривоватый, содержал немало досадных багов, да и вообще впечатления не оказывал скоростью работы. В общем, поигрался с демкой и благополучно забыл. Впрочем, оказалось, что зря…

В предыдущей статье я вывел формулу успешности приложения. Под приложением я понимаю простую, казуальную игру, разработанную под iOS. Что-то вроде тетриса, кроссворда, судоку, 2048, японского дурака, косынки. На создание которого уходит неделя программисткого труда. Для проверки формулы необходима достаточно большая статистическая выборка — порядка 10.000 честно загруженных приложений. Я попытался решить эту задачу при помощи обзоров на 4-х русских и 2-х зарубежных площадках. Кроме того, отследил в первой версии программы наиболее популярные нажатия на кнопки, убрал второстепенные элементы управления, учел замечания игроков и получил следующие результаты.

План – это не идеальная картина, а навигация по проекту

Почему когда вы едете на машине и попадаете в только что возникшую пробку, то ваш навигатор пересчитывает маршрут и время движения по нему, а управляя проектом, вы отказываетесь от такого полезного инструмента?
Когда реальная картина на проекте складывается не так, как было запланировано, то его руководитель начинает выстраивать в голове другие маршруты и перестает ориентироваться на первоначальный план.
Уверен также, что вам знакомо следующее мнение. План – это идеальный сценарий, в действительности все бывает по-другому, поэтому ориентироваться на план невозможно. Авторы подобных тезисов под словосочетанием «план проекта» подразумевают только первоначальный план (Базовый план). Но замечу, что проект должен также иметь другой план — Рабочий план, который будет учитывать все изменения в проекте и являться вашим навигатором по проекту. Такой инструмент будет показывать вам:

• Ак туальное расписание всех задач
• Узкие места
• Прогноз завершения проекта (этапа)

Используя рекомендации, приведенные в статье, вы научитесь легко оживлять ваши рабочие план-графики, находить проблемные места, прогнозировать достижение конечной цели. Тем самым вы качественно улучшите навыки планирования и контроля, что повысит вашу эффективность минимум на 20%!

Настройка статусов задач

Вам один раз нужно настроить программу (MS Project), используя формулы, приведенные в конце статьи, и графические индикаторы.
После чего вы сможете регулярно использовать простой и эффективный инструмент.
Итак, рассмотрим статусы задач, которые нам предстоит настроить.

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

Уровни управления проектом

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

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

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

Я разработал около сотни проектов, в том числе — стартапов. Многие из них достигали пика и умирали, некоторые работают до сих пор. Делал как B2C, так и B2B.

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

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

1. Важнее всего — желание

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

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