процессы

Старший дизайнер из StackOverflow рассказывает, как у них всё remote-first, а не просто remote-friendly.

Длинный и интересный пост с кучей деталей об организации удаленной работы в компании (и дизайн-процессе). У них, например, есть специальный человек, который помогает (удаленно) обустроить домашний офис и разобраться с налогами, а все встречи проводятся через видео-связь (никаких «мы тут соберемся, а ты звони)». Клёвые иллюстрации (видно, что пост делал хороший дизайнер), образцовый пример онлайн-рассказа и отличная реклама работы в компании.

Не всё, что они делают, я готов применить у себя прямо сейчас. У нас всего 11 человек в команде разработки и мы больше экономим, но то, как устроена удаленная работа в StackOverflow — хороший ориентир.

Спасибо за наводку в нашем чатике Максу Сябро.

Удивительно наблюдать, как гиганты (не)справляются с вайб-кодингом:

Github потерял последнюю девятку в своем SLA. Отдельно замечу, что status page вендоров уже давно нельзя верить и вот люди собрали собственный, народный.

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

Хотя казалось бы, уж у них-то должны быть и автоматизированные тесты и легион ручных QA-инженеров!

Вот целый список подобных падений, с оценкой, сколько пользователей они задели.

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

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

В общем, быть техдиром опять становится интересно.

Мы в Медузе уверенно программируем (и управляем разработкой), когда есть четкая постановка задачи — понимание, описание, макеты, тестовые данные и прочее.

Создаешь трелло доску со столбцами «описание», «разработка», «тестирование», «готово». Заводишь в неё все задачи. Даёшь внутри ссылки на .sketch-файлы. Созваниваешься перед началом проекта, обсуждаешь его голосом. Дальше постоянно контролируешь результат. Главное не забыть, что хотел получить в конечном счете.

Меня беспокоит этап, когда разработка формально ещё не началась. Собрать требования, разобраться в документации, разбить проблему на меньшие части, понять, что мы можем себе позволить, а что нет — всё это большая работа. В ней участвует не только разработка, но и дизайнеры и редакция. Сейчас эта работа делается ad-hoc, без «единого источника правды». Из-за этого возникает несколько связанных между собой проблем: 1. сложно оценить объем работы (сколько было/сколько сделано/сколько осталось) 2. сложно её делегировать (делать вместе) и делиться результатом 3. задачи теряются и забываются.

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

Попробуем сделать это с несколькими следующими проектами. Расскажу потом, что получилось.

Спасибо большое Боре Горячеву, что заметил проблему и указал на решение.

Некоторые программисты недавно начали говорить, что у Apple «проблемы с софтом». Мол, во времена Джобса такого не было и вообще, раньше софт был надежнее.

Вот ответ от Стивена Сифонски. Это один из ключевых чуваков в MS: пришел в 1989, уволился в 2012 в должности руководителя разработки Windows https://medium.learningbyshipping.com/apples-software-problem-and-fixing-it-via-twitter-c941a905ba20

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

Раз уж про мессенджеры и работу: на прошлой неделе главный рабочий мессенджер Slack объявил о повышении цен: c 8 долларов в месяц за сотрудника до 8,75$.

Я узнал об этом случайно от знакомых, потому что у нас в компании единственный корпоративный чат — в телеграме, с фоточками котов, собак, ежей, оленей и прочих домашних животных.

Почти вся наша рабочая коммуникация — асинхронная, в Basecamp. Стоит Basecamp 99$ в месяц вне зависимости от числа проектов и сотрудников.

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

—

Я переводил несколько команд в Basecamp и хоть это и не просто, результат того стоит.

Успевают программисты и дизайнеры больше, а устают — меньше. Рекомендую.

Картинка из 2015 для разрыва шаблона.

Мы в компании «Федя и Самат» проводим эксперимент.

Пробуем 4-дневную рабочую неделю.

Мотивация простая: всё равно больше 4 дней нормально думать, именно думать, не просто клавиши нажимать — не получается. Раз так — что время зря терять? Лучше с толком отдохнуть.

Предложил Федя, провели в пятницу общую встречу про это. Отзывы команды:
— «мы и так раньше не следили за рабочим временем и коммуникация почти вся асинхронная, какая разница»;
— «я так всегда и работал»;
остальные отреагировали настороженно, но это в зуме.

У нас через пару недель оффлайн слёт — обсудим там первые впечатления подробнее.

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

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

Краткий список литературы (я сомневаюсь в её валидности): свежая статья от Harvard Business Review, английская википедия, красивый лендос и аж целое НКО.

Встречали это «вечное противостояние» между продактами и разрабами? Каждый думает, что лучше знает, что делать с продуктом:

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

Раньше я думал, это — «здоровый производственный конфликт». Теперь я считаю, что это — признаки «бытовой неустроенности», того, что с разработкой в компании есть проблемы. К сожалению, 90% команд живёт в этом состоянии.

До конца недели я буду отвечать на вопросы о разработке в телеграм-канале «продуктовая культура». Если вопрос будет касаться взаимодействия продакта и разработки, отвечу я. Если вопрос со стороны технических специалистов про продукт, продуктовые циклы и всё это — ответит Валерия Розова, основательница курса «менеджер продукта».

Я приму участие в этом курсе — но об этом в следующий раз.

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

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

Пускай это жёсткий пример, но история классическая:
1. заказчик описывает задачу и просит назвать сроки и цены;
2. подрядчики называют сроки и цену и берут проект;
3. начинаются работы по проекту, и что-то идёт не так;
4. к дедлайну нужного результата нет, все недовольны. Но проект надо доделать.

И эта проблема не только у аутсорсеров — такая же динамика есть и во многих продуктовых компаниях.

Почему так происходит?

- 💼 заказчики живут в реальном мире: если продукт не начнет продаваться или решать другие задачи вовремя, то экономика бизнеса не сойдется и можно закрываться — поэтому они требуют четких сроков и смет;
- 🙏 подрядчики вынуждены комититься в сроки и деньги без детальной проработки проекта. Иначе проект возьмет более сговорчивый конкурент, и команда останется без зарплаты;
- 🛠️ разработчики в команде мечтают работать над сложными проектами уровня Яндекса, но вынуждены пилить такие кривые задачи, как будто их ставили некомпетентные дураки.

На самом деле все хотят как лучше.

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

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

(Этот пост я написал с третьей попытки, а потом понял, что потребуется целая серия постов. Так что я знаю, о чём говорю.)

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

На старте проекта бессмысленно требовать от заказчика четкости: вообще самое плохое, что можно сделать — это заставить его написать техническое задание (если он умеет писать ТЗ — то он и программирует неплохо). Вместо этого мы вначале 70-90% времени работаем исследователями — разбираемся, какую бизнес-задачу заказчика решаем и какие ресурсы и ограничения у нас есть.

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

«На совещаниях всегда за что-то дрючат, но конкретные решения никогда не озвучиваются — и они приходят откуда-то совершенно разрозненно, в виде одиночных задач. Эстетики там нет, смысла нет, руководящей руки нет, — жалуется один из строителей. — Я понял бы еще, если бы приехало первое лицо, прогулялся человек — и говорит: „Сменить нахуй!“ Но его там не бывает — а перемены все равно происходят. Как-то сами собой».

Именно так происходит совсем плохая IT-разработка, на примере строительства мега-дворца.

За наводку спасибо Игорю.