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

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

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

Как убрать из 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

Фреймворки и всё, что менеджеру проектов нужно знать о них

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

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

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

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

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

Классификация фреймворков

Бэкенд-фреймворки

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

Например, при помощи Django вы можете сделать админку с гридами, о которой я писал выше. Это фреймворк на питоне.

Ещё можно выделить:

  • Symfony, Laravel — PHP;
  • Express.js — JavaScript;
  • Ruby on Rails — Ruby.

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

Фронтенд-фреймворки

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

  • Angular;
  • Vue.js;
  • Svelte;
  • React — формально это не фреймворк, а библиотека, но значение этого инструмента так велико, что его постоянно сравнивают с другими веб-фреймворками.

Фуллстек-фреймворки

Сюда относятся фреймворки, реализующие как клиентскую, так и серверную часть. Например, JS Meteor.

Возможности фреймворков

Веб-кеширование

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

Скаффолдинг

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

Шаблонизация

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

Безопасность

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

Сопоставление URL

Вообще, это механизм интерпретации URL-адресов. Нужно для упрощения индексации с сохранением красивого названия для сайта. Например, URL-адрес, который заканчивается на «/page.cgi?cat=science&topic=physics», можно изменить на просто «/page/science/physics», удобно и красиво же.

Приложения

Возможность разрабатывать стандартизованные приложения — форумы, блоги, CMS.

Важное для менеджера

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

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

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

1
1
1

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

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

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

Кроме того, в вашем продукте может потребоваться реализовать дорогостоящую функцию, которая уже сделана в стороннем сервисе на отличненько. Например, если вам нужны карты, целесообразно использовать API Open Street Map или Яндекс.Карт, это сильно дешевле, чем пилить собственные карты.

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

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

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

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

Различия REST и SOAP

Чаще всего в современной разработке встречаются REST и SOAP API. Давайте разберём, в чём разница.

REST

REST (от англ. Representational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

Предполагает использование протокола HTTP для передачи данных.

Применяется преимущественно в вебе и в мобильных приложениях.

Ещё используется в облачных вычислениях.

Через REST API могут передаваться разные форматы данных, но обычно используется JSON.

Предполагает кэширование передаваемых данных.

Хорошо масштабируется.

SOAP

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC).

При помощи SOAP данные могут передаваться не только через HTTP, но и, например, MQ.

Применяется, преимущественно, в Enterprise, для интеграции нескольких отдельно стоящих систем.

Данные передаются только в формате XML.

Данные не кэшируются.

Типы запросов

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

  1. GET
  2. POST
  3. PUT
  4. PATCH
  5. DELETE

GET – используется для получения со стороны севера определенного ресурса. Если вы производите этот запрос, сервер ищет информацию и отправляет ее вам назад. По сути, он производит операцию чтения на сервере. Дефолтный тип запросов.

POST – нужен для создания определенного ресурса на сервере. Сервер создает в базе данных новую сущность и оповещает вас, был ли процесс создания успешным. По сути, это операция создания.

PUT и PATCH – используются для обновления определенной информации на сервере. В таком случае сервер просто изменяет информацию существующих сущностей в базе данных и оповещает об успехе выполнения операции.

DELETE – как и следует из названия, удаляет указанную сущность из базы или сигнализирует об ошибке, если такой сущности в базе не было.

Postman

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

Есть публичное API для смешных переводов, например, эндопоинт для перевода на язык Мастера Йоды находится по адресу: https://api.funtranslations.com/translate/yoda.json

Эндпоинт принимает только один строковый параметр text. Отправим Постманом GET запрос на этот эндпоинт:

Интерфейс Postman с простым GET-запросом к API
Интерфейс Postman с простым GET-запросом к API

Как видите, API возвращает такой ответ:

{
    "success": {
        "total": 1
    },
    "contents": {
        "translated": "Force be with you yoda,Polovec helloy you",
        "text": "Hello Yoda, Polovec helloy you",
        "translation": "yoda"
    }
}

Как нетрудно понять, эндоинт возвратил код успеха, а в поле контента передал три значения:

  • translated — переведённый текст.
  • text — исходный текст.
  • translation — тип переводчика.

По такому же принципу работают любые REST API, только в реальных запросах параметров больше и они сложнее.

Применение в реальной разработке

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

Может сложиться так, что проект будет совсем маленьким и проектирование API поручат вам. Для такого случая предлагаю вам пример API спроектированного мной для мобильного приложения для операций с топливом.

Разное

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

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

Вот ещё хороший документ про API от пользователя Koray OKE:

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

Манифест прожект менеджера

В Манифесте:

  • Методологии человеческим языком
  • Арсенал инструментов PM
  • Технические и продуктовые нюансы
  • Метрики
  • Рекомендации по созданию культуры в команде
  • Про CI/CD
  • Шаблоны
  • Вопросы к собеседованиям и т. д.

За документ спасибо Александру Коновалову.