Методологии разработки

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

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

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

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

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

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

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

Что нужно поколению Z от работы?

1. Deloitte провел исследование разницы в отношениях миллениалов и поколения Z к работе и будущему. Миллениалы – родившиеся с 1983 по 1994 год, поколение Z – с 1995 по 1999. Я обратил внимание на два слайда. Количество миллениалов, собирающихся сменить работу в течение двух лет – 43%, количество людей в поколении Z с теми же целями – 61%. Люди из поколения Z думают, что у них меньше перспектив в жизни и карьере: на 32% меньше, чем у миллениалов, и на 43-46% меньше, чем у предыдущих поколений. Дальше в отчете делаются выводы, что поколение Z бла-бла-бла что-то там. Но мне кажется, что "нет ничего нового под солнцем", а все это проявление других, но древних как мир истин.

2. Молодое поколение более остро чувствует, что радужные перспективы достанутся не всем. Они еще готовы ради этих перспектив суетиться – хотя, ничего, кроме более быстрого перебора рабочих мест, большинство из них придумать не может.

3. Чем взрослее это поколение становится, тем больше люди смиряются с тем, что у них уже есть. Зачем менять работу, если на другое работе будет почти то же самое? Давайте убедим себя, что у нас и так все хорошо – ведь у нас есть квартира и машина, семья и дети, и с работу нас еще не выгнали.

4. Кроме общих соображений по поводу того, "в чем смысл жизни", и "перспективы надо искать и создавать еще в молодости" – напрашивается еще один более конструктивный вывод. Если мы хотим привлекать к себе на работу молодежь – не надо обещать им пожизненной карьеры в своей компании. Наоборот, надо манить их перспективами научиться у нас чему-то настолько полезному, чтобы в течение пары лет они могли упорхнуть от нас куда-нибудь повыше.

Ссылка на полный текст исследования: https://documents.deloitte.com/insights/2018DeloitteMillennialSurvey

​​Namecheap включил бесплатный WhoisGuard

WhoisGuard — это сервис, который защищает от спамеров ваши контакты: домен остается зарегистрированным на вас, но никто об этом не может узнать.

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

​​Следующий раунд борьбы Телеграма с Роскомнадзором

Сегодня вышло обновление телеграма. Официально оно содержит обновления для GPDR, неофициально — поддержку нового формата прокси — MTProto.

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

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

С моего дивана это кажется ещё одним шагом в сторону пропасти^W DPI — такие действия вынуждают Роскомнадзор перейти от тупой блокировки IP-адресов к полноценному автоматическому изучению вашего трафика.

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

О том, как живут люди с DPI в Иране, можно почитать грустный тредик на гитхабе.

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

Ну а я пойду приближать эпоху Золотого Щита, и поднимать MTProto в дополнение к SOCKS для всех, с кем хочу поддерживать связь.

И еще вакансии

Мы в mtrl.ai растём на 20% каждый месяц. Задач становится все больше, поэтому мы открываем новый набор. Кто нужен:

— Дизайнер-продуктолог, Москва. Работа удаленная, но два-три дня в неделю нужно появляться в офисе.
— Ведущий питонист, обязательна терпимость к JS желание стать фулл-стеком.
— Джуниор-фуллстек. Если вы знаете про TDD в питоне и можете отличить vue от реакта — после года у нас начнете стоить как крутой мидл.

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

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

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

Тупое правило менеджера

Ещё в студии я познакомился с простым правилом управления любым проектом:

Если прошло 50% времени, проверь — выполнена ли половина работы

У многих людей в мозгу есть баг: к началу второй половины срока они обычно не осознают, что первая половина уже упущена. Грубо говоря, если вы пообещали сделать что-то через неделю, и прошло три дня, то без внешнего воздействия у вас не возникает ощущение «ааа, только половина времени осталась, пойду хуячить». Скорее будет «ой, да еще 4 дня есть, пойду погуляю».

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

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

