Техноцели (3/4)

Берем вариант И1-Р1-П1-С1-В1, то есть внутренняя маленькая планируемая асап крит цель. Такие предлагаю пропускать мимо всех процессов. Потому что вряд ли ей кто-то будет интересоваться, задача срочная и важная, лучше сразу сделать и не тратить время на оформительство.
 
Впрочем, то же самое можно сказать про все маленькие цели. Просто если источник - руководство или инфра, а важность - крит или важно, задачу И[2-3]-Р1-П*-С*-В[1-2] нужно
а) точно сделать (не продолбать),
б) сказать об этом заказчику в свободной форме. То есть формализм с целями и планированием тут избыточен, если вы выполняете свои обещания и у вас норм коммуникация с заказчиком.
 
Прежде, чем приступать к планированию, нужно убедиться, что у нас есть актуальная стратегия технологического развития. Потому что если ее нет, не получится убедиться, что проекты в плане не отдаляют нас от целей. В стратегии должны быть зафиксированы какие-то таргет-стейты, целевой стек, чувство прекрасного, а также - утвержденные большие цели (Р3) на горизонте. И уже составляющие этих больших целей должны быть пригодны к планированию. Большие цели планировать бесполезно, их нужно декомпозировать с убывающей детализацией.
 
В стратегии стоит обозначать основные постулаты, что мы считаем хорошим и правильным. Каким требованиям должна верхнеуровнево отвечать система. Какие подходы мы практикуем. Эдакий манифест + таргет-стейт.
 
Про влеты. Очевидно, на то они и влеты, что запланировать их нельзя. Но нужно понимать, что они будут. А значит -
а) оставлять под них небольшой зазор (никогда не планируйтесь "под крышечку"! кстати, продуктовых целей это тоже касается),
б) при появлении влета максимально прозрачно уведомлять стейков тех проектов, которые сдвинутся из-за влета (и на гринлайте/чекапе тоже подсвечивайте).
Асап-криты (И*-Р*-П2-С1-В1) примерно все тут.
 
Про вечные цели. Тут тоже нет большого смысла упарываться в их оформление или планирование. Просто не продалбывайте их показатели, и всем будет все равно, как вы это делаете. Условно говоря, можно не ставить цель "повысить рпс-аптайм в сервисе Х", если на момент гринлайта там будет целевое значение.
 
Таким образом, воронка проектов, пригодных к планированию, состоит из небольших планируемых целей И*-Р2-П1-С*-В[1-3]. Уже не столь важен источник - для прозрачности работы и корректности учета капасити нужно планировать и внутренние задачи тоже. Размер проектов должен позволять уложить их в 1-2 квартала. Если больше - декомпозируйте.
 
Дальше осталось приоритизировать проекты, исходя из их срочности и важности. Тут уже можете сами выработать формулу отношения порядка. Но интуитивно - срочное-важное должно попасть в план с сильно большей вероятностью, чем бессрочный найс-ту-хэв. Рекомендую попробовать посчитать такую метрику как cost of delay - и брать в работу в первую очередь те проекты, откладывание которых стоит дороже. Но, очевидно, если задача асап - ее надо сразу брать в работу. Если есть конкретный срок, и он в планируемом ку, надо брать (если в следующем ку, но работы много - нужно брать уже в этот). И сначала критичное и важное. И уже потом полости в плане заполнять не-срочными и найс-ту-хэв вещами. Ими же можно заполнять полости в процессе квартала, например если не было влетов, а зазор остался.

Техноцели (4/4)

Кстати, о непосредственно работе над техноцелями. (Врочем, этот абзац в той же степени справедлив для продуктовых целей.) Если вы в команде распределяете цели/проекты по людям, которые в дальнейшем тащат их в 1 щачло, вы плохо работаете с рисками. Например, есть 4 человека в команде. И 4 цели/проекта. Если каждый человек будет делать свой проект, то к концу квартала вы рискуете подойти с 4 незаконченными проектами. Напомню, проект, законченный на 90% - это незаконченный проект. Даже если случится чудо, и все успеют закончить свои проекты, пользу от этих проектов мы начнем получать лишь с конца квартала. Не лучше ли сначала командными усилиями, вчетвером, затащить самый ценный проект и уже через месяц начать получать с него профит, потом командой затащить второй, и в середине квартала получать пользу от него, и так далее? Тут работает тот же cost of delay, быстрее обналичиваются эффекты, да и риски легче митигировать.
 
