Инструменты | Владимир Бычко об управлении проектами

Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Категория: Инструменты

Как в гугл календаре сделать событие на последний день месяца

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

Зачем это может понадобиться? У меня, например, множество банковских счетов и на пять из них в конце месяца начисляются депозитные, это нужно проконтролировать.

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

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

BEGIN:VCALENDAR
BEGIN:VEVENT
DTSTART:20240131
DTEND:20240131
RRULE:FREQ=MONTHLY;BYDAY=SU,MO,TU,WE,TH,FR,SA;BYSETPOS=-1;WKST=SU
SUMMARY:Name of your event
END:VEVENT
END:VCALENDAR

Затем для полей DTSTART и DTEND прописываем дату старта события. Одну и ту же дату. То есть, если хотите, чтобы событие начало происходить с последнего числа января 2024 года, пишем 20240131 в оба поля.

Затем в поле SUMMARY пишем название вашего события.

Сохраняем с любым именем и расширением txt.

Затем заходим в гугл календарь, жмём на звёздочку настроек, заходим в настройки, затем в «Импорт и экспорт», указываем календарь, в котором нужно создать событие, импортируем свежесозданный текстовый файл.

Всё. Событие появляется в календаре, можете ему добавить описание.

Как отключить автосохранение в wordpress

Изображение с unsplash.com, автор Onur Buz

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

Как с этим бороться? Я вычитал такой рецепт. Открываем:

ваш домен → wp-content → themes → название вашей темы → functions.php

И вписываем туда код:

// Отключаем автосохранение
add_action( 'admin_init', 'disable_autosave' );
function disable_autosave() {
wp_deregister_script( 'autosave' );
}

Об этом способе пишут на многих сайтах, но он почему-то не работает.

Единственный способ реально избавиться от автосохранения в БД — выставить очень длинный период автосохранения. И для этого нужно лезть в другой файл. Открываем:

ваш домен → wp-config.php

И вписываем туда инструкцию:

/** Интервал автосохранения в секундах **/
define('AUTOSAVE_INTERVAL', 10000 ); 

После этого описанное выше поведение больше не будет вас беспокоить. Нет, вводить 0 смысла нет, в этом случае автосохранение будет каждую секунду.

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

Но если у блога несколько авторов и они пишут каждый день по несколько постов, у вас засрётся БД. Давайте ограничим количество редакций. В тот же самый wp-config.php вписываем:

/** Количество редакций в штуках **/
define('WP_POST_REVISIONS', 20);

Всё, теперь количество редакций каждой записи ограничено двадцатью.

14 вещей, за которые я не люблю Evernote и его разработчиков

Evernote, почему это плохой софт.

Впервые я познакомился с Evernote в начале десятых и не понял, зачем он нужен. Просто не было потребности. Но уже через несколько лет устроился аналитиком в Ultimate Guitar и мне потребовалось собирать статьи про интерфейсы и юзабилити, чтобы делиться ими с коллегами. Хотелось, чтобы статьи хранились локально и не пропадали с гибелью родительских сайтов. Эвернот подходил идеально. Сначала пользовался веб-версией, потом поставил десктопную, чтобы работать быстрее. Стал хранить в нём чек-листы своих оперативных заданий, потом завёл блокнот для результатов работы, делился блокнотами с руководителем. В общем, всё было чудесно.

Вот, например, благодаря Эверноту, у меня сохранились скриншоты функциональных подсказок, которые мы пилили больше месяца:

Через некоторое время я решил использовать Эвернот и для личной базы знаний. Завёл блокноты для всякой личной информации, вроде гарантийников и чеков за разные покупки, фотографий интересных рекламок, статей, которые мне показались интересными. Места в 60 мегабайт в месяц, конечно, не хватало и я впервые в жизни купил подписку на ПО:

Счёт за первую в моей жизни подписку на ПО.

Годовая подписка с тех пор подорожала до 4 292 ₽, более чем в 4 раза.

Ещё немного старых документов. Вот, например, счёт на десктопный ПК, купленный в 2013 году:

Накладная на персональный компьютер из 2013 года.
Вот такие цены были в 2013

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

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

Постепенно в Эвернот переехало и всё остальное. Появился блокнот «Ссылки» для хранения закладок на интересные веб-сервисы, «Алиэкспресс» про заказы с Алика, «Здоровье» со всякими медицинскими данными, «Банки» с банковскими договорами и инфой о счетах и многое, многое другое.

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

