#процессы

Как запускать проекты без жиры и прочей скукотени? Набрасываем с Федей на вентилятор и делимся основными принципами в честь сдачи проекта одному из клиентов.

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

Мы с Федей уже почти месяц вместе составляем системный ответ на этот вопрос. Для командной работы мы завели личную базу знаний (что-то вроде своей википедии) в 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. У нас есть отличная вакансия для рубиста в Питере.

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

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

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

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

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

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

Рекомендую.

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

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

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

——

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

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

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

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

💘 https://basecamp.com/shapeup

Фёдор Борщев отвечает на вчерашний пост про Agile:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-----

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