Любой прогресс нужно трекать. Для этого у нас есть ежемесячные гринлайты/чекапы.
Там мы смотрим вот примерно то же самое, что попало в планирование - И*-Р2-П1-С*-В[1-3].
Плюс иногда смотрим на большие цели - есть ли там изменение динамики вследствие успехов/неуспехов локальных вех.
Плюс там рассказываем о влетах и можем упомянуть про мелкие, но важные/интересные задачки.
В конце полугодия полезно собрать итоговый результат - по средним и большим целям, а также по метрикам вечных.
 
Также отмечу, про промежуточные точки контроля нужны не только для того, чтобы проветь свою успеваемость, но и для возможных корректировок планов. Чем чаще мы сверяемся, правда ли текущие усилия приближают нас к целевой картине, тем больше у нас возможностей адаптировать свой план к конъюнктуре момента. Короткая гранулярность сверки помогает быстрее поворачивать в нужную в моменте сторону.
  
Итого, я бы предложил два вида техноцелей - большие (цели) и небольшие (проекты).
Остальная техничка никуда не девается, но ее можно так явно не заводить и не трекать, лишь бы все работало хорошо (ну типа метрики, все такое).
Большие цели обязательно должны декомпозироваться на какое-то количество небольших проектов по принципу OKR - то есть мы верим, что вот такие проекты приведут нас к цели.
При этом не обязательно каждый небольшой проект должен быть привязан к какой-то большой цели, если он сам по себе обоснованно полезен.
Каждый проект должен иметь объяснимую пользу, желательно на метриках.
Если этот проект делается в рамках большой цели - он сам по себе тоже должен приносить частичную пользу.
Также удобно укладывать цели/проекты в дерево, чтобы было наглядней, в какие метрики оно бьет.
 
То есть флоу должен быть примерно такой:
 
стратегия -> цели (зачем?) -> проекты (как?) -> планы -> ... -> профит!!! -> статус-чек
 
Итого получаем каскад от ценностей к конретному плану с оценкой результата и профита. Как-то так.

304 Not Modified

Новостей по проекту #лёха_строит_бэху на этот раз мало.

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

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

И еще заказал новые хромированные ноздри. Потому что для бмв это святое) Попутно впервые воспользовался авито не как доской объявлений (когда звонишь продавцу и договариваешься о доставке), а как маркетплейсом (тыц в корзину, оформил, оплатил, получил). Посмотрим как пройдет.

Сферический код в вакууме

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

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

Но на днях я познакомился с одним человеком, у которого специфика работы не менее занятная. Его код работает ... в космосе! Он пишет ПО для спутников связи. Мне тут же стало интересно - какие ограничения накладывает эта специфика, в сравнении с обычными требованиями, когда код работает у тебя "в руках". Основной подход там - это отказоустойчивость, резервирование и способность к самовосстановлению. Потому что ты не можешь удаленно подключиться и что-то перезапустить (да, там нет kvm/ipmi). То есть система должна сама себя восстанавливать при любых сбоях. И рекомендуется не забывать оборачивать код в трай-кетч :). Уверен, это весьма интересно.

А в каких экстремальных средах работает ваш код?

П.С. А познакомился я с этим человеком через штуку, которая называется Сеньёрный разговор. И мне разрешили про нее вам рассказать. Вообще она пока в глубоком пилоте, мы ее анонсировали на нашем Yandex Tech Tour в Казани и Нижнем. Но вы (по секрету) сможете поучаствовать и поделиться фидбеком. Пилот продлится до 22 декабря. Также оговорюсь, что пока оно рассчитано только на разработчиков. Механика простая: идете в бота https://t.me/seniortalks_bot, там отвечаете на пару вопросов о себе, бот ищет вам собеседников. Выбираете собеседника по душе, выбираете слот, созваниваемся по зуму. Среди возможных собеседников - эксперты Городских сервисов Яндекса (разработчики, руководители, но и не только), включая меня. На встречах можно обсудить технологии, конкретные кейсы и обменяться опытом - в целом тематика общения не сильно ограничена. Заходите, поболтаем!

