Новое

страница 133 из 174

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

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

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

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

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

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

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

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

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

-----

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

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

Оказывается, достаточно было включить автоскрытие дока и статус-бара в General Preferences. Получается тот же полноэкранный режим, только все Cmd+Tab переключения работают мгновенно.

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

Отдел разработки Медузы ведет неравный бой с эмбедами фейсбука, инстаграма и твитера уже третий год. Постоянно что-то меняется и ломается.

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

Снепчат провел крупный редизайн, разделив личные истории от influencers & media (в попытке защититься от fake news).
↓
Больше миллиона человек подписали петицию с требованием откатить редизайн, говорят неудобно пользоваться. ДУРОВ ВЕРНИ СТЕНУ

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

Apple вот не парится — 2 часа запланированного даунтайма iTunes Connect для какого-то (видимо, внутреннего) релиза

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

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

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

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