Shoo and Endless Agony

2022-08-23 20:09:33 Легаси процессы.

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

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

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

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

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

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

2022-07-17 22:11:13 Ну и раз уж мы затронули тему хайринга, минутка (само)рекламы:
В команде, с которой я работаю последние полтора года (и какое-то время ещё работаю), разыскиваются два QA инженера.

Про проект:
Уютный американский стартап Truv, который делает продукт в области employment и income верификации для финтеха, бэкграунд скрининговых агентств и других бизнесов.
Распределенная команда, продукт который быстро растёт, здоровая атмосфера стартапа (с эпизодическими пожарами по периметру), классная команда и много свободы в обмен на много ответственности.
Встраиваемый веб-виджет и селфсервис платформа, большое количество внешних интеграций, бэк на джанго, фронт на реакте, общение в слаке, тикеты в linear.

Кого ищем:
Мы ищем инженеров, которые возьмут на себя весь QA домен в выделенной им зоне ответственности - от обсуждения, декомпозиции и планирования задач с продуктовой командой, до пост-релизных проверок, определения и снятия метрик.
Вам придётся писать минимально необходимую тестовую документацию (или больше, если сочтете нужным) в Qase, проводить ассептанс тесты новых фичей и релизов, вместе с другими QA инженерами поддерживать и развивать автотесты на python + pytest (селениум для UI, requests + cerberus для апи), тюнить QA процессы в рамках своей команды и компании в целом, помогать делать QA процессы простыми, прозрачными, эффективными и минимально завязанными на QA инженеров.
Мы стремимся сводить к необходимому минимуму ручные проверки, но и ими придется заниматься, и здесь хочется видеть тиммейта, способного не только пройтись по требованиям (которых у вас, скорее всего, не будет), но и вообще оценить правильно ли мы делаем эту фигню и есть ли у вас, и остальном команды, понимание “зачем мы это делаем?”.

По требованиям и ожиданиям:
- Высокая степень автономности. Мы ищем человека, способного работать в self-driven режиме, с минимальным количеством супервайзинга и без пинков из вне.
- Соблюдение коммитментов. Мы не трекаем рабочее время, у нас довольно свободный график и всё, что мы ждем взамен - get things done. Коммитмент сделать что-то ко дню N значит, что нужно либо сделать, либо заранее предупредить почему не выходит.
- Понимание, как работают веб-сервисы, API, что такое REST и прочие базовые знания человека, которому придется работать с вебом.
- Опыт написания и поддержки автотестов для UI и API (очень хотелось бы, что бы это был пайтон) и здоровый прагматизм в них - без строительства ненужных космолетов, оверинжениринга и клепания бесконечных тестовых фреймворков.
- Готовность и способность отвечать не только за прогоны тестов, но и за весь QA домен - процессы, практики, критерии и метрики качества, прозрачность тестирования и пр.
- Готовность работать в условиях быстрых изменений, частых релизов, неявных требований и прочих аттрибутах стартапной жизни.
- Способность выражать свои мысли на английском языке, в письменной и устной форме.

Что предлагаем:
- Конкурентную зарплату в $ + опционы (вилки как таковой нет, верхняя граница где-то в районе 8k, но для настоящих рокстаров может и больше).
- Гибкий рабочий график. Нам не важно когда и сколько кто работает, при условии участия в обязательных митингах и нормальном перформансе.
- В разумных пределах нелимитированная PTO-policy, ибо отдыхать тоже важно.
- Удаленка откуда угодно + опции релокейта в Канаду и US.
- Минимум бюрократии, возможность менять процессы и все остальные аттрибуты стартапа.

Куда откликаться:
Задавать вопросы и откликаться можно мне в личку или на странице вакансии (описание можно игнорировать). Открыть/Комментировать