Так почему же мне не нравится Эвернот и я хочу плакать после каждого нового апдейта? Потому что с тех пор у них что-то случилось и они стали планомерно клиент ухудшать.

Давайте разбираться.

Групповые операции с тегами

Одной из базовых возможностей клиента всегда были теги. И всегда было можно организовать иерархию тегов с неограниченными уровнями вложенности (в блокнотах только два уровня вложенности). Например, у меня есть тег «Авторы», под который засовываю теги с фамилиями авторов книжек из блокнота библиотеки. Так вот, в старых версиях клиента была возможность выделить несколько тегов и переместить под родительский одним движением. Хотите посмотреть, как это происходит сейчас?

Видите? Мало того, что из-за того, что теги нельзя выделить и переместить разом, их приходится таскать руками поодиночке, так ещё и в одном из трёх перетаскиваний зачем-то раскрывается родительский тег и его нужно закрывать.

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

Дальше будет много виджетов с видео, убираю под кат.

(далее…)

Как убрать из admin bar wordpress ненужные пункты

Каждый админ wordpress-блога сталкивался с тем, что нужные плагины пихают свои пункты в admin bar (это такая чёрная панелька вверху сайта, которая отображается администраторам). Эти пункты там совершенно не нужны и занимают полезное место.

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

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

Сначала щёлкаем правой кнопкой на этом пункте и открываем инспектор:

Видите айдишник элемента? wp-admin-bar-gutenverse

Важный момент. Из названия айдишника „wp-admin-bar-gutenverse“ удаляем „wp-admin-bar-“ и тогда всё заработает.

Скопируйте его куда-нибудь.

Шаг второй. Лезем по FTP на свой хостинг и открываем:

ваш домен → wp-content → themes → название вашей темы → functions.php

Вставляем туда следующий код, где gutenverse — айдишник вашего пункта:

add_action( 'wp_before_admin_bar_render', 'remove_item_from_admin_bar', 99 );
function remove_item_from_admin_bar() {
	global $wp_admin_bar;
	$wp_admin_bar->remove_menu( 'gutenverse' );
}

Если хотите удалить ещё какой-нибудь пункт, например, нафиг там ненужного Aioseo, добавляйте новую строку вот так:

add_action( 'wp_before_admin_bar_render', 'remove_item_from_admin_bar', 99 );
function remove_item_from_admin_bar() {
	global $wp_admin_bar;
	$wp_admin_bar->remove_menu( 'gutenverse' );
	$wp_admin_bar->remove_menu( 'aioseo-main' );
}

Собственно, это всё, что вам нужно знать об удалении пунктов из admin bar.

А теперь бонус. Если хотите, чтобы admin bar автоматически скрывалась и отображалась при наведении курсора, ставьте бесплатный плагин Auto Hide Admin Bar и будет вам счастье.

Изображение с zazzle.com

Что менеджеру проектов нужно знать об ИСР

Изображение с диска «Реклама и коллаж», автор Lynn Stephenson

Несмотря на то, что проектами можно считать и простенькие активности, состоящие из трёх-четырёх работ, в реальных проектах их обычно сильно больше. Даже для простенького мобильного приложения можно выделить до сотни конечных работ. Для их представления нужна ИСР, иерархическая структура работ или, по-английски, WBS, work breakdown structure. В этой статье подробно разберём все аспекты подготовки этого проектного артефакта.

В целом, всё просто. Проект разбивается на отдельные работы до тех пор, пока не получатся атомарные задачи. Насколько мелкими должны быть конечные задачи? В каждой компании свой подход к этому. Кто-то требует, чтобы задача умещалась в 8 часов. Кому-то достаточно, чтобы задачу мог выполнить один сотрудник.

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

Я использовал Minjet MindManager для составления этой карты. Так удалось не упустить ни одного аспекта переезда. Значком мигалки помечены крайне важные работы, но можно использовать и более продвинутую приоритизацию.

Что же касается «взрослых» проектов, термин был впервые употреблён в 1993 году в США.

Теория

Графическое представление ИСР выглядит нагляднее, чем обычный список, благодаря возможности сворачивать и разворачивать узлы структуры.

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

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

Также ИСР позволит выявить связи между работами.

Обычно её создают во время инициации и уточняют в процессе планирования. После вам лишь останется держать её в актуальном состоянии.

Важные принципы составления ИСР

Иерархическая структура работ проекта строится на следующих принципах:

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

