процессы

Basecamp написали подробную книгу, как они строят свою работу.

Эти ребята умудрились вырастить продуктовую компанию из 2 человек в 50 и не потерять при этом жизнь, скорость и кайф в том, чем они занимаются.

Всё бесплатно, онлайн, с примерами из реальной жизни.

💘 https://basecamp.com/shapeup

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

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

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

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

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

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

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

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

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

-----

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

В чем заключается работа технического директора? Обычно я отвечаю отрывочно или углубляюсь в какой-то аспект профессии, который интересует меня в тот момент.

Мы с Федей уже почти месяц вместе составляем системный ответ на этот вопрос. Для командной работы мы завели личную базу знаний (что-то вроде своей википедии) в Notion. Мы храним там общие задачи, план и знания, которые собрали в ходе работы. Если заменить информацию о конкретном клиенте подробным описанием, зачем мы делаем тот или иной шаг — может получиться книга «как руководить разработкой в продуктовой компании».

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

Глава I, про бизнес и процессы.

1. Чего бизнес хочет от разработки? Важно не остановиться на конкретной хотелке «напрогайте нам X», а докопаться до бизнес-гипотезы, которую хотят проверить.

2. Как построена работа над продуктом: кто преобразует гипотезу в задачу, как ставится задача разработке, доносится ли гипотеза до программиста, интересуется ли они ею? В здоровой продуктовой команде техническая экспертиза подключается на самом раннем этапе.

3. Что происходит после запуска фичи? Анализируется ли результат? Понимают ли программисты, как они повлияли на бизнес?

4. Как происходит планирование и приемка работы? Смотрим на четкость и ритмичность. Четкость: плохо — «мы тут что-то не особо хорошо описанное напланировали, о том успеем или нет — не задумывались», хорошо — «в понедельник у пользователей в продакшене появится X», нужны конкретные обещания и контроль их выполнения. Ритмичность: продуктовая работа — это почти всегда постепенное улучшение и очень редко — один героический забег. Чтобы система работала годами, ей нужна цикличность, с запланированными фазами «напряжение-расслабление».

Глава II, люди.

5. Команда: в каком состоянии ребята, нравится ли им работа, нравятся ли коллеги, конкурентная ли компенсация? План развития ребят, 360 reviews, 1-1.

6. Уникальность знания. Что будет, если сотрудник уволится или заболеет (bus factor)? Документация, стоимость погружения новых людей в проект.

7. HR: достаточно ли мы рассказываем миру о том, хорошо лиу нас работать? Ведение профессионального блога, выступление на профильных конференциях.

Глава III, технологии.

7. Operations: отказоустойчивость, масштабируемость, мониторинг, incident management, бэкапы, учения. Автоматизация процессов в разработке: среды разработки, деплой, откат, etc..

8. Архитектура и код: модульность, связанность, тесты. Тесты: насколько велика вероятность сломать проект? Радость разработчика: насколько комфортно ребятам работать?

9. Информационная безопасность: DDoS, дырки в коде, операционная безопасность, социальная инженерия. Проводим ли ли пентесты, есть ли баунти-программа, как реагируем на сообщения об уязвимостях?

—

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

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

P.S. У нас есть отличная вакансия для рубиста в Питере.

Красноречивый наброс на скрам, мол, Agile > Scrum = 💩 и у всех прорывает.

Если вы ничего не поняли — это нормально. Фраза — практически тест на то, занимались ли бизнес-программированием в последние 5 (10?) лет.

Agile — идея (учение) о том, как правильно разрабатывать программы. Вот простой для понимания первоисточник, рекомендую: 12 заповедей (принципов) Agile (русский перевод). Оцените полет мысли, это практически госпел (понимаю, почему его так любит Герман Греф).

Я капитально упорот на идее servant leadership и работал исключительно в стартапах. Даже я чувствую иррациональный страх перед идеями Agile. Уровень страха нормальных менеджеров можно сравнить со страхом фарисеев перед идеями Христа, я думаю. Поэтому авторами Agile Manifesto был придуман SCRUM.

SCRUM — четко описанные процессы, где отдельный человек и даже продукт уже не так важны. Можно стать сертифицированным коучем SCRUM, есть курсы SCRUM, можно повесить себе шильдик «успешно внедрили и следуем СКРАМ» и т.д.

