FEDOR BORSHEV
Управление проектами
Подписаться
Фундамент для автоматизации

Первая автоматизация, которая должна появиться в вашем проекте
- непрерывная доставка.

CI/CD
- это процесс, который после каждого коммита выполняет манипуляции над кодом: валидирует, тестирует и снимает метрики качества. В случае, если код ок, то CD автоматически раскатывает его по серверам.

CD спасает программистов от кучи рутины: не нужно хранить ключи от серверов, ждать выполнения проверок на локальной машине (любой SaaS умеет пускать тесты хоть в 10 потоков), настраивать окружение для деплоя.

Налаженный процесс CI/CD открывает дорогу к куче ускоряющих/удешевляющих практик: 10 релизов в день, gitflow, TDD/BDD. Даже Agile (простите) не работает без непрерывной доставки.

Вопреки заблуждению, которое я часто слышу от коллег, чтобы внедрить простейший CI/CD не нужно усложнять инфраструктуру. В начальном варианте не нужны даже docker и ansible
- достаточно пары скриптов, которые может написать любой знакомый с bash программист.

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

Самый крутой CI
- circleci.com. Полный каталог всех сервисов
- на гитхабе.

Другие статьи канала FEDOR BORSHEV

FEDOR BORSHEV
Управление проектами
Подписаться
Плато продуктивностиОбычно уровень работоспособности выглядит так:

Плато продуктивности

Обычно уровень работоспособности выглядит так: ∿∿∿∿. Подъёмы чередуются со спадами. На подъёме хорошо заниматься творчеством, на спаде
- рутиной: закрывать долги, отвечать на письма, общаться с коллегами. Если на спаде сделать творческую работу, ее скорее всего придётся переделывать
- вы проснетесь утром и поймёте, что результат никуда не годен.

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

Работа с некачественным кодом сильно выматывает
- вместо фокуса на цели приходится разбираться, о чем же думал «тот парень» (и тот, кто его подгонял). В таком режиме волна продуктивности превращается в болото: ∿∿
-\____. Хочется уволиться и пойти работать машинистом метро.

Нормальная загрузка программиста похожа на плато:
-
-
-
-
-
-. На плато нет всплесков вроде срочных задач и эмоциональных подъёмов. Но нет и болота с унылым разгребанием долгов. Программист на большом проекте
- это марафонец.

FEDOR BORSHEV
Управление проектами
Подписаться
СтражникиСколько ваших пользователей видят ошибки яваскрипта, когда заходят на главную?

​​Стражники

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

Существует несколько сервисов для мониторинга таких вещей. Я рекомендую sentry.io или opbeat.com. Последний ещё и умеет мониторить производительность приложения. Оба сервиса бесплатны на небольших нагрузках.

Важнейший эффект от этих сервисов
- моментальная обратная связь. Если программист выкатил код, который вызывает ошибку у 40% пользователей, он узнает об этом сразу, ещё находясь в контексте задачи. А не на следующий день, погрузившись в соседний проект. Меньше переключений
->
меньше срочной работы
->
больше производительность.

Сервисы очень легко устанавливаются на фронтенд любого сайта. На бекенд, если у вас не битрикс
- тоже.

FEDOR BORSHEV
Управление проектами
Подписаться
Я не знаю ни одного владельца нового макбука, который был бы доволен тачбаром.

Написал статью, которая рассказывает, как не отвлекаться на ненужные кнопки и переключающиеся треки: http://telegra.ph/Kak-zhit-s-tachbarom-02-27-2

FEDOR BORSHEV
Управление проектами
Подписаться
​​Не любить новые фичи

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

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

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

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

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

Трезвый менеджер, наоборот, думает про цифры
- на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет
- фича режется.

Давайте экономить деньги и не любить фичи.

FEDOR BORSHEV
Управление проектами
Подписаться
У канала новости — благодаря Саше Бизикову обновилась иконка.

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

Вторая новость: благодаря пинку от все того же Саши, наша дорогая редакция наконец-то определилась с форматом канала.

Все новые заметки будут посвящены одной (и моей любимой) теме
- производству сложных проектов с позиции CTO. Тем много
- инструментарий, управление командами разработки, построение отношений с бизнесом, проектный менеджмент. Иногда будут появляться новости про мой любимый стек
- Python и vue.js.

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

FEDOR BORSHEV
Управление проектами
Подписаться

FEDOR BORSHEV
Управление проектами
Подписаться

FEDOR BORSHEV
Управление проектами
Подписаться
Гитхаб продолжает удивлять своей заботой о программистах.