Алгоритм создания ИСР

Можно создавать ИСР в одно лицо, но я обычно привлекаю аналитика на начальных этапах и лидов компонентов (фронт, бэк) на более поздних (для нормальной декомпозиции). В целом же, порядок таков:

  1. Идентифицировать конечную цель проекта, по идее, это должен быть некий уникальный продукт. И разместить эту цель в корне иерархии.
  2. То, что мы сделали на предыдущем этапе, декомпозировать на понятные и достижимые компоненты первого уровня. И разместить их на первом уровне.
  3. По тому же принципу сформировать второй, третий уровень. Четвёртый — это уже многовато, если вы задумались о четвёртом уровне, может быть, стоит разбить проект на подпроекты?
  4. Назначить ответственных за каждую работу.
  5. Готово, вы восхитительны ♥️

Крайне важно, чтобы работы были смартовыми.

Крайне важно сделать систему кодировок работ. 1 для корня, 1.1 для первого уровня, 1.1.1 для второго и так далее.

Формы представления ИСР

Если это (требования, отчёт, план) не помещается на одной странице – никто этого не поймёт.

Марк Ардис

Stevens Institute of Technology

Очень важно, чтобы ИСР удобно и читабельно отображалась. Мне известны следующие форматы представления:

  • Контурная структура. Просто список с уровнями. Самая простая в разработке и самая неудобная для просмотра структура.
  • Иерархическая таблица. Делается в экселе или гуглодоках. В первом столбце корень, во втором — первый уровень, во втором — второй. Когда уровни заканчиваются, в таблицу можно занести ответственных оценку и всё, что пожелаете. Тоже относительно просто делается, в использовании немного удобнее предыдущего варианта.
  • Древовидная структура. Делается в программах для деловой графики, Visio для обладателей компа на винде, Draw.io для всех остальных. Или можно использовать софт для майндмапов. Графически представляем все уровни, появляется возможность сворачивать и разворачивать узлы. Это уже совсем удобная штуковина.
  • Диаграмма Ганта. Это следующий этап работы. ИСР с проставленными ответственными, связями, оценкой сроков. Обычно делается в Microsoft Project. Я когда-то делал в Merlin Project.

В целом, это всё, что пиэму нужно знать об ИСР.

Интересные плагины Chrome

Изображение со старого диска «Реклама и коллаж», автор zfoxillustrative12

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

Сначала расскажу про активные плагины, а потом про отключенные, которые держу про запас.

Активные

Clearly Reader — Your reader mode solution 3.0.3

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

Плагин не конфликтует с Evernote Clipper. Вы можете сначала активировать Clearly Reader и заэвернотить страницу в упрощённом режиме, она заэвернотится корректно. Хорошо работает на страницах, из которых клиппер зачем-то копирует километр ненужного контента.

Copy Unicode URLs 0.0.20

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

Evernote Web Clipper 7.33.1

Плагин позволяет отправить в Evernote любую страницу. Я обычно отправляю упрощённую статью, иногда закладку. Сложную страницу можно отправить в заметочник целиком. Раньше он глючил и иногда отказывался отображаться, но его починили и сейчас он вполне исправен. Кроме основной функции, позволяет из контекстного меню страницы отправить в заметочник понравившуюся фотографию. Также умеет отправлять туда же отдельные pdf-документы.

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

LastPass: Free Password Manager 4.116.0

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

minerBlock 1.2.18

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

NoClickjack 2022.7.6.1

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

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

Чтобы предотвратить кликджекинг, установите расширения для браузера. Например, No ClickJack для Google Chrome и NoScript для Firefox. Это надёжные и бесплатные плагины: они автоматически показывают скрытые веб-слои, которые захватывают ваш клик и перенаправляют на опасные сайты. Используйте их — и спокойно кликайте по любым сайтам.

Return YouTube Dislike 3.0.0.9

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

Save Image As PNG 1.0.2

Я понимаю плюсы формата вебпак, но современный софт пока с ним очень плохо работает. Плагин нужен для сохранения вебпаковских картинок в нормальные png в два клика.

Speed Dial 2 Новая вкладка 3.6.2

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

SponsorBlock для YouTube — Пропускайте спонсорские вставки 5.4.7

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

Todoist для Chrome 11.1

Плагин даёт возможность добавить текущий сайт в качестве задачи в Todoist.

Video DownloadHelper 7.6.3.3

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

