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

Открытые вакансии на должность разработчика в Яндексе есть всегда. Компания развивается, и хороших программистов не хватает постоянно. И претендентов на эти должности тоже хоть отбавляй. Главная сложность – отобрать действительно подходящих кандидатов. И в этом плане Яндекс мало чем отличается от большинства крупных IT-компаний. Так что базовые принципы, описываемые в этой статье, могут быть применимы не только к Яндексу.

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

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

В жопу спецификации!

Привет, Хабр!
Аккурат к инициативе поддержки стартапов, озвученной deniskin, мы в ФРИИ продолжаем знакомить сообщество с темой бизнес-инкубаторов и акселераторов. В прошлой статье мы детально разобрали, в чём различие между бизнес-инкубаторами и акселераторами. Сегодня — расскажем о том, куда же, собственно, идти.

Исследовательская компания Gartner хорошо известна на рынке аналитики информационных технологий. Я бы даже сказал — является одним из лидеров этого рынка. Ежегодно она выкладывают крайне интересный график, именуемый «Цикл зрелости технологий» (в англ. Hype cycle, или дословно – «цикл шумихи»). На этом графике, в хронологическом порядке, разложены технологии, которые либо уже готовы к применению, либо только-только вступают в стадию исследований.

Вот так выглядит график на 2013 год (выполнен по состоянию на июль 2012 года):


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

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

Наша команда занимается разработкой интерфейсов для четырех крупных проектов: Яндекс.Картинки, Яндекс.Видео и их версий для смартфонов. Разработка верстки поисковых сервисов в Яндексе обладает своей спецификой. Задачи стекаются с разных сторон: от менеджеров, разработчиков бэкэнда, поиска, проявляются баги и т.д. Внедряются новые фичи, требующие отображения в верстке. Все это стекается в наш таск-трекер (JIRA).

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



В конечном итоге большинство наших проблем удалось решить при помощи Agile Board и Scrum, но пришли мы к этому далеко не сразу, а поэтапно.