Этот ваш хваленый ИИ ничего не может

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

Мы тут с Лёхой думаем над внешкой нашей бэхи - то ли менять цвет, то ли оставить как есть, но добавить цветные акценты.

Попросил дать мне картинку конкретной модели авто в конкретном цвете. Рисует не тот цвет. Прошу поправить - отвечает "я не могу создавать изображения, зато могу помочь составить промт в другую нейронку". Что, блин? Это точно самая умная и универсальная модель? Вы можете себе представить в 00-х, чтобы поисковик на запрос "купить пластиковые окна в москве" вам отвечал "я такое искать не умею, но вот вам запрос покруче, дуйте с ним в другой поисковик - "+окна пвх|пластиковые +купить где:москва""?

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

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

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

П.С. Сегодня рубрику #лёха_строит_бэху пропускаем, так как не хватило времени позаниматься бэхой на этих выходных. В субботу был в командировке, а в воскресенье отмечали Лёхин ДР с семьей (кстати, ему стукнуло 8, можете поздравить в комментах, я передам).

Питон

Это не только 3-4 метра ценной кожи, но и прекрасный язык программирования (душноту "вообще-то Пайтон!" отпустим в форточку).

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

А тут кто-то рассказал, что py3 с async-await и, соответственно, aiohttp на uvloop, в целом, в состоянии держать приличные нагрузки. Что ж, пришлось пробовать. Снова из соображений "а что это у нас все плюсы да плюсы", мы засучили рукава и за несколько дней создали сервис, названный котопсом. Кажется, вдвоем с Сашей. Думаю, он работает и по сей день (котопёс, не Саша. Хотя, Саша тоже работает).

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

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

Осенью какого-то там года (2018 или около того) я свалился с орви или гриппом. Лежу с температурой, сплю. Звонок - мониторинг. Еще звонок - коллеги. Спрашивают, а где котопес? В смысле где, в продакшне. А нету. Просто пропал. Сон при температуре 39, но нет - не сон. Оказывается, у оркестратора деплоя, действительно, была сломана функция удаления окружения в течение нескольких месяцев. И тут они ее починили. А она пошла разгребать очередь накопившихся задач. И просто удалила окружение, которое все это время было уже боевым.

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

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

А если вы уже и так клёвый - у нас есть вакансии питон-разработчиков.

Яндекс - уже не торт.

Яндекс - кондитерская. И в ней есть много отделов - торты, конфеты, пирожные, и даже ЗОЖ-десерты. Каждый найдет себе сладость по вкусу. Кому-то поддерживать уровень сахара в организме необходимо для здоровья. Для кого-то - это guilty pleasure. Кто-то просто любит пожрать. Но в кондитерской все - счастливы.

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

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

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

Как я уже писал ранее, алгоритмы все еще нужны. Нет, правда нужны. Что не отменяет секции прикладного кодинга.
Вайб-кодинг практикуем, но на собесах лучше обходиться своей головой.
Нет, нас не заменит ИИ, и промтп-инженеров пока не нанимаем.
От тимлидов все еще ожидаем написания кода, но еще важнее - technical excellence в команде.
Для более всесторонней оценки компетенций подробно говорим про опыт.
А объективность повышаем через ревью секций.
Стажеров, кстати, тоже нанимаем!

Вакансии, по-прежнему, тут - ждем вас!

Да сколько можно отчитываться то?

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

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

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

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

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

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

Тут важно еще уметь "обналичивать" эффекты от задач. Особенно, если речь о большом, долгосрочном и комплексном проекте. Тут лучше избегать реализаций в духе "пан или пропал", когда по окончании проекта либо ты получаешь outstanding результат, либо "просчитались, но где". Полезно делить проект на вехи так, чтобы промежуточные результаты уже начинали приносить пользу. И по этим промежуточным эффектам корректировать план.

Мысли в этом после инспирированы (а местами - целиком украдены) рассказом моего коллеги Никиты - CPO клиентского продукта Лавки.
Никита серьезней, чем кажется, а еще он ведет классный канал, в котором делится своей мудростью, но не слишком давит софистикой.
Братский рекомендасьон - @nikita_tolstoy

