Управление и команды

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

Вы не поверите, специалист техподдержки спокойно рассказал, как устроена работа компании. Вся команда разработки живет в одном и том же продуктовом цикле. Если на момент написания статьи это были 3-4 команды по 2-3 человека, то теперь это могут быть 7 команд или больше. Да, документ описывающий цикл стал больше, но принципиальная схема осталась прежней.

Я по работе общался с сотнями техподдержек (о, сколько часов музыки я прослушал по PSTN) и эта впечатлила меня больше всего. На втором месте G Suite от Google (бывший Google Apps) — реально разбираются в этом монстре и технологиях, на которых он построен. Третье место занимает поддержка Apple Developer Program. Эти чуваки супер дружелюбные и если правильно пропитчить нужду могут сделать множество исключений из правил. Прямо как в России, закон строг, но можно договориться.

Душевная статья про то, как не стать плохим руководителем от Claire Lew в Signal v. Noise (блок бейзкемпа). Пункты довольно очевидные, но написано так, что приятно читать.

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

Поздравим главного редактора с первым коммитом!

Из руководства без github-аккаунта осталась только Галина Викторовна. Challenge accepted.

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

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

Резюме совещания:

про макеты:
- постепенно создаем один мастер-макет, в котором отрисованы все форматы медузы и в который добавляются новые, перестаем использовать отдельные маленькие макеты как источник правды;
- с помощью этого мастер-макета постепенно уменьшаем количество разных элементов, выносим все общие элементы в стайлбук;
- если в новых форматах есть неочевидные моменты (заголовок изменился на 1 пункт, так просто не заметишь) — указываем эти комментарии прямо рядом элементом, на полях артборда;
- этот мастер-макет храним в версионированном хранилище с возможностью просмотра диффов и автоматическими уведомлениями о правках (скорее всего github + скетч-плагин, но если найдем хороший SaaS — то вполне может и на него сядем);

про совместную работу:
- задача разработчиков — в процессе разработки (чем раньше тем лучше, идеально во время приемки) найти недорисованные/недодуманные моменты и сказать о них дизайнеру. Например, если не учтена ситуация, когда одно из полей пустое — не очевидно, какие отступы делать в этом случае. Дизайнер дорисует эти кейсы и/или добавит в макет комментарий, объясняющий логику;
- если что-то очень сложно сделать на платформе (белая тень, хитрый блюр, etc.) — обсуждаем это с дизайнером. Что нужно в разговоре? 1) объясняем что именно сложно сделать и почему 2) предлагаем решение, как вы думаете можно упростить/сделать по другому 3) приходим вместе к компромиссу. Никто не требует делать безумные хаки, которые дорого поддерживать и которые ломаются с апдейтом чего-нибудь. Все мы хотим классный продукт и дизайнер мог просто не знать/забыть о платформо-специфичной вещи;
- вывод: Не стоит допридумывать то, что не описано/не нарисовано. Нужно договариваться. Молча делать отлично от макета запрещено;

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

Теперь о том, где, как и с кем это всё обсуждать.

1. О каких-то мелких непониманиях по дизайну стоит писать в личку Насте, Вите и Насте; можно созвониться-пошарить экран и тд, если текст не решает;
2. О крупным вещах, которые хочется обсудить с командой и с дизайнерами — пишите прямо в #dev или в проектный канал типа #dev-prodano
3. Если это тема в проектной работе, которая требует осмысления и обсуждения — круто завести для неё карточку в трелло-доске проекта и заменшенить в комментарии всех причастных. В трелло обсуждения не теряются и можно посмотреть толком историю переписки по конкретному вопросу.

Воспользуюсь случаем и напомню, что текущие проекты, предстоящие задачи и icebox (то, что хочется сделать, но хз когда) можно посмотреть в доске «проекты разработки» — он открыт для всех, изучайте и дополняйте, пожалуйста.

-----

А как вы строите работу дизайнеров с программистами? Делитесь в @ctodailychat, интересно послушать ваши истории.

Краткие тезисы из статьи «как построена работа в Basecamp»:

- рабочие циклы по 6 недель. Внутри цикла могут быть до двух больших проектов продолжительностью на все 6 недель и пачка из 4-8 мелких, длящихся от дня до 2 недель каждый. Пример документа, описывающего цикл для команды;
- между циклами есть 1-2 недельное «свободное время», когда они чинят баги, занимаются side project и думают над следующим циклом;
- вся пачка мелких проектов делается одной командой, если в цикле два больших проекта — их делают две отдельные команды;
- самое необычное: команда это 1 дизайнер и один или два программиста; менеджером команды является дизайнер, но вся работа происходит сообща;
- чтобы пропитчить идею, её нужно оформить в связный текст с формулировкой проблемы и решения. Почему не голосом? 1) питчера не могу прервать и загнобить пока он не рассказал идею целиком 2) при написании текста питчер хорошенько над ней думает 3) асинхронное взаимодействие, они не особо любят слеки и личные встречи для работы 4) все комментарии к питчу собираются внизу как единый источник истины. Пример питча;
- координация и трекинг задач происходят в бейзкемпе, внутри всё стандартно;
- в цикле участвуют 2 QA-специалиста, они кочуют между проектами;

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

Я пока не ответили себе на вопрос, что в этой системе делают с задачами, в которых нужен бэкенд и мобильная разработка на двух платформах одновременно. Повышать число человек в команде нельзя — но как разбить задачу на проекты, если она по смыслу — одно целое? Пишите свои мысли в чатик @ctodailychat или личку @samatg.

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

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

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

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

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

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

Когда не предупредил редакцию о тестировании

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

Хорошо сочетаются вместе две половины этой фразы! На самом деле почти у всех так.

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

Покупать много дорогой техники не за свои деньги — тяжело эмоционально. Что, если ошибся и объектив не подойдет к камере, а карта памяти окажется слишком медленной? Что, если монитор не будет работать с заданным компьютером?

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

Плохое планирование работы команды даже из 9 человек стоит дороже любой техники, а всё равно пугает меньше. Наверное, потому, что нет четкого point of no return.