#тупое_правило

Вот тут чувак анализирует вакансии в стартапах США для программистов Руби. Говорит, что спрос еще есть.

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

Кстати, на втором месте в том обзоре — моя любимая Django.

А как вы думаете, что стоит учить джуниору, чтобы найти работу в крутом айти-стартапе?

Что учить джуниору, чтобы найти работу в крутом ИТ-стартапе?
anonymous poll

Node.js😱 – 131
👍👍👍👍👍👍👍 58%

Джанго – 69
👍👍👍👍 31%

Рельсы – 25
👍 11%

👥 225 people voted so far.

​​​​​​Фичреквесты, которые не стоит выполнять

Даже самые полезные фичи в момент появления скорее всего выглядят уродливо.

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

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

Обычно этим занимается выделенный продуктовый менеджер, или дизайнер, который умеет задавать вопросы. Если у вас таких людей пока нет — внедрите хотя бы стоп-задачи: запросы, которые НИКОГДА не обрабатываются в сыром виде:

— выгрузка в Эксель
— автоматическое письмо в посту/слэк/СМС
— добавить любую кнопку/галочку
— покрасить что-нибудь в красный/выделить жирным

Сделайте так, чтобы среди тех, кто обсуждает эти задачи, был хотя бы один человек, способный спросить «зачем?». Если вы не будете задавать такой вопрос каждой новой фиче, то ваш продукт раздуется до таких размеров, что действительно важным вещам просто не найдется места среди пяти разных выгрузок и выделений красным.

#чтобычто

Как мы мониторим заказы

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

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

​​Сервис: uptimerobot

На рынке есть куча SaaS-решений для мониторинга работоспособности — от простого statuscake родом из 2000-х, до дорогущего new relic или специализированных связок из prometheus и продуктов elastic.

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

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

За 5,5$ в месяц дают мониторить неограниченное количество сайтов, проверяют их раз в минуту (вместо раза в 5 минут), отслеживают живость SSL-сертификатов и рассылают СМС.

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

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

Ссылки на докерфайлы ведут на закрытые ресурсы, если интересно что-то оттуда — пишите в личку, расскажу.

Красиво решать задачи

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

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

Медленное и некрасивое решение обычно выглядит так: заказчик пришел с проблемой → уходим пилить → заказчик пришел еще с одной проблемой → проебали обе.

Красивое и быстрое — так: заказчик пришел с проблемой → быстро снимаем боль → решаем другие задачи, параллельно думаем над красивым решением → как только придумали — выкатываем, если ничего не придумали, то записываем техдолг.

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

Пример решения из предыдущего поста

У нас в mtrl.ai есть понятие «виртуального склада» — это огромный массив ценовых предложений со строительных рынков, который мы накопили и постоянно обновляем. Благодаря этому массиву мы можем быстро прогнозировать конкретный рынок (и даже конкретного продавца), который лучше всего повезёт заказ.

После определённого объёма мы стали упираться в производительность базы — прогнозы нужны почти в реальном времени, а данные хранятся в нормализованном виде.

Чтобы задача не болела, мы применили тупое решение — просто увеличили в два раза ресурсы на сервере с базой.

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

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

В итоге мы потратили 30 минут вместо трёх дней просто за счет того, что дали себе спокойно подумать.

Как я распределяю нагрузку среди членов команды: буфер

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

Самое главное правило — не обманывать себя при планировании и помнить, что планы без запаса не сбываются.

Свой запас я держу в буфере, который называется «можно проебать», это прям такой лейбл в трекере. Лейбл ставится на задачи, которые мы будем делать только, если успеем закончить остальные.

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

Если спринт спланирован хорошо, то примерно половина из буферных задач успешно закрывается. Если плохо — закрываются или все, или ни одной.

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

Знакомая проблема?