Восьмой класс, вторая четверть

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

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

Я аж сначала не понял, что он хочет сказать. А потом как понял! Для тех, у кого школьная програма по химии за 8 класс уже слегка заплыла рутинными эксельками, напомню: валентностью называют способность химического элемента образовывать связи с другими атомами. Она определяется числом электронов на внешнем энергетическом уровне. Чем больше у атома «свободных» электронов или незанятых мест для них, тем больше связей он может образовать. Думал ли я, что это знание поможет мне в работе? Пожалуй, нет. Я слово-то это, скорее всего, со школы не слышал.

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

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

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

str = 'Quoliti Ashurenes'

def test_str_correct():
assert len(str) == 17
assert str.count('s') == 2
wrds = str.split()
assert wrds[0][0]+wrds[1][0] == 'QA'
print('PASS\n')

И ведь тесты пройдут! Но что-то тут не так... Давайте разбираться.
Начну с моего любимого анекдота про тестирование. Англоязычную версию считаю первоисточником, поэтому привожу так:

A QA engineer walks into a bar.
Orders a beer.
Orders 0 beers.
Orders 99999999999 beers.
Orders a lizard.
Orders -1 beers.
Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is.
The bar bursts into flames, killing everyone.

(Фьюить-ха!) Так вот.
Есть тестировщики, которые вручную тестируют сервис по тесткейсам. Иногда - без тесткейсов, т.н. исследовательское тестирование.
Есть тестировщики, которые запускают автотесты и интерпретируют результаты. Или сами пишут автотесты, почему бы и нет.
И все они - молодцы и умнички, если того требует конъюнктура момента, команда, продукт, должностные инструкции.

Но есть еще QA-инженеры. Это уже немного другая лига. Что отличает хорошего куа-инженера?
- ориентируется в своем продукте как рыба в воде и точно знает, как продукт должен себя вести, и почему так;
- формирует тест-кейсы, притом на раннем этапе проектирования фичи (подход 3-амиго ftw!);
- участвует в поддержке продукта (л3-л4), чтобы хорошо понимать потребности пользователей;
- знает, что и как нужно проверить, чтобы на самом деле убедиться, что продукт работает как надо (а не как в примерах выше);
- умеет подбирать оптимальный метод проверки в соответствии с пирамидой тестирования (юниты, авто, интеграционные, е2е, ui-тесты);
- заинтересованно участвует в максимальной автоматизации процесса, но понимает ее границы применимости.

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

Но если и есть выделенные люди на задачи QA - они должны не просто тестировать, а двигать команду, продукт и процессы в сторону обеспечения качества. Что бы это ни значило (а значит оно в разных командах разное). Даже если для этого придется внедрять ИИ. Всем кволити!

"Ура, склад!" (с) Шарик

Продолжаем изучать Лавку изнутри. Недавно рассказывал про сборку заказов на дарксторе. Неочевидно, но сборка заказов - лишь 1 из 72 типов задач, которые выполняются на дарке (число не выдумано, у меня и табличка есть!). Есть еще тьма вещей, от приемки товара и размещения (про это немного упоминал тут), до переборки яиц и фасовки бананов. Большая часть задач выполняется через приложение Полка, которое разрабатывает моя команда.

Но кроме линейного складского персонала (кладовщиков) в каждой лавке есть еще старший смены, свой директор и его зам (на фото - как раз их рабочее место в том дарке, где я был), а также супервайзеры на несколько лавок. А в офисе есть еще толпа людей, в обязанности которых входит операционное управление лавками и работа с их показателями. Так вот для всех них у нас есть еще один продукт - админка WMS (warehouse management system).

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

И со всей этой фукциональностью работают каждый день тысячи человек. Тут важно отметить, что это не просто пользователи, которым хочется дать удобный продукт. Это люди, от эффективности работы которых напрямую зависит успех компании. Операционный продукт имеет огромное плечо влияния на бизнес-показатели. Там ведь и проверка качества, и обработка обращений, аудит, инвентаризация, маркировка, ТМЦ, акты, составление графиков. И все это нужно оптимизировать и автоматизировать (где-то даже с применением ИИ, что уж там). В общем, работы - непочатый край.

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