VK Comment Blocker 1.2.2

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

Скачать музыку 2.0.2

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

Отключённые

GoFullPage — Full Page Screen Capture 7.9

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

Google Mail Checker 4.4.0

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

RANDUS.ORG – генератор случайных личностей 1.5.1

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

Screencastify — Screen Video Recorder 2.75.0-b78123fb8

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

Командное голосование методом Fist to Five

Изображение с unsplash.com, автор Element5 Digital

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

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

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

👊 Закрытый кулак означает сильное несогласие или полное «нет».

👆 Один палец указывает на огромные сомнения по поводу предложенного решения. 

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

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

🤘🤘 Четыре пальца означают согласие, но с некоторыми мелкими сомнениями.

🖐️ Пять пальцев демонстрируют полное согласие, энтузиазм по поводу решения, отчётливое «да».

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

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

Я всё же противник голосований, но если голосовать — то методом Fist to Five.

Автор изображения Евгений Полухин

Что менеджеру проектов надо знать о пушах

Изображение с unsplash.com, автор Jose Antonio Gallego Vázquez

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

Изначально эта технология не имела отношения к мобильным устройствам и использовалась для рассылки уведомлений о судебных событиях подписчикам этих событий. Ещё с её помощью слали новости фондового рынка биржевым торговцам. Чуть позже, во время войны браузеров, Майкрософт и Нетскейп внедрили пуши в свои браузеры, но по ряду причин тогда взлетела технология RSS. Ещё чуть позже её внедрили Гугл и Эппл в свои мобильные операционки и вот тогда она уже заработала нормально.

Дальше немного технических деталей.

APNS

На устройствах Apple для работы с пушами используется сервис APNS. Через него пуши отправляются как на iOS, так и на OS X (через Центр уведомлений) и OS X Server (отправка почты, календаря и контактов на устройства пользователей сети).

Схема работы APNS, картинка с Хабра.

Важный момент — для получения сообщения APNS, приложение-адресат необязательно должно быть запущено, пуш придёт в любом случае.

GCM

А на Android-устройства пуши отправляются при помощи гуглового сервиса GCM. Кроме того, через GCM пуши могут отправляться в приложения и расширения для Chrome.

Схема работы GCM, картинка с mavink.com

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

Пуши с точки зрения юзабилити

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

Форма уведомления. У сервисов пушей есть ограничения по размеру сообщения (2 килобайта для APNS и 4 килобайта для GCM) и по времени, которое пользователь готов потратить на его прочтение. Размещайте в тексте пуша значимое сообщение, например, как Яндекс Еде: «В честь вашего дня рождения, дарим промокод EDA24 на бесплатную доставку заказа от 800 руб.»

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

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

Звук уведомлений. Настройте свой, неповторимый. Чтобы пользователь знал, что новое сообщение пришло именно от вашего приложения. Такой звук есть, например, у приложения ВТБ, его пуш не перепутаешь ни с каким другим. Это тоже может стать преимуществом.

Оптимальной работы push-уведомлений можно добиться, объединив их на единой платформе с другими каналами связи, такими как электронная почта, SMS и голосовые звонки. Комплексный подход к коммуникации с клиентом сделает этот процесс бесшовным и эффективным.

В целом, это всё, что пиэму нужно знать о пушах.

Автор изображения — Анастасия Ермакова.

Что менеджеру проектов надо знать о Kanban

Пример Kanban-доски
Изображение с unsplash.com, автор Jo Szczepanska

История и суть явления

Метод появился в компании «Toyota» в 1959 году. К айти имеет косвенное отношение, почитать про него можете в Википедии.

Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.

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

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

Канбан-доска

Главный принцип Канбана — визуализация при помощи канбан-доски. Рассмотрим её подробно.

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

Правее очереди следует расположить колонки допроизводственных этапов, на которых происходит сбор требований, оценка и утверждение задачи. Дальше идёт черта — точка принятия обязательств. Если задача пересекает эту черту, это означает, что она передана в производство и совершенно точно должна быть сделана и влита в продукт.

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

Пример канбан-доски с scrumtrek.ru

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

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

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

WIP-лимиты

WIP (work in progress) — это количество элементов, находящихся в работе в настоящий момент. Его не надо путать с WIP-лимитом, ограничением на количество элементов в работе на настоящий момент времени, введённым для достижения некой цели.

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

Использование WIP-лимита повышает определённость в работе. Потому что чем больше элементов в разных состояниях, тем тяжелее ими управлять и контролировать.

