Памятка будущему PM

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

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

Однако я вынужден вас разочаровать – они не работают в жизни. Совсем не работают.

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

Об этом речь и пойдет далее.

Ешё больше ресурсов удобных и полезных. Большая подборка для тех, кто проводит время с умом (почти всегда).

Я почти закончил чтение книги, написаной Джоном Сонмезом (известный блогер, разработчик ПО и автор множества курсов Pluralsight) — «Soft Skills: The software developer's life manual». Должен сказать, что книга очень легко читается, она полна ценных советов и в большой степени практична. И время от времени она смешная. В книге множество интересных разделов, но сегодня я хотел бы выжать наиболее интересные мысли из раздела, посвящённого продуктивности.

Мы перевели и адаптировали оригинальную подборку книг на тему стартапов. Уверены, что она пригодится как начинающим предпринимателям, так и тем, кто работает над своим очередным проектом.

Собираем подборку вместе. Будем рады добавить книги согласно вашим предложениям, которые было бы удобнее всего высказать в комментариях.

Доклад с прошлогодней конференции специалистов системного и бизнеса анализа — Analyst Days 2013 года от старшего аналитика питерского офиса компании DELL — Петрашева Дмитрия

На странице доклада можно найти презентацию и видео, а здесь текст…

Зачем вообще нужны бизнес аналитики

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

Не стоит преследовать цели, которые легко достичь. Стоит нацеливаться на то, что удается сделать с трудом, приложив немалые усилия — Альберт Эйнштейн

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

Пару недель назад в Москве прошла AgileDays-2015 — самая крупная в РФ конференция по современным методам управления в разработке.

• Два дня, пять треков, огромные залы московского Центра Международной Торговли (не путать с WTC).
• Темы:
  • Agile-менеджмент — от высокоуровнего управления разработкой в неповоротливых компаниях-монстрах, до «бережливого старта» в стартапах.
  • Продуктовый аспект — как не только правильно разрабатывать, а творить именно нужное и правильное.
  • Специфические вопросы процессов и технологий — тестирование и бизнес-анализ, юзабилити и проектирование.
  • Современные архитектурные практики — *DD, и даже немного о функциональном программировании.

Вращаясь в «продвинутых» кругах часто кажется, что Agile-подходы уже «захватили весь мир», и хватит уже говорить о понятном и общеизвестном. Но в реальной жизни, все конечно гораздо запущенней — есть успешная когорта «early adopters», и как видно в широко известной картинке «дилеммы инноватора», далее идет большая пропасть, и либо те, кто совсем не в курсе, либо кому про Agile «все понятно, ибо сосед-Рабинович напел». Это видно даже по ряду недавних публикаций на мегамозге. Поэтому реальный, и даже не всегда успешный, опыт от тех, кто в теме и нашел и все грабли, и кучу ништяков — очень полезен, и гораздо более актуален, чем даже книги, как правило уже устаревающие к моменту публикации. Докладчики — не евангелисты, а практики, из крупных компаний и стартапов, хотя да, были и консультанты, рассказывающие о «сгибании несгибаемого» — типа аджайлизации банков.

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

И я, как член программного комитета, заботящийся о том, чтобы докладчики донесли свои знания до всех заинтересованных, попробую сделать серию публикаций, включающих и видео доклада, аннотации и слайды, и мой очень краткий постобзор. Слона надо есть по частям — еще готово не все видео, смонтированное надо еще отсмотреть и отрефлексировать, да и большие статьи отпугивают своим объемом и читателей и писателей — стыдно признаться, что я, за несколько заходов, но так и не смог дописать за год эпический обзор 72 видеодокладов с прошлого AgileDays-2014, и даже обзор 2011 осилил только через полгода. Конечно же, обзор Agile-конференции надо делать итеративно, максимально быстро отгружая value потребителям. И, как принято в Agile, возможно даже прекратить поставки, если продукт не понравится пользователям…

Итак, смотрите и решайте — такой формат ОК или нет…

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