2022-07-16 21:42:39 И отдельный комментарий для всех, кто занимается наймом.
Первое - помни, что найм людей это своего рода талант и навык, который тоже надо качать.
Анализировать успехи, учиться на ошибках, совершенствовать и улучшать то, как ты ищешь себе в команду людей. Без этого никуда.
Научившись находить подходящих людей себе в команду ты сможешь избежать кучи проблем.

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

Третье - иногда кажется, что тебе просто повезло с классной командой, поэтому всё так просто и нет никакого бесконечного this is fine кругом.
На самом деле, “классная команда” - не результат везения, а результат трудов того, кто эту команду собрал. Цени труд этого человека, особенно если это ты сам. :) Открыть/Комментировать

2022-07-16 21:36:27 Немного размышлений про найм.

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

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

Первое что тут хочется сделать - разобраться с тем, кого же мы всё таки ищем в команду.
Какие задачи человеку придётся решать, в каком режиме работать и каких результатов от него ждут.
Важно понимать, что это не только про скиллы и техническую экспертизу, но и про софт-скиллы, майндсет и общий подход к работе.
Даже если главной задачей человека будет "нарастить покрытие автотестами", надо понимать что автоматизатор из большого финтеха, привыкший работать в режиме "мне приносят задачи покрыть фичи А, Б и В тестами - я делаю" с большой долей вероятности не сможет дать ожидаемых результатов в стартапе, где ему просто выдадут десяток сервисов и полную свободу действий.
И наоборот, человеку превыкшему работать в режиме "сам придумал себе задачу - сам сделал - сам выкатил" будет сильно сложнее перформить в более строгих и вертикальных процессах.
Таким образом появляется формализованный (или не очень) профиль кандидата - набор скиллов и характеристик, которые в разной степени важны.
Какие из них важнее, а какие “было бы хорошо, но не критично” - тоже не всегда очевидный вопрос.

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

Но, есть штуки, которые вообще очень сложно формализовать.
Несколько лет, активно занимаясь наймом инженеров, меня всегда смущала некоторая субьективность в вопросах найма.
Бывает такое, что по результатам интервью ты видишь, что всё хорошо - технические задачи решены правильно, опыт релевантный, задачи на problem solving тоже хорошо прошли.
Но итогового ощущения "хочу этого человека в команду, надо офферить" нет. И ты даже не можешь объяснить почему.
За последние пару лет, во чём-то благодаря саморефлексии, в чём-то благодаря общению с другими нанимающими инженерами, я понял, что попытка заглушить эти сугубо субьективные ощущения скорее ошибочна.
Это почти неформализуемое чутьё на тему "свой/чужой" - штука, которая работает.
Потому что из десяткой нанятых за последние 6 лет инженеров я ни разу не пожалел об оффере, который был выдан с вот этим вот ощущением "надо нанимать”.
Даже там, где техскиллы недотягивали.
А вот с ребятами, найм которых сопровождался субьективными сомнениями, что "все вроде хорошо, но есть какое-то но" - приходилось расставаться, по самым разным причинам.

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

2022-03-02 13:27:16 Про баги, алерты и басню «Волки, волки».

Я довольно часто ссылаюсь на Федю Борщева, что несмотря на то, что в некоторых моментах мы исповедуем совсем разные подходы.
Один из недавних его постов был про вред избыточного алертинга.
Здесь и про false positive срабатывания и про желание видеть алерты на всё, даже на то, что не требует мгновенного реагирования.
Это проблема, которая ощутимо вредит и комфорту команды, и продукту.
Учитывая, что мало кто умеет строить системы мониторинга и алертов - проблема ещё и часто встречающаяся.