Для того, чтобы посмотреть максимальный WIP-лимит по команде, потребуется отчёт CFD (cumulative flow diagram) или накопительная диаграмма потока. 

Пример накопительной диаграммы потока с darvindigital.ru

Каденции

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

Канбан-митинг

Пятнадцатиминутная ежедневная встреча. Команда собирается и обсуждает:

  • Что нам мешает?
  • Как осуществляется поток работы?
  • Что мы можем улучшить?

Очень важно обсудить все заторы и затруднения в работе над задачами. Возможно, кому-то из участников нужно оказать помощь.

Встреча по пополнению

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

Обзор сервиса поставки

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

Встреча по планированию поставки

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

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

Обзор рисков

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

Обзор операций

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

Обзор стратегии

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

Метрики в Канбане

Важнейшая метрика в Канбане называется Lead Time — время прохождения задачи от точки принятия обязательств до точки отдачи обязательств. Чем быстрее задача проходит от одной точки до другой, тем команда эффективнее. Кроме того, есть ещё такие метрики:

  • Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
  • WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
  • Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
  • Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
  • Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).

Делаем правила явными

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

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

Кейс внедрения канбана в реальной практике

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

Оказалось, что отдел использует TFS (сейчас Azure DevOps Server), однако совершенно бессистемно. Кто-нибудь из руководства заводит запрос на доработку, вешает его на рандомного разраба и заказчики ждут у моря погоды. Если какой-то запрос нужен срочно, ответственный внедренец прибегает к руководству департамента и начинает орать. CIO транслирует ор в программиста, он в приоритетном порядке запиливает доработку. Тестировать её некогда, поэтому она сразу накатывается на базу заказчика. Если возникают проблемы, они никак не регистрируются, внедренец просто приходит в отдел SQL, подсаживается к программисту и просит поправить.

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

В первую очередь было принято решение визуализировать очередь. Хотелось использовать веб-приложение, потому что внедренцы крайне не любят ставить сторонние приложения (лол) и вообще, большую часть времени проводят в аутлуке. Выбор пал на trello. Первоочередной задачей стало завести на трелло-доске все открытые запросы на доработку из TFS. Trello тогда умел создавать карточки на основании писем, отправленных на специальную почту, а TFS умел экспортировать воркайтемы в эксель. Мой разраб минут за сорок накидал VBA-скрипт, импортировали запросы.

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

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

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

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

kanbanize.com, в отличие от trello на тот момент поддерживал свимлайны. То есть, можно было завести для каждого разраба дорожку, а колонками сделать уже актуальные статусы, что сильно ближе к нормальному канбану. Кроме того, этот сервис позволял добавить кастомные поля к каждой карточке, что было для нас очень важно, так как кроме TFS-идентифкатора, каждый запрос имел CRM-идентификатор, которыми оперировали внедренцы.

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

Автор изображения Steven Reddy

Семь айти-практик, которые стоит завести в команде

Изображение с unsplash.com, автор Hal Gatewood

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

Гит

На проекте я тимлид,
В мастер пушу свой коммит, 
У меня на это есть
Полный доступ в гит.

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

Код ревью

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

CI/CD

Эту загадочную аббревиатуру нужно внедрять в третью очередь, когда гит и код ревью уже заработали. Даёт великое множество профитов — возможность гибко управлять правами доступа, автоматизировать ручные действия и самое главное, возможность нормально масштабироваться. Без CI/CD в случае резкого всплеска нагрузки вам останется только развести руками.

Прозрачный процесс постановки задач

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

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

Руководитель изрыгнул в чат баг или очередную светлую идею — ответственный сотрудник заводит тикет в таск-трекере и скидывает в чат номер. Исключений нет.

Одна задача = одна ветка в гите.

Крупные задачи нужно дробить на мелкие. А для мелких заводить отдельные ветки. Причина проста. Если вы решите вести в одной ветке 10 задач и срочно потребуется релизиться, вы не сможете это сделать, если хотя бы в одной будет критичный баг. Если вести задачи в отдельных ветках, вы совершенно спокойно зальёте 9 рабочих веток с 9 рабочими задачами и обрадуете стейкхолдеров и пользователей.

Автотесты

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

Мониторинг ошибок

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

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

Вот, в целом, и все полезные практики, которые вам нужно завести в свежем стартапе чем раньше, тем лучше.

Автор изображения Kendall Hale