Разница между Agile и SCRUM — примерно как между учением Христа и табачным бизнесом РПЦ. Поэтому в классных компаниях ценят результат и людей, этот результат достигающих, а в стремных — «процессы». Аминь.

@pmdaily, что скажешь?

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

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

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

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

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

Во первых, нужно выбрать, кого собеседовать. Мы смотрим на исходный код. Просим ссылку на репозиторий, zip или, хотя бы, отдельные исходные файлы. Это отсекает часть кандидатов, которые не способны прогать. Сразу видно крутышей, которые пишут так (или такое), что хочется с ними работать.

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

Очень хороший текст о себе, со всеми правильными ключевыми словами, может подкупить моё сердце, но Рома (или другой программист) наверняка спросит «а код-то где?»

Я не даю тестовые задания, потому что боюсь отсечь самых крутых кандидатов, которые «в р** е**** наши тестовые» (не заинтересованы в тестовых), за ними и так очередь стоит. К тому же, код из реального мира лучше синтетического.

Во вторых, никаких собеседований один-на-один: это более утомительно и менее эффективно. Бэкендера мы искали вдвоем с Антоном, фронтов собеседуем с Ромой и с Сашей втроем. При этом иметь со стороны компании больше 3 человек, наверное, тоже перебор.

В третьих, мы не спрашиваем _тупых_ вопросов на _соображалку_ типа «сколько теннисных мячей поместится в Боинг 747». И никаких whiteboard interview, когда просят написать исходный код «здесь и сейчас». Собеседование призвано ответить на три вопроса:

1. Хотим ли мы работать с этим человеком?
2. Захочет ли он работать с нами?
3. Способен ли он выполнять работу, которую мы хотим ему дать?

Сценарий всех собеседований примерно одинаковый:
1. Мы рассказываем о продукте: какую проблему он решает, какие составные части в нем есть (это я люблю рассказывать сам, но порой я учусь смирению и это делает кто-то из программистов);
2. Какие технологии мы используем — тут обычно программисты начинают говорить на птичьем и в глазах кандидата появляется оживление, он начинает задавать вопросы. Хорошо!
3. Как устроен рабочий процесс — бейзкемп, рабочие циклы, разбиение фичи на подзадачи программистами, созвоны, личные встречи, etc. Больше вопросов, наши истории из жизни, в идеале кандидат делится своими.

Это всё нужно успеть проговорить за первые полчаса или быстрее. Мы раскрываемся перед кандидатом, задаем планку того, как и о чем рассказывать.

Дальше кандидат рассказывает о себе. Часто люди просят задать вопросы. Самый главный:

Почему решил уйти с прошлой работы? По ответу можно узнать, что важно для человека перед вами и зачем он к вам пришел. Почти всегда, есть что спросить по ходу рассказа — кандидат сам разбросает перед вами ниточки, потянув за которые, можно размотать клубок. Пример фразы-маркера, за которую я обязательно уцеплюсь: «у нас были технические разногласия» — уж не «перфекционист технологический» ли перед нами?

Многое можно понять по тому, задает ли кандидат те или иные вопросы. Например, когда мы говорим «react, redux» то классический вопрос чувака «в теме» это «thunk или saga»? Обычно, это начало продуктивной беседы с перекрестными вопросами, когда мы советуемся с кандидатом, узнаем его мнение о той или иной технологии, он узнает больше о нас и нашем подходе к программированию, а мы нащупываем его технический уровень.

Иногда мы спрашивали классические «экзаменационные вопросы» типа «как ты оптимизируешь react-компоненту, чтобы меньше тормозило?», но я считаю этот «экзаменационный» стиль поведения во многом капитуляционным, когда не получается наладить качественный, живой человеческий диалог.

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

P.S. Мы только что провели 7 собеседований за один день и это перебор, так я делать не рекомендую (хотя получилось очень результативно и это балансирует чувство, будто вскопал поле).

Как управляют разработкой в самом популярном музыкальном сервисе в мире?

5 лет назад Spotify рассказали о своей системе управления разработкой, Spotify model. Сегодня о ней знает любой менеджер в IT, а многие положения из этой системы стали стандартами де-факто.