Курсор и его друзья (тесты)

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

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

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

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

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

На собственной шкуре

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

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

Даркстор - это небольшой склад, с которого продукты доставляются непосредственно вам. Эти сторы - на то и дарк, что скрыты от глаз стороннего наблюдателя. Хотя внутри, на самом деле, светло. Их адреса хоть и не афишируются (вам не нужно знать, где они), большой тайной не являются - их нетрудно обнаружить по скоплению голубых курьерских велосипедов рядом с ними. А рядом с некоторыми еще гнездятся роверы - роботы-доставщики, развозящие заказы в нескольких районах. Дарксторов у нас сотни, из них >100 - в Москве. Каждый обслуживает район в несколько км2 - чтобы от склада до любой точки было несколько минут езды на эл.вело - нам нужно держать срок доставки в пределах 15-20 минут с учетом сборки.

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

А пока представим себе, что кладовщик - партнер сервиса - пришел на смену. Например, я. Основной рабочий инструмент кладовщика - ТСД (терминал сбора данных). Он напоминает толстый смартфон со сканером штрих-кодов, на котором крутится приложение, разрабатываемое моей командой - Полка. Эргономика самого ТСД и приложения должна быть выверена максимально - счет времени сборки 1 позиции измеряется секундами. Вот я залогинился в свой ТСД, который мне выдали с зарядки, и на экране уже первые заказы.

Беру в работу 2й. Потому что 1й - с доставкой ровером, и надо будет выходить на улицу, чтобы положить его в отсек робота-доставщика. Это пусть делает Серега, с которым мы пошли в поля, он еще в куртке. Заказ в работе, и я уже вижу на экране первый товар. Указан № стеллажа, № полки, наименование sku, товарная фотография. Иду по указанным координатам и сразу вижу нужный товар - роллтон с курицей.

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

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

Все позиции собраны, и Полка зовет на упаковку. На специальном столе я пишу на пакете номер заказа, упаковываю его и кладу на стеллаж у выхода, откуда его заберет курьер. И сразу беру следующий заказ. За полтора часа я собрал 17 заказов (avg 3.5 мин), в которых было 73 товара (avg 28 сек). После этого я, довольный и со списком доработок Полки, ушел в офис.

Догфудинг - добро. Ходите "в поля". To be continued.

HRBP

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

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

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

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

Что им позволяет быть такими ценными для команды? В первую очередь - развитые софты. Эмпатичность, понимание людей и "третье ухо", чтобы слышать несказанное. Во многом HRBP - почти что психологи. Они могут выявить проблемы у ребят, найти правильный подход к каждому, проработать и поднять мотивацию. К ним приходят плакаться, жаловаться, хвастаться (но чаще - плакаться). HR-партнёр должен быть и “человечком рядом”, и профессионалом, который не растворяется в проблеме, а помогает найти решение. Они могут диагностировать выгорание и помочь его остановить. Реально - психологи. Только в отличие от врачей-психологов - они погружены в твои проблемы изутри и варятся в тех же процессах, а значит - лучше тебя понимают. И от того - тоже могут выгореть. Так что берегите своих HRBP.

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

На днях общался с одним из моих прежних HRBP из Еды - Настей. Она была партнером моей команды полтора года и помогла нам пройти через огонь, огонь и еще огонь. Сейчас Настя как раз помогает выгорающим айтишникам и пишет про это у себя в канале - @zmtkidgvch - братский рекомендасьон. Вот этот пост прям все объясняет.

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

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

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

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

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

Техноцель - по сути, это все, что не исходит от продукта/бизнеса напрямую.
 
