Мне тут подсказывают, что таймер не совсем живой, однако иллюзия очень крутая — открываешь письмо, а оно ШЕВЕЛИТСЯ

​​Как убить технаря в руководителе

Александр Трофимов рассказывает обо всех граблях, на которые наступил, когда из программиста превратился в руководителя.

Рассказ — длинный. Там и попытки делать работу за других, и микроконтроль и даже Павлик Морозов. Опыт Александра взят из Лаборатории Касперского, однако специфики больших компаний совсем не много. Есть видеоверсия.

Рассказ будет полезен если вы (или ваши подчиненные) только что резко повысили свой уровень ответственности.

Картинка на тему одной известной книги, посвященной управлению программистами:

Без срочных задач

Во всех своих командах я избавляюсь от срочных задач. Люблю, когда даже в трекере такого флага нет.

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

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

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

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

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

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

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

Работа любого профессионала строится на обещаниях. Менеджер обещает достичь KPI, программист — сдать задачу в срок, пилот самолета — довезти пассажиров из точки A в точку Б.

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

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

Как обещания влияют на фокус команды

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

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

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

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

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

Тестовые задания для программистов

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

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

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

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

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

​​Книга: Голая Статистика

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

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

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

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

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

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

​​Гитхаб продолжает удивлять своей заботой о программистах.

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

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

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

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

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

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

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

​​Как удобно планировать встречи

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

Минус публичного календаря — сложно открывать его наружу компании, к примеру для собеседований или подрядчиков. Чтобы записаться, получателю приходится обязательно регистрироваться в гугль-каленадре. Процесс записи тоже сложен — как человеку извне можно понять, удобно ли мне созвониться в 21:00, или просто это время свободное?

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

Чтобы решать эти проблемы, существуют сервисы планирования, вроде calendly.com или appoint.ly. Основной продукт у этих сервисов предельно простой — создаешь в них расписание, подключаешь свой календарь и получаешь публичную ссылку, которую рассылаешь всем авторизованным.

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

Вот так к примеру выглядит ссылка на мой календарь сегодня:

​​Не любить новые фичи

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

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

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

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

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

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

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

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

​​Стражники

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

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

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

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

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

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

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

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

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

Фундамент для автоматизации

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

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

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

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

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

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

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

​​Теория игр

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

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

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

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

Ни с кем не встречаюсь по понедельникам

Уже несколько лет я практикую классное правило продуктивности — ни с кем не встречаться по понедельникам.

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

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

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

В терминологии ГТД мой личный понедельник называется «еженедельный обзор».