На прошлой неделе я поговорил с Юлей Куропатенковой, инженерным менеджером в Spotify. Юля отвечает за бэкенд авторизации. Она рассказала, что за эти годы их система управления разработкой сильно изменилась, сколько программистов и команд в Spotify, кто и за что отвечает. До Spotify Юля поработала в дочке IBM и поэтому может сравнить два диаметрально противоположных подхода к организации разработки.

Слушайте на всех платформах: Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия.

Закончил на днях технический аудит очередного клиента. Хочу поделиться историей, которую вижу буквально в каждом втором случае.

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

Через 3-6 лет в компании уже 50 разработчиков. Продукт при этом практически не развивается, фичи доставляются разработкой в продакшен со скорость улитки. Добавьте к этому зарплаты разработчиков в 100-400 тысяч в месяц и вы можете представить, что чувствует бизнес. Почему так?

А происходило вот что: все эти годы, каждый раз, когда нужно было выбрать между «сделать фичу побыстрее прямо сейчас» и «сделать так, чтобы это можно было потом поддерживать, пусть и подольше прямо сейчас» — бизнес с разработкой вместе выбирали первый вариант. Логично, что рано или поздно гора неподдерживабельного кода становится слишком высокой и уже никто не может докинуть ещё что-то сверху.

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

В общем, искать виноватого смысла нет, а варианты решений следующие:

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

2. Если же вам нужно развивать то, что есть — то впереди вас ждут пот и слёзы.

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

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

Организационно, вам придётся выделять на это адское количество времени и сил. Речь о 30-50% времени ваших инженеров. Результаты, в плане увеличения скорости разработки, вы увидите через месяцы в лучшем случае. Другого пути я не знаю.

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

В общем, это — путь смелых.

—

Добавлю, что обычно, ко всем этим техническим проблемам добавляется ещё и нежелание признать реальность, когда бизнес требует, а команды регулярно обещают больше, чем могут реализовать. В результате, разработка постоянно существует в режиме пожара (какая уж тут инженерная культура, когда ничего не успеваешь!), а бизнес постоянно не доволен и не верит обещаниям программистов.

Приведение этого процесса в порядок — отдельная работа, но об этом — в следующий раз.

Дорогой Игорь из нашего чата @ctodailychat делится опытом:

☞
В нашей команде мы перешли на FAQ first development. Если хочется запилить фичу, то первым делом пишется пресс-релиз и/или FAQ который впоследствии становится спекой.

Бенефиты:
- Фичи стали более продуманными и формулируются через value которые они несут;
- Улучшилась командная коммуникация. FAQ всегда под рукой и на вопросы можно ссылаться. Во время дизайн сессий возникает множество вопросов которые пополняют документ;
- Сейлы знают что они продают и умеют правильно питчить фичи;
- Программисты понимают, что важно, а где бессмысленная дрочка.

——

Классный прием!

Basecamp теперь бесплатен для фрилансеров, студентов, семей и личных проектов.

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

Basecamp — не идеальный инструмент. В нем нет канбан доски как в трелло, в которой удобно двигать задачки по статусам от «идея» до «готово». В нем нет кастомных представлений как в жире, в которых удобно посмотреть все iOS-баги, находящиеся в тестировании и назначенные на определенного человека. В нем нет мощного чата, как в слеке (ох как хочется затегать группу!). В нем нет красивого редактора, как в Notion, даже таблицу в задачу не заведешь. В нем нет древовидных комментариев, как в жире и Confluencе, а ведь так хочется ответить на определенный комментарий в треде). И уж конечно это не супер футуристичная бесконечная коллаборативная доска как Miro.

Любым инструментом можно поддержать практически любой процесс разработки. Разница в том, какое поведение инструмент поощряет, а какое — наказывает, делает неудобным. В этом плане я доверяю создателям Basecamp.

Я хочу вести разработку как создатели Basecamp — качественно, стабильно, интересно, с уважением ко всем участникам процесса. Мне интересна тема ответственности и в Basecamp она очень важна.

Если вам стало интересно, как это — вот несколько книг, объясняющих их подход:
- методология разработки — Shape Up;
- одна из главных книг про удаленную работу — REMOTE;
- как не сгореть на работе — It Doesn't Have to Be Crazy at Work!

Рекомендую.