Новый закон по Accessibility софта в Европе

Летом в Европе вступает в силу закон о доступности European Accessibility Act (EAA). Под его действие попадает любой бизнес, у которого есть сайт или приложение. Проверьте, не касается ли вас, а я расскажу немного деталей.

Чтобы выполнить требования закона, нужно соответствеовать стандарту WCAG 2.1 на уровне АА. Это главный в мире стандарт доступности, разработанный умными дядьками из World Wide Web Consortium еще в 1999 году.

Штрафы за невыполнение закона могут быть в районе 5-20К. А в Ирландии даже могут посадить в тюрьму!

Есть ли тут деньги

Еще как!

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

▫️в США живет 61 миллион человек с ограниченными возможностями.

▫️70% из них выбирают продукты, в которых есть поддержка доступности.

▫️Расходы людей с ограниченными возможностями, составлют $8 трлн ежегодно.

Рынок есть, и немаленький, осталось научиться на нем зарабатывать.

Какие требования нужно выполнить

На практике, комплайенс означает поддержку 55 требований WCAG в продукте.

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

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

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

Инструменты для разработки

Бесплатные тулы, которые сделают аудит вашего приложения или сайта:

▫️Accessibility Inspector, iOS;
▫️Accessibility Scanner, Android;
▫️Lighthouse, web.

Встречи без экшн айтемов

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

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

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

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

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

▫️один думал, что данные соберут аналитики.
▫️у аналитиков в этом спринте времени нет.
▫️а данные по проблемным сессиям у нас, оказывается, вообще не логируются.

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

Менеджерский трюк: вынести проблемный скоуп в отдельный майлстоун

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

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

И вот трюк:

🎩Поддержку лендингов выносим в отдельный майлстоун-Б.

Обосновываем так:

Когда мы закладывали 2 месяца на проект, то исходили из того, что лендинги заведутся легко, из коробки. Но оказалось, что они не поддерживают мультиязычность. Поэтому наш майлстоун-А все еще ЗЕЛЕНЫЙ, а поддержку лендингов мы сделаем позже, в майлстоуне-Б.

Формально проект был перевести весь сайт, и лендинги входят в его скоуп. По-хорошему, надо оставлять лендинги в майлстоуне-А и красить его в КРАСНЫЙ.

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

В продуктовой компании посмотрят, что на лендинги ходит 5% пользователей, и скажут, что главная цель – перевести сайт – выполнена на 95%, вот и славно.

«Торги» скоупом – обычное дело на любом проекте. Трюк именно в том, что бы отделить проблемный скоуп от основной работы. Так, им легче потом торговать, а проект остается ЗЕЛЕНЫМ.

Команда не вкладывается в оценки. Что делать?

Представьте, что приходите менеджером в новую команду. Быстро понимаете, что есть проблема с деливери – команда успевает завершить 60-70% того, что пообещала.

Что будете делать?

Вот буду делать я:

▫️проверю, как именно собирается статистика.

▫️спрошу у команды, в чем главная причина на их взгляд.

▫️проверю описание задач, понятно ли из них, что делать.

▫️проверю, что фичи разбиты на задачи размером хотя бы в 1-2 дня.

▫️уточню, самостоятельно ли команда дает оценку или кто-то делает это за нее.

▫️проверю, что в итерацию заложено время на риски и непрограммирование – встречи, тестирование и т.д.

▫️проверю, не успевает вся команда или 1-2 человека.

90% команд, с которыми мы работали над улучшением деливери, имели по крайней мере одну проблему из списка выше.

Бесконечно можно смотреть на 3 вещи:

▫️как горит огонь
▫️как течет вода
▫️как продакт переносит рефакторинг в следующий спринт

“Совет директоров” проекта (Steering Comittee)

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

Раз в месяц главные представители собираются вместе, чтобы обсудить, как идут дела. Типо, как “совет директоров” проекта.

Такая встреча называется Steering committee, обычно сокращают до SteerCo.

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

Ценность стирко в принятных решениях.

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

———

Если знаете подходящий перевод для steering comittee – напишите в комментах.

Замечать успехи команды (Recognition)

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

Например:

▫️”Ребята, настраиваю трекинг задач на проекте на 100 команд. Есть удачные примеры?”.
“Спроси Анну, она построила супер удобный трекинг для проекта Х в прошлом году”.

▫️”Я вычитаю твой документ до пятницы. Кстати, хочу сказать спасибо за то, как ты затащил тот проект без особой поддержки”.

▫️”Поздравляем Алекса с повышением до Senior product manager. Он сделал проекты А, Б и Ц, которые вырастили конвесию в…”. Такие письма менеджер Алекса отправляет на всю компанию.

Бывает, ответ на какой-то вопрос топа начинается издалека, и человек дает явно лишних продробностей. Но даже тут:

▫️“Спасибо, что объяснил, как работает сервис аутентификации. Не знал, что у него столько клиентов. Сейчас я хочу узнать о …”

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

Вообще, хвалить в публичном пространстве – важная роль топов. На этих сообщениях и строится культура компании.

Улучшенная версия реестра рисков – RAID

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

Это реестр рисков.

Иногда, кроме рисков хочется записать и другие штуки.

Например, что другая команда нам висит кусок скоупа (зависимость). Или, что субподрядчики задержали поставку фичи уже на 2 недели (проблема). Или, что мы считаем, что требования нового закона “переводятся” в вот такие фичи (допущение).

Для таких “расширений“, есть хороший формат – RAID.

RAID это тоже табличка, куда вносят:

R – risks (риски);
A – assumptions (допущения),
I – issues (проблемы);
D – dependencies (зависимости);

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

Еще такая табличка помогает рефлексировать над проблемами – полезно открыть перед ретрой или когда делаешь SWOT-анализ.

Пример заполненного RAID для проекта “next day delivery” 👇

Этим сообщением я закрепляю за собой авторское право на всю информацию, опубликованную в этом канале.

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

Когда до последнего ждешь встречи с дорогими коллегами

Джира + гугл таблицы = бомбические отчеты

Недавно делал трекинг для своей программы.

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

К моему большому удивлению, соединить джиру с таблицами, можно только через API ключ. А его еще поди получи у ИТ секьюрити.

Спасением стал вот этот плагин. Все, что он делает – вытаскивает задачи по JQL фильтру и записывает их в таблицу. Получается ряд колонок из джира-данных: статусы, даты закрытия, assignee.

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

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

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

Держи в голове вопрос

Я постоянно сталкиваюсь с ситуациями, где спросили одно, а человек отвечает на другое.

Например:

⁃ Какие задачи вы закроете, если мы добавим человека вам на проект?

⁃ Понимаешь, этот проект вылетает с первого дня, требования неточные, стейкхолдеры по неделе не отвечают…

⁃ [так а задачи? 🫠]

Еще это очень распространенная ошибка мок-интервью:

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

так а задача?

🫠]

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

Проблема в том, что мы порой забываем, о чем нас вообще спросили.

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

Если понимаю, что ухожу в дебри, то сам себе напоминаю вслух:

- Отвечая на твой вопрос, с дополнительным человеком, мы закроем эпики….

Или:

- Я наверное плохо объяснил, как связаны неточные требования и что дополнительно мы закроем. Давай объясню….

Эпик фейл

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

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

Пишу на русском: “Пашка, красава, что все разрулил! Он обычно хмуро отвечает, а тут даже похвалил“. Вскоре приходит ответ, тоже на русском: "Я не есть хмурый”. От заказчика. 🤦

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

Фейлы бывают у всех и это ОК. Через них хорошо учиться, например, проверять отправителя в письме.

Расскажете про свои?