Оно может появляться из разных (И)сточников:
1. Изнутри команды. Чаще всего, вам самим видней, что болит, и во что нужно проинвестировать. Тут вам нужно уметь объяснить "чтобы что". Например, мы хотим потратить месяц на рефакторинг сервиса Х, потому что сейчас разбор каждого дьютика по нему занимает час+, а после рефакторинга мы сможем дать техсапу тулинг самостоятельного разбора жалоб.
2. От руководства. В рамках какой-то стратегии или вижена. Руководство тоже должно объяснить "чтобы что". Например, переписать легаси-сервис Х на стек У, потому что найм разработчиков на стеке У дешевле и мы хотим в перспективе переходить на него.
3. От инфры. Обычно связано с какими-то масштабными переездами/стройками. Тот редкий случай, когда аргументации "чтобы что" может не быть. Например, переезд в новый оркестратор деплоя, потому что старый закапывают (а вот с хрена ли, и кому станет лучше - не всегда легко выяснить, но сделать с этим иногда ничего нельзя).
 
Другой разрез целей - их условный (Р)азмер/продолжительность. Тут цели бывают
4. Маленькие. То, что можно сделать за 1-2 спринта. Просто сделайте и не любите голову, как их оформлять и отчитываться, дольше расписывать. Просто если это важное, предупредите соседние команды, кому полезно знать, и, может, расскажите о результатах на техновстрече, если есть что поведать. Например, "а кстати - мы тут запилили клевый линтер, можете переиспользовать".
5. Небольшие. Делаются за квартал или два. Их надо нормально описать и защитить, они составляют костяк утилизации техноквоты. Например, написать драйвер для постгреса под ноду.
6. Большие. Занимают больше полугода, иногда год-два. По ним нужно самое четкое описание и обоснование. Их нужно делить на этапы/вехи/майлстоуны. Иногда можно сразу весь проект расписать на несколько кварталов вперед, но чаще - ближайший этап описывается подробно, а последующие - верхнеуровнево. Важно, чтобы ближайший этап был четко обозрим, конечен, и должен уже приносить пользу даже до окончания проекта целиком. Например, распил очередного монолита.
7. Вечные. Это те направления деятельности, которыми нужно в той или иной степени заниматься перманентно - иногда более интенсивно, иногда менее. Например, выполнение метрик technical excellence, ZBP, secutity error budget. Тут важно четко понимать, где сейчас что западает, куда сильнее навалиться.
 
С точки зрения (П)ланируемости - тут все просто, есть всего два типа.
8. Можно запланировать заранее. Мы заведомо знаем, что это надо делать. Например, адопшен какой-то технологии.
9. Влёты. В планах не было, но внезапно появилась такая потребность. Например, уперлись в производительность какого-то куска и надо его оперативно сделать более масштабируемым.
 
Еще один срез - (С)рочность. Выделим три варианта:
10. Асап. Надо брать задачу вот прямо сейчас. Например, уязвимость 0 дня.
11. К определенному сроку. Например, к моменту вступления в силу какого-нибудь определенного закона.
12. Не важно когда, просто надо сделать. Например, перейти с самопального решения на какую-то поддерживаемую библиотеку.
 
И последнее - (В)ажность.
13. Крит. Нельзя не делать, есть сильный негативный эффект от не-делания. Например, баг, блокирующий функциональность.
14. Важно. Есть понятный положительный эффект от задачи. Например, тыква, которая снижает потери при инцидентах.
15. Nice to have. Лучше сделать, но не болит. Например, перейти на новый ci, потому что в нем есть какая-то фишка.
16. Можно не делать. Если цель попадает в эту категорию, лучше ее сразу закрыть. Ну а нафига.
 
Теперь, собственно, давайте разбираться, какое должно быть целеполагание и процесс трекинга целей в зависимости от их попадания в ту или иную комбинацию срезов выше. Тут буквально 288 вариантов получается, давайте их все раскидаем по форматам работы с целями. Шутка. Или нет?

Техноцели (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, там отвечаете на пару вопросов о себе, бот ищет вам собеседников. Выбираете собеседника по душе, выбираете слот, созваниваемся по зуму. Среди возможных собеседников - эксперты Городских сервисов Яндекса (разработчики, руководители, но и не только), включая меня. На встречах можно обсудить технологии, конкретные кейсы и обменяться опытом - в целом тематика общения не сильно ограничена. Заходите, поболтаем!