Если упомянуть какой-нибудь опенсорсный проект внутри своего приватного, то тег покажется на странице опенсорсного проекта. И увижу его только я и члены моей команды.

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

Гитхаб
- это те ребята, которым точно стоит заплатить денег, чтобы они захостили ваш код.

FEDOR BORSHEV
Управление проектами
Подписаться
Книга:

Голая Статистика Статистика
- единственная полезная наука, которую нельзя изучить через википедию. Так что если соберетесь
- начните с «Голой статистики» Чарьльза Уиллана.

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

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

>
Систематическая ошибка выбора может возникнуть при различных обстоятельствах. Опрос потребителей в аэропорту искажается тем фактом, что любители летать самолетами, как правило, более состоятельные люди, чем население в целом;
в случае проведения опроса на площадке для отдыха возле автомагистрали Interstate 90 может сложиться противоположная ситуация.

>
На результаты обоих опросов наверняка повлияет и то, что люди, готовые в них участвовать, отличаются от людей, предпочитающих не отвлекаться на подобные вещи. Если вы попросите 100 человек в каком-либо общественном месте заполнить совсем небольшую анкету, то те 60, которые согласятся это сделать, наверняка будут существенно отличаться от остальных 40, которые вас проигнорируют.

Книга продается на озоне.

FEDOR BORSHEV
Управление проектами
Подписаться
Тестовые задания для программистов

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

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

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

Такое задание
- как открытый вопрос. Поймет ли новенький наш стиль для названий тестов? Не испугается ли сложности? Дополнит ли документацию? Напишет ли переиспользуемый код? Не постесняется задавать вопросы? Выдержит ли дедлайн, который сам назовёт?

Если вдруг проект не получается отдать из-за НДА-шных причин
- отдаю специально хранимый для этих целей pet project.

FEDOR BORSHEV
Управление проектами
Подписаться
Как обещания влияют на фокус команды

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

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

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

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

И кстати
- это win-win. Потому что кураторы очень рады получать эти письма. Ведь они заплатили за один продукт, и никто не обещал, что мы в течение года добавим кучу фич.

FEDOR BORSHEV
Управление проектами
Подписаться
Работа любого профессионала строится на обещаниях.

Менеджер обещает достичь KPI, программист
- сдать задачу в срок, пилот самолета
- довезти пассажиров из точки A в точку Б. Хорошо, когда длинная задача разбита на маленькие циклы «пообещал» → «сделал». Бизнесу это дает прозрачность
- всегда видно ваш следующий шаг. Вам лично это позволяет быстро оценивать состояние дел
- не расходится ли количество «пообещал» с количеством «сделал»?

Марьяна Онысько рассказывает о том, как они в электронной библиотеке МИФа дают обещания, которые зажигают не только команду, но и клиента:

FEDOR BORSHEV
Управление проектами
Подписаться

Тяжелее всех наверное приходится бедным пользователям iPhone / iPad, в попытках отсканировать именно свой QR-код, чтобы случайно не скачать приложение под Windows или Android

FEDOR BORSHEV
Управление проектами
Подписаться

Тройное комбо

FEDOR BORSHEV
Управление проектами
Подписаться
Без срочных задач Во всех своих командах я избавляюсь от срочных задач.

Люблю, когда даже в трекере такого флага нет.

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

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

Конечно, не все люди совместимы с таким графиком
- даже среди высокоразвитых профессионалов много таких, которые зависят от внешних стимулов. Такие люди обычно выявляются за первые две недели испытательного срока. Зависимость от внешних стимулов
- не порок, это скорее индивидуальные особенности. Есть же чуваки, которые наоборот, не совместимы с большими компаниями (как я), или в принципе не могут работать без личного контакта с  коллегами.

Вот вам три шага, чтобы победить срочные задачи в вашей команде:

? Разберитесь с техническими и управленческими долгами. Чаще всего срочные задачи возникают на уровне «я выкатил, а оно упало», и «я выкатил, а через неделю поняли, что нихуя не работает». Чтобы привести долги в порядок, нужна сила воли и пара месяцев. Если вы понимаете, что за два месяца не разберетесь
- значит что-то в вашем проекте серьезно не в порядке, нужно все бросать и лечить.? Перестаньте оценивать задачи в часах. Если в вашей команде меньше 5 человек
- совсем не оценивайте. Если больше, и план на неделю не удается обсудить с каждым лично
- попробуйте оценивать днями.? Возьмите комфортный интервал планирования, на который вы можете построить четкий план, к примеру 1 неделю. Заложите запас и не трогайте ребят в течение этого интервала.

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...