Но сегодня хочется взглянуть на эту ситуацию в чуть большем масштабе.
Эта проблема актуальна не только для алертов.
Она касается всей информации о качестве продукта, ошибках и проблемах.
Если на каждый баг в продакшене C-level executive врывается в слак-чат разработки и устраивает филиал ада - то очень скоро команда перестанет на это реагировать.
Потому что в какой-то момент это сведётся к «о, K опять нашёл баг». Просто шум.
Если на каждый тикет разработчик говорит «да там вообще все рефакторить надо, давайте больше времени», то со временем вместо реальной оценки это превратится в «о, В просто любит рефакторить».
Если с каждым релизом QA инженер приходит с возгласом «такое говно катить нельзя», а там ни одного блокера - то оценка качества этим инженером будет обесцениваться в глазах команды.
Если из любой проблемы создавать critical issue - то ценность критикала падает до regular.
Если команда работает по Zero Bug Policy - десять незакрытых дефектов в бэклоге это проблема, а для команды которая просто штампует дефекты сотнями - никто даже не будет этот список смотреть, потому что найти там что-то полезное слишком сложно.

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

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

2022-02-24 11:59:48 Друзья, простите меня за этот пост, но по другому не получается.

После моего поста про Берлин, в комментариях и личке, меня спрашивали что сподвигло сваливать.

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

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

Берегите себя, оставайтесь людьми.
Всем мир. Открыть/Комментировать

2022-02-15 19:39:17 Говорите о том, что важно для вас.

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

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

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

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

2) Руководитель не знает, как правильно поддерживать твою мотивацию.
Денег насыпать? Задачи поменять? Людей в подчинение выдать? Грейд поднять? Повесить фото на доску почёта?
В идеальном мире, конечно же, ты будешь получать здоровый баланс из всех этих ништяков, но баланс этот будет построен не на тех входных данных, которые ты дал, а на “среднестатистическом сотруднике” и представлениях руководителя о твоей системе мотивации.

3) Вы всё равно вернетесь к этому вопросу.
Скорее всего тогда, когда у тебя уже наболит и будет выбор между “ныть пол часа на 1-to-1 или сразу уволиться”.
И тут может быть уже поздновато, потому что даже если пофиксите - осадочек останется, а потраченные нервы никто не вернет.
Грамотный руководитель и хорошо отлаженная коммуникация могут решать эту проблему, но не всегда вовремя.

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

2022-02-09 23:33:30 Открыть/Комментировать

2022-02-09 23:32:31 Status update: it’s alive.

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

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

Сейчас стартанул новый виток приключений для меня.

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

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

2021-07-14 13:37:39 Задачу нормально поставьте.

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

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

Тут есть несколько моментов, о которых надо помнить.

Первый:
Каждый раз, когда вы хотите, что бы вам принесли идеально проработанную задачу - вы просто перекладываете ответственность.
Вы хотите упростить себе жизнь, не ломая голову над тем, что от вас хотят, избежать всех этих уточняющих вопросов и, заодно, минимизировать риски.
Что бы если к вам придут и спросят "почему это работает вот так?" можно было просто сказать "я сделал как в ТЗ было написано".
В желании упростить себе жизнь нет ничего плохого, но надо понимать, что в данном случае вы делаете это в ущерб команде и продукту.
Потому что ответственность, риски и проблемы вы снимаете с себя, но перекидываете на кого-то другого.

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

Третий:
Способность (и готовность) работать в условиях неявных требований - это конкурентное преимущество.
Даже при хорошо отлаженных процессах требования всегда будут неполными.
Задачи без описания и definition of done "Работает хорошо" будут периодически появляться.
Вопрос только в том, какую цепочку проработки они будут проходить прежде, чем окажутся в продакшене.
Переоткрывая задачу в формате "требования опишите нормально" вы просто докидываете ещё одно звено в эту цепочку и увеличиваете time to market.
Инженеры, способные получить слабо формализованную задачу, взять за неё ответственность и выдать результат ожидаемого уровня качества - на вес золота.
Они стоят гораздо дороже и ценятся компаниями гораздо выше, чем инженеры, просто транслирующие ТЗ в код.

Помните, что разные подходы работают для разных команд.

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

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

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

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

Поэтому, каждый раз, когда слышите истории успеха и сладкие речи про идеально проработанные ТЗ и вот это всё - задавайтесь вопросом, а действительно ли это плюс? Открыть/Комментировать