"У нас в бэклоге есть много задач, которые мы реализуем, но очень медленно. Что делать? Искать инвестиции на увеличение количества разработчиков? Как-то разделять задачи по приоритетам – но как?".

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

2. Как ни странно – 2. Увеличение количества разработчиков на реализацию одной фичи, скорее всего, увеличит время разработки этой фичи. Эффект, подмеченный еще Бруксом в "Мифическом человеко-месяце".

3. Единственный совет, который можно дать в такой ситуации – разделить все задачи на три категории.
– Первая категория – реализация фич, которые уверенно дадут вам улучшение конверсии. Эта уверенность базируется на их очевидности. Следствие из очевидности – увеличение конверсии будет ожидаемым, но не критичным.
– Вторая категория – фичи из серии "Хрен его знает, но это может быть круто". Мы не знаем, сработает это или нет. Но, если сработает – конверсия вырастет в разы.
– Третья категория – фичи из серии "Полезно, красиво, удобно, нужно".

4. Так вот, в первую очередь надо реализовывать задачи из второй категории. Потому что этап стартапа – это этап проверки рискованных гипотез. Только в них заложен шанс на взрывной рост.

5. Если мы добираемся до задач из первой категории, стоит задать себе вопрос – а мы уже исчерпали фантазию по поводу рискованных гипотез? Мы уже довольны тем ростом, который у нас есть?

6. А вот задачи из третьей категории вообще не надо реализовывать. Никогда.

Как я распределяю нагрузку среди членов команды: обещания

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

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

Ребята знают, что в ситуации, когда ничего не успевается, нужно не страдать ночами над клавиатурой, а идти ко мне и обсуждать проблему. Спринты у нас длятся с понедельника по понедельник, и обычный день для таких обсуждений — четверг (помните про правило 50%?)

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

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

Изучение того, как флексить, стоит с советов Товеровского.

Сегодня выкладываю подборку материалов, которую мы используем в mtrl.ai для обучения новых программистов. Эта статья в вики так и называется — «Что сделать, приступая к работе».

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

Правила
1. Мы работаем через Github flow.
2. Беклог храним в issues, спринты планируем в milestones.
3. Спринт длится одну неделю, со вторника по понедельник включительно.
4. Мы знаем, что значит сделать.
5. Не решаем придуманные проблемы.


Бекенд
1. Если не чувствуете себя уверенно с Питоном, то почитайте Марк Лутц — Изучаем Питон.
2. Если вдруг еще не знаете, изучите PEP-8.
3. Если мало работали с Джанго, то пройдите официальную обучалку.
4. Прочитайте Требования к коду.
5. Почитайте про TDD.
6. Прочитайте Obey the testing goat.
7. Почитайте про REST и изучите Django REST Framework.
8. Изучите процесс CI и поймите, что делается на каждом этапе.

Фронтенд
1. Изучите ES2015.
2. Изучите airbnb style guide.
3. Для работы над сайтом изучите CSS Grids, или вот, вот и вот.
4. Прочитайте документацию Вью, Вьюкс, Вью-роутера и накста.
5. Изучите ководство и пришлите Федору 5 статей, которые считаете самыми важными.
6. Чтобы писать меньше CSS, изучите Стилус для бекофиса и SCSS для всего остального.
7. Посмотрите Технолог — тоже дизайнер.
8. Чтобы лишний раз не переспрашивать у бекендера, как выполнить ту или иную манипуляцию данными, почитайте про REST.
9. Почитайте про анимацию для разработчиков интерфейсов.
10. Почитайте о том, как писать надписи в интерфейсах.


Коммуникация
1. Настроить пустой инбокс с единой папкой входящих. Почта — основное средство связи в команде.
2. Прописать в почте имя и фамилию ЛАТИНИЦЕЙ.
3. Убедиться, что коммиты в гитхаб делаются от твоего имени.
4. Вступить в чатик для обмена гифками и присылать не менее двух мемасиков в день.