Примечание переводчика: Перевод первой статьи из блога «A Year of Productivity» был благосклонно встречен хабра-сообществом, и меня попросили перевести еще несколько статей из этого блога. Приведенная ниже статья — самая большая и самая близкая к практике, её перевод затянулся у меня на несколько месяцев. Как и прошлый раз рекомендую читать комфортными порциями, записывая (или копируя куда-нибудь) советы, которые хочется попробовать применить на практике.

«Хаки» времени

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

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

Для начала вот несколько моих любимых приемов по тому как:
-  получить больше времени;
-  тратить время на правильные вещи.

Весной этого года я узнал о возможности базы данных HP Vertica создавать запросы с матчингом паттернов событий. Так называемый Events Pattern Matching хорошо ложился под задачу анализировать поведение пользователей в продуктах ivi.ru. Мы решили попробовать разобраться с воронками оплаты, с поиском проблемных мест на устройствах, глубже погрузиться в анализ трафика. Нашей команде очень нравится, как реализована аналитика у Mixpanel и Localytics (она как раз основана на событиях и их свойствах), поэтому многие идеи были позаимствованы у них.

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

Одной из самых важных вещей в GTD является сила воли. Без нее вы не будет доводить дела до завершения, любая выбранная вами система не буде работать. Первый же приступ лени не даст вам заглянуть в список дел. GTD, todo list, канбан доска — это всё инструменты. Мы про них много читаем, учимся их использовать, даже программируем. Только самый важный инструмент, который всегда при нас, это сила воли.

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

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

UPD: Обновленная видеоверсия статьи на Youtube (лекция записана в Киевском политехническом институте 18 апреля 2019 года в рамках курса «100 видео-лекций по программированию»):

Сегодня речь пойдет о том, какую роль в Интернет-поиске играет лингвистика. Чтобы поместить это в контекст, начну с того, как связаны между собой лингвисты и большая поисковая компания, например, «Яндекс» (более 5000 чел.), «Гугл» (более 50 000 чел.), «Байду» (более 20 000). От трети до половины этих людей работают непосредственно на поиск. Лингвисты внутри этих компаний примерно поровну делятся между поиском и остальными направлениями — новостями, переводом и т.д.



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

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

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

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

Добрый день, Хабр!

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

Веб разработчикам нужно настраивать сервера. Обычно под каждый проект. С тех пор как я научился делать это без помощи гугла, настройка перестала быть чем-то интересным, и хотелось её максимально автоматизировать.
Первой идеей было создание виртуальной машины и копирование её при необходимости. Схожие конфигурации настраивать стало проще, но каждый раз когда что-то в конфигурации менялось, приходилось заходить на сервер и настраивать его. Хотелось большего.
Путем проб и ошибок я пришел к связке Vagrant + SaltStack, где Vagrant берет на себя изоляцию окружений, а SaltStack – управление конфигурацией.

С момента перехода с PHP 4.4 на PHP 5.3 в Badoo прошло уже 4 года, пришла пора обновлять PHP, на этот раз сразу на версию PHP 5.5. Помимо новых фич, новая версия PHP в очередной раз принесла нам существенное увеличение производительности, поэтому у нас было много причин для апгрейда. В этой статье мы расскажем о том, как мы переходили на PHP 5.5, какие «грабли» собрали, и зачем в очередной раз переписывали нашу систему для запуска юнит-тестов на основе PHPUnit.


Рис 1. Общая архитектура

«Грабли» при переходе с PHP 5.3 на PHP 5.5

В прошлый раз мы переходили с четвертой версии PHP на пятую, причём наша версия PHP 5.3 содержала патчи, чтобы работал «старый» синтаксис PHP, например, $a = &new ClassName();, и чтобы наша кодовая база могла работать на PHP4 и PHP5 одновременно. На этот раз у нас таких ограничений не было, поэтому при переходе мы просто нашли и заменили все устаревшие конструкции на более актуальные, и на этом переписывание кода было закончено.

Основные проблемы, которые у нас возникли:

• часть deprecated-фич языка была убрана;
• расширение mysql стало deprecated;
• низкая производительность расширения runkit, которое мы используем при написании юнит-тестов.

После перехода на PHP 5.5 наши юнит-тесты начали проходить значительно дольше (в несколько раз), поэтому мы решили в очередной раз доработать нашу «пускалку», чтобы решить эту проблему.